[Glass] Awfully slow GRUtf8CodecStream

[Mariano Martinez Peck via Glass]

On Wed, Oct 15, 2014 at 7:18 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

>
>
> On Wed, Oct 15, 2014 at 2:23 PM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>>
>>
>> On Wed, Oct 15, 2014 at 5:56 PM, Dale Henrichs <
>> dale.henrichs at gemtalksystems.com> wrote:
>>
>>>
>>>
>>> On Wed, Oct 15, 2014 at 9:39 AM, Mariano Martinez Peck via Glass <
>>> glass at lists.gemtalksystems.com> wrote:
>>>
>>>>
>>>>
>>>> Another reason of the slowness in gemstone is that I don't have native
>>>> code enabled in the seaside gems. I would like to do so, but then I cannot
>>>> remote debug anymore.
>>>>
>>>>
>>> Mariano,
>>>
>>> With the 3.1.0.6 and 3.2.2 (the two versions that I've tested with), you
>>> CAN do remote debugging without diabling native code ...
>>>
>>>
>> mmmmmmm if I understand this correct...then this is huge good news (in
>> 3.1.0.5 I was never ever able to do that).
>>
>>
>>
>>> I know the  startSeaside30_Adaptor script has some code that doesn't
>>> enable the Breakpoint exception unless native code is enabled, but that is
>>> no longer correct (and it looks like I won't be able to fix that before
>>> 3.2.3 gets released either as the release is imminent)...
>>>
>>
>> OK. I use my own "form" of startSeaside30_Adaptor so I have no problem to
>> change myself my script. The part you seem to refer is this?
>>
>> *GsProcess usingNativeCode not*
>>   ifTrue: [
>>     "Enable remote Breakpoing handling"
>>     Breakpoint trappable: true.
>>     GemToGemAnnouncement installStaticHandler.
>>     System commitTransaction ifFalse: [ nil error: 'Could not commit for
>> GemToGemSignaling' ].
>>   ].
>>
>> If I understand you correct, what you say is that from 3.1.0.6 and beyond
>> I should remove the "GsProcess usingNativeCode not"  IF ?
>>
>
> yes ... from 3.1.0.6 on (at least), you can enable the Breakpoint
> exception and use breakpoints for remote debugging...
>
>>
>>
Cool!



>
>>
>>> There are still some issues in 3.2.2 (and earlier) with proceeding from
>>> remote Breakpoints,
>>>
>>
>> Ok, that is asking too much ;) I am ok with at least be able to debug and
>> not be able to proceed :)
>>
>
> When you say "remote debug" are you referring specifically to setting
> remote breakpoints?
>
>
I referring when you click remote debug from seaside error handler and then
debug it from gemtools


>
>>
>>> but the error handling and other facilities work quite fine with Native
>>> code enabled .. the vms have been updated so that native code is
>>> automatically disabled when a breakpoint is hit, but new processes will be
>>> created in native mode ...
>>>
>>>
>> mmmm do you recall when that was changed? I ask because I checked the
>> release notes of 3.1.0.6 for this exact issue:
>> http://downloads.gemtalksystems.com/docs/GemStone64/3.1.x/GS64-ReleaseNotes-3.1.0.6.pdf
>>
>> and I found no mention at all about this... and with 3.1.0.5 it never
>> worked for me....so....the VM were updated even before 3.1.0.6 and the
>> reason it didn't work for me was because of the above IF? or the changes to
>> the VM were forgotten in 3.1.0.6 release notes?
>>
>> Thanks for any clarification!
>>
>
> there are two things at work here ... the version of Seaside and the
> capability within the vm ... I reviewed the release notes myself and did
> not see anything talking about native code changes related to debugging, so
> I'm not sure myself when breakpoints and native code got cleaned up
> (probably somewhere between 3.1.0.2 and 3.1.0.5 )... unfortunately we don't
> necessarily record all changes made to the system in release notes ...
>
> The version of Seaside also plays a role ... Although I can't find
> anything in the commit logs, I seem to remember that I did some work this
> year to make sure that remote breakpoints were funcational and I recall
> that I did have to fix some bugs to get things rolling again, so the
> potential for remote breakoints may have been in 3.1.0.5, but the code
> wasn't present in Seaside (or perhaps GLASS) ...
>
>
Thanks Dale.....this is very good news. I just tried with an old test case
I had that reproduced the none-working scenario and now it works (with
native code enabled). So...cool...I can finally have a JIT :)

Thank you very much.



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20141016/f593fe00/attachment.html>