Planet Smalltalk

September 02, 2014

Joachim Tuchel - Beautiful little tutorial on how to build a complete Seaside Application with an RDB Backend

Sven just announced the availability of a new tutorial named “ — In 10 Cool Pharo Classes“. I am fascinated by how short and clear this piece is. It really explains all you need to know to get started building a Seaside Application using Glorp and Postgres as a database. It is nice to read and really […]

Pharo Weekly - Another week of improvements in PharoLand

13941 [FEATURE]: Configuration Browser: Switch to Any Repository

13938 Opal, custom compilers and class side methods

13897 check for argument assignments (block and method argumentts)

13413 Support string operations in AsmJit

13926 Assign to args in RBRefactoryTestDataApp>>#demoRenameMethod:PermuteArgs:

13153 Comment of FreeTypeProvider refers to FileDirectory and it should not

13726 Forward port Pharo4: 13725 NativeBoost crashes when reading null pointer field in a structure

13390 Support NB options with non-boolean values

13911 Metacello test packages not properly unload

13721 Failing test: RBRenameMethodTes>>#testRenameTestMethod1

13631 Deprecate method refactoring

13916 RBLiteralArrayNode uses #to:do: instead of #with:do: (Coding Idiom Violation)

13918 RBMessageNode uses #to:do: instead of #with:do: (Coding Idiom Violation)

13885 Integration report is not showing the changes integrated

13566 should remove this kind of isKindOf:

13865 Cleaning menuMorph

13902 inconsistent behaviour when debugging Pharo3.0

13858 Backport 3.0 case 13857

13910 Add return to Magnitude>>compareWith:ifLesser:ifEqual:ifGreater:

13880 store into method argument: can not recompile standardizeDevVersionString:

13881 Refactoring to PSMCPatchMorph to allow dispatching

13908 RBPragmaNode uses #to:do: instead of #with:do: (Coding Idiom Violation)

13906 Move to class refactoring gives DNU

13909 Instance variable previous in RBProgramNodeTest is not referenced

13894 Class side initialize methods should be runnable in Nautilus

13907 RBSequenceNode uses #to:do: instead of #with:do: (Coding Idiom Violation)

Pharo News - — In 10 Cool Pharo Classes

<p>&quot;This is a tutorial showing how to implement a small but non-trivial web application in Pharo using Seaside, Glorp (an ORM) and PostgreSQL.</p> <p>Reddit is a web application where users can post interesting links that get voted up or down. The idea is that the ‘best’ links automatically end up with the most points. Many other websites exist in the area of social bookmarking, like Delicious, Digg and Hacker News.</p> <p> adds persistency in a relational database, unit tests as well as web application components to the mix.&quot;</p> <p><a href="">Read more...</a></p>

Pharo News - — In 10 Cool Pharo Classes

<p>&quot;This is a tutorial showing how to implement a small but non-trivial web application in Pharo using Seaside, Glorp (an ORM) and PostgreSQL.</p> <p>Reddit is a web application where users can post interesting links that get voted up or down. The idea is that the ‘best’ links automatically end up with the most points. Many other websites exist in the area of social bookmarking, like Delicious, Digg and Hacker News.</p> <p> adds persistency in a relational database, unit tests as well as web application components to the mix.&quot;</p> <p><a href="">Read more...</a></p>

Torsten Bergmann - — In 10 Cool Pharo Classes

Another nice article published by Sven on how to use Pharo, the Seaside web framework and the Glorp ORM together with Postgres DB to create a version.

Read more here.

Essence# - Essence# Syntax: Self Expressions

A self expression is essentially a (possibly cascaded) message sent to self, except that the pseudo-variable “self” is omitted. The value of the “invisible self” that receives the message is established by configuring the compiler to set the pseudo-variable self to the desired value during execution of the self expression.

A self expression is allowed just one message chain having just one message receiver–and the receiver must not be specified syntactically.

Conceptually, the syntactically unspecified–and therefore implied–receiver of the message(s) in the message chain of a self expression is the pseudo-variable self. That’s because the same compiler infrastructure used to set the pseudo-variable self to the correct value during the execution of a method or block is also used to set the value of the implied, unspecified receiver of the message(s) in the message chain of a self expression, and also because a self expression is parsed by the parser simply by adding an actual parse node for the pseudo-variable self as the receiver of the message(s) in the message chain of the self expression. That’s possible because the parser implements self expressions as their own “root parse node” or “grammatical start symbol.”

Any syntactically-valid expression which sends a message to an operand can be converted into a self expression simply be removing whatever syntactical construct is the receiver of the message (a.k.a, the leftmost operand in an expression.) The following examples show two pairs of expressions, where the first member of the pair uses self expression syntax and the second one does not:

Configuring a class

"Using 'self expression' syntax:"

        superclass: Object; 
        instanceVariableNames: #(red green blue)


"Using 'expression' syntax:"

                superclass: Object; 
                instanceVariableNames: #(red green blue)


Adding methods to a class (using method literals to define the method):

"Using 'self expression' syntax:"

        protocol: #accessing 
                [## red


"Using 'expression' syntax:"

                protocol: #accessing 
                        [## red


Prior Art

The inspiration for self expressions comes from Tirade, a data representation language invented by Göran Krampe. The main reason that Essence# uses self expressions instead of Tirade is simply because, once you have a full parser/compiler, it is significantly simpler to implement self expressions than to implement Tirade. Given a full compiler, implementing self expressions only involves adding a few, relatively small methods to the parser and compiler. And it also technically doesn’t require adding new syntax to the language, since self expressions only use syntactical forms that would have to exist in any case; the only innovation is to permit simpler syntax that omits an otherwise-required syntactical construct. So self expressions were “the simplest thing that could possibly work.”

That said, Tirade would be a much superior solution to the problem of programming-language neutral data interchange. But that’s not the problem that self expressions are intended to solve.

Smalltalk Jobs - Smalltalk Jobs – 8/1/14

Good luck with your job hunting,
James T. Savidge

View James T. Savidge's profile on LinkedIn

This blog’s RSS Feed

Filed under: Employment

August 31, 2014

Andres Valloud - Exceptions fixed in Squeak, Pharo and Cuis

Martin McClure just integrated the Pharo exceptions fix we worked on during Camp Smalltalk.  I imagine this fix, in 5 slices, should be straightforward to port to Squeak and Cuis.

Update: I ported the Pharo fix to Cuis.

August 30, 2014

Pharo Weekly - Flickr API Wrapper

Sean started a little wrapper. It does a few basic things. Enjoy!

Gofer it
	smalltalkhubUser: 'SeanDeNigris' project: 'Flickr';

"Global setup"
	userID: myUserID;
	apiKey: myApiKey.

"Generic usage"	
Flickr new
	set: 'photo_id' to: '4975793876';
	get: ''.

"Smalltalk model"	
(FlickrUser named: 'Rebel Shea') id.

"This won''t work because we need to exclude our user_id... not sure how to
(FlickrUser fromUrl: ''
asUrl) id.

August 29, 2014

Bert Freudenberg - Deconstructing Floats: frexp() and ldexp() in JavaScript

While working on my SqueakJS VM, it became necessary to deconstruct floating point numbers into their mantissa and exponent parts, and assembling them again. Peeking into the C sources of the regular VM, I saw they use the frexp() and ldexp() functions found in the standard C math library.

Unfortunately, JavaScript does not provide these two functions. But surely there must have been someone who needed these before me, right? Sure enough, a Google search came up with a few implementations. However, an hour later I was convinced none of them actually are fully equivalent to the C functions. They were imprecise, that is, deconstructing a float using frexp() and reconstructing it with ldexp() did not result in the original value. But that is the basic use case: for all float values, if
[mantissa, exponent] = frexp(value)
value = ldexp(mantissa, exponent)
even if the value is subnormal. None of the implementations (even the complex ones) really worked.

I had to implement it myself, and here is my implementation (also as JSFiddle):
function frexp(value) {
    if (value === 0) return [value, 0];
    var data = new DataView(new ArrayBuffer(8));
    data.setFloat64(0, value);
    var bits = (data.getUint32(0) >>> 20) & 0x7FF;
    if (bits === 0) {
        data.setFloat64(0, value * Math.pow(2, 64));
        bits = ((data.getUint32(0) >>> 20) & 0x7FF) - 64;
    var exponent = bits - 1022,
        mantissa = ldexp(value, -exponent);
    return [mantissa, exponent];

function ldexp(mantissa, exponent) {
    return exponent <= 1023 ?
        mantissa * Math.pow(2, exponent) :
        mantissa * Math.pow(2, 1023) * Math.pow(2, exponent - 1023);
My frexp() uses a DataView to extract the exponent bits of the IEEE-754 float representation. If those bits are 0 then it is a subnormal. In that case I normalize it by multiplying with 264, getting the bits again, and subtracting 64. After applying the bias, the exponent is ready, and used to get the mantissa by canceling out the exponent from the original value.

My ldexp() is pretty straight-forward, except it needs to be able to multiply by very large numbers. The smallest positive float is 0.5-1073, and to get its mantissa we need to to multiply with 21073. That is larger then the largest float 21023. By multiplying in two steps we can deal with that.

So there you have it. Hope it's useful to someone. And here is the version I put into SqueakJS, if you're curious.

Nicolas Petton - Reusing previous git commit messages with Magit

One thing though bothered me for some days after I discovered the use of M-p M-n in the git commit buffer to reuse previous git commit messages: I couldn’t figure out how it worked. Magit seems to save some commit messages (when you cancel a commit for example) but not all of them. That was until I found out that I could easily run git-commit-save-message for each commit:

(add-to-list 'git-commit-mode-hook 'git-commit-save-message)

But wait, there’s an even better solution: M-x customize-variable RET git-commit-mode-hook RET.

Yep, there’s already an option for that to be customized. Magit truly is awesome!


Noury Bouraqadi - Manually build an environment map in MORSE

To check the accuracy of the exploration map, we need to compare with a pre-built one. Of course, the latter needs to have a good accuracy. We provide here a tool to manually build an environment map in MORSE. This tool has the following features: Map building using gmapping ROS package. Robot with perfect odometry.… Continue reading

Nicolas Petton - Using a dark window decoration for Emacs in Gnome

Gnome 3’s default theme Adwaita has support for both light and dark window decorations. Many media apps like Totem use the dark theme. It puts the focus on the content and it’s easier on the eyes.

Emacs with a dark theme and the large white-ish window decoration isn’t really a fit on my desktop, but that can be easily fixed using a bit of elisp with xprop!

(defun set-selected-frame-dark ()
    (let ((frame-name (get-frame-name (selected-frame))))
    (call-process-shell-command (concat "xprop -f _GTK_THEME_VARIANT 8u -set _GTK_THEME_VARIANT \"dark\" -name \""

    (if (window-system)

Here’s a screenshot of both versions:

emacs-light.png emacs-dark.png


August 28, 2014

The Weekly Squeak - Pyonkee (Scratch on iPad)


From Masashi-san:

Hi all,


I have just released a Scratch clone running on iPad. It is based on Scratch 1.4 from the MIT Media Laboratory.

The app is now called “Pyonkee” – freely available on App Store.


Pyonkee was originally started as a fork of John M McIntosh’s Scratch Viewer.


While Scratch Viewer just works as a viewer of the existing Scratch projects, Pyonkee supports creation/edit of projects.


Other features:

- User interfaces are optimized for iPad

- Native font support

- Embedded camera support

- IME support

- Auto-saving project

- Sending projects via e-mail

- Project import/export through iTunes (currently disabled)


Moreover, source code is open on github. Feel free to fork it.



[:masashi | ^umezawa]

Noury Bouraqadi - Robulab’s first lesson of LRP through PhaROS

The objective of this tutorial is to be able to create a behaviour for the Robulab described using Live Robot Programming. The LRP program transparently uses PhaROS to communicate with the Robulab. Let’s do it step by step Follow the instructions to have Robulab working specified in this tutorial. Open the image you created on… Continue reading

German Arduino - Scriptcase hosting

Hace poco anunciamos el lanzamiento de un nuevo servicio y ahora lanzamos el sitio web dedicado a la comercialización y soporte del mismo.

Esta es una primera versión y paulatinamente iremos incorporando más funcionalidades y planes.

Joachim Tuchel - How to see who tried logging into your Ubuntu machine

Putting a piece of software onto a publicly reachable machine on the open (bad, dangerous, dirty and unbelievably complex) web presents you with all kinds of neat problems. One of them is that as soon as you have a public address, a certain kind of people will sure try to knock on your door, push […]

Torsten Bergmann - KelticKnots with Pharo

August 27, 2014

German Arduino - Representamos Scriptcase en México

A partir de este mes de Agosto comenzamos a trabajar como representantes de Scriptcase en México.

Más información aquí.

Essence# - Essence# Syntax: Method Declarations

method declaration is the syntactical construct used to define a method, including its name and its logic. In Essence#, the name of a method is typically referred to as its method selector; or even just its selector.

The EBNF for a method declaration:

MethodDeclaration   = [MethodHeaderToken, [ClassSpecification]], 
MethodHeader, ExecutableCode;
MethodHeaderToken   = OptionalWhitespace, "##", OptionalWhitespace;
MethodHeader   = UnaryMethodHeader | 
                               BinaryMethodHeader | 
UnaryMethodHeader   = UnaryMessageSelector;
BinaryMethodHeader  = BinaryMessageSelector, OptionalWhiteSpace, BindableIdentifier;
KeywordMethodHeader = KeywordMethodHeaderSegment,
{Whitespace, KeywordMethodHeaderSegment};
ClassSpecification  = QualifiedIdentifier,OptionalWhitespace,">>", OptionalWhitespace;


At the beginning of a method declaration, the parser will recognize “##” (two immediately-adjacent hash characters) as a lexical token called a method header token, and will interpret the token to mean “what follows is a method header.”

Whitespace is permitted, but not required, both preceding and following the method header token

A method header token may optionally appear as the first token of any method declaration; but it is not required if the method declaration is the root of the parse tree.

However, if a method header token occurs as the first (non-whitespace) token following a “[" token, then the parser will have no choice but to interpret what follows as the remaining tokens of a method literal (which must be terminated by a "]” token eventually.) And in that case, the “##” (method header) token may be required:

If the initial token following a “[” (BlockBegin) token is either a binary message selector or a keyword, then the source code enclosed within the “[" and "]” tokens will be parsed as a method declaration even though there is no leading method header token, and the entire construct (including the “[" and "]” tokens) will be interpreted as a method literal, and not as a block literal. So in either of those cases, no method header token is required.

However, if the first token following a “[” token is a unary message selector (which might instead just be a variable name,) and if there is no leading method header token in between the “[” token and the unary message selector, then the parser will not interpret the construct as a method literal, but will instead interpret it as a block. So, when a method declaration occurs as part of a method literal, and said method declaration has a unary method header,  the only way to get the parser to interpret the construct as a method literal, and not as a block, is to use a method header token as a prefix to the unary method header.

Note: The method header token will also be required as a prefix to a binary method header, if the binary selector is the “|” (vertical bar) token. That constraint is required in order to avoid syntactical ambiguity, due to the fact that a vertical bar token may also be the initial token of a variable declaration list.

If and only if a method header is preceded by the “##” (method header) token, the name of the class which is to be used as the environment for binding variable references when compiling the method may be specified preceding the method header. But in that case, the token “>>” must then be used as a separator between the class name and the method header.

Whitespace is permitted but not required in between the class name and the “>>” token, and in between the “>>” token and the method header.

Following the method header there must be an executable code construct. An executable code construct defines the method’s logic.  Colloquially, an executable code construct is referred to as a method body. A method bodyhas the same exact syntactical structure as a block body.

There are three different types of method header: A unary method header, a binary method header and akeyword method header. 

A method declaration with a unary method header must be invoked using a unary message.

A method declaration with a binary method header must be invoked using a binary message.

A method declaration with a keyword method header must be invoked using a keyword message.

Examples of method declarations using all three types of method header are shown below (none of which have a method header token as a prefix):

Method declaration using a unary method header:

| stream |
stream := String new writeStream.
self printOn: stream.
^stream contents


Method declaration using a binary method header:

@ y
^Point x: self y: y


Method declaration using a keyword method header:

displayOn: aGraphicsContext at: aPoint
aGraphicsContext displayString: self at: aPoint


If a method header token (“##”) precedes it, then a class specification construct may optionally precede any of the three types of method header. If present, the class specified by the class specification will be used by the compiler as the behavioral context in which the method will be compiled. In other words, the instance variables defined by the specified class, the class variables defined by the specified class and the global variables imported by the specified class will be used to bind any variables referenced by the method that aren’t either method parameters or local variables.

Here are the same three method declarations constructed to have an optional method header token and class specification construct as a prefix to the method header:

Method declaration using a unary method header and an optional class specification:

## Object>>printString
| stream |
stream := String new writeStream.
self printOn: stream.
^stream contents


Method declaration using a binary method header and an optional class specification:

## Number>> @ y
^Point x: self y: y


Method declaration using a keyword method header and an optional class specification:

## String>>displayOn: aGraphicsContext at: aPoint
aGraphicsContext displayString: self at: aPoint


Any method declaration (whether it uses a unary method header, a binary method header or a keyword method header, and whether or not it uses an optional class specification) may optionally begin with a method header token. The reason the method header token is optional is because its purpose is either to separate one method declaration from another in a sequence of method declarations, or else to distinguish a method literal from ablock. Outside of those two cases, it has no purpose, function or meaning. Its presence or absence has no effect on the semantics of the method.

Here’s an example showing two method declarations separated by an intervening method header token:

^self ticks / TicksPerDay


^self ticks / TicksPerHour

Essence# - Essence# Syntax: Method Literals

A method literal is a method declaration surrounded by enclosing syntax so that it can be embedded as a literal value in an Essence# expression.

The EBNF for method literals:

MethodLiteral       = "[", MethodDeclaration, "]";


A method literal must be enclosed between a single beginning “[" character and a single ending "]” character, making its syntax rather similar to that of a block. The key difference between the syntax of a block and the syntax of a method literal is that the construct that immediately follows the beginning “[” character must be unambiguously a method header. And that, in fact, is one of the reasons that the “##” (method header) tokenexists, and is required in some cases, but optional in others: When the “##” token is required, it’s because its absence would create syntactical ambiguity, such that it would not be possible for the parser to distinguish ablock from a method literal.

For more information on the syntax of a method declaration, please see the article on that topic.

Methods defined in Essence# class libraries declare methods as method literals, instead of as method declarations that are the root of their respective parse trees. Using method literals for that purpose obviates any need to encode method names as filenames; or alternatively, it obviates any need to define a special syntax for dealing with sequences of method declarations, or for syntactically embedding method declarations inside of class declarations. So there’s no need for a special “file in” syntax, nor any need for a special parser that can consume a special “file in format.”.

That said, the ANSI standard does require that a conforming implementation support the Smalltalk Interchange Format. Essence# does not currently support that format, but will do so before it leaves beta.

Using Class Specifications

A method declaration may optionally use a class specification construct–but only if a method header token is also used. That means a method literal may also use a class specification construct, since its syntax is defined as an embedding of a method declaration enclosed in between the tokens “[" and "]“.

The presence or absence of the class specification construct may change the behavior of the compiler:

If there is no class specification in the method header, then whether or not the compiler will attempt to bind non-local variable references depends upon how the compiler is invoked. If the compiler is not provided with a binding context for non-local variables when it’s invoked, and if there is no class specification in the method header to provide one, then the compiler won’t check whether any references to non-local variables might be undeclared (however, that check is always performed whenever a method is added to a class or trait.)

On the other hand, if the method header includes a class specification, then the compiler will always attempt to bind references to non-local variables, using whichever class is specified by the class specification construct as the binding context. In that case, any undeclared variables will be treated as compilation errors.

In other words, the compiler interprets the presence of a class specification construct in a method header as a command to verify that there would be no undeclared variables referenced by the method it’s compiling, if that method were to be added to the specified class. Conversely, it interprets the absence of a class specification as a command to defer any such checks until the method is actually added to a class or trait.

When compiling either self expressions or “do its” (initializers or scripts,) the compiler is not configured to provide any default binding context for method declarations–and therefore is also not configured to do so formethod literals. That’s because there’s no way to know a priori what the “right” binding context might be in such cases.

Since methods are checked for any references to undeclared variables when they are added to a class or to a trait (which is usually the proper time, because that’s when the right binding context is known absolutely,) there are no system integrity issues raised by this binding paradigm. And that’s why the method literals in “methods.instance” and “methods.class” files don’t use class specification constructs in their method headers. There’s no need, really.

However, there are compilation use cases other than compiling “methods.instance” and “methods.class” files. And some of those use cases do require that the compiler bind all variable references during initial compilation–which is why class specification syntax is present as on option for method headers.

August 26, 2014

Nicolas Petton - iSearch thing

Wouldn’t it be awesome if when using iSearch, I could search for the symbol under the cursor, or the active region if any?

Unfortunately, AFAIK iSearch can search for the next word (with C-w), but not the symbol at point or the region contents. This small snippet fixes the problem!

Note: it overrides C-t in isearch-mode, but as I never use it, I do not mind :)

(defun symbol-name-at-point ()
    (let ((symbol (symbol-at-point)))
    (if symbol
    (symbol-name symbol)

    (defun current-thing ()
    "Return the current \"thing\":
    - if the region is active, return the region's text and deactivate the mark
    - else return the symbol at point or the empty string."
    (let ((thing (if (region-active-p)
    (buffer-substring (region-beginning) (region-end))

    (defun isearch-thing ()
    "Search for the current \"thing\":
    - if the region is active, return the region's text and deactivate the mark
    - else return the symbol at point or the empty string."
    (isearch-yank-string (current-thing)))

    (define-key isearch-mode-map (kbd "C-t") #'isearch-thing)


August 25, 2014

Torsten Bergmann - Teapot - another way for Pharo to serve the web

There are various options to write web applications in Pharo. You can use Seaside or Aida web framework or play with the new Tide framework connecting Amber with Pharo.

If you want to quickly write something you can use the plain Zn framework as this nice tutorial from Sven describes.

And now there is something inbetween that allow you to quickly write an application that serves static or dynamic content from Pharo. It is called Teapot and with a few lines of code you can provide JSON to the outside world or other REST based functionality. It also includes support for the Pharo port of Mustache (the templating engine).

The basic concept of Teapot is to define one or many URL Route(s) - either direct or as pattern (for instance with a Regexpression) and return an appropriate response from the Smalltalk side. Simple, lightweight and easy to use.

Torsten Bergmann - Woden - 3D graphics engine for Pharo

Woden is a multi-media graphics engine written in Pharo. This graphic engine is being designed for video-game development and data visualization.

Read more here.

Torsten Bergmann - TaskIt Version 1

The first version of TaskIT - a Task management library for the Pharo Language - is released. Read the announcement.

Also read the chapter for the upcoming Pharo for the Enterprise book.

Pharo Weekly - Teapot: a micro web framework for Pharo


I'd like to announce a new micro web framework called Teapot. It follows a
similar philosophy than other lightweight frameworks like
Sinatra/Bottle/Flask/Spark. Teapot is built on top of the Zn HTTP
components, and less than 500 lines long.

More info:!/~zeroflag/Teapot
Gofer it
  smalltalkhubUser: 'zeroflag' project: 'Teapot';


Yoshiki Ohshima - [仕事] ESUG 2014とロンドン観劇

European Smalltalk Users Group Conference に10年ぶりに参加してきました。フレンドリーで、かつ激しい議論を戦わせるだけでの共通認識があるので、楽しい会議である事には違いないです。新しいVMがぽろぽろ出てきていたり、ベンダーも多数来てプロダクトのアップデートをしたり、学生達が発表したりと活気もあります。 帰り道ロンドンで一晩空きがあったので、Gielgud Theatreでやっていた”The Curious Incident of the Dog in the ...

August 24, 2014

Pharo Weekly - Another weekly iteration: The power of doing at work

13898 RBBlockNode>>#equalTo:withMapping: uses #to:do: instead of #with:do: (Coding Idiom Violation)

13901 move DoubleLinkedListTests, LRUCacheTests and TTLCacheTests from Tests

13896 RBBlockNode>>#= uses #to:do: instead of #with:do: (Coding Idiom Violation)

13900 move TextDiffBuilderTest to ToolsTest

13892 Example methods should be runnable in Nautilus

13899 RBCascadeNode uses #to:do: instead of #with:do: (Coding Idiom Violation)

13895 #hasReportableSlip should call #containsHalt

13271 inconsistent behaviour when debugging

13893 Lint rule for checking block argument assignment.

13878 Better comment in Date(class)>>fromString: and test

13870 Spotlight: small enhancement for resolving symbols

13862 Merge OCompletion into Ecompletion

13877 Clean up Settings related to Code Browsing

13855 Small critique cleanup of Tool-Base

13859 replace two uses of OCKeyedSet with Dictionary

13856 Trivial cleanup in DebuggerModel

13857 temporary fix old Browser to allow access to class organization protocol

13819 Remove Check for Slips Preference

10146 Semantic analysis: TempVars should not have index

10144 Improve Comments Opal

13853 GroupWindowMorph does not use themed background color.

13848 EyePatch for inspectors eye

13820 Move #useAstColoring setting to the Shout settings group

13852 MNU on ChangeSorter fileOut

13526 System Browser Add Class menu item does not offer current class as a superclass

13825 MNU: receiver of protocolsFor: is nil

13835 Small cleanup in System-Changes

13836 Clean up RecentSubmissions more

13834 Small Completion Cleanup

13838 Update Zn+Zdc August 2014

13817 remove setting for showing diffs in change list

13807 nil protocol and unclassified in ValueLink

13805 mustBeBooleanMagicIn: can crash the vm

13773 implement drawOnAthensCanvas on MenuItemMorph and MenuLineMorph

13754 cleaning strings API

13815 Finder: remove non-needed preference

13826 Extended search… fooled by block arguments

13789 AthensWrapMorph can not paint gradient fill

13806 Remove ThreadSafeTranscriptPluggableTextMorph

13787 Implement SequenceableCollection >> reverseWithIndexDo:

13526 System Browser Add Class menu item doesn t offer current class as a superclass

13814 DiffMethodReferenceConverter not needed

13816 Unify default method templates + Shout critique clean

13813 Nautilus Refactoring 7: rename methods

13821 Concentrate tools shortcuts in a single class

13097 Keymapping: Cmd-n Cmd-c gives error message

13027 KeyCombination pretty printing is broken

13801 BlockClosureTest failing

13799 Forward port 4: 13796 DNU ReadWriteStream>>fileIn in SmalltalkEditor>>fileItIn

13804 #acceptBasic leads to #mustBeBoolean error (which is catcher by an on: Error do:[]]

13803 Inspecting a Dictionary is broken

13802 failing test: testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits

13795 Browsing certain classes takes several seconds

13800 another small SystemNavigation cleanup

13798 empty package UI can be deleted

13639 RealEstateAgent

13797 RecentMessages: remove useAsSet Preference

13775 Move two methods from SystemNavigation to AbstractTool

11709 remove old ObjectExplorer

13770 Restore Menu Item to Add accessors for anInstVar

13771 User Permission cannot be read from User

13794 Make Tools-Explorer unloadable

13793 Enable new Pointer Explorer

13764 Simplify RecentSubmissions

13774 EyePointerExplorer

13792 remove #callers

13784 Color>>#asColorref ignores blue

13777 remove empty package Settings-Monticello

13780 Wrong compilation context in mustBeBooleanInMagic:

13762 OCInstanceVariable not needed

13788 Unused method in StringMorph

13776 EyeSyntaxTreeInspector

13759 Small Code critique pass over 3 tools packages

13760 Continue remvoving RGFactory

13763 SyntaxErrorNotification: errorMessage ivar not needed

13782 add preference the DEBUG menu entires of Nautilus

13767 packagetree changes visible selection even if okToChange is false

13778 Workspace: fix non-declared temp vars

13781 class Refactor not needed

13752 4 tests failing on main build due to the decompiler

13766 DictionaryValueHolder>>#at:ifAbsentPut: always use a caught DNU

13768 EyeInspector BasicIndexedEyeElement hash is too slow

Pharo Weekly - SXSoundEx for Pharo

Hi all

As part of a recent project I was asked to create a small soundex thingy.

I told the company that I’d do it but it’d be opensource and I’d give it to the community.
They agreed so here it is!
You can find it here!/~riverdusty/SXSoundEx
Hope it’ll be useful for someone.


Gareth Cox
IT Manager/Developer
Inspired Org (PTY) Ltd
tell: +27 (0)21 531 5404
cell: +27 (0)78 374 9035

August 23, 2014

Andres Valloud - While at the Seaside Sprint...

Philippe Marschall had an interesting problem to think about... suppose you have a dictionary with string keys, and that you make sure the keys are uppercase.  Alas, when the code receives queries, it gets lowercase keys.  Fixing this requires sending asUppercase, which takes time.  Can you find a way such that both at: and at:put: can be made to work without sending asUppercase?  Can you do it without creating new classes?

I got a proof of concept to run 2x faster.  From what I hear, the improved code will help speed up HTTP requests.