Planet Squeak

Andreas Raab: Croquet in Squeak 4.1

2010-07-29T05:06:51+00:00

Wow! Looks like the Cobalt folks have been making huge headway with moving Croquet forward to Squeak 4.1. Nikolay Suslov just posted on his blog that he’s got it running! Here is a screenshot from his site:

Croquet in Squeak 4.1

That’s wonderful news! Together with our just announced Seaside images this will make Squeak 4.1 more attractive than ever.

Ramon Leon: A Simple Thread Pool for Smalltalk

2010-07-28T22:04:08+00:00

Forking a thread in Smalltalk is easy, wrap something in a block and call fork. It's so easy that you can easily become fork happy and get yourself into trouble by launching too may processes. About 6 months ago, my excessive background forking in a Seaside web app finally starting hurting; I'd have images that seemed to lock up for no reason using 100% CPU and they'd get killed by monitoring processes causing lost sessions. There was a reason; the process scheduler in Squeak/Pharo just isn't built to handle a crazy amount of threads and everything will slow to a crawl if you launch too many.

I had a search result page in Seaside that launched about 10 background threads for every page render and then the page would poll for the results of those computations, collect up any results found, and AJAX them into the page. Each one needs to run in its own thread because any one of them may hang up and take upwards of 30 seconds to finish its work even though the average time would be under a second. I don't want all the results being stalled waiting for the one slow result, so it made sense to have each on its own thread. This worked for quite a while with nothing but simple forking, but eventually, the load rose to the point that I needed a thread pool so I could limit the number of threads actually doing the work to a reasonable amount. So, let's write a thread pool.

First we'll need a unit of work to put on the thread, similar to a block or a future. Something we can return right away when an item is queued that can be checked for a result or used as a future result. We'll start by declaring a worker class with a few instance variables I know I'll need. A block for the actual work to be done, an expiration time to know if the work still needs done, a value cache to avoid doing the work more than once, a lock to block a calling thread treating the worker as a future value, and an error in case of failure to store the exception to be re-thrown on the main thread.

Object subclass: #ThreadWorker
    instanceVariableNames: 'block expires value lock error'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'ThreadPool'

I'll also want a few constructors for creating them, one that just takes a block, and one that takes a block and an expiration time. For my app, if I don't have results within a certain amount of time, I just don't care anymore, so I'd rather have the work item expire and skip the work.

ThreadWorker class>>on: aBlock
    ^ self new
        block: aBlock;
        yourself 

ThreadWorker class>>on: aBlock expires: aTime
    ^ self new
        block: aBlock;
        expires: aTime;
        yourself

On the instance side let's initialize the instance and setup the necessary accessors for the constructors above.

ThreadWorker>>initialize
    super initialize.
    lock := Semaphore new 

ThreadWorker>>block: aBlock
    block := aBlock 

ThreadWorker>>expires: aTime
    expires := aTime

Now, since this is for use in a thread pool, I'll want a non-blocking method of forcing evaluation of the work so the thread worker isn't blocked. So if the work hasn't expired, evaluate the block and store any errors, then signal the Semaphore so any waiting clients are unblocked.

ThreadWorker>>evaluate
    DateAndTime now < expires ifTrue: 
        [ [ value := block value ] 
            on: Error
            do: [ :err | error := err ] ].
    lock signal

I'll also want a possibly blocking value method for retrieving the results of the work. If you call this right away, then it'll act like a future and block the caller until the queue has had time to process it using the evaluate method above.

ThreadWorker>>value
    lock isSignaled ifFalse: [ lock wait ].
    "rethrow any error from worker thread on calling thread"
    error ifNotNil: 
        [ error
            privHandlerContext: thisContext;
            signal ].
    ^ value

But if you want to poll for a result, we'll need a method to see if the work has been done yet. We can do this by checking the state of the Semaphore; the worker has a value only after the Semaphore has been signaled.

ThreadWorker>>hasValue
    ^ lock isSignaled

That's all we need for the worker. Now we need a queue to make use of it. So we'll declare the class with some necessary instance variables and initialize them to some reasonable defaults along with some accessors to adjust the pool sizes. Now, since a thread pool is generally, by nature, something you only want one of (there are always exceptions, but I prefer simplicity) then we'll just rely on Smalltalk itself to ensure only one pool by making all of the pool methods class methods and the ThreadPool the only instance. I'll use a shared queue to handle the details of locking to ensure the workers share the pool of work safely.

Object subclass: #ThreadPool
    instanceVariableNames: ''
    classVariableNames: 'MaxPoolSize MinPoolSize PoolManager QueueWorkers WorkQueue'
    poolDictionaries: ''
    category: 'ThreadPool'

ThreadPool class>>initialize
    "self initialize"
    WorkQueue := SharedQueue2 new.
    QueueWorkers := OrderedCollection new.
    MinPoolSize := 5.
    MaxPoolSize := 15.
    Smalltalk addToStartUpList: self 

ThreadPool class>>maxPoolSize: aSize
    MaxPoolSize := aSize 

ThreadPool class>>minPoolSize: aSize
    MinPoolSize := aSize

Once you have a pool, you need to manage how many threads are actually in it and have it adjust to adapt to the workload. There are two main questions we need to ask ourselves to do this: are there enough threads or are there too many threads given the current workload. Let's answer those questions.

ThreadPool class>>isPoolTooBig
    ^ QueueWorkers size > MinPoolSize 
        and: [ WorkQueue size < QueueWorkers size ]

ThreadPool class>>isPoolTooSmall
    ^ QueueWorkers size < MinPoolSize 
        or: [ WorkQueue size > QueueWorkers size 
            and: [ QueueWorkers size < MaxPoolSize ] ]

We also need a method for a worker to grab a queued work item and work it, and we don't ever want this to error out killing a worker thread since the worker thread should trap any error and re-throw them to the queuing thread. But just to be safe, we'll wrap it.

ThreadPool class>>processQueueElement
    [ WorkQueue next evaluate ] 
        on: Error
        do: [  ]

Now that workers have something to do, we'll need to be able to start and stop worker threads in order to increase or decrease the working thread count. Once a worker is started, we'll want it to simply work forever and the shared queue will handle blocking the workers when there's no work to do. We'll also want the worker threads running in the background so they aren't taking priority over foreground work like serving HTTP requests.

ThreadPool class>>startWorker
    QueueWorkers add: ([ [ self processQueueElement ] repeat ] 
            forkAt: Processor systemBackgroundPriority
            named: 'pool worker')

To kill a worker, we'll just queue a job to kill the active process, which will be whatever worker picks up the job. This is a simple way to ensure we don't kill a worker that is doing something important. This requires actually using the queue, so a quick couple methods to actually queue a job and some extensions on BlockClosure/BlockContext to make using the queue as simple as forking.

ThreadPool class>>queueWorkItem: aBlock expiresAt: aTimestamp 
    | worker |
    worker := ThreadWorker on: aBlock expires: aTimestamp.
    WorkQueue nextPut: worker.
    ^ worker 

ThreadPool class>>queueWorkItem: aBlock expiresAt: aTimestamp session: aSession 
    | worker |
    "a special method for Seaside2.8 so the worker threads still have access to the current session"
    worker := ThreadWorker 
        on: 
            [ WACurrentSession 
                use: aSession
                during: aBlock ]
        expires: aTimestamp.
    WorkQueue nextPut: worker.
    ^ worker 

BlockClosure>>queueWorkAndExpireIn: aDuration
    ^ ThreadPool 
        queueWorkItem: self
        expiresAt: DateAndTime now + aDuration

BlockClosure>>queueWorkAndExpireIn: aDuration session: aSession 
    "a special method for Seaside2.8 so the worker threads still have access to the current session"
    ^ ThreadPool 
        queueWorkItem: self
        expiresAt: DateAndTime now + aDuration
        session: aSession

And now we're able to queue a job to kill a thread, making sure to double check at time of actual execution that the pool is still too big and the thread still needs to die.

ThreadPool class>>killWorker
    "just queue a task that kill the activeProcess, which will be the worker that picks it up"

    [ self isPoolTooBig ifTrue: [ (QueueWorkers remove: Processor activeProcess) terminate ] ] 
        queueWorkAndExpireIn: 10 minutes

Of course, something has to decide when to increase the size of the queue and when to decrease it, and it needs to a method to do so.

ThreadPool class>>adjustThreadPoolSize
    "starting up processes too fast is dangerous and wasteful, ensure a reasonable delay"
    1 second asDelay wait.
    self isPoolTooSmall 
        ifTrue: [ self startWorker ]
        ifFalse: [ self isPoolTooBig ifTrue: [ self killWorker ] ]

We need to ensure the thread pool is always up and running, and that something is managing it, so we'll hook the system startUp routine and kick off the minimum number of workers and start a single manager process to continually adjust the pool size to match the workload.

ThreadPool class>>startUp
    "self startUp"
    self shutDown.
    MinPoolSize timesRepeat: [ self startWorker ].
    PoolManager := [ [ self adjustThreadPoolSize ] repeat ] 
        forkAt: Processor systemBackgroundPriority
        named: 'pool manager'

And cleanup everything on shutdown so every time the image starts up we're starting from a clean slate.

ThreadPool class>>shutDown
    "self shutDown"
    WorkQueue := SharedQueue2 new.
    PoolManager ifNotNil: [ PoolManager terminate ].
    QueueWorkers do: [ :each | each terminate ].
    QueueWorkers removeAll.

And that's it, a simple thread pool using a shared queue to do all the dirty work of dealing with concurrency. I now queue excessively without suffering the punishment entailed by forking excessively. Now rather than...

[ self someTaskToDo ] fork

I just do...

[ self someTaskToDo ] queueWorkAndExpireIn: 25 seconds

Or in Seaside...

[ self someTaskToDo ] queueWorkAndExpireIn: 25 seconds session: self session

And my app is running like a champ again, no more hanging images due to forking like a drunken sailor.

Torsten Bergmann: Pharo 1.1. Setup for Windows

2010-07-28T21:40:45+00:00

The new Pharo 1.1 release comes (similar to the first version) as a large download: the one-click image with virtual machines for all major platforms (Windows, Mac, Linux).

As before for those who want to use/run Pharo 1.1. on Win32 system only I additionally prepared a smaller installer for the new release. Read more. As ever it is also available on the Pharo project site.

Torsten Bergmann: Aida on Pharo 1.1

2010-07-28T21:32:43+00:00

Not only Seaside 3.0 is running on the new Pharo 1.1. release. Also the Aida Smalltalk
web framework is running nicely on the open source Smalltalk platform. Read more.

Torsten Bergmann: Pharo by Example on Amazon

2010-07-28T19:55:36+00:00

Pharo by Example can now finally be ordered at Amazon.com and therefore also orderable at any bookstore. You can also visit the online version.

Pharo News Blog: Pharo 1.1 released

2010-07-27T07:28:04+00:00

We are excited to announce our second release of Pharo!

This release contains many bug fixes, improvements, performance optimizations, and new features that didn't get into version 1.0.

Specific information about what is new in this release can be found on http://www.pharo-project.org/pharo-download/release-1-1.

Thanks everyone who has contributed and helped to bring Pharo one step further!

Adrian Lienhard, July 26, 2010

Pharo News Blog

2010-07-27T07:12:13+00:00

Torsten Bergmann: Pharo 1.1. released

2010-07-26T20:55:43+00:00

Pharo 1.1. - the next milestone of the Pharo project is released. Here is a short summary what's new.

Smalltalk Medicine Show: iPad - Adding pictures to the WikiServerPro.

2010-07-26T15:02:48+00:00

	iPad - Adding pictures to the WikiServerPro.	From: gandysmedicineshow Views: 16 0 ratings
	Time: 02:37	More in Science & Technology

Andreas Raab: New Squeak 4.1 / Seaside Images

2010-07-24T04:01:07+00:00

Good news, we just finalized a series of preloaded Seaside images on Squeak.org. This became necessary since builder.seaside.st is no longer accessible and consequently our instructions for installing Seaside in Squeak were out-of-date. The new images fix this problem and provide an easy install (for new users; this includes image, sources, vms etc. in an all-in-one setup) as well as an expert install (which just includes the images):

In addition, we now also provide 2.8 based images for people who have existing Seaside 2.8 applications in older versions in Squeak:

Here is a screenshot of the welcome screen:

Seaside 3.0 in Squeak 4.1

Oh, and if you want to load Seaside 2.8 / 3.0 into your custom Squeak variants; the above images include instructions about how they were created so you should be able to apply the same procedure to your own images.

The Weekly Squeak: Seaside 3.0rc – One Click Image

2010-07-23T13:27:38+00:00

Following on from the recent release of the Seaside release candidate for 3.0, a Squeak “One-Click” image has been put together to allow you to try out the new version with—er—one click!

The new image is based on Squeak 4.1, and launches fully configured with Seaside running with Comanche on port 8080, so you can immediately see the new improved Seaside welcome page at http://localhost:8080/, with links to documentation and the Seaside book.

Seaside’s 3.0 release is faster, cleaner, better tested and has many other changes and improvements over previous releases, so it’s well worth checking out this release candidate now.

Squeak Oversight Board: Meeting Report for 7/21/2010

2010-07-21T21:15:47+00:00

In case you haven’t noticed, it’s summer! People are on vacation and consequently Craig (on vacation in Europe) wasn’t present in our meeting and Bert joined us from his hotel room and shared a view of the beach with us.

There wasn’t too much to talk about. We discussed a bit the SFC status and noted that we need to make some progress with the reconciliation of our finances. We’re still waiting for some info from the SFC on how to best address this issue and will ping them again as a reminder. Andreas brought up the issue of providing a Squeak image with Seaside preloaded and the board agrees that we should provide such an image on http://ftp.squeak.org/various_images/seaside.

We raised a couple of other issues in the discussion, including what a useful scope for 4.2 might be, how to make progress with community supported packages, and how to continue the discussion about documentation, but no specific action items resulted from these.

As a result we finished our meeting early. But hey, it’s summer!

Eliot Miranda

2010-07-21T05:33:12+00:00

Hi All, in lieu of some full posts on the Cog JIT here’s a screencast that gives a brief overview of some image level info for the Cog VM before diving into the simulator and looking at the evolution of a send site in the VM through various forms of inline cache. Send post as PDF to [...]

Torsten Bergmann: Sunset or Eclipse with Oracle JVM

2010-07-19T17:36:45+00:00

When you run the new Oracle JVM 6u21 and Eclipse you may encounter frequent Eclipse crashes.

Eclipse launcher (which is written in C/C++) reads the JVM vendor and if it detects a Sun JVM, it adds a necessary memory parameter for Eclipse to function.
Since now the "Java" vendor was changed from Sun to Oracle it crashes.

So the current version of Eclipse does not work with the current version of Java on the most popular platform - at least not out of the box.

There is a bug report already ...

Torsten Bergmann: Seaside in Czech

2010-07-19T17:18:35+00:00

Two new Seaside applications on the radar:

http://www.webchod.cz
http://www.kalorik.cz

Smalltalk Medicine Show: SocketStream

2010-07-19T13:46:04+00:00

	SocketStream Use the wrapper SocketStream instead of handling the Socket class directly.	From: gandysmedicineshow Views: 22 0 ratings
	Time: 02:17	More in Science & Technology

Torsten Bergmann: Cycles in your software

2010-07-19T09:43:16+00:00

Jannik Laval announced a new tool to see your software package structure and to fix cycles between packages. It is based on Pharo and Moose.

Read more.

Torsten Bergmann: Squeak-SSL

2010-07-19T08:59:25+00:00

Andreas announced a new SSL interface for Squeak.

The project page can be found on squeaksource.

Andreas Raab: SqueakSSL released

2010-07-19T06:37:48+00:00

I’ve just released a bit of work that I had been working on for a while. SqueakSSL is a plugin based interface to the native SSL/TLS facilities on your platform. On Windows, it uses the SChannel SSPI and on Unix it uses the OpenSSL implementation. The Mac’s still out there but I’m hoping that the OpenSSL version will work there too.

The official announcement is here: [ANN] SqueakSSL – a platform interface for SSL/TLS

Torsten Bergmann: Self programming language

2010-07-16T06:21:34+00:00

Self 4.4. is released. Read more.

The Weekly Squeak: Smalltalk: the past, the present, and the future?

2010-07-15T10:00:45+00:00

Anyone with an interest in the continuing role and development of Smalltalk has had lots to chew on over the past few days.

As part of a series of investigations into the most widely-used programming languages, Computerworld Australia has published a conversation with Alan Kay about his role in the development of the “foundation of much of modern programming today: Smalltalk-80″, Object-Oriented Programming, and modern software development.

InfoQ is running a series of interviews recorded at QCon London. One of these is a session with Ralph Johnson and Joe Armstrong discussing the Future of OOP, including their take on what Smalltalk got wrong and right.

Finally, Gilad Bracha continues to lay out his vision for what he sees as Smalltalk’s successor, Newspeak. His latest post contains encouragement and advice for those interested in porting existing libraries and applications to Newspeak.

Smalltalk Medicine Show: Seaside - HTML Tags

2010-07-12T15:32:35+00:00

	Seaside - HTML Tags Use the tests to learn the tags.	From: gandysmedicineshow Views: 34 2 ratings
	Time: 01:13	More in Science & Technology

Gilad Bracha: Converting Smalltalk to Newspeak

2010-07-11T18:20:01+00:00

One of the things that has surprised me working with Newspeak is how easy it is to convert Smaltalk code to Newspeak. We have converted most of the core libraries of Smalltalk (aka ‘The Blue Book Libraries’) into Newspeak. Most of the conversion was done by people who had never coded in Newspeak before. In some cases, they had never coded in Smalltalk before.

The syntactic differences are fairly trivial (though they will grow in time) and easily handled - either automatically by tools or by very simple transformations in a text editor. Semantically moving from Smalltalk to Newspeak is easy (see this document for a detailed discussion of the mechanics), but the opposite is harder.

The main issues one has are API differences between libraries; but this is no different than converting from one Smalltalk implementation to another.

The converted code may not be the most idiomatic Newspeak. The easiest conversion path sticks a bunch of related Smalltalk classes inside a Newspeak module class, without creating any interesting substructure. Nevertheless, the converted code is invariably better than the original. It becomes very clear what the code’s external dependencies are, what the module boundaries should be, who is responsible for initialization etc. There is no longer any static state. It’s much easier to tie libraries together (or tear them apart), test them independently and so forth. Once we start enforcing access control, it should be much clearer what the public API really is. All this without losing the flexibility and power of the original.

This is very encouraging, because it means Newspeakers can take advantage of the large body of Smalltalk code that already exists. Any useful Smalltalk library that is publicly available can be converted to Newspeak in pretty short order. It also means that Smalltalkers can take the plunge and migrate to Newspeak relatively easily.

Of course, I don’t expect all the world’s Smalltalkers to instantly convert to Newspeak. Even if they did, Newspeak would still be a niche language. For Newspeak to be a success, we need to reach out to programmers in a variety of communities. This post, however, is aimed squarely at the Smalltalk community.

There are no doubt many Smalltalk projects that are tied to a specific Smalltalk. There are also Smalltalkers who are too conservative, and don’t want to deal with any language changes.

Still, if you are (or were, in some happier time) a Smalltalker and want to move into the future rather than dwelling on the glorious past, I assert that Newspeak is for you. If you are using an open source Smalltalk, it is likely you could do better using Newspeak. Newspeak explicitly addresses Smalltalk’s weaknesses: modularity, security, interoperability. Of course, some people aren’t bothered by these weaknesses.

Tangent: Arguably, the Smalltalk community is, by natural selection, composed largely of such people; if they were bothered by Smalltalk’s deficiencies, they wouldn’t use it.

Newspeak should interest those who appreciate the power of Smalltalk but want to move forward.

Of course, you have to be an early adopter by nature. Things will evolve and change under your feet. The syntax will become less Smalltalk-ish over time. Most importantly, you’ll have to learn something new. This is good for your neurons. You may have to port some libraries you rely on. You may have to make changes so that you do not rely on libraries you wouldn’t want to port (like Morphic). However, the result will likely be a product that is easier to deploy, more visually appealing and better integrated with its surrounding environment. Your code will be much more maintainable and better structured.

I’ve written a simple guide that highlights how to go about converting Smalltalk to Newspeak. Give it a try!

The Weekly Squeak: A newer, faster computer – for free!

2010-07-08T20:31:03+00:00

Eliot Miranda has announced that his new Cog VM is now available for download, bringing Just-In-Time compilation and massive speed-ups to Squeak and Pharo.

If you’ve been following Eliot’s blog, you’ll know that he’s been working on this new VM for quite a few months now; well, it’s now ready for public consumption, and it’s blisteringly fast: up to three times faster than the existing VMs.

The VM selectively re-compiles code to native (Intel) machine-code, based on the size and complexity of the methods, and how often they’re called. This means that the benefits of the new VM vary from task to task, but Andreas Raab estimates that you should expect a 2-3x performance improvement generally, “more towards 2x when running primitive and I/O-bound stuff; more towards 3x when running ‘pure’ Smalltalk code”.

Eliot is interested in hearing from developers on other platforms who want to port the new VM to those platforms. In the meantime, he has also released the “Stack VM”, a cross-platform interpreter that uses context-to-stack mapping to achieve more modest performance gains.

See Eliot’s original post and the following discussion for more details of the new VM, some notes of caution, and how to get your hands on it and use it.

Thanks to Eliot for this great piece of work, and to Teleplace who have funded this work (and have been using it for the past year), and have agreed to release the new VM’s under the MIT Licence.

Dave Woodward: Response to "Why Parents Hate Parenting"

2010-07-07T18:18:02+00:00

I commented on this article when it was linked on Hacker News, and I realized that my comment was probably worthwhile to non-readers of Hacker News too.

Why Parents Hate Parenting
http://nymag.com/news/features/67024/

The lens through which parenting is viewed in the above article is too narrow. Parenting isn't about being happier. It is about being a bigger and better person. Children make your life BIGGER. You feel moments of happiness like you've never felt before. You also feel moments of anger like you've never felt before.

It really is indescribable and not for the faint of heart or the selfish. The beautiful thing about parenting is that it shows you who you really are (not who you think you are), and gives you chances every day to grow.

It makes you see what really matters in life, assuming you actually come to this realization. I've seen plenty of people not realize this and fight to keep their identity, their original idea of what they wanted for themselves while also trying to be a parent. That doesn't work.

Part of parenting is a certain amount of ego destruction. You have to go through that if you want to genuinely care for another human being.

This is what makes the experience of parenting so great. It is a kind of Zen experience of making yourself better by destroying your concept of self (and putting another 'self' first more than your own self would like).

Permalink | Leave a comment »

Torsten Bergmann: Boot Squeak

2010-07-07T07:35:26+00:00

Intersting alternative to SqueakNOS: Michael van der Gulik describes
a way to boot Squeak on a tiny core linux.

Michael van der Gulik: SqueakOS the cheaters way

2010-07-06T23:32:30+00:00

Cold boot to Squeak under 6 seconds? Possible. I haven't actually automated it yet, but it is possible as described below.

Tiny Core Linux is a mini Linux distribution that is, before boot, only two files. One is the Linux kernel. The other is the entire filesystem which is loaded into RAM. These two files are packaged up into a bootable .iso image for burning to a CD, although you can put them on any bootable medium and boot them using grub. You can put these files on an existing Linux partition on your hard disk, for example. The "tiny" version is 10MB and has a graphical interface and package manager! The "micro" version is 6MB and is only a command line. They boot really fast.

Now, the micro version can be used to run Squeak:

Boot it up using one of the "vga=" command line parameters to get a working framebuffer. You could use grub to persist this setting.
Get Squeak into the filesystem somehow. I used wget to fetch an image and the Linux VM from ftp://ftp.squeak.org/. A more permanent option would be mounting an existing filesystem.
Become root (sudo su) to run Squeak, or fix the permissions on /dev/input/mice.
Run squeak: "bin/squeak -vm-display-fbdev".

This is not quite as cool as SqueakNOS, but it is a practical, easy and stable way of running Squeak as if it were the OS with good hardware support and a filesystem.

Smalltalk Medicine Show: Seaside - From Builder To Canvas

2010-07-05T14:50:25+00:00

	Seaside - From Builder To Canvas How the HTML was modelled in Smalltalk.	From: gandysmedicineshow Views: 59 0 ratings
	Time: 03:19	More in Science & Technology

Torsten Bergmann: Seaside 3.0 RC

2010-07-04T19:55:26+00:00

Julian announced Seaside 3.0 RC.

Julian Fitzell: Seaside 3 "Release Candidate"

2010-07-02T23:47:55+00:00

You could say it's been a long time coming.

Seaside 3.0 began ambitiously and grew from there. We began (at least I did) with the goal of cleaning up the architecture, revisiting each aspect and asking what could be simplified, clarified, or standardized. As functional layers were teased apart, suddenly pieces became unloadable and a repackaging effort got under way. From this we realized we could make the process of porting Seaside much less painful. Along the way, we lowered response times and reduced memory usage, added 10x the number of unit tests (1467 at last count), standardized code and improved code documentation, added jQuery support, and, oh, did you hear there's a book?

The result? This release runs leaner, on at least six Smalltalk platforms and is, I think, easier to learn, easier to use, and easier to extend. Seaside 3.0 is the best platform out there for developing complex, server-side web applications. Is it perfect? No, but I'll come to that part in a moment. It is the result of literally thousands of hours of work by a small group of people across all six platforms. But this release also exists only due to the generosity of Seaside users who tried it, filed bugs against it, submitted patches for it, and eventually deployed it.

Deployed it?! Yeah, you see, not only have all the commercial vendors chosen to ship our alphas and betas, but our users have also used them to put national-scale commercial projects into production. I alluded last month to a conference session I attended, in which somebody made the statement that

The best way to kill a product is to publicly announce a rewrite. Customers will immediately avoid investing in the "old" system like the plague, starving the product of all its revenue and eventually killing it.

It was a shocking moment as I realized we'd attempted just that. At first we justified the long release cycle because we were "doing a major rewrite"; then we just had "a lot more work to do". Eventually there were "just too many bugs" and things "just weren't stable enough". And, finally, once we realized we desperately needed to release and move forward, we just ran out of steam (no quotes there—we really did).

I still think the original architectural work needed doing and I'm really happy about where we ended up, but here's what I've learned:

When your wonderful, dedicated users start putting your code into production, they're telling you it's ready to be released. Listen to them.
We don't have the manpower to carry out the kind of QA process that goes along with an Development, Alpha, Beta, RC, Final release process.
We need to figure out how to get more users actively involved in the project. This could be by writing code but probably more importantly by writing documentation, improving usability, building releases, managing the website, doing graphical design, or something else entirely. The small core team simply can't handle it all.

Trying to apply these lessons over the past month, I asked for help from a few people (thank you!) and we closed some final bugs, ran through the functional tests, developed a brand new welcome screen, and managed to bundle everything up. We're releasing this today as 3.0RC.

We're not planning a standard multi-RC process. The "Release Candidate" simply signifies that you all have one last chance to download it, try it , and let us know about any major explosions before we do a final release, hopefully at the end of the month. From there we'll be reverting to a simpler process, using frequent point releases to fix bugs. 3.1 will have a smaller, better defined scope and a shorter cycle. I have some ideas but before we start thinking about that, we all need a breather.

I also have some ideas about the challenges that potential contributors to the project may face. But I'd like to hear your thoughts and experiences. So, if you have any suggestions or you'd like to help but something is stopping you, send me an email or (better yet if you're there) pull me aside at Camp Smalltalk London or ESUG and tell me about it.

Ok, ok. You've waited long enough—thank you. Here's the 3.0RC one-click image, based on Pharo 1.1 RC3 and Grease 1.0RC (just the image here). Dale has promised an updated Metacello definition soon. Enjoy!