You are currently browsing the category archive for the ‘pier’ category.
[Updated: 1/4/2010] If you are interested, you should also check out the discussion on the Seaside list.
Pier version 188.8.131.52 fixes a couple of GemStone portability issues.
MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [ [ Gofer project load: 'Seaside28' version: '184.108.40.206'. Gofer project load: 'Magritte' version: '220.127.116.11'. Gofer project load: 'Pier' version: '18.104.22.168' ] on: Warning do: [:ex | Transcript cr; show: ex description. ex resume ]].
I recommend that you specify explicit versions when you load, because the default version of intermediate projects may not be exactly what you expect. By explicitly loading a version you will have fewer surprises.
Note also that I’ve wrapped the standard Gofer project load messages with a handler for Warnings that dumps the warning message to the Transcript and then resumes execution. The #commitOnAlmostOutOfMemoryDuring: method will do just that … it creates and enables an AmostOutOfMemory signal handler that performs a commit when you are almost out of memory – quite convenient for any operation that might run out of memory on you.
At this point in time, I think that the GemTools Launcher (GemStone-dkh.441) and the OmniBrowser tools are stable enough that you no longer need to be Brave and/or Curious to take the new tools and GLASS.230-dkh.209 for a spin. In fact the tools are probably in better shape now than they’ve ever been (I haven’t seen the MNU storms that would periodically appear in the old client for quite awhile). If you’re reluctant to upgrade, check out the new Backup/Restore commands. Being able to backup/restore your repository from the GemTools Client should ease your mind.
I still have between 50 and 100 issues that I want to address (mainly on the server-side) before the next beta release. In the mean time, I am all but done with the UI changes and I would like feedback from folks on the new commands. If you haven’t already, join the beta mailing list and send mail with your comments and suggestions.
If you run into (gasp!) a bug, use the new Bug Report commands to report the bug. Honestly, I would rather have people report 100 duplicate bugs than miss 1 valid bug report – don’t assume that I know about the problem!
There have been a significant number of changes to the GemTools Client since the last preview release, so many that I decided to update the old Terse Guide to the GLASS Tools with a new post: Terse Guide to the (new) GLASS Tools. All of the menu items for the GemTools Launcher are documented.
If you haven’t already created a new GemTools client smalltalk image, then follow these instructions.
If you’ve already updated to a preview release, then you’ve already got a new Squeak/Pharo image and all you need to do is to update to the latest version of the GemTools Client, using these instructions.
Take a look at the GemTools change log for a complete history of the changes made between GemStone-dkh.355 and GemStone-dkh.441.
In addition to the support needed for the GemTools Launcher a number of bugs were fixed:
- Bug39820 – packages dirtied unnecessarily when recompiling subclasses
- Bug38105 – HTTPSocketError not correctly loaded
- Bug38794 – Subclass creation method leaves instance creation disabled
- Bug39838 – ExceptionA class>>hasFixFor39741 breaks some things
- Bug38146 – unload class and remove method should clean up undeclared sybmols
- Bug39798 – UndefinedSymbols is not maintained correctly
- Bug39850 – MCPackageBrowser doesn’t update when package dirtied
- Bug39345 – ‘Squeak browser tools need move-to-category button’
- Bug39578 – ‘”revert to version” in “Versions of” method browser does not autocommit’
- Bug39303 – sorting of change list in Monticello brower is strange
- Bug39823 – missing OSkSocketReadStream>>upToEnd
- Bug39800 – SeasideTesting has probably decayed…
- Bug39777 – Cannot ‘browse’ ProtoObject without a walkbalk
- Bug39772 – Class>>allSubInstancesDo: always fails
- Bug39582 – lots of key-not-found errors using Vocabulary browser
- Bug38140 – ‘highlight inspect’ feature for debugger
- Bug38274 – need visual separation between ancestors in MCWorkingCopy>>summary
- Bug38304 – CTL-i on a String or Smallinteger ends up with Squeak inspector
- Bug39662 – Inspecting a float in GLASS results in a ‘Float out of Range’ error in Squeak
- Bug39827 – missing base method for GLASS
- Bug39795 – MAPriorityContainer>>remove: fails unexpectedly
Other highlights include:
- A belated update to Seaside2.8.3.
- Update to Pier 1.1.1.
- Improved Debugger, Inspector, and Chasing Inspector.
The following packages have bee removed from the GLASS package:
These packages are not automatically removed by the update process. If you aren’t using them, then you should manually unload them using the Monitcello Browser. If you don’t remove them you may see test failures for the UndefinedSymbolsTest and SentButNotImplementedTest. After removing the above packages the tests should run clean (4182 run, 4182 passed, 0 failed, 0 errors).
Once you’ve updated to the latest version of the GemTools Client, follow these instructions to update the GLASS server software to GLASS.230-dkh.209.
Take a look at the GLASS change log for a complete history of the changes made between GLASS.230-dkh.187 and GLASS.230-dkh.209.
Over the last week I didn’t have a lot of time to do very much with the Pier installation other than set things up so that Seaside would be safe on the open internet:
- Remove all of the default Seaside apps, except the object log.
- Add authorization to the object log. The object log is too useful to remove, but since you can get easy access to the inspector via the object log, it has to be sealed off.
- Using the config editor for the object log, add WAAuthConfiguration as an Ancestor, then set the Login and Password.
- Set deploymentMode to true for pier, config and object log.
- Change all of the passwords (pier, config and object log).
My wife enjoyed herself writing articles and uploading pictures. We don’t have a domain name yet and we turn off lighttpd when we’re not actively using the site.
Today I finally found some time to play with Pier and take a chunk out of my todo list:
- Update to the latest GLASS package (GLASS.230-dkh.176 – still waiting for feedback from Dario, but I thought I’d go ahead and load it on my wife’s site)
- Fix a bug my wife found in the Pier-Blog package.
- Do a bit of repository cleanup.
- Convert the instances of MAMemoryFileModel to MAExternalFileModel,
The first thing I want to mention is that with a production site, it is a real good idea to have a sandbox where you can do development without worrying about impacting production users. Our web site won’t have a lot of traffic, but my wife puts in a fair amount of effort working on content and I don’t want to lose her work, so I take a couple of simple precautions:
- Before making any significant changes, I make a backup of the extent file (/opt/gemstone/product/seaside/data/extent0.dbf). I shut down the stone before copying the file, but you can also use the runBackup script, which safely copies the extent file while the system is running.
- Using scp, I copy the extent to my sandbox system (a 64 bit laptop running a copy of the appliance).
- After shutting down the stone on my sandbox, I copy the extent file to the data directory and restart the stone. The copy is useful in case you do something regrettable.
- After validating the upgrade/update steps using the sandbox, I perform them on the production system.
When all was said and done, I ended up committing a new version of the GLASS package (GLASS.230-dkh.177) and creating two web-site specific packages (Pier-Model-dkh.241 and Pier-Seaside) that I saved in a directory-based repository.
Looking at the object log, I had seen that the repository had grown from 100M to 160M since we’d started, and I was interested in seeing what I could do to reduce the amount of space used:
- There were a couple of continuations stored in the object log that I could get rid of now that the bug that my wife ran into was fixed.
- I knew that the all of the Monticello packages are saved in the repository in the Monticello cache, so I was interested to see what could be gained by flushing the cache.
- While working out the details of converting from MAMemoryFileModel to MAExternalFileModel I noticed that we had some 500 entries in the PRHistoryPersistency. Each one of history entries hangs onto a WASession along with other things, so I figured that cutting the size of the history list to 250 (from 1024) wouldn’t hurt.
In the sandbox, I gained about 20M by doing the above cleanup steps, but some of the Monticello operations took noticeably longer (the cache had to be refilled), so I don’t think that flushing the Monticello cache is worth it.
Convert from MAMemoryFileModel to MAExternalFileModel
GemStone/S extent files get moved around a lot between the time that the Seaside extent is created on one of our build machines and the time an appliance is fired up or GLASS is installed on a Linux or MAC machine. This movement makes it extremely impractical to do anything that depends upon a fixed directory path and lead to my decision to make MAMemoryFileModel the default mechanism used by Magritte and Pier to manage it’s files for GLASS.
Once a system is installed in a production environment it is desirable to start using MAExternalFileModel, because you can arrange for your web server to serve up the files.
In our case, my wife had already uploaded a number of images as instances of MAMemoryFileModel, so I needed to convert the existing instances as well as change Pier to start using MAExternalFileModel.
The first thing to do is to edit PRFile class>>descriptionFile to replace MAMemoryFileModel with MAExternalFileModel.
Then you need to decide where you want the files to be stored. If you are using the appliance, then Apache serves files out of ‘/opt/gemstone/apache/htdocs’. If you are using lighttpd as set up by
The script below, illustrates the choices made for an appliance. The rest of the script grabs all PRFile instances and swaps in an equivalent instance of MAExternalFileModel. The final statement in the script flushes the MADescriptBuilder cache, otherwise you’ll continue using MAMemoryFileModel:
| pf fm xfm | MAExternalFileModel baseDirectory: (ServerFileDirectory on: '/opt/gemstone/apache/htdocs/files'). MAExternalFileModel baseUrl: '/files'. System commitTransaction ifFalse: [ nil error: 'Commit failed' ]. (PRFile allInstances select: [:each | each file isKindOf: MAMemoryFileModel ]) do: [:pf | fm := pf file. xfm := MAExternalFileModel new filename: fm filename; mimetype: fm mimetype; contents: fm contents asByteArray; yourself. pf file: xfm]. MADescriptionBuilder default flush.
This pretty much takes care of the major items on the todo list for my wife’s website.
I am playing with some code that generates real clean URLs for Pier (unfortunately, there are some gotchas for the moment). My wife has seen some java script effects on other sites that she’d like to be able to do on her site so I’ll there’s some java script in my future. When my wife is happy with the way things look, we’ll get that domain name we’ve had our eyes on:) and set up the google analytics.
I have to say that I’m real pleased with the Pier is working out for both me and my wife.
Last week Dario Trussardi submitted a bug report to the GLASS Beta mailing list (subscription required, but feel free to subscribe if you’re interested). The bug involved Magritte auto accessors – a feature whereby new instance variables (and accessor methods) are dynamically added to a class on demand. Dario was triggering the new instance variable creation during the rendering phase of a Seaside component and getting an Internal Server Error from Seaside:
InterpreterError 2403: Cannot commit, <‘a previous commit attempt failed with an error, this transaction must be aborted’>
This error doesn’t have the most intuitive explanantion and the stack dumped into the object log was rooted in the standard commit that occurs right before the HTTP response is returned to the browser – not much help.
I had tangled with the auto accessors before, in the Magritte unit tests, but Dario’s scenario wasn’t covered there. Dario provided a simple test case and I was off to the races. In the end I was able to fix the problem in Dario’s test case (at this writing I’m waiting for confirmation from Dario – when I get it I’ll publish a Beta Update), but I thought that it would be instructive to cover the issues involved in case anyone else wanders into this territory.
If you’re using Magritte auto accessors or are seeing 2403 errors or want to geek out on GemStone for a bit or have already settled down with a cup of coffee to “read another long post of mine” (yes I’m talking about you, Gera:), then by all means read on.
- #readUsing: and #writeObject:using:
- Magritte auto accessor and Seaside
Last week while I was on vacation, I got my wife interested in using Pier for her Saluki website. I used the latest appliance with Pier 1.0.17. We made some changes to Pier like setting up the menu, changing the color scheme and removing some of the features included in the default Pier setup (post ticker on every page). My wife spent the bulk of the week playing with Pier – adding content and pictures.
By the end of the week she was very pleased with the potential – she’s been thinking of putting together a website bragging about our current and past Salukis. Pier is pretty easy for her to use and has just about everything she wants in her website and for the missing features and some of the nitty gritty details, she’s got me. I’m pleased because I’m sorta familiar with GLASS and if anything isn’t working right I have a reasonable chance of fixing it – I’d much rather be fixing things in Smalltalk:)
So far I haven’t deviated from the standard Seaside installation, but I know that I will be doing a few Pier-specific things like setting up PRFile to use MAExternalFileModel (scheduled for tonight) and possibly one or two other things which I’ll document as I go along.
On Tuesday, Tudor Girba announced the release of Pier 1.0.17 and the creation of a new Pier website. Today (Thursday), I am pleased to announce that Pier 1.0.17 is available on GLASS. I suggest that you keep an eye on the Pier blog for ongoing developments.
When the final release of GemStone/S 64 version 2.3 is available ([updated 10-06-2008]real soon now) Pier 1.0.17 will be pre-installed. When the appliance based on the final release is made available ([updated 10-21-2008]probably version 1.0 beta 11), it will make a very nice little Pier-in-a-box with built-in persistence and a ready-to-run Pier instance.
When I ported Pier to GLASS I only made one (intentional) change in the feature set (changing PRFile to use MAMemoryFileModel instead of MAExternalFileModel). I didn’t port the package Pier-Squeak-Persistency either for obvious reasons.
By default PRFiles are created using MAExternalFileModel, however, for GLASS, I changed PRFile class>>descriptionFile to use MAMemoryFileModel instead. The rationale is that the GLASS repository is created and initialized on a build machine here at GemStone and any directory structures created during Pier initialization will not be propogated to the final installation. By using MAMemoryFileModel all of the PRFile data is stored in the repository (which happens to be on disk in the final analysis). When you get around to deploying Pier, you will most likely want to use MAExternalFileModel so that you can use Apache or Lighttpd to serve the static files, so you will need to change PRFile class>>descriptionFile to use MAExternalFileModel when you are ready to deploy.
Note – This was my first post using the ‘Blog It!’ feature on Flickr, so some of you may have seen a premature feed in your RSS reader.