[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 |
Hi,
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