Thursday, December 16, 2010

Metacello Pharo

I am loading Seaside into a Pharo Smalltalk (1.2 beta) 'core image' running on top of the latest Cog VM using
Gofer new
   squeaksource: 'MetacelloRepository';
   package: 'ConfigurationOfSeaside';
   load.

(Smalltalk at: #ConfigurationOfSeaside) load
which is going fine except that I occasionally have to look to see what cycles the process is consuming as I get no 'busy'cursor and the 'top' progressbar stays empty - during some downloads the image returns my blank stare.
It is good to see that I do not need 'ConfigurationOfSeaside30' to get 3.0
And only one walkback so far ( a minor deprecated method to correct )
Enhanced by Zemanta
OOPs ... I saw Cfg of Seaside loading Cfg of S 3.0 but here comes a pile of 2.8   oh vey.
How will we escape 'ConfigurationOfSeaside3.1bOsX' etc etc ?

And POOFFF! Magritte compiles by kicking back multiple error streams ... and we are off to try
Gofer new
    squeaksource: 'MetacelloRepository';
    package: 'ConfigurationOfSeaside30';
    load.

(Smalltalk at: #ConfigurationOfSeaside30) load
On my first try I type '3' and not the full '30' and was rejected (not advised, but rejected.)

The issue is that Smalltalk is not yet organic software: it is component software.  But then I see that Pharo offers a configuration ST file.  Now I have to go check to see if this facility remains available in a 'stripped' Pharo image.

This is an old Smalltalk implementation issue often glossed over - but try to explain to some one tasked with Governance, Risk and Compliance (GRC) that your Pharo image starts up by evaluating a raw ST file.  I remember a mission-critical app at a Fortune 100 where one of the ST files being consumed (Why not read and interpret all ST files that you find in the image directory ? ) was quite a shocker (for me, at least.)  But so long as 'stripping' Smalltalk images is more mysterious than establishing a 'base' Smalltalk developer image this concern will remain.

All in all, Metacello configurations are a big improvement.

I think that David Kranz says something about this in his Dr Dobbs interview on the role of the architect.

Meanwhile a class load method just failed on a createClass  message due to a global name collision - and I do not see the equivalent of a tool dating back to Cooper Peters 1990 for resolving this ... so a Seaside 3.0 on Pharo 1.2 alpha on Cog will have to wait for another day ... so back to Pharo 1.1.1 to further explore what Traits can bring to Seaside for multiple markup strategies (read: Curl in addition to HTML + JS)

No comments: