Planet Squeak

blogs about Squeak, Pharo, Croquet and family
planet squeak - planet squeak es - planet squeak jp - planet croquet - planet squeak code - planet smalltalk

May 29, 2016

Torsten Bergmann

Glorp for Pharo

Glorp (the Smalltalk ORM framework) for Pharo was updated

by Torsten (noreply@blogger.com) at May 29, 2016 07:41 PM

Pharo in use - Sorabito

The largest asian online market place for big machines developed by Sorabito Inc in Pharo

by Torsten (noreply@blogger.com) at May 29, 2016 06:47 PM

May 27, 2016

Torsten Bergmann

Epicea in Pharo 6

Epicea is now integrated into Pharo 6.

by Torsten (noreply@blogger.com) at May 27, 2016 01:18 PM

Who uses Smalltalk

A new article from Richard Eng on who uses Smalltalk.

There are many people and projects all over the world who use Smalltalk. And yes it is true that mostly new projects start in more "fashioned" languages like Java. So this is more a question about how well known Smalltalk is and about popularity. There is also this common misbelief that new technologies must be better out of the box. I have some doubts in that - because today many software technologies or languages are very specific, written in a hurry or lack a solid and stable engineering foundation.

My answer to the question on who uses Smalltalk would be much easier: anyone who is interested in clean OO solutions and knowledgable enough to value increased productivity and long term maintainability.

by Torsten (noreply@blogger.com) at May 27, 2016 01:09 PM

Pharo Newsletter

There is a low traffic “Pharo Newsletter” Mailinglist. If you want to join read here.

by Torsten (noreply@blogger.com) at May 27, 2016 06:17 AM

May 25, 2016

Torsten Bergmann

Visualize Commit History

for Pharo in Pharo. Read more.

by Torsten (noreply@blogger.com) at May 25, 2016 11:33 AM

GitRepositoryScanner

A small tool to show local FileTree repositories in GTSpotter, as a way to add them into repositories list. Read more.

by Torsten (noreply@blogger.com) at May 25, 2016 06:30 AM

Panama Papers: a case for reproducible research, data activism and frictionless data

Want to step into the details of the Panama leak using Pharo? Then continue reading here.

by Torsten (noreply@blogger.com) at May 25, 2016 06:15 AM

May 24, 2016

Torsten Bergmann

Pharo 64 bit in preparation

Pharo 64 bits image on 64 bits VM running on Mac & Linux. Yay!!! Read more.

by Torsten (noreply@blogger.com) at May 24, 2016 02:08 PM

May 23, 2016

Göran Krampe

Spry Performance

When writing Spry I am so far mainly ignoring performance. The general execution of Spry code will be a regular interpreter (although stackless I hope) and not a JIT. But that doesn't prevent us from playing around and learning something!

In this article I do some silly experiments around interpreter startup time and fooling around with 40 million element arrays. As usual, I am fully aware that the languages (Pharo Smalltalk, NodeJS, Python) I compare with a) have lots of other ways to do things b) may not have been used exactly as someone else would have done it. A truck load of salt required. Now... let's go!

Startup time

Spry is pretty fast starting up which obviously has to do with Spry not doing much at all when starting :)

So a trivial hello world being run using hashbang, executed 1000 times from another bash script, takes substantially less time than the same in Python. Useful benchmark? Not really, but obviously we can do scripting with Spry and at least not paying much for startup times! Here are the two trivial scripts and the bash script running them 1000 times:

``` bash

!/usr/bin/env spry

echo "Hello world" ```

``` bash

!/usr/bin/env python

print "Hello World" ```

``` sh

!/bin/bash

Run a trivial hashbang Spry script 1000 times

for run in {1..1000} do ./hello.sy done ```

If we run the above, first for hello.sy and then hello.py, as reported by time: ``` bash

Spry

real 0m4.071s user 0m0.740s sys 0m0.428s

Python

real 0m13.812s user 0m8.904s sys 0m2.324s

Empty shell script for comparison

real 0m2.505s user 0m0.024s sys 0m0.176s ```

Hum! So a trivial Spry script is 3-10x quicker depending on what you count (real clock vs cpu time etc), and... no, it's not output to stdout that is the issue, even a "silent" program that just concatenates "hello" with "world" suffers similarly in Python.

We can of course also compile this into a binary by embedding the Spry source code in a Nim program - it's actually trival to do. The 5th line below could of course be a full script. Since the Spry interpreter is modular we can pick some base modules to include, in this case the IO module is needed for echo to work so we add it to the interpreter on line 3:

nimrod import spryvm, modules/spryio let spry = newInterpreter() spry.addIO() discard spry.eval """[ echo "Hello World" ]""" ..and then we build a binary using nim c -d:release hello.nim and if we run that instead from the same bash loop we get: real 0m0.840s user 0m0.028s sys 0m0.096s

Of course Python can do lots of similar tricks, so I am not making any claims! But still very neat. And oh, we didn't even try comparing to Pharo here :) Startup times is definitely not a strength of Smalltalk systems in general, typically due to lack of minimal images etc.

40 million ints

I wanted to create some fat collection and do some loops over it. Spry has a universal ordered collection called a Block. Smalltalk has it's workhorse OrderedCollection. Nodejs has an Array. Let's stuff one with 40 million integers and then sum them up!

NOTE: The first numbers published were a bit off and I also realized an issue with Cog and LargeIntegers so this article is adjusted.

Pharo 4 with the Cog VM:

NodeJS 4.4.1:

Python 2.7.10:

Spry:

Spry with activation record reuse:

Ehum...

NOTES

If we spend some time profiling Spry we can quickly conclude that the main bottleneck is the lack of a binding phase in Spry - or in other words - every time we run a block, we lookup all words! Unless I am reading the profile wrong I think the endless lookups make up almost half the execution time. So that needs fixing. And I also will move to a stackless interpreter down the line, and that should give us a bit more.

And what about Python's sum function that did it in whopping 0.3 seconds? Yep, definitely the way to go with an optimized primitive function for this, which brings me to...

Spry Secret Weapon

The secret weapon of Spry!

One core idea of Spry is to make a Smalltalk-ish language with its inner machinery implemented in Nim using Nim data types. So the collection work horse in Spry, the block is just a Nim seq under the hood. This is very important.

Combined with a very simple way of making Nim primitives we can quickly cobble up a 6 line primitive word called sum that will sum up the ints in a block. We simply use the fact that we know the block consists only of integers. I am guessing the sum function of Python does something similar.

Here is the code heavily commented:

```

nimPrim is a Nim macro to make Spry primitives

First argument is the word to bind, second is if

this is an infix word (first argument on the left)

and finally how many arguments the primitive expects.

nimPrim("sum", true, 1): # The local variable spry refers to the Interpreter # evalArgInfix(spry) is a function call that returns # the infix argument evaluated at the call site. # We then cast this to a SeqComposite which is the # abstract super type of Blocks. let blk = SeqComposite(evalArgInfix(spry)) var sum = 0 # This is Nim iteration over the nodes member # of the SeqComposite, a seq of Nodes. for each in blk.nodes:

# We cast the node to IntVal since we know
# it's an int, and then we can get the value member
# which is a regular Nim int.
sum = sum + IntVal(each).value

# All Spry functions returns Nodes so we wrap the int # as a Node using newValue() which will wrap it as an # IntVal. return newValue(sum) ``` It's worth noting that almost all primitive words in Spry are written using this same pattern - so there are lots of examples to look at! Of course this is a bit of "cheating" but it's also interesting to see how easy it is for us to drop down to Nim in Spry. We create a new word bound to a primitive function in exactly 6 lines of code.

So how fast is Spry using this primitive word? It sums up in blazing 0.15 seconds, about 100x faster than Cog and 10x faster than NodeJS for summing up. And yeah, even 2x faster than Python!

And yes, we can easily make this primitive smarter to handle blocks with a mix of ints and floats and a proper exception if there is something else in there - then it ends up being 17 lines of code, and still almost as fast, 0.17-0.18 seconds! I love you Nim.

In summary, Cog - which is what I am most interested in comparing with - is fast but my personal goal is to get Spry within 5x slower in general speed - and that will be a good number for a pure interpreter vs an advanced JIT. And if we throw in primitive words - which is not hard - Spry can be very fast!

May 23, 2016 10:00 PM

May 22, 2016

Torsten Bergmann

Sysmocom

Free Software for Mobile Communication in Pharo. Read more.

by Torsten (noreply@blogger.com) at May 22, 2016 06:37 PM

May 21, 2016

Torsten Bergmann

HashIds

Generate short unique ids from integers also for Smalltalk. Read more

by Torsten (noreply@blogger.com) at May 21, 2016 11:52 AM

OpenSmalltalk virtual machine repo

The virtual machine used for open source Smalltalks like Squeak and Pharo is now moved from Subversion to GitHub.

Read about the details.

by Torsten (noreply@blogger.com) at May 21, 2016 01:04 AM

May 20, 2016

Torsten Bergmann

TokyoDB

I did not know yet about this project from Esteban:

TokyoDB is a Pharo wrapper for Tokyo Cabinet.

by Torsten (noreply@blogger.com) at May 20, 2016 09:52 AM

May 18, 2016

Torsten Bergmann

Pharo 6 development

As Pharo 5.0 is now available for download the work on Pharo 6.0 directly started. There are already nice things in the pipe like Immutability

by Torsten (noreply@blogger.com) at May 18, 2016 07:00 PM

Virtual Machines and Managed Runtimes

Want to learn about virtual machine programming? Then have a look here.

by Torsten (noreply@blogger.com) at May 18, 2016 06:47 AM

May 17, 2016

The Weekly Squeak

Virtual Machines and Managed Runtimes

DeutschInLineCache

Mario Wolczko writes:

In early 2015 I was honored to be invited to develop and present a graduate course on Virtual Machines at UC Berkeley. The result is CS294-113: Virtual Machines and Managed Runtimes, which was presented in the Fall of 2015.

This page contains the materials from that course. All materials are Copyright © Oracle and Mario Wolczko, 2015-6, except as noted. The materials can be used non-commercially under the following Creative Commons license:

Virtual Machines and Managed Runtimes

Acknowledgements

I’d like to express my thanks to the following:

 


by Ron Teitelbaum at May 17, 2016 10:02 PM

May 15, 2016

Torsten Bergmann

Pharo packages for ArchLinux

Pharo packages for ArchLinux

by Torsten (noreply@blogger.com) at May 15, 2016 04:49 PM

Stanford Seminar - Eliot Miranda and Clément Béra

Eliot and Clément discuss Sista at Stanford:


by Torsten (noreply@blogger.com) at May 15, 2016 11:01 AM

May 14, 2016

The Weekly Squeak

Eliot and Clément discuss Sista at Stanford

Excellent Description of Sista! Nice job Eliot and Clément!


by Ron Teitelbaum at May 14, 2016 01:41 AM

May 13, 2016

Göran Krampe

Spry vs Allen

Allen Wirfs-Brock wrote down a bullet list of what he thought actually made it possible for the Alan Kay team to create Smalltalk, and many other ground breaking things, at Xerox PARC in the 70s. Let's take a look at his bullets one by one and see how it applies to Spry and my puny little effort around it :)

Look 20 years into the future

That's obviously hard to do, but I am trying a little bit by questioning every little thing that many consider not being even relevant or possible to question. Some examples are:

Everyone is so busy "doing stuff" that noone takes the time to actually reflect. Can we really not create a development system in which I can see exactly what is going on? Is there really no more powerful ways to do debugging?

So I may not look into the future, but most good ideas come from someone doing something unexpected, weird, impossible or downright stupid. In Spry I want us to try a few of those :)

Extrapolate technologies

I don't really dare, but I think it's safe to say that Virtual Reality is probably going to be accessible everywhere. JavaScript has hopefully waned but leaving behind a new much lower threshold to programming being the norm, not the exception. Everyone wants to be able to program. Hardware is basically free, very capable and everywhere. People tend to think that the web is taking over everything, but I don't think its that simple - I think diversity is going to be much higher due to new companies creating new kinds of devices. Many more devices.

How does this affect choices in Spry? Well, I tend to not let performance considerations hinder various ideas. I also focus pretty hard on mobility of code and data, since I think we should be able to find a lot more models of computing in the area of distributed systems.

Finally I do think DSLs in different shapes or forms will play a big part in the future - so Spry should have excellent capabilities for that.

I also want Spry to be modular on most levels, while still being fairly simple.

Focus on people

The Smalltalk team was focused on user interfaces, education and children. With Spry "people" means primarily "developers".

I don't think 20 years will remove the need for writing code, but the pressure for fast results will be immensely higher. I also think the boundaries of computing will be much fuzzier and that we will need to have more advanced tools to create and mold code into doing what we want. Things will run on many devices, distributed in novel ways reaching places in our lives we can not really imagine.

I want to create and modify systems live as they run, as they are being used. Not just run locally, or as prototypes, but as they run live in deployment. Continuous deployment will probably evolve into 100% live online development. How will that affect developers? What tools do we need? How can we evolve a live system with confidence?

This implies we will have to create much more powerful ways to create, debug and modify code. We need to raise the abstraction levels, but perhaps a key to that is to create a homoiconic language that lends itself to introspection and self reference. Smalltalk didn't do that (only to some extent), nor did JavaScript. The Lisp family of languages did to some extent, but for various reasons never really took off. Hard to say why.

Create a vision

One vision is a globally shared live system of cooperating Spry objects. Like GemStone/S but on a global scale, and taken even further to the extreme. Today developers share code - dead code - via various package catalogs and copy/paste forums. The SaaS and PaaS etc are trying to create shared platforms, but it's still very much centered around the same coding model where we don't share actual functionality, but merely code and libraries to recreate the functionality on our own.

To be concrete - instead of downloading a library and create a small service that consumes a live feed of data and produces a stream of Spry objects, in Spry we would find not a library, but a live running existing service that we just hook into. The module is not dead code, but actually a live and running service.

This is homoiconicity driven all the way! During the years sharing of objects have been tried via various RPC-ish standards like CORBA or RMI, but those standards have always revolved around static early binding and separate specifications and have thus later been completely run over by late binding self describing technologies like REST-ful APIs using JSON and similar "soft" formats. Late binding and self description is key for how modern development is done to a large extent - experimentation.

Another vision is Spry being a language to serve as a new foundation for transferable portable active code. Kinda like a JavaScript that doesn't suck and that is homoiconic and thus easy to make tools for.

But in the end... I don't have any grand delusions about Spry - its all for fun and I just hope some of us will find it useful!

A Team of Dreamers and Doers

Obviously I don't have this. Yet. I hope that if I can make enough progress on my own - then people will join. And I stand on firm shoulders in the form of Nim which makes Spry suffering less of NiH (no pun intended). I hope that some Smalltalkers will eventually join, but I need a good solid language manual and perhaps even a reasonably interesting IDE to get any real traction.

Prototype the Vision

Spry has almost reached the point where we can start working on the fun stuff. The module system, serialization mechanisms and lossless AST improvements are all crucial steps towards this. Next step is getting the OO model working and do the Sophia integration to get a working image based system. After that I suspect its time to make a first IDE. I do have some plans and ideas for that too :)

Live Within the Prototype

I think this is definitely important. The existing REPL is just a crude first trivial step. But it will get better!

Make It Useful to You

I personally want to apply Spry in the domains of VR and IoT. Web systems is no longer that interesting to me, but if someone would like to evolve Spry compiled to js - I would be very grateful.

Amaze the World

Hopefully, eventually! :)

May 13, 2016 10:00 PM

May 12, 2016

The Weekly Squeak

Squeak in Action

squeak in action

Chris Muller posted:

The mission-control app I’ve been working on this year appeared in a special episode of CBBC Newsround yesterday!

http://www.bbc.co.uk/newsround/36247103

The segment about Reserve Protection Agency with several screenshots of the app begins at time index 9:40 and runs until 12:25.  I recommend watching the entire episode, though, it’s a worthwhile message.

No one will know it is powered by Squeak but that’s okay, the important message is the one about the danger faced by rhinos as a species.


by Ron Teitelbaum at May 12, 2016 09:12 PM

Torsten Bergmann

Pharo 5.0 - RELEASE

Lots of work in all the details for each member of our Pharo community - but now Pharo 5.0 is pushed out of the door. Great!!!

by Torsten (noreply@blogger.com) at May 12, 2016 04:05 PM

AstaresDistribution of Pharo

I assembled some of my free goodies for Pharo into a Pharo distribution called "AstaresDistribution".

If you use PharoLauncher you can easily load it. The image is available on the Pharo Contribution CI server.

by Torsten (noreply@blogger.com) at May 12, 2016 06:32 AM

Pharo 5.0 - soon

Pharo 5.0 is still in preparation - but you can already try before the final release step.

by Torsten (noreply@blogger.com) at May 12, 2016 06:23 AM

May 09, 2016

Torsten Bergmann

IWST 2016 - Call for Papers

International Workshop on Smalltalk Technologies (IWST) 2016 Call for papers

by Torsten (noreply@blogger.com) at May 09, 2016 04:03 PM

May 08, 2016

Torsten Bergmann

Seaside 3.2.0

Seaside 3.2.0 is now final

by Torsten (noreply@blogger.com) at May 08, 2016 12:48 PM

Changing source code from tests

Nice article on changing source code from tests.

by Torsten (noreply@blogger.com) at May 08, 2016 12:27 PM

Parasol

Parasol is a Pharo Smalltalk framework to automate web browsers. It's particularly useful to write automated tests for Seaside web applications. Its design and implementation are based on the Java Selenium WebDriver API.

by Torsten (noreply@blogger.com) at May 08, 2016 12:26 PM

May 05, 2016

Tony Garnock-Jones

Our operating systems are incorrectly factored

Unix famously represents all content as byte sequences. This was a great step forward, offering a way of representing arbitrary information without forcing an interpretation on it.

However, it is not enough. Unix is an incomplete design. Supporting only byte sequences, and nothing else, has caused wasted effort, code duplication, and bugs.

Text is an obvious example of the problem

Consider just one data type: text. It has a zillion character sets and encoding schemes. Each application must decide, on its own, which encoding of which character set is being used for a given file.

When applications get this wrong, both obvious bugs like Mojibake and subtler flaws like the IDN homograph attack result.

Massive duplication of code and effort

Lack of system support for text yields massive code duplication. Rather than having a system-wide, comprehensive model of text representation, encoding, display, input, collation, and comparison, each programming language and application must fend for itself.

Because it is difficult and time consuming to properly handle text, developers tend to skimp on text support. Where a weakness is identified, it must be repaired in each application individually rather than at the system level. This is itself difficult and time consuming.

Inconsistent treatment

Finally, dealing only with byte sequences precludes consistent user interface design.

Consider a recent enhancement to Thunderbird, landing in version 45.0. Previously, when exporting an address book as CSV, only the “system character set” was supported. Now, the user must specify which character set and encoding is to be used:

Illustration from the Thunderbird 45.0 release notes

The user cannot simply work with a file containing text; they must make a decision about which encoding to use. Woe betide them if they choose incorrectly.

A consistent approach would separate the question of text encodings entirely from application-specific UIs. System UI for transcoding would exist in one place, common to all applications.

User frustration

A tiny fraction of the frustration this kind of thing causes is recorded in Thunderbird’s bug 117236.

Notice that it took fourteen years to be fixed.

Ubiquitous problem

This Thunderbird change is just one example. Each and every application suffers the same problems, and must have its text support repaired, upgraded, and enhanced independently.

It’s not only a Unix problem. Windows and OS X are just as bad. They, too, offer no higher-level model than byte sequences to their applications. Even Android is a missed opportunity.

Learn from the past

Systems like Smalltalk, for all their flaws, offer a higher-level model to programmers and users alike. In many cases, the user never need learn about text encoding variations.

Instead, the system can separate text from its encoding.

Where encoding is relevant to the user, there can be a single place to work with it. Contrast this with the many places encoding leaks into application UIs today, just one of which is shown in the Thunderbird example above.

It’s not just text

Text is just one example. Pictures are another. You can probably think of more.

Our operating systems do not support sharing of high-level abstractions of data between documents or applications.

An operating system with a mechanism for doing so would take a great burden off both programmers and users.

Let’s start thinking about what a better modern operating system would look like.

by tonyg at May 05, 2016 07:48 PM