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

[Mariano Martinez Peck via Glass]

On Tue, Sep 8, 2015 at 4:26 PM, Dale Henrichs <
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> 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> 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/883eec9d/attachment-0001.html>