[squeak-dev] re: Downloading a VM is hard

Frank Shearar frank.shearar at gmail.com
Wed Jan 29 09:57:06 UTC 2014


On 29 January 2014 05:13, David T. Lewis <lewis at 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 at netjam.org> 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.
>>
>
> 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


More information about the Squeak-dev mailing list