Bootstrapping GLASS into extent converted from GS32 bit 6.5.7.5 to GS64 2.4.4.4
Locked
Bootstrapping GLASS into extent converted from GS32 bit 6.5.7.5 to GS64 2.4.4.4
 
|
We are trying to bootstrap GLASS into a production database that has been converted from 32bit to 64 bit. At least, not GLASS itself, but just as much of it as is present in extent0.seaside.dbf so that we can use GemTools/pharo to log into the database and edit code.
We are using installMaster24.topaz as shipped with 2.4.4.4 to do the job. The process works for us with a development database that starts off with an extent0.dbf as shipped in 2.4.4.4, but it does not work if we do it to a database that has been converted from 32bit to 64bit. It fails inside BootstrapDriver>>installConfiguration because nil does not understand repositoryOverrides:. That happens because no pragmas on any methods at all are stored, so Metacello sees no version numbers inside ConfigurationOfGLASS and can't create the latest version. The pragmas are not stored, because Behavior>>createPragmaFrom:for: is never changed away from its stub implementation that does nothing but return nil. Bootstrap-DaleHenrichs.179.mcz was supposed to load a new implementation of Behavior>>createPragmaFrom:for: . In the development extent0 database, Bootstrap-DaleHenrichs.179.mcz does so. In the converted database, it seems to have no effect on Behavior>>createPragmaFrom:for:. In order to debug, we edited installMaster24.topaz to do the following before "BootstrapDriver installMcz.": ----- | result | result := Behavior compileMethod: 'createPragmaFrom: aPragmaArray for: aGsMethod | pragma args pragmas keyword | aPragmaArray isEmpty ifTrue: [ ^nil ]. pragmas := Array new. 1 to: aPragmaArray size by: 2 do: [:i | keyword := aPragmaArray at: i. args := aPragmaArray at: i + 1. args == nil ifTrue: [ args := #() ]. pragma := Pragma keyword: keyword arguments: args. pragma setMethod: aGsMethod. pragmas add: pragma]. ^pragmas' category: '*bootstrap' using: GsSession currentSession symbolList. GsFile stdout nextPutAll: 'RESULT '; nextPutAll: result printString; cr; nextPutAll: (Behavior compiledMethodAt: #createPragmaFrom:for:) sourceString; cr ------ In the development database, the above code has the expected effect of modifying the Behavior>>createPragmaFrom:for:. However, in the converted database, the above "succeeds" without modifying the method at all, the method still remains "stuck" at its ^nil implementation. The return value from compileMethod:category:using: is nil though, so there were no compiler errors. We're a bit stumped by this mystery.
|
Re: Bootstrapping GLASS into extent converted from GS32 bit 6.5.7.5 to GS64 2.4.4.4
|
|
Peter,
I suppose you might have an opportunity to learn more about session methods than you'd like ... I've never tried to add GLASS to an upgraded database or on top of an existing install of user application code, so I'm not sure if the problem is the 32bit upgrade or not ... It _is_ puzzling that you are not getting errors when you try to install Behavior>>createPragmaFrom:for: ... or any other override methods for that matter .. presumably there are a lot of extension methods that aren't being installed correctly ... First off, are you doing everything as DataCurator or are you using a different user for the converted db? Secondly, something else must be going wrong (also?) during the earlier phases of the installMaster24.topaz script so things have gone haywire before your attempt to patch ... we need to verify that things are working correctly from the very beginning of the script... Let's look at the state of your freshly converted db. Be aware that the following steps will modify your persistent state (if you commit) so do these things on a copy of the freshly converted db. Login as DataCurator and run through the following steps. GsCurrentSession>>initialize should execute the following: GsPackagePolicy loadSessionMethodDictionary Then the following: (GsSession currentSession objectNamed: #UserGlobals) at:#GsPackagePolicy_Current should return an instance of GsPackagePolicy and the #enabled instance variable should be false. Behavior compiledMethodAt: #createPragmaFrom:for: should throw a key not found error. The following: GSPackagePolicy current enable. Behavior compiledMethodAt: #createPragmaFrom:for: enables session methods, so that the #createPragmaFrom:for: method should now be visible and the owner of the method (Behavior compiledMethodAt: #createPragmaFrom:for:) segment owner userId should be 'DataCurator'. At this point in time, you should be able to redefine the #createPraga:... method as follows: category: 'xxx' method: Behavior createPragmaFrom: aPragmaArray for: aGsMethod | pragma args pragmas keyword | aPragmaArray isEmpty ifTrue: [ ^nil ]. pragmas := Array new. 1 to: aPragmaArray size by: 2 do: [:i | keyword := aPragmaArray at: i. args := aPragmaArray at: i + 1. args == nil ifTrue: [ args := #() ]. pragma := Pragma keyword: keyword arguments: args. pragma setMethod: aGsMethod. pragmas add: pragma]. ^pragmas % and the following should return the above as the method source: Behavior sourceCodeAt: #createPragmaFrom:for: If all of these things work to this point, then I'll have to think a bit and dig a bit deeper into the problem... Dale On 02/22/2011 04:47 AM, Pieter Nagel wrote: > We are trying to bootstrap GLASS into a production database that has > been converted from 32bit to 64 bit. At least, not GLASS itself, but > just as much of it as is present in extent0.seaside.dbf so that we can > use GemTools/pharo to log into the database and edit code. > > We are using installMaster24.topaz as shipped with 2.4.4.4 to do the > job. The process works for us with a development database that starts > off with an extent0.dbf as shipped in 2.4.4.4, but it does not work if > we do it to a database that has been converted from 32bit to 64bit. > > It fails inside BootstrapDriver>>installConfiguration because nil does > not understand repositoryOverrides:. That happens because no pragmas on > any methods at all are stored, so Metacello sees no version numbers > inside ConfigurationOfGLASS and can't create the latest version. > > The pragmas are not stored, because Behavior>>createPragmaFrom:for: is > never changed away from its stub implementation that does nothing but > return nil. > > Bootstrap-DaleHenrichs.179.mcz was supposed to load a new implementation > of Behavior>>createPragmaFrom:for: . In the development extent0 > database, Bootstrap-DaleHenrichs.179.mcz does so. In the converted > database, it seems to have no effect on Behavior>>createPragmaFrom:for:. > > In order to debug, we edited installMaster24.topaz to do the following > before "BootstrapDriver installMcz.": > > ----- > | result | > result := Behavior > compileMethod: 'createPragmaFrom: aPragmaArray for: aGsMethod > > | pragma args pragmas keyword | > aPragmaArray isEmpty ifTrue: [ ^nil ]. > pragmas := Array new. > 1 to: aPragmaArray size by: 2 do: [:i | > keyword := aPragmaArray at: i. > args := aPragmaArray at: i + 1. > args == nil ifTrue: [ args := #() ]. > pragma := Pragma keyword: keyword arguments: args. > pragma setMethod: aGsMethod. > pragmas add: pragma]. > ^pragmas' > category: '*bootstrap' > using: GsSession currentSession symbolList. > GsFile stdout > nextPutAll: 'RESULT '; > nextPutAll: result printString; > cr; > nextPutAll: (Behavior compiledMethodAt: #createPragmaFrom:for:) > sourceString; > cr > ------ > > In the development database, the above code has the expected effect of > modifying the Behavior>>createPragmaFrom:for:. However, in the converted > database, the above "succeeds" without modifying the method at all, the > method still remains "stuck" at its ^nil implementation. The return > value from compileMethod:category:using: is nil though, so there were no > compiler errors. > > We're a bit stumped by this mystery. > > > > ___________________________ > > *Pieter Nagel* > Methodology Coach > *EFS Investment Solutions* > *Equinox*, Block A, Crystal Park One > 249 Basden Ave, Lyttelton, Centurion, 0157 > South Africa > > > Tel: 0860 378 466 (sharecall) > +27 (0)12 644 0518 (for overseas clients) > Fax: +27 (0)11 388 3223 > www.equinox.co.za <http://www.equinox.co.za> > [hidden email] <mailto:[hidden email]> > /___________________________/ > > |
Re: Bootstrapping GLASS into extent converted from GS32 bit 6.5.7.5 to GS64 2.4.4.4
|
|
We found the problem.
It seems that ordering of packages in the users' symbollist is important, because compiledMethodAt: looks in each package in order and answers the first session override it finds. Normally, extent0.dbf, before bootstrapping GLASS using installMaster24.topaz, the ordering of symbol dicts is: UserGlobals, Globals, Published. The bootstrap process seems to be hard-wired to create SessionMethods before Globals, so one ends up with UserGlobals, SessionMethods, Globals, Published. Through a mechanism which I as yet don't understand, the package inside UserGlobals is made the bearer of the methodDict where Behavior session methods overrides are added to when compiled. But since UserGlobals contains the first package, it is also where these methods are looked up again, so it all works. However, in our production database, the ordering of symbol dicts was <lots of our dictionaries>, then Globals, Published, UserGlobals. installMaster24.topaz once again created SessionMethods directly before Globals, which means that session method overrides were now first searched for in the package inside SessioMethods before UserGlobals. However, compiled session methods still went to the methodDict inside the package in UserGlobals. This caused our observed behavior of methods seeming to not chang after being filed in. When we fixed the ordering of our symbol dicts to be <lots of our dictionaries>, UserGlobals, Globals, Published, we were able to sucessfully run through installMaster24.topaz to the end. It seems that the way in which the position to create SessionMethods is chosen when it is absent is a bit brittle, since it makes too many prior assumptions about the relative ordering of Globals and UserGlobals. On Tue, 2011-02-22 at 13:50 -0800, Dale Henrichs wrote:
|
Re: Bootstrapping GLASS into extent converted from GS32 bit 6.5.7.5 to GS64 2.4.4.4
|
|
Pieter,
Good detective work ... I've submitted an internal GemStone bug (Bug 41336) to address the default positioning of the symbol dictionaries involved in session methods. In the case where you don't want to move the UserGlobals around in the SymbolList, you could create a SymbolDictionary for GLASS and position it in the "correct" spot, leaving UserGlobals where it is. Thanks, Dale On 02/23/2011 05:09 AM, Pieter Nagel wrote: > We found the problem. > > It seems that ordering of packages in the users' symbollist is > important, because compiledMethodAt: looks in each package in order and > answers the first session override it finds. > > Normally, extent0.dbf, before bootstrapping GLASS using > installMaster24.topaz, the ordering of symbol dicts is: UserGlobals, > Globals, Published. The bootstrap process seems to be hard-wired to > create SessionMethods before Globals, so one ends up with UserGlobals, > SessionMethods, Globals, Published. > > Through a mechanism which I as yet don't understand, the package inside > UserGlobals is made the bearer of the methodDict where Behavior session > methods overrides are added to when compiled. But since UserGlobals > contains the first package, it is also where these methods are looked up > again, so it all works. > > However, in our production database, the ordering of symbol dicts was > <lots of our dictionaries>, then Globals, Published, UserGlobals. > installMaster24.topaz once again created SessionMethods directly before > Globals, which means that session method overrides were now first > searched for in the package inside SessioMethods before UserGlobals. > However, compiled session methods still went to the methodDict inside > the package in UserGlobals. This caused our observed behavior of methods > seeming to not chang after being filed in. > > When we fixed the ordering of our symbol dicts to be <lots of our > dictionaries>, UserGlobals, Globals, Published, we were able to > sucessfully run through installMaster24.topaz to the end. > > It seems that the way in which the position to create SessionMethods is > chosen when it is absent is a bit brittle, since it makes too many prior > assumptions about the relative ordering of Globals and UserGlobals. > > On Tue, 2011-02-22 at 13:50 -0800, Dale Henrichs wrote: >> Peter, >> >> I suppose you might have an opportunity to learn more about session >> methods than you'd like ... >> >> I've never tried to add GLASS to an upgraded database or on top of an >> existing install of user application code, so I'm not sure if the >> problem is the 32bit upgrade or not ... >> >> It _is_ puzzling that you are not getting errors when you try to install >> Behavior>>createPragmaFrom:for: ... or any other override methods for >> that matter .. presumably there are a lot of extension methods that >> aren't being installed correctly ... >> >> First off, are you doing everything as DataCurator or are you using a >> different user for the converted db? >> >> Secondly, something else must be going wrong (also?) during the earlier >> phases of the installMaster24.topaz script so things have gone haywire >> before your attempt to patch ... we need to verify that things are >> working correctly from the very beginning of the script... >> >> Let's look at the state of your freshly converted db. Be aware that the >> following steps will modify your persistent state (if you commit) so do >> these things on a copy of the freshly converted db. >> >> Login as DataCurator and run through the following steps. >> >> GsCurrentSession>>initialize should execute the following: >> >> GsPackagePolicy loadSessionMethodDictionary >> >> Then the following: >> >> (GsSession currentSession objectNamed: #UserGlobals) >> at:#GsPackagePolicy_Current >> >> should return an instance of GsPackagePolicy and the #enabled instance >> variable should be false. >> >> Behavior compiledMethodAt: #createPragmaFrom:for: >> >> should throw a key not found error. The following: >> >> GSPackagePolicy current enable. >> Behavior compiledMethodAt: #createPragmaFrom:for: >> >> enables session methods, so that the #createPragmaFrom:for: method >> should now be visible and the owner of the method >> >> (Behavior compiledMethodAt: #createPragmaFrom:for:) >> segment owner userId >> >> should be 'DataCurator'. At this point in time, you should be able to >> redefine the #createPraga:... method as follows: >> >> category: 'xxx' >> method: Behavior >> createPragmaFrom: aPragmaArray for: aGsMethod >> >> | pragma args pragmas keyword | >> aPragmaArray isEmpty ifTrue: [ ^nil ]. >> pragmas := Array new. >> 1 to: aPragmaArray size by: 2 do: [:i | >> keyword := aPragmaArray at: i. >> args := aPragmaArray at: i + 1. >> args == nil ifTrue: [ args := #() ]. >> pragma := Pragma keyword: keyword arguments: args. >> pragma setMethod: aGsMethod. >> pragmas add: pragma]. >> ^pragmas >> % >> >> and the following should return the above as the method source: >> >> Behavior sourceCodeAt: #createPragmaFrom:for: >> >> If all of these things work to this point, then I'll have to think a bit >> and dig a bit deeper into the problem... >> >> Dale >> >> >> On 02/22/2011 04:47 AM, Pieter Nagel wrote: >> > We are trying to bootstrap GLASS into a production database that has >> > been converted from 32bit to 64 bit. At least, not GLASS itself, but >> > just as much of it as is present in extent0.seaside.dbf so that we can >> > use GemTools/pharo to log into the database and edit code. >> > >> > We are using installMaster24.topaz as shipped with 2.4.4.4 to do the >> > job. The process works for us with a development database that starts >> > off with an extent0.dbf as shipped in 2.4.4.4, but it does not work if >> > we do it to a database that has been converted from 32bit to 64bit. >> > >> > It fails inside BootstrapDriver>>installConfiguration because nil does >> > not understand repositoryOverrides:. That happens because no pragmas on >> > any methods at all are stored, so Metacello sees no version numbers >> > inside ConfigurationOfGLASS and can't create the latest version. >> > >> > The pragmas are not stored, because Behavior>>createPragmaFrom:for: is >> > never changed away from its stub implementation that does nothing but >> > return nil. >> > >> > Bootstrap-DaleHenrichs.179.mcz was supposed to load a new implementation >> > of Behavior>>createPragmaFrom:for: . In the development extent0 >> > database, Bootstrap-DaleHenrichs.179.mcz does so. In the converted >> > database, it seems to have no effect on Behavior>>createPragmaFrom:for:. >> > >> > In order to debug, we edited installMaster24.topaz to do the following >> > before"BootstrapDriver installMcz.": >> > >> > ----- >> > | result | >> > result := Behavior >> > compileMethod: 'createPragmaFrom: aPragmaArray for: aGsMethod >> > >> > | pragma args pragmas keyword | >> > aPragmaArray isEmpty ifTrue: [ ^nil ]. >> > pragmas := Array new. >> > 1 to: aPragmaArray size by: 2 do: [:i | >> > keyword := aPragmaArray at: i. >> > args := aPragmaArray at: i + 1. >> > args == nil ifTrue: [ args := #() ]. >> > pragma := Pragma keyword: keyword arguments: args. >> > pragma setMethod: aGsMethod. >> > pragmas add: pragma]. >> > ^pragmas' >> > category: '*bootstrap' >> > using: GsSession currentSession symbolList. >> > GsFile stdout >> > nextPutAll: 'RESULT '; >> > nextPutAll: result printString; >> > cr; >> > nextPutAll: (Behavior compiledMethodAt: #createPragmaFrom:for:) >> > sourceString; >> > cr >> > ------ >> > >> > In the development database, the above code has the expected effect of >> > modifying the Behavior>>createPragmaFrom:for:. However, in the converted >> > database, the above"succeeds" without modifying the method at all, the >> > method still remains"stuck" at its ^nil implementation. The return >> > value from compileMethod:category:using: is nil though, so there were no >> > compiler errors. >> > >> > We're a bit stumped by this mystery. >> > >> > >> > >> > ___________________________ >> > >> > *Pieter Nagel* >> > Methodology Coach >> > *EFS Investment Solutions* >> > *Equinox*, Block A, Crystal Park One >> > 249 Basden Ave, Lyttelton, Centurion, 0157 >> > South Africa >> > >> > >> > Tel: 0860 378 466 (sharecall) >> > +27 (0)12 644 0518 (for overseas clients) >> > Fax: +27 (0)11 388 3223 >> > www.equinox.co.za <http://www.equinox.co.za> <http://www.equinox.co.za> >> > [hidden email] <mailto:[hidden email]> <mailto:[hidden email]> >> > /___________________________/ >> > >> > >> >> >> Please consider the environment before printing >> >> >> EFS Investment Solutions(Pty)Ltd is a licensed financial services provider. >> >> The contents of the email that you received, which may include one or more attachments, is confidential, and is intended solely for the use of the named recipient(s) in the email. If you have received this email in error, you are not permitted to and must not disclose, distribute, or retain it, and are requested to please notify the sender immediately by return email and delete it thereafter. >> >> Email is not necessarily secure or error free as information could arrive late or contain viruses or could be incomplete, intercepted, corrupted, lost or destroyed. It is the responsibility of the named recipient(s) in the email to ensure that emails are virus free. No employee or intermediary is authorised to conclude a binding agreement on behalf of EFS Investment Solutions by email without express written confirmation by a duly authorised representative of EFS Investment Solutions. The use or contents of the email is intended for EFS Investment Solutions business. If it is used for any other purpose, the views expressed are those of the sender and no liability will attach to EFS Investment Solutions. > ___________________________ > > *Pieter Nagel* > Methodology Coach > *EFS Investment Solutions* > *Equinox*, Block A, Crystal Park One > 249 Basden Ave, Lyttelton, Centurion, 0157 > South Africa > > > Tel: 0860 378 466 (sharecall) > +27 (0)12 644 0518 (for overseas clients) > Fax: +27 (0)11 388 3223 > www.equinox.co.za <http://www.equinox.co.za> > [hidden email] <mailto:[hidden email]> > /___________________________/ > > |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |