Smalltalk › Pharo › Pharo Smalltalk Developers

Seamless integration with GTInspector

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Andrei Chis

Seamless integration with GTInspector

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

Denis Kudriashov

Re: Seamless integration with GTInspector

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 <[hidden email]>:

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

Andrei Chis

Re: Seamless integration with GTInspector

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 <[hidden email]> 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 <[hidden email]>:
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