You are currently browsing the category archive for the 'Smalltalk' category.
[Update 3/16/2009: see the post GLASS Beta Update: Cooking with GLASS (Preview) for the latest preview information].
With the latest dev release of Pharo (pharo0.1-10243dev09.02.3), the new GemTools Client has stopped working correctly. From what I can see, a number of updates were made to OmniBrowser which causes the buttons to disappear from the OGLauncher….I stopped looking for additional problems at that point:). I’m not going to complain, though, the Pharo image is pretty cool already and it is still pre-Beta.
As of pharo0.1-10213dev09.01.3 (and probably pharo0.1-10236dev09.02.2.zip) the GemTools Client was working correctly. Until further notice don’t use the latest versions of Pharo.
I have been pretty busy fixing bugs recently and anticipate a refresh of the GemTools Client and the GLASS package in a week or so.
—–
[1] Photo by milomingo via Flickr (Creative Commons).
Sebastion Dietz wrote:
We are using Smalltalk (a rather old implemetation) for a logistics and foreign trade application with a bit over 500,000 lines of code (comments and empty lines excluded ;-) ).
Having worked with Smalltalk for 10 years now, I would not recommend it for larger business applications.
Smalltalk allows me to be agile, productive, my systems are maintainable regardless of all changes of business climate in recent years.
Unfortunately, Smalltalk is an effectively dead langauge to the majority of software shops out there (a real pity, too), relegated to the same dustbin which holds both Lisp and Forth.
Smalltalk is a language that makes true OO programming so cheap that you’re more often than not benefitting from a pure-OO (possibly with patterns) approach to coding for pretty much everything.
In short, it’ll take you, the programmer, substantially longer to implement a properly OO solution to any problem in Java than it would in Smalltalk.
So I’m not suggesting that we are going to see a massive renaissance in Smalltalk use in the near future. Today I still have a hard time recommending most mainstream IT organizations invest heavily in new strategic initiatives with Smalltalk.
If you are BIG fan of dynamics languages (closures, meta programming, and all that cool stuff) then consider giving Smalltalk a look. You might like what you see. Its like Ruby but with bigger muscles. You think Rails is cool? Check out seaside.
In my opinion, Seaside is the coolest thing going in web development
Recently I’ve had the good fortune to be exposed to Blain Buxton, a long time Smalltalker.
Stange talk of ‘messages’ and ‘images’ and crazy talk of changing objects on the fly without restarting anything. In fact, not even having the concept of an application to restart.
After some digging and reading, and after a nice demonstration using Squeak, I am starting to understand things and want to be in this lively Smalltalk world.
I use Ruby, I like Ruby, but Smalltalk is more productive when I’m working in unknown territory.
Smalltalk doesn’t have to be pragmatic, because it’s better than its imitators and the things that make it different are also the things that give it an advantage.
So, if you still haven’t tried Smalltalk, and I mean really tried it, by writing an application in it, give it a go. You’ll never regret it, because everything you learn, and you’ll learn a lot, you’ll be able to bring back with you to whatever language you call home.
Interesting, the corporate world may not be in love with Smalltalk, but for many developers Smalltalk becomes the language of choice (once they get to know it).
The fact is that there are a number of companies with significant and ongoing investments in Smalltalk. There may not be a ton of companies out there leveraging Smalltalk, but they are out there and not all of them are interested in letting the competition in on their secret.
But this post isn’t aimed at IT shops and corporations.
Smalltalk was designed to allow people (not just programmers) to express their creativity in the computing medium.
You don’t program in Smalltalk. You work in Smalltalk. You immerse yourself in Smalltalk.
Everything is an object and everything can be modified from within the development environment, including the tools and the web server. If you need to change the behavior of the web server (i.e., fix a bug), you can – the source code is in the image, easily accessible and the changes can be made without breaking stride.
The image provides built-in persistence for your application objects – no need to configure and manage separate programs to persist your data.
With the built-in inspector you can poke around your object graph. With the built-in debugger you can fix your code and explore the relevant objects. No context switch needed when you hit a problem whether it be a problem in the data base, a problem in your web server, or a problem with your application – the debugger pops up and you just continue with your development. It is a joy to accomplish things in Smalltalk.
For individuals and small groups of programmers (like MicroISVs) for whom productivity is important it can make a lot of sense to choose Smalltalk as the development/deployment platform. For a web application, the entire deployment stack can be built into a single executable program (the image): DB, configuration console and web server, all running within a single program – all written in the same language and all developed with the same tools. Here are several examples of Smalltalk-based deployment stacks in action (each download includes a Mac application, a Linux shell script and a Windows .exe file):
- AIDA6.0-beta1 (Aida; Squeak)
- Pier 1.1.1 (Pier; Pharo)
- Seaside One-Click Experience 2.8.3 (Seaside; Squeak)
Don’t you think it’s time that you gave Smalltalk a whirl?
——
[1] Photo by thebacon via Flickr (Creative Commons).
Norm Green made the following announcement on the GemStone/S customer forum – the invitation for attending the CAB meeting is extended to users of the free Web Edition:
Hello GemStone Customers,
Back in the 1990s, GemStone hosted an annual meeting of customers here
in Beaverton to talk about “all things GemStone”. This was a chance
to meet other customers, give feedback to us on things you like and
don’t like about the product, and talk directly with the Engineering
team. Since Smalltalk Solutions is not happening this year, we are
thinking of holding Customer Advisory Board meetings in May or June.
These would last for 2 or 3 days (something like Tuesday through
Thursday) and would occur here at GemStone headquarters or at a nearby
venue. We have several ideas regarding the format including tutorials
on GLASS and Seaside. We could do something like host a CampSmalltalk
around the same time as the CAB. The only cost to attend would be
travel and living expenses.
In order to move forward, we’d like to get an idea how many people
would be wiling to attend. If you think you could come, please send
me an email. While we’re not asking for a commitment to attend, we’d
like to know that there’s a pretty decent chance you’d be able to
come. Both 32 bit and 64 bit customers are invited and customers are
free to send more than 1 representative.
Looking forward to hearing from you!!
Best regards,
Norman R. Green
GM – Engineering
GemStone Systems Inc.
If you are interested in attending send send mail here or to Norm directly.
———-
[1] Photo by Thomas Hawk via Flickr (Creative Commons).
[Update 3/16/2009: see the post GLASS Beta Update: Cooking with GLASS (Preview) for the latest preview information].
As a few brave souls discovered, the process for updating to the new crop of tools is a little more complicated than it needs to be. A couple of them even got their fingers pinched during the update:).I was looking for feedback, so I appreciate the effort. Hopefully their sacrifices will be worthwhile.
There weren’t that many changes made to the OmniBrowser code in GLASS post GLASS.230-dkh.177, however, the changes that were made created havoc for any windows opened prior to the update. I had originally hoped that a couple of errors between friends would be okay, but enough people ran into odd problems during the updates to GLASS.230-dkh.182 and GLASS.230-dkh.183, that it became clear that the update process needed to be improved.
I tried a number of things including an attempt to work around the problems with the new GemTools Client code. I was successful in getting the new GemTools Client to run against the older versions of GLASS (which is a step in the right direction), but I wasn’t able to get around the crashes and walkbacks. With a nudge from Igor Stasenko, I finally settled on using an update script.
In the end I made two significant changes to the update process:
- Update the GemTools client before updating the server. In the past we’ve updated the server-side code first and then updated the client-side code. However, since we’re recommending that users move to a completely different client image, I think it is easier to get the client update out of the way before doing the server update, especialy now that the latest GemTools Client code will run against older versions of GLASS. Any problems in getting the GemTools Client built and connected to the server can be worked out before making changes on the server side.
- Update the Server using a script instead of the Monticello Browser. With this particular update, using a script is necessary since the windowing mechanism for the current session becomes broken during the update. In the long run, it is useful to have a script-based update mechanism that can be used to update production repositories that aren’t easily accessed through the GemTools Client.
Preview GLASS.230-dkh.187
Since GLASS.230-dkh.183 I’ve made a handful of improvements that are worth trying out:
- merge Pier-Model-lr.245, load Pier-Blog-lr.103.
- OSTestRunner bugfixes.
- debugIt implemented. debugIt opens a Debugger on the selected code, setting a breakpoint on the first statement.
- exploreIt implemented. exploreIt opens a Chasing Inspector on the result of evaluating the selected code.
- Remove MonticelloConfigurations as a required package.
If you’ve been following the mailing list, you will have noted that we’ve received a flurry of bug reports in the last week or so. I appreciate the bug reports, but because I intend to address a good number of them before the next beta update, the next update will be deferred for at least 2 more weeks.
1. Update GemTools Client: GemStone-dkh.355
If you choose to use Pharo as the basis of your GemTools Client, be sure to download the latest dev image as a starting point. As of today, pharo0.1-10211dev09.01.2.zip is the latest dev image. If you choose to use Squeak as your GemTools Client, start with a basic 3.10 image like Squeak3.10-7159-basic.zip.
Use the Universe Browser, select the GemTools-Client version 0.355 package (in Network category) and install it. Note that during the install using 3.10, you will be warned about an extension to OTToolset – is is safe to proceed.
Open a Workspace and evaluate the expression ‘OGLauncher open‘ and then edit the Glass session, inserting the login information that is relevant to your system – stoneHost, gemHost, stoneName and netLDI.
Login using the GemToolsLauncher and get ready to update the GLASS repository to GLASS.230-dkh.187. Note that during the login using Pharo, you will get a warning about using a deprecated #authorInitials: api – it is safe to proceed.
Even though the Class Browser and Monticello Browser are functional, I wouldn’t try to do too much work using the new GemTools Client and an old version of GLASS. For best results you should immediately update your GLASS repository.
I’ve used the new GemTools Client to upgrade GLASS.230-dkh.164 (corresponding to 2.3 release and the 1.0beta11 appliance) and GLASS.230-dkh.177 (corresonding to the 2.3.1 release) with good results.
Since I’m still actively working on the new tools, I don’t plan to publish a ‘one-click’ GemTools Client, until the rate of change has settled down.
2. Update GemStone Repository: GLASS.230-dkh.187
The following update script:
- Adds a method to SystemChangeAnnouncement.
- Turns off autoMigrate.
- Loads GLASS.230-dkh.187 from the GemSource repository.
- Sets autoMigrate back on.
- Performs a commit.
The code should be pasted into the workspace pane of a Gemstone-dkh.355 GemTools Launcher or run from a topaz session.
| httpRepository version rg | SystemChangeAnnouncement compileMethod: 'item: ignored' category: 'accessing'. MCPlatformSupport autoMigrate: false. httpRepository := MCHttpRepository location: 'http://seaside.gemstone.com/ss/GLASS' user: '' password: ''. "pick up the GLASS repository if it's already in default repository group" MCRepositoryGroup default repositoriesDo: [:rep | rep = httpRepository ifTrue: [ httpRepository := rep ]]. version := httpRepository loadVersionFromFileNamed: 'GLASS.230-dkh.187.mcz'. version load. rg := version workingCopy repositoryGroup. rg addRepository: httpRepository. MCPlatformSupport autoMigrate: true. System commitTransaction.
If you’ve used the GemTools Launcher to run the update script you should logout and then log back in before continuing with your work. If you use topaz to update the repository, you need to remember to use a GemStone-dkh.355 GemTools Client to connect to your repository.
The GemTools Client is still in preview, so unless you are brave and/or curious, I’d recommend that you stick with a more stable version of GLASS.
———-
[1] Photo by EricGjerde via Flickr (Creative Commons).
[Update 3/16/2009: see the post GLASS Beta Update: Cooking with GLASS (Preview) for the latest preview information].
Over the Christmas holidays my grandson Oscar and I got serious about tools.
Oscar learned how to use a drill and I built an OmniBrowser-based version of TestRunner to go along with the new GemTools Launcher.
GemTools Launcher updates
Gerhard Obermann has been busy working on the tools, too. He’s made a number of improvements to the Launcher:
- Empty and Show Object log menu items added to the Doit button.
- Added a Transaction button as a home for Commit and Abort.
- Tweaked appearance in a number of places.
To pick up Gerhard’s changes use the Package Universe browser to load GemTools-Client version 0.335. If you haven’t already loaded the tools preview, follow these instructions.
OSTestRunner
OSTestRunner is a clone of the Squeak TestRunner with the functionality molded to fit within OmniBrowser. OSTestRunner can be run in Squeak, Pharo or GLASS. Click on the image below for a full-sized view of the Pharo version.
To use with Squeak or Pharo, check out the instructions in the announcement message.
To load into GLASS:
- Follow the instructions for bringing up the tools preview (make sure you load GemTools-Client version 0.335 on the Squeak side).
- Log into GemStone (using the new launcher) and load GLASS.230-dkh.183 from the GLASS project on GemSource, using the GLASS Monticello browser.
- Logout and log back in to make sure that the client is updated with the new server classes and enjoy.
I’m still tweaking OSTestRunner for GLASS roundtrip performance and I want to have better user feedback while the tests are running, but other than that I’m happy with the new OSTestRunner – hey all of the menus and buttons work on the new version!
Monday, I’ll dive back into MC2 and will beat on the new tools (tweaking here and there), so you can look forward to a general release of the GemTools towards the end of the month.
[Update 3/16/2009: see the post GLASS Beta Update: Cooking with GLASS (Preview) for the latest preview information].
It’s been awhile since I’ve done a major overhaul of the GLASS tools, so it’s about time to get a new update of the tools into circulation. Even if it is a preview.
As reported a couple of weeks ago, I updated to the latest OmniBrowser package in order to get the MC2 UI to work. Technically, I’ve been on vacation the last two weeks, but a major snowpocalypse in Oregon put the kabosh on plans to head to Cannon Beach with the doggies, so I’ve found myself working on the tools.
OB-Standard
The first task was to update to the latest OB-Standard tools. In the last year a lot of work has been put into the OB-Standard tools. David Röthlisberger and Damien Cassou have been busy producing some pretty nice OmniBrowser-based tools. Besides merging the code, I fixed some long standing GemTools problems:
- window updating – now when you save a method in one window, the code will be updated in another window.
- window colors enabled.
- Version browser buttons.
- Monticello Patch browser menu includes browse, implementors, and senders.
- eliminate use of FileList for defining directory-based monticello repositories (too slow over GCI!) – now you just supply a path string.
- Gerhard Obermann enabled drag drop for method recategorization.
OB-Tools
Next on the agenda was to update to the latest OB-Tools. Lukas Renggli has implemented a full range of tools using OmniBrowser, including a Debugger, Inspector, FileBrowser, ProcessBrowser, Workspace and Transcript . So far I’ve integrated all of these tools except the Transcript – right now I use the client Transcript. Notable fixes and improvements include:
- inspectors embedded in debugger window – the new debugger almost looks like the debugger that your Grandpa used:).
- automatic context selection after a step in the debugger.
- eliminate the chasing inspector – replaced with a standard inspector. I think I’ll miss the chasing inspector though.
- out, through, and step to selection in debugger
- out steps until execution leaves the current context, either via return or by entering a block.
- through steps until execution returns to the home context (useful for stepping through block execution).
- step to selection steps until the selected step point is on the stack.
BTW, if you have free time and the inclination, Lukas is looking for someone to take over development of the OB-Tools. We are using and maintaining OB-Tools for GLASS, so I will be chipping in with fixes on an occasional basis, but I can’t commit to the task of Squeak-specific updates – at least right now.
Package Universe, Pharo and Mars
For this round of development, I started out using a Squeak 3.10 basic image (Squeak3.10-7159-basic). As a consequence, the formula for creating the GemTools client image was fresh in my mind so I decided to create a package in the Package Universe for the GemTools-Client. With the Pharo beta coming up and the recent announcement of Mars 0.1, it will be useful to allow folks to build their own GemTools-Client without needing to rely on us to supply the client image.
My first test of the GemTools Client package was to load it into Pharo and I’ve been doing my development in Pharo since then.
New GemTools Launcher
With the addition of the new OB-Tools, I needed to figure out a way to provide easy access to all of the new tools, since button real estate is in short supply in the existing Transcript window. I briefly considered replacing the World menu with a GemTools-specific world menu, but finally faced the fact that I’d need to rework the Transcript window from scratch.
I’ve been planning on reimplementing the Morphic windows in OmniBrowser for a long time, so I decided to rewrite the new window using OmniBrowser and do something with the Login window while I was at it. I combined the Login window and Transcript window functions into a single Launcher window. The screenshot below is from a Pharo dev image (click on the image for full size view):
There’s also a new OmniBrowser-based workspace window with a tabbed interface contrbuted by Gerhard Obermann.
The only remaining non-OmniBrowser window in GemTools is the Test Runner window and I’ll be taking a run that pretty soon.
Having all windows implemented with OmniBrowser is important so that native window UIs like Mars, which is implemented in Cocoa runs on top of OmniBrowser,can be used for GemTools.
Preview for the Brave and/or Curious
I am still working the new GemTools with about 10 items left in my ToDo list, but if you’re brave and/or curious and willing to provide feedback, then I encourage you to take the new GemTools for a spin. Once you have updated your GemStone repository to GLASS.230-dkh.182 or later, you will have to use the new tools – the old client tools will no longer be functional.
First you’ll need to update to the latest GLASS package on the GemStone side (GLASS.230-dkh.182 found on GemSource):
- Before loading GLASS.230-dkh.182 you need to
- evaluate the following expression in a GemStone workspace:
- SystemChangeAnnouncement compileMethod: ‘item: ignored’ category: ‘accessing’.
- turn off auto migration.
- evaluate the following expression in a GemStone workspace:
- After the package has loaded (if you are using the Monticello Package browesr), you’ll get a walkback complaining about #refresh. Close the walkback, press the commit button [updated 1/4/2009], and shut down your old GemTools image.
Remember once you have updated your GemStone repository to GLASS.230-dkh.182 or later, you will have to use the new tools – the old client tools will no longer be functional. This is where the brave part comes in.
Now you need to prepare a new GemTools client image. I’ve used Squeak 3.10 vm with the Squeak3.10-7159-basic image and the Pharo vm with the Pharo-Dev 10185 image (at this writing Pharo-Dev10196 is the latest dev image). I haven’t tried 3.9 yet, but I have no reason to believe that there will problems loading the code. Once you’ve downloaded and launched the base image of your choice:
- Open the Package Universe browser (Universe browser a couple of menus deep in Pharo).
- Click on update list from network.
- Open the Network category.
- select GemTools-Client version 0.324 or later (ignore the GLASS Client packages – I was having trouble with getting the packages defined).
- Click on select package.
- Click on Install Selections.
- When the load is done, evaluate ‘OGLauncher open’ in Squeak workspace.
- Click on the Edit Session menu item with the Glass session selected and fill in the login information.
- Alternatively, use the New Session menu item if you need to add more login information than provided by the Basic template.
- click on the Login button and have fun.
I’ve only been using these tools for several days, so I am very interested in feedback. If you run into walkbacks or are simply confused by the new interface submit a comment to this post, or send mail to the Beta mailing list (you have to join first). If you have no problems, that would also be useful to know.
I will be continuing to work on the new tools for the next couple of weeks so its worth checking the Package Universe every once in a while to see if I’ve published a new version. Also be prepared for changes to the way some of the tools work.
I expect to make a general announcement of the new tools in 3-4 weeks – I’m hoping to get the Test Runner into OmniBrowser and take a run at the OB-Enhancements and OB-Refactory before all is said and done. I’ll have to update the Terse Guide to the GLASS Tools.
Don’t forget to send feedback!
and… Merry Xmas!
——
[1] Photo by jsalvino via Flickr (Creative Commons).
When we last left our weary traveler, he was so close to getting performance results for Single Session per VM, that he could almost taste it. Alas, a perfect storm converged on his cube and months later he remains no closer to those tasty morsels than when he started.
GLASS.230-dkh.177
Though stalled on the scaling front, since the release of 2.3 the most interesting thing is that SIXX has been ported to GLASS and is included in GLASS.230-dkh.177. Note that GLASS.230-dkh.177 isn’t the latest version of the GLASS.230 package, but it is the recommended version.
SIXX (Smalltalk Instance eXchange in XML) looks like it will be useful for moving object graphs from Squeak to GLASS (and vice versa). In late September, Norbert Hartl was wondering how to get the data from the RDB used in his Squeak-based Seaside application (using GLORP) into GemStone and in the ensuing conversation it came up that SIXX would be a good candidate and the race was on. At this point I think that Norbert has been able to transfer his data from the RDB into GemStone.
A number of bugs have been fixed in GLASS.230-dkh.177 as well:
- GLASS bugs:
- fix bug 39539 – ‘Sixx errors in seasidetst’
- fix bug 39513 – ‘#withBlanksTrimmed and _matchPatternNoCase: not implemented in QuadByteString’
- fix Bug: 39574 – ‘MASelectorAccessor>>createVariable: problematic when instances on execution stack’
- Pier bugs
- fix http://code.google.com/p/pier/issues/detail?id=1
- fix for http://code.google.com/p/pier/issues/detail?id=53
Other News

If you’ve been following my checkins on GemSource or if you’ve been reading my tweets, then you know that I’ve been busy with a couple of projects over the last few months.
GLASS.231
The first project to blow into town was SOAP. A customer of ours was interested in using SOAP with GemStone so I ported SoapCore to GLASS. As part of the effort I updated the SOAP-Examples to include some new interoperability tests.
I was able to find SOAP 1.1 servers still running at 4s4c, Microsoft Soap Interop Server and EasySoap++. Predictably, not all of the tests passed. The errors occurred in the way that exceptional values and errors were handled by the server (i.e., not the client’s fault:). The parts of the tests that ‘drove down the middle of the road’ passed against all three servers. Also predictably, I found and fixed subtle bugs after adding tests for each new server.
The main item left undone is to integrate the new versions of Hyper with Seaside. Until that task is finished, SOAP will have to live on its own branch.
GLASS.MC2
Just as I caught my breath with the SOAP work, Monticello2 (MC2) popped up on the radar. This time it was Julian Fitzel blowing into town and the town was Vancouver, BC. Julian was planning on talking to Colin Putney about MC2 and Seaside2.9 and I was interested in participating in that conversation.
Seaside2.9 has been broken up into a whole bunch of components and the dependency graph for the components is pretty complicated. For the short term, Seaside Universes will be used, but the longer term belongs to Monticello2.
I’ve been searching for a configuration solution since at least last March, but haven’t found a good solution in Monticello(1). I want something better than the GLASS package that I currently use to communicate configuration information. MC2 looks like a very good candidate.
In preparation for the conversation with Julian, Colin, and Avi, I decided that it would be a good idea to port MC2 to GLASS. I finished the initial port in a couple of weeks (in time for the meeting) and have continued working on MC2 since then.
The most recent diversion came in the form of OmniBrowser. In order to get the last bits of the MC2.0.29 UI working, I needed to update to the latest version of OmniBrowser. Since I was building a new version of the GLASS client, I decided that it might as well be based on Squeak 3.10.
As of yesterday, I have been doing all of my development using the new GLASS client. Overall, 3.10 appears to be more stable than 3.9 (I have yet to have the UI fritz out on me when I close a debugger). It’s not completely free of bugs, but I think I can actually fix the bugs that I have been seeing.
I plan on continuing doing development for MC2 and the new GLASS client in a separate branch of the GLASS package. Once I feel that the tools are stable I will merge the new OmniBrowser code into the main GLASS package branch.
Seaside2.9
Finally, I haven’t spent much time in the last several months on Seaside 2.9. We have a functional port, but it hasn’t been updated for several months. Seaside 2.9a1 was announced last month and 2.9a2 is imminent so we will have to get our butts in gear. James is looking forward to spending some quality time on Seaside2.9 very soon now and I’ll make time for Seaside2.9 before the end of January.
——
[1] Photo by Telstar Logistics via Flickr (Creative Commons).
Niall Ross (via James Robertson) has written a comprehensive and detailed report on most (if not all) of the talks at Smalltalk Solutions, ESUG and the VASmalltalk User Group Conference in Frankfurt. Even if you attended one or all three of the conferences, it is worth reading Niall’s notes, since he may have picked up on something you missed.
——
[1] Photo by eMaringolo via Flickr (Creative Commons).
For the last month or so since the International Smalltalk Developers Conference, I have been busy working on the Single Session per VM project trying to get to the point were I can validate the approach. It was straightforward to make the necessary changes to Seaside, but I literally spent more time trying to figure out how to get session affinity to work with FastCGI in lighttpd.
Once I had the basic prototype working I needed to really hammer the server, but neither siege nor jcrawler does a good enough job (siege doesn’t crawl a site and jcrawler sends concurrent requests for the same Seaside session) so I started work on a Seaside-aware load testing tool called scrawler. Scrawler needs a a real good HTTP client and the HTTP client (HyHTTPClient) in the latest version of Hyper from Bruce Badger is perfect – which explains why I was porting the latest versions of Sport and Hyper to GLASS last week.
Over the weekend Dario Trussardi reported a problem with MAFileDescription which turned into Bug39648 and a few other GemStone-specific issues related to MAExternalFile model. By Monday, I’d resolved Dario’s problem and I figured what the heck, while I was in the neighborhood I might as well merge in the latest Magritte code from Lukas. And while I’m merging code from Lukas, I might as well pick up the latest code for Scriptaculous and Pier.
The ink wasn’t even dry on my Pier merge, when I received mail from Doru, announcing Pier 1.0.17. Talk about synchronicity. Had events (spanning the globe) been conspiring all month long to converge at this moment in time?….Nope, but we do have a pending final release for GemStone/S 64 version 2.3, so I got my giddy up on and updated to Pier 1.0.17.
After the smoke cleared, I ended up including a number of new packages in the GLASS package:
- Pier-Design-tg.5, Pier-Documents-lr.7, Pier-Google-lr.5, Pier-LightBox-dc.6, Pier-Randomizer-lr.4, Pier-TagCloud-lr.11, Pier-Titles-tg.1, Pier-Twitter-lr.7 Pier-Setup-tg.30 to conform with Pier 1.0.17.
- XML-Parser.g-dkh.14 for Pier-Twitter support.
The following bug fixes are also included in this update:
- Bug39648 – FileDirectory>>forceNewFileNamed: doesn’t ensure creation of subdirectories.
- Bug39357 – appliance 1.0 beta10 gems get commit conflicts on first startup.
- Bug39413 – ‘Magritte implements #description: which interferes with subclass creation’.
- fixed duration string generation (RSRSS2) from Philippe Marschall.
- MAFileDescription upload problem reported by Dario Trussardi.
The update is published as GLASS-dkh.122 (2.2.5) and GLASS.230-dkh.162 (2.3 beta 2 or 1.0beta10). These two versions can be used with GemStone-jgf.291 (Squeak client) or later. All of the versions can be found in the GLASS project on GemSource. If you are running with a version of the GLASS package that is earlier than GLASS-dkh.118 or GLASS.230-dkh.146, then you need to follow these instructions first. After loading the GLASS package you should evaluate the following two expressions in a workspace:
- MADescriptionBuilder initialize.
- PRDistribution new register.
The first expression picks up some new initialization code and the second expression installs Pier 1.0.17 as a Seaside application.
In GemStone-obi.293 Gerhard Obermann changed the layout of the Transcript Window to allow more buttons, added a Find Substring button, and arranaged for SHIFT-click on the Debug button to empty the Object Log. Personally, I’ve moved to this version of the Squeak client as I think it is an improvement.
If you are running in 2.3 beta 2 or 1.0beta10 then you only need to load GemStone-obi.293 into your Squeak client, save the Squeak image and you are done.
If you are running in a 2.2.5 repository then you have a couple of options:
- Download the single-click Squeak client for 2.2 (download) from GLASS downloads and then load GemStone-obi.293. RECOMMENDED.
- Update your existing Squeak image (presumably using GemStone-dkh.283)
- start the Squeak client image.
- load GemStone-obi.293.
- save the image and exit.
- copy (or use a symbolic link) the GCI library (location in top pane of the Login Window) to a file named gciForLinux.so, gciForMacintosh.so or gciForWindows.dll, depending upon your client platform.
- restart the image and log in to GLASS.
Keep an eye out for the announcement of the final release of GemStone/S 64 version 2.3 [update 10-25-2008] which should be coming soon.













