[ruby-talk:13303] Reloading files

First of all, a confession: Lapidary's GTK::TestRunner had a show stopper
bug in it in the first release (a fix is in CVS). However, since nobody's
complained about it, I'm guessing most people aren't using it, probably
because it's not currently very useful. This is because you have to kill it
each time you modify any code and then start it up again, which certainly
outweighs the benefits of having a green (or red) bar. The reason the bug
made it out into the wild is that _I_ haven't been using it for exactly that
reason.

So, the question is, how can it be made to reload changed (or, to keep it
simple, all) test and fixture code? I have a few ideas, but I'd like to run
it by everybody first to see if they're feasible.

1) Establish a baseline by letting Lapidary load and then taking a snapshot
of the system. I'm thinking this might best be done by having Lapidary
required through one entry point, i.e. you'd only need to require the
TestRunner you want to use, and it would load all of the framework classes.
If you required Console::TestRunner, no problem, it would just require
everything and go on. If, OTOH, you required GTK::TestRunner, it would
require all of the Lapidary files, set itself up, and then store the current
state of the system so that it would know what not to mess with when
reloading.

2) Track requires so that they can be reloaded. I think the best way to do
this is to override Kernel#require() in Lapidary, and have it Kernel#load()
and store requires into a Lapidary-specific require global. This way, we end
up with a mutable require global, and we can strip it back down to the bare
minimum before reloading. Is there a better way to do this? Also, there
might be a problem with any programs that depend on the current require
functionality; is there a way to insulate them from harm?

3) Store the initial state of system classes. Because it is very handy to
mess around with system classes within programs, it's very possible that
they will be modified, and we need a way to restore them to their original
state before reloading the test. The only way I can think to do this is to
dup (clone?) the classes in the system, and store them in a hash keyed to
their original name. I'll get to restoring them in a minute.

4) When running a test the second time, remove all newly added classes in
the system before requiring. I think this can be done by going through
ObjectSpace and doing a remove_const on them all. We need to do this because
we want fresh copies of all the classes defined by the test, as opposed to
just imperfectly overwriting their current state. Will this work?

5) Restore system classes to their saved state, by reassigning their
constant to the saved duplicate in the map. Now, we should be back at the
state we were at during the first run. Of course, this will cause a lot of
constant warnings, but I don't know how to avoid that. Now the only thing to
do is...

6) Re-require the originally required files and re-run the test.


Will this work? My biggest fear is that due to the extremely dynamic nature
of Ruby I may be missing a fatal flaw. Also, is there a better way to go
about this?

If we can get something like this to work, it will allow a persistent test
window where you can just click Run every time you want to see if you've
broken something, which would be a beautiful thing.

Thanks for the help,


Nathaniel

<:((><
+ - -						+ - -
| RoleModel Software, Inc. &		| EQUIP VI
| The XP Software Studio(TM)		|