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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> >
