Planet Squeak

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

November 21, 2014

Torsten Bergmann

Using Blowfish in Pharo

look here.

by Torsten (noreply@blogger.com) at November 21, 2014 08:29 PM

Hubcap - a SmalltalkHub API and browser for Pharo

Hubcap - a tool to browse and access SmalltalkHub contents from within the Pharo image. Read the
details.


 

by Torsten (noreply@blogger.com) at November 21, 2014 07:44 AM

Kiviat support in Roassal

Roassal for Pharo now supports Kiviat-Diagramms. Read more here and have a look at the picture.

by Torsten (noreply@blogger.com) at November 21, 2014 06:44 AM

November 20, 2014

Torsten Bergmann

Spur 64

Spur VM for Pharo, Squeak and Newspeak is also progressing in the 64 bit area. Another milestone is described here.

by Torsten (noreply@blogger.com) at November 20, 2014 06:59 PM

The Weekly Squeak

Spur in 64!

bits

From Eliot Miranda:

Hi All,

I’m pleased to say that today the simulator got as far as redrawing the
entire display and finishing the start-up sequence for a bootstrapped
64-bit Spur image. That means it correctly executed over 26 million
bytecodes. So at least a 64-bit Spur Stack VM is not too far off.

best,
Eliot


by Ron Teitelbaum at November 20, 2014 04:44 PM

Torsten Bergmann

Wireless Sensors Network simulation in Pharo

A demonstration of a sensor network overlayed over a map and animated. Read more about it here.


by Torsten (noreply@blogger.com) at November 20, 2014 08:37 AM

OpenStreetMap Roassal extension for Pharo

Watch the video here:

by Torsten (noreply@blogger.com) at November 20, 2014 08:34 AM

Craig Latta

debugging remote exceptions works

a debugger for a remote unhandled exception

a debugger for a remote unhandled exception

I have debugging working for remote unhandled exceptions. My motivating use case was debugging messages not understood by the Context console’s embedded web server. The console is a headless app. In development, I run it with a remote-messaging connection to a headful system. Now, when there is an unhandled exception (like a message not understood), the exception requests that the headful system open a debugger (as its default action).

Before opening the debugger, the headful system replaces the sender of the first relevant context on the headless system with the last relevant context on the headful system, hiding all the remote-messaging-related contexts in between. The picture above shows an example of this. On the headful system, I sent “zork” to an object on the headless system. The debugger shows a continuous context stack which spans the two systems. This all works with little special handling in the debugger because of the complete transparency of remote messaging. It doesn’t matter that the contexts and methods that the debugger is manipulating happen to be remote.


by Craig Latta at November 20, 2014 04:11 AM

November 18, 2014

Torsten Bergmann

Cincom ObjectStudio 8.6 and Cincom VisualWorks 8.0

are available. Read here.

by Torsten (noreply@blogger.com) at November 18, 2014 09:21 PM

SciSmalltalk v0.16

is released. Read more.

by Torsten (noreply@blogger.com) at November 18, 2014 08:55 PM

Smalltalk-on-Rails

The goal of this project is to provide an object-oriented scripting environment for web applications running on Ruby-on-Rails.

by Torsten (noreply@blogger.com) at November 18, 2014 08:39 AM

Treap - a new collection

in VisualWorks. Read more.

by Torsten (noreply@blogger.com) at November 18, 2014 08:14 AM

November 17, 2014

Torsten Bergmann

Arbitrary Precision Float in Pharo

Read more here.

by Torsten (noreply@blogger.com) at November 17, 2014 03:46 PM

November 14, 2014

Torsten Bergmann

Lambda Calculus in Pharo

another nice article from Sven. Read more.

by Torsten (noreply@blogger.com) at November 14, 2014 07:25 AM

InfoQ article on Essense# Smalltalk

A new infoQ article called "Introducing Essence#: A Smalltalk-based Language for .NET"

by Torsten (noreply@blogger.com) at November 14, 2014 07:24 AM

VisualAge Smalltalk 8.6.1.

VisualAge Smalltalk 8.6.1 has been released.

by Torsten (noreply@blogger.com) at November 14, 2014 07:13 AM

November 12, 2014

Torsten Bergmann

Smalltalk with Robots

A presentation can be found here.

by Torsten (noreply@blogger.com) at November 12, 2014 10:31 PM

Kendrick

Kendrick is a platform for epidemiological modeling and analysis. It helps epidemiologists craft custom analyses cheaply. It's based on Pharo and MOOSE. It's open source under BSD/MIT.

Kendrick project participates to the Ebola Computing Challenge organized by Hacker League in October 2014

by Torsten (noreply@blogger.com) at November 12, 2014 08:06 PM

November 10, 2014

Torsten Bergmann

Memoization for Smalltalk

using Smalltalk blocks - clean and simple. See here.

by Torsten (noreply@blogger.com) at November 10, 2014 08:35 PM

ARM Stack VMs available

Pre-built Squeak stack and stack/spur VMs for ARMv6 (i.e. Raspberry Pi) and ARMv7 (i.e. BeagleBone Black, Parallella, numerous Chromebooks, etc) are now available at the same location as the other Cog and Spur VMs. Read more.

by Torsten (noreply@blogger.com) at November 10, 2014 04:40 AM

November 07, 2014

Torsten Bergmann

Smalltalk Foundation meeting in Portland

Smalltalk Foundation meeting in Portland on Monday, November 10, 2014.

by Torsten (noreply@blogger.com) at November 07, 2014 07:20 AM

November 05, 2014

Torsten Bergmann

Toronto Smalltalk User Group and Newspeak

Next meeting of the Toronto Smalltalk User Group is Monday, November 10 on Newspeak. See http://www.smalltalk.ca for details.

by Torsten (noreply@blogger.com) at November 05, 2014 01:26 PM

Smalltalks 2014 conference

has just begun. If you are not there you can follow on Twitter.

by Torsten (noreply@blogger.com) at November 05, 2014 01:25 PM

November 02, 2014

Göran Krampe

Squeak to Nim, come in Nim...

In my exploration of Nim the turn has come to see how we can use Nim together with Squeak.

Squeak (and Pharo) has two basic mechanisms of interfacing with the C world:

The VM plugins are basically a controlled way to introduce new "named" primitives in Smalltalk that can be invoked from Smalltalk. A plugin can be built either linked into the VM binary (statically) or as a dynamically loaded library (dll, so, dylib etc). When "all else fails" a plugin is the way to go, but they are a bit awkward to work with.

Then we have the FFI which is a generic way to dynamically call dynamically loaded libraries. In other words, no compilation step needed - just type the correct Smalltalk line and the library will load and the calls work. Now... sure, the FFI mechanism is a bit slower, since it needs to look at arguments and make the proper type conversions for the call. But the FFI is heavily used in the commercial Terf system, in fact, all the OpenGL calls are done through it. So its quite proven, and not that slow.

NOTE: There are in fact several FFIs today, the old one, the one called Alien and Pharo is brewing a new one called UFFI.

Let's see if we can use the good old FFI with Nim.

Making a Nim library

It turns out that making a library isn't hard, but there are a few things of note. An oh, all files here if you want to try it out. Ok, so here is our testlib.nim library:

``` nimrod

We exercise some trivial types and how they map.

#

SqueakFFI Nim

========= ======

long => int

char* => cstring

import math

A single proc, returns an int. Since we are on 32 bits

an int is 4 bytes (same size as pointer) and in Squeak FFI

this is a long. The exportc pragma ensures that the exported

name for this proc is exactly "hello" and not mangled.

proc hello*(): int {.exportc.} = 42

Trivial, a Nim string can be sent as a cstring because they are

automatically 0-terminated.

proc foo*(): cstring {.exportc.} = "hey"

Not a problem taking int arguments, they are "long" in Squeak FFI.

proc add*(x, y:int): int {.exportc.} = x + y

Just return the length of a cstring

proc length*(x: cstring): int {.exportc.} = len(x)

Here we convert cstrings to Nim strings, concatenate and return.

proc concat*(x, y: cstring): cstring {.exportc.} = $x & $y ```

The only thing above that wasn't obvious - ehrm, unless you read the manual of course - is that you need to use the exportc pragma to make the symbols stay unmangled in the library.

To compile the above to a 32 bit .so library on Linux, we create a corresponding config file called testlib.nim.cfg:

bash --app:lib --cpu:i386 --passC:"-m32" --passL:"-m32" The above are options to the nim compiler, so we could have just used them on the command line. Now we compile it with nim c testlib and it should produce a file called libtestlib.so.

The first options means "compile a lib instead of a program", and the second means "make it 32 bit". The last two were needed to make it boil down to the C compiler, might be a bug somewhere, but it works.

Now... the above library worked just fine to call from Squeak... at least all procs unless the concat proc. Boom. And it almost DROVE ME NUTS trying to figure out why I was having issues sending char* arguments from Squeak. I thought the problem was on the Squeak side, and I must say that googling for info on stuff like this is a bit of a haystack operation.

Sidenote: Squeak does suffer quite hard from a lack of proper singular documentation. I mean, lots of docs, wiki etc, all over - but what is current? What works? Its a bit of a problem in the Squeak community I would say. And... well, is Pharo different? Not entirely sure. I really like Smalltalk, Squeak and Pharo, and I am used to this, but I must say its a mess.

It turns out that the concat proc is the only one that creates a Nim string, that code needs the GC, and the GC... is in the nimrtl.nim module. This is also documented, but its in the Compiler manual. So it wasn't hard, we just need to make sure to build it too as 32 bits, and copy it to some reasonable place:

bash nim c --cpu:i386 --passC:"-m32" --passL:"-m32" --app:lib --define:createNimRtl lib/nimrtl.nim sudo cp lib/libnimrtl.so /lib/i386-linux-gnu/

Then... we also need to add an option to compiling our lib, -d:useNimRtl, so testlib.nim.cfg looks like this:

bash --app:lib --cpu:i386 --passC:"-m32" --passL:"-m32" -d:useNimRtl

The end result is that we now have a dynamically loadable runtime library libnimrtl.so that has the GC etc. The above option makes sure our libtestlib.so uses that runtime library which in turn makes Nim strings work fine and tada, concat() works.

Smalltalk side

Okidoki, so... thanks Andreas for helping me to get it working. Now, time to play. I put the libtestlib.so in the directory where I run Squeak. Now... I am working with an old Squeak, but it also works just fine with Pharo 3.0. So easiest way to see it in action is to download Pharo 3.0 and try it there:

  1. Download Pharo 3.0, unzip somewhere.
  2. Unzip this file into the pharo3.0 directory. It has the libtestlib.so and also the Smalltalk source.
  3. Install FFI into Pharo: I did it by opening the Configuration browser, finding FFI configuration, then "Install stable version". The FFI plugin itself is included in the VM.
  4. File in the Smalltalk source: Open a File browser, select the file Nim-Test.st and do "Install into new changeset".
  5. Open a Test Runner, search for "Nim" using upper left field, then run the test FFINimTest. If its green - yiha!

You find the calls on the class side of FFINimTestLibrary. For example the one for concat():

``` smalltalk ffiConcat: a with: b

"self ffiConcat: 'a' with: 'b' "

<cdecl: char* 'concat' (char* char*) module: 'testlib'>
^self externalCallFailed

`` You can select the code between "" and run it with "inspect it". Hopefully you get the Smalltalk String'ab'`.

Remark

First versions of this article mentioned segfaults, but after looking closer it seems those segfaults appeared due to me using Smalltalk unloadModule: 'testlib' and then trying again, thus causing a reload. Apparently there is a problem doing this in the VM. But the code seems solid, I have run it hours on end with no problems.

I also studied the Squeak FFI code a bit up close and yes, for char* arguments it will copy them out into temporary allocated memory, and then make the call. Afterwards it will deallocate them before returning back into Squeak. For a char* result it will instantiate a ByteString object from inside the plugin and copy the bytes over into it, so the actual pointer and memory returned from Nim, is not used. If we use byte* we can do the same operation from inside Squeak, as the Terf codebase does extensively. But both approaches seem to be solid.

As noted the pointer returned from Nim in concat() is the pointer to the Nim string itself. This works because Nim strings "double" as cstring, because they are null terminated. That string is however a GC tracked ref in Nim, so Nim will eventually garbage collect it - but the GC doesn't run in its own thread, so the data is safe for Squeak to copy - at least until we return back to Nim in the next call. But generally having Nim return pointers to GC tracked data, is of course not safe unless Squeak immediately copies it. Now... thankfully for char* Squeak FFI does it automatically, for other types we can do it manually in Smalltalk code.

Conclusion

The old Squeak FFI is quite proven and works. As we saw Nim can produce libraries quite easily. And using Nim instead of C/C++ is a nobrainer to me. :)

Happy hacking!

November 02, 2014 11:00 PM

Nim seq

One of the most important aspects in a language is how powerful and easy it is to use its collection/container types. At least that is my feeling coming from Smalltalk where the Collection classes and their rather rich protocols are used extensively and also cover String and Array.

In Smalltalk I can for example do: ``` smalltalk

(1 2 3 4 5) select: [:x | x isOdd] thenCollect: [:x | x * 3 ]

```

Nim has some fundamental Collection types too - and tries deliberately to keep this number small. The ones in the system library are: * array - Can use any ordinal type as index type, but are fixed size specified at compile time. So fairly restricted. * set - bigh performance bit vector, base type can only be ordinals. Again a fairly specialized container. * seq - dynamically resizable array. Index type is integer.

I am not listing range, string and cstring types either. So... in Nim, if we look at Collections, we have seq as the single general purpose dynamically sized collection. Now... this is in the Nim language. If we extend our view to also include the standard library, we find lots more.

In order to first learn all you can do with a seq, one way is basically to search for "seq" in the documentation of the system module.

Squeak (and Pharo) has two basic mechanisms of interfacing with the C world:

The VM plugins are basically a controlled way to introduce new "named" primitives in Smalltalk that can be invoked from Smalltalk. A plugin can be built either linked into the VM binary (statically) or as a dynamically loaded library (dll, so, dylib etc). When "all else fails" a plugin is the way to go, but they are a bit awkward to work with.

Then we have the FFI which is a generic way to dynamically call dynamically loaded libraries. In other words, no compilation step needed - just type the correct Smalltalk line and the library will load and the calls work. Now... sure, the FFI mechanism is a bit slower, since it needs to look at arguments and make the proper type conversions for the call. But the FFI is heavily used in the commercial Terf system, in fact, all the OpenGL calls are done through it. So its quite proven, and not that slow.

NOTE: There are in fact several FFIs today, the old one, the one called Alien and Pharo is brewing a new one called UFFI.

Let's see if we can use the good old FFI with Nim.

Making a Nim library

It turns out that making a library isn't hard, but there are a few things of note. An oh, all files here if you want to try it out. Ok, so here is our testlib.nim library:

``` nimrod

We exercise some trivial types and how they map.

#

SqueakFFI Nim

========= ======

long => int

char* => cstring

import math

A single proc, returns an int. Since we are on 32 bits

an int is 4 bytes (same size as pointer) and in Squeak FFI

this is a long. The exportc pragma ensures that the exported

name for this proc is exactly "hello" and not mangled.

proc hello*(): int {.exportc.} = 42

Trivial, a Nim string can be sent as a cstring because they are

automatically 0-terminated.

proc foo*(): cstring {.exportc.} = "hey"

Not a problem taking int arguments, they are "long" in Squeak FFI.

proc add*(x, y:int): int {.exportc.} = x + y

Just return the length of a cstring

proc length*(x: cstring): int {.exportc.} = len(x)

Here we convert cstrings to Nim strings, concatenate and return.

proc concat*(x, y: cstring): cstring {.exportc.} = $x & $y ```

The only thing above that wasn't obvious - ehrm, unless you read the manual of course - is that you need to use the exportc pragma to make the symbols stay unmangled in the library.

To compile the above to a 32 bit .so library on Linux, we create a corresponding config file called testlib.nim.cfg:

bash --app:lib --cpu:i386 --passC:"-m32" --passL:"-m32" The above are options to the nim compiler, so we could have just used them on the command line. Now we compile it with nim c testlib and it should produce a file called libtestlib.so.

The first options means "compile a lib instead of a program", and the second means "make it 32 bit". The last two were needed to make it boil down to the C compiler, might be a bug somewhere, but it works.

Now... the above library worked just fine to call from Squeak... at least all procs unless the concat proc. Boom. And it almost DROVE ME NUTS trying to figure out why I was having issues sending char* arguments from Squeak. I thought the problem was on the Squeak side, and I must say that googling for info on stuff like this is a bit of a haystack operation.

Sidenote: Squeak does suffer quite hard from a lack of proper singular documentation. I mean, lots of docs, wiki etc, all over - but what is current? What works? Its a bit of a problem in the Squeak community I would say. And... well, is Pharo different? Not entirely sure. I really like Smalltalk, Squeak and Pharo, and I am used to this, but I must say its a mess.

It turns out that the concat proc is the only one that creates a Nim string, that code needs the GC, and the GC... is in the nimrtl.nim module. This is also documented, but its in the Compiler manual. So it wasn't hard, we just need to make sure to build it too as 32 bits, and copy it to some reasonable place:

bash nim c --cpu:i386 --passC:"-m32" --passL:"-m32" --app:lib --define:createNimRtl lib/nimrtl.nim sudo cp lib/libnimrtl.so /lib/i386-linux-gnu/

Then... we also need to add an option to compiling our lib, -d:useNimRtl, so testlib.nim.cfg looks like this:

bash --app:lib --cpu:i386 --passC:"-m32" --passL:"-m32" -d:useNimRtl

The end result is that we now have a dynamically loadable runtime library libnimrtl.so that has the GC etc. The above option makes sure our libtestlib.so uses that runtime library which in turn makes Nim strings work fine and tada, concat() works.

Smalltalk side

Okidoki, so... thanks Andreas for helping me to get it working. Now, time to play. I put the libtestlib.so in the directory where I run Squeak. Now... I am working with an old Squeak, but it also works just fine with Pharo 3.0. So easiest way to see it in action is to download Pharo 3.0 and try it there:

  1. Download Pharo 3.0, unzip somewhere.
  2. Unzip this file into the pharo3.0 directory. It has the libtestlib.so and also the Smalltalk source.
  3. Install FFI into Pharo: I did it by opening the Configuration browser, finding FFI configuration, then "Install stable version". The FFI plugin itself is included in the VM.
  4. File in the Smalltalk source: Open a File browser, select the file Nim-Test.st and do "Install into new changeset".
  5. Open a Test Runner, search for "Nim" using upper left field, then run the test FFINimTest. If its green - yiha!

You find the calls on the class side of FFINimTestLibrary. For example the one for concat():

``` smalltalk ffiConcat: a with: b

"self ffiConcat: 'a' with: 'b' "

<cdecl: char* 'concat' (char* char*) module: 'testlib'>
^self externalCallFailed

`` You can select the code between "" and run it with "inspect it". Hopefully you get the Smalltalk String'ab'`.

Remark

First versions of this article mentioned segfaults, but after looking closer it seems those segfaults appeared due to me using Smalltalk unloadModule: 'testlib' and then trying again, thus causing a reload. Apparently there is a problem doing this in the VM. But the code seems solid, I have run it hours on end with no problems.

I also studied the Squeak FFI code a bit up close and yes, for char* arguments it will copy them out into temporary allocated memory, and then make the call. Afterwards it will deallocate them before returning back into Squeak. For a char* result it will instantiate a ByteString object from inside the plugin and copy the bytes over into it, so the actual pointer and memory returned from Nim, is not used. If we use byte* we can do the same operation from inside Squeak, as the Terf codebase does extensively. But both approaches seem to be solid.

As noted the pointer returned from Nim in concat() is the pointer to the Nim string itself. This works because Nim strings "double" as cstring, because they are null terminated. That string is however a GC tracked ref in Nim, so Nim will eventually garbage collect it - but the GC doesn't run in its own thread, so the data is safe for Squeak to copy - at least until we return back to Nim in the next call. But generally having Nim return pointers to GC tracked data, is of course not safe unless Squeak immediately copies it. Now... thankfully for char* Squeak FFI does it automatically, for other types we can do it manually in Smalltalk code.

Conclusion

The old Squeak FFI is quite proven and works. Nim can produce libraries quite easily. And using Nim instead of C/C++ is a nobrainer to me. :)

Happy hacking!

November 02, 2014 11:00 PM

October 30, 2014

Torsten Bergmann

Swiki in Squeak 4.5

Swiki was and still is one of the best (and most easy to use/maintain) implementations of a wiki. It is written in Squeak Smalltalk and I usually use the Winterlong release back from 2005. With it a Swiki server is easy to setup (just unzip and run) and as it stores the files in XML they are easy to backup, repair or query.

Now Chris got Swiki working in a recent Squeak 4.5. image also. Nice!



by Torsten (noreply@blogger.com) at October 30, 2014 10:27 AM

Smalltalks 2014 conference schedule

Smalltalks 2014's preliminary conference schedule is now available, check it here.

by Torsten (noreply@blogger.com) at October 30, 2014 09:49 AM

Smalltalk cheat sheet

Need a litte Smalltalk cheat sheet - then look here.

by Torsten (noreply@blogger.com) at October 30, 2014 09:46 AM

PharoDays 2015

Read all the details about the upcoming Pharo conference and check the doodle.

by Torsten (noreply@blogger.com) at October 30, 2014 08:26 AM

Chat on AmberSmalltalk

see here https://gitter.im/amber-smalltalk/amber

by Torsten (noreply@blogger.com) at October 30, 2014 07:56 AM