[Glass] Grrrr cannot migrate (class rename with subclasses and with a name of a deleted class)

[Dale Henrichs via Glass]

Just rename the temps to ones that compile:)

This time around we are not suspecting that blockClosures and block 
temps are the problem, we are just trying to get the args to the 
primitive call  when it fails, so we can trace things further in the C 
code and try determine the code path that leads to a nil return value ...

Dale

On 09/08/2015 12:49 PM, Mariano Martinez Peck wrote:
>
>
> On Tue, Sep 8, 2015 at 4:26 PM, Dale Henrichs 
> <dale.henrichs at gemtalksystems.com 
> <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>
>     Mariano,
>
>     Sorry for the delay, but I'm back in the office today and what we
>     would like to do is capture the args that are being used for the
>     primitive so replaicing the `memOnlyBool` block logic in the
>     listInstances:.... method with the following will help us get them:
>
>
> Hi Dale, no worries, thanks for pushing!
>
>       memOnlyBool
>         ifFalse: [
>           scanBlk := [ :scanSetThisTime | | ret sKind |
>           sKind := (directoryString ifNotNil:[ 2 ] ifNil:[ 0 ]).
>           ret := self
>             _scanPomWithMaxThreads: maxThreads
>             waitForLock: 60
>             pageBufSize: 8
>             percentCpuActiveLimit: aPercentage
>             identSet: scanSetThisTime
>             limit: aSmallInt
>             scanKind: sKind
>             toDirectory: directoryString ].
>         ret ifNil: [
>            Transcript cr; show: '_scanPomWithMaxThreads failure: ',
>                     maxThreads printString, ' ',
>                     aPercentage printString, ' ',
>                     scanSetThisTime printString, ' ',
>                     aSmallInt printString, ' ',
>                     sKind printString, ' ',
>                     directoryString printString ].
>         ret ].
>
>
> This doesn't compile because 'sKind' was defined inside the 'scanBlk' 
> and 'scanSetThisTime' is the argument to the closure. Since this 
> problem was related to temp vars, I am not sure which is the correct 
> solution.
>
> Let me know,
>
>     We thought the problem might have been related to the method temp
>     reference for `(directoryString ifNotNil:[ 2 ] ifNil:[ 0 ])`, but
>     since the prim is still failing with that expression inlined there
>     must be a different (less obvious) failure mechanism.
>
>     Dale
>
>
>     On 09/01/2015 11:45 AM, Mariano Martinez Peck wrote:
>>     OK then. Perfect. Let me know.
>>     Thanks!
>>
>>     On Tue, Sep 1, 2015 at 3:28 PM, Dale Henrichs
>>     <dale.henrichs at gemtalksystems.com
>>     <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>>
>>
>>
>>         On 9/1/15 10:59 AM, Mariano Martinez Peck wrote:
>>>
>>>         On Tue, Sep 1, 2015 at 2:14 PM, Dale Henrichs
>>>         <dale.henrichs at gemtalksystems.com
>>>         <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>>>
>>>             Could you arrange to get a stack trace from your most
>>>             recent error and a listing of the method that you used
>>>             ... I want to make sure that we understand the failure
>>>             mechanism ... if it is related to block temps then it is
>>>             fixed in 3.2.x, but if it is not related to block temps
>>>             then it could be present in later versions of GemStone
>>>             and we'll want to characterize the problem ....
>>>             Obviously, this particular call doesn't reproduce very
>>>             frequently (I wasn't able to make it break with trivial
>>>             examples) so there is likely to be something a little
>>>             more complex going on ...
>>>
>>>
>>>         Dale, the exception I get is the one I original shared with
>>>         you and you got to the same conclusion as I did.
>>>
>>>         What I can offer you is this that I log the error
>>>         (continuation) in the object log and the provide you a user
>>>         for the web user for our app and from there I can allow you
>>>         open a kind of Seaside debugger/inspector which will be much
>>>         richer than a plain string stack and at least you can also
>>>         print/inspect from there. I cannot send you the extent
>>>         because its quite big.
>>>
>>>         If you think this is OK, then I please need you to ask you
>>>         to only share the login info with GemTalks engineer. Since
>>>         the site is a bit on use (but with a working extent) I must
>>>         recover from backup and so the system will be running with a
>>>         "broken" extent for a while. No problem with this but if
>>>         this will be only a couple of hours or 1-2 day max. So if we
>>>         will do this, I would appreciate that you let me know when
>>>         (you or the engineer) would be available to take a look.
>>>
>>>         Let me know if you want this.
>>>
>>         Thanks for the offer ... we might want to instrument up the
>>         method a bit more instead of looking at a continuation ... so
>>         I will get back to you ... I won't be in the office until
>>         Thursday, and that's when I will talk things over with the
>>         engineer ...
>>
>>         Dale
>>
>>
>>
>>
>>     -- 
>>     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/20150908/c46b253b/attachment-0001.html>