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