I've downloaded the current SVN sources and VMMaker (3.8b3) from SqueakMap and am unable to the build a working VM. This may be the result of changes going into the source tree and me taking a snapshot that just doesn't build.
Anyhow, these are the problems I'm facing and in the past I've been able to successfully build a working VM. I'm building a Carbon VM on Mac OS X 10.4.2 using XCode, I'm able to compile and link but get a runtime error for "getThisSessionID" as an undefined symbol.
When I try to build a unix VM, I get the following undefined symbols:
_dispatchFunctionPointer _dispatchFunctionPointerOnin _fetchLong32ofObject _getThisSessionID _obsoleteDontUseThisFetchWordofObject
I also had to manually tweak the code in order to get it to compile by adding the following to Cross/vm/sq.h
typedef int (*fptr) (void);
I'm not able to get an interp.h generated at all. I have to manually create it to get away from the warnings. At first I thought there was a problem with my image but I downloaded a fresh 3.8 image, added Balloon and VMMaker and tried to build. Same errors.
If anyone can shed some light on how I can proceed, it's greatly appreciated otherwise I'm quite happy to wait for a stable snapshot of the source tree.
-- Sachin.
It's real simple.
The VM had has its hood open and the engine is scattered around the workshop floor. There is a bunch of stuff to do. Right now the VMMaker on SM is not the 'latest' one and does not match the 'latest' SVN tree. At some point it will get cleaned up and put back together.
The VMMaker on SM that is 'official' (in as much as anything is official in this utterly screwed up world) is VMMaker38b3.mcz and matches SVN level 1105. Ideally there would be a simple release package that tied each version of VMMaker with a suitable CVN release. I don't have time to learn how to do that right now.
In the meantime if you use
svn checkout http://squeak.hpl.hp.com/svn/squeak/trunk/platforms -- revision 1105
you will get the right set of files.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Useful random insult:- His data bus stops for red lights.
On Wed, Jul 20, 2005 at 12:18:20PM -0700, Tim Rowledge wrote:
It's real simple.
The VM had has its hood open and the engine is scattered around the workshop floor. There is a bunch of stuff to do. Right now the VMMaker on SM is not the 'latest' one and does not match the 'latest' SVN tree. At some point it will get cleaned up and put back together.
The VMMaker on SM that is 'official' (in as much as anything is official in this utterly screwed up world) is VMMaker38b3.mcz and matches SVN level 1105. Ideally there would be a simple release package that tied each version of VMMaker with a suitable CVN release. I don't have time to learn how to do that right now.
In the meantime if you use
svn checkout http://squeak.hpl.hp.com/svn/squeak/trunk/platforms -- revision 1105
you will get the right set of files.
tim
Is this the right procedure for all platforms, or just Mac? Specifically, I'm intersted in building for Linux. VMMaker38b3.mcz does not sound as if it's intended for Unix :)
Ross
Ross Boylan RossBoylan@stanfordalumni.org wrote:
Is this the right procedure for all platforms, or just Mac? Specifically, I'm intersted in building for Linux. VMMaker38b3.mcz does not sound as if it's intended for Unix :)
VMMaker is never, ever, ever, meant for any one platform.
I build VMMaker on my RISC OS machine, test it as much as I can and release a version to the main port team. If I get no complaints I put it on SM. As we move ahead there tend to be periods where the public version and development version(s) get out of step but really, what else could one expect? At some point we will almost certainly be doing an atomic blast change that will mean having to have new VMS and images that match. It isn't possible (or practical) to do everything completely backward compatibly. We're probably going to move everything over to java syntax soon.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Useful random insult:- Lights are on but nobody's home.
On Wed, Jul 20, 2005 at 01:42:25PM -0700, Tim Rowledge wrote:
Ross Boylan RossBoylan@stanfordalumni.org wrote:
Is this the right procedure for all platforms, or just Mac? Specifically, I'm intersted in building for Linux. VMMaker38b3.mcz does not sound as if it's intended for Unix :)
VMMaker is never, ever, ever, meant for any one platform.
My question concerned the svn repository and revision, as well as the use of VMMaker. I was under the impression that the appropriate code for some platforms, including *nix (excepting Mac OS X), needed to be retrieved from a separate location than the main sources. Is that impression incorrect?
Also, even if the code is in one spot, a particular revision might work for some platforms and not others.
Finally, on VMMaker itself, I was focused more on the packaging. A .mcz file is for Macs, I think.
I build VMMaker on my RISC OS machine, test it as much as I can and release a version to the main port team. If I get no complaints I put it on SM. As we move ahead there tend to be periods where the public version and development version(s) get out of step but really, what else could one expect? At some point we will almost certainly be doing an atomic blast change that will mean having to have new VMS and images that match.
I count at least 4 components: VMMaker, the out of image source code, the VM, and the image. Maybe with the latest packaging the in-image interpreter/source code makes a 5th component.
It's not obvious to me what combinations are appropriate. I'm also a bit fuzzy on where to get them.
It isn't possible (or practical) to do everything completely backward compatibly. We're probably going to move everything over to java syntax soon.
The first sentence makes sense on general terms, but I'm not sure what these two sentences refer to. Maybe it's just saying that, for any of the 4 or 5 components listed earlier, it won't work with arbitrarily old versions of the other components? I'm guessing the reference to java is a joke, but I'm not sure.
It's not obvious to me what combinations are appropriate. I'm also a bit fuzzy on where to get them.
If you just want to run squeak on a 32-bit platform, get the 3.7-7 sources from the unix main page and compile it with gcc-3.3.6 (later versions (eg 3.4.4) are fantasticly, stupendously slow...)
If you want a working development snapshot. get in line. =(
The first sentence makes sense on general terms, but I'm not sure what these two sentences refer to. Maybe it's just saying that, for any of the 4 or 5 components listed earlier, it won't work with arbitrarily old versions of the other components? I'm guessing the reference to java is a joke, but I'm not sure.
Ross Boylan RossBoylan@stanfordalumni.org wrote:
My question concerned the svn repository and revision, as well as the use of VMMaker. I was under the impression that the appropriate code for some platforms, including *nix (excepting Mac OS X), needed to be retrieved from a separate location than the main sources. Is that impression incorrect?
Very. The whole point of having an SVN repository is that all the sources for all the platforms (barring some old, or unsupported or just not harvested yet) should be in one place.
Also, even if the code is in one spot, a particular revision might work for some platforms and not others.
That might end up being true in accidental cases (ie total fuckups) but is not supposed to be so. Remember - the entire point of doing the VM as substantially Slang and having a setup like the SVN repo is that the system is portable.
Finally, on VMMaker itself, I was focused more on the packaging. A .mcz file is for Macs, I think.
Where did you get that strange idea from? .mcz is a Monticello package file, platform independent and usable on any machine with MC. How would I be able to produce a Mac specific weirdo file given that I develop on RISC OS? I don't even have XCode on my pBook or pMac - and given what I've seen of it I doubt I ever will. It's a classic case of software gone mad.
I count at least 4 components: VMMaker, the out of image source code, the VM, and the image. Maybe with the latest packaging the in-image interpreter/source code makes a 5th component.
No, 4. The VMMaker package includes all the standard Slang classes. Actually 3 - you should consider the image and any vm that will support it as a single item.
It's not obvious to me what combinations are appropriate. I'm also a bit fuzzy on where to get them.
Cataloguing exactly what image and release of VMMaker go together is likely impossible. Generally, the latest version image with the latest VMMaker is good but sometimes - like now - we are in the middle of complicated work and it gets delicate. That's why the official release is Squeak 3.8, VMMaker 3.8b3 and SVN 1105. I don't like the complication but unless someone wants to pay me fulltime to keep it cleaner and simpler we have to live with it occasionally.
The first sentence makes sense on general terms, but I'm not sure what these two sentences refer to. Maybe it's just saying that, for any of the 4 or 5 components listed earlier, it won't work with arbitrarily old versions of the other components?
Of course. One can put immense amounts of effort into maintaining backwards compatability but at some point it's time to break and make a quantum jump.
I'm guessing the reference to java is a joke, but I'm not sure.
java is always a joke. Java programming is like teenage sex ....
-Everyone talks about it all of the time (but they don't really know what they're talking about); -Everyone claims to be doing it; -Everyone thinks everyone else is doing it; -Those few who are actually doing it: -Are not practicing it safely; -Are doing it poorly, and -Are sure it will be better next time."
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Strange Opcodes: FART: Fill Accumulator from Result if True
On Wed, Jul 20, 2005 at 12:18:20PM -0700, Tim Rowledge wrote:
It's real simple.
The VM had has its hood open and the engine is scattered around the workshop floor. There is a bunch of stuff to do. Right now the VMMaker on SM is not the 'latest' one and does not match the 'latest' SVN tree. At some point it will get cleaned up and put back together.
The VMMaker on SM that is 'official' (in as much as anything is official in this utterly screwed up world) is VMMaker38b3.mcz and matches SVN level 1105. Ideally there would be a simple release package that tied each version of VMMaker with a suitable CVN release. I don't have time to learn how to do that right now.
In the meantime if you use
svn checkout http://squeak.hpl.hp.com/svn/squeak/trunk/platforms -- revision 1105
I originally got interested in building a VM in an attempt to follow John McIntosh's suggestion (July 4 on high CPU useage) to try a newer VM and diagnostic tools. The instructions for that say to use a VM created in June/July 2005 or later using the latest VMMaker.
Unfortunately, revision 1105 is from 19 Mar 2005 according to the log. Probably not coincidentally, that is the date Ian released the version of the VM I am using (3.7-7 in the changelog, though it identifies itself as Smalltalk vmVersion 'Squeak3.8gamma of ''24 November 2004'', consistent with the versioning Lex gave it in the Debian changelog).
Ok, I had thought that Tim had pushed out the changes for VMMaker that are needed by the source tree updates in april/may timeframe. This is not the case.
The 1105 revision point is when Ian started to work on the 32/64 bit logic which needs the VMMaker changes Tim hasn't pushed out yet. So if you get the 1105 tree, although I think it might be the 1100 revision you need since that pre-dates Ian's changes.
Smalltalk vmVersion 'Squeak3.8gamma of ''24 November 2004'', on my working image this right now returns 'Squeak3.8gamma of ''24 November 2004'' [latest update: #6548] Squeak VM 3.8.8b2'
where 'Squeak3.8gamma of ''24 November 2004'' [latest update: #6548] is the image identification and update data put into the VM source code by VMMaker. This information just indicates which image VMMaker was put into. The Squeak VM 3.8.8b2 is the mac carbon VM version number. For the most part, all of the slang code for building the VM comes from the VMMaker package, very little (if any?) from the base image, so if you load into a 3.8 or 3.9 image is immaterial. Historically the slang code was in the base image, so having the image information was useful. Perhaps we need to stuff the VMMaker info into the vmversion string too..
On 20-Jul-05, at 2:40 PM, Ross Boylan wrote:
I originally got interested in building a VM in an attempt to follow John McIntosh's suggestion (July 4 on high CPU useage) to try a newer VM and diagnostic tools. The instructions for that say to use a VM created in June/July 2005 or later using the latest VMMaker.
Unfortunately, revision 1105 is from 19 Mar 2005 according to the log. Probably not coincidentally, that is the date Ian released the version of the VM I am using (3.7-7 in the changelog, though it identifies itself as Smalltalk vmVersion 'Squeak3.8gamma of ''24 November 2004'', consistent with the versioning Lex gave it in the Debian changelog).
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Summary: What do I need to do to build a Linux VM with the new GC stuff? Is that possible as things stand?
I'm on a 32 bit platform (Linux/AMD chip).
On Wed, Jul 20, 2005 at 03:06:13PM -0700, John M McIntosh wrote:
Ok, I had thought that Tim had pushed out the changes for VMMaker that are needed by the source tree updates in april/may timeframe. This is not the case.
Good; that clarifies things.
The 1105 revision point is when Ian started to work on the 32/64 bit logic which needs the VMMaker changes Tim hasn't pushed out yet. So if you get the 1105 tree, although I think it might be the 1100 revision you need since that pre-dates Ian's changes.
"So if you get the 1105 tree," what? The main body of the sentence seems missing.
Smalltalk vmVersion 'Squeak3.8gamma of ''24 November 2004'', on my working image this right now returns 'Squeak3.8gamma of ''24 November 2004'' [latest update: #6548] Squeak VM 3.8.8b2'
I have the same latest update indicated as well.
where 'Squeak3.8gamma of ''24 November 2004'' [latest update: #6548] is the image identification and update data put into the VM source code by VMMaker. This information just indicates which image VMMaker was put into.
So Smalltalk vmVersion is not a particularly good way to tell what version of the vm you are using? Or it used to be, but is not so reliable anymore because the different components have been decoupled? [Oh, you answer that below, and the answer seems to be yes to both questions.]
The Squeak VM 3.8.8b2 is the mac carbon VM version number.
So this is not the version given by Smalltalk vmVersion, but is established by some other convention by the producer(s) of the mac carbon VM (you?)? That makes mapping it to other platforms hard.
Judging by the file dates and changelog dates, the VM I have predates the June or July target you mentioned in the GC work document.
For the most part, all of the slang code for building the VM comes from the VMMaker package, very little (if any?) from the base image,
OK, so the VMMaker package includes VMMaker proper and the slang code, and thus there are not 5 components, as I suspected, but only 4 (VMMaker, image, VM, external sources). That's a little simpler :)
BTW, the packaging is a little surprising, since VMMaker is logically distinct from the smalltalk representation of the VM (and the simulator of same). I gather that historically the latter preceded the former.
so if you load into a 3.8 or 3.9 image is immaterial. Historically the slang code was in the base image, so having the image information was useful. Perhaps we need to stuff the VMMaker info into the vmversion string too..
Where does this leave me with respect to being able to use your garbage collection work? (Maybe that's the missing stuff after the "if you get the 1105 version?).
It sounds as if that stuff is in later versions of the source code, and so isn't too approachable while the engine parts are all over the floor (to borrow Tim's original metaphor).
On 20-Jul-05, at 2:40 PM, Ross Boylan wrote:
I originally got interested in building a VM in an attempt to follow John McIntosh's suggestion (July 4 on high CPU useage) to try a newer VM and diagnostic tools. The instructions for that say to use a VM created in June/July 2005 or later using the latest VMMaker.
Unfortunately, revision 1105 is from 19 Mar 2005 according to the log. Probably not coincidentally, that is the date Ian released the version of the VM I am using (3.7-7 in the changelog, though it identifies itself as Smalltalk vmVersion 'Squeak3.8gamma of ''24 November 2004'', consistent with the versioning Lex gave it in the Debian changelog).
On 20-Jul-05, at 3:56 PM, Ross Boylan wrote:
The 1105 revision point is when Ian started to work on the 32/64 bit logic which needs the VMMaker changes Tim hasn't pushed out yet. So if you get the 1105 tree, although I think it might be the 1100 revision you need since that pre-dates Ian's changes.
"So if you get the 1105 tree," what? The main body of the sentence seems missing.
Tim mentioned 1105, but if you look at the revision update names it seems the last work done before the 64 bit stuff started was revision 1100
Where does this leave me with respect to being able to use your garbage collection work? (Maybe that's the missing stuff after the "if you get the 1105 version?).
It sounds as if that stuff is in later versions of the source code, and so isn't too approachable while the engine parts are all over the floor (to borrow Tim's original metaphor).
I'm looking at taking the Squeak3.8-6665-basic.zip from the ftp site, loading in the latest published VMMaker via squeakmap and applying the GCInstrumentJMMImprovementsAR.1.cs and JMMGCMonitor. 4.cs from ftp.smalltalkconsulting.com/squeakGarbage/ and grabbing the 1100 source tree. Then seeing if I can make it all work. So hang on a moment
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
John M McIntosh johnmci@smalltalkconsulting.com wrote:
On 20-Jul-05, at 3:56 PM, Ross Boylan wrote:
The 1105 revision point is when Ian started to work on the 32/64
bit
logic which needs the VMMaker changes Tim hasn't pushed out yet. So if you get the 1105 tree, although I think it might be the 1100 revision you need since that pre-dates Ian's changes.
"So if you get the 1105 tree," what? The main body of the sentence seems missing.
Tim mentioned 1105, but if you look at the revision update names it seems the last work done before the 64 bit stuff started was revision 1100
All I can do is look at the revision level of the local branch in my 3. 8b3 development directory, which is 1105. That tree doesn't _appear_ to have any of the 64b stuff.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
Ah, but comments made by ian in the revision notes are 1105 64bit cleanliness 1104 temporary 32-bit backwards compatibility 1103 sizes of int, long, long long...
which leads me to believe after 1100 he started messing with things in 64bit ways
On 20-Jul-05, at 5:44 PM, Tim Rowledge wrote:
Tim mentioned 1105, but if you look at the revision update names it seems the last work done before the 64 bit stuff started was revision 1100
All I can do is look at the revision level of the local branch in my 3. 8b3 development directory, which is 1105. That tree doesn't _appear_ to have any of the 64b stuff.
tim
Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Strange OpCodes: DCBP: Detonate Chair on Bad Password
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
John M McIntosh johnmci@smalltalkconsulting.com wrote:
Ah, but comments made by ian in the revision notes are 1105 64bit cleanliness 1104 temporary 32-bit backwards compatibility 1103 sizes of int, long, long long...
I just freshly downloaded 1105 to my machine and I can't see any evidence - no sqMemoryAccess.h etc.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Useful random insult:- One sandwich short of a picnic.
mmm well my svn that is pointing to http://squeak.hpl.hp.com/svn/squeak/trunk/ says that 1104 has one file /trunk/platforms/unix/vm/sqMemoryAccess.h rev 1104 piumarta 6152 bytes March 19th 23:49
On 20-Jul-05, at 6:53 PM, Tim Rowledge wrote:
John M McIntosh johnmci@smalltalkconsulting.com wrote:
Ah, but comments made by ian in the revision notes are 1105 64bit cleanliness 1104 temporary 32-bit backwards compatibility 1103 sizes of int, long, long long...
I just freshly downloaded 1105 to my machine and I can't see any evidence - no sqMemoryAccess.h etc.
tim
Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Useful random insult:- One sandwich short of a picnic.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
John M McIntosh johnmci@smalltalkconsulting.com wrote:
mmm well my svn that is pointing to http://squeak.hpl.hp.com/svn/squeak/trunk/ says that 1104 has one file /trunk/platforms/unix/vm/sqMemoryAccess.h rev 1104 piumarta 6152 bytes March 19th 23:49
OK, I see. Ian put a bunch of stuff in the UNIX subbranch; sqMemoryAccess.h properly belongs in /Cross/vm but there is an 'experimental' version in /unix/vm etc. Sigh. I have no idea why he would do that, but whatever.
VMMaker3.8b3 wouldn't be expecting any of that so it might work it might not, depending upon what is in the assorted unix config/make furball. There is no way I am going to spend any time digging into that particular ratsnest.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Nostalgia: The good old days multiplied by a bad memory...
John M McIntosh johnmci@smalltalkconsulting.com wrote:
mmm well my svn that is pointing to http://squeak.hpl.hp.com/svn/squeak/trunk/ says that 1104 has one file /trunk/platforms/unix/vm/sqMemoryAccess.h rev 1104 piumarta 6152 bytes March 19th 23:49
SVN diff --revision 1100:1105 shows that all changes were in the unix subbranch. So using 1100 would indeed go back to pre-64bit initial changes for all platforms. Perhaps Ian should have put those changes in a branch or something.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Useful random insult:- Has his brain on cruise control again.
On 20-Jul-05, at 5:27 PM, John M McIntosh wrote:
I'm looking at taking the Squeak3.8-6665-basic.zip from the ftp site, loading in the latest published VMMaker via squeakmap and applying the GCInstrumentJMMImprovementsAR.1.cs and JMMGCMonitor. 4.cs from ftp.smalltalkconsulting.com/squeakGarbage/ and grabbing the 1100 source tree. Then seeing if I can make it all work. So hang on a moment
Ok, I did the following a) Use SVN and get the source tree upto revision 1100 b) Grab Squeak3.8-6665-basic.zip from ftp.squeak.org c) Unpacked started up and invoked Squeakmap d) load Balloon3D e) load VMMaker 3.8b3, then apply these vmmaker fixes: f) MessageNode>>asTranslatorNode
sel _ (selector isMemberOf: Symbol) ifTrue: [selector] ifFalse: [selector key].
to
sel _ (selector isSymbol) ifTrue: [selector] ifFalse: [selector key].
g) MiscPrimitivePlugin>> translatedPrimitives Should read: "an assorted list of various primitives" ^#( (Bitmap compress:toByteArray:) (Bitmap decompress:fromByteArray:at:) (Bitmap encodeBytesOf:in:at:) (Bitmap encodeInt:in:at:) (ByteString compare:with:collated:) (ByteString translate:from:to:table:) (ByteString findFirstInString:inSet:startingAt:) (ByteString indexOfAscii:inString:startingAt:) (ByteString findSubstring:in:startingAt:matchTable:) (ByteArray hashBytes:startingWith:) (SampledSound convert8bitSignedFrom:to16Bit:) )
h) If you want to instrument the VM for GC statistics, you can load GCInstrumentJMMImprovementsAR.1.cs and JMMGCMonitor. 4.cs from ftp.smalltalkconsulting.com
i) Open VMMaker and build the VM with plugins you want.
Post building corrections for OS-X gcc 3.3 should be used, not 4.0. If you are using xcode you must set the target application C source file rule to use GCC 3.3 versus the system default of 4.0x if you have xcode 2.x installed. Corrections: MacMenubarPlugin.c has a trailing ';' after the "TARGET_API_MAC_CARBON " you need to delete the ';'. #if TARGET_API_MAC_CARBON;
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
After doing all steps up til the VMMaker run I attempted to save and the image hung. Details below.
On Wed, Jul 20, 2005 at 11:30:46PM -0700, John M McIntosh wrote:
On 20-Jul-05, at 5:27 PM, John M McIntosh wrote:
I'm looking at taking the Squeak3.8-6665-basic.zip from the ftp site, loading in the latest published VMMaker via squeakmap and applying the GCInstrumentJMMImprovementsAR.1.cs and JMMGCMonitor. 4.cs from ftp.smalltalkconsulting.com/squeakGarbage/ and grabbing the 1100 source tree. Then seeing if I can make it all work. So hang on a moment
Ok, I did the following a) Use SVN and get the source tree upto revision 1100 b) Grab Squeak3.8-6665-basic.zip from ftp.squeak.org c) Unpacked started up and invoked Squeakmap d) load Balloon3D
I loaded Balloon3D, though I had already loaded VMMaker.
e) load VMMaker 3.8b3, then apply these vmmaker fixes: f) MessageNode>>asTranslatorNode
sel _ (selector isMemberOf: Symbol) ifTrue: [selector] ifFalse:[selector key].
to
sel _ (selector isSymbol) ifTrue: [selector] ifFalse: [selectorkey].
That's likely the cause of the error I reported in my initial attempt.
g) MiscPrimitivePlugin>> translatedPrimitives Should read: "an assorted list of various primitives" ^#( (Bitmap compress:toByteArray:) (Bitmap decompress:fromByteArray:at:) (Bitmap encodeBytesOf:in:at:) (Bitmap encodeInt:in:at:) (ByteString compare:with:collated:) (ByteString translate:from:to:table:) (ByteString findFirstInString:inSet:startingAt:) (ByteString indexOfAscii:inString:startingAt:) (ByteString findSubstring:in:startingAt:matchTable:) (ByteArray hashBytes:startingWith:) (SampledSound convert8bitSignedFrom:to16Bit:) )
I made this replacement, though I didn't notice any change from the existing method definition.
h) If you want to instrument the VM for GC statistics, you can load GCInstrumentJMMImprovementsAR.1.cs and JMMGCMonitor. 4.cs from ftp.smalltalkconsulting.com
Ah! I thought these were for after the build. Two issues: On file in of GCInstrument... I got a warning about moving a method to underfined, though it was still in use. I think it was proto.... (sorry, didn't write it down, and forgot in the later excitement).
Second, I'll actually be using this in the image that is giving me troubles, which is 3.6 era. If I file JMMGCMonitor there, and use the new VM, should that work.
After doing all that I attempted to save the image. I got the "Error: a primitive has failed". Debug log attached. I hit debug on the resulting panel, but got no response. The image was hung up using alll CPU (roughly half user, half system). Alt-. didn't help.
i) Open VMMaker and build the VM with plugins you want.
Try it again, if on the mac try a 3.7.5x series VM and see if you get different behavior.
On 21-Jul-05, at 9:26 AM, Ross Boylan wrote:
After doing all steps up til the VMMaker run I attempted to save and the image hung. Details below.
On Wed, Jul 20, 2005 at 11:30:46PM -0700, John M McIntosh wrote:
On 20-Jul-05, at 5:27 PM, John M McIntosh wrote:
I'm looking at taking the Squeak3.8-6665-basic.zip from the ftp site, loading in the latest published VMMaker via squeakmap and applying the GCInstrumentJMMImprovementsAR.1.cs and JMMGCMonitor. 4.cs from ftp.smalltalkconsulting.com/squeakGarbage/ and grabbing the 1100 source tree. Then seeing if I can make it all work. So hang on a moment
Ok, I did the following a) Use SVN and get the source tree upto revision 1100 b) Grab Squeak3.8-6665-basic.zip from ftp.squeak.org c) Unpacked started up and invoked Squeakmap d) load Balloon3D
I loaded Balloon3D, though I had already loaded VMMaker.
e) load VMMaker 3.8b3, then apply these vmmaker fixes: f) MessageNode>>asTranslatorNode
sel _ (selector isMemberOf: Symbol) ifTrue: [selector] ifFalse:[selector key].
to
sel _ (selector isSymbol) ifTrue: [selector] ifFalse: [selectorkey].
That's likely the cause of the error I reported in my initial attempt.
g) MiscPrimitivePlugin>> translatedPrimitives Should read: "an assorted list of various primitives" ^#( (Bitmap compress:toByteArray:) (Bitmap decompress:fromByteArray:at:) (Bitmap encodeBytesOf:in:at:) (Bitmap encodeInt:in:at:) (ByteString compare:with:collated:) (ByteString translate:from:to:table:) (ByteString findFirstInString:inSet:startingAt:) (ByteString indexOfAscii:inString:startingAt:) (ByteString findSubstring:in:startingAt:matchTable:) (ByteArray hashBytes:startingWith:) (SampledSound convert8bitSignedFrom:to16Bit:) )
I made this replacement, though I didn't notice any change from the existing method definition.
h) If you want to instrument the VM for GC statistics, you can load GCInstrumentJMMImprovementsAR.1.cs and JMMGCMonitor. 4.cs from ftp.smalltalkconsulting.com
Ah! I thought these were for after the build. Two issues: On file in of GCInstrument... I got a warning about moving a method to underfined, though it was still in use. I think it was proto.... (sorry, didn't write it down, and forgot in the later excitement).
Second, I'll actually be using this in the image that is giving me troubles, which is 3.6 era. If I file JMMGCMonitor there, and use the new VM, should that work.
After doing all that I attempted to save the image. I got the "Error: a primitive has failed". Debug log attached. I hit debug on the resulting panel, but got no response. The image was hung up using alll CPU (roughly half user, half system). Alt-. didn't help.
i) Open VMMaker and build the VM with plugins you want.
<SqueakDebug.log>
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
There is an experimental [1] VMMaker38b4.mcz on my website to try out; it should be used with svn #1100 and Squeak3.8-6665
http://www.rowledge.org/tim/squeak/SqFiles/packages/VMMaker/VMMaker38b4. mcz
If this seems to work I'll SM it as the official 3.8 release. I might even work out how to make a svn branch to pickle it.
[1] X - is the unknown factor peri - is near, or sort of round about mental - guess...
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim "Yummy" said Pooh, as he rotated Piglet slowly on the spit.
Thanks Tim. I downloaded VMMaker and followed John's instructions from an earlier mail and I was able to successfully build a working VM for Mac OSX.
I built the VM using both gcc3.3 and gcc4.0. The one built with gcc3.3 did not perform as well as the 3.7.5Beta3 that I've been using for Croquet, the frame rates were about half that of the 3.7.5 VM and it took a long time for the AnnotationMorph to appear. The one built with gcc4.0 is as fast and seems to be working well.
Thanks very much to the both of you for your help.
-- Sachin.
On Jul 21, 2005, at 4:00 PM, Tim Rowledge wrote:
There is an experimental [1] VMMaker38b4.mcz on my website to try out; it should be used with svn #1100 and Squeak3.8-6665
http://www.rowledge.org/tim/squeak/SqFiles/packages/VMMaker/ VMMaker38b4. mcz
If this seems to work I'll SM it as the official 3.8 release. I might even work out how to make a svn branch to pickle it.
[1] X - is the unknown factor peri - is near, or sort of round about mental - guess...
tim
Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim "Yummy" said Pooh, as he rotated Piglet slowly on the spit.
On 21-Jul-05, at 11:20 PM, Sachin Desai wrote:
Thanks Tim. I downloaded VMMaker and followed John's instructions from an earlier mail and I was able to successfully build a working VM for Mac OSX.
I built the VM using both gcc3.3 and gcc4.0. The one built with gcc3.3 did not perform as well as the 3.7.5Beta3 that I've been using for Croquet, the frame rates were about half that of the 3.7.5 VM and it took a long time for the AnnotationMorph to appear. The one built with gcc4.0 is as fast and seems to be working well.
Thanks very much to the both of you for your help.
-- Sachin.
Did you run the gunify step? If not you will get lousy performance.
GCC 4.0 in my testing produces slower code than 3.3 after you gunify things.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Sachin Desai smdesai@pacbell.net wrote:
Thanks Tim. I downloaded VMMaker and followed John's instructions from an earlier mail and I was able to successfully build a working VM for Mac OSX.
Glad it worked. That's two platforms it is ok on, so if anyone can try a windows or linux buildI can accept it as an improvement and push it to 'official'.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Never do card tricks for the group you play poker with.
Try it again with an earlier linux vm
On 21-Jul-05, at 5:34 PM, Ross Boylan wrote:
On Thu, Jul 21, 2005 at 02:11:28PM -0700, John M McIntosh wrote:
Try it again, if on the mac try a 3.7.5x series VM and see if you get different behavior.
You mean try the exact same thing again? Or try with a different VM? I'm on Linux.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
1. base Squeak3.8-6665 image. 2. open squeakmap 3. load Balloon3D 4. load PackageInfo (apparently update from 16->18). It recommends loading Monticello, which I do (v 231). 4. save image. 5. Open Monticello browser and load VMMaker38b4. 6. save 7. file in GCInstrumentJMMImprovementsAR.1.cs. I get a warning that FloatProto is still used in ObjectMemory. 8. save. 9. file in JMMGCMonitor.4.cs 10. save. Crash. Looks same as before.
Theory: JMMGCMonitor should only be used with VM's built with GCInstrumentJMMImprovementsAR.
So perhaps I should try again, skipping step 9?
And then build the VM? I was not going to do any editing of the VMMaker code in this new version.
What about the FloatProto warning?
The GCInstrumentJMMImprovementsAR, adds changes by myself for GC statistics, and changes by Andreas for Weak Object processing. The FloatProto is removed from the ObjectMemory definition, but you are missing the changes to a class method that deletes it, that change is in unreleased versions of VMMaker.
mmm as for the crash, if you hand edit JMMGCMonitor.4.cs and remove the "Smalltalk recreateSpecialObjectsArray." at the bottom then file in, does it still crash?
On 21-Jul-05, at 11:22 PM, Ross Boylan wrote:
- base Squeak3.8-6665 image.
- open squeakmap
- load Balloon3D
- load PackageInfo (apparently update from 16->18). It recommends
loading Monticello, which I do (v 231). 4. save image. 5. Open Monticello browser and load VMMaker38b4. 6. save 7. file in GCInstrumentJMMImprovementsAR.1.cs. I get a warning that FloatProto is still used in ObjectMemory. 8. save. 9. file in JMMGCMonitor.4.cs 10. save. Crash. Looks same as before.
Theory: JMMGCMonitor should only be used with VM's built with GCInstrumentJMMImprovementsAR.
So perhaps I should try again, skipping step 9?
And then build the VM? I was not going to do any editing of the VMMaker code in this new version.
What about the FloatProto warning?
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
On Thu, Jul 21, 2005 at 11:58:47PM -0700, John M McIntosh wrote:
The GCInstrumentJMMImprovementsAR, adds changes by myself for GC statistics, and changes by Andreas for Weak Object processing. The FloatProto is removed from the ObjectMemory definition, but you are missing the changes to a class method that deletes it, that change is in unreleased versions of VMMaker.
Does this mean the error is safe to ignore, or do I need to do something to deal with the problem? I take it the change is also not in the unreleased tweak to VMMaker that Tim suggested using (38b4).
mmm as for the crash, if you hand edit JMMGCMonitor.4.cs and remove the "Smalltalk recreateSpecialObjectsArray." at the bottom then file in, does it still crash?
I infer that simply not filing this in to the image from which I willl build the new VM is not acceptable, right?
Each attempt takes about 45 minutes, so I'm trying to reduce the number of attempts :(.
On 21-Jul-05, at 11:22 PM, Ross Boylan wrote:
- base Squeak3.8-6665 image.
- open squeakmap
- load Balloon3D
- load PackageInfo (apparently update from 16->18). It recommends
loading Monticello, which I do (v 231). 4. save image. 5. Open Monticello browser and load VMMaker38b4. 6. save 7. file in GCInstrumentJMMImprovementsAR.1.cs. I get a warning that FloatProto is still used in ObjectMemory. 8. save. 9. file in JMMGCMonitor.4.cs 10. save. Crash. Looks same as before.
Theory: JMMGCMonitor should only be used with VM's built with GCInstrumentJMMImprovementsAR.
So perhaps I should try again, skipping step 9?
And then build the VM? I was not going to do any editing of the VMMaker code in this new version.
What about the FloatProto warning?
Ross Boylan RossBoylan@stanfordalumni.org wrote:
[snip]
unreleased tweak to VMMaker that Tim suggested using (38b4).
To be honest I think trying to do too much mix'n'match is just going to be painful. You _could_ try using the VMMaker-tpr.37.mcz from the same place as the b4 but there are a number of changes to the image needed too and they don't appear to have got through the update listing process yet.
[snip]
Each attempt takes about 45 minutes, so I'm trying to reduce the number of attempts :(.
Good grief! What are you running on? A 90MHz 68000?
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim "Bother," said Pooh, as Satan pointed out the fine print...
On Fri, Jul 22, 2005 at 10:10:58AM -0700, Tim Rowledge wrote:
Ross Boylan RossBoylan@stanfordalumni.org wrote:
[snip]
unreleased tweak to VMMaker that Tim suggested using (38b4).
To be honest I think trying to do too much mix'n'match is just going to be painful. You _could_ try using the VMMaker-tpr.37.mcz from the same place as the b4 but there are a number of changes to the image needed too and they don't appear to have got through the update listing process yet.
Are you saying it probably just isn't going to work? Or that it would be better to try VMMaker-tpr.37.mcz?
The cause of my most recent problem seems to be in the garbage collection filein, so there may not be any additional VMMaker problems. Or, I may not have hit them yet...
[snip]
Each attempt takes about 45 minutes, so I'm trying to reduce the number of attempts :(.
Good grief! What are you running on? A 90MHz 68000?
I was kind of suprised how long my machine took just digesting the new modules. I'm on an 800Mhz Athlon--a few years old. 380Mg RAM. Also I'm on dial up. Also that includes reviewing the advice, figuring out where to get the files and what to do, proceeding slowly to find exactly where things go wrong, and writing up the results.
Ross Boylan RossBoylan@stanfordalumni.org wrote:
[snip]
Are you saying it probably just isn't going to work?
It's often very stressful to try to take one level of a package and mix in some code developed on an image with a somewhat later version of the package. It _can_ be done but like a dancing bear it's not som much that it dances well....
Or that it would be better to try VMMaker-tpr.37.mcz?
It would probably be simpler for you right now. Add the two attachments to your 6665 image, then the vmmaker.37, then try it.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim SET DEVICE=EXXON to screw up your environment.
On Fri, Jul 22, 2005 at 05:57:55PM -0700, Tim Rowledge wrote:
Ross Boylan RossBoylan@stanfordalumni.org wrote:
...
Or that it would be better to try VMMaker-tpr.37.mcz?
It would probably be simpler for you right now. Add the two attachments to your 6665 image, then the vmmaker.37, then try it.
Do the "two attachments" refer to the GC stuff? I thought that was a modification to VMMaker, and so should go in afterwords.
I'm going to assume that's a reference to Balloon3D and Monticello.
[replying to my own question] On Sat, Jul 23, 2005 at 08:52:49AM -0700, Ross Boylan wrote:
On Fri, Jul 22, 2005 at 05:57:55PM -0700, Tim Rowledge wrote:
Ross Boylan RossBoylan@stanfordalumni.org wrote:
...
Or that it would be better to try VMMaker-tpr.37.mcz?
It would probably be simpler for you right now. Add the two attachments to your 6665 image, then the vmmaker.37, then try it.
Do the "two attachments" refer to the GC stuff? I thought that was a modification to VMMaker, and so should go in afterwords.
I'm going to assume that's a reference to Balloon3D and Monticello.
Nope: it meant the two attachments in the original message. Seems obvious in retrospect.
And I'm supposed to skip the other GC stuff I had.
Everything you need is in VMMaker-tpr.37.mcz, except I think for the JMMGCMonitor.4.cs which is the interface to collect GC statistics.
Pre VMMaker 37 you needed the GCInstrumentJMMImprovementsAR.1.cs to pickup the changes to the VM, but those got put into the VMMaker 37 stream.
On 23-Jul-05, at 1:53 PM, Ross Boylan wrote:
[replying to my own question] On Sat, Jul 23, 2005 at 08:52:49AM -0700, Ross Boylan wrote:
On Fri, Jul 22, 2005 at 05:57:55PM -0700, Tim Rowledge wrote:
Ross Boylan RossBoylan@stanfordalumni.org wrote:
...
Or that it would be better to try VMMaker-tpr.37.mcz?
It would probably be simpler for you right now. Add the two attachments to your 6665 image, then the vmmaker.37, then try it.
Do the "two attachments" refer to the GC stuff? I thought that was a modification to VMMaker, and so should go in afterwords.
I'm going to assume that's a reference to Balloon3D and Monticello.
Nope: it meant the two attachments in the original message. Seems obvious in retrospect.
And I'm supposed to skip the other GC stuff I had.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
John M McIntosh johnmci@smalltalkconsulting.com wrote:
Everything you need is in VMMaker-tpr.37.mcz, except I think for the JMMGCMonitor.4.cs which is the interface to collect GC statistics.
Well, there's no way a GC monitoring class would end up in VMMaker since it's nothing to do with building a VM. If it's supposed to be a standard part of the system make a Mantis report and ask Doug to push it out as an update. If it's to stay as an addin package, stick it on SM.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Useful random insult:- Has a pulse, but that's about all.
On 22-Jul-05, at 8:28 AM, Ross Boylan wrote:
Does this mean the error is safe to ignore, or do I need to do something to deal with the problem? I take it the change is also not in the unreleased tweak to VMMaker that Tim suggested using (38b4).
This is safe to ignore, however you can first visit
ObjectMemory(class)>>initializeSpecialObjectIndices and delete FloatProto _ 31.
then file things in.
I infer that simply not filing this in to the image from which I willl build the new VM is not acceptable, right?
Each attempt takes about 45 minutes, so I'm trying to reduce the number of attempts :(.
The Smalltalk recreateSpecialObjectsArray was done as part of Andreas' changes for multiple language support, this is already done in 3.8-6665. I suggest removing it to see if the crash you get goes away. -- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Got past some old problems, ran into some new ones. I first tried with the new VMMaker Time suggested. That didn't seem to work, so I tried the old one. It got further, but also gagged.
Again, this is all on Linux.
On Fri, Jul 22, 2005 at 10:14:36AM -0700, John M McIntosh wrote:
The Smalltalk recreateSpecialObjectsArray was done as part of Andreas' changes for multiple language support, this is already done in 3.8-6665. I suggest removing it to see if the crash you get goes away.
It did.
Here's what I did and what happened:
1. base Squeak3.8-6665 image. 2. open squeakmap 3. load Balloon3D (1.0.4) 4. load PackageInfo (apparently update from 16->18). It recommends loading Monticello, which I do (v 231). 5. save image (Back1). 6. edit JMMGCMonitor.4.cs and remove "Smalltalk recreateSpecialObjectsArray." at the bottom. 7. Open Monticello and load VMMaker-tpr.37 8. ObjectMemory(class)>>initializeSpecialObjectIndices does not define FloatProto. 9. save 10. file in GCInstrumentJMMImprovementsAR.1.cs Warning: LongSizeMask is still used in code of class ObjectMemory. Is it oaky to move it to Undeclare? (yes) same for Byte4Shift, ByteMask(I think), Byte6Mask, Byte3Shift, Byte5Mask, Byte1ShiftNegated, Size4Bit, WordMask, ProcessSignalingLowSpace, Byte2Shift, Byte4ShiftNegated, and many more. 11. save. 12. file in JMMGCMonitor.4.cs 13. save. Yea! No crash. 14. open VMMaker. Oops, during opening, in UnixVMMaker(VMMaker)>>initialize, Smalltalk wordsize is not understood.
I think it's time to try the earlier version of VMMaker.
15. open Monticello, unload VMMaker. 16. load VMMaker 38b4 17. delete FloatProto from ObjectMemory(class)>>initializeSpecialObjectIndices. 18. file in GCInstrumentJMMImprovementsAR.1.cs 19. save. 20. file in JMMGCMonitor.4.cs 21. save. 22. Open VMMaker. No problem. Clean out sources. Make all plugins internal (a few aren't appropriate to platform). No platform specific files found for 'HostWindowPlugin' No platform specific files found for 'InternetConfigPlugin' No platform specific files found for 'MacMenubarPlugin' No platform specific files found for 'TestOSAPlugin' No platform specific files found for 'UUIDPlugin' 23. Generate all in VMMaker. Splat!
MessageNotUnderstood: SmallInteger class>>ccgDeclareCForVar: 23 July 2005 9:48:35 am
VM: unix - a SmalltalkImage Image: Squeak3.8 [latest update: #6665]
SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /usr/local/src/squeak Trusted Dir /usr/local/src/squeak/secure Untrusted Dir /usr/local/src/squeak/My Squeak
SmallInteger class(Object)>>doesNotUnderstand: #ccgDeclareCForVar: Receiver: SmallInteger Arguments and temporary variables: aMessage: ccgDeclareCForVar: 'fPosition' Receiver's instance variables: superclass: Integer methodDict: a MethodDictionary(#as31BitSmallInt->a CompiledMethod (1747) #asFlo...etc... format: 2 instanceVariables: nil organization: ('arithmetic' * + - / // \ gcd: quo:) ('bit manipulation' bitAnd...etc... subclasses: nil name: #SmallInteger classPool: a Dictionary() sharedPools: nil environment: nil category: nil
[] in SmartSyntaxPluginTMethod>>handlePrimitiveDirective:on: {[:argName :spec | declarations at: argName put: (spec ccgDeclareCForVar:...]} Arguments and temporary variables: aStmt: self primitive: 'primitiveAsyncFileReadStart' parameters: #(#Oop #SmallI...etc... sStream: a WriteStream #() argName: 'fPosition' spec: SmallInteger expr: nil
OrderedCollection(SequenceableCollection)>>with:do: Receiver: an OrderedCollection('fHandle' 'fPosition' 'count') Arguments and temporary variables: otherCollection: #(Oop SmallInteger SmallInteger) twoArgBlock: [] in SmartSyntaxPluginTMethod>>handlePrimitiveDirective:on: {[:ar...etc... index: 2 indexLimiT: 3 Receiver's instance variables: array: #('fHandle' 'fPosition' 'count') firstIndex: 1 lastIndex: 3
SmartSyntaxPluginTMethod>>handlePrimitiveDirective:on: Receiver: a SmartSyntaxPluginTMethod (primitiveAsyncFileReadStart) Arguments and temporary variables: aStmt: self primitive: 'primitiveAsyncFileReadStart' parameters: #(#Oop #SmallI...etc... sStream: a WriteStream #() argName: 'fPosition' spec: SmallInteger expr: nil Receiver's instance variables: selector: #primitiveAsyncFileReadStart returnType: 'int' args: an OrderedCollection() locals: an OrderedCollection('f' 'fHandle' 'fPosition' 'count') declarations: a Dictionary('f'->'AsyncFile *f' 'fHandle'->'int fHandle' ) primitive: 0 parseTree: [ self primitive: 'primitiveAsyncFileReadStart' parameters: #(#Oop ...etc... labels: an OrderedCollection() possibleSideEffectsCache: nil complete: false export: false static: true sharedLabel: nil sharedCase: nil comment: nil definingClass: nil globalStructureBuildMethodHasFoo: nil isPrimitive: true suppressingFailureGuards: false fullSelector: #primitiveAsyncFileReadStart:fPosition:count: fullArgs: an OrderedCollection('fHandle' 'fPosition' 'count') parmSpecs: #(Oop SmallInteger SmallInteger) rcvrSpec: Oop
--- The full stack --- SmallInteger class(Object)>>doesNotUnderstand: #ccgDeclareCForVar: [] in SmartSyntaxPluginTMethod>>handlePrimitiveDirective:on: {[:argName :spec | declarations at: argName put: (spec ccgDeclareCForVar:...]} OrderedCollection(SequenceableCollection)>>with:do: SmartSyntaxPluginTMethod>>handlePrimitiveDirective:on: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - SmartSyntaxPluginTMethod>>primitiveDirectiveWasHandled:on: [] in SmartSyntaxPluginTMethod>>extractPrimitiveDirectives {[:stmt | (self primitiveDirectiveWasHandled: stmt on: sStream) ifFalse: [s...]} OrderedCollection>>do: [] in SmartSyntaxPluginTMethod>>extractPrimitiveDirectives {[:sStream | parseTree statements do: [:stmt | (self primitiveDirectiveWasH...]} Array class(SequenceableCollection class)>>streamContents: SmartSyntaxPluginTMethod>>extractPrimitiveDirectives SmartSyntaxPluginTMethod>>setSelector:args:locals:block:primitive: MethodNode>>asTranslationMethodOfClass: [] in SmartSyntaxPluginCodeGenerator(CCodeGenerator)>>addClass: {[:sel :i | bar value: i. source := aClass sourceCodeAt: sel. self addMe...]} [] in Set>>doWithIndex: {[:item | aBlock2 value: item value: (index := index + 1)]} Set>>do: Set>>doWithIndex: [] in SmartSyntaxPluginCodeGenerator(CCodeGenerator)>>addClass: {[:bar | aClass selectors doWithIndex: [:sel :i | bar value: i. sour...]} [] in ProgressInitiationException>>defaultMorphicAction {[result := workBlock value: progress]} ...etc...
This is why mix'n'match is so painful...
Ross Boylan RossBoylan@stanfordalumni.org wrote:
Here's what I did and what happened:
- base Squeak3.8-6665 image.
Good.
- open squeakmap
Don't bother
- load Balloon3D (1.0.4)
Load from FileList if you have a local copy. much faster and saves installing SM. Or just leave it out for now. Do you really need it?
- load PackageInfo (apparently update from 16->18). It recommends
loading Monticello, which I do (v 231). don't bother
- save image (Back1).
- edit JMMGCMonitor.4.cs and remove "Smalltalk
recreateSpecialObjectsArray." at the bottom.
Argh! No! Don't go near that file.
- Open Monticello and load VMMaker-tpr.37
Just load it from the FileList, which understand MC files quite adequately.
- ObjectMemory(class)>>initializeSpecialObjectIndices does not define
FloatProto.
You shouldn't see any complaint about this if you just load the VMMaker & B3D stuff. I don't when I do it on a new 6665 image.
- save
- file in GCInstrumentJMMImprovementsAR.1.cs
Warning: LongSizeMask is still used in code of class ObjectMemory. Is it oaky to move it to Undeclare? (yes) same for Byte4Shift, ByteMask(I think), Byte6Mask, Byte3Shift, Byte5Mask, Byte1ShiftNegated, Size4Bit, WordMask, ProcessSignalingLowSpace, Byte2Shift, Byte4ShiftNegated, and many
more. No, don't load this either. That stuff is already in VMMaker.37, properly merged. Mix'n'match pain again.
Don't load this, don't load any of the unix/misc 64bit stuff, nothing. It is all in VMMaker.37 if it is actually needed.
- save.
- file in JMMGCMonitor.4.cs
I doubt it. AIUI that is the image code now in the file I previously sent 'VMM38-gc-instrument-image.1.cs - is this correct John? This code is the methods that make use of the new GC monitoring primitives.
- save. Yea! No crash.
- open VMMaker. Oops, during opening, in
UnixVMMaker(VMMaker)>>initialize, Smalltalk wordsize is not understood.
That's because you need to load the other file I sent, VMM38-64bit- imageUpdates.1.cs first. It is methods that need to go into the main update stream before it is practical to release the VMMaker.37 officially.
_Now_ you can open VMMaker.
On my machine this works perfectly, except for the B3D plugin which hasn't been properly cleaned up for 64 bit clean yet. I'd recommend leaving it out entirely for now.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim A conscience is what hurts when all your other parts feel so good.
On Sat, Jul 23, 2005 at 11:51:11AM -0700, Tim Rowledge wrote:
This is why mix'n'match is so painful...
I'm certainly finding that to be true!
Ross Boylan RossBoylan@stanfordalumni.org wrote:
Here's what I did and what happened:
- base Squeak3.8-6665 image.
Good.
- open squeakmap
Don't bother
- load Balloon3D (1.0.4)
Load from FileList if you have a local copy. much faster and saves installing SM. Or just leave it out for now. Do you really need it?
I think most thing are on my local disk by now. I probably don't need it; I was just following instructions.
- load PackageInfo (apparently update from 16->18). It recommends
loading Monticello, which I do (v 231). don't bother
- save image (Back1).
- edit JMMGCMonitor.4.cs and remove "Smalltalk
recreateSpecialObjectsArray." at the bottom.
Argh! No! Don't go near that file.
Here we come to the nub of the problem. Getting a VM with this stuff in was my original motivation for this odyssey.
Ross Boylan RossBoylan@stanfordalumni.org wrote:
Here we come to the nub of the problem. Getting a VM with this stuff in was my original motivation for this odyssey.
All the VM stuff is already in VMM.37 The only bits you would need to add are the method sto call the prims and I'm pretty sure they're all in the VMM38-gc-instrument-image changeset, unless John knows different.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Useful random insult:- A 3.5-inch drive, but data on punch cards.
Smashing success until I actually tried to make. 1. base Squeak3.8-665 2. load VMMaker-tpr.37. save. 3. load JMMGCMonitor.4.cs. save. 4. VMM38-gc-instrument-image.1.cs. save. 5. VMM38-64bit-imageUpdates.1.cs. save. 6. open VMMaker. make all internal plugins. leave "64 bit VM?" unchecked! save vmmaker.config from VMMaker. 7. generate entire
In configuration, I noticed 2 directory related problems. First, it looks for src, not src32, probably because svn 1100 predates that. I used the config arguments to straighten it out.
Second, my "top" directory is not called platforms. In a couple of instances, the config script generated messages indicating it was still looking there: checking whether doubles are stored in Squeak order... no ../official/unix/config/configure: line 21858: cd: /usr/local/src/squeak/platforms/unix: No such file or directory
checking for FFI support... ../official/unix/config/configure: line 24996: /usr/local/src/squeak/platforms/unix/plugins/SqueakFFIPrims/ffi-config: No such file or directory
The make proper was awash in errors. I don't know if it's the directory problems or a versioning issues: gcc -g -O2 -fomit-frame-pointer -DLSB_FIRST=1 -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN -I/usr/local/src/squeak/bld -I/usr/local/src/squeak/platforms/unix/vm -I/usr/local/src/squeak/platforms/Cross/vm -I/usr/local/src/squeak/src32/vm -c -o interp.o /usr/local/src/squeak/src32/vm/interp.c /usr/local/src/squeak/src32/vm/interp.c:5:16: sq.h: No such file or directory /usr/local/src/squeak/src32/vm/interp.c:7:28: sqMemoryAccess.h: No such file or directory /usr/local/src/squeak/src32/vm/interp.c:9: error: syntax error before "printCallStack" /usr/local/src/squeak/src32/vm/interp.c:9: warning: data definition has no type or storage class /usr/local/src/squeak/src32/vm/interp.c: In function `error': /usr/local/src/squeak/src32/vm/interp.c:13: error: syntax error before "printingStack" [etc]
I was using the remote build style so I had src32/ official/ # usually known as "platforms" bld
So my configure was /usr/local/src/squeak/bld$ time ../official/unix/config/configure --with-src=src32
Ah, more mix'n'match pain I'm afraid.
The VMMaker.37 expects the latest SVN source rather than the 1100 revision.
Ross Boylan RossBoylan@stanfordalumni.org wrote:
Smashing success until I actually tried to make.
- base Squeak3.8-665
- load VMMaker-tpr.37. save.
- load JMMGCMonitor.4.cs. save.
- VMM38-gc-instrument-image.1.cs. save.
- VMM38-64bit-imageUpdates.1.cs. save.
- open VMMaker. make all internal plugins. leave "64 bit VM?" unchecked!
All souinds good so far. You definitely want to leave the 64 bit switch off for now.
save vmmaker.config from VMMaker. 7. generate entire
In configuration, I noticed 2 directory related problems. First, it looks for src, not src32, probably because svn 1100 predates that. I used the config arguments to straighten it out.
This is where the latest SVN revision would make a difference.
Second, my "top" directory is not called platforms. In a couple of instances, the config script generated messages indicating it was still looking there: checking whether doubles are stored in Squeak order... no ../official/unix/config/configure: line 21858: cd:
/usr/local/src/squeak/platforms/unix: No such file or directory Unfortunately at some point a 'standard' has to be assumed for the sake of sanity. I imagine that the unix config can probably twist things suficiently that you could use any directory names and paths but why make life extra difficult?
Update the svn tree to the latest and try again. Isn't this fun?
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim The computer is mightier than the pen, the sword, and usually, the programmer.
Hooray! I got it to build. I haven't tried it yet because I need to tweak the install. Can the executables be run in place without install?
On Sat, Jul 23, 2005 at 09:46:32PM -0700, Tim Rowledge wrote:
Ah, more mix'n'match pain I'm afraid.
The VMMaker.37 expects the latest SVN source rather than the 1100 revision.
I thought the current source wasn't in a buildable state.
Ross Boylan RossBoylan@stanfordalumni.org wrote:
....
Second, my "top" directory is not called platforms. In a couple of instances, the config script generated messages indicating it was still looking there: checking whether doubles are stored in Squeak order... no ../official/unix/config/configure: line 21858: cd:
/usr/local/src/squeak/platforms/unix: No such file or directory Unfortunately at some point a 'standard' has to be assumed for the sake of sanity. I imagine that the unix config can probably twist things suficiently that you could use any directory names and paths but why make life extra difficult?
I tried that (eventually), but unix/doc/HowToBuildFromSource says If you are checking out from a repository, you can call the direcory anything you like; for example:
$ svn co http://squeak.hpl.hp.com/svn/squeak/trunk squeak
Oh, I see: I checked out one level down from that.
Update the svn tree to the latest and try again. Isn't this fun?
tim
Here are the steps, including a false start (just in case it affected subsequent things). It was a continuation of the procedures reported earlier. People looking for a recipe can skip steps 9-13 8. svn update to current version (1233) 9. rm -r bld 10. clean out src32 in VMMaker 11. generate entire (Or should I have redone the plugin creation list? Any changes to that with the new source? I checked after and their didn't seem to be.) 12. configure. same errors as before. 13. make. disaster, as before.
OK, try again.
14. rm -r bld 15. mv official/ platforms # correct my idiosyncratic naming 16. cd bld; ../platforms/unix/config/configure --with-src=src32 No errors! Not sure if --with-src=32 is necessary with the new svn stuff. 17. make. No errors. But I need to reconfigure for proper install.
I reran configure so it would install to a local directory, and then rebuilt and installed (but no make clean--perhaps I should have said reconfigure or something like that at the first step?).
There's some confusion about the .so extensions. It's expecting them (which seems reasonable), but they aren't there.
When I tried to run: /usr/local/src/squeak$ ~/staging/bin/squeak SqueakVM & /usr/local/src/squeak$ could not find display driver vm-display-X11; either: - check that /home/ross/staging/lib/squeak/3.8a-2/vm-display-X11.so exists, or - use the '-plugins <path>' option to tell me where it is, or - remove DISPLAY from your environment. $ls /home/ross/staging/lib/squeak/3.8a-2/ npsqueak.so squeak vm-display-fbdev vm-display-null vm-display-X11 vm-sound-NAS vm-sound-null vm-sound-OSS $ gcc --version gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ libtool --version ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) Debian: 224 $
Copyright (C) 2003 Free Software Foundation, Inc.
Considering the hour, the confusion may be on my part. But it sort of looks as if libtool and the makefile aren't interacting well.
On Sun, Jul 24, 2005 at 12:45:39AM -0700, Ross Boylan wrote:
I reran configure so it would install to a local directory, and then rebuilt and installed (but no make clean--perhaps I should have said reconfigure or something like that at the first step?).
There's some confusion about the .so extensions. It's expecting them (which seems reasonable), but they aren't there.
No problem here, just some misleading messages. On recent Linux (libtool?), the modules don't have the .so extension. This is as it should be.
When I tried to run: /usr/local/src/squeak$ ~/staging/bin/squeak SqueakVM & /usr/local/src/squeak$ could not find display driver vm-display-X11; either:
- check that /home/ross/staging/lib/squeak/3.8a-2/vm-display-X11.so exists, or
- use the '-plugins <path>' option to tell me where it is, or
- remove DISPLAY from your environment.
This is an actual problem in the current SVN sources for Unix. The above error message is misleading; it suggests that the vm-display-X11 is not being loaded. Actually, it *is* being loaded, but is failing due to a missing symbol reference. The patch for the misleading error message is going to be added to the SVN sources, but I suspect that Ian has not yet had an opportunity to do so. I'm less certain about the fix for the actual problem; I've got a working patch that compiles and runs, but I'm not certain that it is correct.
I am attaching a copy of previous messages from the vm-dev list for your reference. These describe pretty much all that I know on the topic right now. Unfortunately, I'm still not able to produce a VM that actually works without crashing, so I'm looking forward to any results you might get.
Also attached are the patch files that I used to a) correct the misleading error message, and b) fix the missing symbol references. There is a screen shot file mentioned in one of the messages that I have not included due to size. I'll mail that to you (Ross) privately so as not to waste space on the list.
Hope this helps.
Dave
Thanks for the info about what's going on. On Sun, Jul 24, 2005 at 08:44:29AM -0400, David T. Lewis wrote: ...
This is an actual problem in the current SVN sources for Unix. The above error message is misleading; it suggests that the vm-display-X11 is not being loaded. Actually, it *is* being loaded, but is failing due to a missing symbol reference. The patch for the misleading error message is going to be added to the SVN sources, but I suspect that Ian has not yet had an opportunity to do so. I'm less certain about the fix for the actual problem; I've got a working patch that compiles and runs, but I'm not certain that it is correct.
Here you say it compiles and runs.
I am attaching a copy of previous messages from the vm-dev list for your reference. These describe pretty much all that I know on the topic right now. Unfortunately, I'm still not able to produce a VM that actually works without crashing, so I'm looking forward to any results you might get.
Here you say it doesn't work.
I'm not following how these statements can both be true, or if there's any reason it would work for me if it doesn't work for you.
Ross
On Sun, Jul 24, 2005 at 10:45:30AM -0700, Ross Boylan wrote:
Thanks for the info about what's going on. On Sun, Jul 24, 2005 at 08:44:29AM -0400, David T. Lewis wrote: ...
This is an actual problem in the current SVN sources for Unix. The above error message is misleading; it suggests that the vm-display-X11 is not being loaded. Actually, it *is* being loaded, but is failing due to a missing symbol reference. The patch for the misleading error message is going to be added to the SVN sources, but I suspect that Ian has not yet had an opportunity to do so. I'm less certain about the fix for the actual problem; I've got a working patch that compiles and runs, but I'm not certain that it is correct.
Here you say it compiles and runs.
I am attaching a copy of previous messages from the vm-dev list for your reference. These describe pretty much all that I know on the topic right now. Unfortunately, I'm still not able to produce a VM that actually works without crashing, so I'm looking forward to any results you might get.
Here you say it doesn't work.
I'm not following how these statements can both be true, or if there's any reason it would work for me if it doesn't work for you.
It compiles and runs, but usually crashes shortly after entering interpret(). Sometimes the display opens fully on the screen, and several Squeak debuggers appear. From there, some things work and some things don't.
There is a somewhat better explanation in the email messages that I attached earlier. I'm attaching the screem shot that I mentioned earlier, which shows a Squeak image that is running but not "working" ;)
Please let me know if you have better luck with it.
Dave
"David T. Lewis" lewis@mail.msen.com wrote:
It compiles and runs, but usually crashes shortly after entering interpret(). Sometimes the display opens fully on the screen, and several Squeak debuggers appear. From there, some things work and some things don't.
This is very weird. I've been running a VM based on the latest (rolling) SVN sources and VMM.35/6/7 for months - or at least, since early june. Maybe it just feels like months...
John has been building functional Mac VMs on the same stuff as well. Could it be more crapulence from gcc? It does seem to be a pretty poor compiler these days.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim I came, I saw, I deleted all your files.
On Sun, Jul 24, 2005 at 03:58:33PM -0700, Tim Rowledge wrote:
"David T. Lewis" lewis@mail.msen.com wrote:
It compiles and runs, but usually crashes shortly after entering interpret(). Sometimes the display opens fully on the screen, and several Squeak debuggers appear. From there, some things work and some things don't.
This is very weird. I've been running a VM based on the latest (rolling) SVN sources and VMM.35/6/7 for months - or at least, since early june. Maybe it just feels like months...
John has been building functional Mac VMs on the same stuff as well. Could it be more crapulence from gcc? It does seem to be a pretty poor compiler these days.
I honestly don't have a clue. But if someone with a generic 32bit Intel Linux box can confirm or deny a successful build, that would be a big help for me.
Dave
David T. Lewis wrote:
I honestly don't have a clue. But if someone with a generic 32bit Intel Linux box can confirm or deny a successful build, that would be a big help for me.
If you can give me a configuration and test procedure, I'll be hapy to try it... (though my hardware is actualy a dual AMD athlon...)
Mmm, yes but I've had the occasional crash either in the incremental GC, or in become. I'm not 100% comfortable with the VM after the 32bit/64bit changes.
It would be interesting to understand why this VM fails, and is it the same as the VM's I'm generating? Perhaps some can zip me the interp.c and email me (not the list) it and I'll compare it to mine.
On 24-Jul-05, at 3:58 PM, Tim Rowledge wrote:
"David T. Lewis" lewis@mail.msen.com wrote:
It compiles and runs, but usually crashes shortly after entering interpret(). Sometimes the display opens fully on the screen, and several Squeak debuggers appear. From there, some things work and some things don't.
This is very weird. I've been running a VM based on the latest (rolling) SVN sources and VMM.35/6/7 for months - or at least, since early june. Maybe it just feels like months...
John has been building functional Mac VMs on the same stuff as well. Could it be more crapulence from gcc? It does seem to be a pretty poor compiler these days.
tim
Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim I came, I saw, I deleted all your files.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
On Wed, Jul 20, 2005 at 03:06:13PM -0700, John M McIntosh wrote:
where 'Squeak3.8gamma of ''24 November 2004'' [latest update: #6548] is the image identification and update data put into the VM source code by VMMaker. This information just indicates which image VMMaker was put into. The Squeak VM 3.8.8b2 is the mac carbon VM version number. For the most part, all of the slang code for building the VM comes from the VMMaker package, very little (if any?) from the base image, so if you load into a 3.8 or 3.9 image is immaterial. Historically the slang code was in the base image, so having the image information was useful. Perhaps we need to stuff the VMMaker info into the vmversion string too..
Very good idea.
Also, it would be nice to track the level of the platform code (SVN version number defined in a header file in ./platforms?), and include that in the vmVersion string. But I don't know how to do this without creating another maintenance chore. Maybe someone can think of a clever SVN hack to make this happen.
Dave
If anyone can shed some light on how I can proceed, it's greatly appreciated otherwise I'm quite happy to wait for a stable snapshot of the source tree.
in the misc directory under your platform source, (in my case platforms/unix/misc ) there are some patches to vmmaker...
The vmmaker shipped with SVN sources is out of sync with the squeakmap sources.
In theory you can uninstall your sources and then file in the vmmaker and patches from that directory.
I tried to file in the patches on top of the current squeak-map sources to no avail.
Alan Grimes alangrimes@starpower.net wrote:
If anyone can shed some light on how I can proceed, it's greatly appreciated otherwise I'm quite happy to wait for a stable snapshot of the source tree.
in the misc directory under your platform source, (in my case platforms/unix/misc ) there are some patches to vmmaker...
a) there are only such files in the unix branch b) they are pretty much completely out of date
The vmmaker shipped with SVN sources is out of sync with the squeakmap sources.
And I've just explained how to get appropriate SVN revision fiels.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Strange OpCodes: BSO: Branch Sort Of
squeak-dev@lists.squeakfoundation.org
-
Alan Grimes -
David T. Lewis -
John M McIntosh -
Ross Boylan -
Sachin Desai -
Tim Rowledge