unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* `guile-debugging' feature requests
@ 2006-06-19  7:58 Ludovic Courtès
  2006-06-23 13:31 ` Neil Jerram
  0 siblings, 1 reply; 4+ messages in thread
From: Ludovic Courtès @ 2006-06-19  7:58 UTC (permalink / raw)


Hi,

I only started using Neil's `guile-debugging' very recently, and so far
mostly for incremental development from Emacs rather than debugging.
BTW, I find `gds-tutorial.txt' a very nice way to get started and also
to get impressed by the new features.  I think this will have to be
integrated too.

So, below are a couple of feature requests wrt. incremental development
from within Emacs.


* 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.


* 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?


Thanks,
Ludovic.


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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: `guile-debugging' feature requests
  2006-06-19  7:58 `guile-debugging' feature requests Ludovic Courtès
@ 2006-06-23 13:31 ` Neil Jerram
  2006-06-26 12:19   ` Ludovic Courtès
  0 siblings, 1 reply; 4+ messages in thread
From: Neil Jerram @ 2006-06-23 13:31 UTC (permalink / raw)


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!

> * 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.

Regards,
     Neil



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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: `guile-debugging' feature requests
  2006-06-23 13:31 ` Neil Jerram
@ 2006-06-26 12:19   ` Ludovic Courtès
  2006-09-04  7:01     ` Neil Jerram
  0 siblings, 1 reply; 4+ messages in thread
From: Ludovic Courtès @ 2006-06-26 12:19 UTC (permalink / raw)
  Cc: Guile-Devel

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: `guile-debugging' feature requests
  2006-06-26 12:19   ` Ludovic Courtès
@ 2006-09-04  7:01     ` Neil Jerram
  0 siblings, 0 replies; 4+ messages in thread
From: Neil Jerram @ 2006-09-04  7:01 UTC (permalink / raw)


ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> 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).  :-(

I just took a quick look at this.  In Emacs 21.4
hippie-expand-try-functions-list is "exported" by a defcustom:

(defcustom hippie-expand-try-functions-list
  '(try-complete-file-name-partially
    try-complete-file-name
    ...))

So I think all that's needed here is to write a
gds-try-complete-for-hippie-expand function, then document that you
(the user) can add this to hippie-expand-try-functions-list.

Apart from figuring out the calling convention for a try-complete
function, this looks pretty simple; I'll report back soon.

Regards,
     Neil



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


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-09-04  7:01 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-19  7:58 `guile-debugging' feature requests Ludovic Courtès
2006-06-23 13:31 ` Neil Jerram
2006-06-26 12:19   ` Ludovic Courtès
2006-09-04  7:01     ` Neil Jerram

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).