[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-apl] fpc/freepascal interface - c code using inner/outer produc
|
From: |
enztec |
|
Subject: |
Re: [Bug-apl] fpc/freepascal interface - c code using inner/outer product or unquote welcome |
|
Date: |
Thu, 8 Aug 2019 16:06:57 -0600 |
Hi
---
simple quesion on ⎕ARG it doesn't have a value using libapl? (no command
line arguments right?)
---
i did a fresh compile of the svn and the init with libapl gives
*** glibc detected *** ./aplc: free(): invalid pointer: 0x094a22dc ***
while no glibc problem with libcurl or mysql using init - same exact program
format and compile using same static line - if the problem was my environment
wouldn't you expect them to have problems also?
this was the web page that fixed the glibc detected free invalid pointer
https://stackoverflow.com/questions/19941413/glibc-detected-free-invalid-pointer
---
alsoi using
init_libapl(argv[0],0);
with or without init gives
Executable ./APs/APserver not found.
This could means that 'apl' was not installed ('make install') or that it
was started in a non-standard way. The expected location of APserver is
either the same directory as the binary 'apl' or the subdirectory 'APs' of
that directory (the directory should also be in $PATH).
and doesn't seem to affect anything i'm coding with or without using init
what setting would affect use of ]BOXING it only works with init
---
On Wed, 7 Aug 2019 18:17:10 +0200
Dr. Jürgen Sauermann <address@hidden> wrote:
> Hi,
>
> sorry, I was on my way to work and tried to give a quick hint. I was
> assuming
> that your sem_init() fails which I have seen earlier but probably for
> other reasons.
>
> I dont quite follow what you are doing, because the libraries on my
> platform behave
> differently than on yours (what is your platform anyway?).
>
> You say that:
>
> _init() only works with stc static line and ⎕PW is 80 but it segaults at the
> end
>
>
> The problem is that the static libapl.a does not even have an _init()
> function on my
> platform, therefore I wonder whats happening if you call _init().
> Apparently it does
> something good on one hand (initializing ⎕PW) but something bad on exit
> (segfault).
>
> One thing to note is that the segfault occurs when the program exit()s.
> That is, the segfault
> most likely does not come from seminit().
>
> My current theory is roughly this:
>
> 1. In the static case, I assume that _init() is not contained libapl.a
> (check with nm !) so
> you probably call some other _init() function in, say crt0.S or so.
>
> 2. Calling it explicitly does something good, but
> also re-allocates memory, overriding the pointer that is free()d
> (possibly twice) on exit().
> Some init() functions install themeselves in a way that causes them to
> be called on exit()
> again, but with a different argument that tells whether they shall
> initialize or de-initialize.
>
> 3. All of that suggests some kind of improper initialization of libapl
> (which is fairly
> obvious when ⎕PW is 0). This happens before main() is called, (and your
> segfault
> occurs after main() has returned) and therefore GNU APL cannot do
> anything about it.
>
> 4. See also 'man dlopen' regarding _init(). Maybe you need a special
> linker script for
> your case.
>
> A work-around could be to not use libapl at all, but instead to modify
> the existing
> main.cc of GNU APL (in file src/main.cc) to suit your needs. That makes
> sure that
> the C++ stuff is being initialized properly. Another option is to use
> libtool, which
> supposedly deals with dynamic linking issues and MAY fix the problem
> that you see.
> I am using libtool for GNU APL, but I am not an expert in that area.
>
> I tend to believe that the entire problem is less with my code but more
> with your
> environment.
>
> And I also have lots of other things to do.
>
>
>
> On 8/7/19 3:07 PM, address@hidden wrote:
> > Jurgen
> >
> > You seem to only read the top of what i write
> >
> > you have a problem with your code and i am trying to help you find it - i
> > shouldn't even be having to run _init and never mind my needing to run
> > sem_init
> >
> > if you don't want to read my emails tell me - i have lots of things that i
> > can spend my time on
> >
> >
> >
> >
> > On Wed, 7 Aug 2019 12:39:36 +0200
> > Dr. Jürgen Sauermann <address@hidden> wrote:
> >
> >> Hi,
> >>
> >> a simple way to test is setting:
> >>
> >> #define HAVE_SEM_INIT 0
> >>
> >> in config.h (after ./configure). That switches from the standard
> >> sem_init() to a different implementation which works better on
> >> some platforms.
> >>
> >>
> >> On 8/7/19 1:33 AM, address@hidden wrote:
> >>> Hi
> >>>
> >>>> See Common.hh for details and check
> >>>> HAVE_SEM_INIT
> >>>> in config.h to see which decision ./configure has made.
> >>> from config.h
> >>> /* Define to 1 iff sem_init() works */
> >>> #define HAVE_SEM_INIT 1
> >>>
> >>> i tried putting
> >>>
> >>> Q(sem);
> >>> Q(pshared);
> >>> Q(value);
> >>>
> >>> in a bunch of different places to find the values for sem_init (never
> >>> did) but then realized the program already has them - if they are wrong -
> >>> what values should i try?
> >>>
> >>> ----
> >>>
> >>> Now my fun stuff - working on resolving the _init() segfault since i have
> >>> no idea how to form a good sem_init() line
> >>>
> >>> ---
> >>>
> >>> # stc
> >>>
> >>> f="aplc"
> >>> # static gcc line
> >>> gcc $f.c -lpthread -lncurses -lxcb -ldl -lm -lsqlite3 -lstdc++
> >>> /usr/local/lib/apl/libapl.a -o $f -O2 <-- note no -lc
> >>>
> >>> # dynamic gcc lind
> >>> $gcc $f.c -L /usr/local/lib/apl -lapl -o $f -O2
> >>>
> >>> ./$f
> >>>
> >>> ---
> >>>
> >>> // aplc.c stc from /fpc/current/apl/html/msg00009.html from
> >>> libapl_test.c
> >>>
> >>> #include <stdio.h>
> >>> //#include <stdlib.h>
> >>> #include <apl/libapl.h>
> >>> //#include "/usr/local/include/apl/libapl.h"
> >>>
> >>> //int main(int argc, const char *argv[])
> >>> int main(int argc, char *argv[])
> >>> {
> >>> printf("Hello, World!\n");
> >>>
> >>> _init();
> >>>
> >>> //sem_init(sem, pshared, value);
> >>>
> >>> //init_libapl(argv[0], 0);
> >>> //init_libapl("main", 0);
> >>>
> >>> apl_exec("⎕←2 3⍴⍳6 ◊ ⎕←a←'2 3⍴⍳6' ◊ ⎕←⍎a");
> >>> printf("Hello, World!\n");
> >>>
> >>> return 0;
> >>> }
> >>>
> >>> ---
> >>>
> >>> the dynamic stc line doesn't initialze ⎕PW and it is 0 so the little
> >>> UCS_string.cc change to 80 gives good runtime and there is no segfault
> >>>
> >>> _init() only works with stc static line and ⎕PW is 80 but it segaults at
> >>> the end
> >>>
> >>> *** how come the _init() doesn't work with the dynamic gcc line (i think
> >>> i (maybe we) lucked out with my doing the static gcc just for fun) to
> >>> show this
> >>>
> >>> --
> >>>
> >>> when i do
> >>>
> >>>> gdb aplc
> >>> (gdb) run
> >>>
> >>> Hello, World!
> >>> quad_PW: '80' at UCS_string.cc:344
> >>> 1 2 3
> >>> 4 5 6
> >>> quad_PW: '80' at UCS_string.cc:344
> >>> 2 3⍴⍳6
> >>> quad_PW: '80' at UCS_string.cc:344
> >>> 1 2 3
> >>> 4 5 6
> >>> Hello, World!
> >>>
> >>> Program received signal SIGSEGV, Segmentation fault.
> >>> 0xb7c57e29 in __GI___libc_free (mem=0x82dfb14) at malloc.c:3737
> >>> 3737 malloc.c: No such file or directory.
> >>>
> >>> (gdb) bt
> >>> #0 0xb7c57e29 in __GI___libc_free (mem=0x82dfb14) at malloc.c:3737
> >>> #1 0xb7dafbdf in operator delete (ptr=0x82dfb14) at
> >>> /usr/src/gcc/gcc-4.8.5/libstdc++-v3/libsupc++/del_op.cc:47
> >>> #2 0x0804e4c3 in __gnu_cxx::new_allocator<char>::deallocate
> >>> (this=<optimized out>, __p=<optimized out>)
> >>> at /usr/local/gcc-4.8.5/include/c++/4.8.5/ext/new_allocator.h:110
> >>> #3 std::basic_string<Unicode, std::char_traits<Unicode>,
> >>> std::allocator<Unicode> >::_Rep::_M_destroy (__a=..., this=<optimized
> >>> out>)
> >>> at /usr/local/gcc-4.8.5/include/c++/4.8.5/bits/basic_string.tcc:449
> >>> #4 std::basic_string<Unicode, std::char_traits<Unicode>,
> >>> std::allocator<Unicode> >::_Rep::_M_dispose (this=<optimized out>,
> >>> __a=...)
> >>> at /usr/local/gcc-4.8.5/include/c++/4.8.5/bits/basic_string.h:249
> >>> #5 0x0808f879 in std::basic_string<Unicode, std::char_traits<Unicode>,
> >>> std::allocator<Unicode> >::_Rep::_M_dispose (__a=...,
> >>> this=<optimized out>) at LineInput.hh:45
> >>> #6 std::basic_string<Unicode, std::char_traits<Unicode>,
> >>> std::allocator<Unicode> >::~basic_string (this=0x82e92f0,
> >>> __in_chrg=<optimized out>) at
> >>> /usr/local/gcc-4.8.5/include/c++/4.8.5/bits/basic_string.h:539
> >>> #7 UCS_string::~UCS_string (this=0x82e92f0, __in_chrg=<optimized out>)
> >>> at UCS_string.hh:98
> >>> #8 std::_Destroy<UCS_string> (__pointer=0x82e92f0) at
> >>> /usr/local/gcc-4.8.5/include/c++/4.8.5/bits/stl_construct.h:93
> >>> #9 std::_Destroy_aux<false>::__destroy<UCS_string*> (__last=<optimized
> >>> out>, __first=0x82e92f0)
> >>> at /usr/local/gcc-4.8.5/include/c++/4.8.5/bits/stl_construct.h:103
> >>> #10 std::_Destroy<UCS_string*> (__last=<optimized out>,
> >>> __first=<optimized out>)
> >>> at /usr/local/gcc-4.8.5/include/c++/4.8.5/bits/stl_construct.h:126
> >>> #11 std::_Destroy<UCS_string*, UCS_string> (__last=0x82e92f4,
> >>> __first=<optimized out>)
> >>> at /usr/local/gcc-4.8.5/include/c++/4.8.5/bits/stl_construct.h:151
> >>> #12 std::vector<UCS_string, std::allocator<UCS_string> >::~vector
> >>> (this=0x825e4d8 <LineHistory::quad_INP_history+12>,
> >>> __in_chrg=<optimized out>) at
> >>> /usr/local/gcc-4.8.5/include/c++/4.8.5/bits/stl_vector.h:415
> >>> #13 UCS_string_vector::~UCS_string_vector (this=0x825e4d8
> >>> <LineHistory::quad_INP_history+12>, __in_chrg=<optimized out>)
> >>> at UCS_string_vector.hh:30
> >>> #14 LineHistory::~LineHistory (this=0x825e4cc
> >>> <LineHistory::quad_INP_history>, __in_chrg=<optimized out>) at
> >>> LineInput.hh:45
> >>> #15 0xb7c17a29 in __run_exit_handlers (status=status@entry=0,
> >>> listp=0xb7d49344 <__exit_funcs>,
> >>> run_list_atexit=run_list_atexit@entry=true)
> >>> at exit.c:78
> >>> #16 0xb7c17a8d in __GI_exit (status=0) at exit.c:100
> >>> #17 0xb7c008ab in __libc_start_main (main=0x80503e0 <main>, argc=1,
> >>> ubp_av=0xbffff684, init=0x81cc210 <__libc_csu_init>,
> >>> fini=0x81cc280 <__libc_csu_fini>, rtld_fini=0xb7fed120 <_dl_fini>,
> >>> stack_end=0xbffff67c) at libc-start.c:258
> >>> #18 0x080580c1 in _start () at ../sysdeps/i386/elf/start.S:119
> >>> (gdb) quit
> >>>
> >>> -
> >>>
> >>> i don't have a malloc.c file on the computer so i figured it was in the
> >>> glibc source and compiled into libc (-lc))
> >>> so i added -lc to the static line and i got this
> >>>
> >>> -
> >>>
> >>> gcc aplc.c -lpthread -lncurses -lxcb -ldl -lm -lc -lsqlite3 -lstdc++
> >>> /usr/local/lib/apl/libapl.a -o aplc -O2
> >>>
> >>> Hello, World!
> >>> quad_PW: '80' at UCS_string.cc:344
> >>> 1 2 3
> >>> 4 5 6
> >>> quad_PW: '80' at UCS_string.cc:344
> >>> 2 3⍴⍳6
> >>> quad_PW: '80' at UCS_string.cc:344
> >>> 1 2 3
> >>> 4 5 6
> >>> Hello, World!
> >>> *** glibc detected *** ./aplc: free(): invalid pointer: 0x0a22e71c ***
> >>> ======= Backtrace: =========
> >>> /lib/libc.so.6(+0x6c1ea)[0xb759b1ea]
> >>> /lib/libc.so.6(+0x6ccf4)[0xb759bcf4]
> >>> /lib/libc.so.6(cfree+0x69)[0xb759ee39]
> >>> /usr/local/gcc/lib/libstdc++.so.6(_ZdlPv+0x1f)[0xb73d8bdf]
> >>> ./aplc[0x804e4a3]
> >>> ./aplc[0x808f8c9]
> >>> /lib/libc.so.6(+0x2fa29)[0xb755ea29]
> >>> /lib/libc.so.6(+0x2fa8d)[0xb755ea8d]
> >>> /lib/libc.so.6(__libc_start_main+0xfb)[0xb75478ab]
> >>> ./aplc[0x8058091]
> >>> ======= Memory map: ========
> >>> 08048000-08251000 r-xp 00000000 08:01 303186 /fpc/current/apl/aplc
> >>> 08251000-08254000 rw-p 00208000 08:01 303186 /fpc/current/apl/aplc
> >>> 08254000-082a4000 rw-p 00000000 00:00 0
> >>> 0a1f2000-0a255000 rw-p 00000000 00:00 0 [heap]
> >>> b736b000-b736d000 rw-p 00000000 00:00 0
> >>> b736d000-b7371000 r-xp 00000000 08:07 551694
> >>> /usr/local/lib/libXdmcp.so.6.0.0
> >>> b7371000-b7372000 rw-p 00003000 08:07 551694
> >>> /usr/local/lib/libXdmcp.so.6.0.0
> >>> b7372000-b7373000 rw-p 00000000 00:00 0
> >>> b7373000-b7375000 r-xp 00000000 08:07 551142
> >>> /usr/local/lib/libXau.so.6.0.0
> >>> b7375000-b7376000 rw-p 00001000 08:07 551142
> >>> /usr/local/lib/libXau.so.6.0.0
> >>> b7376000-b7390000 r-xp 00000000 08:07 854990
> >>> /usr/local/gcc-4.8.5/lib/libgcc_s.so.1
> >>> b7390000-b7391000 rw-p 0001a000 08:07 854990
> >>> /usr/local/gcc-4.8.5/lib/libgcc_s.so.1
> >>> b7391000-b746c000 r-xp 00000000 08:07 854991
> >>> /usr/local/gcc-4.8.5/lib/libstdc++.so.6.0.19
> >>> b746c000-b746d000 ---p 000db000 08:07 854991
> >>> /usr/local/gcc-4.8.5/lib/libstdc++.so.6.0.19
> >>> b746d000-b7471000 r--p 000db000 08:07 854991
> >>> /usr/local/gcc-4.8.5/lib/libstdc++.so.6.0.19
> >>> b7471000-b7472000 rw-p 000df000 08:07 854991
> >>> /usr/local/gcc-4.8.5/lib/libstdc++.so.6.0.19
> >>> b7472000-b7479000 rw-p 00000000 00:00 0
> >>> b7479000-b752c000 r-xp 00000000 08:07 550637
> >>> /usr/local/lib/libsqlite3.so.0.8.6
> >>> b752c000-b752f000 rw-p 000b3000 08:07 550637
> >>> /usr/local/lib/libsqlite3.so.0.8.6
> >>> b752f000-b768d000 r-xp 00000000 08:01 1541178 /lib/libc-2.11.3.so
> >>> b768d000-b768e000 ---p 0015e000 08:01 1541178 /lib/libc-2.11.3.so
> >>> b768e000-b7690000 r--p 0015e000 08:01 1541178 /lib/libc-2.11.3.so
> >>> b7690000-b7691000 rw-p 00160000 08:01 1541178 /lib/libc-2.11.3.so
> >>> b7691000-b7695000 rw-p 00000000 00:00 0
> >>> b7695000-b76bd000 r-xp 00000000 08:01 1540754 /lib/libm-2.11.3.so
> >>> b76bd000-b76be000 r--p 00027000 08:01 1540754 /lib/libm-2.11.3.so
> >>> b76be000-b76bf000 rw-p 00028000 08:01 1540754 /lib/libm-2.11.3.so
> >>> b76bf000-b76c2000 r-xp 00000000 08:01 1541164 /lib/libdl-2.11.3.so
> >>> b76c2000-b76c3000 r--p 00002000 08:01 1541164 /lib/libdl-2.11.3.so
> >>> b76c3000-b76c4000 rw-p 00003000 08:01 1541164 /lib/libdl-2.11.3.so
> >>> b76c4000-b76ea000 r-xp 00000000 08:07 548998
> >>> /usr/local/lib/libxcb.so.1.1.0
> >>> b76ea000-b76eb000 rw-p 00026000 08:07 548998
> >>> /usr/local/lib/libxcb.so.1.1.0
> >>> b76eb000-b7737000 r-xp 00000000 08:01 1540114 /lib/libncurses.so.6.1
> >>> b7737000-b773a000 rw-p 0004b000 08:01 1540114 /lib/libncurses.so.6.1
> >>> b773a000-b7751000 r-xp 00000000 08:01 1541128 /lib/libpthread-2.11.3.so
> >>> b7751000-b7752000 r--p 00016000 08:01 1541128 /lib/libpthread-2.11.3.so
> >>> b7752000-b7753000 rw-p 00017000 08:01 1541128 /lib/libpthread-2.11.3.so
> >>> b7753000-b7755000 rw-p 00000000 00:00 0
> >>> b776a000-b776c000 rw-p 00000000 00:00 0
> >>> b776c000-b776d000 r-xp 00000000 00:00 0 [vdso]
> >>> b776d000-b778c000 r-xp 00000000 08:01 1540725 /lib/ld-2.11.3.so
> >>> b778c000-b778d000 r--p 0001f000 08:01 1540725 /lib/ld-2.11.3.so
> >>> b778d000-b778e000 rw-p 00020000 08:01 1540725 /lib/ld-2.11.3.so
> >>> bfdcf000-bfde4000 rw-p 00000000 00:00 0 [stack]
> >>> ./stc: line 34: 29302 Aborted ./$f
> >>>
> >>> -
> >>>
> >>> so i googled
> >>>
> >>> glibc detected *** ./aplc: free(): invalid pointer
> >>>
> >>> and found this
> >>>
> >>> https://stackoverflow.com/questions/19941413/glibc-detected-free-invalid-pointer
> >>>
> >>> and did the program and the fix for it
> >>> int *temp = ptr; iniital ptr -> temp
> >>> then free(temp); commenting free(ptr);
> >>>
> >>> and the fix worked
> >>>
> >>>
> >>> #include<stdlib.h>
> >>> #include<stdio.h>
> >>> #include<assert.h>
> >>> int main()
> >>> {
> >>> int x = 5;
> >>> int *ptr = (int*) malloc(sizeof(int));
> >>> int *temp = ptr; // added
> >>> assert(ptr != NULL);
> >>> ptr = &x;
> >>> printf("x = %d\n",x);
> >>> *ptr = 3;
> >>> printf("x = %d\n",x);
> >>> //free(ptr);
> >>> free(temp); // added
> >>> return 0;
> >>> }
> >>>
> >>> ---
> >>>
> >>> the weird thing is i have not been able to reproduce the glibc detected
> >>> dump again - i have removed the -lc and run stc and then put it back
> >>> and run stc and never got the glibc detected again
> >>> i had this one time when i initially replace the glibc rpm with glibc
> >>> source - but it too never came back - somewhere something is keeping
> >>> track?
> >>>
> >>> ---
> >>>
> >>> so i think maybe that you have the same problem - you are freeing a
> >>> pointer that doesn't have the initial value anymore?
> >>>
> >>> the backstrace shows our file UCS_string
> >>>
> >>> -----------------------------------------------------
> >>>
> >>> On Tue, 6 Aug 2019 21:36:31 +0200
> >>> Dr. Jürgen Sauermann <address@hidden> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> the "xxx" in init_libapl() is, by convention the name of the executable.
> >>>> The normal apl interpreter uses it to find itself in the file system (as
> >>>> to locate
> >>>> related binaries such as APserver). Probably not too important for
> >>>> libapl.
> >>>>
> >>>> sem_init() is a tricky one. The second argument (pshared) is always 0
> >>>> because
> >>>> all semaphores lock out threads and not processes. The third argument
> >>>> (value)
> >>>> depends on the semaphore and should be left untouched.
> >>>>
> >>>> Problem with sem_init is that it fails on some platforms (compile error
> >>>> on apple, segfault
> >>>> on others). Normally ./configure handles this, but if your platform is
> >>>> not known to
> >>>> configure then it may be wrong, See Common.hh for details and check
> >>>> HAVE_SEM_INIT
> >>>> in config.h to see which decision ./configure has made.
> >>>>
> >>>>
> >>>>
> >>>> On 8/6/19 6:41 PM, address@hidden wrote:
> >>>>> Hi
> >>>>>
> >>>>> the _init(); gets rid of the ⎕PW error in the c program but when
> >>>>> the function exits (on return 0; or at end of function with #return 0;
> >>>>> commented it gives a segfault)
> >>>>> is there something specific that i use to undo the _init(); ???
> >>>>>
> >>>>> the init_libapl("xxx", 0); and with anything as "xxxx" doesn't
> >>>>> have any effect by itself or mixed with one or either of above
> >>>>> it seems to have no effort at all
> >>>>>
> >>>>> the sem_init(); gives immediate segfault
> >>>>> from man 3 sem_init
> >>>>> int sem_init(sem_t *sem, int pshared, unsigned int value);
> >>>>> what values should i try? i had -lpthread already in the gcc line
> >>>>> but had to move it to the front of the line cause of use of sem_init
> >>>>> before use of sem_init i had the libs in order that they resolved
> >>>>> compile problems using the libapl.a
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, 6 Aug 2019 16:23:59 +0200
> >>>>> Dr. Jürgen Sauermann <address@hidden> wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> my concern is this: The "normal" C++ code initializes ⎕PW properly (to
> >>>>>> 80).
> >>>>>> The initialization of ⎕PW occurs in the default constructor
> >>>>>> Quad_PW::Quad_PW().
> >>>>>>
> >>>>>> The same C++ code, when you compile and link it, causes ⎕PW to be
> >>>>>> 0-initialized, which implies that the constructor was not called.
> >>>>>> Since most
> >>>>>> system variables are initialized in the same manner, I am afraid that
> >>>>>> all
> >>>>>> static constructors (which are executed before main() is called) are
> >>>>>> not
> >>>>>> being executed in your case. Static constructors are not only used for
> >>>>>> system
> >>>>>> variables like ⎕PW but also for other C++ objects.
> >>>>>>
> >>>>>> Often a library contain a function, typically named _init() which does
> >>>>>> the initialization before main(). On some platforms that function is
> >>>>>> called
> >>>>>> automatically, on other platforms maybe not. In your case I would call
> >>>>>> _init()
> >>>>>> explicitly, before init_libapl(), and see if the ⎕PW error disappears.
> >>>>>>
> >>>>>> To figure the name of the init functions you can try, for example:
> >>>>>>
> >>>>>> nm -D /usr/local/lib/apl/libapl.so | grep init
> >>>>>>
> >>>>>> I am also working on the GTK configure matter.
> >>>>>>
> >>>>>> Jürgen
> >>>>>>
> >>>>>>
> >>>>>> On 8/5/19 7:41 PM, address@hidden wrote:
> >>>>>>> Good afternoon (in Germany?)
> >>>>>>>
> >>>>>>>> Unfortunately this implies that no only ⎕PW but most likely all other
> >>>>>>>> C++ objects are
> >>>>>>>> not initialized either.
> >>>>>>> what other c++ objects are you thinking about? i can test specific
> >>>>>>> apl code that is affected by things that are or aren't initialized
> >>>>>>>
> >>>>>>> ---
> >>>>>>>
> >>>>>>> i have /usr/local/lib/apl in /etc/ld.so.conf
> >>>>>>>
> >>>>>>> doesn't seem to be a linker problem at all as the compiled program
> >>>>>>> works with either gcc line
> >>>>>>>
> >>>>>>> f="capl"
> >>>>>>> #gcc $f.c -L /usr/local/lib/apl -lapl -o $f -O2
> >>>>>>> gcc $f.c -lncurses -lxcb -lpthread -ldl -lm -lsqlite3 -lstdc++
> >>>>>>> /usr/local/lib/apl/libapl.a -o $f -O2
> >>>>>>>
> >>>>>>> ---
> >>>>>>>
> >>>>>>> so the problem is : not sure why quad_PW is 0 on my machine and 80
> >>>>>>> on yours
> >>>>>>>
> >>>>>>> so the the obvious solution is :
> >>>>>>>
> >>>>>>> Q(quad_PW)
> >>>>>>> if (quad_PW == 0) { quad_PW = 80; }
> >>>>>>> Q(quad_PW)
> >>>>>>>
> >>>>>>> and it fixes it in libapl.so for me
> >>>>>>>
> >>>>>>> i can now call the c function (main renamed to apll and compiled with
> >>>>>>>
> >>>>>>> gcc -c aplc.c -O2 -> aplc.so
> >>>>>>>
> >>>>>>> from fpc/pascal extern/cdecl)
> >>>>>>>
> >>>>>>> as you can see from this c code - it would be a pain to code like
> >>>>>>> this for long vs apl script (called from fpc tprocess method)
> >>>>>>> return apl_exec("⎕←2 3⍴⍳6 ◊ ⎕←a←'2 3⍴⍳6' ◊ ⎕←⍎a");
> >>>>>>>
> >>>>>>> but i'll study the lua docs for how they do it from lua directly so i
> >>>>>>> can call the apl_exec function directly from libapl in fpc/pascal
> >>>>>>> code without the c intermediate .so
> >>>>>>>
> >>>>>>> i'm not going to recompile the apl binary as i know it works
> >>>>>>>
> >>>>>>> ---
> >>>>>>>
> >>>>>>> something else from working on making new libapls.so/libapl.a now
> >>>>>>>
> >>>>>>> if i make the mistake of make distclean instead of just make
> >>>>>>> after i edit the UCS_string.cc file
> >>>>>>>
> >>>>>>> it seems make distclean doesn't do a proper clean up
> >>>>>>>
> >>>>>>> so the next configure --with-libapl ; make fails with
> >>>>>>> ar: libapl_la-Archive.o: No such file or directory
> >>>>>>>
> >>>>>>> a new libapl_la-Arvhive.o is not made but the old one exists and has
> >>>>>>> the same size as when i don't get the make error - so something
> >>>>>>> else is at work here
> >>>>>>>
> >>>>>>> if i do a make clean it does a proper clean up so a new
> >>>>>>> libapl.so can be made
> >>>>>>>
> >>>>>>> but neither make distclean nor make clean deletes
> >>>>>>> the src/.libs dir
> >>>>>>> but the make clean deletes sometime that make distclean
> >>>>>>> doesn't so a new libapl.so can be made
> >>>>>>>
> >>>>>>> if after make clean if i delete the src/.libs dir manually
> >>>>>>> with rm -rf src/.libs/* then i get a good libapl.so
> >>>>>>>
> >>>>>>> but if after make distclean if i delete the src/.libs dir manually
> >>>>>>> with rm -rf src/.libs/* then make fails with
> >>>>>>> g++: error: .libs/libapl_la-*.o: No such file or directory (* ->
> >>>>>>> it lists all the missing files)
> >>>>>>>
> >>>>>>> using --without-gtk3 has no effect here
> >>>>>>>
> >>>>>>> ---
> >>>>>>>
> >>>>>>> thanks Jürgen i much appreciate your help - your c++ code is to
> >>>>>>> complex to even look at - it is apl and fpc for me :)
> >>>>>>>
> >>>>>>> let me know if you need someone to do some configure/make testing for
> >>>>>>> the libpython_apl i couldn't get it made
> >>>>>>>
> >>>>>>> ---
> >>>>>>>
> >>>>>>> On Mon, 5 Aug 2019 12:16:31 +0200
> >>>>>>> Dr. Sauermann <address@hidden> wrote:
> >>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> the output below shows that ⎕PW is not properly initialized. The
> >>>>>>>> floating point
> >>>>>>>> exception is then raised because the length of an output is divided
> >>>>>>>> by
> >>>>>>>> ⎕PW in
> >>>>>>>> order to get the number of lines for the output.
> >>>>>>>>
> >>>>>>>> Unfortunately this implies that no only ⎕PW but most likely all other
> >>>>>>>> C++ objects are
> >>>>>>>> not initialized either.
> >>>>>>>>
> >>>>>>>> This is most likely a problem with how libapl is being linked (a
> >>>>>>>> sort of
> >>>>>>>> moving target
> >>>>>>>> as far as I understand). It is a bit tricky to set up a machine in
> >>>>>>>> such
> >>>>>>>> a way that dynamic
> >>>>>>>> linking works well.
> >>>>>>>>
> >>>>>>>> The way I do it is this:
> >>>>>>>>
> >>>>>>>> 1. make sure that the directory into which libapl.so is installed
> >>>>>>>> (/usr/local/lib/apl in most cases)
> >>>>>>>> is mentioned in /etc/ld.so.conf.d.
> >>>>>>>>
> >>>>>>>> 2. compile like this:
> >>>>>>>>
> >>>>>>>> gcc test_libapl.c -L /usr/local/lib/apl -lapl -o test_libapl
> >>>>>>>>
> >>>>>>>> 3. On my box it then works:
> >>>>>>>>
> >>>>>>>> eedjsa@server68:~/apl-1.8/src$ ./test_libapl
> >>>>>>>> quad_PW: '80' at UCS_string.cc:340
> >>>>>>>> 1 2 3
> >>>>>>>> 4 5 6
> >>>>>>>>
> >>>>>>>> I would strongly suggest to use gcc because compilers and linkers
> >>>>>>>> behave
> >>>>>>>> quite differently
> >>>>>>>> when it comes to dynamic linking. My gcc is this:
> >>>>>>>>
> >>>>>>>> eedjsa@server68:~/apl-1.8/src$ gcc --version
> >>>>>>>> gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0
> >>>>>>>>
> >>>>>>>> Good luck!
> >>>>>>>>
> >>>>>>>> Jürgen
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 8/4/19 7:51 PM, address@hidden wrote:
> >>>>>>>>> Hi
> >>>>>>>>>
> >>>>>>>>> Hello, World!
> >>>>>>>>> quad_PW: '0' at UCS_string.cc:341
> >>>>>>>>> ./stc: line 26: 4895 Floating point exception./$f
> >>>>>>>>>
> >>>>>>>>> ---
> >>>>>>>>>
> >>>>>>>>> (gdb) run
> >>>>>>>>>
> >>>>>>>>> [Thread debugging using libthread_db enabled]
> >>>>>>>>> Using host libthread_db library "/lib/libthread_db.so.1".
> >>>>>>>>> Hello, World!
> >>>>>>>>> quad_PW: '0' at UCS_string.cc:341
> >>>>>>>>>
> >>>>>>>>> Program received signal SIGFPE, Arithmetic exception.
> >>>>>>>>> 0xb7eb5a22 in UCS_string::UCS_string (this=0xbffff008, pb=...,
> >>>>>>>>> rank=2, quad_PW=0) at UCS_string.cc:350
> >>>>>>>>> 350 breakpoints.reserve(2*total_width/quad_PW);
> >>>>>>>>>
> >>>>>>>>> (gdb) bt
> >>>>>>>>> #0 0xb7eb5a22 in UCS_string::UCS_string (this=0xbffff008, pb=...,
> >>>>>>>>> rank=2, quad_PW=0) at UCS_string.cc:350
> >>>>>>>>> #1 0xb7e11fea in PrintBuffer::do_PrintBuffer
> >>>>>>>>> (this=this@entry=0xbffff168, value=..., pctx=...,
> >>>>>>>>> out=out@entry=0xb7f81a40 <COUT>,
> >>>>>>>>> outer_style=outer_style@entry=66560, scaling=..., pcols=...,
> >>>>>>>>> item_matrix=item_matrix@entry=0x8073594) at PrintBuffer.cc:414
> >>>>>>>>> #2 0xb7e13078 in PrintBuffer::PrintBuffer (this=0xbffff168,
> >>>>>>>>> value=..., _pctx=..., out=0xb7f81a40 <COUT>) at PrintBuffer.cc:169
> >>>>>>>>> #3 0xb7ecf633 in Value::print (this=0x8074c48, out=...) at
> >>>>>>>>> Value.cc:1598
> >>>>>>>>> #4 0xb7e9615d in Quad_Quad::assign (this=0xb7fc6964
> >>>>>>>>> <Workspace::the_workspace+263172>, value=..., clone=true,
> >>>>>>>>> loc=0xb7effa50 "Prefix.cc:1665") at SystemVariable.cc:712
> >>>>>>>>> #5 0xb7de61a9 in Prefix::reduce_V_ASS_B_ (this=0x8071220) at
> >>>>>>>>> Prefix.cc:1665
> >>>>>>>>> #6 0xb7dec3b0 in Prefix::reduce_statements
> >>>>>>>>> (this=this@entry=0x8071220) at Prefix.cc:675
> >>>>>>>>> #7 0xb7e7908a in StateIndicator::run (this=0x8070c00) at
> >>>>>>>>> StateIndicator.cc:337
> >>>>>>>>> #8 0xb7db2def in Executable::execute_body (this=0x8073028) at
> >>>>>>>>> Executable.cc:260
> >>>>>>>>> #9 0xb7da99e3 in Command::finish_context () at Command.cc:335
> >>>>>>>>> #10 0xb7daa1c9 in Command::do_APL_expression (line=...) at
> >>>>>>>>> Command.cc:323
> >>>>>>>>> #11 0xb7da94e9 in Command::process_line (line=...) at Command.cc:133
> >>>>>>>>> #12 0xb7ee7829 in apl_exec (line=0x804899e "⎕←2 3⍴⍳6") at
> >>>>>>>>> libapl.cc:361
> >>>>>>>>> #13 0x080488b1 in main ()
> >>>>>>>>> (gdb)
> >>>>>>>>>
> >>>>>>>>> ---
> >>>>>>>>>
> >>>>>>>>> On Sun, 4 Aug 2019 18:43:13 +0200
> >>>>>>>>> Dr. Jürgen Sauermann <address@hidden> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> I see. Could you please change src/UCS_string.cc around line 337
> >>>>>>>>>> to look
> >>>>>>>>>> like this:
> >>>>>>>>>>
> >>>>>>>>>> //-----------------------------------------------------------------------------
> >>>>>>>>>> UCS_string::UCS_string(const PrintBuffer & pb, Rank rank, int
> >>>>>>>>>> quad_PW)
> >>>>>>>>>> {
> >>>>>>>>>>
> >>>>>>>>>> Q(quad_PW)
> >>>>>>>>>>
> >>>>>>>>>> create(LOC);
> >>>>>>>>>> ...
> >>>>>>>>>>
> >>>>>>>>>> I might be that quad_PW is uninitialized for some reason.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 8/4/19 6:26 PM, address@hidden wrote:
> >>>>>>>>>>> Hi
> >>>>>>>>>>>
> >>>>>>>>>>> You started this yesterday emailing me directly - none of this is
> >>>>>>>>>>> going to the mailing list
> >>>>>>>>>>>
> >>>>>>>>>>> (gdb) bt
> >>>>>>>>>>> #0 0xb7eb6953 in UCS_string::UCS_string(PrintBuffer const&, int,
> >>>>>>>>>>> int) () from /usr/local/lib/libapl.so
> >>>>>>>>>>> #1 0xb7e12fea in PrintBuffer::do_PrintBuffer(Value const&,
> >>>>>>>>>>> PrintContext const&, std::ostream*, PrintStyle, std::vector<bool,
> >>>>>>>>>>> std::allocator<bool> >&, std::vector<PrintBuffer,
> >>>>>>>>>>> std::allocator<PrintBuffer> >&, PrintBuffer*) () from
> >>>>>>>>>>> /usr/local/lib/libapl.so
> >>>>>>>>>>> #2 0xb7e14078 in PrintBuffer::PrintBuffer(Value const&,
> >>>>>>>>>>> PrintContext const&, std::ostream*) () from
> >>>>>>>>>>> /usr/local/lib/libapl.so
> >>>>>>>>>>> #3 0xb7ed0563 in Value::print(std::ostream&) const () from
> >>>>>>>>>>> /usr/local/lib/libapl.so
> >>>>>>>>>>> #4 0xb7e9715d in Quad_Quad::assign(Value_P, bool, char const*)
> >>>>>>>>>>> () from /usr/local/lib/libapl.so
> >>>>>>>>>>> #5 0xb7de71a9 in Prefix::reduce_V_ASS_B_() () from
> >>>>>>>>>>> /usr/local/lib/libapl.so
> >>>>>>>>>>> #6 0xb7ded3b0 in Prefix::reduce_statements() () from
> >>>>>>>>>>> /usr/local/lib/libapl.so
> >>>>>>>>>>> #7 0xb7e7a08a in StateIndicator::run() () from
> >>>>>>>>>>> /usr/local/lib/libapl.so
> >>>>>>>>>>> #8 0xb7db3def in Executable::execute_body() const () from
> >>>>>>>>>>> /usr/local/lib/libapl.so
> >>>>>>>>>>> #9 0xb7daa9e3 in Command::finish_context() () from
> >>>>>>>>>>> /usr/local/lib/libapl.so
> >>>>>>>>>>> #10 0xb7dab1c9 in Command::do_APL_expression(UCS_string&) () from
> >>>>>>>>>>> /usr/local/lib/libapl.so
> >>>>>>>>>>> #11 0xb7daa4e9 in Command::process_line(UCS_string&) () from
> >>>>>>>>>>> /usr/local/lib/libapl.so
> >>>>>>>>>>> #12 0xb7ee8759 in apl_exec () from /usr/local/lib/libapl.so
> >>>>>>>>>>> #13 0x080488b1 in main ()
> >>>>>>>>>>> (gdb)
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Sun, 4 Aug 2019 18:16:25 +0200
> >>>>>>>>>>> Dr. Jürgen Sauermann <address@hidden> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>>
> >>>>>>>>>>>> sorry, forhgot one gdb command (after the fault):
> >>>>>>>>>>>>
> >>>>>>>>>>>> bt
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regarduibng html, you can always view the messages under:
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://lists.gnu.org/archive/html/bug-apl/
> >>>>>>>>>>>>
> >>>>>>>>>>>> Without HTML they look worse.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 8/4/19 5:15 PM, address@hidden wrote:
> >>>>>>>>>>>> Hi
> >>>>>>>>>>>>
> >>>>>>>>>>>> you know you are sending email message as html? it gets blocked
> >>>>>>>>>>>> and i don't get it as soon as it comes in
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>> the gtk configure problem is still there --without-gtk3 has no
> >>>>>>>>>>>> effect - i still have to comment out or delete the line in the
> >>>>>>>>>>>> configure
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>> gcc caplc.c -lapl -lstdc++ -o caplc -O2
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>>
> >>>>>>>>>>>> // caplc.c from /fpc/current/apl/html/msg00009.html from
> >>>>>>>>>>>> libapl_test.c
> >>>>>>>>>>>>
> >>>>>>>>>>>> #include <stdio.h>
> >>>>>>>>>>>> #include <stdint.h>
> >>>>>>>>>>>> //#include <dlfcn.h>
> >>>>>>>>>>>> #include <apl/libapl.h> // "/usr/local/include/apl/libapl.h"
> >>>>>>>>>>>>
> >>>>>>>>>>>> //int main(int argc, const char *argv[])
> >>>>>>>>>>>> int main(int argc, char *argv[])
> >>>>>>>>>>>> {
> >>>>>>>>>>>> // insert code here...
> >>>>>>>>>>>> printf("Hello, World!\n");
> >>>>>>>>>>>>
> >>>>>>>>>>>> init_libapl(argv[0], 0);
> >>>>>>>>>>>> //init_libapl("main"i, 0);
> >>>>>>>>>>>>
> >>>>>>>>>>>> return apl_exec("⎕←2 3⍴⍳6"); <-- Floating point exception.
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>>
> >>>>>>>>>>>> /fpc/current/apl > ldd caplc
> >>>>>>>>>>>> linux-gate.so.1 => (0xb7744000)
> >>>>>>>>>>>> libapl.so => /usr/local/lib/libapl.so (0xb744c000)
> >>>>>>>>>>>> libstdc++.so.6 => /usr/local/gcc/lib/libstdc++.so.6
> >>>>>>>>>>>> (0xb7364000)
> >>>>>>>>>>>> libc.so.6 => /lib/libc.so.6 (0xb71ff000)
> >>>>>>>>>>>> libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0
> >>>>>>>>>>>> (0xb7149000)
> >>>>>>>>>>>> libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0xb7122000)
> >>>>>>>>>>>> libdl.so.2 => /lib/libdl.so.2 (0xb711c000)
> >>>>>>>>>>>> libpthread.so.0 => /lib/libpthread.so.0 (0xb7101000)
> >>>>>>>>>>>> libncurses.so.6 => /lib/libncurses.so.6 (0xb70b2000)
> >>>>>>>>>>>> libnsl.so.1 => /lib/libnsl.so.1 (0xb7098000)
> >>>>>>>>>>>> libm.so.6 => /lib/libm.so.6 (0xb706e000)
> >>>>>>>>>>>> libgcc_s.so.1 => /usr/local/gcc/lib/libgcc_s.so.1
> >>>>>>>>>>>> (0xb7053000)
> >>>>>>>>>>>> /lib/ld-linux.so.2 (0xb7745000)
> >>>>>>>>>>>> libXau.so.6 => /usr/local/lib/libXau.so.6 (0xb704f000)
> >>>>>>>>>>>> libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6
> >>>>>>>>>>>> (0xb704a000)
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> /fpc/current/apl > gdb caplc
> >>>>>>>>>>>> GNU gdb (GDB) 8.3
> >>>>>>>>>>>> Copyright (C) 2019 Free Software Foundation, Inc.
> >>>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later
> >>>>>>>>>>>> <http://gnu.org/licenses/gpl.html>
> >>>>>>>>>>>> This is free software: you are free to change and redistribute
> >>>>>>>>>>>> it.
> >>>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law.
> >>>>>>>>>>>> Type "show copying" and "show warranty" for details.
> >>>>>>>>>>>> This GDB was configured as "i686-pc-linux-gnu".
> >>>>>>>>>>>> Type "show configuration" for configuration details.
> >>>>>>>>>>>> For bug reporting instructions, please see:
> >>>>>>>>>>>> <http://www.gnu.org/software/gdb/bugs/>.
> >>>>>>>>>>>> Find the GDB manual and other documentation resources online at:
> >>>>>>>>>>>> <http://www.gnu.org/software/gdb/documentation/>.
> >>>>>>>>>>>>
> >>>>>>>>>>>> For help, type "help".
> >>>>>>>>>>>> Type "apropos word" to search for commands related to "word"...
> >>>>>>>>>>>> Reading symbols from caplc...
> >>>>>>>>>>>> (gdb) run
> >>>>>>>>>>>> Starting program: /fpc/current/apl/caplc
> >>>>>>>>>>>> warning: File
> >>>>>>>>>>>> "/usr/local/gcc-4.8.5/lib/libstdc++.so.6.0.19-gdb.py"
> >>>>>>>>>>>> auto-loading has been declined by your `auto-load safe-path' set
> >>>>>>>>>>>> to "$debugdir:$datadir/auto-load".
> >>>>>>>>>>>> To enable execution of this file add
> >>>>>>>>>>>> add-auto-load-safe-path
> >>>>>>>>>>>> /usr/local/gcc-4.8.5/lib/libstdc++.so.6.0.19-gdb.py
> >>>>>>>>>>>> line to your configuration file "/root/.gdbinit".
> >>>>>>>>>>>> To completely disable this security protection add
> >>>>>>>>>>>> set auto-load safe-path /
> >>>>>>>>>>>> line to your configuration file "/root/.gdbinit".
> >>>>>>>>>>>> For more information about this security protection see the
> >>>>>>>>>>>> "Auto-loading safe path" section in the GDB manual. E.g., run
> >>>>>>>>>>>> from the shell:
> >>>>>>>>>>>> info "(gdb)Auto-loading safe path"
> >>>>>>>>>>>> [Thread debugging using libthread_db enabled]
> >>>>>>>>>>>> Using host libthread_db library "/lib/libthread_db.so.1".
> >>>>>>>>>>>> Hello, World!
> >>>>>>>>>>>>
> >>>>>>>>>>>> Program received signal SIGFPE, Arithmetic exception.
> >>>>>>>>>>>> 0xb7eb6953 in UCS_string::UCS_string(PrintBuffer const&, int,
> >>>>>>>>>>>> int) () from /usr/local/lib/libapl.so
> >>>>>>>>>>>> (gdb)
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Sun, 4 Aug 2019 11:30:11 +0200
> >>>>>>>>>>>> Dr. Jürgen Sauermann <address@hidden> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>>
> >>>>>>>>>>>> regarding GTK, I found a cut-and-paste error in configure.ac.
> >>>>>>>>>>>> Fixed in SVN 1182.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regarding test_libapl, if that does not work then nothing else
> >>>>>>>>>>>> will.
> >>>>>>>>>>>> Can you send me the output of:
> >>>>>>>>>>>>
> >>>>>>>>>>>> ldd test_libapl
> >>>>>>>>>>>>
> >>>>>>>>>>>> in directory src? Or try:
> >>>>>>>>>>>>
> >>>>>>>>>>>> gdb test_libapl
> >>>>>>>>>>>> run
> >>>>>>>>>>>>
> >>>>>>>>>>>> and dsend me the output?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Best Regards,
> >>>>>>>>>>>> Jürgen
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 8/4/19 5:48 AM, address@hidden wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi Jürgen
> >>>>>>>>>>>>
> >>>>>>>>>>>> Once i got beyond the gtk3 problem using either --with-python or
> >>>>>>>>>>>> --without-python gave make errors so they were good to stay away
> >>>>>>>>>>>> from -> just like you said
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>> to get past my GTK problem i just deleted the line in the
> >>>>>>>>>>>> configure
> >>>>>>>>>>>>
> >>>>>>>>>>>> around line 681 there is
> >>>>>>>>>>>> HAVE_GTK3_FALSE
> >>>>>>>>>>>> HAVE_GTK3_TRUE <- i deleted this line
> >>>>>>>>>>>>
> >>>>>>>>>>>> -
> >>>>>>>>>>>>
> >>>>>>>>>>>> so for good libapl.so
> >>>>>>>>>>>> configure --with-libapl
> >>>>>>>>>>>>
> >>>>>>>>>>>> so for good apl just
> >>>>>>>>>>>> configure
> >>>>>>>>>>>>
> >>>>>>>>>>>> both need the gtk configure edit though on my machine
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>> do you have any c test programs for libapl.so? the old
> >>>>>>>>>>>> libapl_test.c i found gives a floating point exception error
> >>>>>>>>>>>>
> >>>>>>>>>>>> i can call c code from fpc extern/cdecl so if i have a working c
> >>>>>>>>>>>> use of libapl.so ..... it would be a good start
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Sat, 3 Aug 2019 20:17:32 +0200
> >>>>>>>>>>>> Dr. Jürgen Sauermann <address@hidden> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>>
> >>>>>>>>>>>> the ./configure defaults for GNU APL are chosen so that it
> >>>>>>>>>>>> builds with a minimum
> >>>>>>>>>>>> number of dependencies (= libraries).
> >>>>>>>>>>>>
> >>>>>>>>>>>> For some of the libraries I can use m4 macros (= configure
> >>>>>>>>>>>> tests) that are shipped with the
> >>>>>>>>>>>> library, and for other libraries I wrote my own ones (less than
> >>>>>>>>>>>> perfect).
> >>>>>>>>>>>>
> >>>>>>>>>>>> Apparently --without options are not reliable and should, for
> >>>>>>>>>>>> the reason above, never be
> >>>>>>>>>>>> needed.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The build error is for target for GTK_server and not for GNU
> >>>>>>>>>>>> APL. As a work-around
> >>>>>>>>>>>> for glady you could try: touch src/GTK_server and then build GNU
> >>>>>>>>>>>> APL. It could
> >>>>>>>>>>>> very well be that the apl binary was already built in directory
> >>>>>>>>>>>> src before the fault.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Not all configure options are for libapl; option --with-android
> >>>>>>>>>>>> builds an apl binary for android,
> >>>>>>>>>>>> but without using libapl.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Its kind of difficult to test the --without build cases, because
> >>>>>>>>>>>> that would require to un-install all
> >>>>>>>>>>>> the libraries before building (and re-installing after that).
> >>>>>>>>>>>> What I would suggest is to install all
> >>>>>>>>>>>> the libraries even if you ./configure without using them. That
> >>>>>>>>>>>> is the configuration that I use.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 8/3/19 5:05 PM, address@hidden wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi
> >>>>>>>>>>>>
> >>>>>>>>>>>> i got the latest 1181 svn
> >>>>>>>>>>>>
> >>>>>>>>>>>> You dont need the --without options because that's the default.
> >>>>>>>>>>>>
> >>>>>>>>>>>> the default for erlang and android are --without
> >>>>>>>>>>>> but the --without-erlang has problems that we are aware of
> >>>>>>>>>>>> i didn't try the --without-android (are you thinking of a
> >>>>>>>>>>>> libapl for land line phones?)
> >>>>>>>>>>>>
> >>>>>>>>>>>> the default for postgresql appears to also be --without (but not
> >>>>>>>>>>>> sure because i have a very non standard pgsql installation and
> >>>>>>>>>>>> the configure might just think it isn't installed)
> >>>>>>>>>>>>
> >>>>>>>>>>>> the --without-sqlite3 works
> >>>>>>>>>>>>
> >>>>>>>>>>>> the only one that doesn't seem to work is the --without-gtk3 and
> >>>>>>>>>>>> it isn't the default <-----
> >>>>>>>>>>>>
> >>>>>>>>>>>> configure CORE_COUNT_WANTED=2 --with-libapl --with-python
> >>>>>>>>>>>>
> >>>>>>>>>>>> gives the exact same make error for gtk3 as
> >>>>>>>>>>>>
> >>>>>>>>>>>> configure CORE_COUNT_WANTED=2 --with-libapl --with-python
> >>>>>>>>>>>> --without-gtk3
> >>>>>>>>>>>>
> >>>>>>>>>>>> -
> >>>>>>>>>>>>
> >>>>>>>>>>>> the gtk3 make error
> >>>>>>>>>>>>
> >>>>>>>>>>>> Gtk_server.cc: In function 'void cmd_1_load_GUI(const char*)':
> >>>>>>>>>>>> Gtk_server.cc:238:48: error: 'gtk_builder_new_from_file' was not
> >>>>>>>>>>>> declared in this scope
> >>>>>>>>>>>> builder = gtk_builder_new_from_file(filename);
> >>>>>>>>>>>>
> >>>>>>>>>>>> gtk_builder_new_from_file was added since gtk3-3.10
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>> i need not mention that glady's in accounting said she'd go and
> >>>>>>>>>>>> have coffee with me it i had an apl demo by lunch on thursday
> >>>>>>>>>>>> ,....
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please help :)
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Sat, 3 Aug 2019 11:55:03 +0200
> >>>>>>>>>>>> Dr. Jürgen Sauermann <address@hidden> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>> configure CORE_COUNT_WANTED=2 --with-libapl --without-sqlite3
> >>>>>>>>>>>> --without-postgresql --without-gtk3 --without-android
> >>>>>>>>>>>> --without-erlang --without-python
> >>>>>>>>>>>> works for me. It will create a compiler error which I have fixed
> >>>>>>>>>>>> in SVN 1181.
> >>>>>>>>>>>> I also updated README-10-python with the proper ./configure
> >>>>>>>>>>>> option.
> >>>>>>>>>>>>
> >>>>>>>>>>>> You dont need the --without options because that's the default.
> >>>>>>>>>>>> Something looks
> >>>>>>>>>>>> fishy with the --with-erlang=no option because despite of it
> >>>>>>>>>>>> ./configure says "yes"
> >>>>>>>>>>>> instead. This could be a problem with the top-level
> >>>>>>>>>>>> configure.ac. Please try to
> >>>>>>>>>>>> ./configure without mentioning erlang (or any other module that
> >>>>>>>>>>>> is not used by
> >>>>>>>>>>>> default).
> >>>>>>>>>>>>
> >>>>>>>>>>>> the make distclean errors are harmless; they occur because make
> >>>>>>>>>>>> distclean tries
> >>>>>>>>>>>> to remove files which were supposedly created during the build
> >>>>>>>>>>>> (but are missing
> >>>>>>>>>>>> if the build fails for some reason).
> >>>>>>>>>>>>
> >>>>>>>>>>>> If I remember correctly then libapl_test can fail if not
> >>>>>>>>>>>> properly linked.
> >>>>>>>>>>>> Check it with ldd.
> >>>>>>>>>>>>
> >>>>>>>>>>>> If there are more problems, then please keep me posted.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Best Regards,
> >>>>>>>>>>>> Jürgen Sauermann
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 8/1/19 3:55 PM, address@hidden wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> 8/1/9
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi
> >>>>>>>>>>>>
> >>>>>>>>>>>> after getting the latest svn revision 1180 on 8/1/19
> >>>>>>>>>>>>
> >>>>>>>>>>>> i get the exact same configure problems as with the gnuapl-1.8
> >>>>>>>>>>>> tar ball as listed below - i can't believe i'm the only one?
> >>>>>>>>>>>>
> >>>>>>>>>>>> configure CORE_COUNT_WANTED=2 --with-libapl --without-sqlite3
> >>>>>>>>>>>> --without-postgresql --without-gtk3 --without-android
> >>>>>>>>>>>> --without-erlang --without-python
> >>>>>>>>>>>>
> >>>>>>>>>>>> also make distclean gives a tremendous number of errors that
> >>>>>>>>>>>> probably shouldn't be there (never seen before in other
> >>>>>>>>>>>> projects) so i have to use fresh source for each configure
> >>>>>>>>>>>>
> >>>>>>>>>>>> also from the README-10-python configure --with-libpython_apl
> >>>>>>>>>>>> gives : configure: WARNING: unrecognized options:
> >>>>>>>>>>>> --with-libpython_apl
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>> 7/30/19
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I (as the one user you reference) have no real need for it as i
> >>>>>>>>>>>> said - i use the fpc tprocess coding for it - i use apl --script
> >>>>>>>>>>>> as a matrix engine (inner and outer product with unquote dynamic
> >>>>>>>>>>>> code design)
> >>>>>>>>>>>>
> >>>>>>>>>>>> just exploring using libapl.so you didn't respond to if there
> >>>>>>>>>>>> is any libapl.so use code for c (surely the most popular
> >>>>>>>>>>>> computer language) all i found was the
> >>>>>>>>>>>> libapl_test.c but i get a Floating point exception when run so
> >>>>>>>>>>>> i am now updating my apl to get a current libapl.so and now have
> >>>>>>>>>>>> configure/make problems with apl-1.8
> >>>>>>>>>>>>
> >>>>>>>>>>>> the configure options don't work as wanted
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>> the apl-1.8 configure has
> >>>>>>>>>>>>
> >>>>>>>>>>>> --without-PACKAGE do not use PACKAGE (same as
> >>>>>>>>>>>> --with-PACKAGE=no)
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>>
> >>>>>>>>>>>> configure CORE_COUNT_WANTED=2 --with-libapl --without-sqlite3
> >>>>>>>>>>>> --without-postgresql --without-gtk3 --without-android
> >>>>>>>>>>>> --without-erlang --with-python
> >>>>>>>>>>>>
> >>>>>>>>>>>> from configure output
> >>>>>>>>>>>> checking if we are compiling for Android... yes
> >>>>>>>>>>>> checking if we want to build an erlang interface (implies
> >>>>>>>>>>>> libapl.so)... yes
> >>>>>>>>>>>>
> >>>>>>>>>>>> make
> >>>>>>>>>>>> make[2]: Entering directory
> >>>>>>>>>>>> `/transfer/usr.src/apl/1.8/apl-1.8/erlang'
> >>>>>>>>>>>> erlc apl.erl
> >>>>>>>>>>>> make[2]: erlc: Command not found
> >>>>>>>>>>>> make[2]: *** [apl.beam] Error 127
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>>
> >>>>>>>>>>>> configure CORE_COUNT_WANTED=2 --with-libapl --with-sqlite3=no
> >>>>>>>>>>>> --with-postgresql=no --with-gtk3=no --with-android=no
> >>>>>>>>>>>> --with-erlang=no --with-python
> >>>>>>>>>>>>
> >>>>>>>>>>>> from configure output
> >>>>>>>>>>>> checking if we are compiling for Android... yes
> >>>>>>>>>>>> checking if we want to build an erlang interface (implies
> >>>>>>>>>>>> libapl.so)... yes
> >>>>>>>>>>>>
> >>>>>>>>>>>> make
> >>>>>>>>>>>>
> >>>>>>>>>>>> make[2]: Entering directory
> >>>>>>>>>>>> `/transfer/usr.src/apl/1.8/apl-1.8/erlang'
> >>>>>>>>>>>> erlc apl.erl
> >>>>>>>>>>>> make[2]: erlc: Command not found
> >>>>>>>>>>>> make[2]: *** [apl.beam] Error 127
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>> configure CORE_COUNT_WANTED=2 --with-libapl --with-sqlite3=no
> >>>>>>>>>>>> --with-postgresql=no --with-gtk3=no --with-android=no
> >>>>>>>>>>>> --with-python
> >>>>>>>>>>>>
> >>>>>>>>>>>> make
> >>>>>>>>>>>>
> >>>>>>>>>>>> Gtk_server.cc: In function 'void cmd_1_load_GUI(const char*)':
> >>>>>>>>>>>> Gtk_server.cc:238:48: error: 'gtk_builder_new_from_file' was not
> >>>>>>>>>>>> declared in this scope
> >>>>>>>>>>>> builder = gtk_builder_new_from_file(filename);
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Tue, 30 Jul 2019 13:14:21 +0200
> >>>>>>>>>>>> Dr. Jürgen Sauermann <address@hidden> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I am not criticising freepascal in any way. My point is simply
> >>>>>>>>>>>> that the number of users for
> >>>>>>>>>>>> which a combination of Pascal and APL makes sense is rather
> >>>>>>>>>>>> small (maybe one ?) and
> >>>>>>>>>>>> that such an interface should therefore rather be constructed by
> >>>>>>>>>>>> those users rather than
> >>>>>>>>>>>> by myself.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Juergen
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 7/29/19 10:33 PM, address@hidden wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> freepascal is as modern a language as it gets my friend - why
> >>>>>>>>>>>> you have a problem with it is beyond me - but to be honest not
> >>>>>>>>>>>> very professional of you now, is it, considering i run into more
> >>>>>>>>>>>> anti-apl then anti-freepascal programmers and i just wallop them
> >>>>>>>>>>>> all senseless
> >>>>>>>>>>>>
> >>>>>>>>>>>> anyway - i have been running apl as a script in freepascal for
> >>>>>>>>>>>> years and it is the greatest combination of coding there is - no
> >>>>>>>>>>>> real need to use libapl.so/libapl.h anyway - right now it would
> >>>>>>>>>>>> be run as c code anyway as a cdecl extern. (but if you do have
> >>>>>>>>>>>> any c code that runs libapl.so/libapl.h with unquote or inner
> >>>>>>>>>>>> product or outer product - i would love it - can't find any on
> >>>>>>>>>>>> the internet - or any real usefull code to be honest)
> >>>>>>>>>>>>
> >>>>>>>>>>>> with the unquote function and ease of inner and outer product
> >>>>>>>>>>>> etc matrix functions - coupled with fpc being compiled and
> >>>>>>>>>>>> having complete control over processes
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://www.freepascal.org/docs-html/current/fcl/process/tprocess.htm
> >>>>>>>>>>>>
> >>>>>>>>>>>> and threading and [trtl]tcriticalseciton and fpflock mutexes
> >>>>>>>>>>>> (there are a number of ways to perform parallal and threading
> >>>>>>>>>>>> programming and mutex on files and code sections)
> >>>>>>>>>>>> https://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial
> >>>>>>>>>>>> https://www.freepascal.org/docs-html/rtl/system/trtlcriticalsection.html
> >>>>>>>>>>>> https://www.freepascal.org/docs-html/current/fcl/syncobjs/tcriticalsection.html
> >>>>>>>>>>>>
> >>>>>>>>>>>> and libcurl units, openssl units - and hundreds if not thousands
> >>>>>>>>>>>> more (okay maybe not thousands) ,,,,,,
> >>>>>>>>>>>>
> >>>>>>>>>>>> sorry - i gotta take a rest now ... can't get to excited ,,,
> >>>>>>>>>>>> doctors orders ,,,
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, 17 Jul 2019 12:30:05 +0200
> >>>>>>>>>>>> Dr. Jürgen Sauermann <address@hidden> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Most of us are reaching the ends of our life cycles, so we
> >>>>>>>>>>>> should not lol too loudly. Iverson was born 9 years before Wirth,
> >>>>>>>>>>>> so he has all rights to leave first. By the same token, at the
> >>>>>>>>>>>> time when
> >>>>>>>>>>>> Pascal was invented, Iverson had 9 years more working experience.
> >>>>>>>>>>>>
> >>>>>>>>>>>> If I remember correctly (Pascal was a hot topic at that time)
> >>>>>>>>>>>> then Wirth
> >>>>>>>>>>>> never meant Pascal to be a programming language but rather a
> >>>>>>>>>>>> somewhat
> >>>>>>>>>>>> simplified syntax to teach compiler construction. I was only
> >>>>>>>>>>>> later when some
> >>>>>>>>>>>> people misunderstood it as a being programming language. Given
> >>>>>>>>>>>> the languages
> >>>>>>>>>>>> affordable at that time (BASIC and machine code without an
> >>>>>>>>>>>> assembler),
> >>>>>>>>>>>> the mistake is excusable, but we should learn from our mistakes
> >>>>>>>>>>>> and not
> >>>>>>>>>>>> perpetuate them.
> >>>>>>>>>>>>
> >>>>>>>>>>>> BR,
> >>>>>>>>>>>> Jürgen
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 7/15/19 8:07 PM, address@hidden wrote:
> >>>>>>>>>>>> really since apl is older then pascal (excluding algol( i think
> >>>>>>>>>>>> you got it backwards with number of deceased
> >>>>>>>>>>>>
> >>>>>>>>>>>> nicklaus wirth is still around what about iverson? lol
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Thu, 27 Jun 2019 18:37:41 +0200
> >>>>>>>>>>>> Dr. Jürgen Sauermann <address@hidden> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> sure. But I would bet that today the number of python users is
> >>>>>>>>>>>> at least
> >>>>>>>>>>>> two magnitudes greater
> >>>>>>>>>>>> than the number of Pascal users (not counting those who have
> >>>>>>>>>>>> ceased to
> >>>>>>>>>>>> exist since Pascal
> >>>>>>>>>>>> was invented).
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 6/27/19 5:37 PM, address@hidden wrote:
> >>>>>>>>>>>> a grand geocentric (aplcentric) point of view indeed - i'm
> >>>>>>>>>>>> pretty sure the number of pascal users is orders of magnitude
> >>>>>>>>>>>> greater then the number of apl programmers
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Tue, 18 Jun 2019 22:10:20 +0200
> >>>>>>>>>>>> Dr. Jürgen Sauermann <address@hidden> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I believe that extending some language X with an interface to
> >>>>>>>>>>>> APL makes only
> >>>>>>>>>>>> sense if:
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1. language X is popular or at least is gaining popularity, and
> >>>>>>>>>>>> 2. (GNU-) APL can provide an advantage in an area where language
> >>>>>>>>>>>> X is weak.
> >>>>>>>>>>>>
> >>>>>>>>>>>> According to
> >>>>>>>>>>>> http://statisticstimes.com/tech/top-computer-languages.php
> >>>>>>>>>>>> and others, C/C++ and python are the most frequently used
> >>>>>>>>>>>> languages
> >>>>>>>>>>>> today, with Erlang and Pascal having a far lower popularity
> >>>>>>>>>>>> (although
> >>>>>>>>>>>> probably increasing for Erlang but decreasing for Pascal).
> >>>>>>>>>>>>
> >>>>>>>>>>>> Erlang and Python are both weak for large vectors and even
> >>>>>>>>>>>> weaker for
> >>>>>>>>>>>> arrays with higher ranks. Reason is the linked list structure
> >>>>>>>>>>>> that they use
> >>>>>>>>>>>> for vectors.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Now to Pascal: it is not popular and is not weak in a particular
> >>>>>>>>>>>> area (being
> >>>>>>>>>>>> weak in total does not count here). A further difficulty is the
> >>>>>>>>>>>> need to declare
> >>>>>>>>>>>> the data types of variables beforehand, which does not fit well
> >>>>>>>>>>>> to the dynamic
> >>>>>>>>>>>> typing of APL. Python and Erlang are both dynamically type and
> >>>>>>>>>>>> therefore
> >>>>>>>>>>>> this problem does not exist for them.
> >>>>>>>>>>>>
> >>>>>>>>>>>> For that reason you are on your own when it comes to extending
> >>>>>>>>>>>> Pascal with
> >>>>>>>>>>>> GNU APL. I will be glad to help you with technical advice how to
> >>>>>>>>>>>> do that and
> >>>>>>>>>>>> how GNU APL works internally, but I would prefer not be involved
> >>>>>>>>>>>> in building
> >>>>>>>>>>>> such an interface.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Best regards,
> >>>>>>>>>>>> Jürgen
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 6/17/19 5:05 PM, address@hidden wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi Jürgen,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regarding fpc it depends on how they have built their C/C++
> >>>>>>>>>>>> interface (if they did).
> >>>>>>>>>>>> The last time I used Pascal was the time when the only other
> >>>>>>>>>>>> programming
> >>>>>>>>>>>> language on my platform was BASIC. So I am not really up-to-date
> >>>>>>>>>>>> with Pascal.
> >>>>>>>>>>>> If you want to try it, then I can help with technical
> >>>>>>>>>>>> information that you may need.
> >>>>>>>>>>>>
> >>>>>>>>>>>> this is the fpc/c/c++ interface guide that i have used for
> >>>>>>>>>>>> accessing c libs from fpc
> >>>>>>>>>>>> using c++ in fpc is a lot more complicated - i have 'working
> >>>>>>>>>>>> examples' from the following guide (hello++.pas) but that is it
> >>>>>>>>>>>> for c++.
> >>>>>>>>>>>> ftp://ftp.freepascal.org/pub/fpc/docs-pdf/CinFreePascal.pdf
> >>>>>>>>>>>>
> >>>>>>>>>>>> This is an example of the c interface (how i can use 'c/libc'
> >>>>>>>>>>>> from fpc)
> >>>>>>>>>>>>
> >>>>>>>>>>>> this can be your first fpc program!!
> >>>>>>>>>>>>
> >>>>>>>>>>>> // sysconf.pas
> >>>>>>>>>>>> program sysconf; // see man 3 syscon
> >>>>>>>>>>>> uses ctypes;
> >>>>>>>>>>>> const _SC_NPROCESSORS_ONLN = 84; // _SC_NPROCESSORS_ONLN The
> >>>>>>>>>>>> number of processors currently online (available).
> >>>>>>>>>>>> function sysconf(i: cint): clong; cdecl; external 'c'; // libc
> >>>>>>>>>>>> unistd.h
> >>>>>>>>>>>> begin
> >>>>>>>>>>>> writeln(sysconf(_SC_NPROCESSORS_ONLN), ' cpus :
> >>>>>>>>>>>> _SC_NPROCESSORS_ONLN');
> >>>>>>>>>>>> writeln;
> >>>>>>>>>>>> end.
> >>>>>>>>>>>>
> >>>>>>>>>>>> to compile
> >>>>>>>>>>>> fpc -XX sysconf.pas # -XX use smart linking to get smallest
> >>>>>>>>>>>> executable use -gl for generating debug info for gdb and use
> >>>>>>>>>>>> lineinfo unit
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>> The shell approach is fine as long as your programs process a
> >>>>>>>>>>>> small to medium
> >>>>>>>>>>>> amount of data. When the volume of data becomes huge then you
> >>>>>>>>>>>> have a lot of
> >>>>>>>>>>>> overhead (formatting on the shell side and tokenization and
> >>>>>>>>>>>> optimization on the
> >>>>>>>>>>>> APL side) which can only be avoided by calling directly into the
> >>>>>>>>>>>> APL interpreter.
> >>>>>>>>>>>>
> >>>>>>>>>>>> so far i've had no problem using cli apl from fpc (there are
> >>>>>>>>>>>> actually 2 ways depending on if i want to 'trap' and use any apl
> >>>>>>>>>>>> standard output (aprocess.execute) or not
> >>>>>>>>>>>> (sysutils.executeprocess)
> >>>>>>>>>>>>
> >>>>>>>>>>>> program fpcapl;
> >>>>>>>>>>>> uses sysutils;
> >>>>>>>>>>>> var l : ansistring;
> >>>>>>>>>>>> begin
> >>>>>>>>>>>> l := '-c "/usr/local/bin/apl --cfg"';
> >>>>>>>>>>>> //l := '-c "/apl/workspaces/script.apl"'; // script.apl file
> >>>>>>>>>>>> has #! /usr/local/bin/apl --script -- then apl code
> >>>>>>>>>>>> sysutils.executeprocess('/bin/bash', l); // apl standard output
> >>>>>>>>>>>> just displayed
> >>>>>>>>>>>> end.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
>
- Re: [Bug-apl] fpc/freepascal interface - c code using inner/outer product or unquote welcome,
enztec <=