Planet Squeak

Esteban announced the Gofer Project Loader 1.0 (BETA) - a simple
API to use Metacello loading.

There is a webpage explaining it.

by Torsten (noreply@blogger.com) at March 17, 2010 01:49 PM

The Eagle Has Landed: Squeak 4.0 is Released

http://ftp.squeak.org/4.0/

The focus for 4.0 was to relicense Squeak with the MIT license (with
some Apple parts remaining under the Apache license.)

by Torsten (noreply@blogger.com) at March 16, 2010 12:03 PM

Read more here

by Torsten (noreply@blogger.com) at March 15, 2010 04:51 PM

Get the details here: http://colstme.selfish.org/events/stammtisch02

by Torsten (noreply@blogger.com) at March 15, 2010 03:13 PM

New Pharocasts are available:

• How to build the VM on Linux
  
• How to contribute to Pharo
  

by Torsten (noreply@blogger.com) at March 15, 2010 01:30 PM

by Randal Schwartz at March 14, 2010 12:28 PM

Stephen Pair released Trax, a general object versioning system for Squeak.

Read more here.

by Torsten (noreply@blogger.com) at March 11, 2010 01:15 PM

Hey ... and Adrian is using my metacello config for VMMaker too. He just described on how to build the virtual machine on OSX. Nice.

by Torsten (noreply@blogger.com) at March 11, 2010 07:58 AM

Laurent wrote on how to build the Squeak VM on Linux. Nice that the VMMaker metacello configuration I created (see here and here) is used.

by Torsten (noreply@blogger.com) at March 11, 2010 07:50 AM

There is a new page for the Google summer of code with Smalltalk:

http://gsoc2010.esug.org/

You can read more about it here.

by Torsten (noreply@blogger.com) at March 09, 2010 07:54 AM

The Squeak community are working with ESUG to submit a joint entry to this year’s Google Summer of Code but need your help at once!

Squeak participated in GSoC  in 2007 and 2008 but in 2009 Google started to focus on bigger communities, so Squeak developers are working with ESUG this year to put together a joint submission with other groups including open-source projects from all Smalltalk dialects, including Pharo, Smalltalk/X, GNU Smalltalk and Cuis as well as commercial distributions such as VisualWorks, VisualAge, Dolphin and Gemstone. Entries from cross-platform projects like Seaside, AidaWeb, Magma, etc. will also be welcome.

Mariano Martinez Peck will administrate the joint application supported by Janko Mivšek. They need to supply Google with information about ESUG as a mentoring organisation and a list of ideas/projects,  each with a description and a nominated mentor. If their submission get selected by Google they will be told how many projects Google will sponsor — the mentor receives $500 and the student who volunteers to work on the projects will receive $4500.

Due to a late start, they are very near to the first deadline! They have until 12th March 2010 to submit all the information of the mentor organisation and give the list of projects with mentors. So as a matter of urgency they need your projects. They’ve put together a webpage to hold details, so if you have project suggestions, send them a short title and a paragraph (for the moment) explaining the idea. You can also reply to Mariano’s email on most of the key developer mailing lists including the squeak-dev mailing list.

Good mentors are often as hard to come by as good ideas, but often being helpful, being aware of the dates, answering emails, etc. can be more important than the Smalltalk knowledge, so if you’re able to act as a mentor or a back-up, let them know at once!

For some inspiration, you can see the ideas proposed in previous years:
2007: http://wiki.squeak.org/squeak/5936
2008: http://wiki.squeak.org/squeak/6031
2009: http://wiki.squeak.org/squeak/6120

by Michael Davies at March 08, 2010 11:06 PM

The next pharo sprint:

Date: March 13, 2010
Time: 9:30 - 21:30
Place: Software Composition Group, University of Berne, Switzerland

See here for more details.

by Torsten (noreply@blogger.com) at March 08, 2010 04:36 PM

The http://pharobyexample.org book now includes a new chapter on Exception handling in Smalltalk.

by Torsten (noreply@blogger.com) at March 08, 2010 01:03 PM

If you want to do software and data analysis then you should read the
new online book from Tudor Girba:

http://www.themoosebook.org/book

about the Moose technology. Moose is an analysis platform written in Smalltalk.

The (yet unfinished) book already includes descriptions on how to use Moose, how to build a browser with Glamour or how to load the latest Moose version into Pharo using Metacello.

One interesting aspect (beside a good documentation on Moose) is that this is now the second dynamic web book on Smalltalk technologies (after the Seaside online book) which is written using the Smalltalk based Pier Content Management System.

by Torsten (noreply@blogger.com) at March 08, 2010 12:58 PM

The commits to Squeak trunk (the new community development model) are now also visible in Twitter:

http://twitter.com/SqueakTrunk

Should be easy to follow development now.

If you want to know about other package commits (SqueakSource) then
you could use the already known Planet Squeak code:

http://planetmisc.squeak.org

by Torsten (noreply@blogger.com) at March 07, 2010 09:29 PM

John is building a scratch viewer for the iPhone and iPad.

by Torsten (noreply@blogger.com) at March 06, 2010 12:31 AM

In January, I gave a guest lecture in a class on reflection and metaprogramming at HPI Potsdam. A screencast of the talk is now available. It’s an introduction to the concept of mirrors, which is the goodthink way of doing reflection. It’s mostly language neutral, but there is a brief demo using mirrors in Newspeak.

Because it’s a screencast rather than a video, occasionally some detail may be unclear, but by and large it is the most comprehensive introduction to mirrors available other than the OOPSLA paper.

Some people may not have an hour to watch the entire screen cast, and the paper is by no means an easy read, so I’ve decided to post the executive summary here.

The classic approach to reflection in object-oriented programming languages originates with Smalltalk, and is used in most class based languages that support reflection: define a reflective API on Object. Typically, Object supports an operation like getClass() which returns an object representing the class of the receiver. The API of classes defines most additional reflective operations available. For example, in Java, you can get reflective descriptors for a class’ methods (java.reflect.Method), fields (java.reflect.Field) and constructors (java.reflect.Constructor). You can even use these descriptors to evaluate program code dynamically - say, ask the user for the name of a method and invoke it. In Smalltalk, you can also add and remove methods and fields, change a class’ superclass, remove classes from the system etc.

Another approach is used in many scripting languages. The language constructs themselves introduce code on the fly, modifying the program as they are executed. For example, a class comes into being when a class declaration is evaluated, and might change if another declaration of a class with the same name is executed later.

The third approach is that of mirrors, and originates in Self. Mirrors have been used in class based systems such as Strongtalk, and even in the Java world. JDI, the Java Debugger Interface, is a mirror based reflective API. Here, the reflective operations are separated into distinct objects called mirrors. This seemingly minor restructuring has significant implications. Reflection is no longer tied into the behavior of every object in the system (as it is via getClass()) or (even worse) into the very syntax of the language. Instead, it resides in separable components that can be removed or replaced. Reflection is now a distinct capability, in the sense of the object capability model.

If you are worried about security, this is good news. If you don’t provide a program with the means to manufacture mirrors (e.g., you do not provide the mirror factory object), said program cannot do any reflection. You can also provide mirrors with limited capabilities - say mirrors that only reflect the program’s own code, or mirrors that do not allow you to modify code or access non-public members etc.

Caveat: The truth is, mirrors have not really been used for security. Their utility for security seems clear, but a working API has yet to be demonstrated.

Mirrors are good news for other reasons. Say your program doesn’t use reflection, and needs to fit into a small footprint such as an embedded device. It is easy to take it out. Another advantage is that you can easily plug in alternate implementations of reflection - so if you need to reflect on remote objects, you can do so.

Historical note: This is why JDI uses mirrors; indeed, it is why JDI had to be introduced. The original intent was that Java reflection would be used to support debugging; but once you need to deal with cross-process debugging, you need a distinct implementation of reflection; core reflection is tied to a single built in implementation.

Mirrors support a clear boundary between the base-level of your program (the level which deals with the problem domain your program is intended to solve) and the meta-level (the level where your program is discussing itself, where reflection takes place). The classic design, where the class is the main repository of reflective information, tends to blur these lines. Classes often have both base level functionality (like creating instances) and meta-level functionality (reflection). This is most acute in languages like Smalltalk and CLOS. In Java, the base level roles of classes are often supported by specialized constructs like constructors (which have their own, worse, problems) and
static members (likewise). Even in Java, class objects may be used in a base level capacity (as type tokens, for example).

There is much work to be done in this area. No mirror API has yet fulfilled all my claims and ambitions - least of all the Newspeak mirror API, which needs extensive revisions. Still, I hope you’re curious enough to watch the talk and/or read the paper.

by Gilad Bracha (noreply@blogger.com) at March 05, 2010 04:46 PM

For the last official meeting of this instantiation of the Squeak Oversight Board everyone was present: Jecel Mattos de Assumpção Jr, Ken Causey, Bert Freudenberg, Craig Latta, Andreas Raab, Randal Schwartz, and Igor Stasenko.

First we would like to remind everyone that the 2010 election for the Squeak Oversight Board is coming up very soon.  For more information see  http://wiki.squeak.org/squeak/6150.

Recently we announced an anticipated release date for the MIT/Apache licensed Squeak 4.0.  The word is getting out as evidenced by the fact that this site received 5-10 times the usual amount of traffic soon after that announcement was posted.  Ronald Spengler is kindly leading the effort to finalize the packaging of Squeak 4.0 and you should be watching squeak-dev for pre-release versions and related news.

Relatedly  we continue to work with the Software Freedom Conservancy to finalize issues related to our joining this organization.  We are hopeful of completing this not long after Squeak 4.0 is released as this release is essential to the process.

Our next meeting is scheduled for 3/24/2010.  Note that this is a week later than our usual meeting date.  The plan is to have a special meeting with all current and newly elected SOB members to get the new board up to pace quickly.  We will be contacting candidates soon to clarify the plan.

by Ken Causey at March 03, 2010 10:28 PM

This will be a special meeting of both new and old Squeak Oversight Board members to facilitate ‘passing the ball’ to the new Oversight Board.

by Ken Causey at March 03, 2010 08:37 PM

There is now a new website available for the Cologne Smalltalk Meetup.

by Torsten (noreply@blogger.com) at March 02, 2010 03:07 PM

Physical Etoys is a visual programming tool that connects the virtual world of computers with the real world in which we live in. Now a first beta version is released.

It is based on the Squeak Smalltalk system. The announcement is here.

by Torsten (noreply@blogger.com) at March 02, 2010 08:35 AM

Lukas announced the printed version of "Dynamic Web Development with Seaside".

by Torsten (noreply@blogger.com) at February 28, 2010 07:41 PM

A print-on-demand, softcover copy of the book “Dynamic Web Development with Seaside” is now available from Lulu.

Seaside is an source framework for developing highly dynamic and interactive web applications, and makes building web applications as simple as building desktop applications. The book gives you all the instruction and support necessary to get up and running in all the popular distributions of Smalltalk, with separate chapters on Pharo and Squeak, Cincom Smalltalk, Gemstone/S, GNU Smalltalk and VASmalltalk.

The printed book is based on the free online version and the purchasable PDF version of the book, and will be updated regularly. The book costs around €28/£24/$40 and will be delivered within 3-5 working days, so order your copy now!

The authors wish to thank the European Smalltalk User Group (ESUG), inceptive.be, Cincom Smalltalk, Gemstone Smalltalk,  and Instantiations for generously sponsoring this book.

by Michael Davies at February 28, 2010 11:10 AM

The Squeak Oversight Board plans to finalize the multi-year effort of re-licensing Squeak. Squeak 4.0 is scheduled to be released on Monday, March 15th, 2010 and will be licensed under the MIT License with some original parts remaining under the Apache License. Further details are on the Squeak Oversight Board page.

by Milan Zimmermann (noreply@blogger.com) at February 25, 2010 07:02 AM

by Randal Schwartz at February 25, 2010 01:07 AM

by Randal Schwartz at February 25, 2010 12:55 AM

After years it is very close:

"The Squeak Oversight Board plans to finalize the multi-year effort of re-licensing Squeak. Squeak 4.0 is scheduled to be released on Monday, March 15th, 2010 and will be licensed under the MIT License [1] with some original parts remaining under the Apache License [2]."

Read more here ...

by Torsten (noreply@blogger.com) at February 25, 2010 12:17 AM

The Squeak Oversight Board plans to finalize the multi-year effort of re-licensing Squeak. Squeak 4.0 is scheduled to be released on Monday, March 15th, 2010 and will be licensed under the MIT License with some original parts remaining under the Apache License. This release will be functionally equivalent to the previous 3.10.2 release. Current development work will be released as 4.1 as soon as possible following the release of 4.0.

This notice is intended as a “last call” before the actual license change takes effect. We have assembled re-licensing agreements from every identifiable contributor. However, if you have contributed to Squeak or know of someone who has contributed and has not been contacted about the re-licensing effort, this notice is intended to make you aware of the upcoming change and to allow you to contact the Squeak Oversight Board regarding your contributions before the license change takes place.

Please distribute this notice widely. Questions or comments should be sent to relicensing@squeak.org.

by Ken Causey at February 25, 2010 12:01 AM

Way back in October 2009, I threatened to write a post about how serialization can serve as a binary format. The moment of reckoning has arrived.

Object serialization is probably most widely known due to Java serialization, but of course has a long history before that. Modula-2+ supported pickling long before Java, for example, as did Smalltalk systems.

Java serialization serializes objects in a most un-object-oriented way: it separates the object’s data from its behavior. Only the data is actually serialized. The object’s behavior (namely its class) is represented symbolically (as fully qualified class names; more on that later). During deserialization, the symbolic class information is used to reconstruct the classes of objects.

The problem is that this only works properly when both serializer and deserializer agree on the interpretation of the symbolic class information. For example, when two VMs running identical versions of the code communicate via RMI (the original use of Java serialization).

If the code in the deserializer differs from that in the serializer, as is very often the case (say, when one wants to load old serialized data) problems arise. The serialized data may not describe instances of the class on the deserializing side at all, because the private representation of the class may have changed.

Tangent: Java serialization introduced an extra-linguistic mechanism for creating instances, that was not considered as part of the language design, which only foresaw objects being created via constructor calls. This too is problematic. What if the invariants imposed by the constructor change over time?

To deal with these problems, one may opt to store data using a more stable schema than the in-memory representation (e.g., a database, an agreed external data format etc.).

Alternatively, one can add conversion routines that map old representations into new ones. This requires identifying the version of the object’s class (aka the serialVersionUID) when serializing an object. This approach is problematic however. Each change of representation requires a new version number, and a new conversion routine. These must be in place before the objects are serialized.

The reliance on class names is also an issue. What of anonymous classes? This is a problem in any case, but aggravated due to the reliance on names.

Tangent: the serialization team was, however, perfectly justified in assuming every class had a well defined name. They were working with Java 1.0, before the introduction of inner classes. Likewise, the inner class team was working on a system without serialization. No one saw the conflict until after the release combining the two - when it was far too late to do much about it.

In contrast, if one actually serializes the objects rather than just the data (that is, one serializes the data and the behavior), the serialized objects are much more self contained. (at some point one still wants to cut things off, but at stable APIs like Object).

If you want to bring old objects up to date, you must convert them; but:

1. You don’t have to; they work exactly as they did the day they were serialized, just like a mummy come to life.
2. You can add the conversion after the fact, at any time; for example, you can deserialize and then convert. The only requirement is that the necessary information is available via the object’s public API.
   

The serialization team didn’t have the option of serializing the classes in the manner just described. The Java byte code verifier makes that impossible. The verifier imposes a nominal type system, which means you cannot have two classes with the same name running in the same class loader.

Tangent: The wonders of byte code verification probably deserve a post of their own. For now, just note this as another example of the kind of difficult-to-foresee interactions that occur between seemingly unrelated parts of a complex system.

Assume we have a system where we can serialize objects including their behavior. Can we use the serialization format as a binary format for code? Specifically, can we use serialized class objects as our binary format?

In Newspeak, top level classes, also known as module declarations, are stateless. Hence the serialized form of these class objects is stateless as well, fulfilling a key requirement for a binary code representation.

Module declarations have no external dependencies, so we needn’t serialize a great tangle of objects as is often the case with object serialization.

Tangent: This is what a module is supposed to be: something that can be built independently! This also means that you can load modules declarations in any order. I note with glee that this runs against the entire tradition of ADTs as the basis for software modularity.

Entire applications can be represented this way as well - it’s simply a matter of creating an object that ties together the various module declarations used by the application. This source form of this object acts like your makefile, and its serialized form is analogous to an executable (or a JAR or whatever). To make this more concrete:

A Newspeak application is an object conforming to a standard API. This API consists of a single method, main:args:.


class BraveNewWorldExplorerApp fileBrowserClass: fb = (

| BraveNewWorldExplorer = fb. |

)(

“MAIN METHOD”

public main: platform <nsplatform> args: argv <list> = (

| fn <string> |



fn:: argv at: 1 ifAbsent:[ 'C:/Users'].

platform hopscotch core HopscotchWindow openSubject:

((BraveNewWorldExplorer usingPlatform: platform) FileSubject onModel: fn

)))


You need not understand every detail here; what is important is the following:

An serialized instance of BraveNewWorldExplorerApp acts as our binary. The Newspeak runtime loads such a serialized object, deserializes it, and invokes its main:args: method. The latter invocation is very similar to what a JVM does when it loads the main class of a program and calls its main() method, or for that matter, what C does with the main() function.

The method is invoked with two parameters (here we differ from the mainstream). The second of these represents any (command line) arguments to the program, just like argv in a C program. What is different is the first argument, platform, which represents the Newspeak platform. The precise meaning of the expression inside the method is relatively unimportant. What matters is that we use the platform argument in two places: first, to instantiate the file browser module, so that it can make use of platform code; and second to access the GUI (platform HopscotchFramework).

In this case, the application instance is created with a single parameter, the module declaration for the file browser.
More complex applications tie several modules together; in that case, the app module would be instantiated with a series of parameters, one for each module declaration required by the application.

To make it easy for developers, our IDE uses a standard convention for instantiating and serializing application objects. If a top level class has a class method packageUsing:, the IDE will assume the class represents an application, and allows us to create a deployable app with the push of a button.

public packageUsing: ideNamespace = (


^BraveNewWorldExplorerApp fileBrowserClass: ideNamespace BraveNewWorldExplorer


)


The IDE will call the class method, passing it a namespace object as a parameter. The method can use that namespace to look up any available module declarations that it needs to gather into the application, and compute an application object that references them all. This application object is then serialized. This packaging process is somewhat analogous to constructing a JAR file.

Semi-tangent: We also allow you to output more common/mundane deployment formats like Windows executables. Likewise, MacOS apps or Linux rpms can (and likely will) be added; a small matter of programming. Most interesting, and still in flight, deployment as web pages.

We have serialized/deserialized applications, such as the compiler and the IDE, into binary objects a few hundred kilobytes in size. However, this isn’t our standard modus operandi yet. Right now, we are still slowly untangling ourselves from the Squeak environment.

What then is the moral of the story? Well, one moral is that a running application can be thought of as an object, combining state and behavior; moreover, classical binary formats like a.out can be thought of as serialized objects.

Why is this profitable? Because we can cover more ground with less concepts, and less implementation effort. For example, rather than class files, JAR files and serialized objects, we can do with serialized objects alone. Moreover, we can do better with this one mechanism than we did with the other three combined. Less is more. And that is the moral of many stories.

by Gilad Bracha (noreply@blogger.com) at February 24, 2010 12:23 AM

Lukas has a first copy of the Seaside book which is printed from the online version.

by Torsten (noreply@blogger.com) at February 23, 2010 02:44 PM