Sunday, December 13, 2009

Fwd: [squeak-dev] [ANN] Mason 1.0

Date: Sun, 13 Dec 2009 11:11:13 -0800
To: The general-purpose Squeak developers list
<squeak-dev@lists.squeakfoundation.org>

Hi folks,

As I mentioned yesterday, here's the release version of Mason, a Squeak build system. It relies on OSProcess to build images, but it should be possible to build other artifacts, such as directory trees, zip files, SAR files etc without OSProcess. The download is available here:

http://www.wiresong.ca/downloads/Mason-1.0.0.sar

There's no documentation yet, but I've pasted below a brief description that I sent to the Pharo folks a little while ago.

Cheers,

Colin

---

The core model is a hierarchy of targets. Targets represent the artifacts that Mason can produce, such as files, directories, images, packages etc, and the hierarchy represents the desired state, which Mason will work to create. There's a Canvas-like API for creating target hierarchies, and Products are objects that know how to specify targets using that API.

A Product is an abstract thing, which represents a high-level concept such as "the latest version of a given package" or "the HTML documentation for a project." The role of a Product is to reduce that abstraction to a set of concrete targets which it specifies using the canvas API. A Product probably has to examine the environment to decide what targets to specify - it might scan a repository to determine the latest version of a package or scan a directory of creole files to determine which HTML files need to be generated.

Given a target hierarchy, Mason can generate a Build. A Build contains a number of jobs, which collectively create the artifacts specified by the targets. Jobs essentially MethodObjects, and each do small amounts of work. The Build is responsible for running the jobs and managing dependencies between them. The build runs the jobs in parallel where possible, and since many jobs involve IO or spawning other processes via OSProcess, so there's actually a pretty decent performance advantage.

Those are the broad outlines. There's a few issues here still, both architectural and with the current implementation.

One is that building a target tree may be an unnecessary intermediate step. It would feasible to have targets just be transient entities the way TagBrushes are in Seaside - Products would specify a Build directly. Another is that I haven't tried to do any optimization along the lines of make - everything is built fresh every time. The targets -> build converter could try to examine the disk and see if it could avoid building things that are already up to date.

I have an idea to address both these issues by having a step that walks over the target tree and optimizes it before the Build is created. This could involve identifying and merging common intermediate steps, and then doing the make trick of eliminating any targets that already exist and are up-to-date.

For now though, I've been quite happy with even the unoptimized version. I've used it to build distribution SAR archives for OB, MC2 and Filesystem, development images, load-order and package dependency testing etc.

Saturday, December 12, 2009

Fwd: Re: [squeak-dev] Re: Packages, Packages, Packages

At 8:14 PM +0200 12/12/09, Igor Stasenko apparently wrote:
<quoted material snipped>

I am clueless, why people eagerly jumping into the boat in one case,
but prefer to stay away from it in another.
Something irrational in this..

The Sake and Bob [1] projects were announced more than a half year
earlier than Metacello, but there are few people who ever took time to
evaluate it (including me).
But sure, why we would need to ever look at it, if we got a new shiny toy?

I have nothing against Metacello project , neither beloved with
Sake/Bob solution(s). I know very little about them.
But if i would need a packaging tool, i'd first consider alternatives
& look for existing tools and evaluate them before jumping with closed
eyes.

[1] http://wiki.squeak.org/squeak/5953

--
Best regards,
Igor Stasenko AKA sig.

Sake - A Squeak based make-like tool

http://wiki.squeak.org/squeak/5953

Thursday, November 26, 2009

Planet Smalltalk

Planet Smalltalk is a meta blog collecting the content of various Smalltalk-related blogs. It doesn't provide any content of its own.
http://planet.smalltalk.org/

A glimpse of Glamour

Nice overview from Tudor Girba on the Glamour browser framework.

http://astares.blogspot.com/2009/11/glimpse-of-glamour.html

Pharo Code Snippets

This page contains code snippets to help beginners starts with Pharo and learn cool things
http://code.google.com/p/pharo/wiki/CodeSnippets

Thursday, November 19, 2009

Loading Seaside 3.0

Date: Tue, 03 Nov 2009 14:07:38 +0100
From: "Torsten Bergmann" <astares@gmx.de>
Subject: [Pharo-project] ScriptLoader does not implement loadComanche
To: pharo-project@lists.gforge.inria.fr
Message-ID: <20091103130738.6730@gmx.net>
Content-Type: text/plain; charset="us-ascii"

see http://code.google.com/p/pharo/issues/detail?id=1398


If you are in a dev-image you can use:

loadSeaside30
[ self gofer new
squeaksource: 'Seaside30';
addPackage: 'LoadOrderTests';
load ]
valueSupplyingAnswers: {
{'Load Seaside'. true}.
{'SqueakSource User Name'. ''}.
{'SqueakSource Password'. ''}.
{'Run tests'. false}.
}.

"Set up to development environment (enables seaside web toolbar) "
(self environment at: #WAAdmin) applicationDefaults
addParent: (self environment at: #WADevelopmentConfiguration) instance.

(self environment at: #WASqueakServerAdaptorBrowser) open

Pharo ImageBuildScripts

A collection of scripts to build fancy development images
Lukas Renggli

http://code.google.com/p/pharo/wiki/ImageBuildScripts

Programmatically Run Lint

http://www.lukas-renggli.ch/blog/programmatically-run-lint

Saturday, November 07, 2009

More Installer and Sake/Packages documentation

For those who cannot be bothered to look in an Image for documentation, here are some of the
Class Comments retrieved from an 090628-1523_Squeak3.10.2-lpf-atomic image from <ftp://ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/latest/> after executing Installer install: 'Packages'.
This is also being posted to <http://squeaktipsandtrickswatch.blogspot.com/>.

Ken G. Brown

--
Installer-Core/Installer

Documentation now available at http://installer.pbwiki.com/Installer
 
useFileIn - flag to load source.st rather than using Monticello

--
Installer-Core/InstallerMantis

Search feature is based upon a custom mantis query ceveloped and maintained by Ken Causey <ken@kencausey.com>

Installer mantis bugsAll select: [ :ea | ea status = 'testing' ].

--
Installer-Formats/SARInstaller

I am an object that handles the loading of SAR (Squeak ARchive) files.

A SAR file is a Zip file that follows certain simple conventions:

* it may have a member named "install/preamble".

This member, if present, will be filed in as Smalltalk source code at the beginning of installation.
Typically, the code in the preamble will make whatever installation preparations are necessary,
and will then call methods in the "client services" method category to extract or install other zip members.

* It may have a member named "install/postscript".

This member, if present, will be filed in as Smalltalk source code at the end of installation.
Typically, the code in the postscript will set up the operating environment,
and will perhaps put objects in flaps, open projects or README files, or launch samples.

Within the code in the preamble and postscript, "self" is set to the instance of the SARInstaller.

If neither an "install/preamble" nor an "install/postscript" file is present,
all the members will be installed after prompting the user,
based on a best guess of the member file types that is based on member filename extensions.

This is new behavior.

--
Installer-Scripts/InstallerScripts

(self new addPackage: 'Example') options collect: [ :ea  | ea value asLegalSelector asSymbol ]  #(#scriptExampleSqueak310forKPH #scriptExampleSqueak310 #scriptExampleSqueak310)

--
Installer-Launcher/Launcher

A Launcher provides squeak with a range of capabilities that are intended to be used from the command line.

As a design goal, the startup process can invoke Launcher several times at several points in the startup sequence. In particular 1) below aims to provide a mechanism for getting in to images that are broken in some form, so as to enable a script to be run before morphic has attempted to startup.

1) Launcher is registered to handle startup notification after Security manager
any class which wishes to provide a service to be usable at this time implements startFrom:

2) Launcher is wired in to ProjectLauncher to handle startup notification when squeak is fully initialized. Any class wishing to provide a service to be usable at this time implements launchFrom:

#startFrom: and #launchFrom: are called providing a handle to the launcher which may be used to obtain parameters using the desired scheme.

a) launcher getParameters . key=value +yes -no
b) launcher getParametersOldStyle . key value key2 value2

Instance Variables
    actionSelector: #startFrom: #launchFrom:
        commandLineClass: aClass
        image:  the smalltalk image or self if being a mock
     mock: the mock array of startup parameters
      nextCommandLineDocument: aString
        nextParameterIndex:     anInteger
 
--
Sake-Core/SakeBlock

Raise this if for some reason you find that the task you are doing is blocked. This might occur in a multi builder build system where two building threads decide to build the same item.

(implementation idea - not implemented yet)

When a Block is detected, Sake, looks for any following dependent task that is not dependant upon the blocked task.
Alternatively, Sake could simply randomise the task order and re-sort them, tryng again.

--
Sake-Core/SakeCompiler

Enables methods to include raw uncompiled text for documentation purposes following a line containing 6 quotes """"""

--
Sake-Core/SakeMeta

I'm a dictionary which can be used using any method call instead of #at:put: and at:. Use me like:

- (aSakeMeta foo: 'bar') which is equivalent to (aSakeMeta at: 'foo' put: 'bar')
- (aSakeMeta foo) which is equivalent to (aSakeMeta at: 'foo')

The instance variable 'order' remembers the order in which the elements have been added. The methods #withIndexDo: and #printOn: use this variable to iterate in the same order.

| s |
s := ReadWriteStream on: String new.
(self new a: 1; b: 2; yourself) storeOn: s.
s reset contents
--
Sake-Core/SakeTask

SakeTasks are typically defined as class side methods, which return an instance of SakeTask.

To obtain a list of available tasks, do "Senders of #define: "

MyClass-task1: aParameter

     ^ SakeTask define: [ :task |
                    task dependsOn: {self ruleL3.}.
                task if: [ <return true if action is needed> ].
        task action: [ <do something> ]
  ]

The 'unique id' of a task is the method context in which it is instanciated, and its paramters.
Therefore only one task should be instanciated per method.

Note: Sake tasks can have parameters, Rake tasks dont.

To execute a task...

(MyClass task1: 'param') run.

Results of the prior tasks are available via #results.

FAQ
====
How can I call one Sake task from inside another task?

Generally, if you want invoke one task from another task, the proper way to do that is to include the task to be invoked as a prerequisite of the task doing the invoking.

For example:

MyTasks-c-#taskPrimary

^ SakeTask define: [ :task |
  task dependsOn: { self taskSecondary }.
task action: [ self log sake: 'Doing Primary Task'. ].
]

MyTasks-c-#taskSecondary
^ SakeTask define: [ :task |
     task action: [ self log sake: 'Doing Secondary Task' ].
]

In this case, if the secondary task fails, the whole task stops.

Secondary tasks can also be passed to the ifBlock. In that case, if the task succeeds then the action is performed, if the task fails then the action is considered not needed.

^ SakeTask define: [ :task |
     task if: { self taskSecondary }.
        task action: [ self log sake: 'Doing Primary Task'. ].
]

Action, can also take a list of tasks.  
       
^ SakeTask define: [ :task |
    task action: {
                   self taskSecondary.
                     [ self log sake: 'Doing Primary Task' ].  "a block task"
                               }
].
    
       
--
Sake-Packages/Packages

Sake/Packages usage:

Definitions Search Path
============================
Packages named: 'PackageName'.

Will obtain a package definition. Subclasses of Packages are searched using the order defined by #findPath which is specified by #priority.

e.g. Packages findPath => {PackagesSqueak310 . PackagesDev . PackagesAll . PackagesSeaside29}

Packages-#priority is used to sort classes like so:

The class with defns for a relevant version (listed in #relevantVersions) => 100
The class with defns for dev version (PackagesDev) => 400
The class with defns for all versions (PackagesAll) => 500

Additional package "universes" can define their own priority in order to specify where to appear in the #findPath.
PackagesSeaside29
PackagesGjaller
PackagesBeach

Usage:
========
verbose usage specifying run style.

(Packages named: 'Seaside') run.  " or runQuietly, runStepping, runLogging"

#runStepping , - presents a confirm/debug dialog before each action.
#run            - default.
#runQuietly    - auto-confirms any SakeConfirm dialogs.
#runLogging   - Writes any SakeStop warnings to self log.

default usage:

Packages load: 'Seaside'.
Packages latest: 'Seaside'. "as above, but use latest versions of everything"
Packages unload: 'Seaside'.

multiples:

Packages load: #('Seaside' 'Magma' 'Logging') 

Unloading
========
Unloading comes in two variants.

Each package task loaded by Sake/Packages is remembered in the 'provided' list
If you perform:

    Packages unload: 'Seaside' .

    Packages unloadStepping: 'Seaside' .

Then the 'historical' unload scripts are used, as defined when the original load tasks were run.

If instead you perform:

    (Packages current named: 'Seaside') beUnloading runStepping.
 
Then the most recently defined unload script will be run.

Note: If packages such as "Magma server" and "Magma client" provides "Magma", then

    Packages unload: 'Magma'.

Will unload whichever of the two are loaded.
===
Misc notes...

Universes are using 'instance side' task definition, so the task extensions mechanism does not work in this context.

If a package appears in Packages under an obscure name, it can
tell the PackageInfo instance what name was used to load it via #mcName:

If a package has a version number with a '+' after it, then 'Packages upgrade' will always attempt to load the latest code, leaving Monticello to determine if there are any code changed that need to be applied.

To generate all of the methods based upon universes definitions:
       
        Packages taskGenerateAllUniverses run.
  or
        Packages taskGenerateAll  run.

--
Packages-Library/PackagesDevU

Package definitions for this version as obtained automatically from the Universes server.

To override the definitions in the univere add to my subclass in PackagesSqueak310

To re-read the package definitions from the universes server.

self taskGeneratePackageTasks run

--


Re: [squeak-dev] Terms of Reference: discussion is open

At 12:00 PM -0800 11/6/09, Eliot Miranda apparently wrote:
>On Fri, Nov 6, 2009 at 11:26 AM, Ken G. Brown <<mailto:kbrown@mac.com>kbrown@mac.com> wrote:
>
>At 7:15 PM +0100 11/6/09, Bert Freudenberg apparently wrote:
>>On 06.11.2009, at 18:46, Ken G. Brown wrote:
>>
>>>IMHO, such smart guys that are doing the majority of contributions to trunk could have figured out the way forward with Keith's established future methodology using Installer, Sake/Packages, Bob the Builder, MC 1.5/1.6 in about ten minutes. Some were already up to speed on the way forward. They could then have contributed fixes to the tools for that methodology where required and we would be now in the future instead of stuck in the past, forked yet again with the old trunk methodology (it's not a 'new' development model) that got us into the difficulties in the first place.
>>>
>>>Ken G. Brown
>>
>>If it all sounds so easy (which in fact it wasn't, neither for the board members nor the community at large half a year ago) then why don't you contribute a tool everybody can use to easily harvest Mantis fixes into Trunk? Or add Installer support for trunk development? Or set up a Bob server to churn out ready-built trunk images and test results? Or make a trunk image with MC 1.5/1.6?
>
>I believe you are looking at this the wrong way around. The trunk started at an old position.
>As you surely know, latest Installer, lpf and Sake/packages are already in the latest <http://ftp.squeak.org/3.11/Squeak3.10.2-lpf>ftp.squeak.org/3.11/Squeak3.10.2-lpf or <http://ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/>ftp.squeak.org/3.11/Squeak3.10.2-lpf-atomic/, ready to go for Bob the Builder. If the trunk additions were added to the latest, using Sake/Packages I believe we would have something. Andreas and I showed that the trunk repository gets quite far along loading into Keith's latest but with hacks required to overcome the divergence that trunk has taken. Someone with the intimate knowledge of what is going wrong could most likely fix the remaining issue/issues easily. Adding lpf, MC 1.5/1.6 etc. to trunk, just continues the divergence.
>
>
>>It may take you more then 10 minutes but *that* might get us moved forward even faster. Trunk development does progress fine, but we're all for improved tools and processes, so let's see them.
>
>You only need to look at Keith's documentation, videos, and emails to see where it is all at. He has explained this all in my opinion in enough detail over and over again.
>
>
>We've already been over this. A disparate set of communications is inadequate. It is too onerous to try and understand the system from a long and multi-media thread. This needs to be committed to some web pages, e.g. a wiki.
>

For a while (before trunk), I was saving pertinent emails to a blog at <http://squeaktipsandtrickswatch.blogspot.com/>. Some things have changed with Keith's stuff since but relatively minor I think. One could ask him if really interested.
Here is Keith's video from 4 months ago http://www.vimeo.com/groups/squeak/videos/5434330 showing how to use Sake/Packages to load AND unload Seaside 3.0.

Ken G. Brown

>Ken G. Brown
>
>
>>And now back to the discussion at hand, shall we? Otherwise please change the subject.
>>
>>- Bert -

Saturday, July 11, 2009

Monticello External Files Support

Date: Sun, 7 Dec 2008 13:04:33 -0600
From: "Sophie \(itsme213\)" <itsme213@hotmail.com>
Subject: [squeak-dev] Re: [Ann] Monticello15 File support (alpha)
To: squeak-dev@lists.squeakfoundation.org
Message-ID: <ghh6o2$l4d$1@ger.gmane.org>

Wow. That's great, I am looking forward to using this.

Thanks! -- Sophie

"Keith Hodges" <keith_hodges@yahoo.co.uk> wrote in message
news:493B593A.8030708@yahoo.co.uk...
> Seasons Greetings Everyone,
>
> Monticello 1.5 "FINALLY" supports files.
>
> I have set LevelPlayingField to load this new version of MC1.5 If anyone
> has any problems with it do let me know asap.
>
> Keith
>
> ========
>
> PackageInfo comment reads:
>
> External Files Support
> ================
>
> The default implementation of the two methods below considers all files
> and directories (with their contents) matching the package name to be
> part of the package.
>
> #externalFiles
> #externalFilesMatches
>
> e.g. package name 'Release'.
>
> files matching would include:
>
> Release.text
> Release/Introduction.text
> Release/Tutorial/ch1.text
>
> External Files Support - Monticello
> ========================================
> *Only file based repositories (i.e. .mcz files) are supported at present
>
> Since your external files will change far less than your code, it is
> recommended that you
> use a separate package to manage files in order to save space and time.
>
> Files are included in the .mcz (which is a standard zip archive)
> as files/* according to the pattern files/<uuid>/<path>/<to>/<file>
>
> *note: the uuid will change with every snapshot, it is unique to that
> file in that snapshot
> *note: in changes browsers the file is considered to be changed if the
> fileSize has changed.
>
> Snapshotting a package with files uses a temporary directory in
> package-cache/files
> The #flushCachedVersions menu item deletes this directory.

Sunday, March 08, 2009

[squeak-dev] [Ann] Bob has built!

[squeak-dev] [Ann] Bob has built!
Keith Hodges keith_hodges at yahoo.co.uk
Sun Mar 8 22:24:02 UTC 2009

Dear All,

The long awaited Bob, the image builder has been building away! When Bob
is building himself, he will be released as a one click image.

This email is intended to give you an idea of how he works, in order
that we can begin to develop useful scripts for building one-click
images, testing etc.

Bob Components
=============
squeaksource/Sake Sake-Scheduler = Package providing the ability to run
actions/tasks periodically
squeaksource/Sake Sake-Bob = Main image building tasks, based upon sake.
squeaksource/Bob-Releases = Package where we/you add your build tasks,
for distributed bob build/test servers to pick up.

How Bob works
============
There is a Bob build/test server running at http://bob.warwick.st you
can see what he has built and what he is doing by looking around that
site. He is also available via vnc display 1. User/password for ftp/vnc
is as for the swiki. If you are keen you can download the currently
running bob from http://bob.warwick.st/bob/home

Bob picks up his assignments from the Bob-Releases package, the
following is an example of a build instruction from that package.

Example Bob Build Tasks
===================

BobBuildDev>>#build0000

self name: 'Squeak3.10.2-dev'.
self dependsOn: { BobBuildBuildBase taskBuild }.
self when: true.

info by: 'Damien Cassou'.

self image:
'ftp://bob.squeak.org/release/Squeak3.10.2-build/release/*.zip'.

self linkRelease: false.

" info upload:
'ssh://updates@squeakfoundation.org/var/www/files/3.11/' , self name."
info upload: 'link:///bob/release/' , info name.

"http not yet supported"
info download: 'ftp://squeak@bob.warwick.st/bob/release/' , self
name.

self comment: 'Learning to breathe'.
""""""
Installer sake install: 'Squeak-dev image'.

========
In the above meta-data those lines sent to #self are meta-data items
that the framework knows about, those sent to #info are arbitrary
meta-data that Bob ignores but are included in *.info files that Bob
outputs.

#name - defines where the wip/output/release directories will be, and
what the final image and zip files will be named.

output will be written to:
/bob/output/Dev/build0000/<timestamp>/<timestamp>_Squeak3.10.2-dev.zip
/bob/output/Dev/build0000/<timestamp>/<timestamp>_Squeak3.10.2-dev.info
/bob/output/DevBuild/latest (symbolic link)
/bob/output/DevBuild/release (symbolic link)

The *.info file is the metadata filed out into a man & machine readable
format. Bob uses this to compare what he has already built, with what he
is being asked to build.

dependsOn: - uses the standard Sake method for defining dependencies,
i.e. references the actual task that is used for building the dependent.

#when: - true/false/#dont/aDateAndTime/aTimeStamp/aDuration/aFile -
specify a time to build, a period, or a file whose creation time is
monitored to see if it changes.

#image: - a match that will find one zip file in which an image is
available. The file may be a) local b) remote via ftp, or c) local in
the output tree having been generated from other tasks. b) remote files
are cached locally.

#imageCreationTime: aTime - if this field is specified then bob does NOT
poll the image file to see if it has changed. This is set so as not to
keep nagging ftp.squeak.org needlessly on images such as Squeak3.7-basic.

#linkRelease: true/false - indicates whether or not this is to be
designated a release via a symbolic link. Notice how the #image field is
picking up the latest "release" of 3.10.2-build via the "release"
symbolic link, rather than the "latest" symbolic link.

The result of the build is packaged into the
ftp://bob.warwick.st/bob/output directory tree, also visible via
http://bob.warwick.st/bob/output

#upload: aDirectory - a destination directory to send package in the
output directory to - options are:

1) ssh:// perform the upload via ssh (but not as part of the build, this
will be done by a separate uploading thread)
2) link:// perform the upload by linking the /bob/output/Dev/yymmdd-hhmm
to the bob/release/Dev/yymmdd-hhmm directory which may then be rsync'ed
to a mirror ftp site. This is the option that bob.warwick.st uses to
upload files to ftp.squeak.org, because the user that bob is running
under does not have access to ftp.squeak.org, but the user which
performs the rsync does. This allows bob.warwick.st to be made public
via vnc, without compromising the security of ftp.squeak.org
3) list:// perform the upload by adding the file to a list, which can
then be used as an input to rsync in an external process.
4) file:// perform the upload by copying the files to a directory locally.

#download: Bob will look at the download location to determine whether
or not an upload is required.

Multi-Bob-Collaboration
==================
For each instance of Bob the choice of targets to make is specified by
creating the output directory e.g. /bob/output/Dev. If the output
directory does not exist locally bob will not build that target.

Multiple distributed Bob's collaborate by using #image: that are
available via ftp, as generated by another bob. Thus your bob can wait
for my bob to release a new Dev image by pointing to
ftp://bob.warwick.st/bob/release/Squeak3.10.2-dev/release/*.zip Only
one bob should be designated as an uploader to the final ftp site (see
BobConfig and discussion about Configurations later on)

Multiple Bob threads on a single server collaborate by using the "locks"
described below. Within Sake a task can raise a SakeBlock exception,
Sake then trys to find another task that it can do in the meantime,
returning to the blocked task later on. If a Sake task discovers that
all of its dependent tasks are Blocked it too raises a SakeBlock
exception. If a bob thread finds his tasks blocked (i.e. in progress) he
will try again later.

Blocking - Multi-bob-collaboration
=========================
When a build is in progress this is indicated by a BUILD-IN-PROGRESS
link appearing in the output directory. When an upload is in progress
this is also visible in the output directory like so:
"090308-1316.uploading".

BobBuildImage - Starting Image
=======================
Minimum Requirements for the starting image:

Bob expects to find the image to build on, in a zip file, either locally
or on an ftp site somewhere.
The image simply needs to support the execution of a script (full path)
from the command line. There are no other minimum requirements.

Configuration of Bob
===============
The top of the class heirarchy is like so.

BobBuild -> BobConfig -> BobBuildImage

BobConfig is purely used for configuration options. You will need to
configure the parameters, such as :

#configSqueakVM - path to the vm
#configBaseDir - the base directory in which to work, default is set to
'/bob'.
#configPackageCacheDir - a directory that all built images may use for
their package-cache.

This allows you to define a local configuration and to save it simply by
filing out/in the class BobConfig.

Build Scripts
=========
There are two parts to the build script:

1) #theScript, and 2) metadata on the instance side as shown below.

A number of useful script methods have been defined for you. Each is
generated into a chunk of the script file that is handed to the image on
start up. This is an example #theScript.

BobBuildImage>>theScript

script reset.

self
scriptTranscriptLogToFileStart;
scriptAddLPF;
scriptAddInfoScript;
scriptTranscriptLogToFileStop;
scriptSaveImageAndQuit: true.

The line #scriptAddInfoScript appends any script chunks you defined as
an appendix to your metadata method: e.g.

""""""
"self halt."
Installer sake install: 'Squeak-dev image'.

Debugging
========
On the class side of each target, the methods #configStepNeeded
#configStepAction, and #configStepScript are available, if you set any
of these to true, it will halt at the appropriate place for you to step
through the process.

For debugging build scripts, the script is gnerated with a halt at the
beginning of each chunk.

Comments and Description
====================
The comment can contain arbitrary text.
The info metadata can contain any additional fields that you care to use.

However #comment and #description meta data fields are concatenated with
the comment and description of any dependent images.

enjoy

Keith

Thursday, February 12, 2009

[squeak-dev] ditching Monticello objects.

Keith Hodges keith_hodges at yahoo.co.uk
Thu Feb 12 22:09:40 UTC 2009

* Previous message: [squeak-dev] ditching Monticello objects.
* Next message: [squeak-dev] ditching Monticello objects.
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Adrian Lienhard wrote:
> ok, got it.
>
> Is there a way to load all the changes at once and/or get a list of
> the changes that are planned to go into 3.11?
>
> Adrian
There is a set of tasks in the Tasks package that highlighted about 100
fixes. However this is looking a bit untidy, and is being replaced by a
new system.

In mantis there are two new "status" levels, "testing" and "pending".

If you add an installer script to a bug report, switch the status to
"pending".

If you feel that that fix is ready to be included in 3.11 switch the
status to "testing".

All of the status - "testing" fixes will go into the 3.11-test-candidate
image when Bob performs the next build.
All of the status - "resolved" fixes fixed in "3.11" fixes will go into
the 3.11-release-candidate.

So you can both contribute to and determine what is due to go into 3.11
by querying mantis.

==
So if you want to see what fixes are in 3.10-build-candidate, search in
mantis for fixes with status "resolved" - and fixed in - "3.10bc"

regards

Keith


* Previous message: [squeak-dev] ditching Monticello objects.
* Next message: [squeak-dev] ditching Monticello objects.
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the Squeak-dev mailing list

Friday, January 16, 2009

Re: [squeak-dev] MC broken / how to update in 3.11 alpha?

Date: Fri, 16 Jan 2009 05:22:13 +0000
From: Keith Hodges <keith_hodges@yahoo.co.uk>
Subject: Re: [squeak-dev] MC broken / how to update in 3.11 alpha?
To: The general-purpose Squeak developers list
<squeak-dev@lists.squeakfoundation.org>
Message-ID: <49701985.5080108@yahoo.co.uk>
Content-Type: text/plain; charset=ISO-8859-1

Andreas Raab wrote:
> Hi -
>
> I was just doing some stuff in 3.10 when I decided to try the 3.11
> alpha. First of all, can we *please* rename the image to 3.11 instead
> of 3.10.2 "bc"? The reason being that 1) I've never seen the
> designation "build candidate" for any software project, and 2) it gets
> extremely confusing when you have to distinguish "3.10.2" (which works
> fine) from "3.10.2 bc" (which breaks). Much simpler to call 3.11 alpha
> what it is: 3.11 alpha.
But it isn't 3.11 alpha. it has no changes to the base image, except
what are required to support loading LPF and make a 3.10 base image
usable for building production images using Sake/Packages. It is
designated 'beta' because subject to last minute snags (ahem!) it should
be release quality. I used to call it 3.10.2LPF, We could call it
build-base, or anything you like except 3.11alpha.

The difference with this process and previous releases, is that this
release is planned, there is a design, the tasks are in place, they just
need fleshing out. (at least thats the theory), so when these tasks are
ready and applied for the first time, that is when we call things alpha.

In the alpha you will see, classes moved to different places to tidy
things up, some stuff removed, some stuff renamed, deprecated methods
removed etc. I have already written that bit.

The "process" involves defining sets of tasks to create deliverables in
parallel. The application of fixes will be what makes things potentially
unstable so I dont want to over do it with too many so hopefully we wont
stay in alpha too long.

3.10.2bc -> 3.11tc -> 3.11rc -> 3.11-test -> 3.11-light -> 3.11-fun
(build0 - nofixes)
-> 3.11tc -> 3.11rc -> 3.11-test -> 3.11-light ->
3.11-fun (build1 - 50 fixes) etc.

I am working on tasks to load fixes,
http://bugs.squeak.org/installer_export.php?project=Squeak only went
live yesterday. I also started harvesting edgars SqueakLightII script to
make a few more things unloadable to generate a 3.11-light etc.
> Anyway, enough of that. What I noticed in 3.11 alpha
It isnt 3.11 alpha, its a package of the tools I have been using to
produce production images for almost a year, with the addition of
Sake/Packages
> (no I won't call it 3.10.2 bc ;-) is that apparently Monticello got
> badly broken.
I didnt have this problem, I built an image on it so I have no idea what
is going on.

Keith