[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: Elias Mårtenson
Subject: Re: [Bug-apl] Request for feature: Back-channel interaction
Date: Tue, 31 Dec 2013 11:54:40 +0800

Hello again, and yet another followup to myself...

After having slept on this, I had a few more thoughts around this stuff that I would like to share with you:

Native networking?

I realised that there is yet another potential solution to the communication with an external agent that I never considered. There would be no need to depend on the native API if there was a native networking API in GNU APL. Not only would such API be useful for other things, but then the entire APL-side implementation can be implement in APL and loaded into the interpreter on startup, without any need for native C code.

I'd be willing to whip up a test implementation for this, if you're interested.

Threads or I/O channels

No matter what approach I will choose for the Emacs communication, there is still the problem of being able to listen on a network socket while at the same time waiting for input on the commandline.

Usually one resorts to either threads or some kind of select() or poll() like mechanism for this. What is your suggestion here?

Native API questions

In the current implementation, you're relying on a certain C++ name mangling scheme (the one use din GCC I presume). This will not work on any other compiler, for example the Sun C++ compiler suite. It will also not work on other operating systems.

If at all possible, porting would be easier if the call into native code was done through symbols that are declared extern "C". This will remove dependency on a certain C++ ABI (which is not standardised, unfortunately).


reply via email to

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