[Vm-dev] re: hacking a 3.9 VM

[tim Rowledge]

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 at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: EFB: Emulate Five-volt Battery mode