I get a problem when loading the following the package (this works under 3.3.6):
GsDeployer deploy: [
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Marten, It looks like Sean DeNigris has mirrored the XML project up on github[1], at least I found what appears to be the same problematic test method with the spurious ',' in the literal array[2] ... I mention this because you could fork this repository and make the necessary changes to your version of the repo and then arrange to load it into your image for 3.4 (I can help supply the necessary details if you want to go this route) ... the alternative (submitting a patch to SqueakSource/SmalltalhHub???) is a bit more problematic ... I have been eying the XML project as one of the last few projects
used in GemStone that has not been mirrored to GitHub. I was
hoping that with Pharo7.0 the move would happen in the not too
distant future --- the goal being to eliminate reliance on the
monticello repositories so that GsDevKit builds could be done
without requiring an internet connection (except for the initial
download and periodic, but controlled access to get updates to
projects). I have recently made progress towards this goal working in the
GsDevKit project[3], eliminating the need to download Gofer and
Sport from Monticello repositories -- the last remaing
Monticello-based projects used in GsDevKit/GLASS1. As I mentioned in an earlier email, I will am working on greatly improving the upgrade process for GsDevKit/GLASS for GemStone 3.4.1 ... part of that work will be to switch from using the old Monticello bootstrap process and glassdb/glass[4] to using. To directly loading the BaselineOfGsDevKit[3] into an extent0.dbf repository. I'l also switch to using the official SeasideSt/Grease project[5]. The code "bits" will not change just the project where they are loaded from will change ... I know that a number of you are using XML and if there is a consensus to to go ahead and mirror the XML project in GsDevKit, then I'm willing to do so as part of this upgrade process -- so please send mail if you prefer to do the mirror now rather than wait until the project eventually finds it's way to GitHub ... Dale [1] https://github.com/seandenigris/XML-Parser [3] https://github.com/GsDevKit/GsDevKit/tree/gs_port [4] https://github.com/glassdb/glass [5] https://github.com/SeasideSt/Grease [6] https://github.com/GsDevKit On 11/1/17 10:19 AM, Dale Henrichs
wrote:
Marten, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Hi Marten,
I ran into some XML loading problems a little while ago (~6 months, I think), that are different than yours but you may find. The XML projects as developed and maintained by Monty (e.g. http://smalltalkhub.com/#!/~PharoExtras/XMLWriter http://smalltalkhub.com/#!/~PharoExtras/XMLParser and friends ) cannot be loaded twice into the same stone. Upon initial load some classes are initialized and there are some checks so that they are only initialized once. This creates problems when in a long lived stone when upgrading from one XML version to another. I can't put my hands on the notes I made about what to do when upgrading XML in a stone but will look for them. Monty's explanation at the time to me was: "The configurations load the correct core packages and extension packages in the correct order and run postLoads on GS to force explicit initialization of lazy initialized persisted but immutable class state to prevent write-write conflicts (if the same persisted var is initialized once and never modified, but it's done lazily, you can get write-write conflicts between gems, even if it's initialized the same way in each gem)." Basically you need to reset the initialization checks then load the newer packages. Hope this helps. Paul GLASS mailing list wrote > Marten, > > It looks like Sean DeNigris has mirrored the XML project up on > github[1], at least I found what appears to be the same problematic test > method with the spurious ',' in the literal array[2] ... I mention this > because you could fork this repository and make the necessary changes to > your version of the repo and then arrange to load it into your image for > 3.4 (I can help supply the necessary details if you want to go this > route) ... the alternative (submitting a patch to > SqueakSource/SmalltalhHub???) is a bit more problematic ... > > I have been eying the XML project as one of the last few projects used > in GemStone that has not been mirrored to GitHub. I was hoping that with > Pharo7.0 the move would happen in the not too distant future --- the > goal being to eliminate reliance on the monticello repositories so that > GsDevKit builds could be done without requiring an internet connection > (except for the initial download and periodic, but controlled access to > get updates to projects). > > I have recently made progress towards this goal working in the GsDevKit > project[3], eliminating the need to download Gofer and Sport from > Monticello repositories -- the last remaing Monticello-based projects > used in GsDevKit/GLASS1. > > As I mentioned in an earlier email, I will am working on greatly > improving the upgrade process for GsDevKit/GLASS for GemStone 3.4.1 ... > part of that work will be to switch from using the old Monticello > bootstrap process and glassdb/glass[4] to using. To directly loading the > BaselineOfGsDevKit[3] into an extent0.dbf repository. I'l also switch to > using the official SeasideSt/Grease project[5]. The code "bits" will not > change just the project where they are loaded from will change ... > > I know that a number of you are using XML and if there is a consensus to > to go ahead and mirror the XML project in GsDevKit, then I'm willing to > do so as part of this upgrade process -- so please send mail if you > prefer to do the mirror now rather than wait until the project > eventually finds it's way to GitHub ... > > Dale > > [1] https://github.com/seandenigris/XML-Parser > > [2] > https://github.com/seandenigris/XML-Parser/blob/master/repository/XML-Tests-Parser.package/XMLParserTest.class/instance/testEntityReferenceInternalDeclaration.st > > [3] https://github.com/GsDevKit/GsDevKit/tree/gs_port > > [4] https://github.com/glassdb/glass > > [5] https://github.com/SeasideSt/Grease > > [6] https://github.com/GsDevKit > > > On 11/1/17 10:19 AM, Dale Henrichs wrote: >> Marten, >> >> I’ve lost power at my home (where I am working) so I don’t have >> internet — except via my phone — I also cannot access the VPN >> resources... >> >> Anyway, the error you are getting is due to changes that we made in >> the parsing of literal arrays — I forget the exact details and cannot >> look things up at the moment, but I do have a few local stones on my >> laptop :)— >> >> After an experiment I think that the test code needs to be edited to >> turn the offending ‘,’ into ‘#,’ and then both 3.3 and 3.4 will be happy. >> >> Dale >> >> Sent from my iPhone >> >> On Nov 1, 2017, at 6:08 AM, Marten Feldtmann via Glass >> < > glass@.gemtalksystems > > > <mailto: > glass@.gemtalksystems > >> wrote: >> >>> |I get a problem when loading the following the package (this works >>> under 3.3.6): >>> | >>> | >>> | >>> |GsDeployer deploy: [ >>> Metacello new >>> baseline: 'ZincHTTPComponents'; >>> repository: 'github://GsDevKit/zinc:gs_master/repository'; >>> onLock: [:ex | ex honor ]; >>> load: 'Zinc-SSO-OpenID-Core' ]. >>> | >>> | >>> | >>> >>> | >>> | >>> >>> |Error message: >>> | >>> >>> | >>> | >>> >>> |'| >>> |--transcript--'Loaded -> Collections-BitmapCharacterSet-monty.25 --- >>> http://smalltalkhub.com/mc/PharoExtras/BitmapCharacterSet/main --- >>> cache'| >>> |--transcript--'Loaded -> >>> Collections-OrderPreservingDictionary-monty.33 --- >>> http://smalltalkhub.com/mc/PharoExtras/OrderPreservingDictionary/main >>> --- cache'| >>> |--transcript--'Loaded -> >>> Collections-OrderPreservingDictionary-GemstoneCompatibility-monty.1 >>> --- >>> http://smalltalkhub.com/mc/PharoExtras/OrderPreservingDictionary/main >>> --- cache'| >>> |--transcript--'Loaded -> XML-Parser-monty.421 --- >>> http://www.smalltalkhub.com/mc/PharoExtras/XMLParser/main --- cache'| >>> |--transcript--'Loaded -> XML-Parser-GemstoneCompatibility-monty.25 >>> --- http://www.smalltalkhub.com/mc/PharoExtras/XMLParser/main --- >>> cache'| >>> |--transcript--'Evaluated -> 3.2.7 [ConfigurationOfXMLParser] >> >>> initializeClassesForGSBaseline321'| >>> |--transcript--'Loaded -> XML-Writer-Core-monty.73 --- >>> http://smalltalkhub.com/mc/PharoExtras/XMLWriter/main --- cache'| >>> |--transcript--'Loaded -> XML-Writer-GemstoneCompatibility-monty.7 >>> --- http://smalltalkhub.com/mc/PharoExtras/XMLWriter/main --- cache'| >>> |--transcript--'Loaded -> XML-Writer-Tests-monty.37 --- >>> http://smalltalkhub.com/mc/PharoExtras/XMLWriter/main --- cache'| >>> |--transcript--'Loaded -> >>> Collections-Tests-OrderPreservingDictionary-monty.27 --- >>> http://smalltalkhub.com/mc/PharoExtras/OrderPreservingDictionary/main >>> --- cache'| >>> |--transcript--'Warning: The following definitions had errors while >>> loading. Press Proceed to try to load them again (they may work on a >>> second pass):| >>> |XMLParserTest>>testEntityReferenceInternalDeclaration| >>> |XMLParserTest>>testEntityReferenceUnterminatedInEntityValue| >>> |'| >>> |ERROR 2318 , a UserDefinedError occurred (error 2318), reason:halt, >>> Compile error in Class: #'XMLParserTest' method: >>> testEntityReferenceInternalDeclaration| >>> | #('<!DOCTYPE root [| > >> | <!ENTITY % name "root">| >>> | <!ENTITY % contentModel >>> "EMPTY">| >>> | <!ELEMENT %name; %contentModel;>| >>> | ]> > <root/> > ',| >>> | * ^1 *******| >>> | '<!DOCTYPE root [| > >> | <!ENTITY % name > "value">| >>> | <!ENTITY % name2 "%name;">| >>> | ]> > <root/> > '| >>> | '<!DOCTYPE root [| > >> | <!ENTITY % name > "value">| >>> | <!ENTITY name2 "%name;">| >>> | ]> > <root/> > ')| >>> | do: [:each || >>> | self| >>> | should: [SAXHandler parse: each]| >>> | raise: XMLWellFormednessException].| >>> | self| >>> | (UserDefinedError)| >>> |topaz > exec iferr 1 : where | >>> |==> 1 UserDefinedError (AbstractException) >> _signalWith: @6 line 25| >>> |2 UserDefinedError (AbstractException) >> signal @2 line 47| >>> |3 XMLParserTest class (Object) >> error: @6 line 7| >>> |4 XMLParserTest class (Behavior) >> compileMethod:category: @10 line >>> 16| >>> |5 MCPlatformSupport class >> compile:source:classified:withStamp: @5 >>> line 5| >>> |6 MCMethodDefinition >> load @3 line 3| >>> |7 MCMethodDefinition (MCDefinition) >> loadOver: @2 line 2| >>> |8 [] in MCPackageLoader >> basicLoad @67 line 18| >>> |9 MessageNotUnderstood (AbstractException) >> _executeHandler: @8 >>> line 11| >>> |10 MessageNotUnderstood (AbstractException) >> _signalWith: @1 line 1| >>> |11 MessageNotUnderstood (AbstractException) >> signal @2 line 47| >>> |12 MCMethodDefinition (Object) >> doesNotUnderstand: @10 line 10| >>> |13 MCMethodDefinition (Object) >> >>> _doesNotUnderstand:args:envId:reason: @8 line 13| >>> |14 [] in MCPackageLoader >> basicLoad @62 line 14| >>> |15 ExecBlock0 (ExecBlock) >> on:do: @3 line 44| >>> |16 [] in MCPackageLoader >> basicLoad @57 line 15| >>> >>> _______________________________________________ >>> Glass mailing list >>> > Glass@.gemtalksystems > <mailto: > Glass@.gemtalksystems > > >>> http://lists.gemtalksystems.com/mailman/listinfo/glass > > > _______________________________________________ > Glass mailing list > Glass@.gemtalksystems > http://lists.gemtalksystems.com/mailman/listinfo/glass -- Sent from: http://forum.world.st/GLASS-f1460844.html _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Thu, Nov 2, 2017 at 4:50 PM, Paul DeBruicker via Glass <[hidden email]> wrote: Hi Marten, Seaside suffers the same problem. The workaround we found with Dale was to handle MCPerformPostloadNotification (that's the only important part of below script). This is how I reload Seaside after a stone upgrade: GsDeployer deploy: [ [ [ [ Metacello new ..... "load seaside here as you would do normally" ] on: MCPerformPostloadNotification do: [ :ex | (ex postloadClass name beginsWith: 'WA') ifTrue: [ Transcript show: ' Skipping class side initialization of ' , ex postloadClass name asString. ex resume: false ] ifFalse: [ ex resume: true ] ] ] on: Warning do: [ :ex | Transcript cr; cr; show: '===================================================='; cr; show: ex description; cr; cr; show: '===================================================='; cr. ex resume ] ] ensure: [ System performOnServer: 'rm -rf /tmp/curl*; rm -rf /tmp/github*; rm -rf /tmp/*tmpgithub*; rm -rf /tmp/zip.err' ] ]. System commitTransaction ---- Cheers,
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Should be fixed now. There's a change in how the GS compiler handles literal arrays from 3.3 to 3.4, and I was still on 3.3 and so I didn't see this sooner.
Sent: Wednesday, November 01, 2017 at 8:08 AM
From: "Marten Feldtmann via Glass" <[hidden email]> To: "via Glass" <[hidden email]> Subject: [Glass] Some XML packages not loading under 3.4.0 I get a problem when loading the following the package (this works under 3.3.6): GsDeployer deploy: [
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Mirroring is fine, but staying in sync with upstream is important.
These are the projects:
http://www.smalltalkhub.com/mc/PharoExtras/XMLParser/main
http://www.smalltalkhub.com/mc/PharoExtras/XMLParserHTML/main http://www.smalltalkhub.com/mc/PharoExtras/XMLParserStAX/main http://www.smalltalkhub.com/mc/PharoExtras/XMLWriter/main http://www.smalltalkhub.com/mc/PharoExtras/XPath/main http://www.smalltalkhub.com/mc/PharoExtras/BitmapCharacterSet/main http://www.smalltalkhub.com/mc/PharoExtras/OrderPreservingDictionary/main There are zero other external dependencies, and the #stables should all run on GS 3.4. Most have GS compatibility .mczs, and some have GS-specific Configuration post-load doits.
Sent: Wednesday, November 01, 2017 at 5:31 PM
From: "Dale Henrichs via Glass" <[hidden email]> To: "Marten Feldtmann" <[hidden email]>, "GemStone Seaside beta discussion" <[hidden email]> Subject: Re: [Glass] Some XML packages not loading under 3.4.0 Marten, It looks like Sean DeNigris has mirrored the XML project up on github[1], at least I found what appears to be the same problematic test method with the spurious ',' in the literal array[2] ... I mention this because you could fork this repository and make the necessary changes to your version of the repo and then arrange to load it into your image for 3.4 (I can help supply the necessary details if you want to go this route) ... the alternative (submitting a patch to SqueakSource/SmalltalhHub???) is a bit more problematic ... I have been eying the XML project as one of the last few projects used in GemStone that has not been mirrored to GitHub. I was hoping that with Pharo7.0 the move would happen in the not too distant future --- the goal being to eliminate reliance on the monticello repositories so that GsDevKit builds could be done without requiring an internet connection (except for the initial download and periodic, but controlled access to get updates to projects). I have recently made progress towards this goal working in the GsDevKit project[3], eliminating the need to download Gofer and Sport from Monticello repositories -- the last remaing Monticello-based projects used in GsDevKit/GLASS1. As I mentioned in an earlier email, I will am working on greatly improving the upgrade process for GsDevKit/GLASS for GemStone 3.4.1 ... part of that work will be to switch from using the old Monticello bootstrap process and glassdb/glass[4] to using. To directly loading the BaselineOfGsDevKit[3] into an extent0.dbf repository. I'l also switch to using the official SeasideSt/Grease project[5]. The code "bits" will not change just the project where they are loaded from will change ... I know that a number of you are using XML and if there is a consensus to to go ahead and mirror the XML project in GsDevKit, then I'm willing to do so as part of this upgrade process -- so please send mail if you prefer to do the mirror now rather than wait until the project eventually finds it's way to GitHub ... Dale [1] https://github.com/seandenigris/XML-Parser [3] https://github.com/GsDevKit/GsDevKit/tree/gs_port [4] https://github.com/glassdb/glass [5] https://github.com/SeasideSt/Grease [6] https://github.com/GsDevKit On 11/1/17 10:19 AM, Dale Henrichs wrote:
Marten, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Hi Monty, Thanks a lot for taking care of XML support. You know, one of my worst dependencies in GemStone is XML... why? Because of SIXX (I do need SIXX in GemStone) I need to stick with a VERY OLD xml implementation...and even worst, for Pharo, I must use a new one. So it's a real pain. SIXX can be loaded in GemStone via a Baseline like below and it contains 137 tests. As you seem to be an expert on this topic and you already maintain a lot of related packages, do you think there is a chance you help us update SIXX to use the latest parser and writer? Thanks a lot in advance, On Tue, Nov 7, 2017 at 6:23 AM, monty via Glass <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |