[Glass] Awfully slow GRUtf8CodecStream

[Dale Henrichs via Glass]

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...

>
>
>
>> 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?


>
>> 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) ...

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20141015/5de7dd35/attachment-0001.html>