Re: `guile-debugging' feature requests

[ludovic.courtes@laas.fr (Ludovic Courtès)]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
>> * Completion
>>
>> Currently, `gds-complete-symbol' only completes symbols based on those
>> defined in the current module of the attached Guile process.  This is
>> fine, but it would be nice if a completion function compatible with
>> `hippie-expand' was provided, so that one can plug it in the middle of
>> other completion functions.
>
> I don't yet know what this means in detail, because I've never looked
> at how hippie works.  I'll take a look soonish, but if you happened to
> work it out for me first I shouldn't mind!

I'm not an Emacs expert, so I'm afraid I won't be able to provide you
with the exact patch needed to make it work.  ;-)

`hippie-expand' works by calling the functions listed in
`hippie-expand-try-functions-list' which is documented as follows:

  The list of expansion functions tried in order by `hippie-expand'.  To
  change the behavior of `hippie-expand', remove, change the order of,
  or insert functions in this list.

These should be one-argument functions that are passed a previous
completion result.  Hippie provides a number of such functions out of
the box: `try-complete-file-name', `try-complete-lisp-symbol', etc.

Unfortunately, from a quick look at `hippie-exp.el', it seems that these
functions pass their result by mutating `he-expand-list' which is not
exported.  Thus, in order to implement hippie-compatible completion
functions, either hippie-expand has to be adapted, or your own
completion function has to be made part of hippie-expand (which it not
possible in your case).  :-(

>> * Module Unloading/Reloading
>>
>> When one is writing code and periodically testing it via GDS, it may
>> sometimes be useful to tell GDS to entirely unload/reload a given
>> module.  This would be particularly helpful when testing features that
>> span several modules.  I don't know exactly what would be feasible in
>> this area, and this would certainly require support from Guile itself.
>>
>> Also, I don't know what other Scheme/Lisp development environments allow
>> for in this respect.  Does that sound like a useful usage pattern?
>
> I completely agree as regards reloading, and I'm sure from my own
> experience that it is a frequently useful usage pattern.
>
> The implementation is just "load the relevant file", I believe; the
> only slightly tricky part is working out the most convenient possible
> interface.
>
> I'm not sure about unloading.  I don't recall ever wanting to do it in
> practice, and I'm not sure Guile has any way of achieving it.

Unloading would allow the modules' name spaces to be cleaned up before
one reloads it, thus potentially avoiding mysterious side-effects.

I believe module unloading could be achieved either by restarting a
Guile process or by "undefining" the module that is to be reloaded
before reloading it:

  (nested-remove! the-root-module '(%app modules foo bar))

However, the name space of the module users would need to be updated as
well.  One possibility would be to keep a list of all existing modules
(this can be done by "overloading" `make-module').  Another one would be
to include as an object property of each module object the list of its
users (perhaps by overloading `module-use!').

Upon reloading of a module, the `module-uses' list of its users would be
traversed in order to remove the relevant interface and replace it with
a new one obtained via `resolve-interface' (note: you need to know the
options that must be provided to `resolve-interface' here).

In either case, you'd then have to play with the innards of the module
system which can be quite tricky.  I played a bit in the REPL with the
above and was unable to reload a module after I had removed it...

I'm afraid these thoughts won't be very helpful.  ;-)

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel