Hi Elias,
I believe this relates to an earlier discussion about removing of callbacks.
Currently a library can decide how it wants to be handled by )LOAD
(actually by )ERASE
which is triggered by )LOAD):
A. be dlcosed() (and then needs to clear/restore its callbacks) or
B. remain loaded.
The default is B as requested earlier (so that the callbacks remain
intact). If you
want A. instead then define a function close_fun() and make it return
true when called.
Define means that get_function_mux() returns a pointer to it.
Now, if you go for A. then you should restore your callbacks in close_fun().
On the other hand, if you go for B. then you could be called twice and
should prepare for that
(a reference counter ++'ed in get_sig() and --'ed in close_fun()). Dito
for the same
library used under different names in the same WS, so namespaces would
not help).
dlopen() clains to take care of not being loaded twice, but the details
are not very clear, eg.
symbolic links to libs, copy of libs etc.
/// Jürgen
On 05/08/2014 03:28 PM, Elias Mårtenson wrote:
OK, thanks for the hints. I've spent some time looking at this issue
and I now have an idea what is happening.
When you issue )LOAD, the native library becomes loaded again, even
though it's already loaded. There are two issues with this:
First and foremost, after the )LOAD the version of libemacs that is
shipped with GNU APL was loaded, not the one correct onw (which
happens to be in my development directory). If you intend to call
dlopen on the same library, it's important that it's actually the same
library and not another one with the same name in a different directory.
Secondly, after loading this library again, GNU APL calls the
get_sig() function again. Even if the dlopen() call had returned the
same pointer, this would be problematic because the library performs
some initialisation stuff in this function call (as you previously had
recommended when I asked where I should run the initialisation).
Trying to reinitialise an already initialised library is not good.
In short, I think that the idea of using a normal function as entry
point into the native code is problematic. I wouldn't mind a redesign
of this so that native code lives in a namespace separate from the
normal code so it's unaffected by calls to )CLEAR, )ERASE etc.
Regards,
Elias
On 8 May 2014 18:51, Juergen Sauermann <juergen.sauerm...@t-online.de
<mailto:juergen.sauerm...@t-online.de>> wrote:
Hi,
could you please print the value of start_input just before line
223 in Input.cc like:
*I**nput::get_user_line(const UCS_string * prompt)
{
Q(start_input)
if (start_input) (*start_input)();
...*
On my machine it looks OK (even if I don't set it):
* This program is free software, and you are welcome to
redistribute it
according to the GNU Public License (GPL) version 3 or later.
start_input: '0' at Input.cc:223
)load DIJKSTRA
SAVED 2014-5-8 10:42:39 (GMT+2)
start_input: '0' at Input.cc:223*
/// Jürgen
On 05/08/2014 05:07 AM, Elias Mårtenson wrote:
This was reported in this thread:
https://github.com/lokedhs/gnu-apl-mode/issues/7
This problem seems to be caused by a bug in GNU APL. When the
user calls )LOAD to load a workspace, the start_input callback
function is not called before control is returned back to the user.
(because of this, the Emacs mode just sits there, hung, waiting
for a call to start_input that never happens).
Regards,
Elias
