Re: [Bug-apl] erlang APL NIF

[Dr . Jürgen Sauermann]

Hi Rowan,

see below.

BR, Jürgen

On 6/4/19 5:00 PM, Rowan Cannaday wrote:

Hello again,

Trying out the erlang/APL interface (its building now!), running into
a few issues.

BTW I'm pretty new to FOSS mailing lists so if in the future you'd
prefer I'd start these as different threads, or use a different syntax
for distinguishing shell output just let me know.

Don't worry, everything is just fine.

First issue:
```
ldd /usr/local/lib/apl/erlang_APL_nif.so
    libapl.so => not found
```
I fixed by adding "/usr/local/lib/apl" to my LD_LIBRARY_PATH.

2nd issue:
```
1> apl:init().
load called.
Executable /usr/lib/erlang/erts-10.2.4/bin/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).
                                                libapl initialized.
ok
2>
```

I have added a note at the end of erlang/README regarding this.

This seems related to the following previous bug report:
SVN 595
https://lists.gnu.org/archive/html/bug-apl/2015-04/msg00032.html
The function still returns 'OK'.

Third Issue (including entire session for context):
```
PATH=$PATH:/usr/local/bin:/usr/local/lib/apl
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/apl erl
Erlang/OTP 21 [erts-10.2.4] [source] [64-bit] [smp:4:4] [ds:4:4:10]
[async-threads:1]

Eshell V10.2.4  (abort with ^G)
1> c("/usr/local/lib/apl/apl").
{ok,apl}
2> apl:init().
load called.
Executable /usr/lib/erlang/erts-10.2.4/bin/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).
                                                libapl initialized.
ok
3> apl:statement("1 2 3 + 4 5 6").
5 7 9
[{value,[3],[5,7,9]}]
4> apl:statement("(1 2 3)∘.+(1 2 3)").
2 3 4
3 4 5
4 5 6
[{value,[3,3],[2,3,4,3,4,5,4,5,6]}]
5> apl:statement("∘.,/(1 2)(1 2)").
Segmentation fault
```

Yes. I can confirm the segfault. It also happens on my machine. It looks like
The erlang interface as such is working, but fails in this particular case. The
same statement entered directly in APL works as expected.

The real problem is this:

When I published the Erlang interface back in 2017, the feedback that
I received from different communities was ranging from total lack of interest
(Erlang community) to derogative (Elixir community). For that reason I am
inclined to remove the Erlang interface from GNU APL in the next GNU APL
release 1.8.

On the other hand I suspect that the problem with the statement above is not
related to the Erlang interface in the first place, but to libapl. In that case
removing the Erlang Interface would not help. The way Erlang works makes
it quite complicated to troubleshoot the case. If the problem is in libapl,
however, one can replace Erlang by a simple C/C++ main() program that
initializes libapl and then calls the same functions in libapl that Erlang calls
in erlang_APL_nif.c. I was able to track down the segfault to occur in
Prefix.cc line 935:

Token result = at0().get_function()->eval_B(at1().get_apl_val());

This line calls a user-defined Function (probably Macro Z__LO_REDUCE_X4_B
in Macro.def line 147).

If you would like to help, then please try your luck troubleshooting this.
I can help you with the details that you may need.

I have attached a file test_libapl.c that I use to test libapl. You
can use your failing apl _expression_ instead of ⎕←2 3⍴⍳6 in that file.

And the output of `strings apl.beam`:
```
FOR1
        pBEAMAtU8
init
erlang
load_nif
command_utf8
command_utf8__not_loaded
exit
command_ucs
command_ucs__not_loaded
statement_utf8
statement_utf8__not_loaded
statement_ucs
statement_ucs__not_loaded
fix_function_ucs
fix_function_ucs__not_loaded
set_variable
set_variable___not_loaded
eval_mux
eval_mux__not_loaded
eval_
eval_B
eval_AB
eval_XB
eval_AXB
eval_LB
eval_ALB
eval_LXB        eval_ALXB
eval_LRB        eval_ALRB       eval_LRXB
eval_ALRXB
true
false
length
value
lists
foldl
reverse
error
Invalid eterm
command statement
module_info
get_module_info
-e2a/1-fun-0-
Code
@address@hidden@
@#3@
@1C@
@QC@
@address@hidden@
 @#3@
@qC@
&@#3@
(@#3@
F0#G
address@hidden
F0#G
StrT
ImpT
ExpT
FunT
]LitT
c```f``Pm
`Na`-K
LocT
BAttr
vsnl
C3jjCInf
versionk
7.3.1h
optionsjh
sourcek
/usr/local/lib/apl/apl.erljDbgi
debug_info_v1d
erl_abstract_codeh
nonej
Line
        '       +       ,       -       .       /       0       1
 56       7       8       9       :       ;       <       =       >
   ?@       A       E       I       O       T       W       X       S
/usr/local/lib/apl/apl.erl
```

It doesn't seem to be producing a core dump, haven't figured out why yet.

Thanks y'all.
Let me know how I can help!

- Rowan

test_libapl.c
Description: Text Data