I added one more Jenkins job called "Squeak 64-bit image". This will hopefully be triggered each time the SqueakTrunk job runs. The output is a copy of the trunk image traced to 64-bit object format.
I want to see this run for a few days before I mention it on the squeak-dev list, but I think that this will give us an easy way to maintain a 64-bit version of released images.
The build script is actually pretty cool, if you don't mind me saying so. It used to take a lot of manual steps to trace an image to 64 bits and clean up the resulting image to make it look like the original. But this script automates the process with no cleanup required :) The script is here:
http://squeakci.org/job/Squeak%2064-bit%20image/ws/TraceTo64.st
Dave
On 2012-11-07 8:18 AM, David T. Lewis wrote:
I added one more Jenkins job called "Squeak 64-bit image". This will hopefully be triggered each time the SqueakTrunk job runs. The output is a copy of the trunk image traced to 64-bit object format.
I want to see this run for a few days before I mention it on the squeak-dev list, but I think that this will give us an easy way to maintain a 64-bit version of released images.
The build script is actually pretty cool, if you don't mind me saying so. It used to take a lot of manual steps to trace an image to 64 bits and clean up the resulting image to make it look like the original. But this script automates the process with no cleanup required :) The script is here:
http://squeakci.org/job/Squeak%2064-bit%20image/ws/TraceTo64.stDave
That's pretty nifty. And it seems to me to be exactly what the Jenkins server is for. There are lots of things on the periphery that have not received the attention they could have. 64-bit anything seems that way to me. And the Jenkins server makes it possible and fun to extend our reach. Cool stuff.
Chris
On 2012-11-07, at 14:18, "David T. Lewis" lewis@mail.msen.com wrote:
I added one more Jenkins job called "Squeak 64-bit image". This will hopefully be triggered each time the SqueakTrunk job runs. The output is a copy of the trunk image traced to 64-bit object format.
I want to see this run for a few days before I mention it on the squeak-dev list, but I think that this will give us an easy way to maintain a 64-bit version of released images.
The build script is actually pretty cool, if you don't mind me saying so. It used to take a lot of manual steps to trace an image to 64 bits and clean up the resulting image to make it look like the original. But this script automates the process with no cleanup required :) The script is here:
http://squeakci.org/job/Squeak%2064-bit%20image/ws/TraceTo64.st
Dave
Nice. You could move up the quit-without-saving line a bit. Makes it more clear what happens in the tracer image vs the traced image.
And use readOnlyFileNamed: instead of fileNamed:.
Plus a comment why this uses a changeset and file-in instead of MC - less evidence to get rid of, I presume?
- Bert -
On Wed, Nov 07, 2012 at 04:58:55PM +0100, Bert Freudenberg wrote:
On 2012-11-07, at 14:18, "David T. Lewis" lewis@mail.msen.com wrote:
I added one more Jenkins job called "Squeak 64-bit image". This will hopefully be triggered each time the SqueakTrunk job runs. The output is a copy of the trunk image traced to 64-bit object format.
I want to see this run for a few days before I mention it on the squeak-dev list, but I think that this will give us an easy way to maintain a 64-bit version of released images.
The build script is actually pretty cool, if you don't mind me saying so. It used to take a lot of manual steps to trace an image to 64 bits and clean up the resulting image to make it look like the original. But this script automates the process with no cleanup required :) The script is here:
http://squeakci.org/job/Squeak%2064-bit%20image/ws/TraceTo64.st
Dave
Nice. You could move up the quit-without-saving line a bit. Makes it more clear what happens in the tracer image vs the traced image.
And use readOnlyFileNamed: instead of fileNamed:.
Thanks I'll update it.
Plus a comment why this uses a changeset and file-in instead of MC - less evidence to get rid of, I presume?
Actually, the file-in is being done directly from the SystemTracing-dtl.24.mcz file, not from a change set. But you are right, the reason is to minimize the evidence.
The script also opens a new change set, does all the work within that change set, and deletes the change set when done. The last part of the cleanup actually happens in the 64-bit image right after the "Execution resumes here" line. So strictly speaking, the traced image is not cleaned up until it has been started and saved one time. I guess I should add one final open-and-resave step to handle this, but I figured nobody would really notice ;)
Dave
On Wed, Nov 07, 2012 at 04:58:55PM +0100, Bert Freudenberg wrote:
On 2012-11-07, at 14:18, "David T. Lewis" lewis@mail.msen.com wrote:
I added one more Jenkins job called "Squeak 64-bit image". This will hopefully be triggered each time the SqueakTrunk job runs. The output is a copy of the trunk image traced to 64-bit object format.
I want to see this run for a few days before I mention it on the squeak-dev list, but I think that this will give us an easy way to maintain a 64-bit version of released images.
The build script is actually pretty cool, if you don't mind me saying so. It used to take a lot of manual steps to trace an image to 64 bits and clean up the resulting image to make it look like the original. But this script automates the process with no cleanup required :) The script is here:
http://squeakci.org/job/Squeak%2064-bit%20image/ws/TraceTo64.st
Dave
Nice. You could move up the quit-without-saving line a bit. Makes it more clear what happens in the tracer image vs the traced image.
And use readOnlyFileNamed: instead of fileNamed:.
Plus a comment why this uses a changeset and file-in instead of MC - less evidence to get rid of, I presume?
Thanks Bert,
I made some updates to the script as suggested, hopefully it is better now.
Dave
box-admins@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Cunnington -
David T. Lewis