[Glass] Again, Corrup Error preventing debugging real seaside exception

Mariano Martinez Peck via Glass glass at lists.gemtalksystems.com
Fri Feb 3 05:12:13 PST 2017


Dale,

Note that the #nextPutAll: is indeed for Grease and I opened an issue
there. But the change on Utf8 >> asString is part of GemStone itself. Would
you open an issue for that one too so we don't forget? if true, then please
share with me the issue number (I keep track of these).

Thanks

On Thu, Feb 2, 2017 at 11:34 AM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> Yes, there is a bug in selfValue --- the source of the corruptObj error
> ---we haven't  characterized the bug, until we understand the cause, a
> corruptObj error could occur anytime an attempt to create a continuation is
> made or a even debugger opened , so yes you should leave the #selfValue
> patch in until we get to the bottom of the VCContext bug...
>
> Dale
> On 2/2/17 5:16 AM, Mariano Martinez Peck wrote:
>
> Uhhh I forgot to ask.... is the change on #selfValue still needed? I
> mean....sure I can remove it and test, but I am wonder on other scenarios
> than mine. Please let me know.
>
> Thanks
>
> On Thu, Feb 2, 2017 at 10:15 AM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>> OK, Opened issue: https://github.com/SeasideSt/Grease/issues/22
>>
>> Cheers,
>>
>> On Wed, Feb 1, 2017 at 7:49 PM, Dale Henrichs <
>> dale.henrichs at gemtalksystems.com> wrote:
>>
>>>
>>>
>>> On 2/1/17 12:57 PM, Mariano Martinez Peck wrote:
>>>
>>>
>>>
>>> On Wed, Feb 1, 2017 at 5:50 PM, Dale Henrichs <
>>> dale.henrichs at gemtalksystems.com> wrote:
>>>
>>>> Mariano,
>>>>
>>>> This second error is not related to the earlier error we were tracking
>>>> ... I don't see an actual error message in your email, so I'm not exactly
>>>> sure what is breaking here ...
>>>>
>>>
>>> The error message is the one of the screenshot rendered in the browser
>>> (attachment named "Screen Shot 2017-02-01 at 5.13.31 PM.png").
>>>
>>> That error message was "CorruptObj" and the error message I was looking
>>> for was the error message from the #changeClassTo: ... The stack that you
>>> supplied us with was different from the #changeClassTo: stack, as I didn't
>>> see selfValue on the stack ... doesn't matter though
>>>
>>>
>>>
>>>> Nonetheless, #changeClassTo: was a nasty little performance hack that
>>>> is no longer needed.
>>>>
>>>> In GRUtf8CodecStream>>nextPutAll: the following should be done:
>>>>
>>>>   binary
>>>>     ifTrue: [ stream nextPutAll: aString asString ]
>>>>     ifFalse: [ stream nextPutAll: aString _encodeAsUTF8intoString ]
>>>>
>>>> and in Utf8>>asString the following should be done:
>>>>
>>>>     ^ self decodeToUnicode
>>>>
>>>> It is odd that this "trick" is failing now (especially without an error
>>>> message), but I think the right answer is to eliminate the use of
>>>> #changeClassTo:
>>>>
>>>
>>> Thanks!! Those changes DID fix it!!!  Wow...it was hard one this one...
>>> I am glad we find it. Do you need anything more from me to open issue or
>>> whatever? I will live with overrides for the moment.
>>>
>>> Please open an issue against Grease ... up on SeasideST so that we can
>>> get the fix in ... the #changeTo: hack looks like it went in around 3.2.2,
>>> so I'm not exactly sure when _encodeAsUTF8intoString was added to the
>>> system (it was added to replace the #changeTo: hack)...
>>>
>>>
>>> BTW, are you sure about performance? Because I remember that
>>> changeClass: hack did improve performance significantly. I wouldn't want to
>>> loos that performance boost!
>>>
>>> Well, the issue that changeClassTo: was trying to solve was the
>>> conversion of the Utf8 instance (ByteArray) into a String (required by
>>> Seaside). #'_encodeAsUTF8intoString' encodes utf8 directly into a String
>>> instance .... so the performance should be no worse than #changeClassTo:
>>>
>>> Dale
>>>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>
> --
> 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/20170203/c7494931/attachment.html>


More information about the Glass mailing list