Re: [Bug-apl] fpc/freepascal interface - c code using inner/outer product or unquote welcome

[Dr . Jürgen Sauermann]

Hi, see my answers below. Jürgen On 8/9/19 12:06 AM, enz...@gmx.com wrote: Hi --- simple quesion on ⎕ARG it doesn't have a value using libapl? (no command line arguments right?) It depends. Normally a library does not have command line arguments and therefore ⎕ARG is empty. However, you can pass command line arguments to UserPreferences::uprefs.expanded_argv which will make them visible in ⎕ARGV. E.g.: UserPreferences::uprefs.expanded_argv.push_back("--my_argv"); --- 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? No. It only means that libcurl or libmysql do not malloc() in their _init() function, and therefore do not call free() in their _fini() function. The logic in the _init() function (which is created by the compiler or the linker) is usually something like this: void init() { do_init(0); } void fini() { do_init(1); } do_init(int ex) { ...   if (ex)   free(xxx);    else     xxx=malloc(...) ... } This makes sure that every malloc() in init() has a corresponding free() in fini(). If you call _init() twice with argument 0, then you create exactly the situation described in the stackoverflow post below. It is not a fault in the GNU APL C++ code but somewhere in the way the library is being initialized (which is a rather platform specific matter). 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 Yes. APserver is a helper binary for old-style shared APL variables (⎕SVO and friends). The APserver is forked by APL, but APL cannot know where the APServer binary is located in the file system. APL then assumes that the APserver is located either in the same directory as itself, or in a subdir called APs of that directory. You can probably fix this in a number of ways: 1. set UserPreferences::uprefs.user_do_svars and system_do_svars to false 2. Provide a dummy executable (bash script that sleeps forever) in one of the directories mentioned in the printout 3. Install "normal (non-libapl) APL which should also install APserver in the right place. what setting would affect use of ]BOXING it only works with init --- The proper way would be something like: apl_command("]BOXING OFF"); (or the desired boxing value) after calling apl_init(). If your boxing is not off when libapl starts, then this is one more consequence of an incomplete initialization (expect more problems of that kind in the future). 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.