Re: )copy with libapl/apl_exec

[Dr . Jürgen Sauermann]

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, enztec@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