Hah, I hadn't fixed it yet - but I tracked down the same issue in the
last few minutes. There was no init_macros in libapl. I was wondering
why ALL the macros had null pointers, but it would have taken me a bit
longer to implement a fix.
Thank you for your help. I'll update my repo and test.
On 6/5/19, Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> wrote:
> Hi Rowan,
>
> I think I fixed the problem (SVN 1166):
>
> eedjsa@server66:~/projects/juergen/apl-1.7/erlang$ erl
> Erlang/OTP 19 [erts-8.2] [source] [smp:4:4] [async-threads:10] [hipe]
> [kernel-poll:false]
>
> Eshell V8.2 (abort with ^G)
> 1> apl:init().
> load called.
> libapl initialized.
> ok
> 2> apl:statement("∘.,/(1 2)(1 2)").
> 1 1 1 2
> 2 1 2 2
> [committed_value,committed_value,committed_value,
> committed_value,committed_value,committed_value,
> committed_value,committed_value,
> {value,[],
> [{value,[2,2],
> [{value,[2],[1,1]},
> {value,[2],[1,2]},
> {value,[2],[2,1]},
> {value,[2],[2,2]}]}]},
> committed_value]
> 3>
>
>
> There was a missing initialization of the Macro subsystem in libapl.cc.
>
> Macros were introduced after libapl, so I forgot to add that initialization.
>
> Now Erlang works again (of course only on my machine).
>
> Best Regards,
> Jürgen Sauermann
>
>
> On 6/4/19 11:04 PM, Rowan Cannaday wrote:
>>
>> Thats unfortunate re: the feedback you received. I personally think an
>> embedded APL in C/erlang is a fantastic idea - the distributed toolkit
>> of beam with the symbolic math of APL I find very appealing.
>>
>> I'll give it an effort.
>>
>> Appreciative of the help, I'll likely be bugging you in the near future.
>>
>> - Rowan
>>
>> On Tue, Jun 4, 2019, 4:32 PM Dr. Jürgen Sauermann
>> <mail@jürgen-sauermann.de> wrote:
>>>
>>> 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
>>>> @#3@!C@
>>>> @#3@
>>>> @1C@
>>>> @QC@
>>>> @#3@aC@
>>>> @#3@
>>>> @qC@
>>>> &@#3@
>>>> (@#3@
>>>> F0#G
>>>> 5@G
>>>> 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
>>>>
>>>>
>>>
>>
>
>
