Planet Squeak

blogs about Squeak, Pharo, Croquet and family
planet squeak - planet squeak es - planet squeak jp - planet squeak fr - planet croquet - planet squeak code planet squeak archive --> - planet smalltalk
spacer

spacer (validate)
--> spacer (validate) -->
spacer (validate)
--> Last updated:
February 07, 2013 06:00 PM
All times are UTC.

Sources:
(send updates to simon@joyful.com or the darcs repo)

See also:

Contact:
Simon Michael

Logo by: ?
found on the squeak wiki

Powered by: spacer

February 03, 2013

Pharo News Blog

Slides Fosdem 2013

The slide for this years Fosdem talk is online:

       Pharo - 2.0 Update

PDF, SlideShare

by board (board@pharo-project.org) at February 03, 2013 11:48 AM

February 01, 2013

Sean DeNigris

Metacello: Conditional Loading

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

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:

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!

spacer Tweet This Post

by Sean DeNigris at February 01, 2013 03:02 PM

January 30, 2013

LShift Ltd.

Just In Time Development

Since the dark ages of yesteryear Squeak has had a very interesting button in its Debugger – “create”. Today we’re going to teach it a new trick.

Suppose you write a test, showing how Foo s bar . Your very first test case is simply

FooTest >> testFoosCanBar
    Foo new bar.

You try save the method. Of course, Foo doesn’t exist yet, so Squeak prompts you to define the new class:

spacer

OK, you can now save the method. You run the test. Of course, it fails. So you click on the failing method, and see that you haven’t yet taught a Foo how to bar .

spacer

Ah, there’s a “Create” button. What’s it do? Ah, I see. It asks us which object in Foo ’s hierarchy ought to understand this message. Let’s keep it at Foo for now. OK, and now we see a stub implementation where we can enter our real code.

spacer

So far so good. Now suppose we need Foo to supply a template method for its subclasses to impleement. In C# we’d mark the method as abstract . In Smalltalk we mark the method:

Foo >> templateMethod: anObject
    self subclassResponsibility

Now we need to implement this behaviour in a subclass, Bar . We write a trivial test, run the test, see it fail. If we click on the failing test we see a decent error message…

spacer

… but we have to leave the debugger to fix this. Can’t have that! Alright, let’s see what we can do. First we need to distinguish this kind of error from other kinds of errors:

Error subclass: #SubclassResponsibility
    instanceVariableNames: ''
    classVariableNames: ''
    poolDictionaries: ''
    category: 'Exceptions-Kernel'.

Then we must actually throw the error:

subclassResponsibility
    "This message sets up a framework for the behavior of the class' subclasses.
    Announce that the subclass should have implemented this message."

    SubclassResponsibility
        signal: ('My {1} subclass should have overridden {2}'
            format: {self className. thisContext sender selector}).

Next we need to teach the Debugger how to respond to this special error:

Debugger >> buildNotifierWith: builder label: label message: messageString
    "Snip a whole pile of stuff for brevity's sake"

    "This stanza drives the first bit of JIT coding we saw"
    (self interruptedContext selector == #doesNotUnderstand:) ifTrue: [
        quads := quads copyWith:
            { 'Create'. #createMethod. #magenta. 'create the missing method' }
    ].
    "And now we recognise when we're dealing with an override method."
    (self interruptedContext selector == #subclassResponsibility) ifTrue: [
        quads := quads copyWith:
            { 'Create'. #createOverridingMethod. #magenta. 'create the missing overriding method' }
    "Snip a whole bunch more"

Debugger >> createOverridingMethod
    "Should only be called when this Debugger was created in response to a
    SubclassResponsibility exception. Create a stub for the method that was
    missing and proceed into it."

    | err msg |
    err := self contextStackTop exceptionMessage.
    msg := Message selector: err selector arguments: err calledArguments.
    self implement: msg inClass: err offendingClass inCategory: msg selectorCategory.

Here we see the other side of the comment in Object >> #error: . A ContextPart stores the variables relevant to that frame, and in a parameterless method, the first temp will be the first local variable, containing our exception. And we can simply reuse the (mildly extended) existing mechanisms for creating a stub method.

spacer

Hey, presto! Another reason not to leave the debugger!

by Frank Shearar at January 30, 2013 09:53 PM

January 29, 2013

Torsten Bergmann

Marea: Swapping Objects

A new paper was published on Marea, an object graph swapper for Smalltalk. Read more here or directly go to the PDF.

by Torsten (noreply@blogger.com) at January 29, 2013 12:10 PM

Pharo News Blog

Marea: An Efficient Application-Level Object Graph Swapper

Now available online:

Mariano Martinez Peck, Noury Bouraqadi, Marcus Denker, Stéphane Ducasse, and Luc Fabresse. Marea: An Efficient Application-Level Object Graph Swapper. In Journal of Object Technology 12(1) p. 2:1-30, January 2013. PDF

Abstract
During the execution of object-oriented applications, several millions of objects are created, used and then collected if they are not referenced. Problems appear when objects are unused but cannot be garbage-collected because they are still referenced from other objects. This is an issue because those objects waste primary memory and applications use more primary memory than they actually need. We claim that relying on the operating systemm(OS) virtual memory is not always enough since it cannot take into account the domain and structure of applications. At the same time, applications have no easy way to parametrize nor cooperate with memory management. In this paper, we present Marea, an efficient application-level object graph swapper for object-oriented programming languages. Its main goal is to offer the programmer a novel solution to handle application-level memory. Developers can instruct our system to release primary memory by swapping out unused yet referenced objects to secondary memory. Our approach has been qualitatively and quantitatively validated. Our experiments and benchmarks on real-world applications show that Marea can reduce the memory footprint between 23% and 36%.

by board (board@pharo-project.org) at January 29, 2013 10:04 AM

Torsten Bergmann

pdx.st meeting

There is a Portland Smalltalk User Group meeting happening on Tuesday, January 29, 2013 from 7–9pm

by Torsten (noreply@blogger.com) at January 29, 2013 07:52 AM

January 28, 2013

Sean DeNigris

Smalltalk: Extending the Kernel

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…

spacer

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.

 

 

spacer Tweet This Post

by Sean DeNigris at January 28, 2013 03:54 PM

Torsten Bergmann

Pharo Compiler - Opal

The work on the new compiler ("Opal") is progressing. Read more.

by Torsten (noreply@blogger.com) at January 28, 2013 12:14 PM

Pharo News Blog

Moving to SmalltalkHub

Göran Krampe has published a guide how to move project to SmalltalkHub:

"As a long time Squeak/Pharo (Smalltalk) developer I have accumulated a set of packages that I have written or co-written and that have been published open source for others to use. Since quite a few years SqueakSource has been the natural hosting place, but it has reached the end of the road and it’s high time to move on."  more...

More about...
- Blog Post "Moving to SmalltalkHub"
- SmalltalkHub: smalltalkhub.com
- Göran Krampe: goran.krampe.se

by board (board@pharo-project.org) at January 28, 2013 07:53 AM

January 27, 2013

Torsten Bergmann

ZincSSO and DropBox

It is now also possible to access DropBox from Smalltalk (Pharo) using Zinc.

by Torsten (noreply@blogger.com) at January 27, 2013 03:07 PM

January 26, 2013

The Weekly Squeak

First Slice Of Raspberry π

OK, RISC OS Pi squeak is now available as a tentative demo pre-alpha possibly useful maybe release at www.rowledge.org/tim/squeak/Squeak3-9-RISCOS.zip
If you try it and like it, remember to mentally thank Chris Cunnington for providing the dev-tools and the Pi Foundation for providing the tasty Pi. And offer up wishes for somebody realising that they need to *pay me* to develop stuff.

Apparently Scratch runs on it, though I haven’t tried and wouldn’t really have any current experience to judge it by.

tim

 

lists.squeakfoundation.org/pipermail/squeak-dev/2013-January/167703.html


spacer spacer

by smalltalktelevision at January 26, 2013 03:43 PM

January 25, 2013

Pharo News Blog

Progressing with Pharo: an Interview with Stephane Ducasse

"We start the fresh year 2013 with an interview with Stephane Ducasse from Inria, who started the Pharo Smalltalk project with a bunch of Smalltalkers […]
Aside from the product evolution of Pharo, we cover the new Pharo Consortium and Pharo Association, two organizations that were founded last year"  more...

more about...
- The Interview "Progressing with Pharo"
- Pharo: pharo.org
- Pharo Consortium
- Pharo Association
- Stephane Ducasse

by board (board@pharo-project.org) at January 25, 2013 09:03 AM

January 24, 2013

Torsten Bergmann

Smalltalk and CouchDB

If you want to develop an application with Smalltalk (Pharo) and CouchDB, then continue reading this paper.

It includes a port of the Mustache web template library which is easy to use if you work with JSON. Look here for a syntax example.

Code lives on SS3 and will soon move over to SmalltalkHub (at least the project is there already, still empty).

by Torsten (noreply@blogger.com) at January 24, 2013 05:08 PM

January 23, 2013

Torsten Bergmann

Loom

There is another new tool from ObjectProfile called "Loom - Threads Monitor Tool"which is available for Pharo and VisualWorks.

by Torsten (noreply@blogger.com) at January 23, 2013 02:47 PM

Pharo News Blog

Mocketry 2.1

Mocketry is smalltalk mock object framework based on specifications.

It is available on smalltalkhub www.smalltalkhub.com/#!/~dionisiy/Mocketry .

Changes:

1) All code now migrated to smalltalkhub repository. New
    configuration with version 2.1 implemented accordingly.
2) State specs extracted to separate project "StateSpecs" with
    separate configuration. This project contains all object state
    specifications and validation stuff. Mocketry depends on it
    and only implements behaviour specs and mock objects.
    StateSpecs can be used in different projects. I use it in
    Presenty to describe data fields validness.
3) Main new feature is stub behaviour.
4) Few state specs like
          dictionary should include: item at: #key

by board (board@pharo-project.org) at January 23, 2013 08:09 AM

January 22, 2013

Pharo News Blog

PharoBoids

Martin Walk adopted a Ruby implementation (taken from Exploring Everyday Things with Rand Ruby by Sau Sheong Chang) of Craig Raynolds Boids Simulation in Pharo Smalltalk using Athens Canvas.

Have a look:
smalltalkhub.com/#!/~MartinWalk/Boids

spacer

by board (board@pharo-project.org) at January 22, 2013 07:47 AM

January 21, 2013

Pharo News Blog

Headless support for Cog Cocoa VM

Mariano Martinez Peck has announced headless support for the Cog Cocoa VM, he writes:

"For a long time, Pharaoers and Squakers have been asking for headless support in the Cocoa VMs just as we have with Carbon VMs.
Carbon is becoming a legacy framework so people needed this.
I wanted to take this opportunity to thanks Square [i] International for sponsoring me to implement such a support. Not only have they sponsored the development but they have also agreed to release it under MIT license for the community. This headless support will be included in the official Pharo VM and will be, therefore, accessible to everybody. You can read more details in the ANN email.
So…thanks Square [i] International for letting me work in something so much fun and needed." more..

More about...
- Blog Post: Headless support for Cog Cocoa VM
- Mariano Martinez Peck
- Square [i] International: www.square-i.net

by board (board@pharo-project.org) at January 21, 2013 07:29 PM

January 20, 2013

Gilad Bracha

Inheriting Class


I wanted to share a nice example of class hierarchy inheritance. Regular readers of this blog are no doubt familiar with the notion of virtual classes and class hierarchy inheritance. For those who aren’t, I’ll recap. Class hierarchy inheritance is exactly what it sounds like: the ability to inherit from an entire class hierarchy rather than a single class.   

Nested classes, as originally conceived in Beta, were treated as dynamically bound properties of instances, just like methods. If you do that, overriding classes (aka virtual classes) is an automatic consequence of nested classes.  If you miss this crucial point, you can easily end up with nested-classes design that has a great deal of complexity and almost no benefits (cf. Java).

The notion of class hierarchy inheritance has been around for many years, but has not yet caught on in the mainstream.  It is supported in a few languages: Beta, gBeta, Newspeak and several research projects.

Tangent:  Apologies to any languages I’ve not explicitly mentioned. This is a blog, not a scientific paper, and exhaustive citations should not be expected.

The research on this topic has too often been focused on typechecking, under the rubric of family polymorphism.  Fortunately, one can make excellent use of class hierarchy inheritance without worrying about complicated type systems.

Note:  Virtual classes are distinct from virtual types.

To be honest, while class nesting has proven to be useful on a daily basis, class hierarchy inheritance occurs pretty rarely. The biggest advantage of late binding nested classes is not class hierarchy inheritance, but polymorphism over classes (acting as instance factories, ergo constructors), which promotes modularity.   

Nevertheless, class hierarchy inheritance can be very useful at times. And since it comes for free, we might as well use it.

A classic example in the research literature is extending a class Graph that has nested classes like  Node and Edge. In Newspeak this would look roughly like this:
class Graph () (
   class Node ...
   class Edge ...
)

One can introduce a new subclass of GraphWeightedGraph, modifying Edge to hold the weight etc.

class WeightedGraph = Graph ()(
   class Edge = super Edge ( | weight ::= 0. | ) ()
)

In WeightedGraph, the class Edge inherits from the class Edge in the superclass GraphWeightedGraph
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.