If you are interested in poking around in the source code for the GemStone port of Monticello, Seaside, or SqueakSource then you should cruise around GemSource. The site was just brought on-line this afternoon and it will be our primary repository for GemStone/Seaside source as we move forward.
GemSource is ‘read only’ at the moment, but as soon as we start the Beta, we’ll open up access to the site for all users and projects. If you are interested, I encourage you to register for an account, so you can view the package contents from the comfort of you own Squeak image.
If you do decide to take a look from Squeak, you’ll need to make the following change to MCClassDefinition>>kindOfSubclass in your Squeak image:
kindOfSubclass
type = #normal ifTrue: [^ ' subclass: '].
type = #words ifTrue: [^ ' variableWordSubclass: '].
type = #variable ifTrue: [^ ' variableSubclass: '].
type = #bytes ifTrue: [^ ' variableByteSubclass: '].
type = #weak ifTrue: [^ ' weakSubclass: ' ].
type = #compiledMethod
ifTrue: [^ ' variableByteSubclass: ' ].
type = #transient ifTrue: [ ^ ' variableSubclass: ' ].
self error: 'Unrecognized class type'
I’ll be checking that change into SqueakSource in a day or so.
I’m only a third of the way through the “Make It Work, Make It Right, Make It Fast” cycle, so it would be premature to incorporate any of my changes into the Squeak version, but if any Seasiders, see something interesting or odd, don’t hesitate to let me know. I’ll take credit for the interesting bits and find some excuse for the odd ones.
Right now, GemSource is running with a single GemStone Seaside VM (behind Apache) and a maintenance VM (as described in Porting Application-Specific Seaside Threads to GemStone).
In the coming weeks, I will use GemSource as the sample application when I describe a technique for dealing with long-running HTTP requests, and I describe how to avoid concurrency issues when moving an application to multiple VMs.
I know of at least twoone funky problems with the site: wierd component nesting in some cases and the handling of batched lists is broken. Both of t. These problems are directly related to the fact that GemSource was ported from an earlier version of Seaside (2.3 or older). I may need a little help from a Seaside expert to figure out how to fix these two problems (hint, hint…).
In other cases, some html has leaked into the page – again this is due to the change in behavior between Seaside2.3(?) and Seaside2.6. These problems will be fixed shortly.
If you notice anything else that is odd, drop me a line at our Beta mailing address (see GLASS) or submit a comment to this post.
Updated (5/26/2007): With Philippe’s help I was able to fix the broken batched list problem and I’ve updated the site.
(gem)Stone Soup 
11 comments
Comments feed for this article
May 24, 2007 at 2:51 am
Philippe Marschall
The batched list error looks like a problem with #children (probably not implemented correctly).
May 24, 2007 at 3:00 am
Philippe Marschall
Some small observations:
– your Monticello seems to use LF instead of CR in log comments
– Seaside2.6g1-dkh.83 has a broken ancestry, this might cause problems with merging. Same goes for Seaside2.6g1-dkh.74.
May 24, 2007 at 12:30 pm
Dale Henrichs
Philippe, thanks for the feedback!
I’ve updated my version of Monticello to start using CR in version comments. There was also a problem in my version of SqueakSource that I have fixed as well.
As for the broken registry, I’ve got a couple of spots where that happened – it’s what I get when I try to commit versions using a doit…
I’ll go after the batched list error next … I think you’ve given me enough to go on.
Thanks again.
May 25, 2007 at 11:02 am
Dépot Gemstone at #doesNotUnderstand:
[…] Gemstone a ouvert un dépôt (repository) de code pour son initiative GLASS sur un serveur Monticello dédié. Pour rappel, GLASS signifie Gemstone + Linux + Apache + Smalltalk + Seaside. […]
May 31, 2007 at 8:37 am
Monty Williams
In case you’re curious, seaside.gemstone.com is running in a virtualized Xen domU with 768MB of RAM and a 20GB disk image. The underlying hardware is a dual-processor Opteron 252 2.6GHz with 2GB of RAM which also runs GemStone’s other external websites, mail, a Confluence wiki, and DNS.
June 2, 2007 at 2:03 pm
Philippe Marschall
I had a short look at the changes you did. The impression I got is that most of the changes are in your platform specific code and not the platform independent code of Seaside (any category but Seaside-Platform) which is good. The other changes seem to be:
you added:
WATableReport >> #reverse
which I in return added to 2.8
Then you changed:
Error >> #description -> #messageText
In the place where you changed it this was already in newer Seaside versions and it’s now in WAWalkback too (which you probably don’t support).
Some method categorizations (probably).
Newer versions of Seaside have almost all methods categorized.
Are these observations correct?
One particular thing I noted is that you changed the error handlers to not display a (partial) stack trace. I don’t know if this was made because of security considerations or Gemstone/S doesn’t support it. Have you considered making your own error handlers instead of modifying the existing ones? Not modifying the existing ones means less base Seaside code is changed which in term means faster and easier porting of new Seaside versions because the chance of a conflict is smaller. Personally I think using the same name for an error handler with different functionality is a bit confusing.
June 4, 2007 at 8:52 am
Dale Henrichs
Philippe, Thanks for your comments. I think you are pretty much right on.
You might want to look closer at the changes I made to WASession. I inserted logic into the session for overflowing WaSessions to persistent storage to reduce the load on the in-memory garbage collector. I originally put the changes into a subclass of WASession, then I moved them into WASession. I think that in the long run the changes I made should be isolated in a subclass of WASession – if people want to take advantage of that feature, they can subclass WAGemStoneSession…I’ll migrate in that direction before we open up the Beta.
As for the errorHandler changes, could you be more specific. On the one hand, I do remember from early on in the port changing the errorHandlers, but when I look in the code, I can’t find the place where I think I might have made the changes …
In principle, I agree with your points. I haven’t had the chance to pass back over the code and clean up the places where I took short cuts during the port.
June 9, 2007 at 3:04 pm
Philippe Marschall
Sorry for the long delay, moving flats an having no internet conn is not fun :(
I was talking about:
WAResponse class >> #internalError:
WAWalkbackErrorHander >> #handleError:
Looking at the code again I really think it should be split up into two different classes. WADevelopmentErrorDandler and WADeploymentErrorHandler or something like that.
June 11, 2007 at 8:52 am
Dale Henrichs
Okay, now I’ve got it …
The changes I made were in response to a comment that you had made to me in email regarding putting GemSource into production – “install an error hander that informs you and doesn’t scare users”. That’s when I added SeasidePlatformSupport>>logError:title:, so that I could save the stack to a log file and not ‘scare users’.
I like the idea of the separate handlers – in fact different applications may have difference deploment error handlers.
June 11, 2007 at 11:11 pm
Philippe Marschall
Yes, it’s the norm for a production error to have a custom error handler that matches the style of the website and displays no stack (behind the scenes often the trace is sent over email or logged to a file). That’s what I meant with install an error hander that informs you and doesn’t scare users”.
July 31, 2008 at 3:56 pm
GemStone Public Repository « The Trillionth Blog
[…] Public Repository May 24, 2007 GemSource is a Monticello code repository for GemStone. Their goal is to open up access to all users once […]