Planet Smalltalk

September 23, 2016

Pharo Weekly - Material Design Lite for Seaside

Hi everyone!

I am happy to announce the version 1 of Material Design Lite for seaside.

This version contains all components from V1.2.1 of Google's Material
Design Lite (,

This version also contains some widget build in top of MDL as:

    Pagination widget
    Sorted Paginated Table
    Select Widget
    Poll Widget
    Calendar Widget
    Nested List with dynamic loading and search function

Thanks to Kévin Lanvin, Olivier Auverlot, Thomas Heniart, Merwan Ouddane
and Guillaume Larcheveque who helped to release this version.

Thanks to Sabine Mana for the feedback she gave.

You can find the project on:

There is some documentation of the README.

If you find a bug you can open an issue on the repository.
If you have some question I will be happy to answer.

Torsten Bergmann - MaterialDesignLite for Seaside

The project MaterialDesignLite to provide MDL for Seaside reached first milestone 1.0.0. A demo can be seen here.

Torsten Bergmann - Railway modeling in Smalltalk

Railway modeling in MetaEdit - a tool written in Smalltalk. Reminds me of RUT-K from german railway, a large Smalltalk project for train schedule planning that I helped shaping

September 22, 2016

Benoit St-Jean - A Small Contribution

It’s official, they’re gonna add my Trie implementation into Pharo 6.0!!!  Funny enough, I had forgotten about that code.  I’ll have to check if that old version has bugs or performance problems and fix it if it’s the case!

Classé dans:Pharo, Smalltalk Tagged: Pharo, Smalltalk, trie

September 21, 2016

Travis Griggs - Two Years Later...

So nearly two years later, I've stuck with it. I am not a Swift expert, but I no longer use Objective-C. I have written a small app in Swift. And rewrote my much larger app in 100% Swift. Plus also written a few small test/demo apps.

Here's a recap on my original observations:

Out of Date Information - This remains an issue. But seems to burn me less lately. I've learned to always look in the newly integrated doc viewer first. Some, but not all, StackOverflow posts get updated to match Swift3. The mailing list is always current. I make sure if I ask a question on SO, that I make it clear I'm doing Swift3.

Replacing one Legacy with Another - Apple's aggressive integration makes this a lot less than I expected. The fact that most APIs follow the Swift naming conventions instead of being obviously converted from keyword style naming makes it seem less legacy already. The aggressive attitude of replacing oft used types with bridged variants also makes it seem legacy (e.g. Date replacing NSDate). My apps need no @objc qualifiers, so the need to have legacy rubbed in my face is obviously disappearing quickly.

Head Turning Paradigm - The human brain can adapt to some things pretty quickly. This appears to have been one. In fact, I actually prefer the "type post cedes" rather than "type precedes" pattern. I still do quite a bit of C, so it's not just me moving on. I have to do both approaches regularly, and I actually like this. I've even begun to use the optional typing in Python which follows the same notation.

:, :, and : - This has turned out to not bother me much. I don't really notice it in fact. The dictionary thing never shows up much. The tools quickly correct me if I get a dictionary/array mismatched. The other two uses just seem natural now. It still can seem a lot of typing (especially now that default first arguments have been deprecated), but the auto completer keeps me from noticing how much I spell things out.

Wrap, Unwrap, Ugh - Doesn't bother me at all anymore. Especially once I figured out how to extend Optional with ifNil and ifNotNil methods. Sometimes I get a bit tired of nested if let... statements.

Refactoring - Still miss this a lot. But lets face it, I don't have much refactoring support in my C or Python stuff.

At two years in, I like Swift. As an older more polyglotted developer, I don't love it like I did other systems in my younger more idealistic years, but it works for me. I often think "this is like a C++ that I can handle." I still detest C++. If I have to choose between Java and Swift, I'd take Swift in a heartbeat. In fact, I even have a slight preference for Swift over Python.

Pharo Weekly - Trie and Grid…

We get now a trie implementation (developed by Benoit St-Jean) and Grid as part of a slow growing project called Container for collection outside of the image.

location: ‘’
user: ”
password: ”

There are now available in the catalog browser for Pharo 60.

If you have new collections that you want to add to the project just ask.

More to (slowly) come….


Smalltalk Jobs - Smalltalk Jobs – 9/21/16

Job in Lille France at Synectique.

Synectique provides comprehensive and sophisticated analysis tools to
improve the quality of software, reduce maintenance costs, and thus enable
easier software evolution.

The company was created in 2013 and already got some renowned customers.
To sustain our growth we are looking for a full-time Smalltalk (Pharo)
developer with some additional non Smalltalk skills.
2+ years OO programming experience or equivalent, with strong skills in OO
design, front-end JavaScript and back-end Seaside/Pharo.

The ideal candidate should be comfortable with meta-model approaches,
client-side web technologies (HTML, CSS, JavaScript), be familiar with
code parsing and master different languages (Java, C++, C#, ADA,

The job is based in Lille, which is centrally located with good
connections by train to everywhere (one hour from Paris, 1h20 from
London, 35 min from Brussels).

Duration: Permanent (CDI)
Starting date: September 2016
Salary: depending on skill set/experience
Ready to travel if needed.

Additional Skills:
Object-oriented design/programming
Agile Methodologies
Fluent in French and/or English
Please send your applications to

Filed under: Employment

Pharo Weekly - Synectique is recruiting

Synectique provides comprehensive and sophisticated analysis tools to improve the quality of software, reduce maintenance costs, and thus enable
easier software evolution.

The company was created in 2013 and already got some renowned customers.
To sustain our growth we are looking for a full-time Smalltalk (Pharo)
developer with some additional non Smalltalk skills.
2+ years OO programming experience or equivalent, with strong skills in OO
design, front-end JavaScript and back-end Seaside/Pharo.

The ideal candidate should be comfortable with meta-model approaches,
client-side web technologies (HTML, CSS, JavaScript), be familiar with
code parsing and master different languages (Java, C++, C#, ADA,

The job is based in Lille, which is centrally located with good connections by train to everywhere (one hour from Paris, 1h20 from London, 35 min from Brussels).

Duration: Permanent (CDI)
Starting date: September 2016
Salary: depending on skill set/experience
Ready to travel if needed.

Additional Skills:
Object-oriented design/programming
Agile Methodologies
Fluent in French and/or English
Please send your applications to

Cincom Smalltalk - Smalltalk Digest: September Edition

The September Edition of the Cincom Smalltalk Digest.

The post Smalltalk Digest: September Edition appeared first on Cincom Smalltalk.

September 20, 2016

Pharo Weekly - Pharo 50 Little Testimony

Hello all,

Thanks thanks thanks for Pharo 5.

Each year, from September to November, my students are learning Pharo with the last release.
And as you know, beginners and naive users are very good at stressing a software🙂
Previous years I faced issues due to Pharo bugs (especially because of Nautilus but not only).
Since 2 weeks, no issue at all regarding Pharo, a real pleasure.
So this mail is just to thank all of you who made this cool release.


Torsten Bergmann - UK Smalltalk User Group Meeting - Monday, September 26th

ESUG news - UK Smalltalk User Group Meeting - Monday, Sept 26th

The next meeting of the UK Smalltalk User Group Meeting will be on Monday, September 26th.

We'll meet at our usual venue The Counting House at 7pm.

If you'd like to join us, you can just show up at the pub. You can also sign up in advance at the meeting's Meetup page: **.

UK Smalltalk - UK Smalltalk User Group Meeting - Monday, September 26th

The next meeting of the UK Smalltalk User Group will be on Monday, September 26th.

We'll meet at our usual venue, the Counting House, from 7pm onwards.

If you'd like to join us, you can show up at the pub. You can also sign up in advance on the meeting's Meetup page.

Torsten Bergmann - Smalltalk Reflections episode 15: distributed live computing

Torsten Bergmann - CogMethod’s Maps

CogMethod’s Maps explained by Clément Béra

Torsten Bergmann - PoliteSmalltalk to interact with EV3 Robots

A Polite Solution to Interact with EV3 Robots. Using Pharo, Phratch and JetStormForPhratch

Read the summary and the PDF.

September 19, 2016

Torsten Bergmann - Smalltalk is dead, long live Smalltalk

Robert C. Martin (from Object Mentor, Inc, also known as "Uncle Bob") once did a presentation in 2009 on RailsConf with the provocative topic "What Killed Smalltalk Could Kill Ruby, Too".

The way this talk was presented was nice and funny - but by declaring Smalltalk dead he showed me that he never really followed this technology and all its offsprings close enough.

If Smalltalk would be dead how would I have been able to fill my blog with news about it over so many years? If it would be dead why do new things like Agile VisualizationsSoftware Analysis platforms or cloud platforms like pop up? Why is it used to lively program robots or help solving scientific computations when it is dead? How could it help fighting Ebola or disaster and climate change when Uncle Bob says it is dead? How could a dead technology coordinate so many containers shipping around in this world, or how could it be used in one of the largest financial projects? How could it be given to so many people around the world as a visual programming tool? Looks like nobody cared that Mr. Martin declared it as dead already in 2009 ...

For sure Smalltalk is not as widespread as Java, C++ or C# and it will never be on top of the TIOBE index (since this is the most stupid metric to rank programming languages ever invented). But it is in use, a productive and efficient environment to solve daily problems that would be hard to solve in other technologies.

And all this in times where people (without having a deeper understanding) quickly decide for new technologies as the better ones "automagically" - because they think "newer means better". But often we see that new technologies just reinvent the wheel or provide an improvement only in a single aspect.

Smalltalk is around now since 1972, lifted and commercialized in 1980, stable and mature, used in big and small projects and processes. Because of this age it is not the first time it was declared legacy or dead. But due its virtual machine and its dynamic nature it was and still is adopted to new platforms, new requirements or new hardware. Some Smalltalks can even run 1:1 in the webbrowser or on the Pi.

So in the tradition of "The king is dead, long live the king!" Smalltalk is still alive and kicking. Primarily in the open source scene with PharoSqueak, Cuis, Amber there are many new success stories or books.

Now in 2016 even "Uncle Bob" - based on the old Type wars discussions (static vs. dynamic typing) - needs to admit in a blog post that:

"The Smalltalkers will, eventually, win. So says this old C++ programmer."

But there is no competition, so there is no need to have a winner.

Smalltalk is alive and still about new ideas - about new ways of computing and modeling our world to form something better.

Clément Béra - CogMethod’s Maps

Hi everyone,

Today I am going to discuss the little map at end of cog methods. This map is used by the VM to get information about the machine code during various operations such as send’s site relinking and garbage collection.

Cog methods

In Cog, a cog method is the machine code version of a Smalltalk (bytecoded) compiled method. It is located at the different place than the bytecode version, as the machine code needs to be in an executable memory zone. On the contrary, the bytecode version needs only to be in readable, and potentially writable, memory zone. In addition, the cog method requires specific care by the garbage collector (GC) as the GC cannot scan the machine code as it would scan objects.

A cog Method looks like this:


The cog method header contains metadata related to the cog method. One information stored here, for example, is the size of the cog method. The size is used to be able to iterate over all the cog methods in the machine code zone. Another information is the machine instruction address for the stack overflow check, which is one of the first machine instruction of the machine code of the method.

At the end of the cog method, a small map is present. This map is used by the garbage collector, the machine code zone compactor and various other utilities such as relinking inline caches. The map contains annotations of the machine code.

Machine code annotations

While generating the machine code version of a bytecoded method, cogit (cogit is Cog’s JIT compiler) annotates different machine instructions. We will divide the annotations of the machine code in 5 main categories:

  • Object references: When an object is directly referred from machine code, its address is written as a full machine word and is annotated as an object reference. This annotation is used typically for references to the method literals: on some machine back-ends such as x86, literals are inlined in the machine code and their addresses are annotated as object references. This annotation is used by the GC: if one of the literals is moved in memory by the GC, the GC uses the annotation to know the location of the literal’s address in the machine code and update it to its new address.
  • Absolute PC references: This annotation is used exclusively for cog method references. In the stack frame creation code, at the beginning of the machine code of frameful methods, there is machine code which upon execution writes down in the active stack frame the address of the cog method. This address is an absolute address in the machine code zone. It needs to be annotated because when the machine code zone compactor compacts the machine code zone, it moves cog methods and therefore needs to update their addresses.
  • Relative calls: As for absolute addresses, relative calls needs to be updated when the machine code zone is compacted. In most architecture, relative calls are used to call trampolines.
  • Bytecode PCs: At each interrupt point, the VM needs to be able to recreate the interpreter version of the frame for the programmer to debug the code. This annotation is therefore used for each interrupt point, except sends which are implicitly mapped with the send call annotation (explained just below).
  • Send calls: Each send’s site needs to be annotated for the inline cache logic to be able to link and unlink the send and to have a bytecode pc annotation. There are different kinds of sends (normal, super send, directed super send, newspeak sends, etc.), and each of them has a specific annotation.


The challenge is to encode the annotations in a very compact way. To do so, the annotation are encoded as an annotation type and the distance in the machine code from the previous annotation. There is no additional information (no annotation metadata or anything like that).

The annotation scheme used in Cog method maps is as follow:


Each annotation is encoded in a byte. In each byte, 3 bits are used to precise the annotation type and 5 bits are used to encode the distance from the previous annotation.

The annotation types described in the previous sections are encoded as follow (type – annotation name):

  • 2: Object reference
  • 3: Absolute PC reference
  • 4: Relative Call
  • 5: Bytecode PC
  • 6: Newspeak send
  • 7: Normal send

The encoded values 0 and 1 are used to extend the other annotations:

  • 0: Displacement. If the distance from the previous annotation is greater than 31 (depending on machine architectures, 31 bytes or 31 words), this annotation is used to extend the distance.
  • 1: Annotation extension. This annotation is used as a prefix to extend the normal sends (type 7). This allows the VM to support more types than 7. The additional types, from 8 to 255, can be used to encode uncommon sends. Using an extra byte only for uncommon send allows not to waste too many space. The following figure details the extended byte encoding.


Thanks to the annotation extension, 5 other kind of sends are implemented:

  • 08: Super send
  • 09: Directed super send
  • 10: Newspeak self send
  • 11: Newspeak dynamic super send
  • 12: Newspeak implicit receiver send

Reading the annotations

The GC only needs to read object references while the machine code zone compactor only needs to read relative calls and absolute PC references. This is relatively easy: the first annotation is always the stack overflow check, which address is known by the Cog method header. From the first instruction, the VM can iterate over the annotations, computing at each step the new machine instruction address. Each instruction can be patched this way. I won’t go into details on how this happens as this is back-end specific.

Reading the bytecode PC annotations to map the machine code instruction pointer to the bytecode program counter is slightly more complicated. The VM needs to iterate at the same time both over the machine code, computing at each step the machine instruction address, and the bytecode of the method, computing at each step the bytecode PC of the current mapped instruction. While iterating over the bytecode, the VM stops at each instruction which is mapped from bcpc (bytecode PC) to mcpc (machine code PC). When iterating over the nth annotation mapped to a PC in machine code, the VM also knows the nth annotated bytecode as well as its bytecode PC. This way, the bytecode PC annotation does not even need to encode the bytecode PC, it is found out each time by iterating over both versions of the method.

I hope you enjoyed the post.

September 18, 2016

Smalltalk Jobs - Smalltalk Jobs – 9/18/16

Three different jobs!  The first 2 are in Germany, one in Bonn and one in Berlin.

In Bonn they want a 10 week contract for PCV Server and Visual Age Smalltalk.  They would like you to start tomorrow, the 19th, of Sept. You need to be fluent in German.

In Berlin there are 4 positions and they want 5 years of Smalltalk and at least German reading ability. It looks to be a long term contract of at least 2 years, and, might be permanent.

Finally in Amsterdam there is a position for Smalltalk in Banking.    You must speak Dutch and you will lead a team.


Filed under: Employment

September 17, 2016

Joachim Tuchel - Zürich Smalltalk Meetup, Nov. 8, 2016?

It’s been almost a year since the Zürich Smalltalk users met. What a pity. So I’d like to get the ball rolling to gather interested Smalltalkers to meet on Tuesday, November 8, 2016. If you are interested, drop me a note or mail and I’ll keep everybody updated on the exact time and place. Where […]

September 16, 2016

Cincom Smalltalk - Zürich Smalltalkers Meeting

Since the Zürich Smalltalkers had so much fun the last few times they’ve gotten together, they have decided that it would be a shame to miss an opportunity to reconvene.

The post Zürich Smalltalkers Meeting appeared first on Cincom Smalltalk.

September 14, 2016

Adriaan van Os - Photos from the 2016 ESUG Conference in Prague

The now complete set of photos from the 2016 ESUG Conference in Prague is here.

24th ESUG Conference, Prague, 2016

September 13, 2016

Torsten Bergmann - Moldable Tools Book

A book about Moldable tools (in Pharo) is available from Lulu.

Torsten Bergmann - ERP in Smalltalk

September 12, 2016

Torsten Bergmann - ST-76 on top of Alto Emulator on top of JS in a webbrowser

Torsten Bergmann - ST-76 on top of Alto Emulator on top of JS in a webbrowser

Pharo Weekly - Metronomic attitude… systematic enh

19075 SmallLint tests failing after update
19055 More iconNamed: cleaning
19067 Wrong emphasis code for struck and narrow

19061 Move some of rules to new architecture & improve

19066 subclassDefinerClass needs to return Smalltalk compilerClass
19065 Symbol>>#asMethodPreamble isBroken

17879 Wrong example or code in Generator class comment

19063 Factory for RBModel classes

19047 fix vmstats report for spur

19056 Trait Polymorphism tests fail again

19052 rub shoutdecorator should not raise a debugger

19054 QA 3.2.7
19054 QA 3.2.7

19050 Copying a class doesnt replicate the pool dictionary definitions

19044 DebugAction should use key-mappings and not characters to indicate shortcuts

19048 move testZipped to Compression-Tests

19046 SUnit watch dog should not signal error when test environment is not active like during debugger

19028 Process ondo method to inject default exception handlers

18974 A Nautilus fix to support class method tests
19042 QA 3.2.6

19043 UnlimtedIvar slot: fix a #name deprecation side effect
18983 Kommitter is not working when invoked from Versionner

18859 Loading a package break word selection on Windows
19030 SystemAnnouncer restoreAllNotifications produces memory leak

19006 Add support for the file sync primitive to the FileSystem API

19001 Another pass to introduce iconNamed: and avoid Smalltalk ui icons

19002 iconNamed: in Catalog Browser

19015 Tests should never hang and leave forked processes live

18606 MessageBrowser should use fast table and provide filter field

19034 Improve comment of round:
19014 Autodeprecation creates a DoIt method on UndefinedObject

19029 SystemAnnouncer allInstances size = 2

19027 minimal Pharo build failing
19021 RB forgets to unmark removedClasses

10025 MethodDictionary at:put: and #flushCache
18859 Loading a package break word selection on Windows

18930 Regression: Time to show big methods is too high

19020 add preUnload message to Manifest

19022 asClass rules

18827 Mirror primitives should be easy to use

19019 Inexactitude in Dictionary class>> newFromPairs: comment

18950 CritiqueBrowser: Compiler error when accepting a method with argument

18992 asClass in font related package

18988 FreeTypeFontProvider should calculate correctly the directories where to look for fonts.

18974 A Nautilus fix to support class method tests

18991 asClass in RPackageTest

18989 asClass in BlueInk

19011 Integrate two double quotes inside comments

18033 Fraction isPowerOfTwo does too much work

19012 Added rules for icons

19013 Semaphore wait protocol based on duration

19005 Collection>>#ifEmpty: has useless return and wrong comment

18990 Text missing #includesSubstring: and includesSubstring:caseSensitive:

– case 18965 (removed GTExample)

– case 18596
Remove references from Glamour to Smalltalk evaluate:

– case 18948
remove a direct reference to Compiler from GT tests

– case 18923
inspector: improve “list methods using this variable”

– case 18905
cleanup #withThorougMethodsReferTo:do:

Pharo Weekly - Integrations in Pharo for next generation VMs

Hi everyone,

With the help of multiple people (Marcus Denker, Eliot Miranda and some more), I introduced over the past year multiple changes in the Pharo image to support the next generation VMs. It’s still a work in progress, but once issue 19083 will be introduced the bulk of the changes will be in the Pharo image.
These changes have no impact on developers only reading/writing source code and analysing/working with the ASTs, but may have impact with people working with Opal’s IR, the bytecode or directly with the BlockClosure and CompiledMethod instances (People building frameworks like Reflectivity, using OpalCompiler extensions or people working on object serializers).
Three main changes were introduced:
– Secondary bytecode set support
– Read-only objects
– FullBlockClosure
The secondary bytecode set support allows the image to run on a VM supporting 2 bytecode sets. Each compiled method has a flag precising which set it uses. This change allows the image to convert all the methods from one bytecode set to another one without any bootstrap (only in-image do-its). The SistaV1 bytecode set was introduced as the second bytecode set. This bytecode set removes many encoding limitations of the existing bytecode set, simplifies bytecode decoding and features new instructions (such as full block closure instructions).
Read-only objects allows one to mark any object as read-only. Any attempt to mutate a read-only object (primitive operations, instance variable store) fails, and the programmer can handle the failures with Smalltalk code. This feature is present with less than 1% overhead in all of our benchmark suite. In the near future, we plan to have all literals read-only to allow more aggressive compiler optimizations and avoid literal mutation inconsistency bugs. This feature can also be used to build efficient object modification trackers and could be used to improve the performance of part of the Reflectivity framework. It may break your code if you mutate literals (Normally you don’t).
FullBlockClosures are a new implementation of BlockClosures. They allow efficient implementation of Blocks, with the Copying block and Clean block optimizations present in other Smalltalks. They simplify part of the VM, making Blocks more similar to methods. They also remove many dependencies between BlockClosure, compiled method and contexts, which will allow us to implement more aggressive optimizations in the VM in the future. With FullBlockClosures, the closure’s bytecode is present in a separate object (an instance of compiled block) instead of being inlined in the enclosing method. This is still confusing some tools. The debugging support of FullBlockClosure seems however to be complete.
With the issue 19083 integrated and the latest VM compiled with different settings than the current Pharo VM (MULTIPLEBYTECODESETS true bytecodeTableInitializer initializeBytecodeTableForSqueakV3PlusClosuresAndSistaV1 -DIMMUTABILITY 1), all these features seems to be working in the Pharo image. The goal is to get all of these features used by default before the Pharo 6 feature freeze in November. Alternatively I will need to wait many more months (or Pharo will get unstable and Esteban will scream at me ‘No do not integrate that’).
If you worry how any of these changes can impact your frameworks, please answer this thread so we can analyse the potential problems.

Bob Nemec - A year goes by...

September 14, 2015, we launched a new ERP system, written in Smalltalk, running on GemStone and developed with VisualWorks. The system continues to grow, we keep adding features, and our users are mostly happy. 

It got me thinking about my relationship with the company and the project.

Projects have tension between the technical and business needs. The person paying the bills makes the final call and they are being asked to take a leap of faith; they don't see what the developers see. It takes time to build up trust, yet most of the key decisions, like which technology to use, are made at the start of the project, long before the technical team is truly trusted. 

In our case we got a lot right: use Smalltalk to deal with unique and complex business needs, use GemStone as the database to avoid the cost of object to relational mapping, use a web interface to avoid fat client issues, and use Seaside to allow for a single technology stack (we're Smalltalk all the way down). 

We got a few things wrong. The worst was thinking that an old fat client framework was worth keeping. It wasn't, and I strongly argued against it. But that's a tough call for someone that is not familiar with the code. They see a sunk cost. How could it not have value?  

Over time everyone realized just how bad the old framework was, but by then we had invested a lot of time and effort making the domain code run in a new web framework. We're still struggling to remove the last bad bits. But I can see the risk management decision on this: it was scary to agree to throw away the old code and move to something new and unproven. It's self evident now; it wasn't then.  

But it made me think: just how relevant is the technology decision, like which language or framework to use? Our users don't care. They need tools to do their job. Management doesn't care. They want IT to provide services at minimal cost. As a Smalltalk team we're very efficient. But so what? A java team would be easier to staff. Development would take longer, but they could get temporary help up to speed quickly to help get over humps. Technical consultants would actually be helpful (virtually none of the ones we've worked with knew Smalltalk).

And it's a general problem to anyone advocating an unconventional technology. Business might invest in a Smalltalk project if they see a return on investment, and if the risk is acceptable. But selling that vision in a world of deafening silence about Smalltalk is tough.

I haven't lost faith. Using Smalltalk allows us to be flexible in ways other teams could only dream of. Things will get a lot better, once we've scraped off the last of the old framework and are able to focus all of our time on building new stuff. I see a future where the development team is seen as a partner is the business. Where our ability to see business patterns and user flows gives us a voice.  Where we're not just a cost of doing business.

That's my vision: that Smalltalk projects allow the developers to be partners in the business, since they don't need to wallow in technical minutiae. They can stay in the business head space, so they can add value beyond the code. I see that happening in our project, and I think it's an important part of the story when advocating for Smalltalk.

I am looking forward to the next year.

Simple things should be simple. Complex things should be possible.

Torsten Bergmann - Integrations in Pharo for next generation VMs: FullBlockClosure, SistaV1 bytecode set and Read-only objects

There are already multiple changes in the Pharo image to support the next generation VMs. Read more and give feedback to Clément if you see any issues coming up.