This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Module editing; debugging with gdb


Andrew Archibald <aarchiba@calum.csclub.uwaterloo.ca> writes:

> Greg Badros <gjb@cs.washington.edu> writes:
> 
> > 1) Often when I'm working with our Scwm modules, I'd like to test a
> > change to a procedure defined in the module w/o restarting scwm/guile.
> > What is the best way to do this?  Should I edit the module and then
> > re-evaluate a (use-modules ... ) declaration?  Is there any way to give
> > use-modules an explicit filename (since I do not want to overwrite the
> > module.scm file in the installed place until I've tested my change)?
> 
> AFAIK this is difficult.  Once a module has been loaded, it is cached
> and won't be reloaded by a use-modules.  However, ISTR that (load
> "my-hacked-module.scm") will do what you want, that is, define new
> things in the module. 

The load primitive may be good enough-- it lets me avoid the install,
which was one of my goals.

> It would be nice if guile could be coerced to reload modules from
> where it got them.  And coerced to forget modules when they're not
> useful.  I guess we'll just have to wait for Godot.  (Does anyone even
> have a design for it?  Any reason not to clone scheme48's?)

The module could be cached, but the file could still be checked upon a
subsequent (use-modules ...), and if the modification time had changed
it could be reloaded.  Usually a stat is pretty inexpensive (exception:
over NFS, it can be really expensive, especially if the server has gone
down).  Of course, this may not be the semantics that you want, anyway
(maybe you really want modules to not change once one version of the
module has been used).

Thanks Andrew!

Greg