[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: Fri, 3 Jan 2014 00:47:25 +0800

On 2 January 2014 21:45, Juergen Sauermann <address@hidden> wrote:
Hello Elias,

1. Lets say your function is EE and you call it with a function number as axis argument like you did. (I believe
this is a good convention). Then

A EE[x] B in APL calls eval_AXB() in the shared library,
EE[x] B in APL calls eval_XB() in the shared library,
and so on.

Awesome, this helps. :-) 

Not good. What I would propose instead is a simple variable set by the interpreter that tells if the interpreter expects
input (and is then guaranteed to not change its data structures until new input is received. Since you control the input
in emacs mode, when you see the variable set and send no data to the interpreter then you are safe.

Well, it still needs to be protected by a mutex, since the access is done through a separate thread and the only way to guarantee a memory barrier is by protecting the shared data using a mutex.

Without a memory barrier, you can end up with all sorts of cache coherency issues (like memory contents being updated in reverse order and nasty things like that).
3. Yes. I believe you need to sign a few papers (see chapter 6 of http://www.gnu.org/prep/maintain/maintain.html) then.

Ah, the copyright transfer agreement? They mentioned that on emacs-devel as well. I will look into that.
4. right now the .so files are installed in a subdirectory apl of /usr/local/lib or /usr/lib. This is under the control of
autoconf/automake and I believe the path to the parent directory of that subdirectory apl is known by the dynamic
linker by some magic that I do not fully understand. I have also tried to not install the .a and .la files, but have not
succeeded yet. Maybe a relative apl/ee,so works with ⎕FX - havent tried yet. If you have ideas - please let me know.

I tried relative, but it becomes relative to the directory where you started GNU APL, not relative to the installation directory. Perhaps the function that issues the dlopen call could take some special parameter to indicate that the path is relative to the installation prefix?

1 'lib/foo.so' ⎕FX 'EE'

Where 1 would indicate this fact?
Best Regards and a happy new year,

The same to you!


reply via email to

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