Hi,
I just wanted to check - do I need to do anything to a stock 3.6 image, with all the updates, to build the unix VM re: my last email on the subject.
I've checked out google and found the following changes http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-December/071185....
and am wondering if I need to apply these?
My linker error is undefined reference to `isArray'
and if I grep the sources I get the definitions but not the implementation.
Have I missed something?
Cheers
Mike
On Thursday 01 April 2004 1:03 am, Michael Roberts wrote:
Hi,
I just wanted to check - do I need to do anything to a stock 3.6 image, with all the updates, to build the unix VM re: my last email on the subject.
I've checked out google and found the following changes http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-December/071185 .html
and am wondering if I need to apply these?
My linker error is undefined reference to `isArray'
and if I grep the sources I get the definitions but not the implementation.
Have I missed something?
Hmm... I've been using a possibly newer VMMaker package, it seems.
I'm using http://sumeru.stanford.edu/tim/pooters/SqFiles/packages/VMMaker/VMMaker3-7b1... which requires http://sumeru.stanford.edu/tim/pooters/SqFiles/packages/VMMaker/sqVM.zip and a reasonably recent version of the CVS stuff (I'd try the ned-branch, but that's just me...)
I'm sure Tim can provide his usual sage guidance here (though it may take him a while to translate into Canadian).
Hmm... I've been using a possibly newer VMMaker package, it seems.
I'm using http://sumeru.stanford.edu/tim/pooters/SqFiles/packages/VMMaker/VMMaker3-7b1... which requires http://sumeru.stanford.edu/tim/pooters/SqFiles/packages/VMMaker/sqVM.zip and a reasonably recent version of the CVS stuff (I'd try the ned-branch, but that's just me...)
thanks Ned, I'll have a look at these files. It's not really a problem for me because I already have my own vm that runs 3.7 which I build before these changes came in.
I'd just like us to be able to document the exact steps that are needed to build the VM at any point in time. This needs an FAQ entry. I would also like to write a script that automates this. This could then be run as a test to check that the VM can always be built the documented way.
We have had quite a few questions about the unix VM on the list and this would suggest that we need to improve the process.
Do we need to more generally discuss Unix VM maintenance and production? Is Ian's page a little out of date?
I'm sure Tim can provide his usual sage guidance here (though it may take him a while to translate into Canadian).
:-)
I'm on your ned-branch so that is not the issue. I downloaded the sources that you pointed Peter at and your interp.c has the function in. This will be because you have the correct modifications in your image.
I think I at least need IsArrayVMProxy.cs (5 December 2003, Andreas Raab) which modified InterpreterProxy. I imagine all of Andreas' post needs applying.
I roughly understand the changes but I don't know where these need to go for these to be automatically applied. Should they go into the 3.6 update stream? or are they part of vmmaker? Or do you need to know that they need to be applied by hand?
In general I'd just like to know the correct way to build the unix VM from scratch and I'm happy to document this. I had a look on the wiki but there was nothing obvious.
Is there such a thing as the 'correct' image to use for building the VM. Should the latest stable image always be able to build the next VM?
Cheers
Mike
Michael Roberts mike@mjr104.co.uk wrote:
Hmm... I've been using a possibly newer VMMaker package, it seems.
I'm using http://sumeru.stanford.edu/tim/pooters/SqFiles/packages/VMMaker/VMMaker3-7b1... which requires http://sumeru.stanford.edu/tim/pooters/SqFiles/packages/VMMaker/sqVM.zip and a reasonably recent version of the CVS stuff (I'd try the ned-branch, but that's just me...)
Looks like Ned has built from my not-widely-distributed test package. Since I had little to no access to the net whilst moving country, the copies of sqVirtualMachine* are not suitable to the code generated by the latest VMMaker.
I'd just like us to be able to document the exact steps that are needed to build the VM at any point in time. This needs an FAQ entry.
To the best of my knowledge there is quite a bit of this on the swiki. It might be nice to gather it all together a bit better. A decent single page/few pages could reasonably be included in either the VMMaker package or on the cvs tree.
I would also like to write a script that automates this. This could then be run as a test to check that the VM can always be built the documented way.
As I said yesterday - VMMaker has _always_ been scriptable.
I think I at least need IsArrayVMProxy.cs (5 December 2003, Andreas Raab) which modified InterpreterProxy. I imagine all of Andreas' post needs applying.
It's in VMMaker3-7b1.sar and now in VMMaker3-7b2.sar (and even - I hope - in the monticello VMMAker package on squeaksource) along with:- Second beta release of VMMaker for 3.7. Changes from VMMaker37a2:- Add ClassRefsBrowsingForPlugins ( extends image support for classrefs) Add InterpreterSimulator-primitiveGetAttribute (support Simulator) Add InterpreterSimulator-sqGrowMemoryBy (ditto) Add primYield.1.cs - adds primitive for ProcessorScheduler>yield Add primCopy.1.cs - adds a prim to copy Objects, revised from ar original to make numbered (168) Add SlightlyFasterActivate-JMM.8.cs Add ImageStartupFix-JMM.1.cs - consider doing the object counting for real? Add bytecodePrimPoint-internal-tpr.1.cs - variant of MakePrimPointXInternal-JMM.1.cs Add InterpreterPlugin-halt.st Add isArray stuff - update Cross/vm/sqVirtualMachine.[ch] - IsArrayVM.1.cs - which changes core VM code to use isArray: - IsArrayVMProxy.1.cs - which add isArray to the proxy for simulation - IsArrayPlugins.2.cs - which uses isArray in some plugin code Remove the primitive timing code from primitiveResponse and move it to primitiveExternalCall on the premise that only named prims take along time. To counter this obviously wrong assumption, introduce a new way to call for an interruptCheck asap. Use it in suitable palces. Build a table of the function addresses of all numbered prims and branch to them instead of using a case statement. This required a number of changes to the CCodeGenerator.
I roughly understand the changes but I don't know where these need to go for these to be automatically applied. Should they go into the 3.6 update stream? or are they part of vmmaker? Or do you need to know that they need to be applied by hand?
Changes for the vm go into VMMaker and get released when I have time and see a sensible need for a release. VM changes never go into the update stream, certainly 3.7 vm changes would not go into the 3.6 updates! Sometimes in periods of rapid change etc experimental VM builders will need to do manual work. That's just how it is, unfortunately. If I were being paid to spend all my time keeping this perfectly up to date and were provided with a comprehensive test lab of machines and sysadmin support, well then things might seem simpler to the outside world.
In general I'd just like to know the correct way to build the unix VM from scratch and I'm happy to document this. I had a look on the wiki but there was nothing obvious.
I have to disagree here; if _I_ can do it, with my inability to feel comfortable with *nix, then surely anyone can.
Is there such a thing as the 'correct' image to use for building the VM. Should the latest stable image always be able to build the next VM?
Since that is what I use, yes. Just occasionally one or other of the platforms slips behind because of author time issues. We usually get it fixed PDQ.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Oxymorons: Extinct Life
Michael Roberts mike@mjr104.co.uk wrote:
I'd just like us to be able to document the exact steps that are needed to build the VM at any point in time. This needs an FAQ entry. I would also like to write a script that automates this. This could then be run as a test to check that the VM can always be built the documented way.
There is a lot of documentation on building within the Unix source tree -- have you looked at platforms/unix/doc ?
IMHO, there should be a difference between people who just want to compile the VM and people who want to work on it. People who just want to compile it should *not* be pulling down CVS and running VMMaker etc. They should grab a released source tarball and do "./configure; make" in it. I have just posted such a thing for Ned's modifications. For such people, we already do have good instructions and a build script.
I don't know whether a developer build script will help or not. You'd still have the effort of assembling the directory tree. It would be cool, at least, to see Squeak run from a shell script, since it so rarely is! I dunno whether it has real value or not.
Do we need to more generally discuss Unix VM maintenance and production? Is Ian's page a little out of date?
Well, if you want 3.7 support today it is out of date. There was also a multiple year lag between full sound support becoming available and sound support appearing in Ian's distribution.
My take on this is as follows. I hope I am being fair, but I think this is correct. Ian seems to have update cycles spanning approximately 1-2 years. When he does an update, it tends to include every outstanding patch or a reimplementation thereof, and it tend to be a great release to use. 0.5 years or so later it is often good to include one or another patch along with it.
Other arrangements are possible that may work better. Ian has mentioned in the past the possibility of arranging someone else as the day to day maintainer of Squeak/Unix. This may be a good idea to pursue, though I'm not sure how to set up the details. The simplest way would be to name someone else as the maintainer and let Ian be the main contributor. Sort of a producer/director setup. :) But there are other possibilities, I'm sure, if we are creative about it.
Also keep in mind that the project is open source. Everyone can choose what they download and install, and anyone can post a file holding their prefered set of patches if they want.
-Lex
My take on this is as follows. I hope I am being fair, but I think this is correct. Ian seems to have update cycles spanning approximately 1-2 years. When he does an update, it tends to include every outstanding patch or a reimplementation thereof, and it tend to be a great release to use. 0.5 years or so later it is often good to include one or another patch along with it.
Other arrangements are possible that may work better.
That seems right.
On a possibly related note, is anyone else using darcs ? It feels quite like "monticello for files".
Regards, -Simon
On Apr 1, 2004, at 11:58 AM, Simon Michael wrote:
On a possibly related note, is anyone else using darcs ? It feels quite like "monticello for files".
Even closer, AFAICT, is monotone: http://www.venge.net/monotone/
Avi
"Avi" == Avi Bryant avi@beta4.com writes:
Avi> On Apr 1, 2004, at 11:58 AM, Simon Michael wrote:
On a possibly related note, is anyone else using darcs ? It feels quite like "monticello for files".
Avi> Even closer, AFAICT, is monotone: http://www.venge.net/monotone/
As a user of Darcs, Monotone and Arch, I suggest you look at the latest :) (http://www.gnuarch.org/)
Sam
On Thu, Apr 01, 2004 at 02:03:03PM -0400, Lex Spoon wrote:
Michael Roberts mike@mjr104.co.uk wrote:
I'd just like us to be able to document the exact steps that are needed to build the VM at any point in time. This needs an FAQ entry. I would also like to write a script that automates this. This could then be run as a test to check that the VM can always be built the documented way.
There is a lot of documentation on building within the Unix source tree -- have you looked at platforms/unix/doc ?
Sorry, look I think I'm being misunderstood. I was trying to help Peter because I have done this successfully in the past. I have read all the documentation I have found, but I didn't know that the VMMaker package on SM wouldn't build the VM at the time I used it because I needed additional changes. I might have compounded it by being on Ned's branch. I don't know whether that VMMaker would have built the HEAD or not.. but the advice was to use ned's branch so I did. What I didn't do was go to Tim's site to get the latest VMMaker. Now I know.
IMHO, there should be a difference between people who just want to compile the VM and people who want to work on it. People who just want to compile it should *not* be pulling down CVS and running VMMaker etc.
Well ok. It's not difficult to use CVS and learn how VMMaker works. One just needs to know the correct versions and patches that need to be applied at any point. What stumbled me was that updating everything inside the image wasn't enough.
They should grab a released source tarball and do "./configure; make"
That would makes things easier, that's a good idea.
Well, if you want 3.7 support today it is out of date.
I don't think that it is unreasonable to have 3.7 VMs available otherwise how are we expecting people to use 3.7 since there was a point at the start of 3.7 where the previous VM couldn't run the image?
My take on this is as follows. I hope I am being fair, but I think this is correct. Ian seems to have update cycles spanning approximately 1-2 years. When he does an update, it tends to include every outstanding patch or a reimplementation thereof, and it tend to be a great release to use. 0.5 years or so later it is often good to include one or another patch along with it.
Other arrangements are possible that may work better. Ian has mentioned in the past the possibility of arranging someone else as the day to day maintainer of Squeak/Unix. This may be a good idea to pursue, though I'm not sure how to set up the details. The simplest way would be to name someone else as the maintainer and let Ian be the main contributor. Sort of a producer/director setup. :) But there are other possibilities, I'm sure, if we are creative about it.
I think we at least need to have people able to run the latest image.
Also keep in mind that the project is open source. Everyone can choose what they download and install, and anyone can post a file holding their prefered set of patches if they want.
I'd just like to help people running Squeak on Unix. That's really my only motivation here.
Cheers Mike
squeak-dev@lists.squeakfoundation.org
-
Avi Bryant -
Lex Spoon -
Michael Roberts -
Ned Konz -
Samuel Tardieu -
Simon Michael -
Tim Rowledge