Hello,
> Yes. This is covered in general terms by the comments in my earlier
> email today, but for the specific problem you describe, all you need to
> do is:
>
> - export `xchat-register-plugin' from your main infrastructure module,
> which let's say is (xchat main)
>
> - document that plugin
Hello Neil,
Glad to hear from you again.
> 1. The plugin author can still choose to make their file a
> module, if that is of use to them, by beginning it with a
> (define-module ...) form.
>
> 2. The plugin author can still choose to use modules to
> organize their plugin code internally, by
Rob Browning wrote:
I was also concerned about any pending signals, callbacks registered
with other libraries, or anything else that has been set up by code
executed from guile.
I was concerned that there may be trouble unless there's some way of
enumerating all of these things and undoing them
Neil Jerram <[EMAIL PROTECTED]> writes:
> What happens "inside" the library when it is dlopened? I thought
> nothing, so I doubt that loading and unloading per se would be a
> problem.
>
> If a single program called scm_init_guile() twice without the library
> being unloaded and reloaded first ..
Rob Browning wrote:
This made me wonder -- what happens if you dynamically load (dlopen) a
lib that depends on libguile, and then you later dlclose that lib?
What happens to libguile? Presumably it will be unloaded too. Does
Guile tolerate that?
If so, does Guile tolerate being re-loaded? Fo
Zeeshan Ali wrote:
Hello Neil,
I must remind you that i am anxiously waiting for more input on
this mater from you. Moreover, i tried to implement what you
recommended but i think i am in a problem: Since the loaded module
doesn't have access to binding of it's parent module (the module that
'
Zeeshan Ali wrote:
Hello again,
Why not use a registration
API instead? In other words, instead of this:
(define (do-plugin-thing-1 ...) ...)
(define (do-plugin-thing-2 ...) ...)
...
do this:
(let ()
(define (do-plugin-thing-1 ...) ...)
(define (do-plugin-thing-2 ...) ...)
...
(reg
Hello Neil,
I must remind you that i am anxiously waiting for more input on
this mater from you. Moreover, i tried to implement what you
recommended but i think i am in a problem: Since the loaded module
doesn't have access to binding of it's parent module (the module that
'uses' it), it is unab
Hello,
> >I'll try to test it here as well but i'll have to convert it to an
> > equivalent C code first.
>
> Out of interest, why is that? (It's easy enough to call Scheme-defined
> code from C, isn't it?)
Yes! I think i my mind is stuck in the world of C. :(
> That sounds more comple
Neil Jerram <[EMAIL PROTECTED]> writes:
> This way there is no magic, and the visibility of the plugin bindings
> is under the control of the plugin author. Also, this way you could
> stay pure-R5RS if you like, as you don't really need any features of
> the module system.
This made me wonder --
Hello again,
> > Why not use a registration
> > API instead? In other words, instead of this:
> >
> > (define (do-plugin-thing-1 ...) ...)
> > (define (do-plugin-thing-2 ...) ...)
> > ...
> >
> > do this:
> >
> > (let ()
> >(define (do-plugin-thing-1 ...) ...)
> >(define (do-plugin-thing
Zeeshan Ali wrote:
Hello,
It seems to survive 5 minutes of testing by me, but there could well be
problems lurking, so please test carefully in your context.
I'll try to test it here as well but i'll have to convert it to an
equivalent C code first.
Out of interest, why is that? (It's
Hello,
> It seems to survive 5 minutes of testing by me, but there could well be
> problems lurking, so please test carefully in your context.
I'll try to test it here as well but i'll have to convert it to an
equivalent C code first.
BTW guys,
I have been told that the fate of 'undefi
Hello,
> There's no way of completely removing (=> undefining) the definitions
> that a module added.
Hmm... But the GC would take care of that, wouldn't it? If it
doesn'nt then the plugins must do that themselves in their
'xchat-plugin-deinit' procedure, which they must define and export.
Zeeshan Ali wrote:
There's no way of completely removing (=> undefining) the definitions
that a module added.
Hmm... But the GC would take care of that, wouldn't it? If it
doesn'nt then the plugins must do that themselves in their
'xchat-plugin-deinit' procedure, which they must define
Zeeshan Ali wrote:
Hello fellow Guilers,
As most of you (who lurk on #guile) know that I've been writing an
xchat-guile plugin lately so people can write xchat plugins in
scheme/guile. The plugin is almost finished now and i am working on
the plugin loading and unloading functionality right n
16 matches
Mail list logo
