Re: [Help-smalltalk] [PATCH] first attempts at loading Seaside into GNU Smalltalk

[Lukas Renggli]

> I tried to load seaside into GST.  This was meant more as a stress test
> than a porting attempt.  Indeed I had a few problems (mostly my bugs,
> such as having more than 64 items in Undeclared and causing it to grow).

Great, lets get it started ;-)

> Other things I changed (but might be fixed in newer versions):

What version did you use?

> 1) symbols like #'?xml', #'!doctype', #'accept-charset', #'http-equiv'
> have to be expressed with quotes, otherwise RBParser does not like them

I can't find such symbols in my image. That probably has been fixed.

> 2) in WATableReport there is an instance of "aNumber-1" that I had to
> change to "aNumber - 1"

This is fixed in Seaside2.8a1-lr.408.

> 3) DateAndTime is called DateTime in GNU Smalltalk, and MessageSend is
> called DirectedMessage.

It is the easiest if you create a global that points to the right class names.

> 4) I disabled a few classes, WAKom (there is no Comanche), parts of
> WABrowser (there is no Browser), WAVersionUploader (there is no
> Monticello), WAScreenshot, as well as references to ImageSegment.  I
> also removed Exception>>#reactivateHandler.  Some of these should be
> handled by the Exporter, IIUC.  Same for Continuation which is in GST's
> basic image.

Code in the class and method-categories matching *-plattform or
*-squeak' are not supposed to be portable. What kind of exporting
mechanism are you using?

> 5) interesting one: WAInputDialog>>#renderContentOn: refers to a
> non-existing variable "message".

I think this has been fixed, I can't find it in my image. We try to
regularly run SLint on the code and this should catch that kind of
bugs.

> However, there is a bigger problem, that is the infamous zero/one
> argument clash on #ifNotNil:.  I can modify my compiler to automatically
> convert a zero-argument block given to #ifNotNil: and make it
> one-argument, but I'd really hate to do that.  Better, I can augment the
> converter with the possibility to apply refactoring browser rewriting
> rules, which would fix item 3 above.  I wonder though if Avi's exporter
> could do the same instead?

Of course this is almost a religious question. In my opinion the
compiler should accept both variations. Sometimes you want the
argument, sometimes not. VisualWorks also does it like this. The way
Squeak does it is certainly bad.

> (Or could Squeak fix this once and for all???...)

This will probably never happen. Multiple fixes have been posted and
nothing has ever happened: http://bugs.squeak.org/view.php?id=6426.
Also keep in mind that we have to keep portability with Squeak 3.7,
3.8, 3.9 and 3.10.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch