February 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Raw pane on byteStrings

by Thierry Goubier

2017-02-24 15:43 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > > > On Fri, Feb 24, 2017 at 3:28 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> 2017-02-24 14:29 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: >> >>> There should be no hidden costs in GTInspectorIndexedNodes. >>> I made some experiments in the latest Pharo version and opening the Raw >>> view on an array with one million numbers takes around 120ms when 100k >>> elements are computed. >>> I'll be curious how much it takes on your machine. To test update >>> indexableDisplayLimit to 50000 in Object>>#gtInspectorVariableNodesIn: >>> and remove the annotation from Collection>>#gtInspectorItemsIn: (so >>> that the Items presentation is not loaded) >>> >>> arrayLarge := (1 to: 1000000) asArray. >>> >> >> I really wondering why anybody want instantiate wrapper objects for all >> array items? Fast table approach is to not do that. Only visible part of >> items should be recreated >> > > This is how the inspector works for the Items view for Array objects. It > also does not use any wrappers and only computes visible part. > > As I said, it brings in a lazy data source adapted to arrays in a case where it may well be not needed. My experiments show that there is no need for this optimisation, at least for arrays ~ 100k. Thierry

Feb. 24, 2017

Pharo days 2017 at Lille: block the dates 18/19 of May

by stepharong

Dear Pharoers Iâm happy to tell you that we will organise a new edition of the PharoDays at Lille the 18 et 19 of May. The program and registration will be announced soon. The setup will be similar to the ones of previous editions: Little cool presentations and hacking/discussions sessions and a great social event. https://medium.com/concerning-pharo/pharo-days-2016-c52fe4d7caf#.mqurj6rvi So reserve the dates. S. PS: for students, we got some sponsoring from inria and cristal and if you need support let us know.

Feb. 24, 2017

Re: [Pharo-dev] Raw pane on byteStrings

by Thierry Goubier

2017-02-24 15:28 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2017-02-24 14:29 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > >> There should be no hidden costs in GTInspectorIndexedNodes. >> I made some experiments in the latest Pharo version and opening the Raw >> view on an array with one million numbers takes around 120ms when 100k >> elements are computed. >> I'll be curious how much it takes on your machine. To test update >> indexableDisplayLimit to 50000 in Object>>#gtInspectorVariableNodesIn: >> and remove the annotation from Collection>>#gtInspectorItemsIn: (so that >> the Items presentation is not loaded) >> >> arrayLarge := (1 to: 1000000) asArray. >> > > I really wondering why anybody want instantiate wrapper objects for all > array items? Fast table approach is to not do that. Only visible part of > items should be recreated > If you want. The fasttable code does the first thing of not creating a wrapper interactive representation for all elements (i.e. a Morph). Then the datasources may also be lazy: only wrap the objects for which a representation is asked. The thing is that to be able to plan that in totally generic UIs like an inspector, is that you need to create placeholders (one way or another) to let the UI knows what kind and how many elements the datasource holds... if the cost is low enough, just creating a placeholder for each element may turn out to be just fine. And the truth is, in local memory, creating a placeholder for every element in a 100k collection costs about 0. Remote can be handled either by a lazy source, or just by blindly creating placeholders and caching the accesses to the real remote objects (with the fact that you can expect that remote requests are only done when displaying the element, not when building the widget). Simple, easy, fast enough, and maybe better than considering than a lazy source on a remote source is a ad-hoc implementation of a cache. Regards, Thierry

Feb. 24, 2017

Re: [Pharo-dev] Raw pane on byteStrings

by Andrei Chis

On Fri, Feb 24, 2017 at 3:28 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-02-24 14:29 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > >> There should be no hidden costs in GTInspectorIndexedNodes. >> I made some experiments in the latest Pharo version and opening the Raw >> view on an array with one million numbers takes around 120ms when 100k >> elements are computed. >> I'll be curious how much it takes on your machine. To test update >> indexableDisplayLimit to 50000 in Object>>#gtInspectorVariableNodesIn: >> and remove the annotation from Collection>>#gtInspectorItemsIn: (so that >> the Items presentation is not loaded) >> >> arrayLarge := (1 to: 1000000) asArray. >> > > I really wondering why anybody want instantiate wrapper objects for all > array items? Fast table approach is to not do that. Only visible part of > items should be recreated > This is how the inspector works for the Items view for Array objects. It also does not use any wrappers and only computes visible part.

Feb. 24, 2017

Re: [Pharo-dev] Raw pane on byteStrings

by Denis Kudriashov

2017-02-24 14:29 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > There should be no hidden costs in GTInspectorIndexedNodes. > I made some experiments in the latest Pharo version and opening the Raw > view on an array with one million numbers takes around 120ms when 100k > elements are computed. > I'll be curious how much it takes on your machine. To test update > indexableDisplayLimit to 50000 in Object>>#gtInspectorVariableNodesIn: > and remove the annotation from Collection>>#gtInspectorItemsIn: (so that > the Items presentation is not loaded) > > arrayLarge := (1 to: 1000000) asArray. > I really wondering why anybody want instantiate wrapper objects for all array items? Fast table approach is to not do that. Only visible part of items should be recreated

Feb. 24, 2017

Re: [Pharo-dev] Raw pane on byteStrings

by Thierry Goubier

2017-02-24 14:29 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > > > On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> Hi Andrei, >> >> 2017-02-24 11:31 GMT+01:00 Andrei Chis <chisvasileandrei(a)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). >> > > There should be no hidden costs in GTInspectorIndexedNodes. > I made some experiments in the latest Pharo version and opening the Raw > view on an array with one million numbers takes around 120ms when 100k > elements are computed. > I'll be curious how much it takes on your machine. To test update > indexableDisplayLimit to 50000 in Object>>#gtInspectorVariableNodesIn: > and remove the annotation from Collection>>#gtInspectorItemsIn: (so that > the Items presentation is not loaded) > > arrayLarge := (1 to: 1000000) asArray. > arrayLarge inspect. > This is the values I get on my work laptop (core i3-2350M 2.30 Ghz); both inspectors displays 100k elements. (1 to: 1000000) asArray in: [ :s | [s inspect] timeToRun] 0:00:00:00.064 (1 to: 1000000) asArray in: [:s | [GTInspector inspect: s] timeToRun] 0:00:00:00.381 Pharo 6 60411 > > >> >> 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. >> > > If I measure the Items view on the previous array it takes around 35ms. > What I'd like to have is the same opening time for the Items view on large > Sets and Dictionaries. > On my machine, the experiment is that displaying the set is fast, but the system becomes totally unresponsive... which may be an issue with the self refresh of the inspector. Yes, it was the culprit. (1 to: 1000000) asSet in: [ :s | [s inspect] timeToRun] 0:00:00:00.034 (1 to: 1000000) asSet in: [:s | [GTInspector inspect: s] timeToRun] 0:00:00:00.199 Regards, Thierry > > >> >> >>> >>> 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. >> > > Yes, definitely filtering is the way to go there :) > > Cheers, > Andrei > > >> >> Regards, >> >> Thierry >> >> >>> >>> Cheers, >>> Andrei >>> >>> On Fri, Feb 24, 2017 at 10:37 AM, Thierry Goubier < >>> thierry.goubier(a)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 <chisvasileandrei(a)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" <stepharong(a)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 >>>>> >>>>> >>>> >>> >> >

Feb. 24, 2017

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

by Esteban A. Maringolo

If anybody ever did an `apt-cache search name` it will be clear that having a good, concise, intention revealing package name is better than having a sophisticated one. I don't see how in Pharo catalogs and other discovery/browsing mechanisms it would be different. Best regards! Esteban A. Maringolo 2017-02-24 7:34 GMT-03:00 Markus Fritsche <mfritsche(a)reauktion.de>: > Hello, > > I guess the vote is already cast, but I'd like to add my two Cents: > > the packages now have a description that give an idea about what the package > is supposed to do. Still, discoverability should be considered when finding > a name. That's why I would prefer something like TelePharo, since the name > already hints at the core functionality. > > Best regards, > Markus > > > Am 29.01.2017 15:14, schrieb stepharong: >> >> Hi guys >> >> Since we will push the remote tools (videos/web...) I would like to >> get some ideas for a cool name. >> Any ideas? >> >> Because Pharmide (looks like medicine or chemical product). >> Since I vaguely remember some german Pharmide made me think about >> Fern(sehen) but this is not a good name. >> >> Stef >> >> >> -- > >

Feb. 24, 2017

Re: [Pharo-dev] Raw pane on byteStrings

by Andrei Chis

On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > Hi Andrei, > > 2017-02-24 11:31 GMT+01:00 Andrei Chis <chisvasileandrei(a)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). > There should be no hidden costs in GTInspectorIndexedNodes. I made some experiments in the latest Pharo version and opening the Raw view on an array with one million numbers takes around 120ms when 100k elements are computed. I'll be curious how much it takes on your machine. To test update indexableDisplayLimit to 50000 in Object>>#gtInspectorVariableNodesIn: and remove the annotation from Collection>>#gtInspectorItemsIn: (so that the Items presentation is not loaded) arrayLarge := (1 to: 1000000) asArray. arrayLarge inspect. > > 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. > If I measure the Items view on the previous array it takes around 35ms. What I'd like to have is the same opening time for the Items view on large Sets and Dictionaries. > > >> >> 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. > Yes, definitely filtering is the way to go there :) Cheers, Andrei > > Regards, > > Thierry > > >> >> Cheers, >> Andrei >> >> On Fri, Feb 24, 2017 at 10:37 AM, Thierry Goubier < >> thierry.goubier(a)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 <chisvasileandrei(a)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" <stepharong(a)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 >>>> >>>> >>> >> >

Feb. 24, 2017

Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso

by Pavel Krivanek

2017-02-24 13:53 GMT+01:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: > On 24/02/2017 13:36, Pavel Krivanek wrote: > > Hi, > > > > I have published a short video of the Pharo bootstrapping from a Ring > > model that is browsed and modified by the Calypso browser. > > > > https://www.youtube.com/watch?v=QguZSPKo7-w > > > > No audio, please enable subtitles for the description. > > > > Cheers, > > -- Pavel > > Hi! > > Can you explain a little what is Ring model for those who don't know as > me? :D > > Ring is a Smalltalk metamodel implementation. It's simply a set of classes that statically describe elements in the Smalltalk system, like classes, methods, instance variables etc. Ring was included into the image in Pharo 1.4. Currently we have several similar metamodels in the image or as external projects. Monticello definitions, RBBrowserEnvironment, Ring, Ficus. We are working on the new Ring implementation that tries to solve problems of the original one and enables things like: - browse packages without need of loading them - analyse them (QA checks, ...) - bootstrap from an environment model - work on remote images - join and analyze several models as one (like image model+external package model) - work with incomplete models etc. In ideal state the metamodel should be a layer on top of the environment which all tools use and thus you can use the same workflow for various code sources. Like be able to modify and explore an external package with the standard Pharo tools without need of installation of it. Cheers, -- Pavel > -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

Feb. 24, 2017

Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso

by Cyril Ferlicot D.

On 24/02/2017 13:36, Pavel Krivanek wrote: > Hi, > > I have published a short video of the Pharo bootstrapping from a Ring > model that is browsed and modified by the Calypso browser. > > https://www.youtube.com/watch?v=QguZSPKo7-w > > No audio, please enable subtitles for the description. > > Cheers, > -- Pavel Hi! Can you explain a little what is Ring model for those who don't know as me? :D -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Feb. 24, 2017