GemTalk Systems ist das neue Zuhause von GemStone/S und GLASS – ein Deutungsversuch

Es hat sich sicher schon herumgesprochen, dass die Entwicklungs- und Supportmannschaft von GemStone/S und GLASS sowie das darauf basierende MagLev für Ruby nun in einer neuen Firma zuhause sind. Das neue Unternehmen heisst GemTalk Systems und besteht aus der kompletten Mannschaft, die bisher an GemStone gearbeitet hat. Für das Produkt sind das sehr gute Nachrichten. GemStone/S war bei vmware irgendwie ein Stiefkind. Man musste auf der vmware-Website lange suchen, bis man GemStone/S fand. Selbst auf der zentralen Seite aller Produkte waren diverse Produkte aufgelistet, die ursprünglich von GemStone stammten (z.B. GemFire, SQLFire), nicht jedoch das eigentliche Flaggschiff.

Aus den Pressemitteilungen und Blog-Einträgen ist nicht zu entnehmen, wer die Investoren sind, die GemStone von vmware übernommen und GemTalk daraus gemacht haben. Auch auf der Website sind keine Informationen dazu zu finden. Dafür aber, dass vmware sich auch von den anderen Produkten wieder getrennt hat, wegen derer sie GemStone vor drei Jahren gekauft hatte. Diese sind ein paar Wochen zuvor in die Firma Pivotal ausgelagert worden und werden dort weitergeführt. Was das ganze für vmware für einen Sinn hatte, erschliesst sich mir nicht. Aber wer GemStone ein bisschen kennt, weiss, dass es schon in den neunziger Jahren mal ganz ähnlich zuging: der Börsenkracher Brokat aus Böblingen/Stuttgart hatte GemStone gekauft, um sein Portfolio mit GemStone/J (das es meines Wissens inzwischen nicht mehr gibt) aufzupeppeln. Glücklicher Weise ging Brokat erst vor sdie Hunde, nachdem GemStone mit viel Verlust wieder verkauft worden war. Auch bei Brokat hatte man den eigentlichen Edelstein von GemStone nie verstanden. Martin McClure hat auf der letzten Smalltalks 2012 einen sehr interessanten Vortrag zur Geschichte seines Arbeitgebers gehalten (hier gibt es das Video dazu). Um einen running gag aus diesem Vortrag fortzuführen: GemTalk Systems bleibt im selben Bürogebäude und zieht dort einen Stock höher

Nun könnte man meinen, sowohl Brokat als auch vmware haben sich an GemStone verschluckt, weil Smalltalk einfach nicht mehr zeitgerecht ist und niemand Smalltalk nutzt, zumindest niemand, der dafür Geld ausgeben möchte. Also war es nur logisch, das Zeug wieder abzustossen, und die Perlen des Unternehmens zu behalten.

Schaut man genauer hin, ergibt sich dann aber doch ein ganz anderes Bild: Die Kundenliste von GemTalk Systems ist sehr beeindruckend. Nicht, weil die Namen darauf so bekannt sind und Eindruck machen. Vielmehr, weil dahinter Unternehmen mit sehr komplexen, datenintensiven und äusserst flexiblen, veränderlichen Abläufen stecken.

Wie sonst, ausser durch seine besonderen Eigenschaften gerade für sehr komplexe Abläufe und hohe Datenvolumina liesse sich erklären, dass es Investoren gibt,  die eine Ausgründung von GemTalk Systems ermöglichen? Warum sollte jemand Geld in eine Firma stecken, deren Geschäft eine heisse Kartoffel ist, die vmware einfach fallen lassen möchte?

GemTalk hat eine beeindruckende Kundenliste, die – so wird gemunkelt – für einen attraktiven Cash-Flow sorgt. GemStone ist ein profitables Produkt, und das schon seit Jahrzehnten. GemStone war für Brokat eine Cash Cow und bei VMware war es nicht anders. Wie sonst liesse sich erklären, dass GemStone weiter existierte und das Produkt weiter entwickelt wurde? Wie sonst liesse sich erklären, dass vmware die kostenlose Verwendung von GLASS auch für kommerzielle Zwecke weiter gestatttete und sogar den Umfang der kostenfreien Lizenz erweiterte, das kommerzielle Produkt aber weiter führte? Wie sonst wäre zu erklären, dass erst unter VMware so recht Schwung in die Öffnung von GemStone hin zu open source-Projekten kam, sich Dale Henrichs zunehmend auch Themen wie Metacello und der Kompatibiltät von GemStone mit Pharo/Squeak widmen konnte? GemStone macht gerade einen sehr wichtigen Schritt: Weg von GemBuilder und der Notwendigkeit einer zweiten Smalltalk-Tools als Entwicklungs-Frontend hin zu einem kompletten Werkzeug mit einer eigenen (Webbasierten) IDE. Hier wird sehr viel mit Amber und Pharo gearbeitet und es gibt Initiativen hin zu einer Versionsverwaltung in Tools wie git oder subversion.

Der Mond über GemStone ist also ganz sicher nicht erblasst durch diese Ausgründung. Im Gegenteil, wir werden sicher noch viel Ineteressantes über GemStone hören in den nächsten Monaten. Die erste Etappe hierzu wird sicher die im Juni stattfindende STIC 2013 in den USA sein, auf der GemTalk dabei ist. Auch MagLev wird GemTalk weiterführen, und was uns Smalltalkern sicher am wichtigsten sein wird: es wird weiterhin ein kostenloses GLASS geben.

Die Ausgründung von GemTalk Systems steht nicht alleine da. Erst vor drei Jahren passierte bei Instantiations, dem Anbieter von VA Smalltalk, etwas ganz ähnliches: die Firma stiess ihr gesamtes Java-Produktportfolio samt Entwicklungsmannschaft an Google ab, und führte ihre Geschäfte als reine Smalltalk-Firma weiter (Joachims Small World berichtete). Seither hat sich auch an dem Produkt mehr getan, als in den Jahren zuvor.

Smalltalk scheint also nach wie vor eine Umgebung zu sein, in der es sich lohnt, zu investieren. Alle drei wichtigen kommerziellen Anbieter (Cincom, GemStone und Instantiations) scheinen profitabel zu sein und arbeiten fleissig an ihren Produkten. Auch im open source-Umfeld tut sich eine ganze Menge, angefangen bei Pharo, über Amber bis hin zu Squeak und GNU Smalltalk.

Um einen der abgeklopfteren Sprüche berühmter Persönlichkeiten zu bemühen: Die Gerüchte über das Ableben von Smalltalk sind noch immer völlig übertrieben….

Zum Abschluss noch ein paar weiterführende Links:

• “New Home for GemStone/S and Wavemaker” auf dem the VMware Company Blog
• “GemTalk Systems Acquires GemStone/S” auf Dale Henrichs’ Blog
• Unsere Podcast-Episode zu Gemstone/S und GLASS mit Norbert Hartl (in deutscher Sprache!)

Glorp Wisdom (pt. 313): Never make two collections exclusive that can share objects

(Please note: the problems described here are not limited to Glorp. This is an issue to keep in mind in all O/R mapping technologies, not only in Smalltalk. What I’m talking about here is also relevant in other languages and frameworks. It just fits nicely into the Glorp Wisdom series)

Some days are even worse than you might think (see the last installment in this series), because they make you shake your head and pray that at least this last stupid error was not yours.

In this case, it was. As I’ve mentioned before, marking a OneToManyRelationship in Glorp to #beExclusive can cause problems if you want to move the object from one such collection to any other collection or even a 1:1 relation.

Looking a bit deeper, this error is quite pardonable compared to an even dumber one:

Never mark two (or more) OneToManyRelationships as exclusive if they could ever share objects.

Why, you ask? Glad you do, because it makes me feel a bit better. Because as I said in pt. 312, teh object will be relentlessly deleted if it is removed from one of the two collections. No matter if you intended it to remain present in the other one, Glorp will be ruthless (because you told it to be, not because it is a bad guy) and kill it. Forever.

Okay, you think that’s obvious and clear and not worth mentioning, and this would never happen to you. I bet you are wrong!

Because object models evolve. What once was clearly a case of “if it’s not referenced by this object, there’s no use in its existence, ever” may one day look completely different. You may add some 1:m relationship for performance reasons, or you may simply look at another aspect of your business model for a new feature and have the same idea: “well, if it’s removed from here, than it cannot be anywhere else”. Unless it can for reasons that are long forgotten or just not in your focus today.

After the experiences I’ve had today, I’d tend to say #beExclusive should be avoided as long as possible. It does make sense in some cases, but only if an object in an exclusive relationship really is onle related to its containing object and cannot be referenced from anywhere else. And even if you think that is clearly the case in your project, be careful!

Why do I say such stupid things? Because if you have a few thousand unreferenced objects in your database after a while of operation, you can always delete them or simply let them linger a little longer. Storage is cheap. Maybe you’ll finde a bug one day and be glad there are ways to recover their references and build some highly complex SQL code to get them back. An unreferenced object in the DB will not disturb your application’s operations and not get in your way.

If Glorp, however, deleted too many objects because of your mapping error, you may have trouble recovering any data. And it can take months and years to find this problem.

I’m in the flow today, so I’ll give you another word of wisdom for free:

Always act as if you had no relationship mappings, foreign keys or contsraints like ON DELETE CASCADE and clean up your backpointers and stuff in the application instead of relying on some “obscure” database functionality. Clean up on the object side and make sure objects that shouldn’t reference an object, really don’t, rather than assuming the database will do it anyways.

If you follow this rule, there are multiple benefits:

• Your objects in the image reflect the situation in the database much better. The objects in the image may look good before and after a commit, but once you read them back in another session, the situation may be completely different
• Hunting for issues becomes much easier because you can watch what is being de/referenced in the debugger. There is no magic hidden in an ORM layer or even the Database (which is not even visible in an SQL log…)
• Your application is better suited for moving it to other storage techniques, be it simple serialization, NoSQL databases or an OODB system, because these all have no equivalent for constraints like #beExclusive

 

Glorp Wisdom (pt. 312): Don’t reuse objects in exclusive relationships!

There are days when you hunt for a bug and almost are close to giving up. On some of these, it’s best to go home, play with your kids or watch a good movie and start again the next day.

On some, however, you finally find out teh whole problem was just a case of programmer’s stupidity at work.

I won’t tell you what kind of day today is for me, but I’ll share some words of wisdom with you:

Don’t use objects in an exclusive OneToManyRelationship and move them into another collection. You won’t like the results.

Want more details? Okay, my friend, let’s sit down and I’ll tell you all about it.

In Glorp, you can define a 1:m relationship to #beExclusive. This makes a lot of sense (that’s why many other ORM Frameworks have the same ability, maybe named a bit differently). What it means is that if an object that holds on to an exclusive relationship (or better: a collection of related objects) and gets deleted, all these objects will be deleted as well. Exclusive in that context means: the objects in this collection cannot exist withou the objext that holds them.

There is, however another way to look at it: it also means that if the programmer removes an object from this collection, it is not going to exist on its own any more. At least not after a commitTransaction.

So far, all of this makes sense.

Enter Joachim (you may guess right now which kind of day I had today).

Because all of this also means that there is aboslutely no sense in moving this object into another exclusive collection. Because you said it’s doomed. It’s gonna be doomed, no matter what. The object may be reachable from other collections or stuff, but an exclusive collection says: if you leave me, you die. It really is that simple. Glorp is gonna delete it, and never going to update it to reflect its membership of another collection. That would make sense if the object wasn’t coming from an exclusive collection, but, hey, it does!

So if you use exclusive collections (and I do because it makes sense in my business case), always take care what you do with your business objects. Moving it to another object’s collections won’t be reflected by updating it’s foreign keys, even if you do all backpointering and stuff correctly. Glorp’s answer will ALWAYS be a DELETE statement.

So moving an object from one exclusive collection to another always has to be done by removing the original object from the first collection and creating a new one for the other. You may copy references and attributes, even non-exclusive OneToMany collections to this new instance, but the object itself has to be a new one.

Smalltalk GSoC-Teaser

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. 

…and now for my Glorp on VAST error handling rant.

I’ve written in my previous post about a debugging session that took longer than necessary for two reasons: my stupidity and a combination of several unfriendly factors. So let’s continue our journey up through my walkback of today’s image crash.

Once I figured there was no Seaside problem in the crash, I scrolled further up through the walkback and what I found there really made me upset about the error handling in Glorp (I was also upset about myself and the fact that I had just spent an hour for nothing). Just about 1500 lines towards the top of the walkback was this:

ExceptionalEvent>>#signalWith:
  receiver = Exception: Database error
  arg1 = AbtError:  rc=-1 for '57016' in an AbtIbmCliCSDatabaseConnection at (12.12.2012 11:25:20)  '[SQ
LSTATE=57016 - [IBM][CLI Driver][DB2/LINUXX8664] SQL0668N  Operation not allowed for reason code "7" on 
table "MYTABLE".  SQLSTATE=57016
 [Native Error=-668]]
'
[] in VADatabaseAccessor>>#loginIfError:
  receiver = a VADatabaseAccessor
  blockarg1 = AbtError:  rc=-1 for '57016' in an AbtIbmCliCSDatabaseConnection at (12.12.2012 11:25:20)  '[SQLSTATE=57016 - [IBM][CLI Driver][DB2/LINUXX8664] SQL0668N  Operation not allowed for reason code "7" on table "MYTABLE".  SQLSTATE=57016
 [Native Error=-668]]
'

Holy Moly! So this was the cause of my problem. I had altered MYTABLE in some schema migration routine and the table needed reorg. This is easy to handle once you know it needs to be done: fire up some DB2 client and do a REORG TABLE MYTABLE.

But what is Joachim complaining about? It’s his job to know what he did to the database, not Glorp’s…

I am complainning about the fact that Glorp simply obfuscates a very clear error message. Remember what the walkback started with? If you forgot, here are the first lines of the walkback:

Walkback at 11:25:20 on 12.12.2012
Database error: 
    [] in AbtHeadlessRuntimeStartUp class>>#outputWalkback:process:  
    ...etc...

That’s what I am complaining about. I could have fixed the problem in just three minutes if the walkback told me what’s wrong.
DB2 tries hard to tell the stupid programmer what’s the problem. AbtIbmCliDatabaseConnection>>#fetchNextRowFromCursor:ifError: hands this exception on to its caller, and Glorp (or better, the VAST port of it) simply takes that message and puts it into the dustbin or keeps it as a secret. Eat this, programmer!

This is due to some strange error handling code that comes from the original Glorp implementation. It has to be adopted to VAST, because the adaptation that was done in the original Glorp code is defunct. I tried to fix that on my more than once, but only found another problem in VAST that completely befuddled me so I gave up. Whatever I tried, something didn’t work. That problem can be fixed very easily, and I think it will be integrated into VAST soon, but it isn’t yet.

So this is my rant about the current VA ST Glorp port and its error handling mess. Other than that, I must say Glorp is stable and works very well, even if the VAST version is a few versions behind.

Ah, before I forget it: After a reorg of the table it seems my application runs fine and I am in the middle of testing and fixing.

How to waste less time debugging a Seaside/Glorp application

Yesterday I packaged my Seaside Application for the first time on VA Smalltalk 8.5.2 and deployed it to a staging server.

And promptly – as expected, I got some errors: The first few were easy to find. One of them being a missing rule in AbtXDSingleImagePackagingRule (or some superclass) to include the new EsTimeZone code. That could be fixed by hand.

But this morning I spent quite some time searching for a problem in the walkback.log that didn’t exist. And this post is mostly intended for myself to remember next time. But it might also save you some time. The second purpose of this post (or, to be exact, the next one) is to underline why I think the VAST port of Glorp has a lousy adaption of error handling.

But let’s start at the beginning: My image crashed as soon as a web user logged on to the web application. The image exited with Error code 60 and wrote a walkback log. So far, so good. The first thing this tells me is that my error handling code is not perfect yet, because I should have seen an error page instead of an HTTP-503.

So I started reading the walkback. My usual way of doing so is to start with the beginning of the walkback:

Walkback at 11:25:20 on 12.12.2012
Database error: 
[] in AbtHeadlessRuntimeStartUp class>>#outputWalkback:process:  
    receiver = AbtHeadlessRuntimeStartUp  
    arg1 = 'Database error: '  
    arg2 = Process:Dispatch worker: 8{running,3}  
    temp1 = 'walkback.log'  
    temp2 = a CfsWriteFileStream
BlockContextTemplate(Block)>>#valueWithErrorHandler:oldHandler:onReturnDo:  
    receiver = [] in AbtHeadlessRuntimeStartUp class>>#outputWalkback:process:
   ... and so on

So one thing was for sure: this is another one of those useless error messages that come from Glorp. Unfortunately, I decided to skip step two of my usual