Andreas,

Ok, I got this working finally -- I have a 3.8b4 VM. I found a post on the web that mentions the last change for "getImageName" that I needed to make can be changed in Slang ... where do I find the slang? I've looked around for a bit, and seem to be unable to locate it.

Thanks for the assistance.

-- dave

-----Original Message----- From: vm-dev-bounces@lists.squeakfoundation.org [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of Andreas Raab Sent: Friday, October 06, 2006 12:44 PM To: Squeak Virtual Machine Development Discussion Subject: Re: [Vm-dev] hacking a 3.9 VM

Did you go "by the book"?

http://squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/win32/HowToBuild .txt?rev=1530

If so, let me know what didn't work.

Cheers, - Andreas

Raymer David-fdr017 wrote:

------------------------------------------------------------------------

Gentlebeings,

First off, I would like establish that I'm brand new to squeak - I'd like to use it to develop some prototypes of my research work; and to

do

that I'm going to have get into the depths of VM. I seem to have encountered my first Balrog ...

I thought that I would start with building my own 3.9 VM (nothing like

putting something together to figure out how it works). So I grabbed the latest from SVN (after looking at the branches and tags, I did not

see a 3.9 "approved" fileset). I tried to build this ... and failed.

So, I then tried using VMMaker 3.8b6, the 3.9g-7061 image, on a 3.7

VM.

This gave me the files I was missing and after adding a few forward declarations into the win32/vm fileset, I have that building. Things were going quite well until the B3DAcceleratorPlugin. I seem to be getting lots and lots and lots of "implicit function declarations" in OpenGL and DX7 (d3) functions.

Can someone throw me a bone on how to go about building a 3.9 VM for a

Win32 platform?

Dave Raymer Motorola Labs, NSR CoE, NIRL Autonomics Research Distinguished Member of the Technical Staff +1-(817)-245-6834

Michael,

Thanks -- the link to the details is what I needed.

-- dave

On 10/6/06, Michael Haupt mhaupt@gmail.com wrote:

Hi Dave,

On 10/6/06, Raymer David-fdr017 David.Raymer@motorola.com wrote:

...

Ok, I got this working finally -- I have a 3.8b4 VM. I found a post on the web that mentions the last change for "getImageName" that I needed to make can be changed in Slang ... where do I find the slang? I've looked around for a bit, and seem to be unable to locate it.

"Slang" is the name for a subset of Squeak Smalltalk. It is tailored to be easily translatable to C. In Slang, the VM (Interpreter, ObjectMemory, ...) is implemented. VMMaker is used to generate C code, which can then be compiled - but you know this last bit.

Details? http://minnow.cc.gatech.edu/squeak/2267 :-)

I don't know where to look for "getImageName" in particular, so I cannot help you with that one, sorry. (I haven't found it in the image I have at hand.)

Best,

Michael

On 6-Oct-06, at 4:52 PM, Craig Latta wrote:

 There's no Slang for getImageName, that's part of the

platform-specific support (which is generally handwritten C). On Unix, for example, it's in sqUnixMain.c

Andreas, perhaps you could do me a small favour and stick a revision of the appropriate windows file into the http://www.squeakvm.org/cgi- bin/viewcvs.cgi/branches/VMM38b4/win32/vm/ slot? It would save explaining again and again. Actually I can't find an implementation in any of the current windows files either - how are you making it compile in that case?

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Looks for the "Any" key.

On 6-Oct-06, at 5:33 PM, Andreas Raab wrote:

Actually, I have only built VMs against the Croquet code base recently. If you point me to the latest (3.9 scheduled) VMMaker I'll give it a go on the weekend.

OK, just use the 3.8-b6 package on SM for now.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: PSM: Print and SMear

On 7-Oct-06, at 1:09 AM, Andreas Raab wrote:

tim Rowledge wrote:

...

On 6-Oct-06, at 5:33 PM, Andreas Raab wrote:

...

Actually, I have only built VMs against the Croquet code base recently. If you point me to the latest (3.9 scheduled) VMMaker I'll give it a go on the weekend.

OK, just use the 3.8-b6 package on SM for now.

When I do this I have a few strange issues: First, there isn't any getImageName in that code (where does that come from?)

That was exactly the bit I was hoping you'd add so that other people can just compile out of the box :-) It's a trivial function in a platform c file (see sqMacEncoding.c for the most complicated version) that I expect you can implement as char *getImageName(void) { return imageName; } but it allows a convenient place to do any required name massaging that the platform wants. I'd hazard a guess that you'd put it in sqWin32Utils.c for example.

and second, cc1 explodes in my face when trying to compile either B3DAcceleratorPlugin.c or JoystickTabletPlugin.c. Anyone having ideas what might cause this?

All I can tell you there is that both appear to compile ok on OSX and the tablet plugin is ok on RISC OS (no b3d accel there).

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Meets quality standards: It compiles without errors.

Well Tim forgets that on the mac that the image name is UTF-8 and it has to be translated into the character set the VM is using, simply returning the string *might* be good enuf, (sp). However likely that might not work well in Japan.

sq.h has

/* Image file and VM path names. */ extern char imageName[]; char *getImageName(void);

However it seems the interp C code has lapsed back into referring directly to the imageName string. likely no one has tested this for a few years, but as a backwared compatible step the imageName string is setup when the imagename is calculated which is why it works.

On 7-Oct-06, at 12:55 PM, Andreas Raab wrote:

tim Rowledge wrote:

...

...

When I do this I have a few strange issues: First, there isn't any getImageName in that code (where does that come from?)

That was exactly the bit I was hoping you'd add so that other people can just compile out of the box :-)

Sorry, but I mean the opposite: There doesn't seem to be any reference to getImageName in the VMMaker generated sources. If I grep interp.c for getImageName it comes up empty, and I don't get any link errors either. Put differently, the current sources compile just fine except from the two plugins exploding in my face.

...

All I can tell you there is that both appear to compile ok on OSX and the tablet plugin is ok on RISC OS (no b3d accel there).

Odd.

Cheers,

• Andreas

-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

Well someone build a mac vm a few weeks back and as far as I know...

0. Grab your 3.8.1 image, install Balloon 3D, and then install version 3.8b6 of VMMaker, from http://map.squeak.org/accountbyid/ 4340a66e-2296-48b7-9aa8-5305d303752f/files/VMMaker-3.8b6.mcz or later...

When this loads rely yes to move FloatProto to Undeclared. Now load the following two change sets found in the specialChangeSets folder. Note these might be in the VMMaker update since this doc was written, check the change set and the image after loading VMMaker to see if you need these items.

load VMM38-gc-instrument-image.1.cs load VMM38-64bit-imageUpdates.1.cs

That should provide a version of VMMaker that is sufficient to build 3.8.12b5U

On 7-Oct-06, at 6:04 PM, Andreas Raab wrote:

Hm ... trying to go back to 3.8 to see if the problem is caused by 64bit updates wasn't successful either. First I updated to 3.8.1 which loads 6735RemoveLeftoverVMMakerBits-38b4 and thusly removes a whole bunch of methods that are required by the version in the released 3.8 version. After noticing this (the hard way) I loaded VMMaker-38b4 which I thought would include these methods but it doesn't. Okay, so I reverted to 3.8-6665 to generate the VM, only to run into one of those (foo isMemberOf: Symbol) issues from the post-m17n transition phase. That fixed I was almost capable of generating a new VM only to notice that you mustn't have the VMMaker tool or else loading a new Win32VMMaker class is being ignored. Took me a while to find that.

Finally, I was able to generate a new VM but failed immediately with compiling it because of conflicting definitions of byteAt: etc. So after spending a couple of hours on this I still don't know what causes these crashes.

Argh. This is a lot worse than I remembered.

Cheers,

• Andreas

Andreas Raab wrote:

...

tim Rowledge wrote:

...

...

When I do this I have a few strange issues: First, there isn't any getImageName in that code (where does that come from?)

That was exactly the bit I was hoping you'd add so that other people can just compile out of the box :-)

Sorry, but I mean the opposite: There doesn't seem to be any reference to getImageName in the VMMaker generated sources. If I grep interp.c for getImageName it comes up empty, and I don't get any link errors either. Put differently, the current sources compile just fine except from the two plugins exploding in my face.

...

All I can tell you there is that both appear to compile ok on OSX and the tablet plugin is ok on RISC OS (no b3d accel there).

Odd. Cheers,

• Andreas

-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

Well, I'm startled at the problems we seem to be having here. Obviously, as I was developing various versions of VMMaker I was actually running them and building VMs. Clearly, I wouldn't have deliberately released something that didn't work when testing it. However, do remember that I do not have a Windows machine nor a *nix machine so can't do anything but rely on others to test and report back in a timely manner. IIRC, Dave Lewis for example has not had problems with building *nix VMs recently.

Looking back in my history files, it is clear that VMMaker38b4 had the getImageName call in it. If you use the VMMaker38b4 branch from SVN and add the trivial char *getImageName(void) { return imageName; } it *really* ought to work - obviously with your old build setup. This was the last pre-64bit work version. I've got a number of emails from around that date from people that were able to build a vm then, so it must have been reasonably ok at some point.

Moving forward in time, to my annoyance I see that when I loaded Ian's 64 bit changes *last April* the copy of Interpreter>snapshot: sucked in reverted from using getImageName: to just referring to the global 'imageName'. So since then Macs haven't been able to do the character set conversion done by getImageNameWithEncoding(char *target,UInt32 encoding). I wonder if that has caused any bugs? So any release after that (ie 3.8b5-64, 3.8b5-64B and 3.8b6) should compile without requiring the presence of getImageName unless it is used in any platform code or whatever - which is the case for mac and RISC OS.

On 7-Oct-06, at 6:04 PM, Andreas Raab wrote:

Hm ... trying to go back to 3.8 to see if the problem is caused by 64bit updates wasn't successful either. First I updated to 3.8.1 which loads 6735RemoveLeftoverVMMakerBits-38b4 and thusly removes a whole bunch of methods that are required by the version in the released 3.8 version.

Yah, which unfortunately means you would have to reload the vmmaker package. Or better yet, start from a 3.8.1 and then load vmmaker3.8b6

After noticing this (the hard way) I loaded VMMaker-38b4 which I thought would include these methods but it doesn't.

Which is exactly why they were moved into the vmmaker package for 3.8b6, which meant of course that they needed to be removed from the basic image, which lead to 6735RemoveLeftoverVMMakerBits-38b4 being part of 3.8.1. The combination of a MC package and a changeset update doesn't work as cleverly as we might dream.

Okay, so I reverted to 3.8-6665 to generate the VM, only to run into one of those (foo isMemberOf: Symbol) issues from the post- m17n transition phase.

I very vaguely recall some of that but don't seem to have any record of details. I thought it had been fixed before the 3.8 release?

That fixed I was almost capable of generating a new VM only to notice that you mustn't have the VMMaker tool or else loading a new Win32VMMaker class is being ignored. Took me a while to find that.

Is this the new Win32VMMaker class to support your new build setup? I haven't had an opportunity to do anything with that yet.

Finally, I was able to generate a new VM but failed immediately with compiling it because of conflicting definitions of byteAt: etc.

Never seen that issue. Did it tell you where the conflicting versions are and what they are?

What should work as the cannonical approach is run 3.8.1 load vmmaker3.8b6 run vmmaker compile

It works on RISC OS and so as I can tell on OSX - since john has been building vms - and apparently on unix - since Dave L has been building vms. I think the ball got away from us collectively about last june, as everyone scattered off doing more urgent seeming work items. I certainly haven't had any available time since around then.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: EFB: Emulate Five-volt Battery mode

On 8-Oct-06, at 10:11 AM, Craig Latta wrote:

Hi Tim--

...

However, do remember that I do not have a Windows machine nor a *nix machine so can't do anything but rely on others to test and report back in a timely manner.

 I thought you had a MacOSX machine?

True - now. At the time the last lot of vm development was done I didn't, so, yes I should modify that statement. And I know that underneath OSX lurks a form of *nix but I'm not about to try compiling VMs suitable for dedian or whatever; I simply don't have time to worry about everything. Besides, if nobody else is interested enough to assist on such things we might as well just drop the project altogether.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Cave ne ante ullas catapultas ambules = If I were you, I wouldn't walk in front of any catapults.

On 8-Oct-06, at 10:28 AM, David T. Lewis wrote:

I have not done a Unix build since SVN 1513, so I decided to give it a try. Somewhere between 1513 and 1546, a new problem seems to have crept in.

Sigh.

Verifying on a 32 bit Intel Linux:

start with a clean Squeak 3.8 (Squeak3.8-6665-basic.zip) update to 3.8.1 check version ==> SmalltalkImage current (sic) vmVersion 'Squeak3.8 of ''5 May 2005'' [latest update: #6665]'

Well that's the version of the vm you are running on so it isn't a problem. Does the image version provide the right answer ie 3.81 and update 6747 ?

update Squeak Map etc load VMMaker 3.8b6 from SM load OSProcessPlugin 4.0.1 from SM load AioPlugin 2.0 from SM ==> %$%#$! SqueakMap gives user-friendly "can't find EOCD position" error loaded my own copy from disk load XDisplayControlPlugin 2.0 from SM ==> another $#!%@$% SqueakMap error loaded my own copy from disk get an up-to-date platforms tree from SVN (1546) open VMMaker ==> MessageNotUnderstood: SystemDictionary>>wordSize load a copy of #wordSize from a 3.9 image enter Mantis 5198 to get #wordSize included in the next 3.8 release

OK, that ought to have been fixed by the update to 3.8.1 I see it in update 6669VMM38-64bit-imageUpdates.

open VMMaker make all plugins internal except OSPP, AIO, XDCP generate 32 bit code into ./src32 directory

then from a Unix shell: $ ln -s src32 src $ mkdir build32 $ cd build32 $ ../platforms/unix/config/configure $ make install ==> no problems with build, but... run Squeak ==> image startup fails in FileDirectory class>>startUp fails primitive in MacHFSPlusFileDirectory class>>primPathNameDelimiter check "Smalltalk listLoadedModules" ==> FilePlugin is not loaded ==> hmmm... no wonder, VMM did not include it in the plugins to be built. Lots of other primitives were excluded also.

Check Smalltalk listBuiltinModules to see if the plugin was actually included. Remember, load means loaded and in use. If there is a problem that prevents loading it will be in one list and not the other. Made that mistake myself a few times.

In VMMakerTool if you use the menu option to 'make all internal' does the FilePlugin end up in the right list? If not, then perhaps some directory has got lost in some code reshuffle between svn 1513 and 1546?

tim PS uncannily good sigline chosen by that 'random' generator. -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim In the long run, every program becomes rococco, and then rubble.

On 8-Oct-06, at 11:55 AM, David T. Lewis wrote:

I swear I did not imagine this, but the weather is too nice this afternoon to waste any time trying to reproduce it again. I think I'll just write it off to a tempory warp in the bogon flux density caused by sunspot activity and a full moon. Sorry for the confusion, everything looks fine now.

Time to take the Norton out for a ride before the cold weather sets in.

Excellent idea. I spent the afternoon flying my little Extra 300 model. Much more fun than worrying about software.

I really can't think why FilePlugin would get left out though. The only easily imaginable reason is that somehow VMM couldn't see the Cross or Unix directory for FilePlugin. That might possibly happen if you were hit by that uniquely (I hope) silly unixism of the stale directory handle. By pointing somewhere else and doing other stuff yo uwould likely have triggered enough gcs to have killed the old handle and then re-opened it later with fresh files. Or maybe you just burped at the wrong time.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim On Doc: http://www.poppyfields.net/filks/00281.html

On 9-Oct-06, at 9:10 PM, Andreas Raab wrote: [snip]

Right. But it seems as if the post-64bit world is not (compile) compatible with the pre-64bit world which I had assumed (the differences in byteAt: etc). Unfortunately, to get the new build setup working with the old snapshots is more work than I'd like to invest right now.

Do you have an old build setup anywhere? It would be really nice to be able to finish off a 3.8b4 (ie pre 64 bit work) vmmaker/build world and be able to point newcomer vm builders to it as stable starting point. I *think* all it really needs is that getImageName() and some testing.

The later 3.8b6 would be better thought of as a staring point for the 3.9 vm and sometime I want to get your win32 subclass change etc integrated.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Overdue for deincarnation.

Hi Dave,

on Fri, 06 Oct 2006 22:28:02 +0200, you wrote:

Andreas,

Ok, I got this working finally -- I have a 3.8b4 VM. I found a post on the web that mentions the last change for "getImageName" that I needed to make can be changed in Slang ... where do I find the slang?

You can replace the "getImageName()" call in Interpreter>>#snapshot: and in Interpreter>>#writeImageFile: by "imageName" without parentheses. The affected expressions are Mac-only (they are noop on win32), the replacement makes them compile error-free on win32.

/Klaus

I've looked around for a bit, and seem to be unable to locate it.

Thanks for the assistance.

-- dave

-----Original Message----- From: vm-dev-bounces@lists.squeakfoundation.org [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of Andreas Raab Sent: Friday, October 06, 2006 12:44 PM To: Squeak Virtual Machine Development Discussion Subject: Re: [Vm-dev] hacking a 3.9 VM

Did you go "by the book"?

http://squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/win32/HowToBuild .txt?rev=1530

If so, let me know what didn't work.

Cheers,

• Andreas

Raymer David-fdr017 wrote:

...

---

...

Gentlebeings,

First off, I would like establish that I'm brand new to squeak - I'd like to use it to develop some prototypes of my research work; and to

do

...

that I'm going to have get into the depths of VM. I seem to have encountered my first Balrog ...

I thought that I would start with building my own 3.9 VM (nothing like

...

putting something together to figure out how it works). So I grabbed the latest from SVN (after looking at the branches and tags, I did not

...

see a 3.9 "approved" fileset). I tried to build this ... and failed.

So, I then tried using VMMaker 3.8b6, the 3.9g-7061 image, on a 3.7

VM.

...

This gave me the files I was missing and after adding a few forward declarations into the win32/vm fileset, I have that building. Things were going quite well until the B3DAcceleratorPlugin. I seem to be getting lots and lots and lots of "implicit function declarations" in OpenGL and DX7 (d3) functions.

Can someone throw me a bone on how to go about building a 3.9 VM for a

...

Win32 platform?

Dave Raymer Motorola Labs, NSR CoE, NIRL Autonomics Research Distinguished Member of the Technical Staff +1-(817)-245-6834