There seems to be a bit of a problem with downloading recent VMs. We probably don’t want to actually put people off so early. If we’re putting out a nice new release we surely want to make it easy for users to try it out?
Go to squeak.org and click on the Download link. Find ‘Latest Development’ and follow the ‘Get a VM here’ link to… squeakvm.org Thence to http://www.squeakvm.org/mac where we find an ancient mess. Try the ‘CogVM’ link and a) the server isn’t responding right now b) it looks like it would be a Pharo VM anyway
I also looked on http://www.mirandabanda.org/files/Cog/VM/ but nothing later than last August, which I already have.
What easy, up to date, "obvious to a newcomer” am I missing? Sure, I suppose I could suffer through the setup to compile my own but honestly I really don’t have any wish to bugger about with XCode. I did it once a long time ago, and that was enough.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "How many Pak Protectors does it take to change a lightbulb?" "Only one, but the lightbulb has to smell right."
Eliot's latest VM (#2776, August 2013) is the best option at the moment.
I'm waiting to make another all-in-one once 4.5 is out. In it I plan to use whatever is Eliot's latest VM at the time.
I think the all-in-one should be the primary download for newcomers and then links to the current stable & latest image, sources, and platform vm's should be present but not presented in a confusing way as seems to be the case now.
I wish the 4.3 all-in-one and 4.3 image weren't linked directly on the squeak.org download page.
tim Rowledge wrote
There seems to be a bit of a problem with downloading recent VMs. We probably don’t want to actually put people off so early. If we’re putting out a nice new release we surely want to make it easy for users to try it out?
Go to squeak.org and click on the Download link. Find ‘Latest Development’ and follow the ‘Get a VM here’ link to… squeakvm.org Thence to http://www.squeakvm.org/mac where we find an ancient mess. Try the ‘CogVM’ link and a) the server isn’t responding right now b) it looks like it would be a Pharo VM anyway
I also looked on http://www.mirandabanda.org/files/Cog/VM/ but nothing later than last August, which I already have.
What easy, up to date, "obvious to a newcomer” am I missing? Sure, I suppose I could suffer through the setup to compile my own but honestly I really don’t have any wish to bugger about with XCode. I did it once a long time ago, and that was enough.
tim
tim Rowledge;
tim@
; http://www.rowledge.org/tim "How many Pak Protectors does it take to change a lightbulb?" "Only one, but the lightbulb has to smell right."
-- View this message in context: http://forum.world.st/Downloading-a-VM-is-hard-tp4739979p4740014.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
I've done VM rebuilds on all platforms recently. If there's anything we need, please let me know.
thanks,
-C
-- Craig Latta www.netjam.org/resume + 1 510 984 8117 +31 20 893 2796
On 28-01-2014, at 5:44 PM, Craig Latta craig@netjam.org wrote:
I've done VM rebuilds on all platforms recently. If there'sanything we need, please let me know.
All platforms? I didn’t know you had gone RISC OS ;-) But of course, if you have a Pi, you actually could…
We have some fairly sophisticated automation stuff in place and maybe we can leverage that to provide some more timely builds for fans of bleeding edges. I know there is the Jenkins builder but my understanding is that it is intended to do check builds (?) and right now the jenkins dashboard at http://build.squeak.org/ is showing a lot of red for OSX related VMs. I’m not about to guess what most of it even means. Well, except that the Cog related log seems to imply a problem with even trying to generate the sources.
What seems to be missing is assembling the sources *and checking them in* (I know this might cause some storage space issues for Ian on squeakvm.org after a while) in the way that IAn occasionally does for the unix tree; which means that it is harder than really neccessary for me to grab a source tree and build a Pi/Raspbian vm. Worse, it is harder for the guy that puts together the ‘production’ Raspbian vm package. And of course it would be nice to include both Cog and StackVM code.
Mostly what we need is some much more clear information with clear links to both ‘stable’ vms (and platform packages etc if wanted) and development vms, with a decent description of the ways to make use of them.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: BZR: Branch if piZza Ready
On Tue, Jan 28, 2014 at 07:10:11PM -0800, tim Rowledge wrote:
On 28-01-2014, at 5:44 PM, Craig Latta craig@netjam.org wrote:
I've done VM rebuilds on all platforms recently. If there'sanything we need, please let me know.
All platforms? I didn?t know you had gone RISC OS ;-) But of course, if you have a Pi, you actually could?
We have some fairly sophisticated automation stuff in place and maybe we can leverage that to provide some more timely builds for fans of bleeding edges. I know there is the Jenkins builder but my understanding is that it is intended to do check builds (?) and right now the jenkins dashboard at http://build.squeak.org/ is showing a lot of red for OSX related VMs. I?m not about to guess what most of it even means. Well, except that the Cog related log seems to imply a problem with even trying to generate the sources.
If you are looking at the CogVM job, it is currently failing on some sort of fairly trivial bug in initializing VMClass when loading into a clean Squeak image. I was looking it last weekend just long enough to spot the problem, but not to suggest a solution.
I regret my choice of "CogVM" and "InterpreterVM" as names for those two jobs, as it implies that they are VM build jobs. They are intended to verify VMMaker code generation only, and the build artifacts are just source tarballs that claim to be compileable.
I don't know what any of the OS X related jobs are doing.
What seems to be missing is assembling the sources *and checking them in* (I know this might cause some storage space issues for Ian on squeakvm.org after a while) in the way that IAn occasionally does for the unix tree; which means that it is harder than really neccessary for me to grab a source tree and build a Pi/Raspbian vm. Worse, it is harder for the guy that puts together the ?production? Raspbian vm package. And of course it would be nice to include both Cog and StackVM code.
Per suggestion from Ian, I have been checking them in under trunk/src (in parallel with trunk/platforms). Space is not an issue. It's a manual procedure, but the idea is that when you commit something to VMMaker that affects the generated code, you also update VMMaker class>>versionString, generate the sources, eyeball them for sanity, and check them in to trunk/src. Ian has also updated the CMake build so that it uses these sources (as opposed to the platforms/unix/src copy that tends to go out of date). He also incorporated the conventions used for plugins.int, plugins.ext, and plugins.exc so that they are compatible with the procedure that Eliot is using for Cog. These changes appeared in various commit notices over the last few months on the vm-dev list.
If we are going to do automated VM builds, this should be done on squeakvm.org and/or whatever Eliot might want to use for Cog. I'm quite sure that Ian would be happy to support this. I personally would like to see it under the control of the Jenkins infrastructure on build.squeak.org, because this provides a nice console to show status and to retrieve build artifacts. But I think that any actual VM builds need to be done on suitable platforms (definitely not box3.squeak.org), and if possible should be looked after by whomever supports that actual VM.
Mostly what we need is some much more clear information with clear links to both ?stable? vms (and platform packages etc if wanted) and development vms, with a decent description of the ways to make use of them.
100% agree. It might take some work to make this happen, but it is badly needed.
Dave
On 29 January 2014 05:13, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jan 28, 2014 at 07:10:11PM -0800, tim Rowledge wrote:
On 28-01-2014, at 5:44 PM, Craig Latta craig@netjam.org wrote:
I've done VM rebuilds on all platforms recently. If there'sanything we need, please let me know.
All platforms? I didn?t know you had gone RISC OS ;-) But of course, if you have a Pi, you actually could?
We have some fairly sophisticated automation stuff in place and maybe we can leverage that to provide some more timely builds for fans of bleeding edges. I know there is the Jenkins builder but my understanding is that it is intended to do check builds (?) and right now the jenkins dashboard at http://build.squeak.org/ is showing a lot of red for OSX related VMs. I?m not about to guess what most of it even means. Well, except that the Cog related log seems to imply a problem with even trying to generate the sources.
If you are looking at the CogVM job, it is currently failing on some sort of fairly trivial bug in initializing VMClass when loading into a clean Squeak image. I was looking it last weekend just long enough to spot the problem, but not to suggest a solution.
I regret my choice of "CogVM" and "InterpreterVM" as names for those two jobs, as it implies that they are VM build jobs. They are intended to verify VMMaker code generation only, and the build artifacts are just source tarballs that claim to be compileable.
What names would you like? We can change them. Maybe "CogVM: verify code generation"? My only desire here would be that "Cog" and "Interpreter" remain as prefixes for the names.
I don't know what any of the OS X related jobs are doing.
There is only one (Test-OSX was me mucking around with build scripts in ages past, and is now no more), and that's SqueakTrunk-OSX. I see it's failing because of the differences between telling VMs they're headless: sometimes it's -headless (as that job uses) and sometimes it's -vm-display-null. SqueakTrunk-OSX simply runs the test suite of an updated trunk image.
What seems to be missing is assembling the sources *and checking them in* (I know this might cause some storage space issues for Ian on squeakvm.org after a while) in the way that IAn occasionally does for the unix tree; which means that it is harder than really neccessary for me to grab a source tree and build a Pi/Raspbian vm. Worse, it is harder for the guy that puts together the ?production? Raspbian vm package. And of course it would be nice to include both Cog and StackVM code.
Per suggestion from Ian, I have been checking them in under trunk/src (in parallel with trunk/platforms). Space is not an issue. It's a manual procedure, but the idea is that when you commit something to VMMaker that affects the generated code, you also update VMMaker class>>versionString, generate the sources, eyeball them for sanity, and check them in to trunk/src. Ian has also updated the CMake build so that it uses these sources (as opposed to the platforms/unix/src copy that tends to go out of date). He also incorporated the conventions used for plugins.int, plugins.ext, and plugins.exc so that they are compatible with the procedure that Eliot is using for Cog. These changes appeared in various commit notices over the last few months on the vm-dev list.
If we are going to do automated VM builds, this should be done on squeakvm.org and/or whatever Eliot might want to use for Cog. I'm quite sure that Ian would be happy to support this. I personally would like to see it under the control of the Jenkins infrastructure on build.squeak.org, because this provides a nice console to show status and to retrieve build artifacts. But I think that any actual VM builds need to be done on suitable platforms (definitely not box3.squeak.org), and if possible should be looked after by whomever supports that actual VM.
build.squeak.org does run builds, but it doesn't have to. For instance, those OSX builds run on my Mac mini.
frank
On Wed, Jan 29, 2014 at 09:57:06AM +0000, Frank Shearar wrote:
On 29 January 2014 05:13, David T. Lewis lewis@mail.msen.com wrote:
I regret my choice of "CogVM" and "InterpreterVM" as names for those two jobs, as it implies that they are VM build jobs. They are intended to verify VMMaker code generation only, and the build artifacts are just source tarballs that claim to be compileable.
What names would you like? We can change them. Maybe "CogVM: verify code generation"? My only desire here would be that "Cog" and "Interpreter" remain as prefixes for the names.
Maybe CogVM-Slang and InterpreterVM-Slang would have been better. Or perhaps CogVM-VMMaker and InterpreterVM-VMMaker? The idea is that these jobs are focused on the Smalltalk to C code generation, as opposed to compiling a runtime VM with all the associated libraries and platform dependencies.
If we are going to do automated VM builds, this should be done on squeakvm.org and/or whatever Eliot might want to use for Cog. I'm quite sure that Ian would be happy to support this. I personally would like to see it under the control of the Jenkins infrastructure on build.squeak.org, because this provides a nice console to show status and to retrieve build artifacts. But I think that any actual VM builds need to be done on suitable platforms (definitely not box3.squeak.org), and if possible should be looked after by whomever supports that actual VM.
build.squeak.org does run builds, but it doesn't have to. For instance, those OSX builds run on my Mac mini.
Agreed, and this is as it should be. I don't mean to sound as though I am contradicting you, as I think we are saying the same thing. The Jenkins at build.squeak.org does a very nice job of orchestrating tests, and these tests may be run on any number of slave servers. In the case of actual VM builds, we would want the the slave servers to be whatever the VM developers prefer to use, so that they can be set up with the appropriate compilers, libraries, and build tools.
Dave
On 29 January 2014 23:23, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Jan 29, 2014 at 09:57:06AM +0000, Frank Shearar wrote:
On 29 January 2014 05:13, David T. Lewis lewis@mail.msen.com wrote:
I regret my choice of "CogVM" and "InterpreterVM" as names for those two jobs, as it implies that they are VM build jobs. They are intended to verify VMMaker code generation only, and the build artifacts are just source tarballs that claim to be compileable.
What names would you like? We can change them. Maybe "CogVM: verify code generation"? My only desire here would be that "Cog" and "Interpreter" remain as prefixes for the names.
Maybe CogVM-Slang and InterpreterVM-Slang would have been better. Or perhaps CogVM-VMMaker and InterpreterVM-VMMaker? The idea is that these jobs are focused on the Smalltalk to C code generation, as opposed to compiling a runtime VM with all the associated libraries and platform dependencies.
I have no issue with you renaming the builds. One thing to watch out for is that it creates, AFAIK, a _whole new_ workspace. Any special scripts in the old workspace must be manually copied over.
If we are going to do automated VM builds, this should be done on squeakvm.org and/or whatever Eliot might want to use for Cog. I'm quite sure that Ian would be happy to support this. I personally would like to see it under the control of the Jenkins infrastructure on build.squeak.org, because this provides a nice console to show status and to retrieve build artifacts. But I think that any actual VM builds need to be done on suitable platforms (definitely not box3.squeak.org), and if possible should be looked after by whomever supports that actual VM.
build.squeak.org does run builds, but it doesn't have to. For instance, those OSX builds run on my Mac mini.
Agreed, and this is as it should be. I don't mean to sound as though I am contradicting you, as I think we are saying the same thing. The Jenkins at build.squeak.org does a very nice job of orchestrating tests, and these tests may be run on any number of slave servers. In the case of actual VM builds, we would want the the slave servers to be whatever the VM developers prefer to use, so that they can be set up with the appropriate compilers, libraries, and build tools.
Right. Yes, exactly. Ideally that ideal setup would be encoded in however the build's started, through a bootstrap script, so that a blank machine could be added and simply because it's, say, a RasPi machine running RiscOS, magically the right binaries get pulled down and installed and the job runs to completion. Ideally.
frank
Dave
squeak-dev@lists.squeakfoundation.org
-
Craig Latta -
David T. Lewis -
Frank Shearar -
Paul DeBruicker -
tim Rowledge