The Trunk: System-ul.528.mcz

David T. Lewis uploaded a new version of System to project The Trunk:
http://source.squeak.org/trunk/System-ul.528.mcz

==================== Summary ====================

Name: System-ul.528
Author: ul
Time: 12 May 2013, 10:33:50.489 pm
UUID: d59743da-b5a5-4413-81f4-eb6dd7f7704d
Ancestors: System-fbs.527

Added support for defining the exit code when quitting.

=============== Diff against System-fbs.527 ===============

Item was added:
+ ----- Method: SmalltalkImage>>quitPrimitive: (in category 'snapshot and quit') -----
+ quitPrimitive: exitCode
+ "Primitive. Exit with exitCode to another operating system on the host machine, if one exists. All state changes in the object space since the last snapshot are lost. Ignore exitCode if it's not supported by the VM."
+
+ <primitive: 113>
+ self quitPrimitive!

Item was changed:
  ----- Method: SmalltalkImage>>snapshot:andQuit:embedded: (in category 'snapshot and quit') -----
  snapshot: save andQuit: quit embedded: embeddedFlag
- "Mark the changes file and close all files as part of #processShutdownList.
- If save is true, save the current state of this Smalltalk in the image file.
- If quit is true, then exit to the outer OS shell.
- The latter part of this method runs when resuming a previously saved image. This resume logic checks for a document file to process when starting up."
- | resuming msg |
- Object flushDependents.
- Object flushEvents.
 
+ ^self
+ snapshot: save
+ andQuit: quit
+ withExitCode: nil
+ embedded: embeddedFlag!
- (SourceFiles at: 2) ifNotNil:[
- msg := String streamContents: [ :s |
- s nextPutAll: '----';
- nextPutAll: (save ifTrue: [ quit ifTrue: [ 'QUIT' ] ifFalse: [ 'SNAPSHOT' ] ]
- ifFalse: [quit ifTrue: [ 'QUIT/NOSAVE' ] ifFalse: [ 'NOP' ]]);
- nextPutAll: '----';
- print: Date dateAndTimeNow; space;
- nextPutAll: (FileDirectory default localNameFor: self imageName);
- nextPutAll: ' priorSource: ';
- print: LastQuitLogPosition ].
- self assureStartupStampLogged.
- save ifTrue: [ LastQuitLogPosition := (SourceFiles at: 2) setToEnd; position ].
- self logChange: msg.
- Transcript cr; show: msg
- ].
-
- Smalltalk processShutDownList: quit.
- Cursor write show.
- save ifTrue: [resuming := embeddedFlag
- ifTrue: [self snapshotEmbeddedPrimitive]
- ifFalse: [self snapshotPrimitive].  "<-- PC frozen here on image file"
- resuming == false "guard against failure" ifTrue:
- ["Time to reclaim segment files is immediately after a save"
- Smalltalk at: #ImageSegment
- ifPresent: [:theClass | theClass reclaimObsoleteSegmentFiles]]]
- ifFalse: [resuming := false].
- quit & (resuming == false) ifTrue: [self quitPrimitive].
- Cursor normal show.
- Smalltalk setGCParameters.
- resuming == true ifTrue: [Smalltalk clearExternalObjects].
- Smalltalk processStartUpList: resuming == true.
- resuming == true ifTrue:[
- self setPlatformPreferences.
- self recordStartupStamp].
- Project current wakeUpTopWindow.
- "Now it's time to raise an error"
- resuming == nil ifTrue: [self error:'Failed to write image file (disk full?)'].
- ^ resuming!

Item was added:
+ ----- Method: SmalltalkImage>>snapshot:andQuit:withExitCode:embedded: (in category 'snapshot and quit') -----
+ snapshot: save andQuit: quit withExitCode: exitCode embedded: embeddedFlag
+ "Mark the changes file and close all files as part of #processShutdownList.
+ If save is true, save the current state of this Smalltalk in the image file.
+ If quit is true, then exit to the outer OS shell.
+ If exitCode is not nil, then use it as exit code.
+ The latter part of this method runs when resuming a previously saved image. This resume logic checks for a document file to process when starting up."
+
+ | resuming msg |
+ Object flushDependents.
+ Object flushEvents.
+
+ (SourceFiles at: 2) ifNotNil:[
+ msg := String streamContents: [ :s |
+ s nextPutAll: '----';
+ nextPutAll: (save ifTrue: [ quit ifTrue: [ 'QUIT' ] ifFalse: [ 'SNAPSHOT' ] ]
+ ifFalse: [quit ifTrue: [ 'QUIT/NOSAVE' ] ifFalse: [ 'NOP' ]]);
+ nextPutAll: '----';
+ print: Date dateAndTimeNow; space;
+ nextPutAll: (FileDirectory default localNameFor: self imageName);
+ nextPutAll: ' priorSource: ';
+ print: LastQuitLogPosition ].
+ self assureStartupStampLogged.
+ save ifTrue: [ LastQuitLogPosition := (SourceFiles at: 2) setToEnd; position ].
+ self logChange: msg.
+ Transcript cr; show: msg
+ ].
+
+ Smalltalk processShutDownList: quit.
+ Cursor write show.
+ save ifTrue: [resuming := embeddedFlag
+ ifTrue: [self snapshotEmbeddedPrimitive]
+ ifFalse: [self snapshotPrimitive].  "<-- PC frozen here on image file"
+ resuming == false "guard against failure" ifTrue:
+ ["Time to reclaim segment files is immediately after a save"
+ Smalltalk at: #ImageSegment
+ ifPresent: [:theClass | theClass reclaimObsoleteSegmentFiles]]]
+ ifFalse: [resuming := false].
+ quit & (resuming == false) ifTrue: [
+ exitCode
+ ifNil: [ self quitPrimitive ]
+ ifNotNil: [ self quitPrimitive: exitCode ] ].
+ Cursor normal show.
+ Smalltalk setGCParameters.
+ resuming == true ifTrue: [Smalltalk clearExternalObjects].
+ Smalltalk processStartUpList: resuming == true.
+ resuming == true ifTrue:[
+ self setPlatformPreferences.
+ self recordStartupStamp].
+ Project current wakeUpTopWindow.
+ "Now it's time to raise an error"
+ resuming == nil ifTrue: [self error:'Failed to write image file (disk full?)'].
+ ^ resuming!

Item was added:
+ ----- Method: SmalltalkImage>>snapshot:andQuitWithExitCode: (in category 'snapshot and quit') -----
+ snapshot: save andQuitWithExitCode: exitCode
+
+ ^self
+ snapshot: save
+ andQuit: true
+ withExitCode: exitCode
+ embedded: false!

I tested this using a VM that lacks the exit code support, and found no problems.
All new VM builds will provide the primitive, so this belongs in trunk now.

On Sun, Oct 20, 2013 at 07:25:25PM +0000, [hidden email] wrote:

On 20 October 2013 20:33, David T. Lewis <[hidden email]> wrote:
> I tested this using a VM that lacks the exit code support, and found no problems.
> All new VM builds will provide the primitive, so this belongs in trunk now.

Yay! So there's only one small eensy detail left... any idea when we
might see a new released VM?

I realise this is a problem on the Windows and Mac fronts!

frank

On Sun, Oct 20, 2013 at 10:09:01PM +0100, Frank Shearar wrote:
> On 20 October 2013 20:33, David T. Lewis <[hidden email]> wrote:
> > I tested this using a VM that lacks the exit code support, and found no problems.
> > All new VM builds will provide the primitive, so this belongs in trunk now.
>
> Yay! So there's only one small eensy detail left... any idea when we
> might see a new released VM?
>
> I realise this is a problem on the Windows and Mac fronts!
>

Well, I guess the last official Unix build that Ian Piumarta did was about
a year ago, so a refresh might be in order some time soon.

I'll bet that if you were to send an email to Ian (piumarta at speakeasy
dot net, or just to the vm-dev list) telling him about how much you appreciate
his efforts and mentioning how nice it would be if the VM supported exit
status, he might do something for you. He's kind of a pushover for that
sort of influence ;-)

While you are at it you should mention that this is important to you because
you need it to support the work that you are doing with CI on build.squeak.org,
and oh by the way wouldn't it me nice if we had a real VM build slave
running on squeakvm.org that would do continuous builds from the latest
sources in the Subversion repository?

Dave

Dave,

On Oct 20, 2013, at 15:33 , David T. Lewis wrote:

> Well, I guess the last official Unix build that Ian Piumarta did was about
> a year ago, so a refresh might be in order some time soon.

Doesn't time fly?  I'll do the necessary as promptly as I can when your latest src is ready.

> He's kind of a pushover for that sort of influence ;-)

Beer works even better, whenever proximity permits. :)

> wouldn't it me nice if we had a real VM build slave
> running on squeakvm.org that would do continuous builds from the latest
> sources in the Subversion repository?

We could very easily do that for 32-bit Linux right there on squeakvm.org.  The Mac and Windows machines that I use to build binaries here are both up 24/7 and could be made to rebuild a binary archive whenever the trunk changes.  Having your generated src in the trunk would make that very easy (and src can finally be removed from the Unix tree).

For more exotic Unix builds (Solaris, *BSD) I run the OS in VirtualBox and have a script to update source, build everything and upload binaries, in parallel.  Adding Mac OS and Win32 to that script should not be difficult.  A cron job could run it whenever the most recent commit reaches (say) one hour of age.

Unless there a particular well-known cross-platform unattended build framework, having some indispensable feature, that we absolutely should use for all of this?

Regards,
Ian

Dave,

As usual, I read your message after replying to it rather than beforehand...

On Oct 20, 2013, at 15:33 , David T. Lewis wrote:

> While you are at it you should mention that this is important to you because
> you need it to support the work that you are doing with CI on build.squeak.org,
> and oh by the way wouldn't it me nice if we had a real VM build slave
> running on squeakvm.org that would do continuous builds from the latest
> sources in the Subversion repository?

Frank: if you want to duplicate your build magic on squeakvm.org then please just let me know and I'll make an account for you with whatever privileges you need.  Our only real constraint is disk space.  There is a little under 2 GB free right now.

Regards,
Ian

On 20-10-2013, at 4:21 PM, Ian Piumarta <[hidden email]> wrote:

Would any useful amount of space be reclaimed by getting rid of some ancient and seemingly defunct directories? - like sandbox (which appears to only have some test junk of mine from 8 years ago), vmm38b4, ned-branch, replugin-branch… I know svn uses links etc a lot but there must be some space taken up by all those.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Re vera, potas bene = Say, you sure are drinking a lot.

Valid suggestions all, but for Subversion use the available space will be more than sufficient for a long time to come.  The hosting company also seems to grow the disk by a GB for me without being asked whenever it threatens to fill up (it has gradually doubled in capacity over the years).  So I'm not too worried about the space.  The comment was just in case the "build magic" needs fifteen 100 MB Squeak images to do its stuff, at which point I might be worried about abusing their unusually helpful storage policy and/or asking them explicitly about providing significantly more space.

On Oct 20, 2013, at 16:44 , tim Rowledge wrote:

> Would any useful amount of space be reclaimed by getting rid of some ancient and seemingly defunct directories? - like sandbox (which appears to only have some test junk of mine from 8 years ago), vmm38b4, ned-branch, replugin-branch… I know svn uses links etc a lot but there must be some space taken up by all those.

On Sun, Oct 20, 2013 at 04:15:15PM -0700, Ian Piumarta wrote:
> Dave,
>
> On Oct 20, 2013, at 15:33 , David T. Lewis wrote:
>
> > Well, I guess the last official Unix build that Ian Piumarta did was about
> > a year ago, so a refresh might be in order some time soon.
>
> Doesn't time fly?  I'll do the necessary as promptly as I can when your latest src is ready.
>

The SVN trunk/src is up to date as of today, although this is in the
new flat directory layout with internal and external plugins in the
same directory. So to compile from trunk/src we need to either update
the cmake build to use that structure, or regenerate once more in the
traditional internal/external directory structure (which is easy to do).

> > He's kind of a pushover for that sort of influence ;-)
>
> Beer works even better, whenever proximity permits. :)
>

If proximity should ever permit, I'll definitely supply the beer :)


The Jenkins framework that Frank has been using on build.squeak.org
seems to do a very nice job of tracking these things. I think we
could use it as the supervisory trigger to initiate updates on
squeakvm.org, and also to display the result of those updates. The
actual build procedures, including VirtualBox builds, can and should
be your own build procedures on squeakvm.org.

So -- if the existing builds could be set to run under cron, then it
should be a small additional step to wire them into Jenkins to trigger
the builds and display the results.

Dave

>
> So -- if the existing builds could be set to run under cron, then it
> should be a small additional step to wire them into Jenkins to trigger
> the builds and display the results.

A small and hopefully really simple suggestion; can we add an occasional (like once a week or so) test build of the 'old' code that is considered stable. I'm thinking that every now and then it is wise to check that any changes in the tools haven't broken the production system.

Also, is it possible to set things so that we can have … 'probationary'(?) branch that gets built automagically. If PlatformMaintainerA/M/U/R is unavailable for whatever reason (taking a six month trip around the galaxy in his office, for example) than platform A/M/U/R code in the probational branch is alterable by a wider range of people and can be 'fixed' (for applicable values of 'fixed') temporarily.  Um, actually, from what little I know about it, this is sounding a bit git-ish. Or maybe I need more coffee.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: GLV: Ground the Line Voltage

On 21 October 2013 17:53, tim Rowledge <[hidden email]> wrote:
>>
>> So -- if the existing builds could be set to run under cron, then it
>> should be a small additional step to wire them into Jenkins to trigger
>> the builds and display the results.
>
> A small and hopefully really simple suggestion; can we add an occasional (like once a week or so) test build of the 'old' code that is considered stable. I'm thinking that every now and then it is wise to check that any changes in the tools haven't broken the production system.
>
> Also, is it possible to set things so that we can have … 'probationary'(?) branch that gets built automagically. If PlatformMaintainerA/M/U/R is unavailable for whatever reason (taking a six month trip around the galaxy in his office, for example) than platform A/M/U/R code in the probational branch is alterable by a wider range of people and can be 'fixed' (for applicable values of 'fixed') temporarily.  Um, actually, from what little I know about it, this is sounding a bit git-ish. Or maybe I need more coffee.

It is indeed sounding very git-ish, your proposal.

frank

> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: GLV: Ground the Line Voltage
>
>
>

Hi Dave,

On Oct 21, 2013, at 05:38 , David T. Lewis wrote:

> The SVN trunk/src is up to date as of today, although this is in the
> new flat directory layout with internal and external plugins in the
> same directory.

I have been able (with surprisingly little ad hoc tweaking) to make your simpler organisation work with the current cmake build process and produce a working VM with all of the usual internal and external plugins.  (Like the French don't quite say: "The /unix/src is dead!  Long live the /src!" :-)

To eliminate the tweaking will need a couple of hours' work on the cmake scripts.  I'm about to be traveling for a week so that will not be immediate, but will be very soon.

> So -- if the existing builds could be set to run under cron, then it
> should be a small additional step to wire them into Jenkins to trigger
> the builds and display the results.

Let's try to make that happen.  I can attack the first part as soon I get back.

Regards,
Ian

On Mon, Oct 21, 2013 at 02:48:18PM -0700, Ian Piumarta wrote:
Excellent, this should simplify a number of things, including getting trunk
and oscog aligned with the directory structure that Eliot and Andreas came
up with for Cog. We should be able to get rid of some cruft in VMMaker as well.

> To eliminate the tweaking will need a couple of hours' work on the cmake scripts.  I'm about to be traveling for a week so that will not be immediate, but will be very soon.
>
> > So -- if the existing builds could be set to run under cron, then it
> > should be a small additional step to wire them into Jenkins to trigger
> > the builds and display the results.
>
> Let's try to make that happen.  I can attack the first part as soon I get back.
>

Thanks, looking forward to it!

Frank, I'll probably need some coaching on how to set up a remote build
executor on build.squeak.org a couple of weeks from now.

Dave

> Regards,
> Ian
>