Archive for the ‘Squeak’ Category

Metacello: Conditional Loading

February 1st, 2013 No comments


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.


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).

	| 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: '' ].
	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

1. Add a #preLoadDoIt: to your baseline

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:

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


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.


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

Hope it helps!

Categories: Pharo, Squeak 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

    createBaseline: '1.0-baseline'
    for: 'SimpleApplescript' "Project name"
    repository: ''
    requiredProjects: #('OSProcess')
    packages: #('CommandShell-Piping' 'SimpleApplescript')
    repositories: #()
    dependencies: {
        ('SimpleApplescript' -> #('CommandShell-Piping')).
        ('CommandShell-Piping' -> #('OSProcess')) }
    groups: { ('default' -> #('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
    <version: '1.0-baseline'>
    spec for: #'common' do: [
        spec blessing: #'baseline'.
        spec repository: ''.
        spec project: 'OSProcess' with: [
                className: 'ConfigurationOfOSProcess';
                versionString: #'stable';
                repository: '' ].
            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: [
        repository: ''; "added manually"
        requires: #('OSProcess' ). ];

Version Snapshot

    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
    <version: '1.0' imports: #('1.0-baseline' )>
    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'.
            package: 'CommandShell-Piping' with: 'CommandShell-Piping-dtl.10';
            package: 'SimpleApplescript' with: 'SimpleApplescript-SeanDeNigris.1'. ].


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: '';
    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:

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


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

    copyConfiguration: ConfigurationOfSimpleApplescript
    to: ''.


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: Pharo, Smalltalk, Squeak Tags:

Objective-C in Smalltalk

May 2nd, 2011 6 comments

I’ve been playing with an Objective-C Bridge in Squeak and Pharo. Now I can do cool Cocoa things in-image! For example, sometimes I need a Mac app’s bundle identifier. I previously used a Ruby script. There are a few options, but the easiest is MacRuby:

p NSBundle.bundleWithPath('/Applications/').bundleIdentifier

Now, I can do it in Smalltalk, although it’s a little wordy:

bundle := ObjectiveCObject findClassName: 'NSBundle'.
aBundle := bundle bundleWithPath: '/Applications/' asNSStringUTF8.

There were two things annoying me about the above code:

  1. Object create – wow, a lot more complicated than MacRuby!
  2. #asNSStringUTF8 – I was certain that this could be done automatically by the bridge, and in fact, the above code has a memory leak, because the NSString must be released.

The first one, I did something about. I wrote a simple little class called ObjC to use like a namespace for ObjC classes. The above Smalltalk code becomes:

ObjC NSBundle bundleWithPath: '/Applications/' asNSStringUTF8.

Okay, we’re getting better… Currently not a part of the bridge, the changeset for the class is available here. I’m still working on the NSString issue, so standby…

Categories: Mac, Pharo, Smalltalk, Squeak Tags:

Digging Cool Code out of Sophie

December 13th, 2010 2 comments

OpenSophie (“software for writing and reading rich media documents in a networked environment”) did a lot of great stuff that never made it back to Squeak Smalltalk (on which it was built). I just ported mp3 playing to current Squeak/Pharo, and there are many more treasures to be unearthed.

Here’s how to get started:

  1. Download the last Squeak-based version here
  2. Start the image either:
    1. With a current Squeak VM passing it this changeset, which unlocks it for development (select to file in entire file from the menu that pops up).  On the mac, you can do it like this from Terminal (n.b. Squeak VM Opt is inside the VM bundle):
      "path/to/Squeak VM Opt" /path/to/ /path/to/
    2. By launching the Sophie one-click app
      1. Bring up a user interrupt (Cmd-. on the Mac)
      2. Click the “Debug” button
      3. In the debugger, DoIt the following:
        1. (World findA: SophieRootMorph) delete.
        2. Transcript open.
        3. SophieApplication open.

You will find yourself in a Squeak image with an OpenSophie application running in a SystemWindow.

If you rescue any code, share it with the community! And if you make sure to cut and paste the OpenSophie license into it (e.g. in a class comment), it seems you’re in the clear*.

* not legal advice. I’m not a lawyer.

UPDATE: To start exploring a book programmatically, evaluate:

SophieApplication singleton activeBook
Categories: Pharo, Smalltalk, Squeak Tags:

Playing mp3s in Squeak Smalltalk

December 13th, 2010 No comments

Squeak’s VM has an mp3 plugin, but there doesn’t seem to be any access from the image. So I dug into OpenSophie (version 1 of which was based on Squeak) and yanked out some code.

You can now play mp3 files in Squeak and Pharo!


  1. Just load the SophiePort package from
  2. Then try:
    song := StreamingMP3Sound onFileNamed: '/path/to/yourFavorite.mp3'.
    song play.
    "song pause."


  • It works in Squeak 4.1 and Pharo 1.1.1 on Mac OS 10.6.5
  • I am unclear about the license – Sophie has one license, the code itself seems to be SqueakL. Do your own investigation.
  • There were checks like the following that had to be removed for Pharo 1.1.1: “WeakArray isFinalizationSupported ifFalse:[^anObject]“. I’m not sure of the implications of removing them
Categories: Pharo, Smalltalk, Squeak Tags:

Debugger Driven Development

December 4th, 2010 4 comments

An amazing feature of Smalltalk is that you can create methods right from the debugger.  This fits nicely with “write the code you wish you had.”

  • First, you write a test calling whatever methods you want (even if they don’t exist)
  • When you run the test, a debugger pops up with a create button

  • Like magic, with a push of that button, a method skeleton appears in which you fill the implementation

Field Report

Now this is where things get creepy…  It’s after midnight, and I just want to finish one last thing.  You see, I’ve been implementing a very basic Cucumber-like framework for acceptance tests in Squeak, and there’s just one thing left to do.  I’ve got helper methods that turn given/then/when descriptions into methods that define the steps, like this:

As you can see, #given: transforms the description string into a camel case method name.

All I had left to do was handle the case where the method didn’t exist yet.  In cucumber, templates are passed to the command line to be pasted into the step definition file.  Oh, I’ve got it, the transcript is like command line output, I’ll paste it there!  Let me just see what this debugger is about…

When I took a closer look, I started laughing and couldn’t stop…

Smalltalk handed me a magic Cucumber-step-definition-template-generator!  I checked one more item on my todo list and clicked the magic button.

String-pasting Adventure in Squeak Smalltalk

November 29th, 2010 2 comments

Pasting a string into Squeak is just like pasting a string anywhere else… unless it has quotes in it… or is really long. Then, you’re screwed… but only in a this-is-Smalltalk-and-I’ll-be-able-to-wiggle-my-way-out-in-a-few-moments sort of way.

UPDATE: check the comments after this post for two quicker methods.

In the case of quotation marks in the string, Squeak thinks that the string ends at the first one, because they are not doubled:

In this trivial example, we could just put in the extra two quotes, but if the string was longer, a simple solution is to paste the text into a TextMorph and get its contents:

You can see that the quotes around template.NamlServlet have been doubled.

Long strings

However, if you try to do this with a very long string (like an HTML page source), when you ask for the contents, it will be prematurely cut off (note ‘…etc…’ below):

What’s going on here?  Well, if we browse Object’s ‘printing’ protocol (our hint to look in Object is that all objects can be printed in the tools), we find that printString actually calls printStringLimitedTo:

But fear not, the the method comment refers us to the perfectly named Object>>fullPrintString, which does just the right thing.  You can even copy the correctly-escaped string right onto the clipboard:

n.b. if you ‘PrintIt’ the above statement, you will still get a truncated string, because the system will call regular printString on the result of fullPrintString.

Categories: Smalltalk, Squeak Tags:

Squeak Smalltalk: Error recovery in a live open system

November 24th, 2010 3 comments

Vestigial Panic

Photo by star5112@flickr

I accidentally changed the subclass of a morph that was open in the world – oops.  My screen began filling with dozens of error windows.  Right around this time, I started thinking about quitting and rebooting.  And then I remembered… this isn’t Windows!  I can recover from this – and probably quickly.  So I brought up halos on the hosed morph, clicked the delete halo, pressed the user-interrupt shortcut (Cmd-. on Mac) and went for a glass of water – okay, it was wine – stop judging.

Room to Breath

When I got back, I had a debugger open on the event loop, so I knew that the pain had stopped getting worse.  Now I just had to figure out what to do about all those error windows.

Photo by mliu92@flickr

Like a trained seal, my first move was to press the close button on each one.  This got old after the first two, and I remembered I was using Smalltalk.

Brief Digression

After years of being institutionalized by Windows… and Mac (yes fanboys, it’s only slightly better than Windows, and can’t begin to touch what Engelbart and Kay were doing in the 1960′s and 1970′s), I constantly forget that I’m working in a live, open system, and do idiotic, inefficient things like hitting the close button on 50 error windows.  Like the movie Momento, where he wakes up every day and doesn’t remember who he is or what he’s supposed to be doing…

Smalltalk Nirvana

Back to my senses, I took 10 seconds to write a snippet that closed all the windows:

errorWindows := (World submorphs select: [ :m |
  (m respondsTo: #label) and:
    [ m label beginsWith: 'NonBooleanReceiver' ] ]).
errorWindows do: [ :e | e delete ]

And I was back in action.  Of course, this particular example probably only saved me 10 minutes, but multiply that by X times a day for a year and you get a glimpse of the power of Squeak Smalltalk – a live, open, beautiful system.

Categories: Mac, Smalltalk, Squeak Tags:

Unlocking Squeak Etoys

October 1st, 2010 No comments

I always forget how to turn on the developer tools in Etoys.  It is a simple preference set, but the name escapes me, so I’m writing it down.

  1. Bring up the halos on the world and select the ‘Menu’ halo
  2. Choose Preferences
  3. Under ‘scripting’, disable the ‘eToyFriendly’ Preference:

And you have full access to the developer tools…

Categories: Etoys Tags:

Squeak/Pharo Presentation in NYC

September 20th, 2010 No comments

I’ll be giving a talk about Squeak and Pharo for the NYC Smalltalk group.  Details are at

Here is the abstract…

If you enjoy frequent (and long) personal breaks while waiting for your code to compile, stop reading now.  If tears of pride well up every time you behold the library of books you steamed through to learn C++, don’t come to this presentation.  We’ll be talking about Squeak & Pharo – active, open source, production-quality Smalltalk, and what makes it the baddest language on the block… 30 years later!  You may never have the heart to open your Java IDE again – here’s why:
* Productivity – 2.5 times more productive than Java or C++, with less errors
* Easy to learn – sending messages to objects is theonly concept
* Fun – write only code that matters, just the way you want; make any part of the system work how you say it should

UPDATE: Most of the magic happened in the group conversation itself, but here is the slideshow that nudged us along

Categories: Pharo, Smalltalk, Squeak Tags:

windows 7 product key

windows 7 product key

windows 7 key generator

windows 7 key generator

free winrar download

free winrar download

winzip activation code

winzip activation code

free winrar

free winrar

winzip free download

winzip free download

winrar free download

winrar free download

winrar download free

winrar download free

winzip free download full version

winzip free download full version

windows 7 activation crack

windows7 activation crack

windows 7 crack

windows 7 crack

free winzip

free winzip