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
>>
>>
>
