(validate)
-->
(validate) -->
(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:
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
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.
This is the method to use for Monticello packages
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. |
#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. |
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' ] ]. |
This is the method to use for changesets or .st files
For example:
spec for: #'common' do: [ spec blessing: #'baseline'. spec preLoadDoIt: #preLoad. ... |
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. ]. |
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!
Tweet This Post
by Sean DeNigris at February 01, 2013 03:02 PM
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:
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
.
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.
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…
… 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.
Hey, presto! Another reason not to leave the debugger!
by Frank Shearar at January 30, 2013 09:53 PM
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
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
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
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. |
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.
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.
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.
Tweet This Post
by Sean DeNigris at January 28, 2013 03:54 PM
The work on the new compiler ("Opal") is progressing. Read more.
by Torsten (noreply@blogger.com) at January 28, 2013 12:14 PM
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
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
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
by smalltalktelevision at January 26, 2013 03:43 PM
"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
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
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
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
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
by board (board@pharo-project.org) at January 22, 2013 07:47 AM
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