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