Hi Elias,
I am not sure if the observed behavior is actually wrong. If you load
two libraries with different paths
then you get two different libraries and each is initialized. Right now
NativeFunction checks if a shared
library with the *same path* (i.e. directories and filename) exists and
does not load it twice if so.
Your expectation seems to be that a library with the *same name* but
stored in different places should
also not be loaded twice. A consequence of this would be that you cannot
replace a library with a different
version and the same name. In your case it would mean that if you start
in emacs mode then you cannot
load or replace the emacs mode library in the same interpreter session.
This may suit you in relation to
the current problem but could fire back in other cases.
What might be somewhat cleaner is to have a function get_library_id()
that returns some identification string,
and to stop the loading if a duplicate id is detected (or let the
library decide how it would like to proceed).
BTW. I would still be interested in the result files of your 80-core
benchmark.
/// Jürgen
On 05/10/2014 03:09 PM, Elias Mårtenson wrote:
The problem is not related to the unloading of functions, but that the
call to )LOAD triggers a /reload/ of the function, even though the old
one is still active.
That reload is what corrupts the Emacs mode in two different ways,
either of which would cause the Emacs mode to hang:
* The reload triggers another call to the initialisation code
(called by get_signature). This causes an already initialised
library to reinitialise. I could deal with this using a flag, but…
* The library that the )LOAD loads is not the same as the one that
was originally loaded. In my case, the Emacs native library was
original loaded form
/home/elias/prog/gnu-apl-mode/native/libemacs.so, but the call to
)COPY then loads /home/elias/src/apl/dist/lib/apl/libemacs.so
(that's where my development version of GNU APL is installed). So
yes, the library is now loaded twice, causing no end of trouble.
Regards,
Elias
On 10 May 2014 21:02, Juergen Sauermann <juergen.sauerm...@t-online.de
<mailto:juergen.sauerm...@t-online.de>> wrote:
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
