Planet Smalltalk

June 27, 2016

Andres Valloud - Reliable email matters

Many of today's issues with software ultimately cause unreliable service.  Software's popularity does not seem greatly influenced by reliability, so the audience seems to tolerate the situation.  However, when unreliability becomes the norm, the resulting ecosystem is one in which nothing works as advertised.  You have effectively no recourse other than to roll out your own, become a system administrator, or put up with it.

This kind of environment directly limits what you can accomplish in life.  Take for instance email.  Although delivery was never guaranteed, at least you had some chance to track down problems and there seemed to be a general willingness to ensure correct transmission.  Today, emails simply vanish with no explanation, and you're not supposed to know what has happened.  After some debugging, the best working hypothesis for the latest occurrence is as follows:

Comcast silently refuses to deliver you emails that contain your email address.

To verify this hypothesis, I sent myself emails with just "" in the message body.  These emails did not bounce, did not show up in a junk email folder, and were not delivered.  But emails reading "", with the last 't' missing, were delivered.

That aggressive spam filtering is a necessary evil, the usual excuse, doesn't cut it in this case.  Someone replies to you, and the text says "at some point, wrote:".  Or someone comments on a forwarded email of yours that reads "From:".  These ubiquitous, well established email body patterns are being dropped without notice.

This new form of unreliability started at least a few weeks ago.  Comcast's first approach to resolve the issue was to unilaterally reset my password on a Saturday, while stating the department taking action does not work on weekends.  When resetting a password predictably didn't fix the delivery problem, Comcast's final position was for me to complain to Thunderbird, GMail, and several other ISPs / email client software makers for their evident, collective, and synchronized fault.

The side effects of unreliable software are allowed to spread unchecked in part because, in an unknowable and incomprehensible software world, naturally there is no responsibility and thus no recourse.  Hence, the above diagnosis is merely a best working hypothesis.  Occam's razor suggests the email problem is Comcast's fault.  But how do you find where the problem actually is without access, much less appropriate support?

I don't think this will get any better as long as software and derived services can be sold without any form of accountability whatsoever.  Consequently, until then, protecting yourself from unreliability is up to you.  In the case of email, that means implementing and/or managing your own email server.  But where does that road end?  Email is hardly a top reliability concern.  The go-it-alone approach does not scale.

Why does Dan Geer take up farming?  Should you, too?

Clément Béra - FullBlockClosure design

Hi everyone,

As discussed in the previous post I am attempting to introduce FullBlockClosure as a replacement for BlockClosure in Pharo.

The introduction of the FullBlockClosure leads to simplification in Cog’s JIT and other part of the system related to bytecodes. This is because with the new model activating a closure or a method are much more similar, hence more code can be reused between both.

Let’s look at the FullBlockClosure creation bytecode in the SistaV1 bytecode set (which I have been using for a week in Pharo without crashes):

* 255 11111111 xxxxxxxx siyyyyyy push Closure Compiled block literal index xxxxxxxx (+ Extend A * 256) numCopied yyyyyy receiverOnStack: s = 1 ignoreOuterContext: i = 1

At FullBlockClosure creation time, the VM is aware of:

  • The index in the literal frame of the compiledMethod of the compiledBlock (a compiledBlock being very similar to a compiledMethod), which represents the code to execute when the closure is activated.
  • The number of copied values.
  • A bit marks if the receiver in the closure is the outerContext’s receiver, or another object pushed on stack. This is used for inlining.
  • A bit marks if the closure needs an outerContext or not (this is used for copying block to avoid object allocation).

The FullBlockClosure created is filled with those fields:

  • Field 1: outerContext: the outerContext of the closure if the bytecode creation specifies it, else nil.
  • Field 2: (previously startpc) compiledCode: an instance of compiledBlock, which represents the bytecode to execute when the closure is activated.
  • Field 3: numArgs: number of arguments of the closure. It’s cached here for efficient #cull: implementation.
  • Field 4: receiver: the receiver of the closure activation, which is not necessarily the outerContext receiver.

Upon activation, the FullBlockClosure now fetches:

  • The receiver from its receiver field instead of the outerContext receiver field.
  • The compiledBlock from its compiledCode field instead of the outerContext method offset by its startpc.

The new design have implications for the (compiler/VM) programmer:

  • A full closure’s outerContext is now used only for non local returns. Any block without a non local return does not need an outerContext, except for advanced debugging features.
  • The compiled block (code the closure has to execute) is now completely independent from the method the closure is created. This means for example that the JIT can compile to machine code and install separately a method and its inner block closures. Other similar things are simplified.
  • It’s possible to inline a method with a closure in another method without decompiling the closure’s bytecode (The decompiler still needs to check for non local return though). In the past we need to update the closure bytecode, specifically access to instance variables or literals, which was tedious and required additional deoptimization metadata.

Hopefully someone will implement copying blocks and clean blocks, and we will see if the performance overhead is important or not.

With this changes not only Cog’s JIT but also the runtime optimizer is simplified. I’m integrating the FullBlockClosure changes, it’s likely that I will propose an open alpha of the Pharo Sista image (you’ll need to compile the Sista VM to experiment) before ESUG. The debugging support won’t be complete (each context on optimized code *can* be deoptimized, it’s just about having the tools like the debugger doing it), but the benchmarks should run on the alpha version and hopefully some people will help me to integrate new optimization passes to reach the expected 3x performance boost.





June 26, 2016

Smalltalk Jobs - Smalltalk Jobs – 6/25/16

  • Miami, FLSmall Talk Developer/Lead through Cresens Inc Careers
    • Required Skills:
      • 10 years in Smalltalk code development
      • Must have experience in handling multiple projects in parallel
      • Thorough understanding of Object Oriented design principles and detail oriented
      • Strong problem solving skills
      • Systematic approach to work assignments and problem solving
      • Hands-on experience with VisualWorks 7.9 version and above
      • Background developing quality Smalltalk code and delivering product feature documentation
      • Familiarity with the internals of the VisualWorks tool set
      • Comfortable using VisualWorks to design and build user interfaces
      • Strong written communication skills and planning abilities
      • Works well in a distributed team environment
    • Wanted Skills:
      • Experience with API calls and platform libraries on the operating systems of interest to us (Windows, Linux, Unix)
  • Miami, FLSmall Talk Developer through Resource Logistics
    • Required Skills:
      • 3-4 Years of strong hands-on development experience in Visual Works 7.9 Small-Talk Development.
      • Should have excellent knowledge on the OOPS Concepts.
    • Wanted Skills:
      • Should have experience on .Net technologies.
      • Should have good verbal and written communication skill.
      • Should work independently in Smalltalk technology.
    • Additional listings: Simplion Technologies, ReqRoute, e-Solutions
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

June 25, 2016

ESUG news - ESUG 2016, Innovation Technology Awards

ESUG 2016, 13th Innovation Technology Awards

Have you written innovative Smalltalk? The developers of any Smalltalk-based software can enter by submitting a 3-5min video of their software. Entrants demo their systems in a session at the end of Monday August 22, 2016, after which the conference attendees vote. (A vote consists in providing a sorted list of 3 preferred pieces of software.)

The top 3 teams with the most innovative software will receive, respectively, 500 Euros, 300 Euros and 200 Euros. The results are announced in the Awards ceremony that is held during the social event.

Applicants should provide the following information on the conference registration server. Once you have registered your personal info, an 'Awards' menu allows submitting your software. You can provide this information when you first register, or login again later and update your details.

Info to provide:

  • Name of the software
  • Licence information (free, shareware, or commercial)
  • Name of the Smalltalk dialect used
  • Name, Affiliation and Country of developers

Besides, it would be great if the submission could include:

  • URL for a video (3-5 min) showing a screencast / demo of the software
  • URL for downloading the software or at least a runnable demo
  • Deadline: August 21, 2016

Any Smalltalker can apply (students, companies, ...). The presented piece of code/software should be written in Smalltalk or directly support Smalltalk (e.g. Smalltalk VM). All Smalltalk dialects are accepted. The applicant should be "strongly related" to the presented code, be it as an author, as owner of the copyright/copyleft, or as an official representative of the copyright/copyleft owner.

Jordi Delgado - ESUG 2016 Innovation Technology Awards

ESUG 2016, 13th Innovation Technology Awards

Have you written innovative Smalltalk? The developers of any Smalltalk-based software can enter by submitting a 3-5min video of their software. Entrants demo their systems in a session at the end of Monday August 22, 2016, after which the conference attendees vote. (A vote consists in providing a sorted list of 3 preferred pieces of software.)

The top 3 teams with the most innovative software will receive, respectively, 500 Euros, 300 Euros and 200 Euros. The results are announced in the Awards ceremony that is held during the social event.

Applicants should provide the following information on the conference registration server. Once you have registered your personal info, an 'Awards' menu allows submitting your software. You can provide this information when you first register, or login again later and update your details.

Info to provide:

Besides, it would be great if the submission could include:

Any Smalltalker can apply (students, companies, ...). The presented piece of code/software should be written in Smalltalk or directly support Smalltalk (e.g. Smalltalk VM). All Smalltalk dialects are accepted. The applicant should be "strongly related" to the presented code, be it as an author, as owner of the copyright/copyleft, or as an official representative of the copyright/copyleft owner.

June 24, 2016

Torsten Bergmann - Walls, Pillars and Beams: A 3D Decomposition of Quality Anomalies

A video demonstration of a 3D approach (in Pharo) from the paper with the same title.

Torsten Bergmann - Functional callbacks on all Cog platforms

Pharo as well as Squeak are based on a common virtual machine implementation (Squeak VM, later Cog). This virtual machine source code recently was moved over to GitHub as OpenSmalltalk VM to better maintain the (small but existing) differences in the virtual machines for Squeak, Pharo, Newspeak and Cuis Smalltalk.

Within all open source Smalltalks derived from Squeak (Squeak, Pharo, Newspeak) historically and initially there was a mechanisms to call external code outside the Smalltalk environment. This mechanism was called FFI - which is the abbreviation for foreign function interface. So you could call external libraries to perform an action.

Later there was another mechanism called Alien FFI that also allowed to pass a callback function to the ouside world. Alien was provided in 2007 by Eliot Miranda and old docu could be found here and here.

In Pharo later there was another mechanism called "NativeBoost" (provided by Igor Stasenko) to call external functions. NB allowed to be using native code directly and really fast as the native code was attached to a compiled method and lived within the image. Relying on assembler (provided by a package called ASMJit) the NativeBoost solution is very fast - but also hard to maintain because NB was not as portable as the initial FFI solutions.

Later Pharo decided to resynch all these efforts into what is now known as UFFI (Unified Foreign Function Interface) provided by Esteban Lorenzano. UFFI unifies and also borrows from FFI, Alien and even NativeBoost.

Also with the more aligned OpenSmalltalk VM the different open source Smalltalks come closer together. Current work in progress on the virtual machine side is to allow for 64 bit Smalltalk systems and to better support ARM architecture beside x86 one.

Eliot now announced that Alien now has functional callbacks on all x86 platforms, ARM32 platforms and x86_64 platforms. This is another major step in having a portable interface to the outside world as we can use callbacks on all these platforms. Great stuff!!!

June 23, 2016

Torsten Bergmann - CuboidMatrix: Exploring Dynamic Structural Connections in Software Components using Space-Time Cube

A demonstration video of the VISSOFT paper by Teseo Schneider, Yuriy Tymchuk, Ronie Salgado and Alexandre Bergel. Done in Pharo.

Pharo Weekly - Functional callbacks on all Cog platforms

Hi All,

just wanted to report that as of Alien-eem.35 and we now have functional callbacks on all x86 platforms, ARM32 platforms and x86_64 platforms.

There’s a simple example Alien class>>exampleCqsort that shows how to use the system and tests the implementation using the C library’s sort quick sort implementation that takes a function pointer as an argument to use for comparing pairs of elements.  This is mapped onto a Smalltalk block by Alien’s callback implementation.  The example sorts 100 random double-precision floats using qsort and a callback into Smalltalk.

Pharo Weekly - New version of Interactive Fiction Framework

New version of Interactive Fiction Framework

I think it is mature enough to be used, but of course there might be some
rough edges.

Contributors, users and testers would be very welcome!


June 22, 2016

Cincom Smalltalk - Smalltalk Digest: June Edition

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

June 21, 2016

Torsten Bergmann - SmallWorlds for Pharo

Interactive Fiction framework in Smalltalk is released. Read more

June 20, 2016

Torsten Bergmann - Talking Small

Another newbee is discovering Smalltalk. Looks like he tries to learn a language each month and also stumbled over Pharo.

If he really wants to learn Smalltalk and find out more he for sure will need more time than just a simple month. Initial steps in Smalltalk are easy, also syntax is easy to learn - but learning what power it contains requires more time and a deeper understanding. Also it takes a while to understand why things are the way they are. Often learning to deal with pure OO also means to unlearn (bad) things from the mainstream programming languages...

Nonetheless nice summary of his early steps.

Torsten Bergmann - LRP - Live Robot Programming in Pharo

How does a PR2 move through a door opening? By using LRP of course! Live Robot Programming (LRP) is a live programming language designed for the creation of the behavior layer of robots. It is implemented in Pharo.

June 19, 2016

Pharo Weekly - Continuous improvements: the agile way

18520 EyeTreeInspector is broken

18527 #halt should not be in the badSelectors rule

18525 fix for IconStyler
18524 Add Icon Styler for haltOnce and haltOnCount:

18496 duplicate shortcut usage for window close and tab close

18514 ConfigurationOfEpicea not in sync with Pharo

18511 DNU MorphicDiffAdapter keyStroke:fromMorph:
18517 ConfigurationOfVersionner needs update to be in sync with Pharo

18522 Add icon styler for “self halt”

18518 ConfigurationOfCatalog needs update to be in sync with Pharo

18513 NEC fails to guess the type of non-class bindings

18521 Add manifest for Random-Core

18512 cleanup related to deprecations

18509 per send-site #haltOnCount:

18507 add #deprecated:transformWith: (automatic rewrites of deprecated sends)
18477 QualityAssistant v3.0.5

15849 Remove NewList

18282 Scrollbar doesnt move when scrollValue is set in TextModel

18501 icons -> icons iconNamed: (part 2)

18497 EncoderForSistaV1: last integration to be usable.

18484 instance variable refactoring without instance variables

18489 remove more old deprecated methods

18488 remove “recover lost changes…”

18486 remove some methods deprecated in Pharo 5
18492 safer access to charset

15085 non-english character input

18485 TabsExample broken (icon access)

18490 Configuration of TxText needs update stable version
18470 EncoderForSistaV1 update

18480 remove MCMockRPackage

18479 Process termination trick for Semaphore critical method should be refactored to be reusable for other lock objects

18481 Better #haltOnce: per haltOnce state, auto-enable

18332 ClassRefs menu items should be moved at the same level than analyze

18478 “Instance variables defined in all subclasses” rule not clear
18448 Rubric: “Do not use #ifNotNilDo:ifNil:, #ifNil:ifNotNilDo:, #ifNotNilDo:”

18468 Use readOnlyQueue when reading source files
18474 move var to class refactoring broken II

18476 update Versionner to 2.13.15

18072 TxModel >>#applyAttribute:to: sends unimplemented message

18473 move var to class refactoring broken

18475 Do not announce method creation if the class is anonymous

June 18, 2016

Göran Krampe - Fowltalk - a new Smalltalk

In my quest making Spry I also learned about other efforts in the Nim community to construct Smalltalk-like dynamic languages. The most ambitious one may be Fowltalk by "fowl" who typically hangs out in the #nim channel on Freenode. Fowltalk started out written in Nim but since fowl wanted to learn more C++ it's now written in C++17.

At the moment he is rewriting the parser and code generator parts in the language itself, following a similar bootstrapping style as Ian Piumarta's idst. For example, here is the method parsing keyword messages.

At the moment Fowltalk is nowhere near usefulness but its fun stuff!

It's interesting to look at these bootstrap* files - we can immediately notice some syntactic differences to Smalltalk-80:

Block arguments are written like [| :x :y | ... ] and you can mix both locals and params there: [| :aParam aLocalHasNoColon | ... ]. Instinctively I can agree with the combination, but I would probably then make the first | optional.

Some messages have been changed, like ifTrue:ifFalse: is instead ifTrue:else:. I have done similar simplifications in Spry. And just like in Spry ivars are referenced using @myIvar.

There isn't any documentation on Fowltalk yet, but it's clearly a rather elaborate implementation. It compiles to bytecodes, uses numbered primitives (I think) and there is an image mechanism.

It was also quite easy to get the REPL up and running, but just as with Spry, it's hard to know how to use it! On Ubuntu I installed boost sudo apt-get install libboost1.58-dev and then it was easy to get it running following the instructions, as long as you change to

The image constructed by the bootstrap process is 67Mb in size. Then we can do the canonical Smalltalk test in the REPL:

``` bash gokr@yoda:~/fowltalk/idk$ ./bin/oop -i oop.img --mmap --repl

(3 + 4) print 7

!quit gokr@yoda:~/fowltalk/idk$ ```

Fowl mentioned that the new parser can be loaded using !read bootstrap.1 but... at the moment that causes errors.

It will be interesting to see where this goes! Fowltalk is very early in its evolution, and it's not a JIT, but it's a real bytecode VM with an image and we can never have enough Smalltalk-like languages! :)

Pharo Weekly - Updated Pharo Launcher


I just updated Pharo Launcher. A new version 0.2.11 is available.
Here are the change log:
  • move Pharo Launcher to the latest stable pharo image: pharo 5.0. It implies That Pharo Launcher is now shipped with Spur VM.
  • allow an easy download of the new beta image: pharo 6.0
  • the Launcher now comes with 2 VMs:
    • Spur VM (pharo 5.0 and Pharo 6.0)
    • Non-Spur VM (to be able to run old images)
  • the Launcher is now shipped with a default template that is the current default Pharo image. It can be found in local templates.
  • there is a new OS bundle for linux: we now ship more files with the launcher and it was needed to have a bundle.
  • update of the default name propose when you create an image from a template: the default name will be the project name.

Self Blogs - Improvement proposals

I would like to spur discussion about structure of the project and also about the community, its organization and knowledge bases. I believe that this discussion is really important for the future of Self development.

Self is open source, which is important, but not sufficient condition to thrive. Open source success is only partially given by the license, but more importantly by the community of people around projects. In the end, it is the people what makes all the difference.

Self has somehow sleeping community, which I think is partially because we don’t have good tools for communication and self-organization.

Here is what I think that would be useful:

Official Github organization

Github allows to create „organizations“, which is used to group multiple projects under one „official“ entity.

Current state of Self on Github is confusing, especially for newcomers. From what I understand, „official“ repository is the one in Russel Allen’s personal account, but there is no „THIS IS OFFICIAL REPOSITORY, CONTRIBUTE HERE“ sign. People have to figure this on their own and hope that they didn’t figure it wrong.

I would also recommend to split the Self repository into several smaller, single-purpose-oriented repositories. For example: separate the handbook, and maybe application directory (git can do this without the loss of history).

It would be probably good idea to decide if we want to allow anyone to access this „organization“ and to let anyone add their own application repositories. This would simplify the discovery of available Self software. Other possibility is to use it only for „official“ stuff and „syndicate“ Self packages somewhere else (wiki or package repository).

Talking to the people

We need to start to talk to the people. This is a problem that all smaller projects have; there is too much context in your head (this is relevant to the bus factor from previous blog).

The „THIS IS OFFICIAL REPOSITORY, CONTRIBUTE HERE“ sign is the classical example of the context that everyone from the mail-list have. It was posted few times into Self conference, but for anyone coming outside the Self community, this is really hard to figure. You have to talk to people, or they won’t know.

The Self wiki is another example of this problem. There is no sign that there actually is a wiki. [CENSORED (see discussion in mail conference, search keyword drama)]

If you want something from the people (eg. contribution), you have to tell them. They are not mindreaders and they won’t engage without knowing that it is ok to engage.

For example, I pushed a lot of typo and RST formatting fixes to the Self Handbook / Russel Allen’s git repository and I felt really uneasy doing this. Is it okay to contribute? Is it okay to make changes in someone else’s work?

Community WIKI

15.12.2010, 09:55 Thorsten Dittmar written:
hello folks,

for me self is still one of the most beautiful languages I know, but the lib's are not so shapelily. So we have a kind of an Ugly Duckling here... a lady with amazing intrinsic values and horrible "lips"... 

Of course, we can start with some cosmetics.. We can change the UI and other stuff, but for me that doesn't look like the right way... Self has so many unfinished stuff, that I guess we will not make it better to open another bottle.

What is „unfinished stuff“? What is the state of Self? Where is the FAQ? Where is the screenshot section? Where is community knowledge base? Where is documentation? Where is the detailed description of VM? Where do you collect information?

Currently, only way to get a clear idea about Self and its state is to read the mail archive and the 115 thousands lines of C++ sources. Mail archive is the worst possible database for this kind of stuff. Not only that history is not easily accessible for newcomers, it also cannot be edited and improved. Also attachments don’t work much.

We need good community Wiki, where we can:

  • collect information about Self
  • document the VM
  • document aspects of programming in Self
    • It is really hard to find any source code to study. There are applications in Self’s git repository, but it took me 6 months to notice. Again, there is no signs pointing to this.
  • discuss various stuff about Self, ideas, improvements, highlights and so on
  • document what is in bad shape, what needs to be done and plan future work
  • provide user’s sections
    • Something like a blog, but for all kinds of data, files, snippets and information related to Self, that user’s may save for benefit of themselves and others.
    • This need to be under user’s control.
  • have user profiles – some small section, where you may shortly introduce yourself and maybe tell others what you do
    • It is hard to tell who is working on the Self and what are they doing. Again – this is context information which are not available.
  • collect list of links to all relevant Self information sources
    • I am willing to do this and maintain this section.
  • collect list of links to Self alternative interpreters and inspired languages
    • I partially did this in previous blog.
  • tell people how to contribute, where to contribute and other community information
    • Viz „Talking to the people“.

Wiki is important part of the plan to increase the Self’s bus factor (see previous blog). It also helps people (newcomers especially) to put themselves into perspective of what Self is, how to interact with community and how to contribute.

I am willing to be maintainer of this Wiki. I don’t really want to, but I have strong feeling, that if I am not going to do it, nobody will.

Github wiki

I don’t think it is a good idea to use this specific wiki software, because to me, it looks like it is seriously limited in capabilities.

I like, that it uses the Git for synchronization, but I feel, that we will need something more advanced. Something that will be able to host large variety of content, categories and discussions. When I think about it, I see it like the hybrid between the c2 wiki and Wikipedia.

I don’t expect anyone to come with clear solutions, but I think that we need to talk about this and look at alternatives. What do you think?

Package repository

One of the services, which I think is critical for success of any language is the package repository and package manager.

I am not that sure how easily this may be done for Self, but I am 100% sure, that this is necessary for larger adoption;

We need to give people the tool, which will allow them to build applications on top of other people libraries. Not just that – also the place where we can discover new libraries and projects, instead of having them scattered all over the Internet.

I have a lot of experiences with Python and believe me when I say, that this is big win for the language and big reason to use it.

Community decision

I know, that Self was a research language, and partially probably still is. I will impersonate the Generic Beginner* and speak using his voice, when I say:

I think that after 26 years, it is time to make up your mind. How do you perceive Self? What is it to you? Do you take Self seriously, or is this just a game?

I can’t build a product on Self in its current state. I can’t afford to wait decades for improvements. I need to know, whether I can count on you (the community).

I may put my time and/or resources into Self, but I need to know that I won’t be wasting my time, and that I am not alone.

I want to know your opinion. It may be clear in your head, but again – if you don’t talk to the people, they won’t know.

For me,


What about you?

*Not necessarily my opinion, but I think it comes to mind of all newcomers looking at Self and thinking „hey, this looks nice, should I use it?“

June 17, 2016

Pharo Weekly - Automatic Deprecation Refactoring


I have dusted off and improved the automatic refactoring of deprecations.

- when the refactoring engine is not present, it falls back to a standard deprecation
- It does not introduce any dependencies (can just be in the Kernel, the only cost is one method of 10 lines).
- It sets the author so it does not require initials
- It refactors *only* the sending (offending, deprecated) send site. So a second selector that is identical (which might be a different method and not deprecated) will not be affected.

The way to use it is this:

ifNotNilDo: aBlock
        deprecated: 'Please use #ifNotNil: instead'
        transformWith: '`@receiver ifNotNilDo: `@statements' -> '`@receiver ifNotNil: `@statements'.
    ^ aBlock ifNotNil: aBlock

As we try to provide already Lint rules for deprecations (or at least should have..) the amount of additional work is not much.

This is the full implementation:

deprecated: anExplanationString transformWith: aRule
    | rewriteRule method context node |
    context := thisContext sender sender.
    (Smalltalk globals hasClassNamed: #RBParseTreeRewriter) 
        ifFalse: [ ^self deprecated: anExplanationString ].
    method := context method.
    node := context sourceNodeExecuted.
    rewriteRule := (Smalltalk globals classNamed: #RBParseTreeRewriter) new replace: aRule key with: aRule value.
    (rewriteRule executeTree: node)
        ifFalse: [ ^ self ].
    node replaceWith: rewriteRule tree. 
        useAuthor: 'AutoDeprecationRefactoring'
        during: [method methodClass compile: method ast formattedCode classified: method protocol]

This is *with intention* the absolute “simplest thing that can possibly work”. There is no interactive tool to preview refactoring in interactive
mode, or some way to opt in or out. 

The power of things like this comes from actually using them, not from being perfect...


June 16, 2016

Torsten Bergmann - Pharo and 3D

The nice work of Ronie Salgado with Pharo and 3 summarized on his page. Nice!

Torsten Bergmann - Voyage with Unqlite support

For relational databases there is the tiny SQLite database solution that just requires a simple linked library (DLL/SO file) including the full database engine.

There is a similar tiny database called Unqlite in the NoSQL world. Pharo already had a Unqlite binding in the past. Before Pharo 5 this "PUnqlite" project was based on Native Boost. It was provided by Masashi Umezawa and I extended the project with a spec based UI to provide a database browser for Unqlite.

During the Pharo 5 development I discussed with Esteban many issues on #Slack about porting several of my projects to UFFI. We also discusssed about Unqlite and Esteban quickly ported the PUnqlite binding over from NB to UFFI. This was done on GitHub. Additionally I remigrated the changes back to the original repo of PUnqlite on STHub and made it loadable from Catalog in Pharo 5 again. So with Pharo 5 you again have a package "PUnqlite" that you can load from Catalog. Just open Spotter and type in the name.

During these #Slack sessions we also discussed about Estebans Voyage framework. Voyage is a layer that allows for very simple persistence in Pharo. It is explained here and here.

So far Voyage only worked with MongoDB as backend. Often Mongo requires some setup which might be overkill for simple deployable applications that you want to build with Pharo. So we also discussed about using UnQlite as a backend for Voyage.

Esteban wanted to work on this for a project and now first results are available: Voyage is now restructured with a second backend to support also UnQlite beside MongoDB.

Cool - thanks Esteban!

Torsten Bergmann - More than 15 arguments

support is on its way. But I guess if you have need more than 15 arguments in a method you should think about your design. Possibly an argument object would be applicable.

June 15, 2016

Pharo Weekly - Nicer haltOnce


Yesterday we improved #haltOnce to be more like a “once” BreakPoint:

	-> state per *each* haltOnce send
		(this means you can put two in one method and they are independent)
	-> when putting a haltOnce, it is enabled by default
	-> The global menu entry just resets all haltOnce to be active again.

Interesting is how trivial this was to implement… in class Halt 
    | node |
    node := thisContext sender sender sourceNodeExecuted.
    (node hasProperty: #haltOnce) ifTrue: [^self]. 
    node propertyAt: #haltOnce put: true.
    ^ self signal.

This means, we get the AST node of the “haltOnce” message send. Then we put an annotation there.
To reset all (enable all), the global many just does:

	#haltOnce senders do: #recompile.


This will be in 60082.


Cincom Smalltalk - Cincom® ObjectStudio® 8.7.1 and Cincom® VisualWorks®8.1.1 Are Here!

It is our pleasure to bring you the Personal Use License (PUL) version of Cincom Smalltalk™. This PUL release includes the maintenance releases of Cincom ObjectStudio 8.7.1 andCincom VisualWorks 8.1.1.