Planet Squeak

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

July 25, 2016

Torsten Bergmann

Pharo Kiosk system

Pharo 1.1 was used to build ATM-kind software in Russian Bank. Such devices could be found in Moscow streets. Here is a sample video:


by Torsten (noreply@blogger.com) at July 25, 2016 08:49 AM

July 24, 2016

Torsten Bergmann

Towards 64 Bit VMs

Nicolas has finally compiled a 64bits VM for windows - and now the OpenSmalltalk VM has makefiles for 64 bits windows. Cool!

by Torsten (noreply@blogger.com) at July 24, 2016 07:52 PM

A taste of bootstrap

With Smalltalks image approach you save the whole state of your "object oriented world" to disk and continue later at the same point of execution where you left. Some objects are part of the standard image since the 1970s which makes Smalltalk images software artefacts that are maintained since a long time.

Other Smalltalks (like Amber) work without images and bootstrap right from the beginning (like Amber which is a Smalltalk running on top of JavaScript).

Nonetheless it also makes sense to bootstrap new images right from the start and (as I already reported) the Pharo community is working on that. Now there is yet another step done for this as you can read and now also try here.

Note that the boostrapped image is already in Spur format.

by Torsten (noreply@blogger.com) at July 24, 2016 07:34 PM

Pillar 4.0.0

New update on Pillar for Pharo. Now also with an ePub exporter. Nice!

by Torsten (noreply@blogger.com) at July 24, 2016 07:15 PM

Seamless (0.8.2)

A new update for Seamless is available.

by Torsten (noreply@blogger.com) at July 24, 2016 03:32 PM

ObjectTravel

A tool to traverse object references for Pharo. Read more.

by Torsten (noreply@blogger.com) at July 24, 2016 03:31 PM

JSONWebToken for Pharo

JWT (JSONWebToken) is a token format suitable for authentication and authorization. Read about the Pharo implementation.

by Torsten (noreply@blogger.com) at July 24, 2016 03:31 PM

Freewill - GA framework for Pharo

Freewill is the name of the genetic algorithm framework for Pharo. Read more here or see it in action here.

by Torsten (noreply@blogger.com) at July 24, 2016 03:26 PM

July 21, 2016

Torsten Bergmann

Remote Debugging Tools for Pharo

A first version of RemoteDebuggingTools project. It allows explore and debug remote images. Read more

by Torsten (noreply@blogger.com) at July 21, 2016 07:17 AM

OpenGLES2 binding for Pharo

is available. Read more.

by Torsten (noreply@blogger.com) at July 21, 2016 07:13 AM

How learning Smalltalk can make you a better developer

TechBeacon published an article Richard Eng wrote about Smalltalk

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

July 18, 2016

Göran Krampe

Is Spry a Smalltalk?

I love Smalltalk and I have been in love with it since approximately 1994. I have used VisualWorks, VisualAge (IBM Smalltalk), Dolphin Smalltalk, GemStone, Squeak and Pharo quite a lot, and I was very active in the Squeak community for a long period.

But the last few years, finally, I have started to feel the "burn"... as in "Let's burn our disk packs!". And last year I started doing something about it - and the result is Spry. Spry is only at version 0.break-your-hd and several key parts are still missing, but its getting interesting already.

Now... is Spry a Smalltalk? And what would that even mean?

I think the reason I am writing this article is because I am feeling a slight frustration that not more people in the Smalltalk community find Spry interesting. :)

And sure, who am I to think Spry is anything remotely interesting... but I would have loved more interest. It may of course change when Spry starts being useful... or perhaps the lack of interest is because it's not "a Smalltalk"?

Smalltalk family

The Smalltalk family of languages has a fair bit of variation, for example Self is clearly in this family, although it doesn't even have classes, but it maintains a similar "feel" and shares several Smalltalk "values". There have been a lot of Smalltalks over the years, even at PARC they made different variants before releasing Smalltalk-80.

So... if we look at Spry, can it be considered a member of the Smalltalk family?

There is an ANSI standard of Smalltalk - but not many people care about it, except for some vendors perhaps. I should note however that Seaside apparently (I think) has brought around a certain focus on the ANSI standard since every Smalltalk implementation on earth wants to be able to run Seaside and Seaside tries to enforce relying on the ANSI standard (correct me if I am wrong).

Most Smalltalk implementations share a range of characteristics, and a lot of them also follow the ANSI standard, but they can still differ on pretty major points.

My personal take on things in Smalltalk that are pretty darn important and/or unique are:

  1. Everything is an object including meta levels
  2. A solid model for object oriented programming
  3. The image model
  4. 100% live system
  5. The browser based IDE with advanced cross referencing, workspaces and debuggers
  6. The keyword syntax and message cascades
  7. Message based execution model
  8. Dynamic typing and polymorphism
  9. Closures everywhere with lightweight syntax and non local return
  10. Very capable Collections and a good standard library

Not all Smalltalks cover all 10. For example, there are several Smalltalks without the image model and without a browser based IDE. Self and Slate and other prototypical derivatives don't have classes. Some Smalltalks have much less evolved class libraries for sure, and some are more shallow in the "turtle department".

In Spry we are deviating on a range of these points, but we are also definitely matching some of them!

How Spry stacks up

  1. Everything is an object including meta levels. No, in Spry everything is an AST node, not an object. A similar feel of uniformity exists, but it's different.
  2. A solid model for object oriented programming. Yes I think so, but Spry does not use the classic class model but is experimenting with a functional OO model.
  3. The image model. No, not yet. But the idea is to have it, not on a binary "memory snapshot" level, but in a more fine granular way.
  4. 100% live system. Yes, Spry is definitely 100% live and new code is created by running code etc.
  5. The browser based IDE with advanced cross referencing, workspaces and debuggers. No, but eventually I hope Spry gets something similar. First step is making a UI binding and evolving the meta programming mechanisms.
  6. The keyword syntax and message cascades. Yes, Spry has keyword syntax, but also has prefix syntax and currently no cascades nor statement separators.
  7. Message based execution model. No, Spry execution is not message based, but rather functional in nature. The practical difference should be slim to none I hope.
  8. Dynamic typing and polymorphism. Yes, Spry is dynamically typed and offers polymorphism, but through a different technique.
  9. Closures everywhere with lightweight syntax and non local return. Yes, closures with non local return, similar pervasiness, even more light weight syntax than Smalltalk!
  10. Very capable Collections and a good standard library. No, not yet. But intend to have it and will in many ways try to pick the best from Smalltalk and Nim.

So Spry scores 5/10. Not that shabby! And I am aiming for 3 more (#3, #5, #10) getting us up to 8/10. The two bullets that I can't really promise are #1 and #7, but I hope the alternative approach in Spry for these two bullets still reaches similar effects.

Let's look at #1, #2 and #6 in more detail. The other bullets can also be discussed, but ... not in this article :)

Everything is an object including meta levels

In Smalltalk everything is an object, there are no "fundamental datatypes". Every little thing is an instance of a class which makes the language clean and powerful. There are typically some things that the VM treats differently under the hood, like SmallInteger and BlockClosure etc, but the illusion is quite strong.

Spry on the other hand was born initially as a "Rebol incarnation" and evolved towards Smalltalk given my personal inclination. Rebol as well as Spry is homoiconic and when I started building Spry it felt very natural to simple let the AST be the fundamental "data is code and code is data" representation. This led to the atomic building block in Spry being the AST Node. So everything is an AST node (referred to as simply "node" hence on), but there are different kinds of nodes especially for various fundamental datatypes like string, int and float and they are explicitly implemented in the VM as "boxed" Nim types.

In Smalltalk objects imply that we can refer to them and pass them around, they have a life cycle and are garbage collected, they have an identity and they are instanciated from classes which describes what messages I can send to them.

In Spry the same things apply for nodes, except that they are not instanciated from classes. Instead nodes are either created by the parser through explicit syntax in the parse phase, or they are created during evaluation by cloning already existing ones.

An interesting aspect of Spry's approach is that we can easily create new kinds of nodes as extensions to the Spry VM. And these nodes can fall back on types in the Nim language that the VM is implemented in. This means we trivally can reuse the math libraries, string libraries and so on already available in Nim! In essence - the Spry VM and the Spry language is much more integrated with each other and since the VM is written in Nim, Nim and Spry live in symbiosis.

Using Spry it should be fully normal and easy to extend and compile your own Spry VM instead of having to use a downloaded binary VM or learning Black Magic in order to make a plugin to it, as it may feel in the Squeak/Pharo world.

Finally, just as with Smalltalk the meta level is represented and manipulated using the same abstractions as the language offers.

Conlusion? Spry is different but reaches something very similar in practice.

A solid model for object oriented programming

But what kind of behaviors are associated with a particular node then? In Spry I am experimenting with a model where all nodes can be tagged and these tags are the basis for polymorphism and dynamic function lookup. You can also avoid tagging and simply write regular functions and call them purely by name, making sure you feed them with the right kind of nodes as arguments, then we have a pure functional model with no dynamic dispatch being performed.

In Spry we have specific node types for the fundamental datatypes int, float, string and a few other things. But for "normal" objects that have instance variables we "model objects as Maps". JavaScript is similar, it has two fundamental composition types - the "array" and the "object" which works like a Map. In Spry we also have these two basic structures but we call them Block and Map. This means we can model an object using a Map, we don't declare instance variables - we just add them dynamically by name to the map.

But just being a Map doesn't make an object - because it doesn't have any behaviors associated with it! In Smalltalk objects know their class which is the basis for behavior dispatch and in Spry I am experimenting with opening up that attribute for more direct manipulation, a concept I call tags:

  1. Any node can be tagged with one or more tags.
  2. Functions are also nodes and can thus also be tagged.
  3. A polyfunc is a composite function with sub functions.
  4. A polyfunc selects which sub function to evaluate based on comparing tags for the first argument, the "receiver" with the tags for the sub functions.

The net effect of this is that we end up with a very flexible model of dispatch. This style of overloading is a tad similar to structural pattern matching in Erlang/Elixir.

One can easily mimic a class by associating a bunch of functions with a specific tag. The tags on a node have an ordering, this means we also get the inheritance effect where we can inherit a bunch of functions (by adding a tag for them) and then override a subset using another tag - by putting that tag first in the tag collection of the node. Granted this is all experimental and we will see how it plays out. It does however have a few interesting advantages over class based models:

  1. Tags are dynamic and can be added/removed/reordered during the life cycle of an object.
  2. Tags have no intrinsic relations to each other, thus multiple inheritance in various ways works fine.
  3. Polyfuncs are composed dynamically which makes it easy to extend existing modules with new behaviors (like class extensions in Smalltalk).

I am just starting to explore how this works, so the jury is still out.

The keyword syntax and message cascades

Spry supports infix and prefix functions and additionally keyword syntax using a simple parsing transformation. The following variants are available:

```

Function call with zero arguments.

Well, we are in fact referring to whatever is bound to the name "root"

and evaluating it - and if it is indeed a func then it will be called.

This happens to be a Spry primitive func that returns the Map holding the

root bindings, essentially the same as "Smalltalk" in Smalltalk.

root

Prefix function call with one argument.

echo "Hey"

Prefix function call with two arguments. I am experimenting with different

styles of conditionals in Spry, Smalltalk style is also doable.

if (3 < 4) [echo "yes"]

Infix function call with one argument.

[1 2 3] size

Infix function call with two arguments. In Spry this is currently not limited

to a specific subset of characters like binary messages in Smalltalk.

3 + 4

Infix function call with three arguments, keyword style.

Parser rewrites this as "[1] at:put: 0 2" and since ":" is a valid character

in a Spry name, it will simply run that func.

[1] at: 0 put: 2

Infix function calls with 3 or more arguments do not need to use keyword style though,

foo here could be an infix function taking 4 arguments. Not good style though.

1 foo 3 4 5

Keyword style can be used for prefix functions too so

that there is no receiver on the left! Looks funky for a Smalltalker and I

am not yet certain it is a good idea.

loadFile: "amodule.sy" ```

This means Spry supports the classic Smalltalk messge syntax (unary, binary, keyword) in addition to prefix syntax which sometimes is quite natural, like for echo. Currently there is no syntactic support for cascades, but I am not ruling out the ability to introduce something like it down the road.

Conclusion

Spry is very different from Smalltalk and I wouldn't call it "a Smalltalk", but rather "Smalltalk-ish". I hope Spry can open up new exciting programming patterns and abilities we haven't seen yet in Smalltalk country.

Hope you like it!

July 18, 2016 10:00 PM

July 17, 2016

Torsten Bergmann

Magic with Pharo Reflectivity

Read this blog post from Denis Kudriashov on implementing an analogue of Dolphin Smalltalks ##() syntax

by Torsten (noreply@blogger.com) at July 17, 2016 08:04 PM

Smalltalks 2015 videos

are available

by Torsten (noreply@blogger.com) at July 17, 2016 10:28 AM

July 16, 2016

Torsten Bergmann

New Spec tutorial for Pharo

A new tutorial on Spec is coming.

by Torsten (noreply@blogger.com) at July 16, 2016 09:46 AM

Epidemiological models with Roassal

A draft chapter is available.

by Torsten (noreply@blogger.com) at July 16, 2016 09:45 AM

Live Twitter Analysis and Visualization with Pharo

by Torsten (noreply@blogger.com) at July 16, 2016 09:44 AM

July 07, 2016

Torsten Bergmann

DSL in Pharo

Building an external Domain specific language (DSL) with the help of an internal DSL. Using PetitParser in Pharo is easy as this picture proves.

by Torsten (noreply@blogger.com) at July 07, 2016 12:09 PM

Squeak on Slack

Squeak now also has a slack team.

by Torsten (noreply@blogger.com) at July 07, 2016 10:38 AM

July 05, 2016

Torsten Bergmann

Twitter data visualization with Pharo

Twitter data selfies: From Paper Mockup to digital prototype

by Torsten (noreply@blogger.com) at July 05, 2016 08:13 AM

June 29, 2016

The Weekly Squeak

PLATEAU – Evaluation and Usability of Programming Languages and Tools Call For Papers

Plateau

7th Workshop on the Evaluation and Usability of Programming Languages and Tools (PLATEAU)

Co-located with SPLASH 2016

Amsterdam, Netherlands

PLATEAU 2016

http://2016.splashcon.org/track/plateau2016

CALL FOR PAPERS

Programming languages exist to enable programmers to develop software effectively. But how efficiently programmers can write software depends on the usability of the languages and tools that they develop with. The aim of this workshop is to discuss methods, metrics and techniques for evaluating the usability of languages and language tools. The supposed benefits of such languages and tools cover a large space, including making programs easier to read, write, and maintain; allowing programmers to write more flexible and powerful programs; and restricting programs to make them more safe and secure.

PLATEAU gathers the intersection of researchers in the programming language, programming tool, and human-computer interaction communities to share their research and discuss the future of evaluation and usability of programming languages and tools.

TOPICS

Some particular areas of interest are:

PLATEAU encourages submissions of three types of papers:

Research and position papers: We encourage papers that describe work-in-progress or recently completed work based on the themes and goals of the workshop or related topics, report on experiences gained, question accepted wisdom, raise challenging open problems, or propose speculative new approaches. We will accept two types of papers: research papers up to 8 pages in length; and position papers up to 2 pages in length.

Hypotheses papers: Hypotheses papers explicitly identify beliefs of the research community or software industry about how a programming language, programming language feature, or programming language tool affects programming practice. Hypotheses can be collected from mailing lists, blog posts, paper introductions, developer forums, or interviews. Papers should clearly document the source(s) of each hypothesis and discuss the importance, use, and relevance of the hypotheses on research or practice. In addition, we invite language designers to share some of the usability reasoning that influenced their work. These will serve as an important first step in advancing our understanding of how language design supports programmers.Papers may also, but are not required to, review evidence for or against the hypotheses identified. Hypotheses papers can be up to 4 pages in length.

Submission site: PLATEAU papers should be submitted via HotCRP.

https://plateau2016.hotcrp.com/

Format: Submissions should use the SIGPLAN Proceedings Format (http://www.sigplan.org/Resources/Author/), 10 point font. Note that by default the SIGPLAN Proceedings Format produces papers in 9 point font. If you are formatting your paper using LaTeX, you will need to set the 10pt option in the \documentclass command. If you are formatting your paper using Word, you may wish to use the provided Word template that supports this font size. Please include page numbers in your submission. Setting the preprint option in the LaTeX \documentclass command generates page numbers. Please also ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes are legible.

All types of papers will be published in the ACM Digital Library at the authors’ discretion.

KEYNOTE

Alan Blackwell

Professor

Computer Laboratory

University of Cambridge

Cambridge, United Kingdom

http://www.cl.cam.ac.uk/~afb21/

DATES

Submission deadline: August 1, 2016

PROGRAM COMMITTEE

Kelly Blincoe, Auckland University of Technology, New Zealand

Jeff Carver, University of Alabama, USA

Kathi Fisler, Worcester Polytechnic Institute, USA

Tudor Gîrba, Independent, Switzerland

Stefan Hanenberg, University of Duisburg-Essen, Germany

Andrew Ko, University of Washington, USA

Brad Myers, Carnegie Mellon University, USA

Peter-Michael Osera, Grinnell College, USA

Janet Siegmund, University of Passau, Germany

Jeremy Singer, University of Glasgow, United Kingdom

Emma Söderberg, Google, USA

Andreas Stefik, University of Nevada, Las Vegas, USA

Ian Utting, University of Kent, United Kingdom

Philip Wadler, University of Edinburgh, United Kingdom

ORGANIZERS

Craig Anslow, Middlesex University, UK

Thomas LaToza, George Mason University, USA

Joshua Sunshine, Carnegie Mellon University, USA


by Ron Teitelbaum at June 29, 2016 12:02 AM

June 28, 2016

Torsten Bergmann

FullBlockClosures

From Blocks to BlockClosures now to FullBlockClosures. It is nice that Clément Béra summarizes current activities for Sista on his blog.

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

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.

by Torsten (noreply@blogger.com) at June 24, 2016 11:18 AM

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!!!


by Torsten (noreply@blogger.com) at June 24, 2016 08:21 AM

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.


by Torsten (noreply@blogger.com) at June 23, 2016 09:58 PM

June 21, 2016

Torsten Bergmann

SmallWorlds for Pharo

Interactive Fiction framework in Smalltalk is released. Read more

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

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.

by Torsten (noreply@blogger.com) at June 20, 2016 04:35 PM

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.


by Torsten (noreply@blogger.com) at June 20, 2016 04:21 PM

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 setup-linenoise.sh to setup_linenoise.sh.

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! :)

June 18, 2016 10:00 PM

June 17, 2016

Torsten Bergmann

Pharo Launcher

was updated to Pharo 5. Cool!!!

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