Re: libapl with fpc (free pascal)

[enztec]

Hi

I recently upgraded to svn 1553 from svn 1474 and it takes a real effort to do 
an upgrade since i have to manually edit all the files i'v changed over the 
years
doing the changes manually seems more reliable to me then to rely on diff/patch

using init_libapl gives the following but doesn't affect any libapl fpc errors

initial RLIMIT_AS (aka. virtual memory) is: 'unlimited'
estimated available memory: 2952790016 bytes (2952 MB)

sizeof(int) is            4
sizeof(long) is           4
sizeof(void *) is         4

sizeof(Cell) is           20
sizeof(SI stack item) is  3080
sizeof(Svar_partner) is   28
sizeof(Svar_record) is    328
sizeof(Symbol) is         52
sizeof(Token) is          20
sizeof(Value) is          376 (including 12 Cells)
sizeof(ValueStackItem) is 20
sizeof(UCS_string) is     24
sizeof(UserFunction) is   244

⎕WA total memory is       2952790016 bytes (2952 MB, 0xb0000000)
increasing rlimit RLIMIT_NPROC from 24047 to infinity

initializing paths from argv[0] = aaaa
initializing paths from  $PATH = 
/bat:.:/ram:/bin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/usr/local/gcc/bin:/usr/local/samba/bin:/usr/local/samba/sbin:/usr/local/ssl/bin:/usr/local/php/bin:/mingw/bin:/usr/X11R6/bin:/usr/local/mariadb/bin
initializing paths from  $PWD = /apl/libapl/fpc
APL_bin_path is: .
APL_bin_name is: aaaa
Not reading config file /usr/local/etc/.apl/preferences (No such file or 
directory)
Reading config file /root/.apl/preferences ...
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))
Not opening shared memory because command line option --noSV (or similar) was 
given.

-

using libapl in c/fpc/python is a bit to cumbersome to use for program coding 
and since i have a nice apl ws and apl scripting programming environment with 
apl fns results being brought into fpc using a tstringlist (very fast) which 
basically treats apl fns like fpc procedures/functions

so unless someone is interested in this libapl stuff with fpc i'll let it go

i am able to create very large variables with my fpc copy procedure for libapl 
with fpc but get the following exception when trying to create a fns
it wouldn't be a problem actually since i can just do the fns code inline as 
straight code which works fine

i'm just including this fns runtime exception for completeness in case someone 
is interested
i'll leave the libapl c/fpc/python3 linux coding setup intact in case any one 
who uses libapl is interested in this

-

libapl    apl_exec('∇aa');       same gdb exception in c and python gives a 
floating point exception

An unhandled exception occurred at $B7506207:
EAccessViolation: Access violation
  $B7506207
  $B7506787
  $B750D37D
  $B750E1A6
  $B74DA6B8
  $08048B12  main,  line 126 of libapl.pas

(gdb) run
Program received signal SIGSEGV, Segmentation fault.
0xb7d7c207 in LineInput::edit_line (mode=LIM_Nabla, prompt=..., user_line=..., 
eof=@0xbfffe210: false, hist=...) at LineInput.cc:949
949        the_line_input->current_termios.c_lflag &= ~ISIG;   // disable ^C

(gdb) where
#0  0xb7d7c207 in LineInput::edit_line(LineInputMode, UCS_string const&, 
UCS_string&, bool&, LineHistory&)
    (mode=LIM_Nabla, prompt=..., user_line=..., eof=@0xbfffe210: false, 
hist=...) at LineInput.cc:949
#1  0xb7d7c787 in LineInput::get_terminal_line(LineInputMode, UCS_string 
const&, UCS_string&, bool&, LineHistory&)
    (mode=LIM_Nabla, prompt=..., line=..., eof=@0xbfffe210: false, hist=...) at 
LineInput.cc:936
#2  0xb7d7c9f4 in InputMux::get_line(LineInputMode, UCS_string const&, 
UCS_string&, bool&, LineHistory&)
    (mode=LIM_Nabla, prompt=..., line=..., eof=@0xbffff2c4: false, hist=...) at 
LineInput.cc:862
#3  0xb7d8337d in Nabla::edit() (this=0xbffff384) at Nabla.cc:106
#4  0xb7d841a6 in Nabla::edit_function(UCS_string const&) (cmd=...) at 
Nabla.cc:40
#5  0xb7d506b8 in Command::process_line(UCS_string&) (line=...) at 
Command.cc:130
#6  0xb7ec298b in apl_exec(char const*) (line=0x809eec1 <_$LIBAPL$_Ld42+5> "") 
at libapl.cc:363
#7  0x08048b12 in main () at libapl.pas:126

-

some interesting timing results from my recent code testing

⍴a and ⍴b are both 30000    apl code used is  (a,¨b)⌷¨⊂ar

in apl ws         running it 1 time takes 49 msec      (cna apl )copy r)
in apl script     running ot 1 time takes 46 msec    (cn  st enz.apl)

in libapl fpc     running it 1 time takes 56 msec     (caf st libapl.pas)
in libapl c        running it 1 time takes 59 msec     (cac st libapl.c)
in libapl puthon  running it 1 time takes 60 msec  (cap st libapl.py)

-

fpc code with  n :=  250 runs take 49 msec   200 runs take 37 msec   100 runs 
take 18 msec   50 runs take 9 msec     (cn stt timing.pas)
length(a) and length(b) are both 30000
the fpc code is  for j := 1 to n do for i := 1 to 30000 do rs[i] := ar[a[i], 
b[i]];

---

thanks

enztec


On Sat, 11 Jun 2022 19:29:14 +0200
Dr. Jürgen Sauermann <mail@xn--jrgen-sauermann-zvb.de> wrote:

> Hi,
>
> I have no immediate answer what is going wrong.
> Possibly the parallel execution subsystem is not properly initialized.
>
> Did you call init_libapl() before using libapl?
>
> I also fixed a few issues in the parallel execution (which is used even if
> no parallel execution takes place). Maybe the behaviour is different
> now (SVN 1562).
>
> Best Regards,
> Jürgen
>
>
> On 6/11/22 1:34 AM, enztec@gmx.com wrote:
> Hi,
>
> thank you for this information about how )copy works.
>
> since it was such a simple idea to get )copy working with libapl i went back 
> to my libapl with fpc (free pascal) coding to get it working there.
>
> i was able to write a sinple file reading procedure in fpc to have a copy 
> procedure for my libapl with fpc
> i'll leave writing the file reading code for libapl with c and libapl with 
> python to others
>
> i wrote a freepascal library unit that allows everything i want to run with 
> libapl with fpc (especiall your apl_exec('rs←(a,¨b)⌷¨⊂ar'); code with no 
> problems so i was very surprised when demoing my code that the folloing 
> simple code runtime exceptions resulted
>
> there are only 2 problem apl code locations for these errors
>
> just to clarify these errors only occur (along with the ⎕pw divide by zero 
> error which i resolved in src/UCS_string.cc a few years ago with your help) 
> with libapl with fpc - the only problems with libapl c and python were the 
> )copy problem
>
> -
>
> libapl.pas  +1 and 1+1 and (1 2 3)=1 2 3
>
> An unhandled exception occurred at $B7639BE7:
> EAccessViolation: Access violation
>   $B7639BE7
>   $B763A33A
>   $B76415DB
>   $B75A1C76
>   $B76448B4
>   $B7551D0C
>   $B75527E2
>   $B7551698
>   $080489EB  main,  line 86 of libapl.pas
>
> gdb libapl
>
> (gdb) run
> Program received signal SIGSEGV, Segmentation fault.
> Parallel_job_list<PJob_scalar_B, false>::start (loc=0xb7ef29a3 
> "ScalarFunction.cc:157", first_job=..., this=0x2c) at PJob.hh:261
> 261        /// set current job. CAUTION: jobs may be modified by the
>
> (gdb) where
> #0  0xb7e38be7 in Parallel_job_list<PJob_scalar_B, 
> false>::start(PJob_scalar_B const&, char const*)
>     (loc=0xb7ef29a3 "ScalarFunction.cc:157", first_job=..., this=0x2c) at 
> PJob.hh:261
> #1  0xb7e38be7 in ScalarFunction::do_scalar_B(ErrorCode&, Value const&, 
> ErrorCode (Cell::*)(Cell*) const) const
>     (this=0xb7f81420 <Bif_F12_PLUS::_fun>, ec=@0xbfffefa8: E_NO_ERROR, B=..., 
> fun=<optimized out>) at ScalarFunction.cc:157
> #2  0xb7e3933a in ScalarFunction::eval_scalar_B(Value const&, ErrorCode 
> (Cell::*)(Cell*) const) const
>     (this=0xb7f81420 <Bif_F12_PLUS::_fun>, B=..., fun=&virtual table offset 
> 156) at ScalarFunction.cc:130
> #3  0xb7e405db in Bif_F12_PLUS::eval_B(Value_P) const (this=0xb7f81420 
> <Bif_F12_PLUS::_fun>, B=...) at ScalarFunction.hh:800
> #4  0xb7d9f364 in Prefix::reduce_MISC_F_B_() (this=0x80f3a68) at Prefix.cc:975
> #5  0xb7da0c76 in Prefix::reduce_statements() (this=<optimized out>) at 
> Prefix.cc:706
> #6  0xb7e438b4 in StateIndicator::run() (this=0x80f3448) at 
> StateIndicator.cc:357
> #7  0xb7d5dcdb in Executable::execute_body() const (this=0x80ee5e0) at 
> Executable.cc:261
> #8  0xb7d50d0c in Command::finish_context() () at Command.cc:343
> #9  0xb7d517e2 in Command::do_APL_expression(UCS_string&) (line=...) at 
> Command.cc:331
> #10 0xb7d50698 in Command::process_line(UCS_string&) (line=...) at 
> Command.cc:141
> #11 0xb7ec298b in apl_exec(char const*) (line=0x809edca <_$LIBAPL$_Ld33+2> 
> "") at libapl.cc:363
> #12 0x080489eb in main () at libapl.pas:86
>
> -
>
> libapl.pas  a[⍳4]+.=b[⍳4] and a+.=b
>
> An unhandled exception occurred at $B7512726:
> EAccessViolation: Access violation
>   $B7512726
>
> (gdb) run
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7d1a726 in Bif_OPER2_INNER::PF_scalar_inner_product (tctx=...) at 
> Bif_OPER2_INNER.cc:250
> 250     ShapeItem z = tctx.get_N() * slice_len;
>
> (gdb) where
> #0  0xb7d1a726 in Bif_OPER2_INNER::PF_scalar_inner_product(Thread_context&) 
> (tctx=...) at Bif_OPER2_INNER.cc:250
> #1  0xb7d1c22d in Bif_OPER2_INNER::scalar_inner_product() const 
> (this=0xbffff058) at Bif_OPER2_INNER.cc:235
> #2  0xb7d1c22d in Bif_OPER2_INNER::eval_ALRB(Value_P, Token&, Token&, 
> Value_P) const
>     (this=0xb7f74200 <Bif_OPER2_INNER::_fun>, A=..., _LO=..., _RO=..., B=...) 
> at Bif_OPER2_INNER.cc:141
> #3  0xb7d5a939 in DerivedFunction::eval_AB(Value_P, Value_P) const 
> (this=0x80f3448, A=..., B=...) at DerivedFunction.cc:216
> #4  0xb7d9e163 in Prefix::reduce_A_F_B_() (this=0x80f3a68) at Prefix.cc:1177
> #5  0xb7da0c76 in Prefix::reduce_statements() (this=<optimized out>) at 
> Prefix.cc:706
> #6  0xb7e438b4 in StateIndicator::run() (this=0x80f3448) at 
> StateIndicator.cc:357
> #7  0xb7d5dcdb in Executable::execute_body() const (this=0x80ee510) at 
> Executable.cc:261
> #8  0xb7d50d0c in Command::finish_context() () at Command.cc:343
> #9  0xb7d517e2 in Command::do_APL_expression(UCS_string&) (line=...) at 
> Command.cc:331
> #10 0xb7d50698 in Command::process_line(UCS_string&) (line=...) at 
> Command.cc:141
> #11 0xb7ec298b in apl_exec(char const*) (line=0x809ede1 <_$LIBAPL$_Ld36+17> 
> "") at libapl.cc:363
> #12 0x08048a60 in main () at libapl.pas:104
>
> ---
>
>
>
>