Re: [Pharo-dev] Seamless integration with GTInspector

2017-03-04 Thread Andrei Chis
Hi Denis,

Thanks for the clarification. Then it's good as Seamless will not be
impacted by this.
Let me if/when you start looking making GTInspector in Seamless use
FastTable.

I think I'll still add a tiny cache so that the string representation is
not recomputed every time.

Cheers,
Andrei

On Sat, Mar 4, 2017 at 6:07 PM, Denis Kudriashov 
wrote:

> Hi Andrei
>
> I already adopted Seamless to changes in GTInspector. So everything works
> well.
> For now I do not follow your fast table solution. Remote and local
> presentations are implemented with old approach. I just copied few methods
> from old GT version to make it work.
> So it works same way as before and compatible with Pharo 5.
> In future I will reuse new fast table approach.
>
> Thank's for thinking about it :)
>
>
> 2017-03-04 17:48 GMT+01:00 Andrei Chis :
>
>> Hi Denis,
>>
>> Can you try Seamless with GTInspector in the latest version of Pharo or
>> Moose and let me know if you see any slowness. Not sure how Seamless uses
>> GTInspector to inspect proxy objects but now as the inspector uses
>> FastTable by default there is no cache whatsoever.  What this means is that
>> the string representation shown in a FastTable presentation is recomputed
>> every time fast table needs to display an element in a row or column. For
>> example, this is the case when you scroll or when you resize the window
>> (all visible elements are recomputed).
>>
>> In a local context the inspector is still very fast as it is. Just we
>> should double check that it's also the case for Seamless. If not there are
>> some caches that could be put into place relatively easy, either at the
>> level of the inspector or fast table. Just before doing this I'd like to
>> know if this is actually a problem.
>>
>> Cheers,
>> Andrei
>>
>
>


Re: [Pharo-dev] Seamless integration with GTInspector

2017-03-04 Thread Denis Kudriashov
Hi Andrei

I already adopted Seamless to changes in GTInspector. So everything works
well.
For now I do not follow your fast table solution. Remote and local
presentations are implemented with old approach. I just copied few methods
from old GT version to make it work.
So it works same way as before and compatible with Pharo 5.
In future I will reuse new fast table approach.

Thank's for thinking about it :)


2017-03-04 17:48 GMT+01:00 Andrei Chis :

> Hi Denis,
>
> Can you try Seamless with GTInspector in the latest version of Pharo or
> Moose and let me know if you see any slowness. Not sure how Seamless uses
> GTInspector to inspect proxy objects but now as the inspector uses
> FastTable by default there is no cache whatsoever.  What this means is that
> the string representation shown in a FastTable presentation is recomputed
> every time fast table needs to display an element in a row or column. For
> example, this is the case when you scroll or when you resize the window
> (all visible elements are recomputed).
>
> In a local context the inspector is still very fast as it is. Just we
> should double check that it's also the case for Seamless. If not there are
> some caches that could be put into place relatively easy, either at the
> level of the inspector or fast table. Just before doing this I'd like to
> know if this is actually a problem.
>
> Cheers,
> Andrei
>


[Pharo-dev] Seamless integration with GTInspector

2017-03-04 Thread Andrei Chis
Hi Denis,

Can you try Seamless with GTInspector in the latest version of Pharo or
Moose and let me know if you see any slowness. Not sure how Seamless uses
GTInspector to inspect proxy objects but now as the inspector uses
FastTable by default there is no cache whatsoever.  What this means is that
the string representation shown in a FastTable presentation is recomputed
every time fast table needs to display an element in a row or column. For
example, this is the case when you scroll or when you resize the window
(all visible elements are recomputed).

In a local context the inspector is still very fast as it is. Just we
should double check that it's also the case for Seamless. If not there are
some caches that could be put into place relatively easy, either at the
level of the inspector or fast table. Just before doing this I'd like to
know if this is actually a problem.

Cheers,
Andrei