[squeak-dev] MonticelloConfiguration and Installer questions

I'm trying to move myself into the 21st century here by using Installer
and MonticelloConfigurations.  Great tools for image building, I think ,
but  I'm having a couple of small problems.

Version info:

Squeak-3.9.1-7075
Insaller-Core-kph.222
Monticello-md.308
MonticelloConfigurations-stephaneducasse.38

1) I'm confused about how MC ".mcm" files are supposed to be published.  
It seems that that configuration browser always asks me for a repo and a
file name.  I've tried using the same name as an existing configuration
(assuming I'd get a new version of that configuration) but, at least in
a HTTP repo, and I just get an error (refuses to overwrite the existing
file...doesn't seem like the correct behavior anyway).  Are
configurations not versioned like other MC entities?  How do people work
with changing configs?

2) Once I have a configuration published in a repo, opening the MC repo
browser and clicking on the configuration file (select the configuration
"package" then click on the .mcm file) gives me a walkback as per the
attached file ClickOnMcmDebug.log.  I've patched it but should I be
working with a newer version of Monticello?  If so, which one (I've
tried a few but they have all caused me one problem or another with
things that are working fine in my existing setup)?

3) Trying to install a configuration using Installer doesn't seem to
work.  The offending code is in Installer>>mcThing which tries to add
the MCConfiguration to the loader thus:

loader addVersion: version.

This eventually results in an error (the configuration is added after
all of its "dependencies").  I've patched Installer but I'm not sure if
this is the right thing to do.  See attached InstallerPatches-cds.3.cs.


David


Error: My subclass should have overridden #loadVersionInfo
16 September 2008 8:30:55 am

VM: unix - a SmalltalkImage
Image: Squeak3.9.1 [latest update: #7075]

SecurityManager state:
Restricted: false
FileAccess: true
SocketAccess: true
Working Dir /home/shaffer/Source/Squeak/ProfitPortal/ImageBuilder
Trusted Dir /home/shaffer/Source/Squeak/ProfitPortal/ImageBuilder/secure
Untrusted Dir /home/shaffer/Source/Squeak/ProfitPortal/ImageBuilder/My Squeak

MCMcmReader(Object)>>error:
        Receiver: a MCMcmReader
        Arguments and temporary variables:
                aString: 'My subclass should have overridden #loadVersionInfo'
        Receiver's instance variables:
                stream: a RWBinaryOrTextStream '(
repository (''http://www.cdshaffer.com/housto...etc...
                package: nil
                info: nil
                definitions: nil
                dependencies: nil
                stepChildren: nil
                fileName: 'HitMysticR4Config7.mcm'

MCMcmReader(Object)>>subclassResponsibility
        Receiver: a MCMcmReader
        Arguments and temporary variables:

        Receiver's instance variables:
                stream: a RWBinaryOrTextStream '(
repository (''http://www.cdshaffer.com/housto...etc...
                package: nil
                info: nil
                definitions: nil
                dependencies: nil
                stepChildren: nil
                fileName: 'HitMysticR4Config7.mcm'

MCMcmReader(MCVersionReader)>>loadVersionInfo
        Receiver: a MCMcmReader
        Arguments and temporary variables:

        Receiver's instance variables:
                stream: a RWBinaryOrTextStream '(
repository (''http://www.cdshaffer.com/housto...etc...
                package: nil
                info: nil
                definitions: nil
                dependencies: nil
                stepChildren: nil
                fileName: 'HitMysticR4Config7.mcm'

MCMcmReader(MCVersionReader)>>info
        Receiver: a MCMcmReader
        Arguments and temporary variables:

        Receiver's instance variables:
                stream: a RWBinaryOrTextStream '(
repository (''http://www.cdshaffer.com/housto...etc...
                package: nil
                info: nil
                definitions: nil
                dependencies: nil
                stepChildren: nil
                fileName: 'HitMysticR4Config7.mcm'


--- The full stack ---
MCMcmReader(Object)>>error:
MCMcmReader(Object)>>subclassResponsibility
MCMcmReader(MCVersionReader)>>loadVersionInfo
MCMcmReader(MCVersionReader)>>info
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[] in MCHttpRepository(MCFileBasedRepository)>>loadVersionInfoFromFileNamed: {[:r | r info]}
MCMcmReader(Object)>>ifNotNilDo:
MCHttpRepository>>versionReaderForFileNamed:do:
MCHttpRepository(MCFileBasedRepository)>>loadVersionInfoFromFileNamed:
MCHttpRepository(MCFileBasedRepository)>>versionInfoFromFileNamed:
MCFileRepositoryInspector>>versionInfo
MCFileRepositoryInspector>>versionSummary
MCFileRepositoryInspector(MCVersionInspector)>>summary
PluggableTextMorphPlus(PluggableTextMorph)>>getText
PluggableTextMorphPlus(PluggableTextMorph)>>update:
PluggableTextMorphPlus>>update:
[] in MCFileRepositoryInspector(Object)>>changed: {[:aDependent | aDependent update: aParameter]}
DependentsArray>>do:
MCFileRepositoryInspector(Object)>>changed:
MCFileRepositoryInspector>>versionSelection:
PluggableListMorphPlus(PluggableListMorph)>>changeModelSelection:
PluggableListMorphPlus(PluggableListMorph)>>mouseUp:
PluggableListMorphPlus(Morph)>>handleMouseUp:
MouseButtonEvent>>sentTo:
PluggableListMorphPlus(Morph)>>handleEvent:
PluggableListMorphPlus(Morph)>>handleFocusEvent:
[] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self.  ActiveEvent := anEvent.  result := focusHolder     han...]}
[] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]}
BlockContext>>on:do:
PasteUpMorph>>becomeActiveDuring:
HandMorph>>sendFocusEvent:to:clear:
HandMorph>>sendEvent:focus:clear:
HandMorph>>sendMouseEvent:
HandMorph>>handleEvent:
HandMorph>>processEvents
[] in WorldState>>doOneCycleNowFor: {[:h |  ActiveHand := h.  h processEvents.  capturingGesture := capturingGest...]}
Array(SequenceableCollection)>>do:
WorldState>>handsDo:
WorldState>>doOneCycleNowFor:
WorldState>>doOneCycleFor:
PasteUpMorph>>doOneCycle
[] in Project class>>spawnNewProcess {[[World doOneCycle.  Processor yield.  false] whileFalse.  nil]}
[] in BlockContext>>newProcess {[self value.  Processor terminateActive]}

'From Squeak3.9.1 of 2 March 2008 [latest update: #7075] on 15 September 2008 at 8:34:32 pm'!

!Installer methodsFor: 'monticello' stamp: 'cds 9/15/2008 20:15'!
mcThing

        | loader files fileToLoad  version  count |

        loader := self classMCVersionLoader new.
       
        1 to: self packages size do: [ :n |

                self logCR: 'finding ', self package asString, '...'.
                "several attempts to read files - repository readableFileNames sometimes fails"
                count := 0. fileToLoad := nil.
       
                [count := count + 1.
                 (fileToLoad = nil) and:[ count < 5 ] ]
                        whileTrue: [
                                                        files := mc readableFileNames asSortedCollection: self mcSortFileBlock.
                                                        fileToLoad := files detect: self mcDetectFileBlock ifNone: [ nil ].
                ].

                version := mc versionFromFileNamed: fileToLoad.
                (version isKindOf: MCConfiguration)
                        ifTrue: [^version]
                        ifFalse:[version workingCopy repositoryGroup addRepository: mc].
                self log: ' found ', version fileName, '...'.

  loader addVersion: version.

                packages removeFirst.
        ].

        ^ loader
! !

Hi David,

do you have anything against using, LevelPlayingField, with MC1.5 ?

see http://installer.pwiki.com/LevelPlayingField

Not that I have any problem with getting earlier versions to work with
Installer, however this is the most supported combination.  I also
notice that MonticelloConfigurations is now up to version 48 in the
http://www.squeaksource.com/mc repository.

best regards

Keith

p.s. You might find Sake/Packages a viable alternative to mcm depending
upon your needs

Keith Hodges wrote:
Thanks for the response.  Re: LPF and MC1.5, never found any motivation
to use either so maybe now's the time?  I installed LPF and MC "48" in
my image and I get the same walkback.  I don't believe that Installer
handles MCM files correctly at all, even under LPF, even with newer
versions of MonticelloConfigurations.  I've attached the walkback.  The
stack should make the problem clear (a MCConfiguration instance is
ending up in the installer's "versions" list and it doesn't respond to
the same protocol as a "version").  My previous e-mail had a patch to
Installer.  I'm using it in my build script now.  Maybe it should be
considered for inclusion although I think that it is sloppy.  I'd prefer
"works" over "elegant" so I'm not ashamed :-)

I peek at Sake now again and, while I'm a long-standing make and ant
user, I don't yet see the need for it in my Smalltalk systems.  Maybe
that day will come.  For now I get all the flexibility I need by
building little "script building" classes that create my deployment
image builder.  I'm cautious that the abstractions provided by the
declarative approach would make this simple process more complicated
(again, in my rather trivial package loading image builder).

Thanks for the tips...

David


MessageNotUnderstood: MCConfiguration>>package
16 September 2008 3:20 pm

VM: unix - a SmalltalkImage
Image: Squeak3.9.1 [latest update: #7075]

SecurityManager state:
Restricted: false
FileAccess: true
SocketAccess: true
Working Dir /home/shaffer/Source/Squeak/ProfitPortal/ImageBuilder
Trusted Dir /home/shaffer/Source/Squeak/ProfitPortal/ImageBuilder/secure
Untrusted Dir /home/shaffer/Source/Squeak/ProfitPortal/ImageBuilder/My Squeak

MCConfiguration(Object)>>doesNotUnderstand: #package
        Receiver: a MCConfiguration
        Arguments and temporary variables:
                aMessage: package
        Receiver's instance variables:
                name: 'HitMysticR4Config7'
                dependencies: an OrderedCollection(a MCVersionDependency a MCVersionDependency ...etc...
                repositories: an OrderedCollection(a MCHttpRepository(http://www.cdshaffer.com/...etc...
                log: nil

[] in MCVersionLoader>>checkForModifications {[:ea | ea package workingCopy modified]}
        Arguments and temporary variables:
                modifications: nil
                ea: a MCConfiguration

OrderedCollection>>select:
        Receiver: an OrderedCollection(a MCVersion(DynamicBindings-gk.1) a MCVersion(KomServices-cds.5) a MC...etc...
        Arguments and temporary variables:
                aBlock: [] in MCVersionLoader>>checkForModifications {[:ea | ea package working...etc...
                newCollection: an OrderedCollection()
                element: a MCConfiguration
                index: 65
        Receiver's instance variables:
                array: an Array(a MCVersion(DynamicBindings-gk.1) a MCVersion(KomServices-cds.5...etc...
                firstIndex: 1
                lastIndex: 65

MCVersionLoader>>checkForModifications
        Receiver: a MCVersionLoader
        Arguments and temporary variables:
                modifications: nil
                ea: a MCConfiguration
        Receiver's instance variables:
                versions: an OrderedCollection(a MCVersion(DynamicBindings-gk.1) a MCVersion(Ko...etc...


--- The full stack ---
MCConfiguration(Object)>>doesNotUnderstand: #package
[] in MCVersionLoader>>checkForModifications {[:ea | ea package workingCopy modified]}
OrderedCollection>>select:
MCVersionLoader>>checkForModifications
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
MCVersionLoader>>loadWithNameLike:
MCVersionLoader>>load
[] in Installer>>mcInstall {[self mcThing load]}
[] in BlockContext>>valueSupplyingAnswers: {[self value]}
BlockContext>>on:do:
BlockContext>>valueSupplyingAnswers:
BlockContext>>valueSuppressingMessages:supplyingAnswers:
Installer>>withAnswersDo:
Installer>>mcInstall
[] in Installer>>install {[self sake   ifNotNil: [^ self sakeInstall].  self universe   ifNotNil: [^ s...]}
Installer>>logErrorDuring:
Installer>>install
UndefinedObject>>DoIt
Compiler>>evaluate:in:to:notifying:ifFail:logged:
Compiler class>>evaluate:for:notifying:logged:
Compiler class>>evaluate:for:logged:
Compiler class>>evaluate:logged:
[] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: {[val := (self peekFor: $!)     ifTrue: [(Compiler evaluate: self nextChunk l...]}
BlockContext>>on:do:
[] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: {[:bar |  [self atEnd]   whileFalse: [bar value: self position.    self skipS...]}
[] in ProgressInitiationException>>defaultMorphicAction {[result := workBlock value: progress]}
BlockContext>>ensure:
ProgressInitiationException>>defaultMorphicAction
ProgressInitiationException>>defaultAction
UndefinedObject>>handleSignal:
ProgressInitiationException(Exception)>>signal
ProgressInitiationException>>display:at:from:to:during:
ProgressInitiationException class>>display:at:from:to:during:
ByteString(String)>>displayProgressAt:from:to:during:
RWBinaryOrTextStream(PositionableStream)>>fileInAnnouncing:
RWBinaryOrTextStream(PositionableStream)>>fileIn
CodeLoader>>installSourceFile:
[] in CodeLoader>>installSourceFiles {[:req | self installSourceFile: req contentStream]}
Array(SequenceableCollection)>>do:
CodeLoader>>installSourceFiles
ProjectLauncher>>startUpAfterLogin
ProjectLauncher>>startUp
[] in AutoStart class>>startUp: {[launcher startUp]}
WorldState>>runStepMethodsIn:
PasteUpMorph>>runStepMethods
WorldState>>doOneCycleNowFor:
WorldState>>doOneCycleFor:
PasteUpMorph>>doOneCycle
[] in Project class>>spawnNewProcess {[[World doOneCycle.  Processor yield.  false] whileFalse.  nil]}
[] in BlockContext>>newProcess {[self value.  Processor terminateActive]}

Am 16.09.2008 um 21:29 schrieb C. David Shaffer:

>  I'd prefer "works" over "elegant" so I'm not ashamed :-)


Hehe, that attitude pretty much drove MCConfiguration development :)  
It's TSTTCPW and just gets the job done it was needed for, but as you  
noticed it isn't well-integrated, it does not do autmatic versioning.  
But I like its simplicity - it really is nothing more than a list of  
package versions and repositories.

- Bert -

>   I'm cautious that the abstractions provided by the declarative
> approach would make this simple process more complicated (again, in my
> rather trivial package loading image builder).
>
> Thanks for the tips...
>
> David
I love it, my critics say its not declarative enough!

Keith

 
>  in my image and I get the same walkback.  I don't believe that
> Installer handles MCM files correctly at all
I do, since I load Magma using an mcm, and have done for months. However
I realise that I used this method:

Installer installUrl:
'http://www.squeaksource.com/Magma/Magma%201.0r40%20server%20configuration.mcm'.

not this method:

Installer squeaksource project: 'MagmaTester' ; install: 'Magma 1.0r40
server configuration.mcm'.

I have included your latest patch in latest. If this works it will use
the multiple package loader, and with atomic loading enabled it should
load the whole caboodle atomically.
> , even under LPF, even with newer versions of
> MonticelloConfigurations.  I've attached the walkback.  
thanks awfully!

Keith

Keith Hodges wrote: Hi David,

I just went back to your original simple fix to Installer, but changed
MCConfiguration-#load to use MCVersionLoader. This will enable all users
of mcm's to take advantage of atomic loading (not just Installer). I
would be grateful if you could check if it works with your packages,
just in case I did something stupid.

regards

Keith

Keith Hodges wrote: Keith,

I patched your MCConfiguration patch (published to ss) and now the
configuration loads on the simple test cases I was using before.  Now
I'm having a new problem, the class initialization order is somehow
messed-up.  My code doesn't assume anything about the order of sending
initialize to classes in an individual package but my system (actually a
package that my system uses) assumes that packages loaded before it have
been initialized.  I think that's a reasonable expectation.  Using the
older MCConfiguration>>#load (djr.48), I get the correct initialization
behavior.  By the way, my second patch produced the same errant behavior
(didn't notice it until testing my more complex configuration).

So, the original patch + the older MCConfiguration>>#load is good enough
for me for now.  The patched Installer>>mcThing doesn't work correctly
if multiple packages, one of which is an MCM, are being loaded but I
think it will take a bit more design thinking to get that case right.  
You could either:

1) Make MCConfiguration behave more like a version so it can be added to
the load
2) Make the loader understand the difference between a version and a
configuration
3) other possibilities?

David

 
>>  
> Keith,
>
> I patched your MCConfiguration patch (published to ss) and now the
> configuration loads on the simple test cases I was using before.  Now
> I'm having a new problem, the class initialization order is somehow
> messed-up.  
I hear echoes of "I told you so" coming from Matthew!
> My code doesn't assume anything about the order of sending initialize
> to classes in an individual package but my system (actually a package
> that my system uses) assumes that packages loaded before it have been
> initialized.  I think that's a reasonable expectation.  Using the
> older MCConfiguration>>#load (djr.48), I get the correct
> initialization behavior.
....
> So, the original patch + the older MCConfiguration>>#load is good
> enough for me for now.  The patched Installer>>mcThing doesn't work
> correctly if multiple packages, one of which is an MCM, are being
> loaded but I think it will take a bit more design thinking to get that
> case right.
Fair enough

Keith

Bert Freudenberg wrote: :-) MCConfiguration is working /very/ well for me.  It is a nice
incremental improvement over my manual process.  I'm not using the
"Store" capability in the configuration browser, though, because it will
quickly make a mess of my MC repository browser (I've already got too
many packages to scroll through there).  It seems more sensible to write
my configs to disk during deployment so I can "version" them by release
number.  I assume that's what most people are doing?  ...or is there a
sensible way to use them in a MCBrowser that I've just missed?  Maybe a
naming convention that makes the MC browser show only one package entry
per config (as opposed to per /instance/ of a config).

David

Am 18.09.2008 um 14:28 schrieb C. David Shaffer:


I just overwrite a single config in the repo every time I make a new  
release. So this config is the "head" of the development tree.

- Bert -

Bert Freudenberg wrote:
>
>
> I just overwrite a single config in the repo every time I make a new
> release. So this config is the "head" of the development tree.
>
> - Bert -
>
I see...so you can't reconstruct an old release?  Also, it doesn't seem
that MC will allow you to overwrite an MCM stored in an HTTP repo so
this only works for file-based repos?  (Still just verifying that I'm
not doing something stupid with the tools.)

David

Am 18.09.2008 um 15:23 schrieb C. David Shaffer:


Works fine with an http squeaksource server for me.

- Bert -

Bert Freudenberg wrote:
>
>
> Works fine with an http squeaksource server for me.
>
Ah, that's it.  Apache/WebDAV servers produce:

HTTP/1.1 204 No Content

when a PUT is issued on top of an existing file.  This appears to be OK,
as far as the specification doesn't really indicate what successful
status code should be used.  Anyway, this causes MC to produce a
walkback even though the PUT was successful.  I suggest (only last two
lines changed):

MCHttpRepository>>writeStreamForFileNamed: aString replace:
ignoreBoolean do: aBlock
    | stream response statusLine code |
    stream := RWBinaryOrTextStream on: String new.
    aBlock value: stream.
    response := HTTPSocket
                    httpPut: stream contents
                    to: (self urlForFileNamed: aString)
                    user: self user
                    passwd: self password.

    statusLine := response copyUpTo: Character cr.
    code := (statusLine findTokens: ' ') second asInteger.
    (#(200 201 204) includes: code)
            ifFalse: [self error: response].


but I'm not enough of an MC guru to know if this is a bad idea or not.  
If I don't hear any objections I'll post the patch.

David

Am 18.09.2008 um 20:14 schrieb C. David Shaffer:


Actually, all 2xx codes mean okay:

http://www.w3.org/Protocols/HTTP/HTRESP.html

- Bert -