Works great :)
- Rowan
On 6/5/19, Rowan Cannaday <cannad...@gmail.com> wrote:
> 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
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
