[Glass] Migrating from 3.2.9 to 3.3.3 block compilation issue
Mariano Martinez Peck via Glass
glass at lists.gemtalksystems.com
Tue Jan 31 19:58:12 PST 2017
BTW... i forgot to say... the on: Warning do: is because else i get:
Warning: cannot find key for optimized literal value oop 655362 (a
SmallInteger)
For many many many closures (I think I get this when I ask #needsRecompile
or #recompile (I don't remember).
Just in case this is useful...
On Wed, Feb 1, 2017 at 12:44 AM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:
>
>
> On Tue, Jan 31, 2017 at 2:25 PM, Dale Henrichs via Glass <
> 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?
>
> Thanks in advance
>
>
>
>
>
>> Dale
>> On 01/30/2017 07:15 PM, Mariano Martinez Peck via Glass wrote:
>>
>> Hi guys,
>>
>> Ok, as Dale found out, some automatic recompilation from `upgradeStone`
>> was not being done because of a GsDevKit_issue.
>> Now, problem is that even with that fixed, I am still finding here and
>> there more and more closures that need recompilation. These are NOT sort
>> blocks of sorted collections nor method. They are closures (from my domain
>> objects) stored somewhere.
>>
>> Now, manually fixing each, like this:
>>
>> anObject setter: anObject getter _sourceString evaluate.
>>
>> Is a pain and not accurate (the closure may be still referenced from
>> another place)...because I must know how to re-assign the new closure. Is
>> there an alternative GENERIC solution to recompile all needed ones? I can
>> think of that but using #become:
>>
>>
>> System commit.
>> [
>> MCPlatformSupport installAlmostOutOfMemoryStaticHandler: 75.
>> ExecBlock allSubInstances do: [:each |
>> each become: each _sourceString evaluate.
>> ].
>> ]
>> ensure: [ MCPlatformSupport uninstallAlmostOutOfMemoryStaticHandler ].
>> System commit.
>>
>> But...comment of #become: says that BlockClosure instances cannot be
>> become...BUUUUUUH.
>>
>> So.. any idea?
>>
>> Thanks in advance,
>>
>>
>>
>>
>>
>> On Thu, Jan 26, 2017 at 4:01 PM, Mariano Martinez Peck <
>> marianopeck at gmail.com> wrote:
>>
>>> Hi guys,
>>>
>>> I am migrating some stones (tODE and GsDevKit based) that are on
>>> GemStone 3.2.9 to 3.3.3. I am doing this with the `upgradeStone` gsDevKit
>>> command.
>>>
>>> I first hit one problem when trying to execute this code via topaz:
>>>
>>> MCRepositoryGroup default removeRepository: (MCHttpRepository
>>> location: 'xxx'
>>> user: ''
>>> password: '').
>>>
>>>
>>>
>>>
>>> *ERROR 2142 , a ImproperOperation occurred (error 2142), Cannot execute
>>> method, 'method needs recompile, MCRepositoryGroup class >> default , oop
>>> 206736385' (ImproperOperation) *
>>>
>>> Then, I said...ok, let's connect with tODE and investigate some more
>>> (like doing Object _objectForOop: 206736385). But when I try to connect
>>> with tODE I get:
>>>
>>>
>>> *Error running testLogin:*
>>>
>>> *'Error: Unable to log into server:a ImproperOperation occurred (error
>>> 2142), Cannot execute method, ''method needs recompile, TDTopezServer class
>>> >> createFor: , oop 245949953''with: ''TDTopezServer createFor: 1'''*
>>>
>>> * NOTE: netldi log can be found in the file:
>>> '$GS_HOME/server/stones/<stone-name>/logs/netldi.log'.*
>>>
>>>
>>>
>>> So...looks like I have methods to be recompiled everywhere. I saw this
>>> issue [1] but that does not seem to help as these closures are not in
>>> sorted collections right ?
>>>
>>> Now, manually fixing each, like this:
>>>
>>> | sc sortBlock val cls str val |
>>> sc := "sortedcollection instance".
>>> sortBlock := sc sortBlock.
>>> str := sortBlock _sourceString.
>>> val := str evaluate.
>>> sc _sortBlock: val
>>>
>>> Is a pain...because I must know how to re-assign the new compiled
>>> method. Is there an alternative GENERIC solution to recompile all needed
>>> ones? I can think of that but using #become:
>>>
>>>
>>> System commit.
>>> [
>>> MCPlatformSupport installAlmostOutOfMemoryStaticHandler: 75.
>>> ExecBlock allSubInstances do: [:each |
>>> each become: each _sourceString evaluate.
>>> ].
>>> ]
>>> ensure: [ MCPlatformSupport uninstallAlmostOutOfMemoryStaticHandler ].
>>> System commit.
>>>
>>> But...comment of #become: says that BlockClosure instances cannot be
>>> become...BUUUUUUH.
>>>
>>> So.. any idea?
>>>
>>> Thanks in advance,
>>>
>>> [1] https://github.com/GsDevKit/GsDevKit_home/issues/70
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>> _______________________________________________
>> Glass mailing listGlass at lists.gemtalksystems.comhttp://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>>
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
--
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170201/9d08aa61/attachment-0001.html>
More information about the Glass
mailing list