### Archive

Archive for the ‘Smalltalk’ Category

## Code Club: The Dynabook Vision Alive and Well

March 13th, 2013 1 comment

This video reminds me of those great stories about kids at PARC… They are using Scratch to teach children how to use their Dynabooks

From the teachers (Alan Kay has obviously developed a mind control device):

“We’d like the outcome of Code Club to be a whole generation that understands… how to make [computers] do what they want, so they can create their own tools and their own games”

“I really wanted to get the kids… learning how to make things work, [rather] than just being consumers”

From a student:

“It’s really good for learning… before we were just… moving around, but… now we know how to make proper games”

“Our mission… to give every child in the UK the chance to learn to code.

It is our aim to have a Code Club in 25% of primary schools in the UK by the end of 2014″

Categories: Tags:

February 1st, 2013 No comments

#### Why

The most frequent use case I have is for pending bug fixes. Imagine this… you find a bug in Pharo that you need fixed to progress on your project, so you fix it. Now, you’ll need the fix to be present anywhere your project is loaded, so what do you do while waiting for the fix to be integrated? You’re obviously not about to manually file in changesets when you have a powerful tool like Metacello! And anyway, you don’t want to have to edit the scripts for your continuous integration server.

#### How

I’ve found two ways I like to handle this scenario. I’ll show the (slightly) easier one first.

##### Method #1 – #customProjectAttributes

This is the method to use for Monticello packages

###### 1. Make sure your configuration has #customProjectAttributes

Depending on the version of Metacello that was used to create your ConfigurationOfMyProject, you may have to add this method (which is easy enough).

In ConfigurationOfMyProject>>project, if you see the following two statements:

 "Construct Metacello project" constructor := (Smalltalk at: #MetacelloVersionConstructor) on: self. project := constructor project.

Change them to the following:

 project := MetacelloMCProject new projectAttributes: self customProjectAttributes. constructor := (Smalltalk at: #MetacelloVersionConstructor) on: self project: project.
###### 2. Define your custom attributes

#customProjectAttributes will return a collection of symbols that will be added to the Metacello platform symbols e.g. #’squeak4.4′ or #’pharo2.0.x’. The following is for the bug fix example we discussed earlier. The general process is a) declare a condition that let’s you know the fix hasn’t been applied in this image (e.g. a class is not present or DNU a message), and if true, add an attribute declaring that (e.g. #’PharoIssue6300′, as below).

customProjectAttributes   | requiresPharoFix6300 requiresPharoFix6382 attributes | attributes := OrderedCollection new.   requiresPharoFix6300 := (Morph canUnderstand: #hasKeymapCategoryNamed:) not. requiresPharoFix6300 ifTrue: [ attributes add: #'PharoIssue6300' ].   ^ attributes.
###### 3. Finally, add fixes to your baseline

With this method, they must be packaged with Monticello. See method #2 below if you have to use changesets or .st files

 spec for: #'PharoIssue6300' do: [ spec package: 'SLICE-Issue-6300-Detach-keymaping-shortcuts' with: [ spec repository: 'http://ss3.gemstone.com/ss/PharoInbox' ]. spec package: 'VimPharo' with: [ spec requires: #'SLICE-Issue-6300-Detach-keymaping-shortcuts' ] ].

##### Method #2 – #preLoadDoIt:

This is the method to use for changesets or .st files

For example:

 spec for: #'common' do: [ spec blessing: #'baseline'. spec preLoadDoIt: #preLoad. ...
###### 2. Define your callback

This method is going to look much like #customProjectAttributes in method #1. The main difference is, since Metacello can not handle file-ins, you will load the code right in this method instead of delegating, as in the following example:

preLoad   | shouldFixIssue7294 | shouldFixIssue7294 := (EventHandler canUnderstand: #keyStrokeRecipient) not. shouldFixIssue7294 ifTrue: [ '/path/to/issue7294.cs' asFileReference fileIn. ].

#### When

So when would you want to use method #2? For one, you may already have a changeset handy. But the other reason is time decay. In Pharo, for example, because of the rapid pace of development, the package you fixed may have another fix applied first. Now, loading your version may silently replace those changes (this is what happens in the MC browser, I assume Metcello works the same way). I’m actually still figuring out the tradeoffs here for myself. For now, I default to method #1 unless I have a specific reason for #2.

#### Summary

So there you have a simple pattern to conditionally load packages or code files in a Metacello configuration

Hope it helps!

Categories: Tags:

## Smalltalk: Extending the Kernel

January 28th, 2013 No comments

#### Motivation

Many time I wish I could send a non-existent message to an object that’s part of the built-in Smalltalk library.

For example:

String>>surroundedByDoubleQuotes   ^ $" asString, self,$" asString.

#### Packaging

##### Simple Case: Project-specific Extensions

In Pharo, I can store this method in a package different from the one of the class in question. This is called an “extension method” and the implementation is currently a bit of a hack… You put the method in a protocol that starts with an asterisk followed by the package name. Thus, for the example above, if my project was packaged in MyPackage, I could package the method with it like this…

For methods that are project-specific, this is all we need (although hopefully now that Pharo is working on first-class packages, it would be great if we could have both a protocol and specify an extension). However, the method above really has nothing to do with a particular project. It seems generally useful; and indeed, I find myself using it over and over.

##### Generally Useful Extensions

In these cases, it doesn’t work to package the method with the project that uses it, because if more than one of these projects are loaded into the same image, one method will override the other, creating a mess in Monticello. So I’ve been experimenting with two approaches.

The naive way would be to package all such methods in one package, e.g. “PharoExtensions”. This is the first thing I tried, but I was a bit uncomfortable with the all-or-nothing idea – that I’d have to load every extension I’ve ever created to use just one.

The most flexible tack is to package each method individually. The method above could be in the “StringSurroundedByDoubleQuotes” package. This way, one could load the method without effecting any other parts of the system. However, a package is a bit heavy-weight for just one method.

##### A Compromise

The current idea I’ve been playing with is to mirror the existing package structure of Pharo. For the above, String lives in “Collections-Strings”, so I tack on a standard suffix, making it “Collections-StringsSpd”. Now, we can load extensions for only the packages we are using, without having a confusing mess of ClassNameMethodName packages.

Categories: Smalltalk Tags:

## Smalltalk Magic: The Simplest Notes Browser That Could Possibly Work

September 11th, 2012 5 comments

From problem to source browser in 2 minutes (it took much longer to write this post about it)!

UPDATE: InspectIt (sorry, first version said “DoIt”):

'/path/to/home/Library/Mail/V2/Mailboxes/Notes.mbox/' asFileReference allChildren select: [ :e | e extension = 'emlx' ] thenCollect: [ :e | e readStream contents ].

Categories: Tags:

## Pharo Smalltalk: An Acknowledgement

July 7th, 2012 1 comment

Mark Watson wrote a nice blog post about his appreciation for Pharo and its progress.

I was inspired to comment on my own experience of Pharo as we move toward 2.0:

Thanks for the shout, Mark! Given how much you’ve enjoyed Pharo so far, I think you’ll be really impressed after the 2.0 release – I’m sure it will be a game-changer.

Much of the work the past few years has been in improving Pharo under the hood, like the new compiler, class builder, vector graphics, keyboard shortcut framework, and countless cleanups. This has been coupled with great leaps in infrastructure, like the CI server testing many variants of Pharo and its VM on Mac, Window, and Linux with every commit.

Now, all these investments are starting to payoff for Pharo users:

• Continuous integration has given us the confidence to replace the uggggly File library with FileSystem, a beautiful object-oriented library which is a joy to work with.
• Nautilus, the new browser, has long-awaited features like a history and custom groups.
• I’ve been playing around today with Vim bindings for Pharo tools, made easy by Keymapping.
• Fuel is a new fast object serializer
• Fuel might soon allow near-instantaneous bootstrap times for Metacello, the new package-mananagement system, which is getting closer to RubyGems (plus tools) every day
• The Pharo Kernel is driving the system to become more modular

I feel that we are close to a tipping point where the system becomes so easy and fun for developers that we will see a self-perpetuating revolution in the IDE. For me, Vim bindings are something I’ve sorely missed since finding Smalltalk two years ago. It’s only now that I’ve seen in Pharo an opening to make that dream a reality…

Now, if we can just clean Morphic…

Categories: Pharo Tags:

## Squeak VM: Compiling for Xcode

January 11th, 2012 No comments

When compiling the VM for Xcode, one has to switch back and forth from the image to the command line. To make things easier, here’s a little script that:

1. empties the build directory
2. generates the sources and cmake info
3. Configures with cmake
4. Opens the project in Xcode

First, load PipeableOSProcess via:

Gofer it squeaksource: 'MetacelloRepository'; squeaksource: 'CommandShell'; package: 'ConfigurationOfOSProcess'; package: 'CommandShell-Piping'; load. (Smalltalk at: #ConfigurationOfOSProcess) load.

Then, execute this script (also available as a gist) whenever you want a fresh Xcode project:

PipeableOSProcess waitForCommand: '/usr/bin/osascript -e "tell application \"Xcode\" to quit"'.   buildDir := FileDirectory on: '/Developer/cogvm/cog/build/'. buildDir entries do: [:e | e name = 'vmVersionInfo.h' ifFalse: [ e isDirectory ifTrue: [ e asFileDirectory recursiveDelete ] ifFalse: [ e delete ] ] ].   StackCocoaIOSConfig new addExternalPlugins: #( FT2Plugin ); generateForDebug; generateSources; generate.   PipeableOSProcess waitForCommand: 'cd /Developer/cogvm/cog/build/; /opt/local/bin/cmake -G Xcode'. PipeableOSProcess waitForCommand: 'open /Developer/cogvm/cog/build/StackVM.xcodeproj'.
Categories: VM Tags:

## Programming Language Rankings

January 10th, 2012 No comments

The Tiobe index is total rubbish. But it’s worse than useless. It’s actually harmful. As Tyler Cowen mentioned in his TED Talk, “Be suspicious of stories”, feeling like you know what’s going on is way worse than admitting you don’t have a clue:

The most dangerous people are those that have been taught some financial literacy

Undoubtedly, there are people out there choosing careers and technologies based on the information age’s “divining by chicken bones”.  Tiobe is based on search engine hits for goodness sake. In the uber-democratic-everyone’s-a-technical-blogger web, of what is “talking about a language” a good indicator? Here is a primary one: that the language and its tools are not sufficient to support development. In other words, the Niobe Index (i.e. search engine results) is inversely proportional to language quality, as seen below:

$I_{n} \approx \frac{1}{Q_{l}}$
Since the equation above is obviously scientific (because it seems “mathy” and nerdy), it must be true. Furthermore (another great smart-people word), if one believes in (yes, like Santa Claus) the Niobe index (which can only be believed because it superficially seems scientific), one must believe my equation, which creates a paradox (another great science-y term).

In a live, open, dynamic environment (like Smalltalk*), the programmer has at their fingertips most of the things they would otherwise be forced to search the internet for, which is succinctly described by Torsten Bergmann. Also, working in a low level language, like C++ (e.g. manual memory management), guarantees search engine love. I used to need a Safari Books membership just to make sure I didn’t shoot myself in the foot.

* I am not pushing Smalltalk. In fact, I can’t wait until someone invents something better (hint, cough; VPRI).

Categories: Tags:

## Cocoa Smalltalk App

December 20th, 2011 No comments

For a while, I’ve been thinking about using MacRuby for native UIs and multiple windows in Pharo on the Mac. I uploaded a proof of concept to https://github.com/seandenigris/PharoMacRubyTest . It has a simple Cocoa UI that uses http to get a value (the current time) from a running Pharo image and displays it in a text field. See the discussion on the Pharo mailing list.

Categories: Tags:

## Metacello Toolbox

December 6th, 2011 2 comments

### Metacello Is Cool

Metacello is a great project that manages your Smalltalk project’s dependencies on:

1. other projects
2. Smalltalk platforms (e.g. Squeak 4.2 vs. Pharo 1.2)

Overcoming the mess that package loading has historically been (imagine trying to guess which version to use of each package of multiple interoperating projects while the platform evolves beneath you!), it lets you say the programmatic equivalent of:

Before loading my project, you must load the current stable version of the OSProcess project. Then, for my first package: if this is Pharo1.2, load version X; if Squeak 4.2, load version Y…

### But We Need Tools!

Writing configurations by hand can be a drag. But fear not! Dale and Co. have created an API to facilitate your workflow. It is described in detail in the draft chapter of Pharo By Example 2. Here’s a walkthrough of my first experience using it…

#### Describing Project Structure

MetacelloToolBox createBaseline: '1.0-baseline' for: 'SimpleApplescript' "Project name" repository: 'http://squeaksource.com/SPDPlayground' requiredProjects: #('OSProcess') packages: #('CommandShell-Piping' 'SimpleApplescript') repositories: #() dependencies: { ('SimpleApplescript' -&gt; #('CommandShell-Piping')). ('CommandShell-Piping' -&gt; #('OSProcess')) } groups: { ('default' -&gt; #('SimpleApplescript')) }.

As good Smalltalk code, it does just what it says – describes the project and its dependencies – namely, that the SimpleApplescript package depends on CommandShell-Piping, which in turn depends on OSProcess. Usually, it would not be our responsibility to describe dependencies of an external package like CommandShell-Piping, but CommandShell currently has no Metacello configuration of its own, so we step in (although creating one would be cleaner :)). Here’s the method it generated:

baseline10: spec &lt;version: '1.0-baseline'&gt;   spec for: #'common' do: [ spec blessing: #'baseline'. spec repository: 'http://squeaksource.com/SPDPlayground'. spec project: 'OSProcess' with: [ spec className: 'ConfigurationOfOSProcess'; versionString: #'stable'; repository: 'http://www.squeaksource.com/MetacelloRepository' ]. spec package: 'CommandShell-Piping' with: [ spec requires: #('OSProcess' ). ]; package: 'SimpleApplescript' with: [ spec requires: #('CommandShell-Piping' ). ]; package: 'SimpleApplescript-Specifications' with: [ spec requires: #('SimpleApplescript' ). ]. spec group: 'default' with: #('SimpleApplescript' 'SimpleApplescript-Specifications' ). ].

Now there was one thing I was unable to specify above. Because CommandShell-Piping is an external package, we need to tell Metacello where to find it (see how quickly things get complicated without Metacello). So I added a line to the generated baseline above:

package: 'CommandShell-Piping' with: [ spec repository: 'http://www.squeaksource.com/CommandShell'; "added manually" requires: #('OSProcess' ). ];

#### Version Snapshot

MetacelloToolBox createDevelopment: '1.0' for: 'SimpleApplescript' importFromBaseline: '1.0-baseline' description: 'initial development version'.

Here, we just did something amazingly cool. Metacello walked through our project’s packages and dependencies and created a version with:

• the current versions of each package
• the appropriate version of each external project (e.g. stable, bleedingEdge)

Here’s the method it generated:

version10: spec &lt;version: '1.0' imports: #('1.0-baseline' )&gt;   spec for: #'common' do: [ spec blessing: #'release'. spec description: 'initial development version'. spec author: 'SeanDeNigris'. spec timestamp: '12/6/2011 10:38'. spec project: 'OSProcess' with: #'stable'. spec package: 'CommandShell-Piping' with: 'CommandShell-Piping-dtl.10'; package: 'SimpleApplescript' with: 'SimpleApplescript-SeanDeNigris.1'. ].

#### Validation

PBE2 advises us to validate our configurations after editing. It’s easy to do, just printIt the following, which will return a collection of problems, if any:

MetacelloToolBox validateConfiguration: ConfigurationOfSimpleApplescript.

#### A configuration is Born

Now we have a functioning configuration. We will commit it so we can start testing it on the different platforms we support:

Gofer new url: 'http://squeaksource.com/SPDPlayground'; package: 'ConfigurationOfSimpleApplescript'; commit: 'Initial version of configuration'.

#### Release into the Wild

Once we are satisfied that our configuration is correct for all supported platforms (beyond the scope of this post, see the PBE2 draft chapter), we promote our current development version (the one we created a few steps ago) to released status:

MetacelloToolBox releaseDevelopmentVersionIn: ConfigurationOfSimpleApplescript description: '- release version 1.0'. "this will be the commit comment"

#### Sharing

So the community can easily find our configuration, we copy it to http://www.squeaksource.com/MetacelloRepository (note that this location may change in the future as the community is rapidly evolving best practices for Metacello):

MetacelloToolBox copyConfiguration: ConfigurationOfSimpleApplescript to: 'http://www.squeaksource.com/MetacelloRepository'.

#### Conclusion

Metacello solved a great need in the Squeak/Pharo ecosystem, and its tool support is making it easy and fun to use.

Here’s a github gist of the code above that you can customize to create your own configuration. Have fun!

Categories: Tags:

## Smalltalk Simple Image-based Persistence

May 30th, 2011 5 comments

In an enlightening blog post, Ramon Leon explains that most applications are designed for small businesses with small amounts of data. Therefore most applications will never have to scale (i.e. become the next Twitter), so a relational database is overkill. However, persisting by simply saving the image is slow and error-prone.

Based on these ideas, he suggests a simple (one class) framework which saves only your model. The idea is to use it as long as you can get away with, which may be forever.

I packaged the code from the post, added a few tests, and put it on SqueakSource as SimplePersistence.

It’s really easy to give your application persistence (see SPFileDatabase’s class comment). The three steps are:

1. Subclass SPFileDatabase
2. On the class-sode of the subclass, implement
• #repositories – returns a collection of objects to be saved
• #restoreRepositories: – gets passed back the collection.

That’s it! Now, whenever you want to save, call class>>saveRepository or class>>takeSnapshot (background save).

Categories: Tags:
\n