Hi enztec,
it looks to me as if the initialization of your libapl is incomplete.
I have created a small program to test libapl (the libapl version I used
is a little older
since I don't build libapl too frequently, but that should not make a
difference):
======================================================
*#include <apl/libapl.h>
// compile with: gcc libapl_test.c -L /usr/local/lib/apl -lapl -lstdc++
-o libapl_test
int
main(int argc, char * argv[])
{
init_libapl(argv[0], 0);
apl_exec("⍳3"); // prints 1 2 3
apl_exec("'⎕PW:' ⎕PW"); // print ⎕PW
}
*
======================================================
which produces:
*1 2 3**
** ⎕PW: 80 **
*
on stdout.
The first argument of *init_libapl()* is, according to *man execve*
convertions, the name of the
binary that is being executed. In your case probably freepascal. GNU APL
uses the path to the
binary as a starting point for finding: other colocated binaries (e.g.
APserver)m its library
root, and for its debug output.
The second argument of *init_libapl* controls the debug verbosity at
startup (just like command line
argument *-l 37* of the apl interpreter. Normally set to 0; nonzero
produces some additional output like this:
*---------------------------------------
**eedjsa@server68:~/apl-1.8/src$ ./libapl_test
initial RLIMIT_AS (aka. virtual memory) is: 'unlimited'
estimated available memory: 15332720640 bytes (15332 MB)
sizeof(int) is 4
sizeof(long) is 8
sizeof(void *) is 8
sizeof(Cell) is 24
sizeof(SI stack item) is 4072
sizeof(Svar_partner) is 28
sizeof(Svar_record) is 328
sizeof(Symbol) is 88
sizeof(Token) is 24
sizeof(Value) is 456 (including 12 Cells)
sizeof(ValueStackItem) is 24
sizeof(UCS_string) is 32
sizeof(UserFunction) is 416
⎕WA total memory is 15332720640 bytes (15332 MB, 0x391e6c000)
increasing rlimit RLIMIT_NPROC from 63378 to infinity
initializing paths from argv[0] = ./libapl_test
initializing paths from $PWD = /home/eedjsa/apl-1.8/src
APL_bin_path is: .
APL_bin_name is: libapl_test
Reading config file /usr/local/etc/gnu-apl.d/preferences ...
Not reading config file /home/eedjsa/.config/gnu-apl/preferences (No
such file or directory)
using ANSI terminal output ESC sequences (or those configured in your
preferences file(s))
using ANSI terminal input ESC sequences(or those configured in your
preferences file(s))
Using TCP socket towards APserver...
connecting to 127.0.0.1 TCP port 16366 failed.
(the first ::connect() to APserver is expected to fail, unless
APserver was started manually)
Starting a new APserver listening on 127.0.0.1 TCP port 16366
Executable ./APserver not found (this is OK when apl was started
from the src directory): No such file or directory
Found ./APs/APserver
Starting ./APs/APserver --port 16366 --auto...
connected to APserver, socket is 3
using Svar_DB on APserver!
**---------------------------------------*
You should actually use *apl_command()* and not *apl_exec()* with APL
commands.
*apl_exec()* tokenizes its input while *apl_command()* does not (APL
commands do
not follow the syntax of the APL language).
My best guess is that freepascal does not use the standard start-up
(aka. crt0.o)
sequence of the binary, causing ⎕PW to be initialzed with 0 instead of
80. 0 is
an invalid value for ⎕PW causing segfaults here and there. Assignment to ⎕PW
in APL ignores too small values:
* ⎕PW←0 ◊ ⎕PW**
**80*
but if it is being tricked then bad things may happen.
I would also propose to link *libapl* statically because in my
experience the initialization
of dynamic libraries is more tricky and less portable than static ones.
Best Regards,
Jürgen
On 7/26/22 9:34 PM, enz...@gmx.com wrote:
Hi Jürgen,
i was able to get )copy working with libapl
i had to define ⎕pw←80 in the fpc program right after init_libapl() to get rid
of the divbyzero runtime exception from apl_exec(')copy aa.apl');
if you remember, i had to originally put a ⎕pw←80 in src/UCS_strings.cc (for
libapl.so compile only) or else libapl gave a divbyzero runtime exception when
it starts
I can now call apl_exec(')copy aa.apl'); which contains any number of fns in
it but all the fns headers give the following error when they are encountered
in order from the )copy buffer and sequentiall apl_exec('∇fns#'); fns header
calls.
SYNTAX ERROR+
Tokenizer: No token for Unicode U+2207 (∇)
Input: prep (this is the name of the first fns in my aa.apl but repeated
for each new fns as i get them from the )copy buffer)
the error is from line 120 in src/Tokenizer.cc - i tried to find something in
Tokenizer.hh Token.hh and UCS_string.hh to fix but to no avail
to create the fns - right after the apl_exec(')copy aa.apl'); i have to run
apl_exec('∇prep'); myself to open a good fns header so the fns lines that are
in the )copy buffer can get put into the fhs until the ∇ closes the fns
definition
i have to repeat this for each fns in the aa.apl after the one time
apl_exec(')copy aa.apl'); i just have to keep track of the order of the fns
names in aa.apl.
if there are 4 fns in aa.apl but only run 3 apl_exec('∇fns#') then the 4th fns
stays in the buffer until i do the 4th apl_exec('∇fns4'); - i can run a lot of
stuff and then get the 4th so nothing seems to interfer with the )copy buffer?
so the apl_exec uses a different buffer for it's output?
if i run apl_exec('∇fns5'); with only 4 fns in aa.apl i get the rest of aa.apl
in it but with no closing ∇ definitions i get the following behavior
if the last fns in the aa.apl (or the above ∇fns5 example) and for example the
fns has 4 lines in it and no closing ∇ then there is a fns editing line [5]
displayed and i can add more lines or close the fns manually with ∇ - however
in order to save the changes to the fns i have to edit aa.apl
enztec
