Planet Smalltalk

October 24, 2014

Nicolas Petton - Watching file changes with buffer-watcher.el

October 24, 2014

buffer-watcher.el makes it easy to evaluate shell commands each time a buffer is saved in Emacs.

You can specify a mode and base path for which a specific script should be evaluated, and each time you save a buffer that matches the criteria, the hook will be run.

Here’s an example that runs lessc each time a less file is saved in the project proj:

(require 'buffer-watcher)
    (add-to-list 'buffer-watcher-commands '("Lessc hook" less-css-mode "~/projects/proj/" "lessc % > style.css"))

The command will be run from within the same folder as the save file, and % is expanded to the buffer’s file name.

If you’re into customize, you can M-x customize-group RET buffer-watcher to add your commands.


You can grab buffer-watcher from my emacs settings on GitHub.


Pharo Weekly - Continuous improvement at work…

14290 Menu translation should be the responsibility of menus (part 1)

14297 Kernel fixes for Spur

14302 Replace Announcer>>#on:send:to:s senders in NewValueHolder

14291 browse open a class side browser

14289 MNU in Finder>>computeWithMethodFinder:

14298 pre for 14297 Kernel fixes for Spur

14068 Should add spyFor: to systemProfiler

14296 Replace Announcer>>#on:send:to:s senders in NautilusCommon

14286 add a test for #sourceNode on Contexts for optimized blocks

14283 Slice for Spur integration

14284 fix #sourceNode for Blocks

14282 add SourceNode tab for IRInstruction and SymbolicBytecode

14276 Add UDPSocketEchoTest test/example

14222 Tests around KeyChain

14281 Replace Announcer>>#on:send:to:s senders in Nautilus

14241 add a inspector view for IRMethods

14254 AST method replaceWith: does not change source interval

14235 IRInterpreter should be replaced by IRVisitor

14272 #_foo: isBinary —> true

14221 Tests around Graphics

14271 RBCodeCruftLeftInMethodsRule>>initialize and RBAllAnyNoneSatisfyRule>>name have spelling errors

14269 Komitter: Improve layout for long repo names

14242 Installing a method is slow

14257 Replace Announcer>>#on:send:to:s senders in NativeBoost-Core

14240 evaluating nil and: [true] gives an infinite loop

14264 World Menu > Help > Pharo Zen DNU

14263 fix “search all source”

14262 small speedup of CompiledMethod>>#endPC

14270 Workaround: speed up code critique by not checking send messages for now

14228 critic rules running on all methods of a class extended by a package

14246 CompiledMethod>>hash can produce clashes

14257 Replace Announcer>>#on:send:to:s senders in NativeBoost-Core

14253 MC dependency warning should name which package is failing to load

14251 Add a scope browser: shows tree of scopes, corresponding source

14243 tiny refactoring in #compile:classified:withStamp:notifying:logSource:

14231 add “inspect method” to method menu in browser and everywhere

14218 Opal should be able to compile methods for SqueakV3PlusClosure and Spur

14177 Add properties to classes

14215 Fix for (Behavior new) compile:

14237 SymbolicBytecodeBuilder: rename #print to #addBytecode:

14239 add inspector view for byte code with source highlighting

13535 Class code wrongly styled in critic browser

14236 add #sourceInterval and #sourceNode to SymbolicBytecode

14238 Replace Announcer>>#on:send:to:s senders in NECompletion

14218 Opal should be able to compile methods for SqueakV3PlusClosure and Spur

14232 remove ByteCodeMethodConverter

14225 implement #symbolic by printing the SymbolicBytecode….

13318 no (strong) visual feedback for bytecode view while looking at a class definition

14217 GTTools version 1.0.7

14229 Replace Announcer>>#on:send:to:s senders in MonticelloGUI

14226 smallLintCritics optimisation is slow

14227 Replace Announcer>>#on:send:to:s senders in Monticello-Tests

13457 The Implementors of browser adds all methods added to its list

14204 OCStoreIntoReadOnlyVariableError: VersionnerProjectPanel>>#initializeGroupsWidget:

14224 add #symbolicBytecodes to CompiledMethod and clean up InstructionPrinter a little

14208 Move ByteArray close to WordArray, delete package Collection-Arrayed

14213 Replace Announcer>>#on:send:to:s senders in Monticello

14098 allClassesAndTraits significantly different from allClassesAndTraitsDo:

10288 Add a lint rule to check that class initialize method does not calls super initialize

14210 Replace Announcer>>#on:send:to:s senders in Komitter

14197 Little Morphic Package Reorganization

14198 Time>>print24 prints nanos, though it claims not to

14211 Replace Announcer>>#on:send:to:s senders in Manifest-CriticBrowser

14096 Rewrite lint rules to check classes and methods

6512 Traits should not use compiler

14203 OCStoreIntoReadOnlyVariableError: RecentMessageList>>#lastClasses

October 21, 2014

Cincom Smalltalk - Smalltalk Digest: October Edition

The October edition of The Cincom Smalltalk Digest is available now.

Cincom Smalltalk - Painting with Roassal2

We’re happy to announce that Alexandre Bergel of ObjectProfile has put out a new video showing how easy it is to analyze your Smalltalk code with Roassal.

Hernán Morales Durand - 10 simple survey questions about Smalltalk


So I did a short on-line Smalltalk survey to find out where is the technology today, and what could be expected in the future, by asking people about their experiences and expectations with Smalltalk. Any programmer could participate and answer. The survey was designed to a broad developer audience.
Why is important you take this survey? Because you could help to a small(talk) community to uncover answers, to gather feedback and meaningful opinions, and to evolve by telling what you need most. The survey is open until 31/10/2014 at 3:15 a.m.

The survey is not biased towards any particular Smalltalk flavor (I am not affiliated with any particular Smalltalk provider). The following Smalltalk platforms have been included (any other not listed flavor can be added):


I have collected a list of well-known forums containig "General Computer Programming" sub-forums, as most forums do not contain a Smalltalk sub-forum. I have rejected all programming sub-forums specific to a particular language, for example: JavaForum, PHPDevForum, "General C++ Forum", etc. Because:

  • Posts with surveys related to other programming language are not commonly accepted
  • They are marked as off-topic or closed.
  • It could be seen as promotion which is not the intent of this survey.


The survey is still running! You can come back after 31/10/2014 and check responses.

Torsten Bergmann - Amber 0.13 is released

October 20, 2014

Cincom Smalltalk - What on Earth is “Shellshock Honeypot”?

How to test your system for Shellshock vulnerability, how a simple attack against a web server can exploit it and how to build a quick and dirty honeypot using the Cincom® VisualWorks® 8.0 SiouX HTTP server.

Pharo Weekly - Building your own power tools: an Example

Using ZnLogEvents and GT Tools to look at HTTP traffic behind Monticello.

I love it when a plan comes together. Many small usability changes were added to GT Tools since they were included in Pharo 4. And a lot of small custom inspector presentations were added.  (be sure to select the 720p version)

This short screencast shows how to use ZnLogEvents and GT Tools in Pharo 4 to look at the HTTP traffic behing Monticello (more specifically, an MCSmalltalkhubRepository). This demonstrates how simple custom inspectors are combined to form a powerful tool - and how easy it is to learn about what is going on inside Pharo or inside your complex business app


October 19, 2014

Julian Fitzell - Declaring Seaside sub-components in the #children method

People often ask why they need to define the #children method on Seaside components. I wrote a long email today to the mailing list explaining how #children is currently used and why it's important and I thought it might be useful to post it here as well so it's easier to find and link to. 

When you render a child component you are implicitly defining a tree of components. #children simply allows the framework to walk the component tree explicitly. The reasons for needing to walk the tree explicitly have changed over time, which is part of the reason for the confusion.

At one point, for example, we used to walk the tree to give each component a chance to handle callbacks, so if your component wasn't in #children it would never even have seen its callbacks. That is no longer the case (which is actually a bit of a shame because decorations can no longer intercept them, but I digress).

If you look in the image for users of WAVisiblePresenterGuide and WAAllPresenterGuide, you will see the current cases where we need to traverse the tree:
  1. Calling #updateStates: for snapshotting/backtracking
  2. Calling #initialRequest: when a new session is started
  3. Executing tasks (they need to execute outside of the render phase to make sure the render phase does not have side effects)
  4. Calling #updateRoot:
  5. Calling #updateUrl:
  6. Displaying Halos for each component in development mode
  7. Generating the navigation path in WATree
  8. Detecting which components are visible/active to support delegation (#call:/#show:)
Keep in mind that basically all these things happen before rendering, so if you create new components inside #renderContentOn: they'll miss out: you should try to create your sub-components either when your component is initialized or during a callback. If your child component doesn't rely on any of the above (and doesn't use any child components itself that rely on any of these things) then technically everything will work fine without adding it to #children. But keep in mind that:
  • the framework may change in the future to traverse the tree for other reasons;
  • add-ons may depend on being able to walk the tree for other reasons; and
  • it's not great encapsulation to assume that, in the future, components you are rendering will never need any of the above nor start using sub-components that do. 
Finally, components are stateful by definition, so if you don't feel the need to persist your component between render phases, it probably shouldn't be a component. For stateless rendering you're better to subclass WAPainter directly or even WABrush: both of these are intended to be used and then thrown away and they will make it clearer in your mind whether or not you're using on things that depend on #children.

Pharo Weekly - Another week of effort in Pharo

13606 testSlotScopeParallelism is failing

14085 Image blocked when halt placed on setUp method and running a whole TestCase from Nautilus

14054 Cant load font from a path with accented characters

11021 MouseEvent>>blueButtonChanged

14075 Halt once in Rectangle>>setOrigin:corner:

14028 PluggableThreePhaseButtonMorph should be packaged with Morphic-Widgets-Basic

13668 remove the last StringHolder references

13635 Package Spec-Extensions just contains one accessor –> can be moved to the class

5625 TextDiffBuilder in System-FilePackage ?

14076 Move ProtocolRemovalException to Kernel-Exceptions

14048 two tests failing in EmbeddedFreeTypeFontInstallerTest

14079 Inconsistent information in debugger (pharo 4)

14061 windows systemfonts : wrong path in guessWindowsFontFolderPath

13131 Spec weirdness > MNU ToolDockingBarMorph>>popupEvent:in: on right click on button

14072 Failing test: BlockClosureTest>>#testTallyInstructions

14069 Finish cleaning RGFactory

14077 Move PseudoClassOrganization close to PseudoClass

13738 MNU: CompiledMethod>>hasRun

13705 Shared pool incorrectly defined as global

14071 OSWindow integration part1

13599 ClassOrganizer-Core: move to Kernel-Protocol

12111 (Date readFrom: 4.2.2013 readStream pattern: d.m.yy) ==>> 4 February 2020

13193 Regular expression field should not open debugger when making a syntax error

3841 FinderUI gets out of sync when more than one Finder open

10307 Monticello FTP repo should not keep username and should behave like MC HTTP

14067 More cleaning of Ring Factory

14034 add to Pharo3: substrings:

12828 Unfullfilled subclass responsibility in JPEGReadWriter

13879 Move Tests out of NECompletion

14065 Spec WorldModel should not change theme background

14057 fix the description and unique name RBFutureDeprecationWarningRule.

14062 Remove SmallInteger class>>#ccgCanConvertFrom:

14056 Missing DejaVu copyright notices

11996 Wrong exception handler problem (parrt 5/5)

11996 Wrong exception handler problem (4/5)

11996 Wrong exception handler problem (Part3)

11996 Wrong exception handler problem

14048 two tests failing in EmbeddedFreeTypeFontInstallerTest

11996 Wrong exception handler problem (Part1/5)

14055 Fix some failing tests related to Code Critics (due to accidental #halt)

13606 testSlotScopeParallelism is failing

14019 add critics rule for #withFirstCharacterDownshifted-> #uncapitalized

14049 add String>>substrings: and lint rule for #subStrings:

14035 openWorldWithSpec not taking over the world

14045 Categorize classes in System-Announcements

10572 Locking image with test icons (Glorp example)

13843 MOPTraitTes>>#testOrigin failing

14046 Deprecate SystemAnnouncement(class)>>fromInternal:

14044 Selfies shot with Pharo should give visual feedback

14008 Tests from Nautilus-Tests need to be moved to a nautilus test package

13949 stackAlignment on windows should be 16

14043 TabContainerMorph example gives DNU #instance

14037 #recompile does not recompile the classTrait

14038 #testSendersOfAt failing when running the tests in the image

14039 #testCurrent always fails when running all tests…

14041 Continue cleaning Ring Factory

14026 Cleanup System-Localization package and add tests

12873 IconicButton should absord property as instance variable

14032 Fix test cases and access singletons using slots

14030 MorphicTabManagerAdapter>>doesNotUnderstand: #tabSelected:

14018 backport #uncapitalized to Pharo3

14025 DateModel Broken in 3.0

14027 ensureTransparentColor is unused and looks dead

14029 Smart Suggestion Implementors does not work in Nautilus anymore

14023 Nautlilus: Jump to test class should not only work on instance side

14012 RGMetaclassDefinition and RGMetatraitDefinition DNU #category

14009 RBAddClassRefactoringTest should be moved close to the other refactoring tests

14007 DebuggerModelTest should be moved out of debugger package

14017 No senders of analyzeItemLabels

14022 Infinite loop in simple subclasses of SequenceableCollection

14020 Add test cases which check font installation process and registration on singletons

14006 3 tests fail for AsmJit in the Pharo4

13214 rename instance variable does not work on class side

14011 Many leftover methods after method announcement refactoring

October 17, 2014

Pharo Weekly - Phratch 40 is out

Phratch 4.0 is out of the box !
Phratch 4.0 is cleaner, faster and more stable than phratch 3.0.
After the version 3.0 that was a release for usability and stability, phratch 4.0 is released to prepare the future.
The new features are:
- phratch is more modular, eg having a kernel and lots of addons.
- cleaning a lot the source code
- customizable environment
- each block can be made visible or invisible
- each category can be made visible or invisible
- it is possible to add translation for addons with the pragma <phratchTranslation: ‘fr’> in the class PhratchTranslator. This make the translation more modular.
- first integration of phratch with the pharo environment. Using the pragma at the class side of any class in Pharo make the class visible and usable in phratch.
- There is a lot of things to do with phratch, you are welcome to contribute ! The documentation for new features will arrive soon.
See you on

Smalltalk Jobs - Smalltalk Jobs – 10/17/2014

Two ads for the same job for 5+ years of java/agile/etc.  Needs English.  Located somewhere in Germany but the location is unspecified.



Filed under: Employment

October 16, 2014

Torsten Bergmann - PharoNOS - Pharo No Operating System

Booting Pharo as OS with only 55MB ISO image. Read more and take care where you use it (best on a virtual platform to not to erase disks)

Ricardo Moran - Programmable Minecraft: coding at runtime

Hello everyone! The Programmable Minecraft project is progressively growing and I’d like to share its current status with you today.

We polished the interaction mechanisms we had designed earlier, so we could begin to “expose” the code involved. Users can now carry out a few basic tasks (such as placing a block of a specific kind on a determinate position of the world). While only a very reduced number of interactions have been incorporated into the project until now, the number of applications these have is huge.

An example of application is the generation of structures of enourmous size and complexity. What would manually take days (or even weeks) can be achieved through simple algorithms in a few minutes.

Here are a few screenshots of some structures we’ve been generating to test the project:

Sierpinski Triangle

Dragon Curve

Archimedean Spiral

¡Hola a todos! El proyecto de Minecraft Programable avanza poco a poco, y vengo a compartirles su estado actual:

Puliendo un poco los mecanismos de interacción desarrollados inicialmente, comenzamos a “exponer” el código útil para dicha interacción. Ahora es posible para los usuarios realizar algunas acciones básicas mediante código (como colocar un bloque en una determinada posición del mundo). Si bien se ha incorporado un número muy pequeño de interacciones, los resultados alcanzables mediante ellas son prácticamente ilimitados.

Aquí hay algunos screenshots de las estructuras que hemos generado para probar al proyecto:

Sierpinski Triangle

Dragon Curve

Archimedean Spiral

Noury Bouraqadi - Controlling robots with PhaROS

An example of a robotic guide at Ecole des Mines de Douai. Controlling robot with PhaROS from jannik Laval on Vimeo.

Nicolas Petton - Interview with Johan Degerfeldt

Oct 16, 2014

Two months ago I moved to Stockholm, working full-time at Företagsplatsen as a software engineer. Företagsplatsen (or FTGP for short as we call it) is a really fun IT company to work at, I really enjoy the people and the culture. Just like I did with my previous job at Inria, I decided to do another series of interviews of my colleagues at FTGP.

As the CEO of the company, it only made sense to interview Johan first. I guess Johan looks like what we imagine of a viking: tall, light hair and a beard, but he is definitely more talkative than the average Swedish guy. He’s half of the time joking around and the other half really serious talking business and stuff, making him a really cool guy to work with.

Read the interview

Torsten Bergmann - Pharo 4 progressing

Pharo 4.0 is not yet released but progressing. Beside many many other stuff some of the interesting things include:

Pharo News - Pharo Consortium: New Gold Member LabWare

<p>The Pharo Consortium is very happy to announce that LabWare has joined the Consortium as a Gold Industrial Member. </p> <p>About LabWare: &quot;LabWare is recognized as the global leader in providing enterprise scale laboratory automation solutions. Our Enterprise Laboratory Platform combines the award-winning LabWare LIMS™ and LabWare ELN™, a comprehensive and fully integrated Electronic Laboratory Notebook application, which enables companies to optimize compliance, improve quality, increase productivity and reduce costs. LabWare is a full service provider offering software, professional implementation services and validation assistance, training, and world class technical support to ensure our customers get the maximum value from their LabWare products.&quot;</p> <ul><li> LabWare: <a href=""></a></li><li> Pharo Consortium: <a href=""></a></li></ul> <p>The goal of the Pharo Consortium is to allow companies to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: <a href=""></a></p>

Pharo News - Pharo Consortium: New Gold Member LabWare

<p>The Pharo Consortium is very happy to announce that LabWare has joined the Consortium as a Gold Industrial Member. </p> <p>About LabWare: &quot;LabWare is recognized as the global leader in providing enterprise scale laboratory automation solutions. Our Enterprise Laboratory Platform combines the award-winning LabWare LIMS™ and LabWare ELN™, a comprehensive and fully integrated Electronic Laboratory Notebook application, which enables companies to optimize compliance, improve quality, increase productivity and reduce costs. LabWare is a full service provider offering software, professional implementation services and validation assistance, training, and world class technical support to ensure our customers get the maximum value from their LabWare products.&quot;</p> <ul><li> LabWare: <a href=""></a></li><li> Pharo Consortium: <a href=""></a></li></ul> <p>The goal of the Pharo Consortium is to allow companies to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: <a href=""></a></p>

Smalltalk Jobs - Smalltalk Jobs – 10/15/14

  • Houston, TX, or Los Angeles, CA (but will accept REMOTE) – Smalltalk / VisualWorks Consultant through Valtech
    • Required Skills:
      • 5+ years experience in Smalltalk/VisualWorks (v7.X).
      • Experience developing and supporting a 24X7 mission critical application with Smalltalk/VisualWorks is required.
      • Applicant must be fluent in English reading, writing and speaking skills.
      • US Citizenship or Green Card.
    • Additional listings: eclaro, NetSource, VisionIT

Updates on 10/22/14: Marked out a listing for the position.

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 Tagged: jobs, Smalltalk, Smalltalk jobs

October 14, 2014

ESUG news - CfP Smalltalk Devroom at FOSDEM 2015.

Call for Participation in the Smalltalk Devroom at FOSDEM 2015.

A devroom for the Pharo, Squeak, Amber, GST, Etoilé, Seaside, Moose Smalltalk projects & Objective Smalltalk and Newspeak as derived languages. Smalltalk environments offer a very high development productivity, unmatched by their successors. Come do some pair programming with us and experience yourself the advantages of a real OO environment"

The meetup will take place Sunday, February 1, 2015, room S.H.2214. This room has 100 seats, a VGA video projector and wireless internet. Presentations will be video recorded (CC BY).

Proposals on content and format are welcome.


All submissions are made in the Pentabarf event planning tool at

When submitting your talk in Pentabarf, make sure to select the 'Smalltalk devroom' as the 'Track'.

If you already have an account there, please reuse it.


Any questions, and video volunteers, please mail to


with [FOSDEM] in the subject. I will send out updates on a regular basis to the lists and anyone stating his interest.


Sessions of 30/60 minutes (-5 min setup), last session a two hour hands-on introduction to smalltalk. First session or lunch session can be show-us-your-project, lightning talks.

The desired time slot is meant to help you prevent conflicts with other dev rooms in which you might have a talk or your travel arrangements.

There are alternative, non smalltalk-specific tracks available: lightning talk and the main track

Please submit before December 1, 23:00 GMT+1.  

Devroom related URLs:

FOSDEM is the Free and Open source Software Developers' European Meeting, a free and non-commercial two-day weekend event that offers open source contributors a place to meet, share ideas and collaborate.

October 13, 2014

Hernán Morales Durand - Application Security 2: The CheckPoint Protocol


As commented in my previous post, CheckPoint is a security pattern to avoid unauthorized access to a system.

The nice idea of the design pattern is to delegate complex validation behavior into specific classes which can manage events, response actions and statistics, completely transparent to your application. CheckPoints could be used to bypass validations for specific cases too. For example if you are debugging or testing your application, you don't want to be constantly bothered by timeouts and logins, you don't want to bias security statistics, and certainly you don't want to debug into someone's new bug merged in your repository, in the middle of your workflow.

The following sections describe how to use core classes for a typical application scenario.

Basic workflow

Let's assume an application is globally represented by a Singleton class, and it has different states. An state could be "in deployment mode" or "in testing mode". Each of these "modes" contain behaviors, implemented in specific CheckPoint subclasess. This simply means, you can use a Global Application class to answer a default CheckPoint class for your needs.

An example: Our Singleton manages application's state, and so it could be asked which CheckPoint should be assigned to each user, at a specific scenario he is in. This is, CheckPoint instances are associated to user sessions. Initially all newly created users will have a "invalid" or "unregistered" state. When the user begins the registration process, its session is given a CheckPoint instance to behave accordingly.

From here two different security scenarios are possible, depending on the registration state. Each scenario is represented by a CheckPoint subclass:

ASRegisterCheckPoint : Should be assigned while the (candidate) user is not confirmed as user. Maintains a registration object (ASUserRegistration), responsible to hold an unique link identifier, the registration time, and the corresponding candidate instance (ASCandidateUser). To optimize resources, a candidate user manages expiration (#hasExpiredRegistration) and that's a reason why is important to keep a #registrationDate.

ASDeployCheckPoint: This is a "common" CheckPoint which should be used for production systems, and when a registered user signs-in a system. It checks against typical login conditions, which we will se below in the Using the CheckPoint section.

Registering Users

Before anything else, create a repository and mock user to play with:

| cp newRegId |
cp := ASRegisterCheckPoint new.
newRegId := cp registrationId.
cp addNewUser: (ASCandidateUser new
entityName: 'alphabetic name';
username: 'alpha3';
password: 'alphanumeric123';
registrationId: newRegId;
Trying to add another candidate with the same username will raise an ASUserExists exception. Ideally you should catch and handle it appropiately in the context of your application. You can now query if you can register this candidate:

cp isValidPendingRegistrationId: newRegId.
and register as valid user in your system:

cp registerCandidateAsUser: newRegId.

Using the CheckPoint

Continuing with the Session-based example, login code which uses the CheckPoint could ask for the current user CheckPoint, and perform a global validate and retrieve:

user := self checkPoint
loginUserNamed: 'myuser'
password: 'anypassword'
machine: ''.
The message send performs three major steps:
  • Validate authentication settings for the provided parameters
  • Validate if passwords match.
  • Answer the user from the repository
You can also chain exceptions to manage fail conditions, logging messages or block an user:

^ ASEmptyError , ASInvalidUsername , ASEntityNotFound , ASPasswordError , ASMaxUserFailCountError
, ASMaxMachineFailCountError , ASMaxGlobalFailCountError , ASDenegatedAccess
and manage the exception properly:

[ cpUser := self checkPoint loginUserNamed: usernameString password: passwordString machine: '' ]
on: self loginExceptions
do: [ :ex | ^ self handleFailedLogin: ex ].

CheckPoint verifications

Login an user should perform a number of checks which, many times, are application security specific. The default implementation is naive, but useful for many cases. For specific security requirements, validation settings are customizable by subclassing ASDeployCheckPoint and specializing the method #validateAuthSettingsLogin:password:machine:. This is how looks like as in the current release:

(userString isEmpty or: [ userString isNil ])
ifTrue: [ ^ ASEmptyError signal: 'Username' ].

(passwordString isEmpty or: [ passwordString isNil ])
ifTrue: [ ^ ASEmptyError signal: 'Password' ].

(self isValidIpAddress: ipAddressString)
ifFalse: [ ^ ASDenegatedAccess signal ].

(self validationSettings allowedUsernameCharacters includesAllOf: userString)
ifFalse: [ ^ ASInvalidUsername signal: 'Invalid characters ' , userString ].

(self validationSettings allowedPasswordCharacters includesAllOf: passwordString)
ifFalse: [ ^ ASPasswordError signal: userString ].

(Remember, this is not code checking on User-Agent side, this is Application Security so your application's security can be guarantee independently of UI code).

A first look at Validation Settings

If you have ever worked with an Expert System, you already know what a Rule-Base is, and probably have figured out that all verifications could be easily written using rules. Although currently Application Security does not use rules, it seems a good point to note the direction where our model should be going to (if you want to read a really cool chapter about Rules-Based Expert Systems, try the one from Robbie T. Nakatsu in Diagrammatic Reasoning in AI)

Validation setting objects are maintained by CheckPoints and useful during registration time. They notify authorization/authentication exceptions and answer limit settings like:

  • Maximum size for characters allowed for a user name.
  • Maximim size for characters allowed for a password.
  • Characters allowed by a password.
  • characters allowed by an user name.
  • Expiration days for a password.
  • Valid IP addresses

As they are CheckPoint specific, they could be changed at run-time for an user or a group of users, which is very handy for debugging purposes. And that's all for today, in the following post I will post how to set up password rules to customize validation settings. See you soon.

October 12, 2014

Göran Krampe - Here Comes Nim!

I just posted an article comparing some silly benchmarks between Cog Smalltalk and LuaJIT2. Now... let's take a look at one of the latest "Cool Kids" on the language front, Nimrod - or as it has been renamed - Nim.

So I love programming languages. But generally I have preferred dynamically typed languages because I have felt that the static type systems that we have suffered with for the last ... 25 years or so has basically been completely awful. Perhaps not in implementation performance, but definitely in developer productivity and enabling good quality code.

Working in say Smalltalk has been like roaring free in the skies instead of crawling in the mud with C++, well, you get my point. I still recall one of the first 30 line "programs" I wrote in Smalltalk, just quickly jotted it down - and it ran perfectly at the first try. I attributed that to the concise language and "noise free" code (no static type noise!). My first stumblings in C++? Ha! Its not even funny.

But I have never been against static type information per se - I mean, its just a question of what we need to tell the compiler... so if we can have a type system that can reason around my code at compile time without bogging me down in endless typing and convoluted code that is hard to change and refactor and hard to read and hard to write... argh! Then yes, by all means.

Many new statically typed languages have started incorporating type inference. I haven't really worked with them, Haskell is perhaps one of the best known. Dart is a dynamically typed language but instead opted to adding mechanisms for static type annotation in order to help on the tooling front, a clever idea IMHO.

Rust, Go and... Nim!

In another article I wrote about Rust and Go (and more) - two new, popular and very interesting statically typed languages. But I admit that I totally missed Nim! Previously known as Nimrod, ehrm. And yes, Nim does have type inference, although to a balanced extent.

Just like LuaJIT2 has been a "Tour de Force" of a single author, so has Nim - and that is interesting in itself. I would say it has been a pattern over the years with most successful open source languages.

Ok... so enough chit chatting, let's look at that silly benchmark I played with earlier - in Gang Nim Style:

Nim silly benchmark

<h1>Import times for time measurements and future for some upcoming features (naked lambdas)</h1>

<p>import times, future</p>

<h1>Just a recursive function, the astute reader notes that we declare a return type of int64</h1>

<p>proc benchFib(fib) :int64 =
  if fib &lt; 2:</p>

<pre><code>return 1

<p>  else:</p>

<pre><code>return 1 + benchFib(fib-1) + benchFib(fib-2)

<h1>Trivial helper to measure time, discard is used to show we ignore the return value</h1>

<p>proc timeToRun(bench) :float =
  var start = epochTime()
  discard bench()
  epochTime() - start</p>

<h1>And this is the bytecode benchmark translated from Squeak</h1>

<p>proc benchmark(n) :int =
  const size = 8190
  var flags: array[1..size, bool]
  for j in 1..n:</p>

<pre><code>result = 0
# Clear all to true
for q in 1..size:
  flags[q] = true
for i in 1..size:
  if flags[i]:
    let prime = i + 1
    var k = i + prime
    while k &lt;= size:
      flags[k] = false
      inc(k, prime)

<h1>And echo the time to run these two, note the naked lambda syntax "() => code"</h1>

<h1>The "&amp;" is string concatenation. The $ before timeToRun is "toString"</h1>

<p>echo($timeToRun(() => benchmark(100000)) &amp; " bytecode secs")
echo($timeToRun(() => benchFib(47)) &amp; " sends secs")

Whoa! Look at that code! I mean... it looks like Python-something! And not much static type noise going on, in fact there are only 4 places where I specify types - the three return types of the three procs, and I also specify that the array has bools in it. That's it.

If you recall the numbers from LuaJIT2:

10.248302 bytecode secs
26.765077 send secs

...and Cog:

49.606 bytecode secs
58.224 send secs

...then Nim mops the floor with them:

2.6 bytecode secs
7.6 sends secs

So Nim is about 4x faster on bytecode speed and 3x faster on recursive calls compared to LuaJIT2. And about 20x faster on bytecode speed and 8x faster on recursive calls compared to Cog.

A few things of note:

  • The Nim code is just as small and readable as the Lua and Smalltalk code.
  • The brute speed comes from shoulders of giants, GCC. But it also means that the generated code is fairly C-friendly, which is fascinating given the depth of this language.
  • I used a few extra features; const for the size, let for prime (non assignable var), inc() for incrementing variables - but all these didn't affect the numbers much, it was just fun to try to make it more Nimiomatic.
  • The above little snippet compiles in 0.2 seconds to a 67kb executable on Linux using the short command "nimrod c -d:release test.nim". Nice!


I wrote this as a teaser - Nim is actually a brutally darn cool language. Lots of people seem to prefer it over Rust - and it has a "pragmatic" soul - Rust on the other hand is very focused on safety, safety, safety. Nimrod is more focused on developer productivity. And it has a lot of nice stuff:

  • Written all in itself, clean and nice bootstrap.
  • Compiles via C (or C++/ObjC) which gives it very good performance, platform independence and integration with C/C++/ObjC etc.
  • Has a very neat modules system
  • Has lots of really, really interesting language features. Sure, a bit featuritis perhaps - but I am not judging just yet.
  • ...and well, I just can't go through it all here! Its too much!

I would say that if you are thinking of perhaps taking a peek at the "Dark Side" (static typing) - then this is it. I think Nim will make you smile in more ways than one.

Göran Krampe - Cog vs LuaJIT2

In the open source Smalltalk community we have a pretty fast VM these days - its called Cog and is written by the highly gifted and experienced Eliot Miranda who also happens to be a really nice guy! Cog is fast and its also still improving with some more developers joining recently.

Another very fast VM is LuaJIT2 for the Lua language (version 5.1), also written by a single individual with extraordinary programming talent - Mike Pall. LuaJIT2 is often mentioned as the fastest dynamically typed language (or VM) and even though Lua is similar to Smalltalk (well, its actually very similar to Javascript) its also clearly a different beast with other characteristics. If you start looking at the world of game development - then Lua appears everywhere.

I am a language lover but I admit to having only glanced at Lua earlier and wrongfully dismissed it in the category of "less capable and quirky languages". Now that I have looked closer I realize its a similar "hidden gem" as Smalltalk is! And just as Smalltalk was given a boost of interest when Ruby hit the scene - I guess Lua gets an influx now with the Javascript craze. And the gaming world keeps infusing it with fresh code.

Lies and, well basically just lies...

In Squeak Smalltalk we have this silly little benchmark called tinyBenchmarks. It's not for benchmarking. No, let me repeat that - it really is not.

But hey, let's just ignore that for a second. :) And oh, comparing Lua vs Smalltalk - speed is only a tiny piece of the picture - there are other much more interesting characteristics of these two eco systems that would affect any kind of "choice":

  • Smalltalk implementations typically have live reflective rich IDEs, and excel at complex domain models and interactive explorative development. And very clean late bound OO. Not so good at "playing well with others" though.
  • Lua, and especially LuaJIT, is extremely good at playing with others - and specifically the C/C++ eco system. As a more traditional scripting language you have more choices in IDEs and SCM tools etc, but it is not as interactive and exploring as Smalltalk and is not focused at OO specifically, although it can do it pretty good. It does however have several good IDEs, but hardly anything matching a Smalltalk IDE.

So Smalltalk excels in interactive development - but you are often limited in integration options... while Lua excels as a dynamic language thriving as a catalyst in the C and C++ eco system.

These languages and their tools were simply born from two very different sets of goals. And Lua is also different from say Python, since Lua in contrast was designed as a minimal language (in many ways like Smalltalk was) and a language meant for embedding in a C/C++ application (almost no batteries included). This carves out a fairly unique niche for Lua.

Ok, so back to tinyBenchmarks. It consists of two small snippets of code, one measures "bytecode speed" by counting primes in a few nested loops and another is a recursive function similar to Fibonacci that just counts the number of recursive calls. Ok, so... latest Cog (binary VM.r3000) vs latest LuaJIT2 (2.1.0-alpha), here follows the Lua code I whipped up. I tried basically three different variants on the Fibonacci recursion to see how much penalty an OO design would give.

Lua silly benchmark
local class = require("classy")</p>

<p>-- First here is how you would do it in proper Lua, just a recursive function
local function benchFib(fib)
  if fib &lt; 2 then</p>

<pre><code>return 1

<p>  end
  return 1 + benchFib(fib-1) + benchFib(fib-2)

<p>-- Or using a metatable for a bit more manual OO style
local Bench = {}
Bench.__index = Bench</p>

<p>-- A constructor
  local bench = {}
  setmetatable(bench, Bench)
  return bench

<p>-- And a method in it
function Bench:benchFib(fib)
  if fib &lt; 2 then</p>

<pre><code>return 1

<p>  end
  return self:benchFib(fib-1) + self:benchFib(fib-2) + 1

<p>-- A variant using the "Classy" OO lib. Another popular is called "MiddleClass"
local Benchy = class("Benchy")</p>

<p>-- And a method in it
function Benchy:benchFib(fib)
  if fib &lt; 2 then</p>

<pre><code>return 1

<p>  end
  return self:benchFib(fib-1) + self:benchFib(fib-2) + 1

<p>-- And this is the bytecode benchmark translated just as it says in Squeak
local function benchmark(n)
  local size = 8190
  local count = 0
  for j=1,n do</p>

<pre><code>count = 0
local flags = {}
for q=1,size do
  flags[q] = true
for i=1,size do
  if flags[i] then
    local prime = i+1
    local k = i + prime
    while k &lt;= size do
      flags[k] = false
      k = k + prime
    count = count + 1

<p>  end
  return count

<p>-- Return seconds to run fn
local function timeToRun(fn)
  local start = os.clock()
  return os.clock() - start

<p>t1 = timeToRun(function() benchmark(100000) end)
t2 = timeToRun(function() benchFib(47) end)
t3 = timeToRun(function() end)
t4 = timeToRun(function() Benchy():benchFib(47) end)</p>

<p>print(t1 .. ' bytecode secs')
print(t2 .. ' benchFib send secs (normal Lua)')
print(t3 .. ' Bench send secs (OO Lua)')
print(t4 .. ' Benchy send secs (OO Lua Classy)')

And the Smalltalk code would be:

Squeak silly benchmark
Transcript show: ([100000 benchmark] timeToRun / 1000.0) asString, ' bytecode secs';cr.
Transcript show: ([47 benchFib] timeToRun / 1000.0) asString, ' send secs';cr@

I picked 100000 and 47 to get fairly long running times, so LuaJIT:

10.248302 bytecode secs
26.765077 benchFib send secs (normal Lua)
70.418739 Bench send secs (OO Lua)
71.003568 Benchy send secs (OO Lua Classy)

...and Cog:

49.606 bytecode secs
58.224 send secs

So LuaJIT2 is about 4x faster on bytecode speed and 2x faster on recursive calls.

But wait, lots of things to note here:

  • These are two trivial benchmarks meant to detect really bad regressions in VM code, not benchmarking.
  • The above. Read it again.
  • A recursive function call in Lua is not the same thing as a message send with full OO lookup in Cog. If we look at Bench and Benchy we see that 2x factor vanish!
  • Integer math is clearly different in Lua vs Smalltalk. Lua does doubles only, Smalltalk has a full math system falling back to "big ints" when needed!
  • Using Classy was the same speed as manual metatable approach. So in Lua you would definitely use such a lib instead of manual OO, much easier and with nice features.
  • And oh, both grabbed a single core by the throat doing this - Cog even managed to squeeze out 104%! :)


There is no real conclusion from the silly benchmark - it was just a fun exercise! I already knew Cog is pretty darn fast and LuaJIT is the King of the Hill - it even beats V8 regularly. Cog on the other hand is executing a much more refined and advanced language and object system, you really do need to keep that in mind here.

But I hope that especially Smalltalkers might get intrigued by this article and find Lua interesting. To me its much nicer than Javascript. Its also the first time in many years that I have found a language that actually can keep my interest for a longer period - despite me constantly comparing it with my beloved Smalltalk.

Python could never keep me interested, although I did try - but it kept turning me off, so unclean, lots of different mechanisms, too complicated. Same story with Ruby, too messy, no elegance and a community drug crazed with nifty tricks... IMHO.

But Lua has that smallness that Smalltalk has, it feels "designed". It has strong abstractions that it carries through all the way. In short it doesn't turn me off. And then, a lot more in this eco system is pure candy. LuaJIT2 has awesome speed. Very powerful interoperability with C and C++, in fact, the LuaJIT FFI can call C libraries as fast as C can! Tons of good libraries and tools. Very strong on mobile development. Many interesting projects like TurboLua, Tarantool, OpenResty, Lapis, Metalua etc etc.

Always nice to realize that there still is stuff out there that can attract an old Smalltalk dog... :)

October 10, 2014

Pharo Weekly - Another iteration follows another one

I’m always fascinated by the fact that when we do something every day, at the end we improved, changed, ….

14201 RBAssignmentOnBlockArgumentRule does not catch all assignments to block args

13174 Should warn against creating class #NameOfSubclass

14207 failing test testBehaviorRespectsPolymorphismWithTraitBehavior

14209 add back #allUnimplementedCalls

14206 remove empty RBRenameInstanceVariableRefactoringTest

7291 Creating a class with empty category should be an error

11243 Class>>copy does not preserve layout

14099 SmalllintManifestChecker duplicates RBSmalllintChecker>>#run

14098 allClassesAndTraits significantly different from allClassesAndTraitsDo:

14196 Do not use workspace as an editor

14086 RBSmalllintChecker is not applying rules in class-side

14133 UIManager should not overuse the workspace for editing

14195 In the ChangeSorter: DNU when trying to get a menu

14199 RBFindBlockArgumentAssignment is sometimes wrong

14189 OCSemanticWarning does not need #interactive

13588 Rename inst var should rename accessors too

14166 RectangleTest#testPointNearestTo failing since 40283

14183 Update Zn October 2014

14191 Add #deselectAll to TreeModel

14188 DNU when moving a method to a package

14187 Replace Announcer>>#on:send:to:s senders in Keymapping-Pragmas

14184 Replace Announcer>>#on:send:to:s senders in GroupManager

14185 Replace Announcer>>#on:send:to:s senders in Kernel

14186 remove AllowBlockArgumentAssignment from CCompilerContext

14175 GTools version 1.0.6

14179 deprecate the method in UIManager “deprecated” category

14162 Replace Announcer>>#on:send:to:s senders in Morphic-Widgets-Tree

14173 remove #allowBlockArgumentAssignment preference

14154 GTools version 1.0.5

14161 Replace Announcer>>#on:send:to:s senders in Morphic-Widgets-Windows

14169 There are undeclared in Zinc in Pharo4

14146 Disable “store into argument”-exception in non-interactive mode

13905 entering non existing issue numbers in slice maker

14164 using exampleWidget and not widgetExample

13088 Deleting class that is used in pool dictionaries leaves a “private” class pool entry

14159 Update Fuel

14155 Replace Announcer>>#on:send:to:s senders in Morphic-Widgets-Extra

14131 Improving some little tests in the system

14117 merge menuSpec and menuItemSpec

14119 Cleaning left over of docking bar in menu

14153 Replace Announcer>>#on:send:to:s senders in Morphic-Base

14150 Replace Announcer>>#on:send:tos senders in Morphic-Core

14149 IRDecompiler creates an extended method state object for all methods

14147 add Symbolic tab to inspector for IRMethod

14145 GTools version 1.0.4

13719 Failing test: RBRemoveClassTest>>#testRemoveClass

14144 unify #usePolymorphDiffMorph and #polymorphDiffToolsUsedByDefault

13718 Failing test: RBExtractMethodTest>>#testExtractMethodThatMovesTemporaryVariable

13222 HDLintReport generates invalid output

12774 DialogGroupAdderUI “item to add” list should be sorted, has superfluous periods after class names

14134 ecompletion raises DNU for some input

14082 Remove very old repositories in ScriptLoader

14138 Nautilus Refactoring 9: rename “showPackages”

14136 Replace senders of Announcer>>#on:send:to in Versionner-Spec-Browser

14128 “Print it” from Playground menu does not work

14117 merge menuSpec and menuItemSpec

14113 WorldSate stepList not properly cleaned when a morph is deleted

13641 Merge Package Key into package System-Platforms

14099 SmalllintManifestChecker duplicates RBSmalllintChecker>>#run

14129 Use Announcer>>#when:send:to: in Spec-Debugger

14124 Remove SystemAnnouncer subclass NautilusAnnouncer

14126 Remove SystemAnnouncer subclass GroupAnnouncer

10148 IRVisitor and IRInterpreter

14125 Remove SystemAnnouncer subclass TestAnnouncer

14122 Classes in Morphic-Examples should include real #example methods

12973 ChangeSorter CMD-W with menu open causes error

14120 decompiler view for GTInspector

14123 removed backgroundColor, fixed playgroundpage>>contents

13931 Integrate GTools

14100 use Announcer>>#when:do: and Announcer>>#when:send:to in Spec-Core

14116 RGDefinition is mispelled and its comment doesnt make sense

14101 Use Announcer>>#when:send:to: in Spec-MorphicAdapters

14102 Use Announcer>>#when:send:to: in Spec-Tools

12841 #testDebuggerTempAccess failures

14115 Merge RGDefinition and RGNamedDefinition

14114 use SizeMismatch, not just #error

13518 Strange color and wrong positions in the Find & Replace dialog

14111 Handle isInDockingBar conditional logic

14112 Hook decompiler into source access logic

14014 translatedIfCorresponds

14110 Remove RGObject

14090 use Announcer>>#when:do: in packages Announcements

14103 Use Announcer>>#when:send:to: in Spec-Inspector.

14087 use Announcer>>#when:send:to in packages Announcements

14095 use Announcer>>#when:send:do: and Announcer>>#when:do: in AnnouncementsTutorial

13864 Deleting last tab removes the toolbar and we cannot add tabs anymore

14088 procotol -> protocol

13607 Remove iVar MorphicModel: accessor

14105 Nautilus Refactoring 8.5: rename “showHierarchy”

12826 Zip FileSystem does not work

13867 MessageBrowser does not inform about certain syntax error

13293 We should add definedSelectors and extensionSelectors to ClassDescription

13934 Extra characters in string returned by String class>>new:streamContents:

13742 PluggablePanelMorph looks empty and is only used once in the system

14094 Deprecate a few unused String methods

13337 Moving a class to a package does not work anymore

13331 moving a group of methods class side raises an error

11475 Optimize FuelTests >> #tearDownTraits

October 09, 2014

Ricardo Moran - Congreso + Decálogo para utilizar y disfrutar Etoys

¡Hola, amigos!

Espero que anden bien. Voy a dividir el post en dos:

La primer parte se trata de nuestra participación en el congreso de tecnología informática organizado por la UAI (CIITI 2014).

El congreso estuvo muy interesante y mostramos nuestros desarrollos en un stand. Además, Gonzalo y Richi dieron dos charlas tituladas Plataforma de Hardware para Robótica Educativa y Plataforma de Programación Physical Etoys dentro del marco de los bloques Robótica Aplicada y Arquitecturas y Desarrollos Tecnológicos Innovadores.

Acá pueden hacer click para agrandar algunos comentarios que nos hicieron por Twitter:

prensa twitter


Además, publicamos los pósters que hicimos para el congreso. Si quieren tener una idea bien concreta arcerca de lo que estamos trabajando y qué pretendemos con nuestro trabajo, les recomiendo que los vean:

Poster Mendieta

Poster Minecraft

Poster Physical Etoys

La segunda parte de este post se trata de un documento que armé antes de dar un taller de Etoys hace un tiempo. El mismo se llama decálogo para utilizar y disfrutar Etoys. El mismo está basado en algunas ideas de Alan Kay y en mi experiencia al usar Etoys.

1-La computadora es un instrumento musical cuya música son las ideas. La música no está en el instrumento sino en los docentes y en los alumnos.

2-Si quiero transmitir una idea, tengo que pensar en qué objetos intervienen y cómo colaboran para lograr ese objetivo.

3-La esencia de Etoys es la interacción. Si no hubiera interacción ¿Qué lo diferenciaría de un libro o de unas diapositivas?

4-La metáfora de un mundo vivo que late constantemente en donde el error es algo natural dentro de la programación es poderosísima para programar nuestros objetos.

5-Exploren, construyan y rompan todo si es necesario para aprender. Etoys está para eso.

6-Etoys es transversal a la currícula. No tienen por qué casarse con matemática, física o tecnología. Existen proyectos de música, pintura, literatura y animación.

7-No es lo mismo consultar un valor que asignarlo. Por lo tanto, hay que considerar desde dónde arrastramos a los bloques.

8-Realizar tutoriales, compartir proyectos y sugerir mejoras hace que la experiencia de Etoys sea mejor no sólo en tu escuela sino en todo el mundo. Nada más lindo que enseñarle a un chico a hacer proyectos para que otros chicos puedan aprender una idea. 

9-Utilizar bien Etoys requiere constancia pero por sobre todo humildad. Nosotros guiamos a los chicos pero ellos pueden mostrarnos muchas cosas que descubrieron en sus casas. Más se les enseña, más nos enseñan.

10- Diviértanse. Si no es divertido para ustedes ¿Por qué habría de serlo para los chicos?

Bueno, espero que les sirva esto como guía y que les haya gustado.

Les voy a decir una cosa más: Physical Etoys está más vivo que nunca. Y cierro el post con un video emocionante que nos llegó de la provincia de Salta :D

Que se diviertan!


October 08, 2014

Marten Feldtmann - PUM 1.2.59

More work done towards a general REST generator (model and GUI change):

-> Projects may now have a class prefix attribute. This string is added to all created classes

-> Classes may now have “roles”. The code generators may use this “roles” during code generation.

-> Classes/Attributes have now “shadow” objects.

-> Menu entry added to jump directly to the error definition page

-> Menu entry added to create all classes within the model needed to have initial REST support.

Filed under: Smalltalk Tagged: Gemstone, PUM, Smalltalk