Stephen Pair wrote:

> I'm looking into an issue with re-installing the VMConstruction module
> after unloading (or rather uploading) it.  It appears that
> "VMConstruction Plugins" has a cyclic dependency with "VMConstruction
> Plugins Test".  There may be other examples in these two modules, but
> here is one:
> 
> JPEGReadWriter2Plugin (in "VMConstruction Plugins") depends on the
> definition of TestInterpreterPlugin (in "VMConstruction Plugins Test")
> 
> TestInterpreterPlug (in "VMConstruction Plugins Test") depends on the
> definition of InterpreterPlugin (in "VMConstruction Plugins")

After getting the report about this problem from the SqueakEnd, I have been
working on the problem too. Once I've tested that my result works, I will
post it.

My memory had lapsed, so I wrote on the swiki that you can unload
VMConstruction and Balloon3D safely, which is true, but I also wrote that
you can reload them, which is not quite true, especially for VMConstruction
(reason below). I have corrected this on the swiki.

While cycles are generally reported before saving, there was a subtle bug
that caused these cycles to be missed.

I have moved things around in VMConstruction, and I will integrate your
renamings of the Test*** classes, which was just what I thought should be
done too.

> Now, of course, there is a good argument for re-organizing things to
> eliminate this cyclic dependency.  But, setting that aside, should we
> allow cyclic dependencies and handle that issue during activation

Undeclared should be able to handle forward references, because global name
references go via Association objects, which is what Undeclared exploits. So
theoretically this should already work with the current codebase. And it
does work for the unit tests but apparently not for all of Balloon3D.

However, the problem is this: this technique doesn't work for
subclass-superclass dependencies, since they use the superclass object
directly (no Association). The latter issue is a much harder problem. This
is the problem with the plugin classes you mention above. Still,
subclass-superclass cycles are much more rare than cyclic dependencies
caused by references in methods.

So I'm working on an enhancement that will get the superclass ordering right
when possible, but there are certain problems with this so that this only
works under special conditions. That means that the circularity must be
dealt with when the module is saved, not on loading it. Luckily it is
usually easy to apply this technique on saving however.

> by
> first collecting all of the required modules, then installing the
> collective items of all modules in an order that would not cause a
> walkback?  Currently, the module system installs each module one at a
> time, which makes it impossible to install two modules that are
> co-dependent (without some trickery anyway).

I don't really understand how such a scheme would work? What I think be
needed would be a way to fix superclass references "in retrospect", similar
to how Undeclared binds references in retrospect. It would be rather easy to
make the installer go through a list of classes and fix them up when
everything is loaded.

Henrik