Release October 2008

release@lists.squeakfoundation.org

4 participants
8 discussions

Monticello 2
by Matthew Fulmer 30 Oct '08

30 Oct '08

Hi. I saw on Lukas's Esug presentation that Monticello 2 is recommended for Seaside development because it is supported on all of the Smalltalks that Seaside is available on. I was not aware of this; I thought Monticello 2 was still in the alpha phase, didn't yet support remote repositories, and only worked on Squeak. I must have missed something. Where can I find out more about Monticello 2? Here is what I am referring to: Slide 58: http://www.lukas-renggli.ch/blog/seaside-presentation-esug2008 Minutes 28-31 of the talk: http://www.cincomsmalltalk.com/blog/blogView?showComments=true&printTitle=L… -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

2 2

MC1.6 Problem #compilerClass not supported/supportable
by Keith Hodges 26 Oct '08

26 Oct '08

keithy_: ClassEditor compilerClass is Compiler so ignoring any custom #compilerClass [02:26] keithy_: so... mc1.6 cant load Tasks [02:27] keithy_: or anything that takes advantage of SakeCompiler [02:30] keithy_: and of course SakeCompiler is not yet loaded in the atomic loading scenario [02:31] keithy_: this makes things a bit trikkey [02:31] rudolph99 joined the chat room. [02:31] keithy_: no one can use compilerClass [02:33] keithy_: so it looks like methods that fail to compile with the default compiler need to be compiled after the atomic load

2 1

Some Bob docs
by Keith Hodges 26 Oct '08

26 Oct '08

Some introductory docs Keith ======= * Bob the Builder* */ Your Build is defined as a Class/* To add your own 'Build' process to Bob, create a subclass of BobBuild, with your process defined as a SakeTask returned from the class method #build. When Bob starts his work in BobBuild-c-#taskMain, he collects all of these tasks, and sorts them according to their dependencies. /* Your build can depend upon other builds*/ So your build can specify which other builds it depends upon, for example: BobBuildMyWebServer-#build ^ self define: [ :task | task dependsOn: { BobBuildSeasideOneClick build }. .... ... ... ]. /* Repositories are watched and builds run when changes are spotted*/ Sake-Scheduler is used to run periodic tasks. These tasks can do many useful things, as well as running #taskMain. Scheduled tasks are used to: 1. Periodically collect data that either Bob/users may need in their work (e.g. BobPeriodicallyReadMantis ) 2. Periodically update the Bob server image with the latest code from contributors (e.g. BobPeriodicallyWatchRepositories ) You can add your own periodic tasks by subclassing ScheduledTask, however some tasks are designed to be extended, by adding (extension) instance methods. e.g. BobPeriodicallyWatchRepositories-#taskWatchPackages (watches the squeaksource Packages repository for updates) if you wish to invoke bob following an update to your repository this example shows how. BobPeriodicallyWatchRepositories >> #taskWatchTasks ^ SakeTask checkUrl: 'http://www.squeaksource.com/Tasks/feed.rss' onChanged: [ Installer sake install: 'Tasks'. BobBuild taskMain run. ]. /* Configuration*/ Your build process 'task' is defined on the class side of your Build class. If your task has a number of "const" parameters that configure the task, these should also be defined on the class side. For example, the location of a working directory would be returned from #configWorkingDir /*Metadata - build numbers etc*/ The metadata for each Build task is specified on the instance side of the class, e.g. #build0001, #build0002. Your task definition in #build is automatically uses the most recent metadata method. example metadata: MyBuild>>#build0001 info name: 'Squeak3.11-basic'. info moniker: '311'. info codeName: 'Kipper'. info by: 'kph'. info image: 'bzr://bzr.warwick.st/squeak/3.10'. info candidate: false. info release: false. info overwrite: true. info comment: 'testing'. /*Only build if necessary*/ It is very important that your build only runs when absolutely necessary. If your build is manually invoked by an increment in build number (i.e. info overwrite: false) then the existence of the output directory with that build number is enough to determine that the build has already been run. If your build is automatically invoked by updates to particular repositories, then the versions of those packages need to be recorded in the metadata. The metadata is written to a file in the output directory. Subsequent builds should compare the current metadata with that in the file to see whether the build needs to be re-run. If your build is a derivative of a released product, then you only need to build if the dependant has #info release = true.

1 0

Re: [Release] Installer refactor review
by Matthew Fulmer 09 Oct '08

09 Oct '08

I refactored Installer into 14 classes. Reviewing this change via Monticello is impossible, so here is a snapshot of Installer-Core-kph.232 side-by-side with Installer-Core-mtf.233. Use your favorite diff tool to compare them. I recommend vimdiff -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

1 0

Installer refactor
by Matthew Fulmer 09 Oct '08

09 Oct '08

You may have noticed me doing something fishy in the Sake repo with the package Sake-Installer This package is just a copy of Installer, but named SakeInstaller. It is in the Sake repo because I'm planning to rewrite Installer to use Sake, and this is preliminary work for that. I am dividing Installer up into 14 classes: Installer (abstract) InstallerMC InstallerUniverses InstallerInternet (abstract) InstallerWebBased (abstract) InstallerFile InstallerUrl InstallerWeb InstallerMantis InstallerSM InstallerWebSM InstallerSake InstallerUpdateStream InstallerCruft (leftovers) I have finished all but InstallerFile, InstallerSake, and InstallerUpdateStream I am doing the refactore entirely in vim, so that I can easily compare old and new versions, using vimdiff. Monticello's diff doesn't work when methods are moved or renamed. I have not removed any methods, although I did add and modify a few in order to keep Installer working. Most importantly, Installer still uses the same syntax as it did before to install stuff, so, sans bugs, existing Installer scripts will still work. Once I finish the refactor in the Sake repo, I'll rename the classes to the names listed above. I'm not sure what to do after that, though. I don't want to commit it to the Installer repo, as it is not stable and may break for anyone who does an Installer upgrade. I could commit it under a different package name, like Installer-splitup. Next, I'll need to test it. I plan to do that by replacing http://installer.pbwiki.org/f/Installer.st with this split up version, with a self notify: 'LPF is probably broken. try again later', then making sure LPF runs in every image I can get hold of. After LPF works in all the images, I'll commit the splitup Installer into the mainline Installer branch. This will cause some down time for LPF, but I don't know of a better way to test this and get it into production. Can I do that? -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

1 1

Monticello and ToolBuilder
by Matthew Fulmer 07 Oct '08

07 Oct '08

Hi Keith. I've been trying to reach you on IRC for the past couple of days with this issue, but I couldn't. Perhaps I should have just sent this email to start with. Anyway... Monticello has a kinda funky infrastructure for making its UI's. It uses ToolBuilder when it is available, and when it is not, it falls back to a half-clone of ToolBuilder implemented in MCTool and MCToolBuilder. This was made in (I believe) the Squeak 3.6 days, when ToolBuilder was new. Now, you can hardly get an image without ToolBuilder. 3.9, 3.10, Pharo, and Croquet all have ToolBuilder. 3.8 and Etoys do not. I discovered this by tracing a bug with the dual repo browser in my Etoys image. The center pane of the tool uses a ToolBuilder "panel", which is not implemented by MCTool. So, the dual repo browser does not work in images without ToolBuilder. I installed the Croquet version of ToolBuilder into my Etoys image, and everything worked fine. (I had the croquet version handy). So, there are two ways to fix the issue with the dual repo browser. One is to expand the emulation done by MCTool to cover "panel". The other is to make MC depend on ToolBuilder, add ToolBuilder to LPF, and start deleting MCTool's emulation. I like the second option the best. ToolBuilder (especially the existence or non-existence of UIManager) is one of the bigger API differences between 3.8 and 3.9 images, so I think putting ToolBuilder in LPF makes it a bit more "leveling". What do you think? -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

2 1

Installer LPF woes
by Keith Hodges 02 Oct '08

02 Oct '08

The latest Installer, retries if pbwiki gives a "too busy" message. However, it appears that this is still not good enough! I have emailed support, again Keith

2 1

Organising Fixes
by Keith Hodges 01 Oct '08

01 Oct '08

Name: Tasks-Squeak310-kph.11 Comment: Organised Tasks to conform to the hierarchy of "Mother Of" bug reports on mantis. I have organised the tasks to reflect the structure of the "Mother Of" reports so that we can modularise our work a bit. It means that in generating 3.11 all Morphic fixes will be loaded as a batch together, starting from... #taskMotherOfUIMorphicCleanUp It would be nice if we could work towards filling in the tasks in the next few weeks. I will attempt to adopt this structure more widely, though it is probably not necessary to maintain an explicit "MotherOf " page for everything in Mantis itself. best regards Keith

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Release October 2008