Release

release@lists.squeakfoundation.org

59 discussions

Re: [squeak-dev] Forking
by Keith Hodges 08 Dec '08

08 Dec '08

> I am most curious about what will happen to 3.10 when 3.11 is released. > > Thanks, > TimJ Here is the theory! In an LPF image: Installer install: 'Tasks'. The main workflow is summarized in the following releases generated by the following classes/tasks which need to be fleshed out. Squeak 3.11 Personal Test Candidate - ReleaseAfterSqueak310Kph-#taskTESTCANDIDATE. Squeak 3.11 Unstable T.C. - ReleaseAfterSqueak310Unstable-#taskTESTCANDIDATE. Squeak 3.11 Stable T.C. - ReleaseAfterSqueak310-#taskTESTCANDIDATE. Squeak 3.11-basic Release Candidate - ReleaseSqueak311-#taskRELEASECANDIDATE. Squeak 3.11-basic Golden - ReleaseSqueak311-#taskGoGolden. Derived images Squeak-3.x-dev - Packages current load: 'Squeak-dev image'. (czar: damien, should already work in 3.9+) Squeak-3.x-web - Packages current load: 'Squeak-web image'. (ditto) Squeak-3.x-devbeta - Packages beta load: 'Squeak-dev image'. (ditto) Squeak-3.x-webbeta - Packages beta load: 'Squeak-web image'. (ditto) Squeak-3.x-fullbeta - Packages beta load: 'Squeak-full image'. (czar wanted) Squeak-3.x-full - Packages current load: 'Squeak-full image'. Squeak-3.x-max - Packages current load: 'Squeak-max image'. (czar wanted) Squeak-3.x-fun - tba (czar wanted) Squeak-3.x(-*whatever*)-test - Packages current load: 'AllTests'. (loads tests into any image Squeak-3.x-seaside - Packages current load: 'Squeak-seaside image'. Squeak 3.x-(*whatever*)-oneclick - ReleaseX-taskGenerateOneClick. Squeak 3.11-minimal - Release311-#taskMINIMAL Squeak 3.11-kernel - Release311-#taskKERNEL Squeak 3.11.1-basic - Release311-#taskUPDATE1 Squeak 3.11.2-basic - Release311-#taskUPDATE2 So by extension, those who only want a minor update of the most essentially essential fixes to 3.10 there is a set of tasks managed by class ReleaseSqueak31-#taskUPDATE3 This would be applied via: Installer install: 'Tasks'. ReleaseSqueak310 taskUPDATE3103 run. Packages current unload: 'Sake'. (to remove all vestiges of the Sake/Tasks/Packages). cheers Keith

1 1

Re: The progress status on V4?
by Keith Hodges 02 Dec '08

02 Dec '08

Yoshiki, do join us on the release(a)lists.squeakfoundation.org list. Matthew Fulmer wrote: > On Mon, Dec 01, 2008 at 03:13:04PM -0800, Yoshiki Ohshima wrote: > >> Hi, Matthew and Keith, >> >> On behalf of the board, now I'm supposed to be checking with you >> guys about the status of the effort for making a relicensed Squeak >> V4 regularly. >> >> Craig told me that Keith (IIRC) won't have much time until sometime, >> but I got some messages from Matthew about the Authorship code... >> What should I say to the "leadership"? >> > > I worked on this three days last week. I started with your 3.10 > history image, made a file containing all the dirty methods, and > now I'm annotating it with every change you made to etoys, to > see what would still need relicensing after I applied your etoys > 3.2 changes, and whether they would apply cleanly. So far, I > have gone through about 4 of your 10 etoys changesets. > > My plan is something like this: > > - Check to see what yoshiki's changesets don't cover (40% done) > - Apply yoshiki's changesets to 3.10, carefully > How are you planning to publish the results? Would they be in a changeset/equivalent that is loadable as a 3.11 build task? > - Confirm and fix the licensing status of new modules in 3.10: > - Traits (almost certainly clean) > - Universes (probably clean) > - Monticello (yikes) > - Do whatever I missed above > Keith

2 1

3.11 status
by Keith Hodges 02 Dec '08

02 Dec '08

Hello All, just a update as to where we are. My personal life has got a whole lot better recently. No more visiting hospitals etc, so a bit more time for Squeaking. Although my commercial project is still a high priority, I have started to spend time at the weekends working on Squeak stuff that I can also use as part of my paid work. i.e. not everything is directly 3.11 related, but it does have a contribution to make. My thinking is still, that 3.11 is about getting tools working really well for squeak accross the board. The Pharo guys are doing some great work on the kernel, and we will be able to benefit from their work significantly in the longer term. So tools wise: MC1.6 (LevelPlayingField) ==================== The goal is to have a definitive supported Monticello for everyone who uses MC1 packages. We expect MC2 to take a while to come into regular use, but we don't expect MC1 to disappear any time soon. Matthew is making great progress with Traits support for MC1.6, and I have been using MC1.6 for my development images. It is really nice and fast. Sake/Packages ========== To prepare for smaller images, a good solution for loading things back in is needed. Building images (like the dev image) also needs a good solution. To make Sake/Packages even better I have developed an automatic 'beta' loading feature. If a package definition (from universes or elsewhere) supplies a url for loading a package from a repository supported by Installer (e.g. Installer squeaksource). Packages beta, will dissect that url and attempt to find the repository and the most recent version from that repository. Packages current load: 'Aida'. - will load the released version of AidaWeb and its dependencies (Swazoo). Packages beta load: 'Aida'. - will track down the most recent version of AidaWeb and Swazoo. Bob The Builder ============ Bob is very close to completion now that Rio has been updated and revised. Rio - File/Directory ============== Key to the workings of Bob. Rio File/Directory package has been revised, refactored massively, simplified greatly, some more tests and transparent FTP support has been added (the feature Bob was wiating on). Logging (Used by Sake and Bob) ======================== Big refactoring, simplification, and much more powerful configuration options available. I need this for my commercial project, where I want my different seaside users to generate separate logs of their activities on my website. best regards Keith

1 0

Monticello 1.5 on Squeakmap and Universes
by Matthew Fulmer 24 Nov '08

24 Nov '08

On Mon, Nov 24, 2008 at 10:43:47PM +0530, K. K. Subramaniam wrote: > On Monday 24 Nov 2008 10:26:03 pm Matthew Fulmer wrote: > > Hmm. I tried loading MC 1.5 into both an etoys-dev upgraded to > > 4.0, and an etoys-image-and-pr, and both worked fine. How did > > you load MC 1.5? The only recommended method right now is to use > > the LPF installation script: > > > > HttpSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st' > > I tried the usual way - World Menu->open->SqueakMap Loader and got into a > loop. > > I tried your script and it read the stream for a loonng time. The transcript > was interspersed with "data too slow" messages. But it did install MC in the > end. Is this going to go into the final etoys 4.0 image? We should release MC1.5 onto SqueakMap and Universes by just pointing to http://installer.pbwiki.org/f/LPF.st I slightly tweaked LPF.st into http://installer.pbwiki.org/f/mc15.st, which just loads installer and Monticello, and doesn't do any squeakmap updating or transcript openning. We should point to that from SqueakMap and Universes Can you make me a co-maintainer of the mc1.5 entry in SqueakMap and Universes? -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

1 0

Rio's very minor dependency upon Null removed
by Keith Hodges 02 Nov '08

02 Nov '08

for nullphobics see subject Keith

1 0

Sake Dependencies
by Keith Hodges 02 Nov '08

02 Nov '08

In order to improve Sake's acceptability, I have worked to remove its dependence upon Kernel-Extensions. Sake now depends upon the "Streams Readability fix 7219" which has been taken out of Kernel-Extensions. Sake also required 'Logging', only if the #runLogging option is used, and Rio if the SakeTask file: is used. Keith

1 0

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Release