[Glass] Migrating from 3.2.9 to 3.3.3 block compilation issue

[Dale Henrichs via Glass]

On 1/31/17 7:44 PM, Mariano Martinez Peck wrote:
>
>
> On Tue, Jan 31, 2017 at 2:25 PM, Dale Henrichs via Glass 
> <glass at lists.gemtalksystems.com 
> <mailto:glass at lists.gemtalksystems.com>> wrote:
>
>     Mariano,
>
>     1. Find allInstances of ExecBlock
>
>     2. Select all instances that #needsRecompile.
>
>     3. Send #recompile to the selected instances and collect instances
>     that signal an error during #recompile. The #recompile method
>     attempts to recompile Simple blocks in-place if there is an error
>     during compilation or the block is not simple, an Error is signaled.
>
>     4. For the remaining instances of ExecBlock, you will have to
>     track down the reference to the block and reinstall a new,
>     recompiled instance of the ExecBlock.
>
>         1. look at the #blockSource and the #receiver for the block
>     and you might recognize the method needed to recreate the block
>
>         2. look at the #blockSource and pick out a likely chunk of
>     source that you can use to search in method source (`browse source
>     --exact `<source-chunk>`)
>
>         3. Use Repository>>findReferencePathToObject: or
>     Repository>>findAllReferencePathsToObject: to find which object(s)
>     are holding onto the block.
>
>
> Hi Dale,
>
> OK, it seems I am not having good luck. I tried the following code:
>
> [
> | allBlocks allBlocksNeedingRecompile blocksFailedToRecompile 
> correctlyRecompiled |
> blocksFailedToRecompile := OrderedCollection new.
> correctlyRecompiled := OrderedCollection new.
> System commit.
> allBlocks := ExecBlock allSubInstances.
> allBlocksNeedingRecompile := allBlocks select: [:each | each 
> needsRecompile ].
> allBlocksNeedingRecompile do: [:each |
> [
> each recompile.
> correctlyRecompiled add: each.
> ] on: Error do: [:ex |
> blocksFailedToRecompile add: each.
> ]
> ].
> System commit.
> Transcript show:  'Correctly recompiled closures: ', 
>  correctlyRecompiled size asString.
> Transcript show: 'Erred recompiled closures: ', 
>  blocksFailedToRecompile size asString.
> ] on: Warning do: [:ex | ex resume  ]
>
>
> And it outputs:
>
> Correctly recompiled closures: 0Erred recompiled closures: 797155
>
> Wow. That's a lot to fix.
>
> But things get strange when I analyze which are the failing closures. 
> For example,  I have an ExecBlock whose source is:
>
> /"This is source for a block.  " /
> / ^ [ /
> /     self error:/
> /         'No concrete db roles associated to '''/
> /           , (FaDBAccessor common users row: username column: 
> 'CONCRETE ROLE')/
> /           , ''' of user ''' , username/
> /           ,/
> /             '''. Either the concrete db role id is wrong or the 
> roles must be added to concreteRoles.csv' /
> /]/
>
>
>
> That closure, is a closure of an ifEmpty:  of the 
> method #sessionMapFor:prepareAccessLimitingSessionsWith:
> See:
>
> sessionMapFor: username prepareAccessLimitingSessionsWith: 
> aDictionaryOfPreparationBlocks
> | answer  concreteRole abstractRoleID  |
> answer := IdentityDictionary new.
> concreteRole := self concreteRoleForUsername: username.
> concreteRole
>    ifEmpty: [
>      self error:
>          'No concrete db roles associated to '''
>            , (FaDBAccessor common users row: username column: 
> 'CONCRETE ROLE')
>            , ''' of user ''' , username
>            ,
>              '''. Either the concrete db role id is wrong or the roles 
> must be added to concreteRoles.csv'
> ].
> .....
>
>
> What is going on? I re-load all my app code after I upgraded stone so 
> I expect that method to have been recompiled. In fact, I just edited 
> the method and saved it again (so that a recompilation was triggered) 
> and the above closure still appears as needing compilation!
>
> Even worst....   the _method  instVar of that example IS NOT IDENTICAL 
> (same OOP) to the one installed in the method dictionary 
> (FaDBSessionsByRolesFactory >> 
> #sessionMapFor:prepareAccessLimitingSessionsWith: ). So it looks like 
> if they were un-installed closures.
>
> I thought it could be some MC version history around or whatever. So I 
> performed my typical GC and cleanup code which should collect all that 
> garbage. Still same numbers.
>
> mmmm I am running out of ideas.
>
> Thoughts?
I imagine that the #sessionMapFor:prepareAccessLimitingSessionsWith: 
method is in an older version of the class, which would explain the 
differences in oops and the fact that when you recompile the method in 
the current version of the class, you don't eliminate block that needs 
to be recompiled ...

`GsDeployer new classesWithClassHistory` should give you the list of 
classes that have older versions ...

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170131/91873013/attachment.html>