a3aan.st

Search

Commands

Navigation

New versions of Seaside packages appear in a rate no vendor will ever be able to keep up with. So what can you do if you want the latest and hottest version with that new feature or fix you are so desperately in need for?

The answer is port it yourself. And the good news is that this has been made a lot easier now.

At the VA Smalltalk Forum last September John O'Keefe of Instantiations announced the availability of a package exporter for Squeak targeted at VA Smalltalk. Recently this package exporter popped up in http://www.squeaksource.com/Seaside. Look for a package named like 'PackageInfo-Exporters-<author>.<version>.mcz'. Load the most recent version into your Squeak image and you're ready to start porting. That's what I did to create the initial port of jQuery.

So how does it work? Load the package exporter into your Squeak image with all of Seaside 2.9 loaded and you can export packages like in this example

VAPackageExporter fileOutPackage: (PackageInfo named: 'JQuery-Core')

This will generate a .st file that can be filed-in to VA Smalltalk/ENVY using

EmFileOutInterface fileInSourceFrom: (CfsReadFileStream open: 'JQuery-Core-<author>.<version>.st')

Prerequisites

Unfortunately, this often won't work right away because of missing prerequisite applications or mismatches in the prerequisite application names between Squeak (Pharo) and VA Smalltalk. These need to be fixed by hand, either in the .st file or directly in the image. This problem has been reduced a bit by learning VAPackageExporter how some common applications (eg. SUnit) are named in VA Smalltalk. Obviously, when you need to import multiple packages that depend on each other, the order of filing-in these packages becomes an issue as well. VAPackageExporter uses the class WAPackage to figure out prerequisites. This means that VAPackageExporter currently doesn't export appropriate prerequisite definitions for non-Seaside packages, but don't let that stop you.

Compilation issues

When the file-in has completed, it's time to check the Transcript for any compilation issues. These need to be solved by hand as well. Then your initial load is ready! Ensuring the tests, if any, are green would be the next thing to call it a port.

Maintaining the port

The above is a workable solution for porting a first version, but what about updating your port? Filing-in a new export will scratch all the sub applications and create new editions for every class and method, no matter how small the change was since porting the initial version. I didn't like that and thought about a solution. ENVY has no reconcile functionality as StORE has that could help here. Fixing it at the source, like exporting changes in ENVY, seemed to make more sense then fixing it in ENVY.
Given that, Lukas Renggli, John O'Keefe and I started working on extending John's initial VAPackageExporter with the possibility to export changes only. You can now export the differences between a package currently loaded in your Squeak image, relative to a version in the Monticello repository, like this

VAPackageExporter
     fileOutPackage: (PackageInfo named: 'JQuery-Core')
     relativeTo: 'JQuery-Core-<author>.<version>'

Filing-in to VA Smalltalk works the same as with the initial version. Now only the changed classes, extensions and applications need to be versioned. This will make keeping your port up-to-date a much smoother operation. With only the real changes in VA Smalltalk it is also easier to keep track of the development history of the ported application.

Posted by Adriaan van Os at 21 December 2008, 6:50 pm with tags VASmalltalk, VAST, Seaside, porting link

What about switching to Squeak ;)

Posted by Squeak at 22 December 2008, 10:23 am link
© 2004-2020 Adriaan van Os  -  [ | ] Powered by Smalltalk (Squeak/Seaside/Magritte/Pier)  -  Served by Apache  -  Hosted on eComStation