Hi Tim,
The latest update in Balloon3D-Plugins-tpr.9 breaks code generation for VMM trunk. A fixed version is attached.
This keeps your changes for #inferTypesForImplicitlyTypedVariablesAndMethods and #pruneUnusedInterpreterPluginMethodsIn: but reverts the change that removed B3DEnginePlugin from the classes being added to the code generator (I am not sure if that was just a mistake or if there is something different about how the code generator is being assembled on oscog).
I can confirm that this works again on VMM trunk but I can't easily check it on oscog right now. Can you please review and commit back to the Balloon3D repository as needed (I don't have write access).
Note, there is a monitor job at http://build.squeak.org/job/InterpreterVM/ that should turn green again once this update is done.
Thanks, Dave
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.
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.
What is the error you get? I just don’t seem to get one!
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: JSP: Jump on Sexy Programmer
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.
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.
What is the error you get? I just don???t seem to get one!
Compile time errors look like this (small sample):
[ 33%] Building C object Squeak3D/CMakeFiles/Squeak3D.dir/home/lewis/squeak/VMM-20150614/src/plugins/Squeak3D/Squeak3D.c.o /home/lewis/squeak/VMM-20150614/src/plugins/Squeak3D/Squeak3D.c: In function ‘analyzeMatrix’: /home/lewis/squeak/VMM-20150614/src/plugins/Squeak3D/Squeak3D.c:172:19: error: ‘FlagM44NoPerspective’ undeclared (first use in this function) flags = flags | FlagM44NoPerspective; ^ /home/lewis/squeak/VMM-20150614/src/plugins/Squeak3D/Squeak3D.c:172:19: note: each undeclared identifier is reported only once for each function it appears in /home/lewis/squeak/VMM-20150614/src/plugins/Squeak3D/Squeak3D.c:177:20: error: ‘FlagM44NoTranslation’ undeclared (first use in this function) flags = flags | FlagM44NoTranslation; ^ /home/lewis/squeak/VMM-20150614/src/plugins/Squeak3D/Squeak3D.c:179:21: error: ‘FlagM44Identity’ undeclared (first use in this function) flags = flags | FlagM44Identity; ^
Those errors are caused by missing static declarations for e.g. FlagM44NoPerspective, presumably caused by B3DEngineConstants not being included in the code generator, probably because B3DEnginePlugin was not added to the code generator.
We must be overlooking something here. I don't see how this could possibly have worked, but you are apparently getting generated code that differs only by time stamp. What are we missing?
Dave
On 02-12-2015, at 9:22 PM, David T. Lewis lewis@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.
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.
I’ll see if I can tidy it up tomorrow.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RC: Rewind Core
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@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
On 03-12-2015, at 5:37 AM, David T. Lewis lewis@mail.msen.com wrote:
For sure, the methods we're looking at here are pretty ancient. So it's possible that some minor updates may be in order ;-)
Fortunately it looks like very few. So far.
I don't see the problem with moduleName though, it looks ok to me?
It was sticking the plugin class name in instead of the chosen module name; a good place to cause confusion when tracking down problems.
I’ve committed a change to the Balloon3D plugin that looks ok to me, next up is a couple of changes to the cog vmmaker to make that happy.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SHP: Solve Halting Problem
On Thu, Dec 03, 2015 at 11:41:20AM -0800, tim Rowledge wrote:
On 03-12-2015, at 5:37 AM, David T. Lewis lewis@mail.msen.com wrote:
For sure, the methods we're looking at here are pretty ancient. So it's possible that some minor updates may be in order ;-)
Fortunately it looks like very few. So far.
I don't see the problem with moduleName though, it looks ok to me?
It was sticking the plugin class name in instead of the chosen module name; a good place to cause confusion when tracking down problems.
I???ve committed a change to the Balloon3D plugin that looks ok to me, next up is a couple of changes to the cog vmmaker to make that happy.
Confirming, the generated code looks good and trunk VMM is happy.
Dave
vm-dev@lists.squeakfoundation.org
-
David T. Lewis -
tim Rowledge