Re: [Bug-apl] Request for feature: Back-channel interaction

[Elias Mårtenson]

Oh, and sorry for replying to my own email, but I realise that I left one piece of information out that probably makes my previous mail seems strange.

My previous comment regarding the native interface was based on a misunderstanding on my part; I thought that your native approach was that of an FFI (i.e. more like the Common Lisp approach rather than the Java one) where there is a local API that allows the user to directly call any function in arbitrary libraries. Such an approach would not require a native module.

Regards,

Elias

On 30 December 2013 23:24, Elias Mårtenson <address@hidden> wrote:

I did take a look at the version of the ⎕FX stuff that is in the source right now, and I can see that your approach is similar to that of JNI, the native interface for Java. I.e. you write some native code that acts as glue to integrate the underlying native library with the APL runtime.

My problem is that it's more complicated (although not impossible) to build an Emacs module with native code dependencies. There are very few such modules, and I don't know of a standardised way of distributing these. It would certainly add a lot of complexity to the install process (a process which is very simple right now, which is why I would love to be able to keep it as such).

I'm not entirely sure what I'm asking of you. :-)  I mean, it kind of works now, given the caveats I mentioned (in particular, never use any features that talk to the runtime unless the commandline is at the ready prompt). I guess I'm just trying to highlight the situation I'm in right now. I'll use whatever features you decide yo build into the runtime.

Regards,

Elias

On 30 December 2013 22:12, Juergen Sauermann <address@hidden> wrote:

Hello Elias,

I believe that the new native functions in GNU APL are the way go.

Instead of messing around with commands and their responses, you can
write C++ functions that have direct access to all the internals of GNU APL.

Put these functions into a shared library, say emacs.so. You can then
'emacs.so' ⎕FX 'EMACS' to get a user defined APL function EMACS that you
can "call" via stdin of GNU APL with their output on stdout. That makes
you filters simple and you still have access to everything you need.

See src/native for examples. I am currently working on a native FILE_IO that
shall provide all file related functions (fopen(), fclose(), ...) to GNU APL. You
may take that as a blueprint of how to use native functions.

/// Jürgen