Downloading a VM is hard

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; [hidden email]; 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; [hidden email]; 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."

     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 <[hidden email]> wrote:

>
>     I've done VM rebuilds on all platforms recently. If there's
> anything 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; [hidden email]; 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:
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 <[hidden email]> wrote:
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.

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:
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.

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 <[hidden email]> wrote:
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.

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