[Vm-dev] Re: Squeak3D plugin code generation broken by latest update

[David T. Lewis]

On Wed, Dec 02, 2015 at 11:16:46PM -0800, tim Rowledge wrote:
> 
> > On 02-12-2015, at 9:22 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> > 
> > On Wed, Dec 02, 2015 at 06:54:14PM -0800, tim Rowledge wrote:
> >> This is very puzzling. The change relevant to this is that in the Cog vmmaker version of  buildCodeGeneratorUpTo: the receiver (B3DEnginePlugin in this case) is added and initialized etc. So it needs to *not* be in the following list.
> >> 
> > 
> > Not so in trunk. Presumably this is a change in oscog.
> 
> Correct. All part of Eliots changes to make it possible to split up the vm parts.
> 

Yep, cool stuff. If you run out of things to do, take a look at how I
added Eliot's refactoring in trunk VMM. I did some additional work to
separate the object memory and interpreter aspects, clarify the differences
between stack interpreter versus context interpreter, and refactor
to get rid of overrides. (I still can't quite generate a stack interpreter
on trunk VMM/SVN, hmmm I need to remotivate myself to finish that little
chore before it all goes to rot.)

> > 
> >> In the trunk vmmaker, it really looks like it is also correctly added. If I generate the B3DEnginePlugin it creates a file that only differs in the date related info from one created by an unchanged vmmaker. 
> >> 
> > 
> > Generated code attached.
> > 
> > The generated code is missing a bunch of stuff, most notably the static
> > variable declarations that presumably are included when B3DEnginePlugin
> > is added to the code generator.
> > 
> > Note the empty /*** Constants ***/ section with no static variables
> > declared. That's what leads to the compile time errors, but I expect
> > that there are other things missing, given that the B3DEnginePlugin
> > class is missing from the code generator.
> 
> And I???ve just generated another copy (several times) and it has the filled out Constants section. This is really weird.
> 
> OK, I see a problem. My image has what I can only imagine is the older version of the B3DEnginePlugin class>translate??? method installed. The version in the Balloon3D-Plugins-tpr.8 package has been overwritten but there is no version info to hint what happened. So evidently I screwed up something somehow. What fun.
> 
> The odd things is that we are initialising the class, then in buildCodeGen??? we create the codegen, declare the module name and add the class; ah, the class added is InterpreterPlugin, not B3DEnginePlugin. In the .oscog version it finds the list of class from self upto and including InterpreterPlugin and deals with all of them. Oh-hoh, now I think I see what has occurred; when I originally wrote the #buildCodeGeneratorUpTo: method it was intended to do the building of a code generator up to the point where it dealt with the class passed in as the arg - normally this was the actual plugin class but for some special cases I needed to do the basics and then futz around, so by passing in InterpreterPlugin it stopped before the futzing. Eliot???s code uses the same message to deal with all the classes *from* the receiver plugin class *up to* Object or VMClass and ignores the argument (naughty, naughty).
> 
> It looks like theB3D plugin hasn???t really kept up and this is the cause of the confusion. I note that it also gets the moduleName wrong and we???re building a module that thinks it is named B3DPluginEngine in a plugin call Squeak3D. Oh dear.
>

For sure, the methods we're looking at here are pretty ancient. So it's
possible that some minor updates may be in order ;-)

I don't see the problem with moduleName though, it looks ok to me?
 
> I???ll see if I can tidy it up tomorrow.
>

Thanks!

Dave