Re: [Bug-apl] libapl.so?

[Elias Mårtenson]

I already do pretty much this in the Android version. The Android APK contains libapl.so which is then linked from the Java code which drives the user interface.

Building libapl.so takes a bit of manual work right now, but in essence I configure the GNU APL source using the --with-android flag, and then compile and manually link the library together with some glue code.

You can look at the source here: https://github.com/lokedhs/android-gnu-apl/tree/master/build-tools

Regards,

Elias

On 30 January 2015 at 16:32, Dirk Laurie <address@hidden> wrote:

Dear Jürgen:

I am tackling a (possibly ambitious) project to make bindings to GNU APL 1.4
that would allow a Lua program to create one or more APL workspaces, pass
strings containing APL code to them, and convert items from the workspaces
to Lua values. Since Lua is a component of LuaTeX, it would then be
possible to include APL code and the result of executing it in one TeX
document without leaving TeX.

At present, I simply make one huge shared object file which also contains
all of GNU APL except main.cc. In order to satisfy external references,
I have needed to copy the code defining `void cleanup()` and `void
control_C(int)` as well as the five external variables in between to the
file defining the bindings.

A more canonical way of doing the same would be to link to a library
`libapl.so`, but GNU APL 1.4 does not make such a library. Perhaps the
current suite of files `/usr/lib/apl/lib_template_F0.so` etc could provide
the equivalent, but I have not been able to discover a way of loading
those files sequentially in Lua, which requires each shared object file
to have no unresolved dependencies.

Do you think there is any chance that a future release of GNU APL might
provide a library that would allow the embedding of APL functionality in
a different host program?

Thanks for a very impressive APL implementation, and best wishes.

Dirk Laurie