Squeak Tips And Tricks Watch

Fwd: Re: [squeak-dev] Cuis Development With Bazaar and LaunchPad

2010-02-13T16:40:00.001-07:00

>New video tutorial/demo uploaded.
>
>http://www.vimeo.com/groups/squeak/videos/9392990
>
>Keith

Juan et al,

I have settled on the name "InstallSeries" rather than InstallStreams, for my multiple update streams implementation.

The latest release of my personal "InstallSeries" is, revno 5, and is available from:

bzr branch lp:~keithy/cuis/stable-kph

some documentation follows

Keith

===========
>revno: 5
>committer: Keith Hodges <keith_hodges@yahoo.co.uk>
>branch nick: stable-kph
>timestamp: Sat 2010-02-13 23:00:39 +0000
>message:
> remove #presumeSentMethods, Initial SourceFiles refactoring

Contains:

doc0001SystemStartUpLaunch
"
1) The StartupManager is available via 'environment startupManager'.

2) Classes may access startup arguments without creating a dependency upon
StartupManager because the startUp process calls #startUp: resuming with: startUpManager
on each class.

3) Classes may choose from alternative parameter interpreting methods.
The default being: #argAtKey: aKey ifAbsent: block
"
doc0002SystemStartUpShutDownProcess
"
The startUp and shutdownLists are compiled by looking at all implementors of:
#startUpPriority and #shutDownPriority

Priorities are: #first #earliest #earlier #early #normal #late #later #latest #last

#hasImageMoved is available to determine if the image has moved since it was last saved.
"

doc0003SystemSources
"
Initial Refactoring of Sources access to be managed in the package System-Sources.

The ./Contents/Resources directory of a vm packaged as a one-click image, is now on the search path for the sources file.
"
doc0004PresumeSentMethods
"
Adopt an implicit means for allowing a method to declare itself as a presumed sent selector using:

self flag: #presumeSentSelector

"

Fwd: [squeak-dev] Cuis Development With Bazaar and LaunchPad

2010-02-13T15:09:00.002-07:00

New video tutorial/demo uploaded.

http://www.vimeo.com/groups/squeak/videos/9392990

Keith

Fwd: Re: [squeak-dev] [Cuis] LaunchPad to collaborate on Cuis2 development

2010-02-13T15:09:00.001-07:00

[resend with updated information]

>I started 2 open groups on LaunchPad.net
>
><https://launchpad.net/>https://launchpad.net/~rodents For those interested in collaborating on Cuis and derived images.
><https://launchpad.net/>https://launchpad.net/~smalltalkers - For anyone else.
>

Launchpad uses Bazaar2.0, I liked git for 1 day, but github doesnt offer open repositories, or open team projects, so it is back to the old faithful bazaar! Launchpad.net is very cool though.

We have two projects so far

<https://code.launchpad.net/cuis>https://code.launchpad.net/cuis
<https://code.launchpad.net/cuis-packages>https://code.launchpad.net/cuis-packages

To use - begin by making yourself a local working directory...

# mkdir Cuis2.0_trunk
# cd Cuis2.0_trunk

Runtime and One-Click template
=========================
Checkout the vm runtime - this is also a one-click image template for you to branch from, or help improve.

# bzr branch lp:~rodents/cuis/Cuis2.0vm.app

Incremental Kernel Development
==========================
Checkout the current Cuis2.0 kernel development repositories - these are the starting image and InstallStreams for incrementally moving the kernel forwards.

# bzr checkout --lightweight lp:~rodents/cuis/base
# bzr branch lp:~rodents/cuis/release
# bzr branch lp:~rodents/cuis/stable
# bzr branch lp:~rodents/cuis/unstable

1) cuis/base - the starting image to build on using InstallStreams

To check out Juan's original official release, rather than the most recent.
# bzr checkout --lightweight -r tag:Cuis2.0-0393 lp:~rodents/cuis/base test

2) cuis/release - the released updates (included in the release image)
This is intended to track Juan's official updates, which are tagged.
It also tracks ./base/Cuis2.0.1,image showing what it contains.

3) cuis/stable - branch & contribute back your tested updates here
In anticipation that these may get incorporated in the release by Juan.

4) unstable - branch & contribute your "being-tested" updates here

Unstable patches are not built by default.

The default search for updates is only 2 directories deep. In the unstable repository each contributed set of updates is published in a containing folder, and is 3 levels deep, escaping the standard search

"To apply a specific unstable update execute:"
InstallStreams updatesInstall: 'unstable/InstallStreams-testing'.

"To apply all unstable updates execute"
InstallStreams updatesInstall: 'unstable'.

Optional Kernel Innovations Development
=================================
InstallStreams providing optional kernel innovations may go in their own repositories, rather than release,stable, or unstable.

i.e. when you are ready to show the world...
# bzr push lp:~rodents/cuis/simple-namespaces
# bzr push lp:~rodents/cuis/pragmas
# bzr push lp:~rodents/cuis/nano-traits
# bzr push lp:~rodents/cuis/logging

Packages - Loadable with InstallStream
===============================
There is a separate project for sharing loadable packages.
In your working directory make a sub-directory for non-installed packages,
and checkout/branch your chosen packages there.

# mkdir packages
# cd packages
# bzr checkout lp:~rodents/cuis-packages/Installer

To manually load an individual package
InstallStream packagesInstall: 'packages/Installer'

To manually install all the packages you have checked out into ./packages
InstallStream packagesInstall: 'packages'

Generating the build
================
Juan's original release of Cuis2.0 does not appear to support the execution of a script on start up. So I have provided a modified image for you to begin with, this is called: (I should have called it 2.0.1-build or something less official looking, however if Juan doesn't mind, I will leave it as it is)

Cuis2.0.1.image

A simple script is provided in ./stable/build.sh which copies the ./base directory into your working directory giving you a known starting point, and then launches the image with ./stable/build.st. (on mac only for the moment)

A second simple script is provided in ./unstable/build.sh which launches the image with ./unstable/build.st.

enjoy

Keith

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

2009-12-13T14:11:00.000-07:00

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.

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

2009-12-12T12:09:00.001-07:00

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

2009-12-12T12:08:00.001-07:00

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

Planet Smalltalk

2009-11-26T18:39:00.001-07:00

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

2009-11-26T17:40:00.000-07:00

Nice overview from Tudor Girba on the Glamour browser framework.

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

Pharo Code Snippets

2009-11-26T17:15:00.001-07:00

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

Exceptions in Smalltalk - Book Chapter

2009-11-24T08:28:00.000-07:00

Torsten Bergmann: Exceptions in Smalltalk - Book Chapter (Torsten ()) http://astares.blogspot.com/2009/11/exceptions-in-smalltalk-book-chapter.html

Loading Seaside 3.0

2009-11-19T15:02:00.000-07:00

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

2009-11-19T15:00:00.000-07:00

A collection of scripts to build fancy development images
Lukas Renggli

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

Programmatically Run Lint

2009-11-19T14:58:00.000-07:00

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

More Installer and Sake/Packages documentation

2009-11-07T16:06:00.000-07:00

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

2009-11-07T10:49:00.000-07:00

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 -

Monticello External Files Support

2009-07-11T14:24:00.001-06:00

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.

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

2009-03-08T17:10:00.001-06:00

[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

[squeak-dev] ditching Monticello objects.

2009-02-12T15:16:00.001-07:00

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

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

2009-01-16T06:16:00.001-07:00

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

[squeak-dev] 3.11 deliverable no.1

2008-12-10T07:09:00.000-07:00

Date: Wed, 10 Dec 2008 06:19:18 +0000
From: Keith Hodges <keith_hodges@yahoo.co.uk>
Subject: [squeak-dev] 3.11 deliverable no.1
To: The general-purpose Squeak developers list
<squeak-dev@lists.squeakfoundation.org>
Message-ID: <493F5F66.6060500@yahoo.co.uk>
Content-Type: text/plain; charset=ISO-8859-1

Hello All,

The first result of the 3.11 effort is going to be an image that I have
called 3.10bc. Where bc stands for "Build Candidate".

The purpose of this image is to provide a base starting point for
everyone who would like to contribute to 3.11, and do image building
activities of any kind.

3.10bc is the first "fixed point", being essentially the stable 3.10
release, against which small projects can be carried out safely.

To if you were to test a bug fix, and I want to reproduce it, it will be
a case of taking 3.10bc and repeating your test.

3.10bc consists of, 3.10.2 + LevelPlayingField
(Monticello, PackageInfo, MonticelloConfigurations, Monticello-Files,
Installer-Launcher), and the latest of AtomicLoading, Universes,
SqueakMap, Sake/Packages, SUnit, and Tasks, together with some essential
fixes which support the above packages. Full details of the mantis bug
reports for those fixes are included in the image.

This "base" is generated and should be easily reproducible for any of
the images supported by LevelPlayingField. Some tools like SUnitGUI are
not backwardly compatible, BUT SUnit includes a non GUI TestReporter
which is.

Projects which can start based upon 3.10bc

A) Bug Harvesting

All the outstanding bugs on mantis can be assessed, in their respective
categories.

B) Image Tidying

C) Image wide adjustments renaming etc.

e.g.

_ to := revisited. == to = Transcript show -> self logCR:

D) Module Definition and Removal

Move classes into a category, make them into a monticello package, move
methods to become extension methods, and publish the package.

E) Validation of external packages, and getting more stuff to work

And many more I am sure.

3.10bc+fixes, from A above, will be a continuously moving target, for
those intending to build on top of 3.11, so instead we provide a 3.11bc
this will be 3.10bc + tidying, reorg and removals. But Not Bug Fixes.
This is an image that may be used as a second fixed point if preferred.

back to the day job for a few days for me I am afraid

Keith

[squeak-dev] [Ann] Installer now supports Mantis searching

2008-12-10T07:07:00.000-07:00

Date: Wed, 10 Dec 2008 06:06:47 +0000
From: Keith Hodges <keith_hodges@yahoo.co.uk>
Subject: [squeak-dev] [Ann] Installer now supports Mantis searching
To: The general-purpose Squeak developers list
<squeak-dev@lists.squeakfoundation.org>
Message-ID: <493F5C77.7090708@yahoo.co.uk>
Content-Type: text/plain; charset=ISO-8859-1

This facility is based upon the output of the csv export from Mantis.

M := Installer mantis. "keep the instance to avoid the table being gc'ed"

M searchCategoryCollections explore.
M searchStatusConfirmed.

M := nil. "let it go."

regards Keith

Re: [squeak-dev] Re: What is Forking Squeak

2008-12-09T23:29:00.001-07:00

Date: Wed, 10 Dec 2008 02:53:52 +0200
From: "Igor Stasenko" <siguctua@gmail.com>
Subject: Re: [squeak-dev] Re: What is Forking Squeak
To: "The general-purpose Squeak developers list"
<squeak-dev@lists.squeakfoundation.org>
Message-ID:
<4a5f5f320812091653j77f64d10o8e3398615034b6f0@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

2008/12/10 Hilaire Fernandes <hilaire@ofset.org>:
> Where I found Squeak is dramatically failing is at the core level.
> The list you have been writing is from projects at the periphery of Squeak.
> All those project are forks of Squeak, and each fork is the symptom of a
> difficulty for cooperation at the core level. I don't know why, I just see
> as all of you the symptom.
>
> The result is diluted energy, duplication of effort, incompatibilities, all
> the badness you got from fork.
>
> Try to imagine each Python based projects as a Python fork, you will hardly
> saw that as proof of success. More like a proof of failure.
>
> I think most of the problem come from the legacy of Squeak. Was Squeak
> designed to be a plate forme to develop on top of it other software? I don't
> think so. More like a great toy but it hardly scales when you want to do
> serious things. Then of course the complete lack of leadership in the
> Squeak community does not help to aggregate...
>
> Frankly I am suprised Squeak is still alive, is it? But in fact it does not
> matter as there are many forks out there.
>
>

+1 :)

That's why i think 3.11 team does right job.
We don't need just a yet-another-prebuilt-image, because it again will
lead to another fork (for those who don't see it - look at 3.8-3.10
fate).
We need tools for building images and integrate fixes/new/custom stuff easily.

Also, i think we should focus on making easy to plug-in / easy to
plug-out code with a little restriction(s) on kernel.
While its easy to say, hard to do - people who tried to refactor a
code to remove some global from use know what i mean. :)
I dreaming, to have image where i can load a compiler into image as
separate package, same for morphic & other stuff.

--
Best regards,
Igor Stasenko AKA sig.

[squeak-dev] Polymorph

2008-12-09T23:23:00.001-07:00

Date: Tue, 9 Dec 2008 15:39:55 -0000
From: "Gary Chambers" <gazzaguru2@btinternet.com>
Subject: [squeak-dev] Polymorph
To: "The general-purpose Squeak developers list"
<squeak-dev@lists.squeakfoundation.org>
Message-ID: <860A3A169FAB4176869BD2B29E0939C7@GuruVista>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original

Just to lets everyone know that Polymorph has been updated on SqueakSource.
(never had any joy with the announcements list...)
More fixes etc. The Watery2 theme is starting to look pretty cool now.

After a few weeks of feedback I'll update the dev Universe.

Wiki: http://wiki.squeak.org/squeak/6005
SqueakSource: http://www.squeaksource.com/UIEnhancements/

In use with 3.9.
Not tested with 3.10, though should be ok.
A little further on than the current Pharo version.

Regards, Gary.

Re: [squeak-dev] Waiting for 3.11 artifacts.

2008-12-09T23:19:00.000-07:00

Date: Tue, 09 Dec 2008 13:00:36 +0100
From: G?ran Krampe <goran@krampe.se>
Subject: Re: [squeak-dev] Waiting for 3.11 artifacts.
To: The general-purpose Squeak developers list
<squeak-dev@lists.squeakfoundation.org>
Message-ID: <493E5DE4.10508@krampe.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi all!

First of all - great thread!! :) I could ask questions and comment on
hundreds of things but I am letting the current people hash it out for
now. One thing I would like someone to do though is to "distill" this
thread into at least a Swiki page on the Squeak Swiki! :)

But a bit of comments anwyay:

Keith Hodges wrote:
> Jerome Peace wrote:
>> I personally do not want to have to understand what is on the pbwiki or to navigate keith's new ways of doing things in order to play and test out a new squeak image.
>>
>> What unsettles me at the moment is that two very powerful programmers are taking 3.11 in some very new directions relative to what the community is used to.
>>
> The alternative was officially nothing. I piped up when the board were
> considering cancelling 3.11
>
> So anything is better than nothing, perhaps?

Indeed and I have repeatedly asked for a clarification on the 3.11
status and how "official" it is! Now I hope it is FULLY official and
that Matthew (?) is the release team leader.

>> While I have a great respect in Matthew's judgment and ability to explain what he is doing, I have found from experience that Keith's notions are more of a gamble.
>>
> So far, I am quite pleased to say that everything I have put my hand to
> has worked really well.
>
> But this comment indicates to me that you really dont "get it" yet.
>
> The whole deal with this 3.11 project is not about delivering an image,
> its about addressing a need, through putting a philosophy into practice
> across the board. The 3.11 goal is to showcase the tools that make that
> philosophy possible. While the tools are not ready there is no 3.11
> (fortunately the tools are getting there and there will be a 3.11)

Many of us who have been around for a while know that we have tried
numerous approaches over the years and we know that many of these have
failed due to various reasons. For example, the idea of "harvesting" and
having so called "harvesters" failed because it only led to a few people
burning out (in the very early years it "worked" because we had paid
people doing the harvesting).

So such a model is not viable IMHO. We need to move and try other routes
- and I for one applaud the current effort in 3.11 and will try to chip
in wherever I can.

> The need is definitely there, and the philosophy aiming to meet that
> need has been operating well for almost a year now. That's not a gamble
> at all, its already happening.
>
> Edgar has delivered image after image, but does that help anyone in the
> long run really. It doesn't help me. I have production code and I don't
> have time to spend a month moving it form one image to another manually,
> without any tools to help, broken MC, broken Universes etc. It doesnt
> help us move forward in the future to something like Morphic 3.0, or COG
> for which atomic loading is likely to be essential.
>
> Real World Example:
>
> As an example, Gjallar was working in 3.8, there is no technical
> compelling reason to move the huge code base over to 3.10. It doesn't
> offer any must have new features. The only reason for moving is to be
> able to keep up for the sake of it. So into this situation comes
> Installer, Gjallar migrates to use Installer for its build scripts
> (July2007). Once Installer is used, the build script can be run in 3.7,
> 3.8, 3.9, 3.10, Sophie, Croquet or Etoys. Installer proves the common
> ground that is essential to move forward, even though that move didn't
> take place for almost a year, the Gjallar team knew that they were no
> longer a fork, because they had the tools to make keeping up possible
> and straight forward.
>
> So did Gjallar move to 3.10 because of the 3.10 image features, or
> because Installer and LevelPlayingField helped make it a smooth
> transition? Gjallar is a fork no more. Which of 3.10/Installer is
> really contributing most to moving the community forward? I would say
> that Installer is doing a damn fine job for a little tool.

Yes, we made the move just recently of Gjallar over to 3.10 and adjusted
our Installer script to use LPF etc. It worked really well and we did it
mainly because we don't want to be left out on the improvements/fixes
pouring in. All in all Installer is a great tool making "image building"
quite easy. Combined with Sake/Packages (modulo having not used it yet)
I presume it gets even more powerful.

A trivial example from Gjallar: We include fixes available on Mantix
using Installer "oneliners". We don't need to wait for someone else to
harvest it, get it into the image etc etc.

[SNIP]
> The important thing is that all of the contributions to that 3.11 are
> also available to all other image users. So you don't have to wait for a
> 3.11 image to partake of the new wine.
>
> Its not really a gamble its a coherent strategy to implement what Goran
> had as a vision, multiple update streams, but in a different form.
> Different experts can contribute different tasks managed in Monticello.

Yes, we share the same understanding of where we are right now - the
Squeak world is already "forked" in several directions. We need to get
mechanisms in place to cope with that. I still hope to be able to move
DeltaStreams forward (time, time, time...) but the important thing is
that we are several who share the understanding of the core problem.

> Dont Panic

Hehe, I like it! :) Remember folks - we are all in this for fun! Matthew
and Keith (and several others of course) have made huge contributions
over the last year, and I am extremely grateful for that.

I hope to be able to pull my share mainly related to SM.

regards, G–ran

Re: [squeak-dev] Re: Waiting for 3.11 artifacts.

2008-12-09T23:13:00.001-07:00

Date: Tue, 09 Dec 2008 12:00:33 +0000
From: Keith Hodges <keith_hodges@yahoo.co.uk>
Subject: Re: [squeak-dev] Re: Waiting for 3.11 artifacts.
To: The general-purpose Squeak developers list
<squeak-dev@lists.squeakfoundation.org>
Message-ID: <493E5DE1.4000909@yahoo.co.uk>
Content-Type: text/plain; charset=ISO-8859-1

Hi Andreas,

Thanks for having a go!
> Obviously. We all have to make a living ;-) But in the meantime we
> should see if we can redistribute the work or adjust the goals to
> reflect the realities
volunteers?
> we're encountering. One of the reasons why I have proposed in the past
> to only include work that was completed previously is to avoid
> situations where some individual needs to make adjustments to their
> situation. From what you say I can only guess that there are parts of
> the 3.11 proposal that critically depend on you and that you won't
> have the time to work on for the foreseeable time. Would it make sense
> to adjust the plan towards that end?
>
>> Nevertheless the goals were stated in the paper that Matthew presented
>> to the board, and those goals have been worked upon and stuff is in the
>> process of coming online.
>
> By "the paper" I presume you mean
> http://installer.pbwiki.com/Squeak311Proposal ?
>
yes
>>> 2. What are the goals for 3.11? I have seen references to
>>> http://installer.pbwiki.com/311 - is this "the place" for it? (again
>>> yes/no/perhaps are all good answers, I just want to make sure we're
>>> using the same frame of reference)
>> "THE" place of reference is the 311-Proposal accessible from that page.
>
> I have found the following three pages:
> http://installer.pbwiki.com/311
> http://installer.pbwiki.com/Squeak311
> http://installer.pbwiki.com/Squeak311Proposal
> Is this it or are there other places that I'm missing?
Thats it.
>> Matthew might update things in the next week or two.
>>> 3. Where are we in the process towards these goals? Both from a
>>> high-level perspective as well as the nitty-gritty details of things
>>> that don't work but need to be addressed for a release.
>> Many of the parts are in place. We are waiting for Bob to bring them all
>> together, Bob was waiting for Rio to support ftp seamlessly.
> Could you be a little more precise about which parts are in place? The
> above three pages list lots of stuff and it is very difficult to
> understand how much progress has been made where, what dependencies
> remain and where (on a percentage or similar base) we are in the process.
>From - http://installer.pbwiki.com/311

1. Start with 3.10 LPF - [ works well ]
2. Sake and Tasks - [ loading is now in Packages item 5 ]
3. Do SetPreferences-Squeak3:10 [ is a roadmap task ] [background
color is set for image type tc/rc/u etc ]
4. Add 311-KernelExtensions - as version managed Sake/Task [ Being
broken down into mantis fixes ]
5. Packages [ working well - Matthew thinks we need a UI ]
6. Do Reorganize-Squeak3:10 [ in progress ]

[ Manual Fixes - we have 80 or so in the system, as you pointed out
Installer is struggling with .gz extension
but that is a trivial thing to fix ]

[ Plan to automate more of the fixing process - We have "Mantis" code
which reads Mantis periodically for Bob
Mantis will generate tasks for applying fixes according to status.
(1/2 day) ]

[ Mantis review - 1 week initially - then how long is a piece of string
- (850 unresolved issues to go) ]

7. Do Latest
1. MinorFixes-Squeak3:10 - as version managed SakeTask
2. MajorFixes-Squeak3:10

3. PackageUpgrades [ task present in road map - complete? ]

[ 8 Same as 7 only Unstable ]

8. Optionally Do LatestUnstable
1. MinorFixesUnstable-Squeak3:10
2. MajorFixesUnstable-Squeak3:10
3. PackageUpgradedUnstable

9. DeprecatedMark-Squeak3:10 - mark deprecated
10. DeprecatedClean-Squeak3:10 - remove stuff that was deprecated in
3.9/3.10 [done]
11. Save Packages [done]
12. Clean-Squeak3:10 - remove stuff that is old or can be reloaded [
Some done - sufficient to be an example ]
13. Strip-Squeak3:10 - back to minimal [ Some done - sufficient to be
an example ]

>>> 4. How does one best track progress for 3.11? Is there an update
>>> stream? Are there Monticello releases? Mantis entries? Installer
>>> scripts? Alpha images? All of them?
>> 1. packages@lists.squeakfoundation.com - receives emails of all of the
>> monticello package commits for the components that contribute to 3.11
>
> I've briefly looked at it and I don't understand the purpose. There
> seem to be hundreds of commit messages about Monticello, Installer,
> Packages, Sake, Tasks etc.
Given that our goal is to put in place a process for generating images
with Bob. Take for example the step of loading a workspace with a ReadMe
and an Introduction Release Notes etc. These steps have been done
manually for years, and there is no Monticello cabability for
collaboratively managing text files, and Workspace is hopeless at
saving/loading files

So...

The Commit Messages you see are:

Monticello - Adding files support.
Installer - This is a brand new Installer implementation with the same
API (thanks to Matthew)
Tasks - thats what is specifying the build so adding a Packages beta
unload: 'Kernel-Tracer'. to a task is matched by.....
Packages - adding a PackagesBeta-#KernelTracer entry
> And zero about Kernel, System, Graphics etc. Which doesn't look like a
> 3.11 commit list but rather like a KPH-dev list ;-) (nothing wrong
> with that but in terms of tracking 3.11 progress I would expect to see
> just as much traffic in other areas)
The fixes applied are not commited until the first step of the
taskRELEASECANDIDATE (see previous road map email) and we havent been
there for a while.
>> 2. release@lists.squeakfoundation.com - discussion on the release
>> (though irc is our preferred means of communication)
> If you don't mind, can we have these discussions on Squeak-dev? I
> never liked the idea of "private" release lists too much - I think the
> release is the most important artifact produced here so why not
> discuss it out in the open so that people can follow along?
I do mind actually for various reasons (private mail)
>> 3. www.squeaksource.com/Tasks - has the actual build tasks, the roadmap
>> is embodied in this code. This is where you can contribute tasks, or
>> define your own personal test builds for Bob to build and test for you
> How does one read this? When I look at the code there is a
> taskRELEASECANDIDATE which (from what I can tell) unloads a bunch of
> packages, unloads the tests and that's it. No fixes, no loading of any
> of the new stuff you were referring to above? Or am I misreading this?
taskTESTCANDIDATE is run first this generates a version of 3.10 with
stuff added

taskRELEASECANDIDATE starts with the output of taskTESTCANDIDATE and
just tidies it up and updates the version number.
>> 4. www.squeaksource.com/Packages - loading and unloading packages, this
>> is where you can contribute knowledge about what works where, AND how to
>> unload things. e.g. "Castrait" (see previous mail) could be published
>> here, as could SqueakByExample. Recent addition include a Kernel-Tracer
>> unload, and a Null unload, a ProcessSpecific unload, AllTests (hunts
>> down tests for the loaded packages), and Tasks (loads tasks for this
>> version and the next)
> Again, I'm not sure what exactly I'm seeing here.
Most of the load/unload scripts are handled by the #defaultAction which
simply uses the data supplied in

self info url: 'http://host/project/package-author-1.mcz'.

Any lump of code that can be moved into a package is committed to
squeaksource.com/311 and gets an entry in Packages, probably in
PackagesDev, or PackagesBeta, so that it can be reloaded. If we would
rather keep that lump in the release, it gets an entry in Packages so
that it can be unloaded easily later.
>> 5. A Mantis revival is on the way. There will be some queries for you to
>> see progress on bug fixing very clearly.
>
> That would be very useful.
>
>> 6. Image build script is Installer installUrl:
>> 'http://installer.pbwiki.com/311'. When it completes (it used to) we
>> will publish an image.
>
> Thanks, I'm running it now.
>
>>> 5. How does one best contribute to 3.11? (both, for more long-term
>>> continued development as well as the ten-minute scratch-an-itch kind
>>> of exercise)
>> a. Small fixes and Additional Tests - ChangeSet on Mantis, AND an
>> Installer script on mantis.
>> b. Bigger Kernel contributions add your task to ReleaseSqueak310, and
>> add it as a dependency, or step to one of the build steps.
>> c. Kernel contributions can be made as a monticello package which is
>> merged into the kernel by a task.
>> d. Unloading stuff - changeset on mantis, and unload script in Packages
>> e. Knowledge of what loads where (basic dependencies -> Universes)
>> anything more Packages
>> f. Tutorials/Readmes/Intrductions use the MC files feature to put the
>> files under monticello, and add a corresponding Packages entry for
>> load/unload
>> g. Build scripts for Bob, particularly the OneClick image
>>> I think that maybe one of our problems here is that we lost a little
>>> track of what exactly the goals for 3.11 are and where we're in the
http://installer.pbwiki.com/Squeak311Proposal

The only goal left in that page to be completed is Bob, and underscores
in selectors.

The goals for 3.11 are fundamentally based around getting Bob working,
and to showcase a release being built with Bob.
The more work is done on the image stuff the less work is done on Bob.

[ Bob status - Bob is probably less than 1 perfect working day away from
release ].
>>> process relative to those and I think get some clarity on that might
>>> help for future steps.
>> hope that helps a bit
>
> It sure does.
>
> Cheers,
> - Andreas
thanks for having a go.

Keith

#Squeak - 20081209 - 11:09

2008-12-09T16:45:00.001-07:00

matthewf
:
keithy: I think what I'll do is write up a "how to contribute" policy document, with instructions on making packages, bug fixes, how fixes get applied to packages, how to generate a release, and whether patches are applied at build time, or upstream
[
11:09am
]
matthewf
:
then you, I, and Ken can ratify it on the release list
[
11:09am
]
matthewf
:
then present it to squeak-dev
[
11:10am
]
keithy
:
I am aiming to release the "build candidate today
[
11:10am
]
matthewf
:
what is a build candidate?
[
11:10am
]
keithy
:
its the base we are starting from
[
11:10am
]
keithy
:
its the build up to the point where the fixes start to get applied
[
11:11am
]
matthewf
:
ok
[
11:11am
]
keithy
:
i.e. LPF + updates SM, Universes
[
11:11am
]
keithy
:
so its basically 3.10+LPF+Packages+Tasks
[
11:11am
]
keithy
:
so its basically 3.10+LPF+Packages+Tasks+UNiverses+SqueakMap+SUNit-improved
[
11:12am
]
keithy
:
all existing packages in the image are upgraded
[
11:12am
]
matthewf
:
maybe you should write up what it is on the wiki
[
11:12am
]
keithy
:
it would make a good candidate for 3.10.3
[
11:12am
]
keithy
:
sure
[
11:13am
]
matley left the chat room. (Read error: 110 (Connection timed out))
[
11:14am
]
matthewf
:
so, is it about time to bring 3.11 out of hiding, you would say?
[
11:14am
]
matthewf
:
before mc1.6 is ready?
[
11:14am
]
keithy
:

erm... bring it to the point where contributors like jerome know what is going on from their point of view

Re: [squeak-dev] Re: Waiting for 3.11 artifacts.

2008-12-09T16:06:00.001-07:00

At 4:00 AM -0800 12/9/08, squeak-dev-request@lists.squeakfoundation.org apparently wrote:
>Date: Tue, 09 Dec 2008 06:54:31 +0000
>From: Keith Hodges <keith_hodges@yahoo.co.uk>
>Subject: Re: [squeak-dev] Re: Waiting for 3.11 artifacts.
>To: The general-purpose Squeak developers list
> <squeak-dev@lists.squeakfoundation.org>
>Message-ID: <493E1627.305@yahoo.co.uk>
>Content-Type: text/plain; charset=ISO-8859-1
>
>Andreas Raab wrote:
>> These are *excellent* thoughts. Perhaps we can get a bit more clarity
>> by summarizing the answers to the following questions (apologies if
>> this amounts to repeating things that have been said many times before):
>>
>> 1. What is the current status of 3.11 - has work on it "officially"
>> started? (yes/no/dunno are all fine answers here; I'm trying to
>> establish the basics in terms of where in the process we are)
>I have held back from saying it is "officially" started, due to pressure
>to deliver on work deadlines, which have suffered due to my extreme
>domestic pressures recently. Home life has returned to normal but still
>my paid work is a priority.
>
>Nevertheless the goals were stated in the paper that Matthew presented
>to the board, and those goals have been worked upon and stuff is in the
>process of coming online.
>> 2. What are the goals for 3.11? I have seen references to
>> http://installer.pbwiki.com/311 - is this "the place" for it? (again
>> yes/no/perhaps are all good answers, I just want to make sure we're
>> using the same frame of reference)
>"THE" place of reference is the 311-Proposal accessible from that page.
>
>Matthew might update things in the next week or two.
>> 3. Where are we in the process towards these goals? Both from a
>> high-level perspective as well as the nitty-gritty details of things
>> that don't work but need to be addressed for a release.
>Many of the parts are in place. We are waiting for Bob to bring them all
>together, Bob was waiting for Rio to support ftp seamlessly.
>> 4. How does one best track progress for 3.11? Is there an update
>> stream? Are there Monticello releases? Mantis entries? Installer
>> scripts? Alpha images? All of them?
>1. packages@lists.squeakfoundation.com - receives emails of all of the
>monticello package commits for the components that contribute to 3.11
>
>2. release@lists.squeakfoundation.com - discussion on the release
>(though irc is our preferred means of communication)
>
>3. www.squeaksource.com/Tasks - has the actual build tasks, the roadmap
>is embodied in this code. This is where you can contribute tasks, or
>define your own personal test builds for Bob to build and test for you
>
>4. www.squeaksource.com/Packages - loading and unloading packages, this
>is where you can contribute knowledge about what works where, AND how to
>unload things. e.g. "Castrait" (see previous mail) could be published
>here, as could SqueakByExample. Recent addition include a Kernel-Tracer
>unload, and a Null unload, a ProcessSpecific unload, AllTests (hunts
>down tests for the loaded packages), and Tasks (loads tasks for this
>version and the next)
>
>5. A Mantis revival is on the way. There will be some queries for you to
>see progress on bug fixing very clearly.
>
>6. Image build script is Installer installUrl:
>'http://installer.pbwiki.com/311'. When it completes (it used to) we
>will publish an image.
>> 5. How does one best contribute to 3.11? (both, for more long-term
>> continued development as well as the ten-minute scratch-an-itch kind
>> of exercise)
>a. Small fixes and Additional Tests - ChangeSet on Mantis, AND an
>Installer script on mantis.
>b. Bigger Kernel contributions add your task to ReleaseSqueak310, and
>add it as a dependency, or step to one of the build steps.
>c. Kernel contributions can be made as a monticello package which is
>merged into the kernel by a task.
>d. Unloading stuff - changeset on mantis, and unload script in Packages
>e. Knowledge of what loads where (basic dependencies -> Universes)
>anything more Packages
>f. Tutorials/Readmes/Intrductions use the MC files feature to put the
>files under monticello, and add a corresponding Packages entry for
>load/unload
>g. Build scripts for Bob, particularly the OneClick image
>> I think that maybe one of our problems here is that we lost a little
>> track of what exactly the goals for 3.11 are and where we're in the
>> process relative to those and I think get some clarity on that might
>> help for future steps.
>hope that helps a bit
>
>Keith