>From the Emacs mode's perspective, that would be perfectly appropriate of
course. However, the native library module is, despite its name, not
necessarily specific to Emacs. It implements a generic protocol that any
external tool could use. It's not guaranteed that a user of the native
module want
Hi Elias,
wouldn't it then be easier for the user to load the emacs lib when
--emacs is given?
BTW we could make --emacs an entry in the preferences file so that the
user does not
need to give it on the command line every time.
/// Jürgen
On 05/11/2014 03:12 AM, Elias Mårtenson wrote:
Ind
Indeed it would fine to load it via a command, and it's perfectly
acceptable to not be able to call it from APL. The Emacs library has very
few requirements.
So, perhaps we should have two different types of native libraries? We
could call them "native library" (with the existing semantics), and t
Hi Elias,
I see. So when would you like to load the shared lib? We could do it by
)COMMAND or by a --command-line-option.
Sounds like you want it rather early, even before APL's immediate
execution loop starts. That would be a
--command-line-option then. We could keep the rest (function names i
First of all, sorry about the benchmark numbers. I thought I already sent
them but I see now that I had forgotten about it. I'll do it tomorrow.
About the libraries, I see what you are saying. Having a library ID is
definitely one way of dealing with this (I suppose the package manager can
be used
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
d
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
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.
Th
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 libemac
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 softwar
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
11 matches
Mail list logo
