Planet Squeak

Those of you who read the squeak-dev mailing list will know that the list is currently going through the annual frenzy of discussion about the nature and direction of Squeak, including much to-and-fro over such topics as: the original vision of the founders of Squeak; the tangled relationship between Etoys and the rest of the Squeak environment and community; the reasons behind the Pharo project and how much its goals really differ from those of Squeak; whether children should be locked in the nursery or allowed to roam freely into every room of the house; and much more. If you have time (and some light body armour), it’s well worth reading through the hundreds of emails that have been written which explore and interpret much of the history and philosophy of Squeak.

This discussion has motivated the Squeak Oversight Board to look at one topic that caused much debate: how to manage the development of Squeak. Driven by a concern that there are many hurdles that discourage wide-spread participation in the contribution process, the Board have put forward a new community development model that they hope will “enable the community at large to improve Squeak, the core of the system and its supporting libraries”.

Based on processes that have been shown to work in commercial settings, the Board’s model includes the use of Monticello as the primary source code management system, free access for the developers to the main repositories (trunk, tests, and inbox) and an incremental update process for both developers and users of Squeak.

Obviously, such a change has sparked off its own debate, and important questions are being hammered out on the squeak dev mailing list. If you care about the health of the Squeak environment, its future direction, and the future support for your own favourite applications, this is a key moment for you to understand and contribute to the discussion which is continuing on the squeak-dev mailing list (see archives), on irc, and on the Board’s blog.

In the board meeting today we had a nice discussion about how to move forward with a new community development model for Squeak. Here is an overview of the model and what will happen next:

The goals

The goal of this process is to get rid of as many hurdles as possible in the contribution process. We are trying to enable the community at large to improve Squeak, the core of the system and its supporting libraries.

To do this, we are adopting processes that have been shown to work in commercial settings: The use of Monticello as the primary source code management system, free access for the developers to the main repositories, an incremental update process for both developers and users of Squeak.

Repositories

We will be setting up the following Monticello repositories:

* http://source.squeak.org/trunk

This will be the main repository for ongoing development. New code will be committed here, the repository will be world-readable and writable for the core-dev group.

* http://source.squeak.org/tests

This is the main repository for unit tests. It will be world-readable AND world-writable. We encourage everyone to write more tests and commit them, improve the existing tests and bring in entirely new test suites.

* http://source.squeak.org/inbox

This repository is intended as dropbox. It’s usage will depend on what we make it out to be. The idea is to have it world-readable and world-writable, too.

License

In accordance with our goal of joining the Free Software Conservancy, all code submitted to the repositories must be licensed under the MIT license.

Developer access

The board will manage developer access to the repositories at source.squeak.org. In the next days we’ll send out a few “you are pre-approved” messages to people who have proven to be active developers in the past in order to invite them to become a core developer.

If you can’t wait and absolutely want to be in on the action you can register yourself at http://source.squeak.org/ and send message to the board asking for access but most of the regular contributors (you know who you are) will be invited anyway.

Rules of Engagement

If you have used Monticello in projects with more than two developers in the past you already know the drill. If not, here are some useful guidelines:

* Merge often. In particular when you pick up work and right before you intend to commit.

* Exercise caution. This is a running system and breaking it needlessly is generally frowned upon.

* Restrain yourself. Getting developer access doesn’t mean you are free to put in every pet extension you always wanted to have without discussion.

* If in doubt, ask. This is the corollary to the restrain yourself rule. You’re not under pressure to ship a product, so you have the time to send a note saying “hey, I’m planning to fix this old issue and it may have some side effect here or there. Anyone having a problem with that?”

>>> I’ll add a Squeak-dev exception here: Any response from any non-developer can be entirely ignored in this context.

* You break it, you fix it. If you change something you are generally expected to take care of the consequences, though there are some exceptions. If in doubt, ask

* Do good and talk about it. When you’re done with whatever it is you’ve been working on let people know about it. It can be as short as a note to Squeak-dev saying “hey, some of you might care that I’ve fixed the long standing bug with xyz. Update and enjoy”

I think that roughly covers it. Basically you will be working with a dozen (hopefully more) other developers on Squeak and we’ll all have to learn how to make this work successfully.

Updating

We are in the process of developing an update process that can work seamlessly with Monticello. An early experiment is described here. We are evaluating alternative approaches, in particular the use of Installer since there are some shortcomings when using Monticello Configurations.

Existing Work

It is important to note that we will be trying very hard not to lose any work that is being done for Squeak 3.11. We will start with the package set that was used in the 3.10 release, then we will issue package updates to cover the missing delta up until 3.10.2. Following which we will reissue any changes done for 3.11 into the repositories.

First let me state that we are paying attention to your comments and we do appreciate them but it’s amazing how quickly one hour disappears and there is only so much that can be fit into a single meeting.  Triage is required.

Development Model Progress

Relicensing Release Progress

I’m sure more will be added, feel free to offer your own suggestions.

Attendance was complete and timely this time around: Jecel Mattos de Assumpção Jr, Ken Causey, Bert Freudenberg, Craig Latta,  Andreas Raab, Randal Schwartz, and Igor Stasenko.

We discussed the progress of the relicensing release.  Currently Matthew Fulmer is gathering information in preparation to meet with a representative of the Software Freedom Consortium to plan the next steps toward the completion of the 4.0 relicensing release.

Members of the Squeak Oversight Board have been kindly asked again to appear on Industry Misinterpretations.  Details are still being worked out but expect this episode sometime in September.

The primary topic was Andreas Raab’s proposed development model.  Discussion of this can be found here and here.  There was considerable discussion and even a little debate but ultimately the decision was to support Andreas’ proposal.  Expect Andreas to announce this in more detail soon.

Our next meeting is scheduled for Wednesday, July 15th, 2009.

The Innovation Technology Awards session is one of the real highlights of the annual International Smalltalk Conference organised by ESUG each year.

Noury Bouraqadi has just posted to remind everyone that you only have until 1st July to nominate your work for an award. Put together a brief description of your work, which can be in any Smalltalk dialect, make it available for inspection online, and be prepared to demonstrate it to a constant stream of inquisitive Smalltalkers during the conference, and you could win up to €500 in addition to the recognition and respect of your peers.

Have a look at Noury’s site for an introduction to the ideas that have proved popular in the past, or our own details of last year’s winners.

All the administrative details can be found on the ESUG 2009 website – so get those application forms in now!

And in case you’ve forgotten, this year’s conference is in Brest, France from 31 August—4 September, 2009. It will be preceded by Camp Smalltalk running on the weekend of 29—30 August 2009, and incorporates the International Workshop on Smalltalk Technologies on 31 August.

Subject to updates, please offer suggestions–

3.11 Status

4.0/Relicensing Status

Squeak Swiki update or replacement

Teams

Anything more?

Once again we were all present for today’s meeting: Jecel Mattos de Assumpção Jr, Ken Causey, Bert Freudenberg, Craig Latta,  Andreas Raab, Randal Schwartz, and Igor Stasenko.

We spent the bulk of the meeting talking about 3.11 status.  We didn’t come to any significant conclusions but resolved to increase communication with the release team and compile as much information as possible about the current status of this project and where it is going next.

We also discussed the wiki (Have you read Garbage Collecting the Wiki yet?), what can be done about the ‘forking impulse’, the status of the work on a new Smalltalk standard, and the 4.0 relicense release; no concrete results on these ongoing projects yet.

We meeting again on July 1, 2009.  Let us know what you think we should be discussing.

More exciting conference news for Smalltalk aficionados: James Foster has announced on his blog that this year’s OOPSLA conference will include several tutorials with a Smalltalk theme including his “Back to the Future: Programming in Smalltalk” in which he will look at the “new” ideas from Smalltalk that are still influencing newer programming languages. He will examine some of these ideas and present a number of tutorial exercises that explore some of Smalltalk’s  fundamentally different approach to language design and object orientation, including the following aspects:

• All values are objects, even integers, booleans, and characters (no boxing/unboxing);
• Classes and methods are objects (supporting reflection);
• The language has only five reserved words;
• All control flow (looping and conditional branching) is done through message sends;
• Programming is done by sending messages to existing objects; and
• The base class library can be modified.

James works on Gemstone’s high performance product family based on Smalltalk, but intends the exercises to be relevant across different versions.

This year’s OOPSLA will be held in Orlando, Florida from 25 to 29 October, and will also be co-located with the Dynamic Languages Symposium, which will doubtless have lots to interest Smalltalkers.

On the other hand, if you’re looking for a European break this year, don’t forget that the 2009 International Smalltalk Conference, organised by ESUG, will be held in Brest, France, from 31 August to 4 September, and also has a great set of sessions lined up.

The wiki is a fantastic resource for the community. Any search involving “squeak” will certainly have a link to a wiki page among the top results. And when answering questions on IRC, I nearly always end up pointing out some wiki page as the source for additional information.

Unfortunately, a significant portion of the information available there is obsolete. It is very easy for less experienced Squeakers to waste a lot of their time following advice they found on some page without realizing that it no longer applied to any Squeak newer than 2.5! One way to solve this is for a team to scan the wiki looking for stuff like this and then updating the information. In practice this is simply too much work and is unlikely to happen in a larger scale than what has been done so far. An alternative, inspired on garbage collection algorithms like those implemented in the Squeak VM, is to start a new wiki and move only current information there. This might seem like even more work, but it can be done incrementally: any person searching for information and not finding it in the new wiki can copy it from the old one.

If access to the old wiki remains as it is now, nobody would have any incentive to copy information to the new one. The most radical solution would be to simply eliminate normal access to the old wiki – you would have to explicitly log on to it or something like that. This would quickly make it vanish from the search engines. At the other extreme, it would be simple to add a warning to all old wiki pages saying that the content is obsolete. That could be done with the “message of the day” mechanism (lately it has been broken and only showing one quote from me anyway). This is too easy to ignore, however. A slightly more complicated solution would be to patch the swiki code to show a warning that would be far harder to ignore. It might be interesting to include a link to the new wiki for any page which has content that has been moved there. One way to encourage moving content to the new wiki would be to disable editing of the old one (except for adding links to the new).

The goal is to eventually have a new wiki, possibly based on some more modern Squeak technology, that document the system as it is now. The best way to achieve this would be for the board to issue a request for proposals so that people interested could form a team to create the new wiki and patch the old one. This team would not be responsible for the content, except moving a few key pages themselves to get the process started. The details that I have mentioned above are only examples – the candidates would be free to suggest any solution they want as part of their proposals.

Personally, I am very interested in Squeak’s history and would not like to see the old information vanish entirely from the web. But I do agree that as things are now the noise is getting in the way of the signal and we need to cause a better first impression to people interested in Squeak and Squeak based projects.

Phil Schiller led the keynote presentation today at Apple’s Worldwide Developers’ Conference. One of the many causes for celebration he had was the phenomonal success of the iPhone App Store, which now has 50,000 applications available for download.

Although he was careful to be even-handed in giving credit to all iPhone developers for helping Apple achieve this success, he must have secretly been thanking John McIntosh, who is turning into a one-man app wave. Without John’s recent batch of new Squeak-based applications, Phil would have been left announcing the much less satisfactory figure of 49,99749,994 applications.

In case you missed it, John’s latest announcement was that his Fraction app is now available for calculations involving unlimited sized fractions and factorials, as it attempts to preserve numerical accuracy to an unprecedented degree. The new app joins the two apps based on his WikiServer that John already has on the App Store.

We look forward to seeing if the notoriously byzantine App Store approval process will be able to keep up with John’s flood of new applications.

Everyone made it this time and so the meeting was attended by: Jecel Mattos de Assumpção Jr, Ken Causey, Bert Freudenberg, Craig Latta,  Andreas Raab, Randal Schwartz, and Igor Stasenko.

We started out finalizing the mission statement which has finally been published allowing us to move on to other topics.  Please read and comment.

We have received replies to the team survey we sent out some weeks back and we discussed this somewhat but haven’t had the time to properly digest the data or come to any conclusions yet.  In time the teams page will receive a significant update hopefully clarifying how teams are formed and work.

We discussed the Release team and have asked them for an update on progress.  The team leader, Matthew Fulmer, recently moved to a new state, started up at a new university, and started a new job; so I think we can all understand that he has been too busy to make much progress recently.  Matthew is going to be setting aside time soon to work with the Software Freedom Conservancy to work out what further work is needed to produce an MIT/Apache licensed 4.0 release that is acceptable to the SFC as a requirement for our membership.

I think everyone can agree that the community Swiki has aged poorly and can be very confusing, particularly to newcomers to our community looking for clear information.  We are discussing a plan to replace the Swiki with a new system.  Some of the requirements for such a system would be a clear link between the current Swiki and the new system at least during the development of the new system and not losing the Google links to the existing Swiki pages.  We need the community’s assistance with this and welcome suggestions.  Do you have a plan for updating or replacing the Swiki with a better documentation system while not losing it’s existing strengths?  Please let us know.

On a similar note one of our long range goals is to encourage the incorporation of ideas and code from our related communities such as Pharo, Etoys, and Croquet and of course many others.  Also we want to examine the reasons that forks occur and consider what can be done to make it less necessary for developers to do so.  We need your thoughts and ideas.  Please give us your comments on this subject.

Our next meeting will take place on Wednesday, June 17th, 2009.

Well it took a while but we have finally published a ‘Mission Statement’ for ourselves and it can be found listed on the right.  Please let us know what you think.

Despite recent discussions over what killed Smalltalk, there continues to be lots of interest in the language and in Seaside in particular. Anyone based near London will be able to find out more about both topics at a talk dramatically titled “Seaside: The Revenge of Smalltalk“.

This “Geek Night” is going to cover how Smalltalk makes web development different and how Seaside is being put to use in the “Real World”. Participants will learn about real object-orientated programming rather than class-orientated programming.

The two presenters are Lukas Renggli, who will be talking about Squeak and the world of Open Source Smalltalk; and Michel Bany from Cincom who will be discussing how Seaside and Smalltalk has been used in companies like JP Morgan.

The talk is hosted by Thoughtworks‘ London office on Monday 6th July, 2009 from 7:00pm—10:00pm.

Mikael Kindborg and colleagues at comikit.se have announced that their Magic Words application is now available as Open Source software.

Magic Words gives children (of all ages!) the ability to create interactive animated worlds. It has been used to allow its users to make their own friendly non-violent computer games and explore the meaning of words as part of learning how to read.

The team have made the source-code available under the MIT licence, and have provided some sample resources including pictures, text, and sounds to get you started.

The application is of course based on Squeak, and the Comikit team give detailed instructions on how to load it into a standard Squeak image.