[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Juergen Sauermann
Subject: Re: [Bug-apl] Request for feature: Back-channel interaction
Date: Tue, 31 Dec 2013 14:25:17 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130330 Thunderbird/17.0.5


referring to a previous of your posts, I believe that there is no real dependency on GNU APLs internal code when using Native functions. The dependency is between emacs (in your case) and the native APL function. How the native APL function is
implemented is not visible or relevant to the caller of the native function.

Such a function would be tailored to one particular user; in your case
'emacs.so' ⎕FX 'EMACS' would create an APL function EMACS and only
the arguments provided to and the result returned by EMACS would be
relevant for the emacs side. Since this function is tailor made for emacs
it would only change when the emacs side has new requirements. The implementation in emacs.so would be maintained together with GNU APL if something changes on that side.

Having that said lets look at your other topics:

Native Networking.

There is already a "networking API" in GNU APL which is used for shared variables (for workspace-to-workspace communication and communication to auxiliary processors). The problem with that API is that APL only reacts to signals on that interface when ordered to do so (⎕SVE and friends). Otherwise signals received on that interface are ignored. All-in-all I would say that use of this API (or a similar one) only makes things more
complicated without solving any of your current problems.

Threads / IO-channels

Maybe you need threads sooner or later. I personally don't like select() very much (even though I use it at times for operations that have a timeout). A cleaner approach is blocking recv() or
read() in its own thread.

Of course, I would like to avoid a thread in the APL interpreter only for accommodating emacs.
But I see no need for that either.

Native API question

Thanks for the hint, I hadn't thought of that. Declaring extern "C" will not work because all arguments are C++ classes. But I could use a extern "C" function that returns pointers to the
C++ functions.

/// Jürgen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]