[Glass] SIXX load conflict
Locked
12
12
Re: [Glass] SIXX load conflict
 
|
On 03/06/2015 02:19 AM, Dario Trussardi
via Glass wrote:
Dale, So Dario, I want to START here ... please supply the full load statement that you are using ... you have cut off this expression so I cannot see how you are actually doing the load .... When I asked you to "add" the following: #( 'XMLSupport' '1.2.2' 'http://seaside.gemtalksystems.com/ss/MetacelloRepository') I was referring to your list of load statements above ... I still want to see the full expression, so that I can make sure that you suing `Metacello new` to load things and I'm pretty sure that the `lock` statements should be visible as well, but I want to see what you are actually using ... With regards to getting the latest gsDevKit release ... yes the `git pull` command is the proper thing to do ... .... But I want to emphasize that if you don't `lock` XMLSupport to version 1.2.2, then it is likely that SIXX will fail. I haven't seen this myself, but I have confirmed that recently the XMLSupport configuration was changed to load the very latest XML code and that code may not have been properly ported to GemStone .... Let's get everything working including SIXX based on using a freshly built tODE stone and then go from there... Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] SIXX load conflict
|
|
Dale,
GsDeployer bulkMigrate: [ {#('Seaside3' '3.0.13' 'http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'). #('ZincHTTPComponents' '1.1' 'http://www.squeaksource.com/ZincHTTPComponents'). #('Magritte3' '3.0' 'http://www.squeaksource.com/MetacelloRepository'). #('Magritte3AddOns' '3.0.0' 'http://www.squeaksource.com/MetacelloRepository'). #('Pier3' '3.0.0' 'http://www.squeaksource.com/MetacelloRepository'). #('Pier3AddOns' '3.0.3' 'http://www.squeaksource.com/MetacelloRepository'). #( 'XMLSupport' '1.2.2' 'http://seaside.gemtalksystems.com/ss/MetacelloRepository')} do: [ :ar | | projectName version repository | projectName := ar at: 1. version := ar at: 2. repository := ar at: 3. Metacello new configuration: projectName; repository: repository; get. Metacello new configuration: projectName; version: version; repository: repository; onUpgrade: [ :ex :existing :new | existing locked ifTrue: [ ex disallow ] ifFalse: [ ex allow ] ]; onConflict: [ :ex | ex disallow ]; load. Metacello new configuration: projectName; version: version; repository: repository; lock ] ] It work fine in a new tODE stone ( N.B. i add the #( 'XMLSupport' '1.2.2' 'http://seaside.gemtalksystems.com/ss/MetacelloRepository') ) After i do: GsDeployer bulkMigrate: [ Metacello new baseline: 'SIXX'; repository: '<a href="github://glassdb/SIXX:master/repository'">github://glassdb/SIXX:master/repository'; load ]. SixxExamples example2 also work fine. Thanks. I submit the all same commands into a tODE stone where i found SIXX error. On it when i do: SixxExamples example2 the system go into error : nextWhitespace
| nextChar |
writeBuffer reset.
[(nextChar := self peek) notNil
and: [SeparatorCharacters includes: nextChar]]
whileTrue: [writeBuffer nextPut: self next].
^ writeBuffer stringContents. where SeparatorCharacters is not defined . I can work with new tODE stone if it is complicate solving this. Question : a) for remove a tODE stone is sufficient remove the relative ..... /stones/ xyz directory ? b) for my first deploy environment i refer to the latest gsDevKit release. it's good Ciao, Dario
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] SIXX load conflict
|
|
On 03/06/2015 11:49 AM, Dario Trussardi
via Glass wrote:
Okay ... you probably should load XMLSupport 1.2.2 first, since I think that TopFeeder will bring in the troublesome version of XMLParser ...
If you notice, the last Metacello expression is using the `lock` command ... The `lock` ensures that no matter what version may be specified for a project in a configuration, the `locked` version of the project will always be loaded ... this is very useful when the #stable version of projects is changed out from under you ... I am still suspicious about having XMLSupport loaded last ... I think that you should change your script to load it first, then you'll ensure that a later version isn't loaded ... I don't know for certain, but this problem is probably due to the fact that XMLSupport wasn't loaded earlier in the process ... I think there are some pretty significant changes when XMLParser gets loaded, so I wouldn't trust a stone that was built without first loading and locking XMLSupport 1.2.2 ... That's probably a good idea ... Yes. Make sure that you've shutdown the stone and the netldi and you can simply remove the $GS_HOME/gemstone/stones/<stone-name> directory and all of the stone-related stuff will be removed ...
I don't think that there have been many substantive changes in the gsDevKitHome structure, but it is always good to use a recent version ... Right now I am in the process of preparing a new release of gsDevKitHome and part of the prep has been to tag the "most recent" master as version 0.0.1 (a 0.0.2 is planned) .... then when I do the NEW release it will be version 1.0.0 and will have some significant changes to project structure and the createStone scripts and installTode scripts will work a bit differently with the new version of tODE. To use 1.0.0 will take a small amount amount of conversion work, but nonetheless I will plan on maintaining 0.0.1 for folks who don't want to move to 1.0.0 until they are good and ready .... Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |