VMTRAP with VA Smalltalk due to strange bytecode differences (or whatever)

Today I was on the hunt. And I finally shot the beast that killed hundreds of good men over the last decades or so.

Well, at least it seems it’s dead, and I don’t really know why. I know it’s dead and I was hunting for it, but I am not sure I pulled the trigger.

But let’s start at the beginning. Yesterday I had a shiny new version of my Seaside Application and I had cross packaged it for Linux and tested it on two different Linux machines. And it crashed. It crashed without much comment, the Server just didn’t respond any more, the process was dead and all it left for me was a vmtrap.log and an vmtrap.img file in the image directory. Funnily, it crashed very reliably, within only a few Web page requests, but it died in many different places. The vmtrap.log almost always indicated the image had gotten to some method that was not the same of any of the previous crashes.

The funny thing was that the packaged image of the day before ran nicely, without any crashes. It ran using the very same VM and all external libs and stuff. The only difference was that other image. The code changes were only in application code, no external calls, strange extensions to UndefinedObject or any evil class initialization stuff. Just a few bug fixes and stuff.

So to sum the situatuon up: the dev image on Windows ran, a dev image on Linux ran as well, the packaged image of the previous day ran – even on the same machines using the same path and vm and libs and ini and whatever. The VM crashed in various places, and I could not find any pattern why it may have crashed.

I even created two completely fresh XD images and repackaged and went through the .es files and whatnot. I also repackaged the image of the previous day and all was the same again: old one was good, new one was broken.

So I was somewhat out of luck. I asked the wizard of G and found a very old post that seemed to talk about the very same problem. It came up with the (crude?) theory that someone must have screwed bytecodes in the library (Maybe I should mention I use a Linux XD image for packaging while I develop on Windows, so it’s not related to any image problems. I throw images away very often to avoid such problems right from the start) and recompiling methods helped their problem.

So I thought there’s not much to loose. I fired up a Config Map Browser, browsed the Changes between previous day and current (incl. required maps) and simply changed all changed methods by entering a blank or newline somewhere in the Methods. Luckily, I hadn’t changed that much code yesterday, maybe 50 methods. Have I ever mentioned I really love envy?

And what can I say? I fired up the Linux VM, cross-packaged the new (unchanged, but recompiled) code and the problem seems to be solved. The packaged image is running and seems to be stable.

So what could have gone wrong? I am packaging once or twice a week and haven’t seen this ever before.

Ah, and before you ask: None of the methods I had changed were ever mentioned in the vmtrap.log files…

Very strange…

But here’s my theory (please take it with a grain of salt):

I remember two things that happened to me yesterday. One was that I added an instance variable with accessors (using RB) named ‘class’ which wasn’t a good idea, so I later renamed the variable (but not the Accessors) to ‘cssClass’. I know I later couldn’t version/release that class because it was “inconsistent withe the edition in the Library”, an issue that is easy to solve most of the times.

I remember I once had lots of variables and accessors to rename in a very poor code base and I’ve had similar problems with these accessor methods that obviously didn’t work right. The source code said it would be doing one thing, but the results of executing them was different… Back then, changing the accessor methods by hand and saving /compiling new editions of them solved the issue.

I am not sure this theory is any good and am not sure how I could ever build a test for this stuff or write a somewhat useful support case. I only hope I remember this post  if I ever encounter such a strange problem again.

So what do we learn from this?

• Version your code frequently to have milestones to check for changes!
• Envy is one of your best friends when it comes to finding differences (handling them is another story and envy is not yet good at that)
• Package early. package and test the packaged code often so that you know when things go wrong (and so that you don’t have too many of these surprises the night before shipping date)
• Sometimes the fix of a bug doesn’t feel right. How can I know the next build tomorrow isn’t screwed again?

Die Interaktivität der Smalltalk-Entwicklung im Video

Erst gestern schrieb ich im Zusammenhang mit dem Google Summer Of Code und der Programmiersprache Smalltalk:

Smalltalk macht enormen Spass. Die sehr dynamische Umgebung ist sehr motivierend, weil man nicht toten Quelltext pflegt, sondern sich stets direkt im lauffähigen Objektsystem aufhält. Man muss es ausprobiert haben, um das zu verstehen…

und just einen Tag später lese ich auf Torsten’s blog über ein exzellentes Beweisvideo von Esteban Lorenzano, das dies sehr schön belegt:

Interactive Smalltalk

A really nice video from Esteban that demonstrates the interactive nature of Smalltalk development and scripting facilities - here with Pharo. The demo is using Storm (a small game engine).

Hier kann man live zusehen, wie man sich als Smalltalk-Entwickler ein Objekt in einem Inspector greift, und direkt während des Programmablaufs Änderungen daran durchführt. Im verlinkten Video werden nur Variablen von Objekten zur Laufzeit geändert und damit der Verlauf des Programms beeinflusst.

Aber das ist erst der Anfang: Nutzt man den Smalltalk-Debugger, kann man direkt während des Programmlaufs den Code verändern und das Programm direkt weiter laufen lassen. Da es in Smalltalk keinen Compiler/Link-Zyklus gibt, ist das Ergebnis sofort verfügbar, man sieht die Auswirkungen seiner Änderungen sofort – und kann sie eventuell auch sofort noch feintunen. Leider ist der Debugger nicht im Video zu sehen.

Und das gezeigte funktioniert nicht nur mit virtuellen Bällen und Körben, sondern auch mit Flugbuchungen, SEPA-Lastschriftaufträgen, Wertpapier-Orders oder Buchungssätzen. Oder auch mit komplexen Berechnungen und so weiter. Ein Programm ist so seine eigene Simulation. Das meine ich mit motivierend und Dynamik.

Danke Torsten, für die Argumentationshilfe zum perfekten Zeitpunkt

Und natürlich Danke an Esteban für das tolle Video.

Die European Smalltalk User’s Group ist Mentoring Organization für Googles Summer Of Code 2013

Auch dieses Jahr hat Google die ESUG (European Smalltalk User’s Group) als Mentoring Organization für die Teilnahme am Summer Of Code ausgewählt. Das sind für die Smalltalk-Welt sehr gute Nachrichten.

Was ist der Google Summer Of Code?

Die Kurzform: Google bezahlt einen oder mehrere Studenten dafür, dass sie diesen Sommer an einem open source – Projekt zusammen mit einer Mentoring Organization arbeitet. Mitmachen können alle Studenten einer Bildungseinrichtung wie z.B. Universitäten, Fachhochschulen, duale Hochschulen etc. Jeder (zugelassene) Student, der zum Abschluss des Summer Of Code seine Ziele erreicht, erhält von Google ein Stipendium in Höhe von 4500 US Dollar. Ja, richtig gelesen: eine schöne Summe fürs Programmieren an einem open source – Projekt.

Die Mentoring Organization, also in diesem Fall die ESUG bekommt von Google für jeden betreuten Studenten eine Aufwandsentschädigung in Höhe von 500 USD. Auch das ein sehr willkommener Beitrag für eine Organisation, die open source – Projekte durchführt.

Die Langform und wirklich alle wichtigen Informationen finden sich auf der Homepage des Google Summer Of Code 2013. Dort findet sich auch eine sehr umfangreiche Sammlung von FAQs.

Wie kann man mitmachen?

Es gibt die Möglichkeit, als Mentor für ein Projekt mitzuhelfen. Für Studenten heisst es nun, sich bis 22. April schlau zu machen, was für Projektideen die ESUG vorgeschlagen hat, und woran man Spass hätte, mit zu arbeiten. Die Projektideen der ESUG finden sich hier. Als Teilnehmer wendet man sich zunächst an die Mentoring Organization, die dann anhand der (noch nicht festgelegten) Anzahl gesponserter Projekte die Studenten auswählt. Die Bewerbungsfrist für Studenten endet am 3. Mai.

Warum sollte man sich ausgerechnet für ein Smalltalk-Projekt im Google Summer Of Code interessieren?

Es gibt einige gute Gründe:

1. Smalltalk ist die Mutter der OO-Sprachen. So ziemlich alle Konzepte rund um die objektorientierte Programmierung haben ihren Ursprung in Smalltalk. Selbst wenn man nicht vorhat, später in Smalltalk zu arbeiten, lernt man hier eine ganze Menge über gutes Design. Smalltalk ist wie Latein: Spanisch, Französisch und andere Sprachen lassen sich mit fundiertem Latein leichter erlernen.
2. Im Smalltalk-Umfeld passiert sehr viel mehr, als man vielleicht denkt. Gerade in Europa: Pharo Smalltalk zum Beispiel ist ein Projekt, das hauptsächlich in Frankreich, der Schweiz und Deutschland von zahlreichen Leuten unterstützt wird. Daneben ist Smalltalk auch stark in Südamerika vertreten (wie wäre es mit einem Job in Buenos Aires???).
3. Smalltalk macht enormen Spass. Die sehr dynamische Umgebung ist sehr motivierend, weil man nicht toten Quelltext pflegt, sondern sich stets direkt im lauffähigen Objektsystem aufhält. Man muss es ausprobiert haben, um das zu verstehen…
4. Die Smalltalk-Gemeinde, vor allem im open-source-Umfeld, ist seit Jahren am Wachsen. Auch, wenn es auf den ersten Blick so aussieht, als wenn Smalltalk seine beste Zeit gehabt hätte, macht Smalltalk sich seinen Weg langsam aber sicher zurück in den Markt. Ähnlich wie es Ruby, PHP und andere Technologien vorgemacht haben, bewegt sich Smalltalk nicht mehr, wie das in den neunziger Jahren noch üblich war, durch große Strategie-Entscheidungen in Organisationen hinein, sondern durch Projekte einzelner, die einfach eine Lösung für existierende Probleme implementieren. So setzen aktuell Unternehmen Smalltalk ein, in denen “das Management” gar nichts davon weiss, und leistet gute Dienste.
5. Die ESUG hat einige Erfahrung mit der Betreuung von Studenten im Rahmen des GSoC. 2013 wird das sechste Jahr sein, in dem die ESUG teilnimmt. Einige der Mentoren, die bisher Projekte vorgeschlagen haben, sind schon mehrfach dabei gewesen und haben mit ihren Studenten wertvolle Tools und Frameworks in die Smalltalk-Welt eingebracht. Manche Mentoren für 2013 waren selbst in vorangegangenen GSoC’s als Student dabei. Einen Überblick dazu kann man sich hier verschaffen.
6. Die Smalltalk-Welt ist überschaubar: Wir sind eine relativ kleine Familie (verglichen mit Communities wie JavaScript oder PHP), in der man mit einem einzelnen Projekt durchaus etwas bewegen kann, und nicht eines von vielen Projekten ist, das vielleicht niemals Beachtung finden wird. Es kann also durchaus sehr befriedigend sein, hier mit zu arbeiten. Und vielleicht gibt es dann auch noch ein kleines Stückchen Ruhm zu erlangen

Also: Gründe gibt es genug, und wir freuen uns über jeden, der Mitmachen möchte. Es gibt viel zu tun und hohe Ziele zu erreichen, aber vor allem viel zu lernen und dabei eine Menge Spass zu haben!

Informier Dich hier! 

 

Pharo 2.0 ist offiziell verfügbar

Das Pharo-Projekt, das einst mit dem simplen Anspruch startete, die beste Smalltalk-Umgebung zu entwickeln und als open-source kostenfrei zur Verfügung zu stellen, hat auf diesem Weg einen neuen Pflock eingeschlagen. Die Version 2.0 wurde gestern freigegeben. Es wurde viel aufgeräumt, vereinheitlicht und verbessert, aber vor allem wurden weit über 1000 Bugs gefixt:

We are proud to announce the release of Pharo 2.0!

You can find information about Pharo at:
http://www.pharo-project.org

About this release
——————
All in all, there were over 1600 issues treated in the issue tracker
and 1350 improvements integrated into 2.0.

Pharo ist die Heimat diverser Projekte, die in der Smalltalk-Welt und darüber hinaus für Aufsehen gesorgt haben. Als erstes fallen mir da natürlich Seaside und einige darauf aufbauende Tools (Pier, Magritte etc.) ein, sowie Moose mit seinen Teilprojekten. Nicht zu vergessen DBXTalk, das eine komplette Infrastruktur rund um GLORP und openDBX für Pharo aufbaut. Viele davon sind auf anderen Umgebungen ebenfalls verfügbar, aber werden in Pharo gepflegt.

Ein Ansatz der Pharo-Gemeinde, der von Anfang an im Mittelpunkt stand, war, dass man sich von anderen Plattformen abspaltet, und seinen eigenen Weg geht. Das hat eine ganze Menge Vorteile, etwa eine sehr hohe Schlagzahl an Innovationen, aber eben auch Schattenseiten. Es gab und gibt immer wieder Maintainer von Projekten, die sich entschieden haben, Pharo als Plattform nicht mehr primär zu bedienen, sondern dazu aufriefen, es möge sich jemand als Portierer bzw. Maintainer eines Ports nach Pharo bereit erklären. Letztes prominentes Beispiel ist Chris Muller mit seiner OO-Datenbank Magma. Das kann aber im Endeffekt natürlich bedeuten, dass, wenn sich ein Porter findet, mehr Zeit für das eigene Projekt bleibt, und somit kann auch dies eine gute Nachricht sein. Und wer weiss, vielleicht wird aus dem Porter eines Tages ein Hauptentwickler, und so wächst das Projekt noch schneller…

Pharo Smalltalk ist  bei weitem die Smalltalk-Umgebung mit der aktivsten open source – Gemeinde und legt ein enormes Tempo bei der Integration von Neuerungen hin. Es lohnt sich also ganz sicher, sich mit Pharo Smalltalk zu beschäftigen, wenn man sich für Smalltalk interessiert.

Pharo Smalltalk läuft auf Windows, Linux, Mac OS X, Android und iOS und deckt damit neben Squeak die meisten Plattformen ab. Der Code ist auf allen Plattformen unverändert lauffähig (man kann einfach das Image auf einen anderen Rechner transportieren und dort starten, ohne jegliche Anpassungen), sodass ein Portierungsaufwand nicht anfällt, solange man keine Plattformspezifischen APIs nutzt (was vor allem auf iOS und Android natürlich schwierig sein kann, vor allem wegen des nativen Look&Feels).

Wer also von Smalltalk schon gehört hat, und sich das irgendwie mal gerne anschauen würde, sollte sich unbedingt Pharo 2.0 herunterladen und loslegen. Auf den Projektseiten von Pharo sind viele Links zu Einsteiger- und weiterführendem Material.

Wir haben übrigens erst vor ein paar Wochen ein Interview mit Stéphane Ducasse auf unserem Podcast “Smalltalk Inspect” geführt, in dem wir über die Entwicklung und Beweggründe hinter Pharo gesprochen haben. Ausserdem haben wir viel über die Bemühungen des Projekts in Richtung Finanzierung und Weiterentwicklung von Pharo gelernt. Es lohnt sich also, auch da mal reinzuhören.

Smalltalk Inspect interviews Stéphane Ducasse on Pharo

We’ve got another sweet episode of Smalltalk inspect over on our podcast page. To start 2013 off we chose to talk to Stéphane Ducasse about Pharo Smalltalk and its almost finished 2.0 release as well as the newly formed Pharo Consortium and Pharo Association, two organizations with one simple goal: accelerate and stabilize Pharo’s progress.

So head over to our podcast page or iTunes or any other podcast portal and hear all about what’s new in the Pharoverse.

Are we Smalltalkers missing the mobile trend?

This might be an interesting detail for all people involved in Smalltalk environments that run on Android and/or iOS. Among the top 10 search terms used in 2012 to find  my blog there were “smalltalk android” and “smalltalk ipad”. And in fact, almost every day I check my blog statistics, and these terms or variations thereof are on the list.

To me, this is a clear indication that people are looking for documentation and possibly ready-made installation packages for either Smalltalk IDEs or deployed applications that are written in Smalltalk. I must admit I have been playing with the idea of writing an application for Android in either Gnu ST or Pharo repeatedly, but never took the time because I couldn’t find much documentation for it. People do deploy Smalltalk appliations on iPhones and Android devices but I haven’t found much material on how they do it. It’s either blindingly obvious for people who are used to writing Android / iOS apps, or the people who managed to do it regard their knowledge as a trade secret. Both are okay with me. I like to have a certain advantage on things I know as well. So I am not going to bash this. 

Using ltrace to debug VA Smalltalk calls to external libraries

This post is a bit technical, but sometimes even Smalltalk developers need to dive down into depths were it feels like noone else has ever been there before.

In this case I am looking for a segmentation fault in a call to an external library on Linux. From logfiles, I know that the library is found and the external function executes. This is because I am in the luxurious position to use an external library that writes a logfile.  I could even tell from log4s logging output in my application that a log output immediately after the call to the library is not executed any more. That’s all I know so far.

For Linux there are very helpful tools to trace what an application does, like strace and ltrace. I’ve used both, but strace didn’t really help me much. This post is about how to use ltrace together with VAST on Linux. There are a few little difficulties with using ltrace, one of them being that you cannot start ltrace on a shell script, and VAST typically is started using the abt shell script on Linux. Luckily, you can also start ltrace and tell it to sniff on a running process, which you have to name by its PID (process id). This option is quite useful for another reason: trace output can be very big and there’ll be a lot of information in it that’s not helpful for your case. If you need to run a few Smalltalk statements before the actual error, you can save yourself a lot of searching for relevant information in the log output if you start tracing as late as possible.

So first you need to find out the process’ PID. The easiest way to do so is to look at the shell output of the abt script:

joachim@BooberFraggle:~/image852> ./abt
VA Smalltalk, Version 8.5.2 

VM Timestamp: 4.0,(NC) 8/7/2012 (84)

(C) Copyright Instantiations 1994, 2012. All rights reserved.
(C) Copyright International Business Machines Corp. 1994, 2006. All rights reserved.
Virtual Machine PID: 30749

Commandline args {
 -mcd
 -i./abt.icx

 }

VM Options {
... etc. ...

You find the PID in this output (see red line).

So after starting VAST and executing whatever is needed to do before you want to start tracing, you start ltrace with a command line like this (best done as root, of course):

ltrace -p 30749 -S  -o ltrace.log -l /path/to/library

Then you can start evaluating the Smalltalk code that will crash the image and exit with a segmentation fault. YXou can of course even use the smalltalk debugger to run the code and see what happens – up to the point of the segmentation fault

Here’s what the parameters mean:

• -p is the process id to trace (the one from above)
• -S Display system calls as well as library calls
• -o name of the trace log file
• -l Display only the symbols included in the library  filename (If you know which library causes problems).

ltrace does have a lot more parameters and as always the man command is your friend to learn more about them.

So in my case, I get a trace file that contains the following info:

30749 SYS_getcwd("/home/joachim/image852", 4096) = 23
30749 SYS_lstat64(0xbfa008f4, 0xbfa005e4, 0xb725aff4, 0x92763d4, 0x92763dc) = -2
30749 SYS_getcwd("/home/joachim/image852", 4097) = 23
30749 SYS_lstat64(0x92765dc, 0xbfa018ac, 0xb725aff4, 3, 0xbfa01954) = -2
30749 SYS_lstat64(0xbfa008f4, 0xbfa005e4, 0xb725aff4, 0x9276575, 0x9276579) = 0
30749 SYS_lstat64(0xbfa008f4, 0xbfa005e4, 0xb725aff4, 0x927657a, 0x9276581) = 0
30749 SYS_lstat64(0xbfa008f4, 0xbfa005e4, 0xb725aff4, 0x9276582, 0x927658a) = 0
30749 SYS_lstat64(0xbfa008f4, 0xbfa005e4, 0xb725aff4, 0x927658b, 0x9276593) = -2
30749 SYS_lstat64(0x9276574, 0xbfa018ac, 0xb725aff4, 3, 0xbfa01954) = -2
30749 SYS_gettimeofday(0xbfa0178c, NULL) = 0
30749 SYS_write(12, "2012-11-20 10:43:14,003 INFO - "..., 70) = 70
30749 SYS_lseek(12, 0, 2) = 1004
30749 SYS_brk(0x092a5000) = 0x092a5000
30749 SYS_brk(0x092a4000) = 0x092a4000
30749 SYS_brk(0x092c5000) = 0x092c5000
30749 SYS_brk(0x092e6000) = 0x092e6000
30749 SYS_brk(0x09307000) = 0x09307000
30749 SYS_brk(0x09328000) = 0x09328000
30749 SYS_munmap(0xb6375000, 65588) = 0
30749 SYS_gettimeofday(0xbfa02840, NULL) = 0
30749 SYS_write(12, "2012-11-20 10:43:14,015 INFO - "..., 70) = 70
30749 SYS_lseek(12, 0, 2) = 1074
30749 SYS_gettimeofday(0xbfa02980, NULL) = 0
30749 SYS_write(12, "2012-11-20 10:43:14,016 INFO - "..., 96) = 96
30749 SYS_lseek(12, 0, 2) = 1170
30749 --- SIGSEGV (Segmentation fault) ---
30749 SYS_rt_sigprocmask(1, 0xbfa02790, 0, 8, 0xb725aff4) = 0
30749 SYS_open("vmtrap.log", 577, 0644) = 13
30749 SYS_write(13, "-Platform Information-----------"..., 40) = 40
30749 SYS_write(13, "\nVM Timestamp: ", 15) = 15
30749 SYS_write(13, "4.0,(NC) 8/7/2012 (84)", 22) = 22
30749 SYS_write(13, "\nCPU Architecture: ", 19) = 19

So as you can see, the last few lines are the beginning of the ouptut of the VM into vmtrap.log, which it writes when it crashes. The most interesting part is above the coloured line: The last few statements that were executed before the crash. What did I learn from that file?

You can see that the Library is producing output onto its log file (30749 SYS_write(12, “2012-11-20 10:43:14,016 INFO – “…, 96) = 96). Somewhere above the excerpt reproduced here, there is a line that says:

30749 SYS_open(“/home/joachim/image852/myLib.log”, 65, 0600) = 12

That obviously opens the log file and returns its file handle (12).

So I still don’t know what happens exactly, but ltrace at least can tell me a bit about what happened last before a crash.

This article, as you may have guessed, is mainly there to save me time next time I need to trace stuff and may not be extremely entertaining

Installing VA Smalltalk on openSuSE 12.2 32bit

Regular readers of my blog may know that we are working on a Seaside Application that is to be deployed on a Linux Web Server on the Internet. VA Smalltalk does support Linux, even though using VA Smalltalk for development work on Linux is not as nice and convenient as on Windows. But at least for testing, packaging and fixing some last bugs, VA Smalltalk runs reasonably well on Linux.

Over the last few days, I was on the hunt (and still am) for a problem with calls to an external library that causes no troubles on Windows, but ends with a General Protection Fault on Linux. Luckily, the Library does log its activity, so I know the library finishes its job, but control never returns back to our VAST application (We’ve added log entries right before and after the call to the library). Maybe I’ll write a little bit more about this later.

So I wanted to test whether this is only a problem in Ubuntu 12.04 (missing libraries or whatever) or if it is reproducible on openSuSE 12.2. I’ve been using SuSE for more than a decade, even longer than that, because I remember running a distro named LST (Linux Support Team) back in the early nineties, and I think that was the predecessor of SuSE that shipped on a CD or some twenty floppy discs…

Installing on Ubuntu runs quite flawless (I just updated to VAST 8.5.2 a few days ago and hod no problems at all), so I expected no problems on openSuSE. The installation of openSuSE in VmWare Fusion is extremely easy, and I was full of energy to install VAST on openSuSE. I kicked off a terminal, entered su – and ./setup & . Usually, this shell script starts a graphical installer that looks pretty similar to the one you know from Windows. From there on, all is very simple and boring.

Not this time.

The terminal said something like it had errors and I should please look into /tmp/vastInstall-output  . No graphical installer in sight.

And here’s what I found in that file:

VA Smalltalk, Version 8.5.2 
VM Timestamp: 4.0,(NC) 8/7/2012 (84)
(C) Copyright Instantiations 1994, 2012.  All rights reserved.
(C) Copyright International Business Machines Corp. 1994, 2006.  All rights reserved.
Virtual Machine PID: 3908
Commandline args {
 -mcd
 -no_break
 -isetup.icx
 -z.us./home/joachim/Downloads/cd_c
 }

VM Options {
  }
Xlib: connection to ":0.0" refused by server 
Xlib: No protocol specified

ERROR: Failed to open default display - exiting.

This happened in Gnome, KDE and IceWM. Luckily, Seth and John from Instantiations knew what I have to do and posted it to the VA Smalltalk support group. All that needs to be done is to configure the X server to allow local connections to the display for all users who need to start X programs. So before starting the installation, you have to execute the following commands (as root):

xhost local:root
xhost local: <user name who wants to start VAST>

You can then run setup to install VA Smalltalk as usual (please make sure you run it as root). These settings are not permanent, so you have to repeat the commands for every start of VA Smalltalk (so it’s helpful to add these commands to the abt startup shell script – which I plan to do once I have a little time. All that’s needed is to find out the current user that runs the script…).

I don’t fully understand the reasons for this, because you can start xclock, xeyes etc. even before that. But I keep this info here for further reference. VAST now runs on openSuSE 12.2 and I am happy I asked on the support forum.

Reviving VA Smalltalk’s AbtXmlObjectCache after lots of messing with it

Building XML mapping specifications in VA Smalltalk is not the kind of job that I’d call pleasant. At least not with my level of knowledge. I keep on messing the stuff and registering things in the Xml Object Cache that may or may not be in my way during development.

So there is a simple way to at least throw everything (Schemas, MappingSpecs, Serializers etc.) out of it. In fact there are two of them:

a) AbtXmlObjectCache current initialize
b) AbtXmlObjectCache reset

while a) sets all cache dictionaries to new empty Dictionaries or LookupTables, b) simply throws the Current instance away.

The effect, however, is not exactly what you may want. The reason is that VA Smalltalk

Pharo, Squeak and GNU: Smalltalk runs on Android devices

I’ve mentioned Stefan Krecher’s work on GNU Smalltalk integration for Android a few weeks ago and somehow forgot to mention that it’s not the only Smalltalk environment that runs on this nice mobile operating system.

Just yesterday, I read on The Weekly Squeak that a new version of the Cog VM for Android has been announced together with a corresponding Pharo Image. The VM, however, can run Squeak Images as well. There’s quite some information on how to install and run the VM, the corresponding Pharo Image and known limitations and stuff available.

So it seems at least for Smalltalk, the openness of Android is excellent news. Even though there is some sort of VM and image support for iOS for Squeak and Pharo, it’s somewhat hard to find and even harder to get installed on users’ devices. I hope to find the time to get my fingers at either Pharo or Gnu ST on Android soon.