- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Raw pane on byteStrings

by Andrei Chis

Hi Thierry, Strangely enough I'm getting different times on my machine Just to start from the same baseline in a fresh Pharo 60411 image with no changes to any of the inspectors over a series of runs I get: array := (1 to: 1000000) asArray. [array inspect] timeToRun. "0:00:00:00.145" [GTInspector inspect: array] timeToRun. "0:00:00:00.031" If I change indexableDisplayLimit to 50000 and remove the Items view then I get: [GTInspector inspect: array] timeToRun. "0:00:00:00.124" I'm really interested in seeing what makes GTInspector slower on your machine. Did you do other optimizations to SpecInspector? I'm using a MacBook Pro Retina - 2.8 GHz Intel Core i7 Pharo VM version: CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016 git@github.com:pharo-project/pharo-vm.git Commit: 06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200 By: GitHub <noreply(a)github.com> Cheers, Andrei On Fri, Feb 24, 2017 at 3:24 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 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] Pharo bootstrap with Ring and Calypso

by Pavel Krivanek

2017-02-24 16:31 GMT+01:00 Martin Dias <tinchodias(a)gmail.com>: > Great! any idea how far is new Ring from replacing old Ring? > In Pharo 7. Right now the new version can live in the image next to the old one. > > MartÃn > > On Fri, Feb 24, 2017 at 11:58 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> >> >> On Fri, Feb 24, 2017 at 8:36 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com >> > 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. >>> >>> >> Wow wow wow !! Super-cool !! >> I had to watch it a few times. >> 314k image is pretty impressive. >> >> Just to clarify, Calypso is not connected to a remote image but browses >> the bootstrap source code loaded into a Ring Environment? (btw, should we >> call this a "guest environment"?) >> >> When you show the previously opened window "Methods with a string aText >> 'Smalltalk run' ..." >> showing PBImageBuilder50 >> initializeImage, >> that was opened before you created the new Ring Environment and Calypso >> was opened, >> so can I presume it was opened on a similar Ring Environment created >> earlier? >> >> There were no processes in the guest image prior to doing this... >> process := objectSpace >> createProcessWithPriority: 40 >> doing: ('Smalltalk primitiveGarbageCollect. Smalltalk run'). >> objectSpace installActiveProcess: process. >> so this was a single process Image? >> >> You say "The image must contain support for the class builder to be able >> to be bootstrapped." >> When you create the SmalltalkImage>>run method in the guest environment, >> is that actually *running* to compiled as normal using its class builder? >> >> How difficult would it be for the guest image to invoke class builder via >> seamless in the host image? >> And how much smaller could the image get if the class builder was removed. >> >> It could be cool if this bootstrap creation process was integrated in >> PharoLauncher as a GUI tool. Then later the ability to download these >> mini-image to an embedded controller could be added. >> >> cheers -ben >> >> P.S. Could you maybe blog this also, to make it easier to replicate and >> copy-paste the Playground text. >> > >

Feb. 24, 2017

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

by Pavel Krivanek

2017-02-24 15:58 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > > On Fri, Feb 24, 2017 at 8:36 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > 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. >> >> > Wow wow wow !! Super-cool !! > I had to watch it a few times. > 314k image is pretty impressive. > > Just to clarify, Calypso is not connected to a remote image but browses > the bootstrap source code loaded into a Ring Environment? > Yes, Calypso browses an off-line source code loaded into the Ring environment. > (btw, should we call this a "guest environment"?) > It is possible to open Calypso on a Ring model that takes data from the current image so in that case it would be confusing:-) > > When you show the previously opened window "Methods with a string aText > 'Smalltalk run' ..." > showing PBImageBuilder50 >> initializeImage, > that was opened before you created the new Ring Environment and Calypso > was opened, > so can I presume it was opened on a similar Ring Environment created > earlier? > It is a standard Nautilus window on the code in the image that does the bootstrapping. For the standard bootstrap it does much more things. See: https://github.com/guillep/pharo-core/blob/dfbfb77844a31701da6e49691af2a05a… > > There were no processes in the guest image prior to doing this... > process := objectSpace > createProcessWithPriority: 40 > doing: ('Smalltalk primitiveGarbageCollect. Smalltalk run'). > objectSpace installActiveProcess: process. > so this was a single process Image? > Yes, see the method above > > You say "The image must contain support for the class builder to be able > to be bootstrapped." > When you create the SmalltalkImage>>run method in the guest environment, > is that actually *running* to compiled as normal using its class builder? > No, when I create the method, only the source code is set in the Ring model. The model is "dead". The real installation of the method into the generated object memory is done during the bootstrapping. > > How difficult would it be for the guest image to invoke class builder via > seamless in the host image? > The "guest" object memory runs in a special virtual machine simulator during the bootstrapping. That simulator uses AST Interpreter to execute the code inside the guest environment before it is installed for real. It uses own special kind of proxies and tricks to do it. The current bootstrap cannot run without class builder in the guest environment, but... > And how much smaller could the image get if the class builder was removed. > ...Guille in his thesis tried different approaches and he was able to produce extremely small images (~10 KiB) that did for example only a sum of two numbers. https://guillep.github.io/files/publications/Poli15Thesis.pdf > > It could be cool if this bootstrap creation process was integrated in > PharoLauncher as a GUI tool. Then later the ability to download these > mini-image to an embedded controller could be added. > > cheers -ben > > P.S. Could you maybe blog this also, to make it easier to replicate and > copy-paste the Playground text. >

Feb. 24, 2017

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

by Martin Dias

Great! any idea how far is new Ring from replacing old Ring? MartÃn On Fri, Feb 24, 2017 at 11:58 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Fri, Feb 24, 2017 at 8:36 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > 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. >> >> > Wow wow wow !! Super-cool !! > I had to watch it a few times. > 314k image is pretty impressive. > > Just to clarify, Calypso is not connected to a remote image but browses > the bootstrap source code loaded into a Ring Environment? (btw, should we > call this a "guest environment"?) > > When you show the previously opened window "Methods with a string aText > 'Smalltalk run' ..." > showing PBImageBuilder50 >> initializeImage, > that was opened before you created the new Ring Environment and Calypso > was opened, > so can I presume it was opened on a similar Ring Environment created > earlier? > > There were no processes in the guest image prior to doing this... > process := objectSpace > createProcessWithPriority: 40 > doing: ('Smalltalk primitiveGarbageCollect. Smalltalk run'). > objectSpace installActiveProcess: process. > so this was a single process Image? > > You say "The image must contain support for the class builder to be able > to be bootstrapped." > When you create the SmalltalkImage>>run method in the guest environment, > is that actually *running* to compiled as normal using its class builder? > > How difficult would it be for the guest image to invoke class builder via > seamless in the host image? > And how much smaller could the image get if the class builder was removed. > > It could be cool if this bootstrap creation process was integrated in > PharoLauncher as a GUI tool. Then later the ability to download these > mini-image to an embedded controller could be added. > > cheers -ben > > P.S. Could you maybe blog this also, to make it easier to replicate and > copy-paste the Playground text. >

Feb. 24, 2017

Re: [Pharo-dev] Epicea - showing latest lost changes

by Yuriy Tymchuk

I have one more suggestion for Epicea. When the window pops up Iâd like to have a big âRESTOREâ button to reapply all the changes. I think it will be also more user friendly, as how should an newcomer know that he has to select all the items in the list and use the context menu. Cheers. Uko > On 24 Feb 2017, at 08:33, stepharong <stepharong(a)free.fr> wrote: > > Hi martin > > Thanks for our constant improvement of epicea. > In VW they have a nice way to filter > > you can filter the entitiies > doit or not > method or not > packages or not > and you can deselect a selected item. > > this way you can say I do not want any doit except this one. > > > > On Fri, 24 Feb 2017 06:29:36 +0100, Martin Dias <tinchodias(a)gmail.com> wrote: > > Hi. Does this report match your idea? > https://pharo.fogbugz.com/f/cases/19686/Epicea-Filters <https://pharo.fogbugz.com/f/cases/19686/Epicea-Filters> > > Martin > > On Thu, Feb 23, 2017 at 3:35 PM, stepharong <stepharong(a)free.fr <mailto:stepharong@free.fr>> wrote: > I agree :) > > On Wed, 22 Feb 2017 18:10:35 +0100, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > > One thing I am missing from Epicea that I used to be able to do > is being able to filter out old changes. If I've been thrashing > some method back and forth between a few implementations, > often I don't want to see *all* the old changes,only the latest ones. > > An option to restore old versions would also be nice, but I don't think that feature existed previously. > > cheers -ben > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ <http://www.opera.com/mail/> > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ <http://www.opera.com/mail/>

Feb. 24, 2017

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

by Ben Coman

On Fri, Feb 24, 2017 at 8:36 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> 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. > > Wow wow wow !! Super-cool !! I had to watch it a few times. 314k image is pretty impressive. Just to clarify, Calypso is not connected to a remote image but browses the bootstrap source code loaded into a Ring Environment? (btw, should we call this a "guest environment"?) When you show the previously opened window "Methods with a string aText 'Smalltalk run' ..." showing PBImageBuilder50 >> initializeImage, that was opened before you created the new Ring Environment and Calypso was opened, so can I presume it was opened on a similar Ring Environment created earlier? There were no processes in the guest image prior to doing this... process := objectSpace createProcessWithPriority: 40 doing: ('Smalltalk primitiveGarbageCollect. Smalltalk run'). objectSpace installActiveProcess: process. so this was a single process Image? You say "The image must contain support for the class builder to be able to be bootstrapped." When you create the SmalltalkImage>>run method in the guest environment, is that actually *running* to compiled as normal using its class builder? How difficult would it be for the guest image to invoke class builder via seamless in the host image? And how much smaller could the image get if the class builder was removed. It could be cool if this bootstrap creation process was integrated in PharoLauncher as a GUI tool. Then later the ability to download these mini-image to an embedded controller could be added. cheers -ben P.S. Could you maybe blog this also, to make it easier to replicate and copy-paste the Playground text.

Feb. 24, 2017

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

by stepharong

This is what we call having a vision :) > Nice! > > It is interesting how all these projects are coming togetherâ¦ :-) > > Marcus > >> On 24 Feb 2017, at 13:36, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> 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 > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 24, 2017

Re: [Pharo-dev] Pharo 60 : 60410 DNU on commit and no idea how to copy the stack :((((((((((((((((((((((((((((((((((((((((((((((

by stepharong

thanks Yes it will be much better. Stef On Fri, 24 Feb 2017 10:39:51 +0100, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > > On Fri, Feb 24, 2017 at 8:44 AM, stepharong <stepharong(a)free.fr> wrote: >> On Fri, 24 Feb 2017 00:05:10 +0100, Andrei Chis >> <chisvasileandrei(a)gmail.com> wrote: >>>> >>>> >>>> - How do we get the old textual stack description? >>> >>> In the toolbar menu of the stack you find 'Fuel out stack' and 'Copy >>> to clipboard'. >>> 'Copy to clipboard' copies a textual description of the stack that can >>> then be pasted in an email. >>> Is this the "old textual description" or are you referring to >>> something else? >> >> Ok this is what I was looking for.It looks like a generic copy past >> entry so I did not tried it.Can you rename it into copy textual stack? > > Indeed the name is confusing (even if it's always been like that). > I renamed it yesterday to 'Copy Stack to Clipboard'. Is that better? (It > fits also with 'Fuel out Stack') > > Cheers, > Andrei > >> >> Then I do not get why we could not get action about the current context >> and action about the complete stack together.Because these are not >> method that we see but contexts. >>>> >>>> Now I wanted to report it and share with you the stack..... oh >>>> boy! >>>> I thought it was file out but no it just save one method >>>> definition (So great) >>> >>> What action did you use to file our the textual description? >> >> fileout in the main menu when you clik on the stack element.I never >> ever used it since 2006. >> >>>>>> Cheers, >>> Andrei >>> >>> >>>> >>>> I got Fuelout the stack in the menu but this is not what I >>>> want. :((((((((((((((((((((((((((((((( >>>> >>>> - Finally >>>> BTW I clicked on report and I have no idea what it does not >>>> mean. The fly by help is empty :((((( >> >> >> do you have an idea about what is this Send a report: it looks totally >> obscure and useless. >> >>>> >>>> >>>>>>>> So like an idiot I did a screen capture. >>>> This broke totally my feel. In less than 10 min I left like either >>>> the system became less good or I'm totally stupid. >>>> >>>> Stef >>> >> >> >> >> --Using Opera's mail client: http://www.opera.com/mail/ > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 24, 2017

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