Planet Squeak

Squeak Oversight Board: Preliminary Agenda for 2/17/2010

2010-02-07T21:10:03+00:00

Squeak 4.0 and SFC

Free server hosting options

Promotion and Visibility of Squeak

Development Progress

Squeak Swiki Improvement

Squeak Oversight Board: Meeting Report for 2/3/2010

2010-02-07T21:09:45+00:00

Once again everyone was present and accounted for today: Jecel Mattos de Assumpção Jr, Ken Causey, Bert Freudenberg, Craig Latta, Andreas Raab, Randal Schwartz, and Igor Stasenko.

While we are reviewing other issues are focus right now is primarily on completing the process involved in releasing Squeak 4.0 and joining the Software Freedom Conservancy. We are still checking facts and looking for possible problems but the chances look good for an imminent (small number of weeks) release. One aspect of that is actually taking care of the packaging of 4.0 and updating places where the licensing of Squeak is referenced. Expect a post on squeak-dev soon to discuss this issue and hammer out the details.

We spent much of the rest of the meeting discussing the election process. Part of our agreement with the SFC specifies how the ‘governing committee’ (AKA Squeak Oversight Board) is formed. After the retirement of the SqueakPeople website was which was an integral part of forming the voters list for the Oversight Board election the process has temporarily become somewhat informal. After discussing this in some detail we realized that trying to formalize things a bit more this year would likely just disrupt the upcoming election and so we ultimately decided to set this issue aside for now. After the election the new Oversight Board and the Election Team should work on this issue with the assistance of the entire community.

Thanks to Chris Cunnington with assistance from others on squeak-dev instructions on how to install Seaside on Squeak were placed on the Squeak website and linked to from the Seaside website. As a community we fully intend to ensure that Seaside continues to run on Squeak.

Our next meeting is scheduled for 2/17/2010.

Torsten Bergmann: Monticello, Metacello ... Metaceller

2010-02-05T15:16:50+00:00

Metacello is a nice package management system for Monticello in Pharo.
There are already various configurations for well known packages available in the MetacelloRepository project.

With a pharo image installed Metacello can be used to load a specific (or the latest) versions of Seaside:

  Gofer new
    squeaksource: 'MetacelloRepository';
    package: 'ConfigurationOfSeaside30';
    load.

 (Smalltalk at: #ConfigurationOfSeaside30) loadLatestVersion

Tudor Girba now created a basic version of a browser called "Metaceller" for managing Metacello configurations that are already loaded in the image. Read more here.

To load in Pharo evaluate:

 Gofer new 
        squeaksource: 'glamoroust'; 
        package: 'ConfigurationOfGlamoroust'; 
        load. 
 (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault.

After loading you can open the tool using:

 GTMetaceller open

Torsten Bergmann: Smalltalk meetup in Cologne

2010-02-01T19:39:40+00:00

There is a Cologne Smalltalk User Meetup on 18th of February.
Read more here.

Gilad Bracha: Nail Files

2010-02-01T19:37:37+00:00

Files are extremely important in current computing experience. Much too important. Files should be put in their place; they should be put away.

There are two aspects to this: the user experience, and the programmer experience. These are connected. Let’s start with the user experience.

Users see a hierarchical file system (HFS), with directories represented as folders. The idea of an HFS goes way back. The folder was popularized by Apple - first with the Apple Lisa , the ill-fated precursor of the mac, and then with the mac itself.

Historical Tangent: The desktop metaphor comes from Xerox PARC. I know some of that history is controversial, but one thing Steve Jobs did NOT see at the legendary 1979 Smalltalk demo was a folder. Smalltalk had no file system to put folders in. To be fair though, Smalltalk had a category hierarchy navigated via a multi-pane browser much like the file browsers we see in MacOS today. The folder came later, with the Xerox Star (1981 or so).

David Gelernter has said that computers are turning us into filing clerks. Sadly, his attempt to fix this was a commercial failure, but his point is well taken. We have seen attempts to improve the situation - things like Apple’s spotlight and Google desktop search - but this is only a transition.

Vista was supposed to have a database as a file system. This is where we’re going. Web apps don’t have access to the file system. Instead we see mechanisms like persistent object stores and/or databases. Future computers will abstract away the underlying file system - just like the iPhone and iPad. Jobs gave us the folder (i.e., the graphical/UI metaphor for the HFS) and Jobs taketh away.

This trend is driven in part by an attempt to improve the user experience, but there are also other considerations. One of these is security - and better security is also better user experience. Ultimately, it is about control: If you don’t have a file system, it becomes harder for you to download content from unauthorized sources. This is also good for security, and in a perverse way, for the user experience. And it’s also good for software service providers.

Tangent: This is closely tied to my previous post regarding the trend toward software services that run on restricted clients.

Which brings us to the programmer experience. File APIs will disappear from client platforms (as in the web browser). So programmers will become accustomed to working with persistent object stores as provided by HTML 5, Air etc. And as they do, they will get less attached to files as code representation as well.

Most programmers today have a deep attachment to files as a program representation. Take the common convention of representing the Java package hierarchy as a directory hierarchy, with individual classes as files within those directories.

Unlike C or C++, there is nothing in the Java programming language that requires this. Java wisely dispensed with header files, include directives and the C preprocessor culture. This is a great help in fighting bloat, inordinately long compilation times, platform dependencies etc.

A Java program consists of packages, which in turn consist of compilation units. There are no files to be found. And yet, the convention of using directories as a proxy for the package hierarchy persists.

Of course, it’s not just Java programmers. Programmers in almost any language waste their time fretting over files. The only significant exception is (bien sur!) Smalltalk (and its relatives).

Files are an artifact that has nothing to do with the algorithms your program uses, or its data structures, or the problem the program is trying to solve. You don’t need to know how your code is scattered among files anymore than you need to know what disk sector it’s on. Worrying about it is just unnecessary cognitive load. Programmers need not be filing clerks either.

With modern IDEs, one can easily view the structure of the program instead. In fact, the IDE can load your Java program that much faster if it doesn’t use the standard convention. You can still export your code in files for transport or storage but that is pretty much the only use for them.

I suspect these comments will spur a heated response. Most programmers have used the file system as a surrogate IDE for so long that they find it hard to break old habits and imagine a cleaner, simpler way of doing business. But do note that I am not arguing for the Smalltalk image model here - I’ve discussed its strengths and weaknesses elsewhere.

What I am saying is that your data - including but not limited to program code - should be viewed in a structured, searchable, semantically meaningful form. Not text files, not byte streams, but (collections of) objects.

As file systems disappear from the user experience, and from client APIs, newer generations of coders will be increasingly open to the idea of storing their code in something more like a database or object store. It will take time, and better tooling (especially IDEs and source control systems) but it will happen.

Miguel Cobá: Seaside book - PDF version

2010-02-01T19:28:39+00:00

Just announced on the Lukas Renggli’s blog:

The PDF version of the book Dynamic Web Development with Seaside is available to download now:

http://book.seaside.st/book/introduction/pdf-book

At the end of the payment process (PayPal) you will be redirected to the download area where you are able to get the latest builds of the PDF version of the book. If you bookmark the page you will be able to download fixes and extra chapters as we integrate them into the online version. By buying the PDF version you support our hard work on the book.

We wish to thank the European Smalltalk User Group, inceptive.be, Cincom Smalltalk and GemStone Smalltalk for generously sponsoring this book. We are looking for additional sponsors. If you are interested, please contact us. If you are a publisher and interested in publishing this material, please let us know.

So if you’re looking for a updated reference to Seaside, this is the book to have. Support the effort by purchasing a copy in PDF version. Also, soon they will have this version available in lulu so that if you prefere the dead-tree version, you’ll also soon have access to it.

Ramon Leon: Dynamic Web Development with Seaside PDF Available for Purchase

2010-02-01T10:02:20+00:00

Reposted from Lukas Renggli blog:

The PDF version of the book Dynamic Web Development with Seaside is available to download now.

So please, support the Seaside community and buy the book, I know I will.

Milan Zimmermann: Using Etoys to Develop XO Sugar Activities

2010-02-01T00:27:50+00:00

This blog describes how to use Etoys to develop a XO Sugar Activity. Let me start with a FAQ. Blog FAQs - Using Etoys to Develop XO Sugar Activities Changes: February 2010 added a note about different ways of installing the Sugar Operating System added a note about Etoys and Squeak What is the Goal of this Blog? This blog will talk about development of Sugar Activities in Etoys; it will also

Julian Fitzell: Easing compatibility with Grease

2010-01-30T08:35:36+00:00

Photo by DarkSide, sxc.hu

In December, I gave a presentation on portability to the NYC Smalltalk group. Seaside now runs on at least seven different Smalltalk distributions. Given the lack of standardization, this is no minor feat; for Seaside’s developers, the need to keep code portable is always on our mind. As a result, we have gradually accumulated a set of tools, patterns, and conventions to help keep our code as portable as possible and to factor out code that needs to be implemented differently on each platform.

In our work on other projects, we found the same portability challenges came up over and over and we wanted to use the tools we had developed for Seaside to address them. So we began to split out the Seaside-specific functionality, allowing us to leverage the generic parts it in our other work. And thus Grease was born.

So what exactly is Grease?

Grease enhances the ANSI Smalltalk standard. With only a few exceptions, we assume platforms are fully ANSI-compliant. Platforms want to support Seaside and standardization makes this easier for the project’s developers and its porters.
Grease defines expected APIs with unit tests. Platforms can quickly determine if they are compatible and users can examine the tests to determine exactly which behaviours they can count on.
Grease takes a pragmatic approach to compatibility. Sometimes a method behaves so differently on two platforms, for example, that we are forced to avoid it or to standardize on a new selector. To get standard exception signaling on all platforms, Grease is forced to provide special exception classes that can be subclassed. Sometimes we need to put “right” aside and settle, instead, on a solution that can be implemented everywhere.
Grease tries to be concise and consistent. Despite its pragmatic approach, we still want to be “right” as much as possible. Because it’s hard to remove functionality once it has been added, we need to carefully consider each addition before proceeding. We’re moving slowly and looking for methods that are commonly used and that have clear names and semantics.
Grease does not try to solve all problems. We are not testing Sockets or HTTP clients. We don’t expect platforms to have standard SSL or graphics libraries. Its scope may grow over time, but for now we’re focusing on extending the functionality of the core classes defined in the ANSI standard (collections, exceptions, streams, blocks, etc.) and on other pieces of functionality that are critical to the Seaside project (e.g. random number generation and secure hashing).
Grease is widely adopted. Implementations exist already for all platforms that support Seaside 3.0. As well as Seaside, new versions of Magritte, Pier, and Monticello are already being implemented on top of Grease.

If you’re developing on Squeak or Pharo, you can also benefit from Slime, which uses the Refactoring Browser to find and, in some cases, rewrite common compatibility problems. Think of Grease as defining what you can write and Slime as defining what you can’t. It would be nice if Slime could be extended to other platforms, but their RB implementations are currently not compatible enough (a perfect target for Grease!).

Grease will continue to be part of the Seaside project and to be driven, for now, primarily by Seaside’s requirements. But we hope other projects will find it increasingly useful over time. Since each platform has already ported it, you may already be able to leverage it to provide increased consistency and portability for your applications. For the moment, consider Grease a prerelease and subject to major change; it will track Seaside releases for now, though I’m thinking of assigning independent version numbers to Grease releases to make things clearer.

The Grease packages can be found in the Seaside 3.0 repository or through your vendor's standard code distribution mechanism.

Torsten Bergmann: seasidehosting.st now with Pharo support

2010-01-29T08:35:25+00:00

Adrian announced that the free Seaside hosting service seasidehosting.st now also supports Pharo (as well as any other closure aware Squeak images) since they updated the VM. Cool!

Bert Freudenberg: Interactive OLPC XO Display Simulation

2010-01-27T15:37:49+00:00

Many people still have not seen the innovative display of the OLPC project's "XO" laptop. It has twice the resolution of a regular LCD (200 dpi), and works in bright daylight in gray-scale reflective mode. It's impossible for me to increase your screen's resolution by software, and I cannot make your display reflective, but here is an interactive simulation of the backlight mode with its interesting color pattern. This pattern is the source of a lot of confusion about the "color resolution" of the display. The LCD has 1200x900 square pixels, but the backlight puts a full color through each pixel. It is not made of red, green, and blue sub-pixels like a regular LCD, but the first pixel is full red, the second green, the third blue, and so on. The DCON chip (Display CONtroller) selects the color components from the full-color frame buffer.

My simulation of the DCON achieves the same effect by selecting either the red, green, or blue color component in each pixel. Just move the mouse pointer around to see how different colors are reproduced. You'll notice strong diagonal patterns, but remember, on the actual display the pixels are only half as large. Note that the actual DCON optionally applies a bit of anti-aliasing in hardware which is not simulated here. It helps reproducing fine structures and depicts colors more accurately. Additionally, the simulation shows a magnified image to better illustrate the principle, but it is not accurate because the reflective area of each pixel is not depicted. Maybe I can add this in a later version.

I made the simulation using Squeak / Etoys, which is one of the programming environments on the OLPC machine, but also works on Windows, Mac OS X, Linux, and many more systems. If you run the simulation on the actual laptop (download the project, place it in /home/olpc/.sugar/default/etoys/MyEtoys, run Etoys, choose Load Project), then you should close the small simulated screen and just leave the magnified view open.

For the interactive simulation, download Squeak (this version installs both, a regular application and a browser plugin), then click here to run the simulation in your browser, or download the project file, launch Squeak, and drop the project into it.

Intel-Mac users beware, the plugin is not supported directly yet. To see the project in Safari, you have to quit Safari, set it to open in Rosetta (select Safari in the finder, press Cmd-i), and reopen. Or, use the download method, Squeak itself is running fine on Intel Mac, it's just the browser plugin that's making problems.

Bert Freudenberg: Etoys kid-tested on XO

2010-01-27T15:37:42+00:00

I brought my green machine home this weekend, and my twins had fun with it. Enormous fun in fact for the two 7-year olds, pounding on TamTam furiously. I couldn't bear it anymore after half an hour or so.

Instead, I showed Jakob how to make a little figure bounce around on the screen in Etoys, while his sister went to practice her cello. He painted a simple head, and then we used the "forward by" and "bounce" tiles in a tiny two-line script making it move around. I made the mistake of pointing out that the "bounce" tile can produce some noise when bouncing. Endless fun trying the different noises ensued. Oh well.

Disturbed in her practice by these noises, Sophie came over and wanted to paint, too. So we saved Jakob's project and started a new one for her. I sat back to work on my email and let her brother teach. She spend like half an hour just painting the figure. The paint tool showed that it is not tuned to the XO's display resolution yet, it's far too small. But not giving up that easily, Sophie was erasing and repainting it over and over until she was satisfied with her "cow girl". Then Jakob proudly told her how to let it move and bounce, he had rembered almost everything needed. Together they quickly made it work, and just started exploring the noise-making possibilities again when we were saved by the call to dinner ...

Bert Freudenberg: OLPC talk at design school

2010-01-27T15:37:34+00:00

I gave a talk about the $100-laptop at the Magdeburg school of Industrial Design. We did some very inspiring projects using Squeak, Etoys, and Croquet together before. The designers always come up with interesting ideas, even though not everything is directly implementable by us developers.

Carola Zwick, dean of the school, wrote a book Designing for Small Screens that certainly gives valuable insight for OLPC developers, and she provided (though indirectly) some very important infrastructure for the OLPC office: her group designed the chairs they are sitting on. I got the actual invitation by Christine Strothotte, who got her PhD doing computer graphics in Smalltalk just a few years before I got mine from the same school. She's teaching interaction design nowadays. I'm looking forward to doing an OLPC-related project with these great folks.

A student took some photographs during the talk. Also, from his blog post it seems I convinced him of the merits of the OLPC project (it was a lively discussion). Thanks for posting, Cheng!

Bert Freudenberg: Sophie, Tweak on the OLPC laptop

2010-01-27T15:37:26+00:00

I just installed Sophie on my green machine. Sophie is a project of the Institute for the Future of the Book, is implemented in Squeak (just like my Etoys activity on the laptop) using Tweak as its UI framework (which is the original topic of my blog). Tweak is also the base for the next-gen Etoys.

Installation went pretty smooth. I downloaded the cross-platform zip file using the Web activity from Sugar
and unpacked it using the command line. The first start of Sophie failed, but after replacing the failing plugin with one from the pre-installed Squeak it started and worked. Yay!

This is an excellent example why it's a good idea to have a regular X11 installation on the kid's laptop: a lot of software will just work, even if it is not correctly integrated into the Sugar UI.

Michael Rüger of impara (a Squeak shop leading Sophie development here in Magdeburg, Germany) came over and made a little book, downloading two logos directly from the web (Sophie can do that!), adding a bit of text and color ... Tweak performance is not exactly blazing on the XO machine, I think we made the right decision to not use the Tweak-based Etoys but stick to the proven Morphic-based one. Of course one could optimize it a lot, but who has time for that? Anyway, it was useable - click the image to get a larger view:

Bert Freudenberg: Squeak for every child

2010-01-27T15:37:18+00:00

Lately I work on Squeak integration in the One Laptop Per Child (OLPC) project, perhaps better known as the "$100 laptop". The whole etoys group came over to OLPC's office in Cambridge. Squeak looks surprisingly well on the display prototype, and also etoys are reasonably fast. Ian Piumarta took some nice pictures, which might very well be the first photos of the actual display in the wild.

Torsten Bergmann: Seaside - PDF Book

2010-01-27T14:14:59+00:00

Lukas announced a PDF version of the online Seaside book.

Randal Schwartz: Pier2 on Seaside3 on Squeak Trunk

2010-01-27T01:22:39+00:00

Apparently, while I wasn't looking, some Very Smart People finally ported Pier to new Seaside, which I've been waiting for as a prerequisite to cutting www.stonehenge.com over to Seaside and away from Perl. It's a bit tricky to get it all installed, but I have this magical set of incantations that can bring it in as needed:

(Installer ss project: 'MetacelloRepository') install: 'ConfigurationOfMetacello'; install: 'ConfigurationOfPier2'!
ConfigurationOfMetacello loadLatestVersion!
ConfigurationOfMetacello project latestVersion load: #('UI')!
ConfigurationOfPier2 load!

Stick these into a file ending in ".cs", and then drag that file into an updated Squeak-Trunk image, or pull up a file list and browse to it and file it in. After about 5 minutes and a lot of net downloads, you have a "squeak trunk plus seaside 3 plus magritte plus pier 2" image. Yeay!

Read and post comments | Send to a friend

Torsten Bergmann: Pharo 1.0 Release Candidate 2 and image building

2010-01-26T21:44:04+00:00

There is a new Pharo 1.0 RC2 (release candidate 2) image available. If you are on Windows you can also download the new setup. But there is much more going on in the Pharo community going on than just a new image.

The interesting stuff is that by using the Metacello packaging system one is able to load packages that are compatible with Pharo. Try the examples in the provided intro workspaces of RC2 and check out Dales blog for more metacello news.

After playing a little bit with it and cleaning up my projects I'am now able to load a Seaside sample application - here MetaSource with dependencies like FFI, Seaside 3.0, JQueryWidgetBox, ... just by providing a metacello configuration and evaluating a simple script:

Gofer new squeaksource: 'MetaSource'; package: 'ConfigurationOfMetaSource'; load. ((Smalltalk at: #ConfigurationOfMetaSource) project version: '1.0-alpha1') load

There is also a loader in preparation to ease this a little bit more. However - it is really easy now to build custom images like the one with MetaSource - a simple seaside application:

Torsten Bergmann: German Smalltalk evening in Munich

2010-01-26T14:15:03+00:00

There is a german Smalltalker Meeting ("Smalltalk-Stammtisch") on
27.1.2010 in Munich. Just visit the Laab location in the evening. Entrance is free.

There will be a presentation from Thomas Stalzer on "Distributed Objectmodels". If you want to apply just send a short mail with your name to the organizer (Steffen.mueller AT VisKonz.de)

See also Joachims blog.

Randal Schwartz: Squeak on Android!

2010-01-25T21:10:57+00:00

Andreas Raab writes:

As a result of my weekend distraction you can now download and run
Squeak on any Android based phone. If you have an Android phone, simply
search for "squeak" in the Android market place and it should find it
right there (sorry, Google doesn't seem to give web access to the apps
in the store so I can't send a link).
Please be aware that this is not a full port yet. It's a weekend effort
to show the basic feasibility. Lots (and I mean *lots*) of things are
still missing from a full port (among those is text input and network
support to name just two of the more glaring ones). However, I would be
*very* interested to hear if (and how well) it works for other
Android-based cell phones. So if you have a Motorola Droid or or a
T-Mobile G1 give it a shot and post some benchmark results.

Cool! I don't have an Android (yet :), but I think this is pretty interesting. Squeak already runs on the iPhone (two applications in the Apple App store), although not in a way that lets your program it.

Read and post comments | Send to a friend

Gilad Bracha: Closing the Frontier?

2010-01-24T23:37:46+00:00

How is a programming language interpreter like pornography? They’re both banned at the iPhone App store. The restrictions on interpreters disturb me (this blog does not deal with the other topic).

What if I want to write an iPhone app in my favorite programming language? Or my second favorite? The freedom to program in the language of my choice is a big concern of mine. Even though Squeak Smalltalk runs on the iPhone, and Newspeak runs on top of Squeak, I’m out of luck. Packaging the entire runtime with each app is not attractive.

Tangent: In principle, one should be able to write a compiler that spits out Objective-C. After all, Objective-C incorporates Smalltalk style message sends, down to the keyword syntax. In practice, Objective-C on the iPhone doesn’t support true garbage collection, so it just seems too painful. This may change soon - maybe as soon as Wednesday., with iPhone OS 4 and/or the iTablet (pick your favorite rumor).

The iPhone is a prime example of a trend where our computing platforms become more restricted. As we move toward software as a service rather than an artifact, the computer is no longer as personal; it is very much under control of the service provider. In this case Apple, in other cases Amazon or Google or Microsoft. I’d be surprised if the rumored iTablet won’t work on the same model: rather than an open version of MacOS, a semi-closed world with an app store.

I completely understand why service providers place these restrictions. What if my app is a storefront for apps? Whither the app store’s revenue? And then there are security concerns.

On the iPhone, there are administrative restrictions. Other platforms are more open in that respect - but you tend to run into technical problems. Take Android - you can distribute a language runtime, but it is the Javanese VM that’s in charge.

No one will prevent you from implementing your own system on a JVM or on .Net. However, the VM, by its architecture, will make things difficult. If it does not support the right primitives, you find that your language is a second or third class citizen.

Examples: the typed VM instruction sets are a problem for dynamically typed languages. On .Net, the DLR provides some support, but you’ll never get to peak performance using it as it stands today. On the JVM, invokedynamic will ship some sunny day, and that will be better. Even then, if you want real dynamism, you’ll find it very hard. How do you change the class of an object? How do you change the shape of a class? Or its superclass? The solutions are convoluted and/or suboptimal.

On the desktop, you can choose to bypass these platforms, but the action is increasingly moving elsewhere. Looking ahead, the dominant platforms won’t be traditional operating systems like Windows, MacOS and Linux; far fewer people will use them directly than today. Instead, we’ll have the web (as in, e.g., ChromeOS), and semi-enclosed service platforms: The moral equivalent of iTablet OS (regardless of what Apple does this Wednesday). The “real OS” may still be there underneath, but virtually no one will care.

Each of these service platforms will combine a client side, running on phones, tablets, e-books, laptops (e.g., iPhone, Android, Kindle, ChromeOS) and desktops; and a server side (e.g., Azure, Google, E3, iTunes/MobileMe) supporting storage/backup, software update and distribution and services we haven't invented yet.

The most open of these virtual platforms is of course, the web browser. Mercifully, it is relatively free of administrative restrictions and its machine language is much more flexible than MSIL or JVM byte codes (JVML). Which is not to say that you don’t have to go through some very convoluted and costly hoops. Think of weak pointers/finalization; or stack manipulation (debuggers, tail recursion) etc.

There are two threads here:

The narrow technical one, which is about providing abstractions that are good enough to support alternate ways of doing things. One wants flexible designs, especially in the languages that are supposed to be at the heart of general purpose open platforms. Of course, this is much easier said than done.
The broad technological/social/commercial one: the trend toward software services and the cloud is pulling us away from the personal computer and the individual control it entails. Of course, one of the great attractions here is the idea of a service that relieves much of the responsibility for digital housekeeping. The vast majority of people don’t want all that control with the trouble that goes with it. Balancing this with the freedom to innovate at the platform and language level, and the freedom to choose among languages, is hard.

Long term, the platforms that have more flexibility will benefit more from new ideas, which gives me a basis for unnatural optimism :-)

Torsten Bergmann: GemDev IDE - Smalltalk in Eclipse

2010-01-21T10:01:33+00:00

GemDev is an experimental implementation of Eclipse-based IDE for GemStone Smalltalk.

See more here.

The IDE provides features like Smalltalk Browser, code editor or object inspector. Interesting.

Squeak Oversight Board: Preliminary Agenda for 2/3/2010

2010-01-21T00:53:13+00:00

Contributor relicensing agreements

Software Freedom Conservancy and Relicensing

Free server hosting options

Promotion and Visibility of Squeak

Development Progress

Squeak Swiki Improvement

Seaside support

Something more? Add a comment…

Squeak Oversight Board: Meeting Report for 1/20/2010

2010-01-21T00:47:55+00:00

Perfect attendance: Jecel Mattos de Assumpção Jr, Ken Causey, Bert Freudenberg, Craig Latta, Andreas Raab, Randal Schwartz, and Igor Stasenko were all present today.

Movement is slow but progressing on the MIT relicensing issue and our intent to join the Software Freedom Conservancy. We are making one more attempt to contact contributors who have not returned signed re-licensing agreements and we will give them a couple of weeks to respond and after that we will take the result and submit it to the SFC for approval. If they are satisfied with it we will label it Squeak 4.0 and will be functionally equivalent to the 3.10.2 release but fully under the MIT license. This is a major requirement for our joining the SFC and once complete we are confident that the rest of the process is reasonably straightforward and hopefully completable on the order of a few weeks.

Once Squeak 4.0 has been released focus will turn to releasing a 4.1 based on the Trunk development work. We are vaguely aiming at releasing this in March or April if all goes smoothly.

One of the issues regarding the release of Trunk development work is how to release an image that has had many packages removed and yet make those removals easily and obviously available for reinstallation to users who are new to Squeak. Andreas brought this issue up on the squeak-dev mailing in hopes that someone would become interested and come up with a solution. This has not happened as of yet and is a topic we continue to discuss. The reality however is that Andreas and the rest of the Oversight Board have only so much time and other projects that require attention and this one is not likely to get sufficient attention from us before 4.1 is released. Ultimately we will of course do the best we can to make external package installation as easy as possible, but we welcome better solutions than exist today. Please give this issue some thought and if you have an idea, better yet a solution, please bring it to the attention of the community on the squeak-dev mailing list.

The Oversight Board election is coming up soon. Look for campaigner’s comments, ensure you are registered to vote, and vote.

Our next meeting is scheduled for February 3, 2010.

Torsten Bergmann: Smalltalk the good parts

2010-01-20T10:53:45+00:00

Douglas Putnam started a blog called http://smalltalkthegoodparts.com to record his Smalltalk explorations. He starts with a proof of concept for running Smalltalk on Slicehost.

"We believe that Smalltalk can give us a technological advantage in the coming Web 3.0. "

Pssst ... use Smalltalk as your secret weapon and dont tell any other! ;)

Torsten Bergmann: Porting from Java to Smalltalk/Seaside

2010-01-19T09:33:15+00:00

Interesting

Maybe the Smalltalk community should provide tools to ease porting ;)

Torsten Bergmann: Squeak on Android

2010-01-18T11:56:25+00:00

Andreas started to port Squeak to Android. Cool!

Gilad Bracha: Debugging Visual Metaphors

2010-01-18T01:58:08+00:00

My previous post commented on the unsatisfactory state of mainstream IDEs. Continuing with this theme, I want to focus on one of my long term pet peeves - debugger UIs.

Donald Norman, in his book The Design of Everyday Things, makes the point that truly good designs are easy to use, because they make it intuitive how they should be used - in his words, they afford a usage pattern.

How do you describe the state of a running program on a whiteboard? You draw the stack. So it seems to me that a stack is the natural visual metaphor for a debugger. Here is a screen shot of our new Hopscotch-based debugger, which will soon replace the Squeak debugger in the Newspeak IDE.

You can see that the debugger looks like a stack trace. Every entry in the stack trace can be expanded into a presenter that shows that stack frame - including the source code for the method in question, and a view of the state of the frame - the receiver, the variables in the activation, the top of the evaluation stack for expressions (i.e., the last value computed).

Of course, this isn’t my idea. It’s another one of those great ideas from Self, as evidenced in this screenshot:

we already stole the idea from Self once before, in Strongtalk, as shown here.

One of the nice properties of the stack oriented view is that you can view multiple stack frames at once, so you can see and reason about a series of calls, much as you would at your whiteboard.

In contrast, most IDEs (even Smalltalk IDEs) show a multi-pane view, with one pane showing the source for the current method (in its file, naturally), one pane showing the state of the current frame, and one showing the stack trace.

You can’t easily see the state of the caller of the current method, or its code, while simultaneously looking at the current method (or another activation in the call chain). And if you modify the current method’s code (assuming you can do that at all), you’re likely locked into a mode, and can’t see the other frames unless you save or cancel your changes.

Hopscotch GUIs are inherently non-modal - so you can modify any one of the methods you’re viewing, and then link to another page to view, say, the complete class declaration, all without opening another window and without having to save or lose your work.

The fact that one rarely needs more than one window is one of the things I really like about Hopscotch. There’s no need for a docking bar, or tabs for that matter. Tabs are popular these days, but they don’t scale: they occupy valuable screen real estate, and beyond half a dozen or so become disorienting and unmanageable.
Hopscotch does better than the mainstream, and better than previous efforts like Strongtalk or Self, partly because of its navigation model, and partly because of the inherent compositionality of tools built with it. The fact that I can move from the debugger to the class browser in the same window did not require special planning - it’s inherent in the way Hopscotch based tools behave - they can be composed by means of a set of combinators. Compositionality is one of the most crucial, and most often overlooked, properties in software design; it’s what sets Hopscotch apart.

You can find out more about Hopscotch in this paper and on Vassili ‘s blog.

The design of debugger UIs is one example of something that needs to change in modern IDEs. There are others of course. Many are related to the basic problems of modality, navigation and proliferation of panes/windows noted above. Overall, your typical IDE UI is too much like the control panel of a B-52 bomber or an Apollo space capsule: a mind boggling array of switches, gauges, controls and wizards that interact with each other in myriad and confusing ways. This is neither necessary nor desirable. Like explicit memory management and primitive types, in time we will progress beyond these.

Gilad Bracha: Invisible Video

2010-01-18T01:56:27+00:00

A quick update; several people have told me that the Smalltalk Solutions video of the Hopscotch demo is unhelpful, since you can't see the screen. I should have watched it before linking to it; I apologize. Since I was in the room during the presentation, I didn't think to watch it again. My bad. I've taken the link down. We'll produce a viewable demo for download and post it in th enear future. Again, apologies to to anyone who spent time downloading/watching the unwatchable.

Gilad Bracha: Apologia

2010-01-18T01:56:27+00:00

Here’s a quick update on the status of the Newspeak prototype release. If anyone is keeping score - I had said we’d put something out in the first week of January 2009. So we’re behind schedule. I apologize, but what are you going to do - cut my funding?

Nevertheless, we will be putting a prototype out soon. I’m holding off so that a few small things can be added.

In the meantime, I wanted to take the opportunity to say a bit about the prototype. Obviously, due to our reduced circumstances, it is a lot less ambitious than I had once hoped.

We do have a native GUI binding on Windows; I had hoped to have native GUI bindings for Mac and Linux, but that will depend on future open source contributions. You can of course run the system on those platforms, but you’ll have to live with the Morphic binding for now.

The language itself remains incomplete as well - but the key features are there. I expect to rev the syntax and add the missing features (like object literals) over time. One of the reasons these features have been delayed is that I want to add them in the context of a completely new compiler. Such a compiler will also make it easier to do ports - e.g., Newspeak on V8.

One of the biggest deficits is the lack of libraries written in Newspeak. We continue to rely heavily on the existing Squeak libraries. We have made some progress on this front, largely through the efforts of some volunteers who got early access to the system. I want to take this opportunity to thank Yardena Meymann, David Pennell and Stephen Pair for their work on the library port. They are all busy professionals who were willing to take the time to do something concrete to help move Newspeak forward. I hope that we’ll see a lot more of that after the release!

What we’ve been doing is porting some of the core libraries from Strongtalk to Newspeak. These libraries have several important advantages: they are small, yet complete enough to run a real system; they are blue book compatible (give or take), so we have a good chance of replacing our uses of Squeak code with them, without excessive disruption; they are quite cleanly written; they have type annotations; and, it so happens, they have a liberal license.

On the other hand, these libraries were not purpose built for Newspeak; no thought has been given to security, the designs do not leverage features like mixins as much as one might etc.. Still, they provide us the with the most realistic path to getting a small stand alone system in the foreseeable future.

This library code will not be anywhere near complete and integrated when we put out the prototype. But it whatever we have will be available, and we’ll move on from there.
There are any number of other things lacking, and no doubt many will be eager to point them out. However, that scarcely matters. What matters is the potential this system has. It’s being put out, so those with the imagination, sophistication and, above all, taste to appreciate it can start using it and contributing to it - eventually realizing that potential.

So for that small elite that has shown interest and appreciation for Newspeak so far - thanks, and hang in there. It will be available, Real Soon Now :-)