Hi Andrei, 2017-02-24 11:31 GMT+01:00 Andrei Chis <chisvasileand...@gmail.com>:
> Hi Thierry, > > Indeed that's the simplest option now that we are using fast table. > > Just now in the case of the Raw view an OrderedCollection is used to store > all displayed elements. > If you display large collections every time you open the Raw view it will > instantiate a collection of size 100k and instantiate 100k objects of > type GTInspectorIndexedNode. With FastTable we can lazily load elements so > we should be able to remove this behaviour and the limit. Just we need to > make sure it will play nicely with automatic refresh. There is also the > issue that when expanding an element in the tree if it's a collection you > don't want to expand all elements. > I'm not sure you need to worry too much about that one; in practical experiments, creating that 100k collection for viewing (and the associated nodes instances) isn't too costly (unless creating the GTInspectorIndexedNodes has hidden costs: I've only experimented with the EyeInspector framework). Opening the tree with all elements works fine in my experiments. Tuning scrolling as done in Bloc is necessary, however. > > I'm looking now on a lazy data source for FastTable that plays nicely with > GTInspector. Let's see how it will go. Help is always welcomed :) > As I said: do not overoptimize that part... just remove that limitation on the raw view and measure. > > I think I used the word paginator in the wrong way. If you have a very > large collection (millions of elements) I do not want to scroll through > elements but most likely jump to a certain element or view just a subset of > all elements. Not really add a paginator like in web pages. > Ok, millions of elements is a bit out of my scope... I'll look for filtering then. Regards, Thierry > > Cheers, > Andrei > > On Fri, Feb 24, 2017 at 10:37 AM, Thierry Goubier < > thierry.goub...@gmail.com> wrote: > >> Hi Andrei, >> >> if you're using fasttable for the Raw view, you should be able to reach >> one 100k elements without issues. I did some experiments and it handles the >> load very well. >> >> Avoid the paginator at any cost. This thing is really user-unfriendly. >> >> Regards, >> >> Thierry >> >> 2017-02-23 20:19 GMT+01:00 Andrei Chis <chisvasileand...@gmail.com>: >> >>> Hi Stef, >>> >>> Currently that's the default behaviour of the Raw view: it displays for >>> collections only the first and the last 21 elements. The Items view however >>> always should display all the elements of a collection. >>> >>> The main problem with the Raw view in Pharo 5 is the speed. In Pharo 6 >>> now the speed of the Raw view is greately improved so we could increase >>> those limits. Still for now there should still be some limit for the Raw >>> view. Ideally we should add a small widget, something like a paginator, for >>> navigating through large and very large collections. >>> >>> Cheers, >>> Andrei >>> >>> On Feb 23, 2017 19:35, "stepharong" <stephar...@free.fr> wrote: >>> >>>> Hi >>>> >>>> I'm trying to debug citezen generation and I have to compare strings. >>>> Now I think that the raw views (in Pharo 50) is not good because we >>>> cannot see all the items in raw format. >>>> See the attachements. It jumps from 21 to 174 ... >>>> and what I want to see is of course in the middle. >>>> >>>> Is it me or there is something wrong there. >>>> Stef >>> >>> >> >
