Problems generating images automatically

> I started to do hudson integration. I create a directory skeleton that
> sets environment variables for the instance and has a clean copy of
> extent0.seaside.dbf. But I discover some problems and I'm not sure I do
> the right thing. I'm using GS 2.4.4.1
>
> I assemble scripts (into script.st) to feed into topaz and then I do
> basically
>
> ---
> startstone test$BUILD_NUMBER -z $WORKSPACE/data/system.conf -l
> $WORKSPACE/log.txt
>
> $GEMSTONE/bin/topaz -l -T200000 < $WORKSPACE/script.st
> STATE=$?
> echo "state: $STATE"
>
> stopstone test$BUILD_NUMBER DataCurator swordfish
>
> exit $STATE
> ---
>
> That works for most cases but if I do
>
> 1. loading metacello
> ---
>
> display oops
>
> iferror where
>
> login
>
> run
> ConfigurationOfMetacello project updateProject.
> ConfigurationOfMetacello project latestVersion load.
> %
> commit
>
> exit 0
>
> ---
>
> I get an error in the attachment metacello-load.txt
>
> 2. loading xml-parser together with magritte
>
> ---
>
> display oops
>
> iferror where
>
> login
>
> run
> "XMLSupport"
>
> Gofer new
> squeaksource: 'XMLSupport';
> package: 'ConfigurationOfXMLSupport';
> load.
> ((Smalltalk at: #ConfigurationOfXMLSupport) project version: '1.0.5') load.
> %
> run
>     Gofer new
>        squeaksource: 'MetacelloRepository';
>        package: 'ConfigurationOfMagritte2';
>        load.
>     (Smalltalk at: #ConfigurationOfMagritte2) project latestVersion load.
> %
> commit
>
> exit 0
>
> ---
>
> I get a stack overflow seen in attachment xml-load.txt. It does not happen if I load xml support alone. But together with magritte it loads not only xml-parser but xml-writer as well and those two loop until the stack overflows
>
> 3. loading pier
>
> If I do
> ---
>
> display oops
>
> iferror where
>
> login
>
> run
> Gofer new
>     renggli: 'pier2';
>     package: 'ConfigurationOfPier2';
>     load.
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>     (Smalltalk at: #ConfigurationOfPier2) project latestVersion load ]
>
> %
> run
> Gofer new
>     renggli: 'pier2addons';
>     package: 'ConfigurationOfPierAddOns2';
>     load.
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>     (Smalltalk at: #ConfigurationOfPier2AddOns2) project latestVersion load: 'Pier-Setup' ]
>
> %
> commit
>
> exit 0
>
> ---
>
> I get an error in PRMigration that does an allSubInstances and gemstone
> aborts with the know error that the transaction needs to be fresh at
> that point doing it. But while doing this via metacello there is not
> much chance to interfer and I wonder why this happens to me and not to
> others.
> Stack trace is in attachment pier-load.txt
>
> Hope this is helpful information.
>
> Norbert
>
>

> I started to do hudson integration. I create a directory skeleton that
> sets environment variables for the instance and has a clean copy of
> extent0.seaside.dbf. But I discover some problems and I'm not sure I do
> the right thing. I'm using GS 2.4.4.1
>
> I assemble scripts (into script.st) to feed into topaz and then I do
> basically
>
> ---
> startstone test$BUILD_NUMBER -z $WORKSPACE/data/system.conf -l
> $WORKSPACE/log.txt
>
> $GEMSTONE/bin/topaz -l -T200000 < $WORKSPACE/script.st
> STATE=$?
> echo "state: $STATE"
>
> stopstone test$BUILD_NUMBER DataCurator swordfish
>
> exit $STATE
> ---
>
> That works for most cases but if I do
>
> 1. loading metacello
> ---
>
> display oops
>
> iferror where
>
> login
>
> run
> ConfigurationOfMetacello project updateProject.
> ConfigurationOfMetacello project latestVersion load.
> %
> commit
>
> exit 0
>
> ---
>
> I get an error in the attachment metacello-load.txt
>
> 2. loading xml-parser together with magritte
>
> ---
>
> display oops
>
> iferror where
>
> login
>
> run
> "XMLSupport"
>
> Gofer new
> squeaksource: 'XMLSupport';
> package: 'ConfigurationOfXMLSupport';
> load.
> ((Smalltalk at: #ConfigurationOfXMLSupport) project version: '1.0.5') load.
> %
> run
>     Gofer new
>        squeaksource: 'MetacelloRepository';
>        package: 'ConfigurationOfMagritte2';
>        load.
>     (Smalltalk at: #ConfigurationOfMagritte2) project latestVersion load.
> %
> commit
>
> exit 0
>
> ---
>
> I get a stack overflow seen in attachment xml-load.txt. It does not happen if I load xml support alone. But together with magritte it loads not only xml-parser but xml-writer as well and those two loop until the stack overflows
>
> 3. loading pier
>
> If I do
> ---
>
> display oops
>
> iferror where
>
> login
>
> run
> Gofer new
>     renggli: 'pier2';
>     package: 'ConfigurationOfPier2';
>     load.
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>     (Smalltalk at: #ConfigurationOfPier2) project latestVersion load ]
>
> %
> run
> Gofer new
>     renggli: 'pier2addons';
>     package: 'ConfigurationOfPierAddOns2';
>     load.
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>     (Smalltalk at: #ConfigurationOfPier2AddOns2) project latestVersion load: 'Pier-Setup' ]
>
> %
> commit
>
> exit 0
>
> ---
>
> I get an error in PRMigration that does an allSubInstances and gemstone
> aborts with the know error that the transaction needs to be fresh at
> that point doing it. But while doing this via metacello there is not
> much chance to interfer and I wonder why this happens to me and not to
> others.
> Stack trace is in attachment pier-load.txt
>
> Hope this is helpful information.
>
> Norbert
>
>

> Re: loading metacello:
>
>     Otto reported the same problem (DNU for
>     #'bypassGoferLoadUpdateCategories') and I haven't been able to
>     reproduce the problem. It _is_ a familiar problem to me, but without
>     being able to put my hands on a debugger it will be hard to diagnose
>      ... there are about a half a dozen different possibilities:(
>
> Re: xml-parser with magritte
>
>     That looks like a configuration issue. From the information in log,
>     it looks like the basic problem is that 'Grease Core 1.0-rc' is being
>     loaded for some reason ... if you recall at one point in time you (I
>     think it was you) added Grease as a prerequisite for XML, but in
>     earlier versions of GLASS, XML was inadvertently a prerequisite of
>     Grease ... and that looks like 1.0-rc is the version that will end up
>     requiring Grease ... as I recall there were Metacello bugs involved
>     as well as configuration tweaking. Given the tangle, I would assume
>     that you might have better luck loading Magritte before XML.
>
>     I should be able to reproduce this problem and get a fix out there.
>
> Re: loading pier
>
>     I could swear that I've fixed that bug in the past, by adding a
>     commit right before the allInstances call or perhaps you have exposed
>     another failure mechanism ... If you could supply me with the source
>     code of GRGemStonePlatform>>  magritteAllSubInstancesOf:do: and
>     Class>>  allSubInstancesDo: for this error, I should be able to
>     provide you with a patch...
>
>
> I'll submit a collection of bugs on these and then start grinding away
> on finding fixes ...
>
> Dale
>
> On 02/07/2011 12:06 PM, Norbert Hartl wrote:
>> I started to do hudson integration. I create a directory skeleton that
>> sets environment variables for the instance and has a clean copy of
>> extent0.seaside.dbf. But I discover some problems and I'm not sure I do
>> the right thing. I'm using GS 2.4.4.1
>>
>> I assemble scripts (into script.st) to feed into topaz and then I do
>> basically
>>
>> ---
>> startstone test$BUILD_NUMBER -z $WORKSPACE/data/system.conf -l
>> $WORKSPACE/log.txt
>>
>> $GEMSTONE/bin/topaz -l -T200000<  $WORKSPACE/script.st
>> STATE=$?
>> echo "state: $STATE"
>>
>> stopstone test$BUILD_NUMBER DataCurator swordfish
>>
>> exit $STATE
>> ---
>>
>> That works for most cases but if I do
>>
>> 1. loading metacello
>> ---
>>
>> display oops
>>
>> iferror where
>>
>> login
>>
>> run
>> ConfigurationOfMetacello project updateProject.
>> ConfigurationOfMetacello project latestVersion load.
>> %
>> commit
>>
>> exit 0
>>
>> ---
>>
>> I get an error in the attachment metacello-load.txt
>>
>> 2. loading xml-parser together with magritte
>>
>> ---
>>
>> display oops
>>
>> iferror where
>>
>> login
>>
>> run
>> "XMLSupport"
>>
>> Gofer new
>> squeaksource: 'XMLSupport';
>> package: 'ConfigurationOfXMLSupport';
>> load.
>> ((Smalltalk at: #ConfigurationOfXMLSupport) project version: '1.0.5') load.
>> %
>> run
>>      Gofer new
>>         squeaksource: 'MetacelloRepository';
>>         package: 'ConfigurationOfMagritte2';
>>         load.
>>      (Smalltalk at: #ConfigurationOfMagritte2) project latestVersion load.
>> %
>> commit
>>
>> exit 0
>>
>> ---
>>
>> I get a stack overflow seen in attachment xml-load.txt. It does not happen if I load xml support alone. But together with magritte it loads not only xml-parser but xml-writer as well and those two loop until the stack overflows
>>
>> 3. loading pier
>>
>> If I do
>> ---
>>
>> display oops
>>
>> iferror where
>>
>> login
>>
>> run
>> Gofer new
>>      renggli: 'pier2';
>>      package: 'ConfigurationOfPier2';
>>      load.
>> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>>      (Smalltalk at: #ConfigurationOfPier2) project latestVersion load ]
>>
>> %
>> run
>> Gofer new
>>      renggli: 'pier2addons';
>>      package: 'ConfigurationOfPierAddOns2';
>>      load.
>> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>>      (Smalltalk at: #ConfigurationOfPier2AddOns2) project latestVersion load: 'Pier-Setup' ]
>>
>> %
>> commit
>>
>> exit 0
>>
>> ---
>>
>> I get an error in PRMigration that does an allSubInstances and gemstone
>> aborts with the know error that the transaction needs to be fresh at
>> that point doing it. But while doing this via metacello there is not
>> much chance to interfer and I wonder why this happens to me and not to
>> others.
>> Stack trace is in attachment pier-load.txt
>>
>> Hope this is helpful information.
>>
>> Norbert
>>
>>
>

> Norbert,
>
> I think I've got a handle on your issues:
>
> Re: loading metacello:
>
>  Issue 232:
>
>    MCPlatformSupport class>>autoMigrate: needs to be set to true so
>    that the instance of MetacelloGemStonePlatform gets migrated
>    properly.
>

> Dale
>
> On 02/07/2011 12:29 PM, Dale Henrichs wrote:
>> Re: loading metacello:
>>
>>    Otto reported the same problem (DNU for
>>    #'bypassGoferLoadUpdateCategories') and I haven't been able to
>>    reproduce the problem. It _is_ a familiar problem to me, but without
>>    being able to put my hands on a debugger it will be hard to diagnose
>>     ... there are about a half a dozen different possibilities:(
>>
>> Re: xml-parser with magritte
>>
>>    That looks like a configuration issue. From the information in log,
>>    it looks like the basic problem is that 'Grease Core 1.0-rc' is being
>>    loaded for some reason ... if you recall at one point in time you (I
>>    think it was you) added Grease as a prerequisite for XML, but in
>>    earlier versions of GLASS, XML was inadvertently a prerequisite of
>>    Grease ... and that looks like 1.0-rc is the version that will end up
>>    requiring Grease ... as I recall there were Metacello bugs involved
>>    as well as configuration tweaking. Given the tangle, I would assume
>>    that you might have better luck loading Magritte before XML.
>>
>>    I should be able to reproduce this problem and get a fix out there.
>>
>> Re: loading pier
>>
>>    I could swear that I've fixed that bug in the past, by adding a
>>    commit right before the allInstances call or perhaps you have exposed
>>    another failure mechanism ... If you could supply me with the source
>>    code of GRGemStonePlatform>>  magritteAllSubInstancesOf:do: and
>>    Class>>  allSubInstancesDo: for this error, I should be able to
>>    provide you with a patch...
>>
>>
>> I'll submit a collection of bugs on these and then start grinding away
>> on finding fixes ...
>>
>> Dale
>>
>> On 02/07/2011 12:06 PM, Norbert Hartl wrote:
>>> I started to do hudson integration. I create a directory skeleton that
>>> sets environment variables for the instance and has a clean copy of
>>> extent0.seaside.dbf. But I discover some problems and I'm not sure I do
>>> the right thing. I'm using GS 2.4.4.1
>>>
>>> I assemble scripts (into script.st) to feed into topaz and then I do
>>> basically
>>>
>>> ---
>>> startstone test$BUILD_NUMBER -z $WORKSPACE/data/system.conf -l
>>> $WORKSPACE/log.txt
>>>
>>> $GEMSTONE/bin/topaz -l -T200000<  $WORKSPACE/script.st
>>> STATE=$?
>>> echo "state: $STATE"
>>>
>>> stopstone test$BUILD_NUMBER DataCurator swordfish
>>>
>>> exit $STATE
>>> ---
>>>
>>> That works for most cases but if I do
>>>
>>> 1. loading metacello
>>> ---
>>>
>>> display oops
>>>
>>> iferror where
>>>
>>> login
>>>
>>> run
>>> ConfigurationOfMetacello project updateProject.
>>> ConfigurationOfMetacello project latestVersion load.
>>> %
>>> commit
>>>
>>> exit 0
>>>
>>> ---
>>>
>>> I get an error in the attachment metacello-load.txt
>>>
>>> 2. loading xml-parser together with magritte
>>>
>>> ---
>>>
>>> display oops
>>>
>>> iferror where
>>>
>>> login
>>>
>>> run
>>> "XMLSupport"
>>>
>>> Gofer new
>>> squeaksource: 'XMLSupport';
>>> package: 'ConfigurationOfXMLSupport';
>>> load.
>>> ((Smalltalk at: #ConfigurationOfXMLSupport) project version: '1.0.5') load.
>>> %
>>> run
>>>     Gofer new
>>>        squeaksource: 'MetacelloRepository';
>>>        package: 'ConfigurationOfMagritte2';
>>>        load.
>>>     (Smalltalk at: #ConfigurationOfMagritte2) project latestVersion load.
>>> %
>>> commit
>>>
>>> exit 0
>>>
>>> ---
>>>
>>> I get a stack overflow seen in attachment xml-load.txt. It does not happen if I load xml support alone. But together with magritte it loads not only xml-parser but xml-writer as well and those two loop until the stack overflows
>>>
>>> 3. loading pier
>>>
>>> If I do
>>> ---
>>>
>>> display oops
>>>
>>> iferror where
>>>
>>> login
>>>
>>> run
>>> Gofer new
>>>     renggli: 'pier2';
>>>     package: 'ConfigurationOfPier2';
>>>     load.
>>> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>>>     (Smalltalk at: #ConfigurationOfPier2) project latestVersion load ]
>>>
>>> %
>>> run
>>> Gofer new
>>>     renggli: 'pier2addons';
>>>     package: 'ConfigurationOfPierAddOns2';
>>>     load.
>>> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>>>     (Smalltalk at: #ConfigurationOfPier2AddOns2) project latestVersion load: 'Pier-Setup' ]
>>>
>>> %
>>> commit
>>>
>>> exit 0
>>>
>>> ---
>>>
>>> I get an error in PRMigration that does an allSubInstances and gemstone
>>> aborts with the know error that the transaction needs to be fresh at
>>> that point doing it. But while doing this via metacello there is not
>>> much chance to interfer and I wonder why this happens to me and not to
>>> others.
>>> Stack trace is in attachment pier-load.txt
>>>
>>> Hope this is helpful information.
>>>
>>> Norbert
>>>
>>>
>>
>

> On 07.02.2011, at 23:56, Dale Henrichs wrote:
>> Re: xml-parser with magritte
>>
>> Issue 233:
>>
>> Magritte2 must be loaded before XMLSupport 1.0.5 to avoid running
>> into a stack overflow, use this workaround until I further
>> characterize the problem.
>>
> Yes, the other way round it works.
>
> The 1.0-rc grease was in the ConfigurationOfXMLSupport. But changing
> it to 1.0.2 didn't help. I don't understand when does metacello load
> which version. I specified the version number of XMLSupport to be
> 1.0.5 but metacello loaded the newest stuff as well and this could be
> the cause of the cycle. I hope this grease depency isn't striking
> back very often. I favoured the cross-platformness but maybe I'm the
> only one that cares. Anyway the ConfigurationOfXMLSupport is a mess.
> If you look at it you can see that as usual a method is copied and
> tweaked. But the tweaking is only done for e.g. the pharo platform.
> The gemstone part kept to be the same. The result is that there is a
> gemstone latest version that points to the same package as the 1.0.5
> version. The only thing I would do is to do a blessing: #development
> in the gemstone section from version 1.0.6 on. So that the 1.0.5
> version stays the latest until a port has been done to catch up. What
> is the best solution to deal with this?
>

> On 02/07/2011 03:36 PM, Norbert Hartl wrote:
>> On 07.02.2011, at 23:56, Dale Henrichs wrote:
>>> Re: xml-parser with magritte
>>>
>>> Issue 233:
>>>
>>> Magritte2 must be loaded before XMLSupport 1.0.5 to avoid running
>>> into a stack overflow, use this workaround until I further
>>> characterize the problem.
>>>
>> Yes, the other way round it works.
>>
>> The 1.0-rc grease was in the ConfigurationOfXMLSupport. But changing
>> it to 1.0.2 didn't help. I don't understand when does metacello load
>> which version. I specified the version number of XMLSupport to be
>> 1.0.5 but metacello loaded the newest stuff as well and this could be
>> the cause of the cycle. I hope this grease depency isn't striking
>> back very often. I favoured the cross-platformness but maybe I'm the
>> only one that cares. Anyway the ConfigurationOfXMLSupport is a mess.
>> If you look at it you can see that as usual a method is copied and
>> tweaked. But the tweaking is only done for e.g. the pharo platform.
>> The gemstone part kept to be the same. The result is that there is a
>> gemstone latest version that points to the same package as the 1.0.5
>> version. The only thing I would do is to do a blessing: #development
>> in the gemstone section from version 1.0.6 on. So that the 1.0.5
>> version stays the latest until a port has been done to catch up. What
>> is the best solution to deal with this?
>>
>
> Yes XMLSupport is especially problematic, because it evolved quickly and the GemStone version was not kept in sync ... then with Grease being introduced into the mix the loops were introduced ... a Metacello bug, which was good to find, but ....
>
> With GLASS 1.0-beta.8.5, I moved Grease into GLASS, so moving forward it will always be present along with the latest version of Metacello which should avoid all of the looping issues...
>

>
> On 08.02.2011, at 01:07, Dale Henrichs wrote:
>
>> On 02/07/2011 03:36 PM, Norbert Hartl wrote:
>>> On 07.02.2011, at 23:56, Dale Henrichs wrote:
>>>> Re: xml-parser with magritte
>>>>
>>>> Issue 233:
>>>>
>>>> Magritte2 must be loaded before XMLSupport 1.0.5 to avoid running
>>>> into a stack overflow, use this workaround until I further
>>>> characterize the problem.
>>>>
>>> Yes, the other way round it works.
>>>
>>> The 1.0-rc grease was in the ConfigurationOfXMLSupport. But changing
>>> it to 1.0.2 didn't help. I don't understand when does metacello load
>>> which version. I specified the version number of XMLSupport to be
>>> 1.0.5 but metacello loaded the newest stuff as well and this could be
>>> the cause of the cycle. I hope this grease depency isn't striking
>>> back very often. I favoured the cross-platformness but maybe I'm the
>>> only one that cares. Anyway the ConfigurationOfXMLSupport is a mess.
>>> If you look at it you can see that as usual a method is copied and
>>> tweaked. But the tweaking is only done for e.g. the pharo platform.
>>> The gemstone part kept to be the same. The result is that there is a
>>> gemstone latest version that points to the same package as the 1.0.5
>>> version. The only thing I would do is to do a blessing: #development
>>> in the gemstone section from version 1.0.6 on. So that the 1.0.5
>>> version stays the latest until a port has been done to catch up. What
>>> is the best solution to deal with this?
>>>
>>
>> Yes XMLSupport is especially problematic, because it evolved quickly and the GemStone version was not kept in sync ... then with Grease being introduced into the mix the loops were introduced ... a Metacello bug, which was good to find, but ....
>>
>> With GLASS 1.0-beta.8.5, I moved Grease into GLASS, so moving forward it will always be present along with the latest version of Metacello which should avoid all of the looping issues...
>>
>
>
>> With Metacello 1.0-beta.28, symbolic versions have been introduced, which means that you will no longer use latestVersion, but load the #stable version instead. The #stable version is a specification of which version should be loaded on a platform by platform basis, so configurations that use XML should eventually converted to use #stable version instead ... Symbolic versions don't solve everything, but they do make it easier to manage the fact that different platforms may be lagging behind ...
>>
>> For XMLSupport, I think that if you had upgraded to GLASS 1.0-beta.8.5 first, there would have been no problem, but I haven't convinced myself of that yet...the intent is that configuration load order should not matter, but there have been bugs in Metacello that then complicate things because you need to fix the Metacello bug first...sooner or later when we've fixed every Metacello bug, then we can expect Metacello to work in all cases, like we expect Monticello to load correctly all the time.
>>
> No, that is exactly what I tried in the meantime. I started to build by first updating the 2.4.4.1 virgin extent to 1.0-beta5 and to update metacello to the latest. But it doesn't solves the problem. I just saw that in ConfigurationOfGsMisc there is also the xml parser 1.0.5 loaded. So I don't know where the problem lies. I'll check tomorrow without my own xml config. And I find it really strange that the XML-Writer is pulled in. As far as I can see there is no reference to it.
>

> Dale,
>
> On 07.02.2011, at 23:56, Dale Henrichs wrote:
>
>> Re: loading pier
>>
>> Issue 234:
>>
>> MCPlatformSupport class>>autoMigrate: needs to be set to true so a
>> commit is automatically done before the allInstances call.
>
> I don't get this running. I get either the XML-Writer XML-Parser loop
> or the PRMigrations problem. I'll checked the source and it loads
> Pier-Model-lr.399 and Pier-GemStone-Model-DaleHenrichs.2 (which
> doesn't change anything regarding this problem).
>
> My script to generate is this (the extent I'm running this one is
> latest GLASS, latest metacello, latest seaside/grease, latest
> magritte)
>
> ---
>
> display oops
>
> iferror where
>
> login
>
> run MCPlatformSupport autoMigrate: true. % run Gofer new
> squeaksource: 'MetacelloRepository'; package:
> 'ConfigurationOfPier2'; load. MCPlatformSupport
> commitOnAlmostOutOfMemoryDuring: [ (Smalltalk at:
> #ConfigurationOfPier2) project latestVersion load ]
>
> % run Gofer new renggli: 'MetacelloRepository'; package:
> 'ConfigurationOfPierAddOns2'; load. MCPlatformSupport
> commitOnAlmostOutOfMemoryDuring: [ (Smalltalk at:
> #ConfigurationOfPier2AddOns2) project latestVersion load:
> 'Pier-Setup' ]
>
> % commit
>
> exit 0
>
> ---
>
> The XML-Writer problem I like to fix. Can you tell what is the proper
> way to mark a version to be not available for gemstone? My approach
> doeing a blessing: #development does not work if someone is loading
> the development version. I need something that can state: No, I'm not
> available in this version for this platform. I think the problem lays
> in the fact that every version of XMLSupport is valid for gemstone
> and the baseline of XMLSupport 1.1.7 has dependencies on XML-Writer
> which depends on packages that only work in pharo. In both cases I
> should be able to set a no-gemstone constraint.
>
>
> Norbert
>
>

> Dale,
>
> On 07.02.2011, at 23:56, Dale Henrichs wrote:
>
>> Re: loading pier
>>
>> Issue 234:
>>
>> MCPlatformSupport class>>autoMigrate: needs to be set to true so a
>> commit is automatically done before the allInstances call.
>
> I don't get this running. I get either the XML-Writer XML-Parser loop or
> the PRMigrations problem. I'll checked the source and it loads
> Pier-Model-lr.399
> and Pier-GemStone-Model-DaleHenrichs.2 (which doesn't change anything
> regarding this problem).
>
> My script to generate is this (the extent I'm running this one is latest
> GLASS, latest metacello, latest seaside/grease, latest magritte)
>
> ---
>
> display oops
>
> iferror where
>
> login
>
> run
> MCPlatformSupport autoMigrate: true.
> %
> run
> Gofer new
>     squeaksource: 'MetacelloRepository';
>     package: 'ConfigurationOfPier2';
>     load.
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>     (Smalltalk at: #ConfigurationOfPier2) project latestVersion load ]
>
> %
> run
> Gofer new
>     renggli: 'MetacelloRepository';
>     package: 'ConfigurationOfPierAddOns2';
>     load.
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>     (Smalltalk at: #ConfigurationOfPier2AddOns2) project latestVersion load: 'Pier-Setup' ]
>
> %
> commit
>
> exit 0
>
> ---
>
> The XML-Writer problem I like to fix. Can you tell what is the proper way to mark a version to be not available for gemstone? My approach doeing a blessing: #development does not work if someone is loading the development version. I need something that can state: No, I'm not available in this version for this platform. I think the problem lays in the fact that every version of XMLSupport is valid for gemstone and the baseline of XMLSupport 1.1.7 has dependencies on XML-Writer which depends on packages that only work in pharo. In both cases I should be able to set a no-gemstone constraint.
>
>
> Norbert
>
>

> Norbert,
>
> I had to edit your script in a few places and I added a load of
> Metacello, because I was testing a load into a virgin 2.4.4.1 script
> (GLASS 1.0-beta.8.1) and I was successful in getting the script to
> finish completely:
>
> run
> MCPlatformSupport autoCommit: true. "to avoid PrMigrations issue"
> MCPlatformSupport autoMigrate: true. "to be able to load Metacello"
> %
> run
> "load latest Metacello to avoid XMLWriter bug"
> Gofer new
>      squeaksource: 'MetacelloRepository';
>      package: 'ConfigurationOfMetacello';
>      load.
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>      (Smalltalk at: #ConfigurationOfMetacello) project latestVersion load ]
>
> %
> run
> Gofer new
>      squeaksource: 'MetacelloRepository';
>      package: 'ConfigurationOfPier2';
>      load.
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>      (Smalltalk at: #ConfigurationOfPier2) project latestVersion load ]
>
> %
> run
> Gofer new
>      gemsource: 'MetacelloRepository';
>      package: 'ConfigurationOfPierAddOns2';
>      load.
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>      (Smalltalk at: #ConfigurationOfPierAddOns2) project latestVersion
> load: 'Pier-Setup' ]
>
> %
>
> During the process or working out this script, I did hit the
> allInstances issue and the XMLWriter/looping load problem. You need to
> have autoCommit enabled so that allInstances will work. The
> XMLWriter/stack overflow/looping load problem is due to a Metacello bug
> (and you need autoMigrate enabled to load Metacello)...
>
> Just in case there is some other problem lurking out there, I will do
> this all again including a GLASS, Seaside, and Magritte load before the
> pier load...
>
> I think the lesson here is that if you are loading code using topaz and
> not GemTools that you should preface each load with the following
> sequence, to ensure the best possible outcome:
>
> run
> MCPlatformSupport autoCommit: true.
> MCPlatformSupport autoMigrate: true.
> %
> run
> "load latest Metacello to avoid XMLWriter bug"
> Gofer new
>      squeaksource: 'MetacelloRepository';
>      package: 'ConfigurationOfMetacello';
>      load.
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>      (Smalltalk at: #ConfigurationOfMetacello) project latestVersion load ]
>
> %
>
> I will be including these lessons in GsDeployer, but until GsDeployer is
> generally available we'll have to do these things manually.
>
> Dale
>
> On 02/08/2011 02:35 AM, Norbert Hartl wrote:
>> Dale,
>>
>> On 07.02.2011, at 23:56, Dale Henrichs wrote:
>>
>>> Re: loading pier
>>>
>>> Issue 234:
>>>
>>> MCPlatformSupport class>>autoMigrate: needs to be set to true so a
>>> commit is automatically done before the allInstances call.
>>
>> I don't get this running. I get either the XML-Writer XML-Parser loop or
>> the PRMigrations problem. I'll checked the source and it loads
>> Pier-Model-lr.399
>> and Pier-GemStone-Model-DaleHenrichs.2 (which doesn't change anything
>> regarding this problem).
>>
>> My script to generate is this (the extent I'm running this one is latest
>> GLASS, latest metacello, latest seaside/grease, latest magritte)
>>
>> ---
>>
>> display oops
>>
>> iferror where
>>
>> login
>>
>> run
>> MCPlatformSupport autoMigrate: true.
>> %
>> run
>> Gofer new
>>      squeaksource: 'MetacelloRepository';
>>      package: 'ConfigurationOfPier2';
>>      load.
>> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>>      (Smalltalk at: #ConfigurationOfPier2) project latestVersion load ]
>>
>> %
>> run
>> Gofer new
>>      renggli: 'MetacelloRepository';
>>      package: 'ConfigurationOfPierAddOns2';
>>      load.
>> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>>      (Smalltalk at: #ConfigurationOfPier2AddOns2) project latestVersion load: 'Pier-Setup' ]
>>
>> %
>> commit
>>
>> exit 0
>>
>> ---
>>
>> The XML-Writer problem I like to fix. Can you tell what is the proper way to mark a version to be not available for gemstone? My approach doeing a blessing: #development does not work if someone is loading the development version. I need something that can state: No, I'm not available in this version for this platform. I think the problem lays in the fact that every version of XMLSupport is valid for gemstone and the baseline of XMLSupport 1.1.7 has dependencies on XML-Writer which depends on packages that only work in pharo. In both cases I should be able to set a no-gemstone constraint.
>>
>>
>> Norbert
>>
>>
>

> Norbert,
>
> This load sequence worked for me...getting latest GLASS, Seaside30, Magritte2 and Piers. Loaded into a virgin 1.0-beta.8.1 extent:
>
> run
> MCPlatformSupport autoCommit: true.
> MCPlatformSupport autoMigrate: true.
> %
> run
> Gofer new
>   gemsource: 'MetacelloRepository';
>   package: 'ConfigurationOfMetacello';
>   load.
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>   (Smalltalk at: #ConfigurationOfMetacello) project latestVersion load ]
>
> %
> run
> Gofer new
>   gemsource: 'MetacelloRepository';
>   package: 'ConfigurationOfGLASS';
>   package: 'ConfigurationOfSeaside30';
>   package: 'ConfigurationOfMagritte2';
>   package: 'ConfigurationOfPier2';
>   package: 'ConfigurationOfPierAddOns2';
>   load.
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>   (Smalltalk at: #ConfigurationOfGLASS) project latestVersion load.
>   (Smalltalk at: #ConfigurationOfSeaside30) project latestVersion load.
>   (Smalltalk at: #ConfigurationOfMagritte2) project latestVersion load.
>   (Smalltalk at: #ConfigurationOfPier2) project latestVersion load.
>   (Smalltalk at: #ConfigurationOfPierAddOns2) project latestVersion load: 'Pier-Setup'.
> ]
>
> %
>
> On 02/08/2011 10:38 AM, Dale Henrichs wrote:
>> Norbert,
>>
>> I had to edit your script in a few places and I added a load of
>> Metacello, because I was testing a load into a virgin 2.4.4.1 script
>> (GLASS 1.0-beta.8.1) and I was successful in getting the script to
>> finish completely:
>>
>> run
>> MCPlatformSupport autoCommit: true. "to avoid PrMigrations issue"
>> MCPlatformSupport autoMigrate: true. "to be able to load Metacello"
>> %
>> run
>> "load latest Metacello to avoid XMLWriter bug"
>> Gofer new
>>     squeaksource: 'MetacelloRepository';
>>     package: 'ConfigurationOfMetacello';
>>     load.
>> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>>     (Smalltalk at: #ConfigurationOfMetacello) project latestVersion load ]
>>
>> %
>> run
>> Gofer new
>>     squeaksource: 'MetacelloRepository';
>>     package: 'ConfigurationOfPier2';
>>     load.
>> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>>     (Smalltalk at: #ConfigurationOfPier2) project latestVersion load ]
>>
>> %
>> run
>> Gofer new
>>     gemsource: 'MetacelloRepository';
>>     package: 'ConfigurationOfPierAddOns2';
>>     load.
>> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>>     (Smalltalk at: #ConfigurationOfPierAddOns2) project latestVersion
>> load: 'Pier-Setup' ]
>>
>> %
>>
>> During the process or working out this script, I did hit the
>> allInstances issue and the XMLWriter/looping load problem. You need to
>> have autoCommit enabled so that allInstances will work. The
>> XMLWriter/stack overflow/looping load problem is due to a Metacello bug
>> (and you need autoMigrate enabled to load Metacello)...
>>
>> Just in case there is some other problem lurking out there, I will do
>> this all again including a GLASS, Seaside, and Magritte load before the
>> pier load...
>>
>> I think the lesson here is that if you are loading code using topaz and
>> not GemTools that you should preface each load with the following
>> sequence, to ensure the best possible outcome:
>>
>> run
>> MCPlatformSupport autoCommit: true.
>> MCPlatformSupport autoMigrate: true.
>> %
>> run
>> "load latest Metacello to avoid XMLWriter bug"
>> Gofer new
>>     squeaksource: 'MetacelloRepository';
>>     package: 'ConfigurationOfMetacello';
>>     load.
>> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>>     (Smalltalk at: #ConfigurationOfMetacello) project latestVersion load ]
>>
>> %
>>
>> I will be including these lessons in GsDeployer, but until GsDeployer is
>> generally available we'll have to do these things manually.
>>
>> Dale
>>
>> On 02/08/2011 02:35 AM, Norbert Hartl wrote:
>>> Dale,
>>>
>>> On 07.02.2011, at 23:56, Dale Henrichs wrote:
>>>
>>>> Re: loading pier
>>>>
>>>> Issue 234:
>>>>
>>>> MCPlatformSupport class>>autoMigrate: needs to be set to true so a
>>>> commit is automatically done before the allInstances call.
>>>
>>> I don't get this running. I get either the XML-Writer XML-Parser loop or
>>> the PRMigrations problem. I'll checked the source and it loads
>>> Pier-Model-lr.399
>>> and Pier-GemStone-Model-DaleHenrichs.2 (which doesn't change anything
>>> regarding this problem).
>>>
>>> My script to generate is this (the extent I'm running this one is latest
>>> GLASS, latest metacello, latest seaside/grease, latest magritte)
>>>
>>> ---
>>>
>>> display oops
>>>
>>> iferror where
>>>
>>> login
>>>
>>> run
>>> MCPlatformSupport autoMigrate: true.
>>> %
>>> run
>>> Gofer new
>>>     squeaksource: 'MetacelloRepository';
>>>     package: 'ConfigurationOfPier2';
>>>     load.
>>> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>>>     (Smalltalk at: #ConfigurationOfPier2) project latestVersion load ]
>>>
>>> %
>>> run
>>> Gofer new
>>>     renggli: 'MetacelloRepository';
>>>     package: 'ConfigurationOfPierAddOns2';
>>>     load.
>>> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>>>     (Smalltalk at: #ConfigurationOfPier2AddOns2) project latestVersion load: 'Pier-Setup' ]
>>>
>>> %
>>> commit
>>>
>>> exit 0
>>>
>>> ---
>>>
>>> The XML-Writer problem I like to fix. Can you tell what is the proper way to mark a version to be not available for gemstone? My approach doeing a blessing: #development does not work if someone is loading the development version. I need something that can state: No, I'm not available in this version for this platform. I think the problem lays in the fact that every version of XMLSupport is valid for gemstone and the baseline of XMLSupport 1.1.7 has dependencies on XML-Writer which depends on packages that only work in pharo. In both cases I should be able to set a no-gemstone constraint.
>>>
>>>
>>> Norbert
>>>
>>>
>>
>

> Dale,
>
> thanks very much. I had to add the autoCommit and now I can load
> pier.
>
> The xml parser error is really weird. I load 1.0.5. But the load
> looks for the actual version in the configuration. That pulls in the
> xml writer package that defines the class XMLWriter which was in
> 1.0.5 included in the xml parser package. So it is overridden and my
> code fails. If I would have known this before it would have been less
> work just to port the xml parser. Now I cannot use the metacello
> config of my app. If I learn how to modify the configuration of the
> xml parser in a senseful way I'll do it but I don't understand how it
> should be done.

> On 02/08/2011 02:06 PM, Norbert Hartl wrote:
>> Dale,
>>
>> thanks very much. I had to add the autoCommit and now I can load
>> pier.
>>
>> The xml parser error is really weird. I load 1.0.5. But the load
>> looks for the actual version in the configuration. That pulls in the
>> xml writer package that defines the class XMLWriter which was in
>> 1.0.5 included in the xml parser package. So it is overridden and my
>> code fails. If I would have known this before it would have been less
>> work just to port the xml parser. Now I cannot use the metacello
>> config of my app. If I learn how to modify the configuration of the
>> xml parser in a senseful way I'll do it but I don't understand how it
>> should be done.
>
> Norbert,
>
> I'm not sure what you mean when you say that "the load looks for the actual version in the configuration"?
>
> I think that it may be worth running the following expression against your configuration (you need at least Metacello 1.0-beta.28 for the toolbox to be present):
>
>  (MetacelloToolBox
>    validateProject: ConfigurationOfYourAPP project
>    version: 'problematic version'
>    debug: #()
>    recurse: true) explore
>
>

> Norbert,
>
> I had to edit your script in a few places and I added a load of
> Metacello, because I was testing a load into a virgin 2.4.4.1 script
> (GLASS 1.0-beta.8.1) and I was successful in getting the script to
> finish completely:
>
> run
> MCPlatformSupport autoCommit: true. "to avoid PrMigrations issue"
> MCPlatformSupport autoMigrate: true. "to be able to load Metacello"
> %
> run
> "load latest Metacello to avoid XMLWriter bug"
> Gofer new
>      squeaksource: 'MetacelloRepository';
>      package: 'ConfigurationOfMetacello';
>      load.
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>      (Smalltalk at: #ConfigurationOfMetacello) project latestVersion load ]
>
> %
> run
> Gofer new
>      squeaksource: 'MetacelloRepository';
>      package: 'ConfigurationOfPier2';
>      load.
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>      (Smalltalk at: #ConfigurationOfPier2) project latestVersion load ]
>
> %
> run
> Gofer new
>      gemsource: 'MetacelloRepository';
>      package: 'ConfigurationOfPierAddOns2';
>      load.
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>      (Smalltalk at: #ConfigurationOfPierAddOns2) project latestVersion
> load: 'Pier-Setup' ]
>
> %
>
> During the process or working out this script, I did hit the
> allInstances issue and the XMLWriter/looping load problem. You need to
> have autoCommit enabled so that allInstances will work. The
> XMLWriter/stack overflow/looping load problem is due to a Metacello bug
> (and you need autoMigrate enabled to load Metacello)...
>
> Just in case there is some other problem lurking out there, I will do
> this all again including a GLASS, Seaside, and Magritte load before the
> pier load...
>
> I think the lesson here is that if you are loading code using topaz and
> not GemTools that you should preface each load with the following
> sequence, to ensure the best possible outcome:
>
> run
> MCPlatformSupport autoCommit: true.
> MCPlatformSupport autoMigrate: true.
> %
> run
> "load latest Metacello to avoid XMLWriter bug"
> Gofer new
>      squeaksource: 'MetacelloRepository';
>      package: 'ConfigurationOfMetacello';
>      load.
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>      (Smalltalk at: #ConfigurationOfMetacello) project latestVersion load ]
>
> %
>
> I will be including these lessons in GsDeployer, but until GsDeployer is
> generally available we'll have to do these things manually.
>
> Dale
>
> On 02/08/2011 02:35 AM, Norbert Hartl wrote:
>> Dale,
>>
>> On 07.02.2011, at 23:56, Dale Henrichs wrote:
>>
>>> Re: loading pier
>>>
>>> Issue 234:
>>>
>>> MCPlatformSupport class>>autoMigrate: needs to be set to true so a
>>> commit is automatically done before the allInstances call.
>>
>> I don't get this running. I get either the XML-Writer XML-Parser loop or
>> the PRMigrations problem. I'll checked the source and it loads
>> Pier-Model-lr.399
>> and Pier-GemStone-Model-DaleHenrichs.2 (which doesn't change anything
>> regarding this problem).
>>
>> My script to generate is this (the extent I'm running this one is latest
>> GLASS, latest metacello, latest seaside/grease, latest magritte)
>>
>> ---
>>
>> display oops
>>
>> iferror where
>>
>> login
>>
>> run
>> MCPlatformSupport autoMigrate: true.
>> %
>> run
>> Gofer new
>>      squeaksource: 'MetacelloRepository';
>>      package: 'ConfigurationOfPier2';
>>      load.
>> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>>      (Smalltalk at: #ConfigurationOfPier2) project latestVersion load ]
>>
>> %
>> run
>> Gofer new
>>      renggli: 'MetacelloRepository';
>>      package: 'ConfigurationOfPierAddOns2';
>>      load.
>> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>>      (Smalltalk at: #ConfigurationOfPier2AddOns2) project latestVersion load: 'Pier-Setup' ]
>>
>> %
>> commit
>>
>> exit 0
>>
>> ---
>>
>> The XML-Writer problem I like to fix. Can you tell what is the proper way to mark a version to be not available for gemstone? My approach doeing a blessing: #development does not work if someone is loading the development version. I need something that can state: No, I'm not available in this version for this platform. I think the problem lays in the fact that every version of XMLSupport is valid for gemstone and the baseline of XMLSupport 1.1.7 has dependencies on XML-Writer which depends on packages that only work in pharo. In both cases I should be able to set a no-gemstone constraint.
>>
>>
>> Norbert
>>
>>
>

>
>> This will look for validation issues related to the particular version of your configuration ... it will also validate the version for projects that you reference ...
>>
>> I suspect that for some reason you are asking for the latest version of ConfigurationOfXML instead of version '1.0.5' ... if you have a spelling error or something like that the validator should tell you about it ...
>>
> No, I don't need to do anything at all. If I do
>
> (ConfigurationOfGsMisc project version: '0.237') fetch loadDirective
>
> I get
>
> linear load :
> explicit load : 0.237 [ConfigurationOfGsMisc]
> explicit load : 0.237 [ConfigurationOfGsMisc]
> atomic load : 0.237 [ConfigurationOfGsMisc]
> explicit load : 1.1.7 [ConfigurationOfXMLSupport]
> explicit load : 1.1.7 [ConfigurationOfXMLSupport]
> linear load : 1.1.7 [ConfigurationOfXMLSupport]
> linear load : 1.0.4 [ConfigurationOfXMLWriter]
> load : XML-Writer-JAAyer.5
> explicit load : 1.0.3 [ConfigurationOfGrease]
> explicit load : 1.0.3 [ConfigurationOfGrease]
> explicit load : 1.0.3 [ConfigurationOfGrease]
> explicit load : 1.0.3 [ConfigurationOfGrease]
> linear load : 1.0.3 [ConfigurationOfGrease]
> atomic load : 0.237 [ConfigurationOfGsMisc]
> linear load : 1.1.7 [ConfigurationOfXMLSupport]
> load : SmaCC-dkh.14
>

> On 02/09/2011 03:24 AM, Norbert Hartl wrote:
>>  (MetacelloToolBox
>>    validateProject: ConfigurationOfXMLSupport project
>>    version: '1.0.5'
>>    debug: #()
>>    recurse: true) explore
>>
>> gives me an empty orderedcollection. I updated to latest metacello as well.
>
> That means there are no validation issues, so the configuration is valid.
>
>>
>>> This will look for validation issues related to the particular version of your configuration ... it will also validate the version for projects that you reference ...
>>>
>>> I suspect that for some reason you are asking for the latest version of ConfigurationOfXML instead of version '1.0.5' ... if you have a spelling error or something like that the validator should tell you about it ...
>>>
>> No, I don't need to do anything at all. If I do
>>
>> (ConfigurationOfGsMisc project version: '0.237') fetch loadDirective
>>
>> I get
>>
>> linear load :
>> explicit load : 0.237 [ConfigurationOfGsMisc]
>> explicit load : 0.237 [ConfigurationOfGsMisc]
>> atomic load : 0.237 [ConfigurationOfGsMisc]
>> explicit load : 1.1.7 [ConfigurationOfXMLSupport]
>> explicit load : 1.1.7 [ConfigurationOfXMLSupport]
>> linear load : 1.1.7 [ConfigurationOfXMLSupport]
>> linear load : 1.0.4 [ConfigurationOfXMLWriter]
>> load : XML-Writer-JAAyer.5
>> explicit load : 1.0.3 [ConfigurationOfGrease]
>> explicit load : 1.0.3 [ConfigurationOfGrease]
>> explicit load : 1.0.3 [ConfigurationOfGrease]
>> explicit load : 1.0.3 [ConfigurationOfGrease]
>> linear load : 1.0.3 [ConfigurationOfGrease]
>> atomic load : 0.237 [ConfigurationOfGsMisc]
>> linear load : 1.1.7 [ConfigurationOfXMLSupport]
>> load : SmaCC-dkh.14
>>
>
> Okay, now I can see what the problem is ... Metacello believes that you've got version 1.1.7 of ConfigurationOfXMLSupport already loaded into your image.
>
>  ConfigurationOfXMLSupport project currentVersion
>
> will answer 1.1.7.  Here's the 1.1.7 specification:
>
> spec for: #common do: [
>  spec blessing: #release.
>  spec author: 'JAAyer'.
>  spec timestamp: '1/20/2011 03:31'.
>  spec project: 'XML-Writer' with: '1.0.4'.
>  spec
>   package: 'Collections-OrderPreservingDictionary'
>          with: 'Collections-OrderPreservingDictionary-JAAyer.6';
>   package: 'Collections-BitmapCharacterSet'
>          with: 'Collections-BitmapCharacterSet-JAAyer.1';
>   package: 'XML-Tests-Parser' with: 'XML-Tests-Parser-JAAyer.6';
>   package: 'Opax' with: 'Opax-FabrizioPerin.16'.].
> spec for: #squeakCommon do: [
>  spec
>   package: 'XML-Parser' with: 'XML-Parser-JAAyer.116';
>   package: 'Pastell' with: 'Pastell-Alexandre_Bergel.18'.].
> spec for: #gemstone do: [
>  spec project: 'Grease Core' with: '1.0-rc'.
>  spec
>   package: 'XML-Parser' with: 'XML-Parser.g-DaleHenrichs.93';
>   package: 'SIXX' with: 'SIXX-NorbertHartl.171'.].
>
> You've already got 'XML-Parser.g-DaleHenrichs.93' loaded into your image, so according to the specifications you have version 1.1.7 in you image.
>

> When a configuration is loaded via another configuration, Metacello tries to honor the current version of the project, so:
>
>  (ConfigurationOfGsMisc project version: '0.237') fetch
>
> finds that version 1.1.7 of xml project is currently loaded and proceeds to attempt to load version 1.1.7 of the project, which in turns starts to bring ConfgurationOfXMLWriter and friends ...
>
> Do you recall when a new version of the ConfigurationOfXMLSupport package was pushed out to the MetacelloRepository? All of these issues were hidden from GemStone until those versions were pushed out and now we are seeing problems for the first time ...
>
> I saw that you'd changed the version of Grease in the repository, but I don't think that is the actual issue ... a better solution is to mark all of the versions after 1.0.5, as #broken for #gemstone and things should work correctly now.
>

>
> On 09.02.2011, at 18:49, Dale Henrichs wrote:
>
>> On 02/09/2011 03:24 AM, Norbert Hartl wrote:
>>> (MetacelloToolBox validateProject: ConfigurationOfXMLSupport
>>> project version: '1.0.5' debug: #() recurse: true) explore
>>>
>>> gives me an empty orderedcollection. I updated to latest
>>> metacello as well.
>>
>> That means there are no validation issues, so the configuration is
>> valid.
>>
>>>
>>>> This will look for validation issues related to the particular
>>>> version of your configuration ... it will also validate the
>>>> version for projects that you reference ...
>>>>
>>>> I suspect that for some reason you are asking for the latest
>>>> version of ConfigurationOfXML instead of version '1.0.5' ... if
>>>> you have a spelling error or something like that the validator
>>>> should tell you about it ...
>>>>
>>> No, I don't need to do anything at all. If I do
>>>
>>> (ConfigurationOfGsMisc project version: '0.237') fetch
>>> loadDirective
>>>
>>> I get
>>>
>>> linear load : explicit load : 0.237 [ConfigurationOfGsMisc]
>>> explicit load : 0.237 [ConfigurationOfGsMisc] atomic load : 0.237
>>> [ConfigurationOfGsMisc] explicit load : 1.1.7
>>> [ConfigurationOfXMLSupport] explicit load : 1.1.7
>>> [ConfigurationOfXMLSupport] linear load : 1.1.7
>>> [ConfigurationOfXMLSupport] linear load : 1.0.4
>>> [ConfigurationOfXMLWriter] load : XML-Writer-JAAyer.5 explicit
>>> load : 1.0.3 [ConfigurationOfGrease] explicit load : 1.0.3
>>> [ConfigurationOfGrease] explicit load : 1.0.3
>>> [ConfigurationOfGrease] explicit load : 1.0.3
>>> [ConfigurationOfGrease] linear load : 1.0.3
>>> [ConfigurationOfGrease] atomic load : 0.237
>>> [ConfigurationOfGsMisc] linear load : 1.1.7
>>> [ConfigurationOfXMLSupport] load : SmaCC-dkh.14
>>>
>>
>> Okay, now I can see what the problem is ... Metacello believes that
>> you've got version 1.1.7 of ConfigurationOfXMLSupport already
>> loaded into your image.
>>
>> ConfigurationOfXMLSupport project currentVersion
>>
>> will answer 1.1.7.  Here's the 1.1.7 specification:
>>
>> spec for: #common do: [ spec blessing: #release. spec author:
>> 'JAAyer'. spec timestamp: '1/20/2011 03:31'. spec project:
>> 'XML-Writer' with: '1.0.4'. spec package:
>> 'Collections-OrderPreservingDictionary' with:
>> 'Collections-OrderPreservingDictionary-JAAyer.6'; package:
>> 'Collections-BitmapCharacterSet' with:
>> 'Collections-BitmapCharacterSet-JAAyer.1'; package:
>> 'XML-Tests-Parser' with: 'XML-Tests-Parser-JAAyer.6'; package:
>> 'Opax' with: 'Opax-FabrizioPerin.16'.]. spec for: #squeakCommon do:
>> [ spec package: 'XML-Parser' with: 'XML-Parser-JAAyer.116';
>> package: 'Pastell' with: 'Pastell-Alexandre_Bergel.18'.]. spec for:
>> #gemstone do: [ spec project: 'Grease Core' with: '1.0-rc'. spec
>> package: 'XML-Parser' with: 'XML-Parser.g-DaleHenrichs.93';
>> package: 'SIXX' with: 'SIXX-NorbertHartl.171'.].
>>
>> You've already got 'XML-Parser.g-DaleHenrichs.93' loaded into your
>> image, so according to the specifications you have version 1.1.7 in
>> you image.
>>
> Ok, so it deducts to version number from the package. That means by
> lazily creating new versionxxx methods some advances the version for
> metacello automatically. I think that will cause a lot of trouble in
> the future. It is just too easy to do this. On the other hand we have
> now a use case where everything went wrong. I guess here we shouldn't
> blame metacello. "If someone will build a fool proof system another
> one will breed a better fool"

>
>> When a configuration is loaded via another configuration, Metacello
>> tries to honor the current version of the project, so:
>>
>> (ConfigurationOfGsMisc project version: '0.237') fetch
>>
>> finds that version 1.1.7 of xml project is currently loaded and
>> proceeds to attempt to load version 1.1.7 of the project, which in
>> turns starts to bring ConfgurationOfXMLWriter and friends ...
>>
>> Do you recall when a new version of the ConfigurationOfXMLSupport
>> package was pushed out to the MetacelloRepository? All of these
>> issues were hidden from GemStone until those versions were pushed
>> out and now we are seeing problems for the first time ...
>>
>> I saw that you'd changed the version of Grease in the repository,
>> but I don't think that is the actual issue ... a better solution is
>> to mark all of the versions after 1.0.5, as #broken for #gemstone
>> and things should work correctly now.
>>
> Well, that is what I was trying to ask in the last couple of mails :)

>
>> I have committing that fix so you will want to update to use a
>> newer version of the ConfigurationOfXMLSupport configuration. Now
>> the existing references to version 1.0.5 for GemStone will work.
>>
>> The next step in the evolution of the xml support configuarion is
>> to port all of the packages to GemStone ... I recall that Otto was
>> talking about doing this and pushing out a new version of the
>> configuration ...
>>
> That would be great because there are quite some bugs in the 1.0.5
> version. I just don't find time doing it.

> On 02/09/2011 10:09 AM, Norbert Hartl wrote:
>>
>> On 09.02.2011, at 18:49, Dale Henrichs wrote:
>>
>>> On 02/09/2011 03:24 AM, Norbert Hartl wrote:
>>>> (MetacelloToolBox validateProject: ConfigurationOfXMLSupport
>>>> project version: '1.0.5' debug: #() recurse: true) explore
>>>>
>>>> gives me an empty orderedcollection. I updated to latest
>>>> metacello as well.
>>>
>>> That means there are no validation issues, so the configuration is
>>> valid.
>>>
>>>>
>>>>> This will look for validation issues related to the particular
>>>>> version of your configuration ... it will also validate the
>>>>> version for projects that you reference ...
>>>>>
>>>>> I suspect that for some reason you are asking for the latest
>>>>> version of ConfigurationOfXML instead of version '1.0.5' ... if
>>>>> you have a spelling error or something like that the validator
>>>>> should tell you about it ...
>>>>>
>>>> No, I don't need to do anything at all. If I do
>>>>
>>>> (ConfigurationOfGsMisc project version: '0.237') fetch
>>>> loadDirective
>>>>
>>>> I get
>>>>
>>>> linear load : explicit load : 0.237 [ConfigurationOfGsMisc]
>>>> explicit load : 0.237 [ConfigurationOfGsMisc] atomic load : 0.237
>>>> [ConfigurationOfGsMisc] explicit load : 1.1.7
>>>> [ConfigurationOfXMLSupport] explicit load : 1.1.7
>>>> [ConfigurationOfXMLSupport] linear load : 1.1.7
>>>> [ConfigurationOfXMLSupport] linear load : 1.0.4
>>>> [ConfigurationOfXMLWriter] load : XML-Writer-JAAyer.5 explicit
>>>> load : 1.0.3 [ConfigurationOfGrease] explicit load : 1.0.3
>>>> [ConfigurationOfGrease] explicit load : 1.0.3
>>>> [ConfigurationOfGrease] explicit load : 1.0.3
>>>> [ConfigurationOfGrease] linear load : 1.0.3
>>>> [ConfigurationOfGrease] atomic load : 0.237
>>>> [ConfigurationOfGsMisc] linear load : 1.1.7
>>>> [ConfigurationOfXMLSupport] load : SmaCC-dkh.14
>>>>
>>>
>>> Okay, now I can see what the problem is ... Metacello believes that
>>> you've got version 1.1.7 of ConfigurationOfXMLSupport already
>>> loaded into your image.
>>>
>>> ConfigurationOfXMLSupport project currentVersion
>>>
>>> will answer 1.1.7.  Here's the 1.1.7 specification:
>>>
>>> spec for: #common do: [ spec blessing: #release. spec author:
>>> 'JAAyer'. spec timestamp: '1/20/2011 03:31'. spec project:
>>> 'XML-Writer' with: '1.0.4'. spec package:
>>> 'Collections-OrderPreservingDictionary' with:
>>> 'Collections-OrderPreservingDictionary-JAAyer.6'; package:
>>> 'Collections-BitmapCharacterSet' with:
>>> 'Collections-BitmapCharacterSet-JAAyer.1'; package:
>>> 'XML-Tests-Parser' with: 'XML-Tests-Parser-JAAyer.6'; package:
>>> 'Opax' with: 'Opax-FabrizioPerin.16'.]. spec for: #squeakCommon do:
>>> [ spec package: 'XML-Parser' with: 'XML-Parser-JAAyer.116';
>>> package: 'Pastell' with: 'Pastell-Alexandre_Bergel.18'.]. spec for:
>>> #gemstone do: [ spec project: 'Grease Core' with: '1.0-rc'. spec
>>> package: 'XML-Parser' with: 'XML-Parser.g-DaleHenrichs.93';
>>> package: 'SIXX' with: 'SIXX-NorbertHartl.171'.].
>>>
>>> You've already got 'XML-Parser.g-DaleHenrichs.93' loaded into your
>>> image, so according to the specifications you have version 1.1.7 in
>>> you image.
>>>
>> Ok, so it deducts to version number from the package. That means by
>> lazily creating new versionxxx methods some advances the version for
>> metacello automatically. I think that will cause a lot of trouble in
>> the future. It is just too easy to do this. On the other hand we have
>> now a use case where everything went wrong. I guess here we shouldn't
>> blame metacello. "If someone will build a fool proof system another
>> one will breed a better fool"
>
> The real issue here was that the development of XMLSupport was ongoing and the changes to the configuration weren't visible to GemStone users until it was pushed out into the MetacelloRepository a couple weeks ago and we are just now coming to terms with the new issues ...
>
> If I had caught the problem in 1.0.6 and marked the version #broken for GemStone ... the #broken blessing would have been propogated and we'd only be talking about migrating the fixes ...
>
>>
>>> When a configuration is loaded via another configuration, Metacello
>>> tries to honor the current version of the project, so:
>>>
>>> (ConfigurationOfGsMisc project version: '0.237') fetch
>>>
>>> finds that version 1.1.7 of xml project is currently loaded and
>>> proceeds to attempt to load version 1.1.7 of the project, which in
>>> turns starts to bring ConfgurationOfXMLWriter and friends ...
>>>
>>> Do you recall when a new version of the ConfigurationOfXMLSupport
>>> package was pushed out to the MetacelloRepository? All of these
>>> issues were hidden from GemStone until those versions were pushed
>>> out and now we are seeing problems for the first time ...
>>>
>>> I saw that you'd changed the version of Grease in the repository,
>>> but I don't think that is the actual issue ... a better solution is
>>> to mark all of the versions after 1.0.5, as #broken for #gemstone
>>> and things should work correctly now.
>>>
>> Well, that is what I was trying to ask in the last couple of mails :)
>
> Sorry about that ... I have too many projects in the air and I didn't take the time to try some experiments to see what might be going wrong ... until this morning ...
>
>> How to properly mark the configurations for exclusion by gemstone.
>> Now I see that I can use any symbol in blessing to deactivate it. I
>> would prefer #unconfirmed or #needsToBePorted.
>
> The #broken blessing has an explicit meaning. "any symbol in blessing" will not deactivate a version ... only the #broken symbol deactivates a version...
>
> There are only three blessings with a special meaning in Metacello:
>
>  - #baseline
>  - #development
>  - #broken
>
> all other symbols are treated equally ...
>
>>
>>> I have committing that fix so you will want to update to use a
>>> newer version of the ConfigurationOfXMLSupport configuration. Now
>>> the existing references to version 1.0.5 for GemStone will work.
>>>
>>> The next step in the evolution of the xml support configuarion is
>>> to port all of the packages to GemStone ... I recall that Otto was
>>> talking about doing this and pushing out a new version of the
>>> configuration ...
>>>
>> That would be great because there are quite some bugs in the 1.0.5
>> version. I just don't find time doing it.
>
> You and me both:)
>
> Dale