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

Re: [Pharo-dev] [ANN] Woden 2 first release for OS X and Linux

by Ronie Salgado

Hello, I updated the BaselineOf, so now Woden 2 is loading the game system by default. I still have to restore the level editor and the Roassal 3D. With this update it is now possible to do the following (It requires OpenAL for the sound): map := WTGSMap loadJsonFromFileNamed: 'core-assets/maps/demos/esug-2016.json'. WTGSLevelPlayer new map: map; spawn; openInOSWindow. Best regards, Ronie [image: ImÃ¡genes integradas 1] 2017-02-26 10:10 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > This is great Ronie! > I tried and it works like a charm. > Impressive work! > > This will revive the Roassal3D project! > > Alexandre > > > On Feb 23, 2017, at 10:02 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > > > Hello, > > > > Finally I am glad to announce a first release of Woden 2. I made a > hopefully simplified process for loading Woden 2 out of the box. > > > > For loading and testing Woden 2, follow the instructions at: > > > > https://github.com/ronsaldo/woden2 > > > > In this release, I am not loading the level editor by default because it > depends on an outdated version of Bloc. Until I fix the dependency problem > of the Level editor, it will remain unusable. > > > > Because Woden 2 requires Metal on OS X, it requires 64 bits on OS X, > which can be unstable. This is tested on OS X El Capitan. I do not know > whether it will work or not on OS X Sierra. > > > > Best regards, > > Ronie > > <Captura de pantalla 2017-02-23 a las 10.00.45 p.m..png> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Feb. 27, 2017

Re: [Pharo-dev] Raw pane on byteStrings

by Andrei Chis

Hi Thierry, On Mon, Feb 27, 2017 at 12:15 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > Hi Andrei, > > Le 26/02/2017 Ã 23:48, Andrei Chis a Ã©crit : > >> Hi Thierry, >> >> Thanks for the measurements. Things are more clear now :) >> >> On Fri, Feb 24, 2017 at 11:52 PM, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Hi Andrei, >> >> Le 24/02/2017 Ã 17:02, Andrei Chis a Ã©crit : >> >> 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" >> >> >> Yes, this is expected. I'm not comparing to the standard >> EyeInspector, but with my experiments with a FastTable-derived >> widget and the EyeInspector model. GTInspector is a lot faster than >> the normal EyeInspector. >> >> As default (the only one displaying 100k elements is the AltInspector) >> >> | array | >> array := (1 to: 1000000) asArray. >> [AltInspector inspect: array ] timeToRun. "0:00:00:00.096" >> [EyeInspector inspect: array] timeToRun. "0:00:00:00.364" >> [GTInspector inspect: array] timeToRun. "0:00:00:00.065" >> >> >> Indeed this is what I expected. >> >> >> >> >> If I change indexableDisplayLimit to 50000 and remove the Items >> view >> then I get: >> >> [GTInspector inspect: array] timeToRun. "0:00:00:00.124" >> >> >> [GTInspector inspect: array] timeToRun. "0:00:00:00.256" >> >> So this time is to be compared to the "0:00:00:00.096". >> >> >> Can you just also try to remove the Items view and set >> indexableDisplayLimit to 50. >> > > In the previous times, the Item view was removed. If indexableDisplayLimit > is set at 50, then the time become: > > [GTInspector inspect: array] timeToRun. "0:00:00:00.156" > > Which is interesting in itself: multiplying the limit by 1000 (from 50 to > 50k) increase the time by a factor of ~1.6. You're right, the performance of the datasource it's actually quite good. > > > I think there is some small performance degradation in the current tree >> data source used by Glamour but I'm not 100% sure. >> > > It looks pretty efficient to me. There isn't much increase in times. > > I looked at the scaling in my experiment: the lower bound in opening the > inspector is reached for a 100k elements array. Anything smaller > has the same time (~80ms). The 1000k array increase that by ~15/20ms. I still think ~150ms to just open the Raw view is a bit too much, but for the moment it should be fine. > > > I'm really interested in seeing what makes GTInspector slower on >> your >> machine. Did you do other optimizations to SpecInspector? >> >> >> The optimisations are: >> - remove Spec (revert to a pure morphic application), >> - use a FastTable-derived widget for a tree view (with a 100k >> element limit), >> - have the GT views as subitems in the widget. >> >> >> Nice. Would be also interesting to see if in the future we can merge >> more the models used by GTInspector and EyeInspector. >> > > Could be. I just used them out of convenience, and I needed an inspector > with the ability to view large trees. > > For now, for the Raw view I set the limit to 5000 elements. This seems >> fast/large enough and it allows to add the automatic refresh back to the >> Raw view. >> > > I wonder if it wouldn't be possible to tune the automatic refresh. > Increase the time interval if it takes to long (for example when refreshing > a set with 1M elements). But 5000 elements is already a good limit. > Tuning the refresh rate could definitely be a possibility. For now I set it to 1.5 seconds. Cheers, Andrei > > Regards, > > Thierry > > Cheers, >> Andrei >> >> >> >> >> I'm using a MacBook Pro Retina - 2.8 GHz Intel Core i7 >> >> >> Back on a Acer Chromebook C720p 1.4GHz Intel Celeron, with vmLatest. >> >> 5.0-201702231204 Thu Feb 23 12:36:20 UTC 2017 gcc 4.6.3 [Production >> Spur ITHB VM] >> CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: >> 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 23 2017 >> StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 >> uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 23 2017 >> VM: 201702231204 https://github.com/pharo-project/pharo-vm.git >> <https://github.com/pharo-project/pharo-vm.git> $ Date: Thu Feb 23 >> 13:04:59 2017 +0100 $ >> Plugins: 201702231204 https://github.com/pharo-project/pharo-vm.git >> <https://github.com/pharo-project/pharo-vm.git> $ >> Linux testing-docker-b6b0368d-4817-4638-86be-f022b8a58580 >> 4.8.12-040812-generic #201612020431 SMP Fri Dec 2 09:33:31 UTC 2016 >> i686 i686 i386 GNU/Linux >> >> >> 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 <mailto:noreply@github.com> >> <mailto:noreply@github.com <mailto:noreply@github.com>>> >> >> Cheers, >> Andrei >> >> >> On Fri, Feb 24, 2017 at 3:24 PM, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com> >> <mailto:thierry.goubier@gmail.com >> <mailto:thierry.goubier@gmail.com>>> wrote: >> >> >> >> 2017-02-24 14:29 GMT+01:00 Andrei Chis >> <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com> >> <mailto:chisvasileandrei@gmail.com >> <mailto:chisvasileandrei@gmail.com>>>: >> >> >> >> On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier >> <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com> >> <mailto:thierry.goubier@gmail.com >> <mailto:thierry.goubier@gmail.com>>> >> wrote: >> >> Hi Andrei, >> >> 2017-02-24 11:31 GMT+01:00 Andrei Chis >> <chisvasileandrei(a)gmail.com >> <mailto:chisvasileandrei@gmail.com> >> <mailto:chisvasileandrei@gmail.com >> >> <mailto:chisvasileandrei@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 >> <mailto:thierry.goubier@gmail.com> >> <mailto:thierry.goubier@gmail.com >> <mailto:thierry.goubier@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 >> <mailto:chisvasileandrei@gmail.com> >> <mailto:chisvasileandrei@gmail.com >> >> <mailto:chisvasileandrei@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 >> <mailto:stepharong@free.fr> <mailto:stepharong@free.fr >> <mailto:stepharong@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. 26, 2017

Re: [Pharo-dev] Raw pane on byteStrings

by Thierry Goubier

Hi Andrei, Le 26/02/2017 Ã 23:48, Andrei Chis a Ã©crit : > Hi Thierry, > > Thanks for the measurements. Things are more clear now :) > > On Fri, Feb 24, 2017 at 11:52 PM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Hi Andrei, > > Le 24/02/2017 Ã 17:02, Andrei Chis a Ã©crit : > > 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" > > > Yes, this is expected. I'm not comparing to the standard > EyeInspector, but with my experiments with a FastTable-derived > widget and the EyeInspector model. GTInspector is a lot faster than > the normal EyeInspector. > > As default (the only one displaying 100k elements is the AltInspector) > > | array | > array := (1 to: 1000000) asArray. > [AltInspector inspect: array ] timeToRun. "0:00:00:00.096" > [EyeInspector inspect: array] timeToRun. "0:00:00:00.364" > [GTInspector inspect: array] timeToRun. "0:00:00:00.065" > > > Indeed this is what I expected. > > > > > If I change indexableDisplayLimit to 50000 and remove the Items view > then I get: > > [GTInspector inspect: array] timeToRun. "0:00:00:00.124" > > > [GTInspector inspect: array] timeToRun. "0:00:00:00.256" > > So this time is to be compared to the "0:00:00:00.096". > > > Can you just also try to remove the Items view and set > indexableDisplayLimit to 50. In the previous times, the Item view was removed. If indexableDisplayLimit is set at 50, then the time become: [GTInspector inspect: array] timeToRun. "0:00:00:00.156" Which is interesting in itself: multiplying the limit by 1000 (from 50 to 50k) increase the time by a factor of ~1.6. > I think there is some small performance degradation in the current tree > data source used by Glamour but I'm not 100% sure. It looks pretty efficient to me. There isn't much increase in times. I looked at the scaling in my experiment: the lower bound in opening the inspector is reached for a 100k elements array. Anything smaller has the same time (~80ms). The 1000k array increase that by ~15/20ms. > I'm really interested in seeing what makes GTInspector slower on > your > machine. Did you do other optimizations to SpecInspector? > > > The optimisations are: > - remove Spec (revert to a pure morphic application), > - use a FastTable-derived widget for a tree view (with a 100k > element limit), > - have the GT views as subitems in the widget. > > > Nice. Would be also interesting to see if in the future we can merge > more the models used by GTInspector and EyeInspector. Could be. I just used them out of convenience, and I needed an inspector with the ability to view large trees. > For now, for the Raw view I set the limit to 5000 elements. This seems > fast/large enough and it allows to add the automatic refresh back to the > Raw view. I wonder if it wouldn't be possible to tune the automatic refresh. Increase the time interval if it takes to long (for example when refreshing a set with 1M elements). But 5000 elements is already a good limit. Regards, Thierry > Cheers, > Andrei > > > > > I'm using a MacBook Pro Retina - 2.8 GHz Intel Core i7 > > > Back on a Acer Chromebook C720p 1.4GHz Intel Celeron, with vmLatest. > > 5.0-201702231204 Thu Feb 23 12:36:20 UTC 2017 gcc 4.6.3 [Production > Spur ITHB VM] > CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: > 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 23 2017 > StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 > uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 23 2017 > VM: 201702231204 https://github.com/pharo-project/pharo-vm.git > <https://github.com/pharo-project/pharo-vm.git> $ Date: Thu Feb 23 > 13:04:59 2017 +0100 $ > Plugins: 201702231204 https://github.com/pharo-project/pharo-vm.git > <https://github.com/pharo-project/pharo-vm.git> $ > Linux testing-docker-b6b0368d-4817-4638-86be-f022b8a58580 > 4.8.12-040812-generic #201612020431 SMP Fri Dec 2 09:33:31 UTC 2016 > i686 i686 i386 GNU/Linux > > > 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 <mailto:noreply@github.com> > <mailto:noreply@github.com <mailto:noreply@github.com>>> > > Cheers, > Andrei > > > On Fri, Feb 24, 2017 at 3:24 PM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com> > <mailto:thierry.goubier@gmail.com > <mailto:thierry.goubier@gmail.com>>> wrote: > > > > 2017-02-24 14:29 GMT+01:00 Andrei Chis > <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com> > <mailto:chisvasileandrei@gmail.com > <mailto:chisvasileandrei@gmail.com>>>: > > > > On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier > <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com> > <mailto:thierry.goubier@gmail.com > <mailto:thierry.goubier@gmail.com>>> > wrote: > > Hi Andrei, > > 2017-02-24 11:31 GMT+01:00 Andrei Chis > <chisvasileandrei(a)gmail.com > <mailto:chisvasileandrei@gmail.com> > <mailto:chisvasileandrei@gmail.com > <mailto:chisvasileandrei@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 > <mailto:thierry.goubier@gmail.com> > <mailto:thierry.goubier@gmail.com > <mailto:thierry.goubier@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 > <mailto:chisvasileandrei@gmail.com> > <mailto:chisvasileandrei@gmail.com > <mailto:chisvasileandrei@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 > <mailto:stepharong@free.fr> <mailto:stepharong@free.fr > <mailto:stepharong@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. 26, 2017

Re: [Pharo-dev] Raw pane on byteStrings

by Andrei Chis

Hi Thierry, On Fri, Feb 24, 2017 at 3:49 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 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. > For this particular case there is no special lazy data source. It's just the default table data source from Glamour. In works in this particular case because for a SequenceableCollection we currently have no wrapping of elements, so we can just extract them directly. Will be worth looking for a lazy data source for a remote inspector but not for Pharo 6. Cheers, Andrei > > Thierry > > > > >

Feb. 26, 2017

Re: [Pharo-dev] Raw pane on byteStrings

by Andrei Chis

Hi Thierry, Thanks for the measurements. Things are more clear now :) On Fri, Feb 24, 2017 at 11:52 PM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > Hi Andrei, > > Le 24/02/2017 Ã 17:02, Andrei Chis a Ã©crit : > >> 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" >> > > Yes, this is expected. I'm not comparing to the standard EyeInspector, but > with my experiments with a FastTable-derived widget and the EyeInspector > model. GTInspector is a lot faster than the normal EyeInspector. > > As default (the only one displaying 100k elements is the AltInspector) > > | array | > array := (1 to: 1000000) asArray. > [AltInspector inspect: array ] timeToRun. "0:00:00:00.096" > [EyeInspector inspect: array] timeToRun. "0:00:00:00.364" > [GTInspector inspect: array] timeToRun. "0:00:00:00.065" Indeed this is what I expected. > > > If I change indexableDisplayLimit to 50000 and remove the Items view >> then I get: >> >> [GTInspector inspect: array] timeToRun. "0:00:00:00.124" >> > > [GTInspector inspect: array] timeToRun. "0:00:00:00.256" > > So this time is to be compared to the "0:00:00:00.096". Can you just also try to remove the Items view and set indexableDisplayLimit to 50. I think there is some small performance degradation in the current tree data source used by Glamour but I'm not 100% sure. > > I'm really interested in seeing what makes GTInspector slower on your >> machine. Did you do other optimizations to SpecInspector? >> > > The optimisations are: > - remove Spec (revert to a pure morphic application), > - use a FastTable-derived widget for a tree view (with a 100k element > limit), > - have the GT views as subitems in the widget. Nice. Would be also interesting to see if in the future we can merge more the models used by GTInspector and EyeInspector. For now, for the Raw view I set the limit to 5000 elements. This seems fast/large enough and it allows to add the automatic refresh back to the Raw view. Cheers, Andrei > > > I'm using a MacBook Pro Retina - 2.8 GHz Intel Core i7 >> > > Back on a Acer Chromebook C720p 1.4GHz Intel Celeron, with vmLatest. > > 5.0-201702231204 Thu Feb 23 12:36:20 UTC 2017 gcc 4.6.3 [Production Spur > ITHB VM] > CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: > 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 23 2017 > StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: > 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 23 2017 > VM: 201702231204 https://github.com/pharo-project/pharo-vm.git $ Date: > Thu Feb 23 13:04:59 2017 +0100 $ > Plugins: 201702231204 https://github.com/pharo-project/pharo-vm.git $ > Linux testing-docker-b6b0368d-4817-4638-86be-f022b8a58580 > 4.8.12-040812-generic #201612020431 SMP Fri Dec 2 09:33:31 UTC 2016 i686 > i686 i386 GNU/Linux > > > 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 <mailto:noreply@github.com>> >> >> Cheers, >> Andrei >> >> >> On Fri, Feb 24, 2017 at 3:24 PM, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> >> >> 2017-02-24 14:29 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com >> <mailto:chisvasileandrei@gmail.com>>: >> >> >> >> On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> >> wrote: >> >> Hi Andrei, >> >> 2017-02-24 11:31 GMT+01:00 Andrei Chis >> <chisvasileandrei(a)gmail.com >> <mailto:chisvasileandrei@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 >> <mailto:thierry.goubier@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 >> <mailto:chisvasileandrei@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 <mailto:stepharong@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. 26, 2017

Re: [Pharo-dev] Why do we have doublequoting for "?

by stepharong

I hate my mail client.... Apparently I wrote email to explain what I finally understood and it never sent it nor archive it :( So I will try to summarize it and take some time tomorrow to reexplain it. Now I understand why I got confused printit is currently a function from objects -> literals (this handles the self-evaluating objects) + (and this is unfortunate non literals such as string objects by opposition to literal strings) It means that there ares case where we can have object -> a string object (and not a literal) in that case we use the string object as a mediocre "reference" to the object. If we would have printgraphics we would have objects -> graphics and unknow objects would be represented by a little blue square and clicking on it would bring and object representation (inspectors or whatever) Now how to we improve the situation. I have the impression that it would be good to have instead of printOn: which is used to do too many things. - first printOn: should not be used for list/combo or any widgets (this will avoid some friends I know to get interfaces with ' inside their comboxchoice) but to use displayString - second I would introduce asLiteralOn: which garantee that you cannot escape this way printIt will only prints strings as literal strings and the contract is clear. objects -> literals (this handles the self-evaluating objects) 1 >>> 1 false >>> false but (Directory name: 'comics') >>> 'comics' { 1 . Browser new} >>> 'anArray with (1, a Browser') now we can ask ourselves if { (Directory name: 'comics') } >>> { 'comics' } I do not like it or >>> 'anArray with ( comics ) back to my confusion: I was confused about the fact that I was hijacking the textual representation 'comics' is not a directory but a string now may be I should have return a storeOn: representation or 'aDirectory (comics)' and introduce displayString 'comics' Probably that printOn: should not be used the way I did it. but I do not know. I think that this is a subtle domain and we should provide better guidelines. Do you understand my points? What do you think? Stef

Feb. 26, 2017

Re: [Pharo-dev] Why do we have doublequoting for "?

by Tudor Girba

Hi, > On Feb 26, 2017, at 10:42 PM, stepharong <stepharong(a)free.fr> wrote: > > > >> Hi Stef, >> >> I think you are saying that having the possibility of embedding the printout as a comment is useless. But, there were people that wanted exactly that behavior without breaking the syntax highlighting. Esteban was one of them, for example. >> >> And now we have Cmd+p,Cmd+p which does exactly what the old Cmd+p did. > > I was hacking on citezen in Pharo 50. > Now I have the impression that printIt is bogus. Its semantics is a hack and it feels like > it each time you get to the limit. > We would have the same bgus behavior if we would have printAsGraphicsRepresentation. > Now we overuse textual representation and breaks the underlying repl. I agree that we overuse textual representation. For a long time we were conditioned by the fact that the editor was the central piece and that it only supported text. We will soon not have that limitation though. Letâs see what we can make of it. > Now what I see is that I have to edit by hand long boring stupid XML because I cannot use printIt to get > a textual representation that is not trying to be too smart and failing on me. > Look for my remark on asLiteralOn: I am still looking for it, but I did not find it yet :). Doru > Ste > > >> What is missing? >> >> Doru >> >> >>> On Feb 26, 2017, at 10:33 PM, stepharong <stepharong(a)free.fr> wrote: >>> >>> To me it looks wrong and it breaks flow. The poor guys working on XML should just suicide with such >>> behavior. You can never print anything decently. >>> I think that the tools are hijacking printString and turn it into something mega strange and bogus. >>> I cannot even use plain Pharo code to survive. >>> copyReplaceAll: '""' byt: '"' >>> >>> Stef >>> >>>> Hi Stef, >>>> >>>> Just a clarification. >>>> >>>> The mechanism you mention is obtained through Cmd+p, Enter and this embeds the printout as a comment in the existing editor. This is particularly useful when you want to keep a trace of multiple executions in the same editor (typically a Playground). In order to make any string a valid Pharo comment we use String>>asComment, and this escapes â (double-quote) inside a comment. Without it, the result would not be a valid comment and the syntax highlighting would be broken. >>>> >>>> For your goal of having the result in the debugger this is obviously not ideal. This is why we ended up with Cmd+p,Cmd+p, but this is not available in Pharo 5. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>> On Feb 24, 2017, at 8:30 AM, stepharong <stepharong(a)free.fr> wrote: >>>>> >>>>> Yuriy >>>>> >>>>> >>>>> Why does it make sense to have "" "" inside strings? >>>>> >>>>> >>>>> So if you paste this as a comment somewhere you donât have to manually add double double-quotes. >>>>> >>>>> Did you read my example? >>>>> I do not need any double double quotes. >>>>> >>>>> >>>>> I donât use the result of print it at all, but I guess there are two scenarios for itâs usage. One as you described: copy the result and use it in tests or in some further computation. >>>>> >>>>> But this is exactly what I cannot do with this stupid doubling of double quotes >>>>> >>>>> (but if you use TDD test are already written ;P). >>>>> >>>>> well... >>>>> >>>>> Another one is to copy the result and paste it somewhere as a comment in your code, to access it easily afterwards. If you have a double quote in your result it will break the comment, so the thing is escaped automatically. >>>>> >>>>> Probably but here this is inside a string. >>>>> I think that this heuristic is totally bogus. >>>>> >>>>> >>>>> Uko >>>>> >>>>>> On 23 Feb 2017, at 22:25, stepharong <stepharong(a)free.fr> wrote: >>>>>> >>>>>> Thnkas gabriel >>>>>> I'm hacking in an old Pharo 50 image and it was terrible because printit even a copyReplaceAll: '""' byt: '"' >>>>>> did not work. >>>>>> I do not understand what is the scenario to double quote comment character " >>>>>> >>>>>> I understand single quotes but not double quotes. >>>>>> stef >>>>>> >>>>>> Try doing Ctrl+P twice. It will not comment the printed string. >>>>>> >>>>>> On Thu, Feb 23, 2017 at 4:17 PM, stepharong <stepharong(a)free.fr> wrote: >>>>>> about quoting ;( >>>>>> >>>>>> Hi >>>>>> >>>>>> I have a string >>>>>> >>>>>> '<li> >>>>>> Stéphane Ducasse and Damien Pollet, Fingerprints, Journal of Information System, 2010. >>>>>> </li> >>>>>> ' >>>>>> >>>>>> and when I do printIt in the debugger I get the following >>>>>> >>>>>> >>>>>> "'<li> >>>>>> Stéphane Ducasse and Damien Pollet, Fingerprints, Journal of Information System, 2010. >>>>>> </li> >>>>>> '" >>>>>> >>>>>> I do not get why we doublequote the character " >>>>>> inside string. >>>>>> >>>>>> It means that I have to remove all the " inside to string to be able to express tests. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Using Opera's mail client: http://www.opera.com/mail/ >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Using Opera's mail client: http://www.opera.com/mail/ >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Innovation comes in the least expected form. >>>> That is, if it is expected, it already happened." >>>> >>>> >>> >>> >>> -- >>> Using Opera's mail client: http://www.opera.com/mail/ >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Every now and then stop and ask yourself if the war you're fighting is the right one." >> >> >> >> > > > -- > Using Opera's mail client: http://www.opera.com/mail/ -- www.tudorgirba.com www.feenk.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Feb. 26, 2017

Re: [Pharo-dev] Why do we have doublequoting for "?

by stepharong

> Hi Stef, > > I think you are saying that having the possibility of embedding the > printout as a comment is useless. But, there were people that wanted > exactly that behavior without breaking the syntax highlighting. Esteban > was one of them, for example. > > And now we have Cmd+p,Cmd+p which does exactly what the old Cmd+p did. I was hacking on citezen in Pharo 50. Now I have the impression that printIt is bogus. Its semantics is a hack and it feels like it each time you get to the limit. We would have the same bgus behavior if we would have printAsGraphicsRepresentation. Now we overuse textual representation and breaks the underlying repl. Now what I see is that I have to edit by hand long boring stupid XML because I cannot use printIt to get a textual representation that is not trying to be too smart and failing on me. Look for my remark on asLiteralOn: Ste > What is missing? > > Doru > > >> On Feb 26, 2017, at 10:33 PM, stepharong <stepharong(a)free.fr> wrote: >> >> To me it looks wrong and it breaks flow. The poor guys working on XML >> should just suicide with such >> behavior. You can never print anything decently. >> I think that the tools are hijacking printString and turn it into >> something mega strange and bogus. >> I cannot even use plain Pharo code to survive. >> copyReplaceAll: '""' byt: '"' >> >> Stef >> >>> Hi Stef, >>> >>> Just a clarification. >>> >>> The mechanism you mention is obtained through Cmd+p, Enter and this >>> embeds the printout as a comment in the existing editor. This is >>> particularly useful when you want to keep a trace of multiple >>> executions in the same editor (typically a Playground). In order to >>> make any string a valid Pharo comment we use String>>asComment, and >>> this escapes â (double-quote) inside a comment. Without it, the result >>> would not be a valid comment and the syntax highlighting would be >>> broken. >>> >>> For your goal of having the result in the debugger this is obviously >>> not ideal. This is why we ended up with Cmd+p,Cmd+p, but this is not >>> available in Pharo 5. >>> >>> Cheers, >>> Doru >>> >>> >>>> On Feb 24, 2017, at 8:30 AM, stepharong <stepharong(a)free.fr> wrote: >>>> >>>> Yuriy >>>> >>>> >>>> Why does it make sense to have "" "" inside strings? >>>> >>>> >>>> So if you paste this as a comment somewhere you donât have to >>>> manually add double double-quotes. >>>> >>>> Did you read my example? >>>> I do not need any double double quotes. >>>> >>>> >>>> I donât use the result of print it at all, but I guess there are two >>>> scenarios for itâs usage. One as you described: copy the result and >>>> use it in tests or in some further computation. >>>> >>>> But this is exactly what I cannot do with this stupid doubling of >>>> double quotes >>>> >>>> (but if you use TDD test are already written ;P). >>>> >>>> well... >>>> >>>> Another one is to copy the result and paste it somewhere as a comment >>>> in your code, to access it easily afterwards. If you have a double >>>> quote in your result it will break the comment, so the thing is >>>> escaped automatically. >>>> >>>> Probably but here this is inside a string. >>>> I think that this heuristic is totally bogus. >>>> >>>> >>>> Uko >>>> >>>>> On 23 Feb 2017, at 22:25, stepharong <stepharong(a)free.fr> wrote: >>>>> >>>>> Thnkas gabriel >>>>> I'm hacking in an old Pharo 50 image and it was terrible because >>>>> printit even a copyReplaceAll: '""' byt: '"' >>>>> did not work. >>>>> I do not understand what is the scenario to double quote comment >>>>> character " >>>>> >>>>> I understand single quotes but not double quotes. >>>>> stef >>>>> >>>>> Try doing Ctrl+P twice. It will not comment the printed string. >>>>> >>>>> On Thu, Feb 23, 2017 at 4:17 PM, stepharong <stepharong(a)free.fr> >>>>> wrote: >>>>> about quoting ;( >>>>> >>>>> Hi >>>>> >>>>> I have a string >>>>> >>>>> '<li> >>>>> Stéphane Ducasse and Damien >>>>> Pollet, Fingerprints, >>>> class="journal">Journal of Information System, >>>> class="year">2010. >>>>> </li> >>>>> ' >>>>> >>>>> and when I do printIt in the debugger I get the following >>>>> >>>>> >>>>> "'<li> >>>>> Stéphane Ducasse and Damien >>>>> Pollet, Fingerprints, >>>> class=""journal"">Journal of Information System, >>>> class=""year"">2010. >>>>> </li> >>>>> '" >>>>> >>>>> I do not get why we doublequote the character " >>>>> inside string. >>>>> >>>>> It means that I have to remove all the " inside to string to be able >>>>> to express tests. >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Using Opera's mail client: http://www.opera.com/mail/ >>>> >>>> >>>> >>>> >>>> -- >>>> Using Opera's mail client: http://www.opera.com/mail/ >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Innovation comes in the least expected form. >>> That is, if it is expected, it already happened." >>> >>> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ > > -- > www.tudorgirba.com > www.feenk.com > > "Every now and then stop and ask yourself if the war you're fighting is > the right one." > > > > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 26, 2017

Re: [Pharo-dev] Why do we have doublequoting for "?

by Tudor Girba

Hi Stef, I think you are saying that having the possibility of embedding the printout as a comment is useless. But, there were people that wanted exactly that behavior without breaking the syntax highlighting. Esteban was one of them, for example. And now we have Cmd+p,Cmd+p which does exactly what the old Cmd+p did. What is missing? Doru > On Feb 26, 2017, at 10:33 PM, stepharong <stepharong(a)free.fr> wrote: > > To me it looks wrong and it breaks flow. The poor guys working on XML should just suicide with such > behavior. You can never print anything decently. > I think that the tools are hijacking printString and turn it into something mega strange and bogus. > I cannot even use plain Pharo code to survive. > copyReplaceAll: '""' byt: '"' > > Stef > >> Hi Stef, >> >> Just a clarification. >> >> The mechanism you mention is obtained through Cmd+p, Enter and this embeds the printout as a comment in the existing editor. This is particularly useful when you want to keep a trace of multiple executions in the same editor (typically a Playground). In order to make any string a valid Pharo comment we use String>>asComment, and this escapes â (double-quote) inside a comment. Without it, the result would not be a valid comment and the syntax highlighting would be broken. >> >> For your goal of having the result in the debugger this is obviously not ideal. This is why we ended up with Cmd+p,Cmd+p, but this is not available in Pharo 5. >> >> Cheers, >> Doru >> >> >>> On Feb 24, 2017, at 8:30 AM, stepharong <stepharong(a)free.fr> wrote: >>> >>> Yuriy >>> >>> >>> Why does it make sense to have "" "" inside strings? >>> >>> >>> So if you paste this as a comment somewhere you donât have to manually add double double-quotes. >>> >>> Did you read my example? >>> I do not need any double double quotes. >>> >>> >>> I donât use the result of print it at all, but I guess there are two scenarios for itâs usage. One as you described: copy the result and use it in tests or in some further computation. >>> >>> But this is exactly what I cannot do with this stupid doubling of double quotes >>> >>> (but if you use TDD test are already written ;P). >>> >>> well... >>> >>> Another one is to copy the result and paste it somewhere as a comment in your code, to access it easily afterwards. If you have a double quote in your result it will break the comment, so the thing is escaped automatically. >>> >>> Probably but here this is inside a string. >>> I think that this heuristic is totally bogus. >>> >>> >>> Uko >>> >>>> On 23 Feb 2017, at 22:25, stepharong <stepharong(a)free.fr> wrote: >>>> >>>> Thnkas gabriel >>>> I'm hacking in an old Pharo 50 image and it was terrible because printit even a copyReplaceAll: '""' byt: '"' >>>> did not work. >>>> I do not understand what is the scenario to double quote comment character " >>>> >>>> I understand single quotes but not double quotes. >>>> stef >>>> >>>> Try doing Ctrl+P twice. It will not comment the printed string. >>>> >>>> On Thu, Feb 23, 2017 at 4:17 PM, stepharong <stepharong(a)free.fr> wrote: >>>> about quoting ;( >>>> >>>> Hi >>>> >>>> I have a string >>>> >>>> '<li> >>>> Stéphane Ducasse and Damien Pollet, Fingerprints, Journal of Information System, 2010. >>>> </li> >>>> ' >>>> >>>> and when I do printIt in the debugger I get the following >>>> >>>> >>>> "'<li> >>>> Stéphane Ducasse and Damien Pollet, Fingerprints, Journal of Information System, 2010. >>>> </li> >>>> '" >>>> >>>> I do not get why we doublequote the character " >>>> inside string. >>>> >>>> It means that I have to remove all the " inside to string to be able to express tests. >>>> >>>> Stef >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Using Opera's mail client: http://www.opera.com/mail/ >>> >>> >>> >>> >>> -- >>> Using Opera's mail client: http://www.opera.com/mail/ >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Innovation comes in the least expected form. >> That is, if it is expected, it already happened." >> >> > > > -- > Using Opera's mail client: http://www.opera.com/mail/ -- www.tudorgirba.com www.feenk.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

Feb. 26, 2017

Re: [Pharo-dev] Why do we have doublequoting for "?

by stepharong

To me it looks wrong and it breaks flow. The poor guys working on XML should just suicide with such behavior. You can never print anything decently. I think that the tools are hijacking printString and turn it into something mega strange and bogus. I cannot even use plain Pharo code to survive. copyReplaceAll: '""' byt: '"' Stef > Hi Stef, > > Just a clarification. > > The mechanism you mention is obtained through Cmd+p, Enter and this > embeds the printout as a comment in the existing editor. This is > particularly useful when you want to keep a trace of multiple executions > in the same editor (typically a Playground). In order to make any string > a valid Pharo comment we use String>>asComment, and this escapes â > (double-quote) inside a comment. Without it, the result would not be a > valid comment and the syntax highlighting would be broken. > > For your goal of having the result in the debugger this is obviously not > ideal. This is why we ended up with Cmd+p,Cmd+p, but this is not > available in Pharo 5. > > Cheers, > Doru > > >> On Feb 24, 2017, at 8:30 AM, stepharong <stepharong(a)free.fr> wrote: >> >> Yuriy >> >> >> Why does it make sense to have "" "" inside strings? >> >> >> So if you paste this as a comment somewhere you donât have to manually >> add double double-quotes. >> >> Did you read my example? >> I do not need any double double quotes. >> >> >> I donât use the result of print it at all, but I guess there are two >> scenarios for itâs usage. One as you described: copy the result and use >> it in tests or in some further computation. >> >> But this is exactly what I cannot do with this stupid doubling of >> double quotes >> >> (but if you use TDD test are already written ;P). >> >> well... >> >> Another one is to copy the result and paste it somewhere as a comment >> in your code, to access it easily afterwards. If you have a double >> quote in your result it will break the comment, so the thing is escaped >> automatically. >> >> Probably but here this is inside a string. >> I think that this heuristic is totally bogus. >> >> >> Uko >> >>> On 23 Feb 2017, at 22:25, stepharong <stepharong(a)free.fr> wrote: >>> >>> Thnkas gabriel >>> I'm hacking in an old Pharo 50 image and it was terrible because >>> printit even a copyReplaceAll: '""' byt: '"' >>> did not work. >>> I do not understand what is the scenario to double quote comment >>> character " >>> >>> I understand single quotes but not double quotes. >>> stef >>> >>> Try doing Ctrl+P twice. It will not comment the printed string. >>> >>> On Thu, Feb 23, 2017 at 4:17 PM, stepharong <stepharong(a)free.fr> wrote: >>> about quoting ;( >>> >>> Hi >>> >>> I have a string >>> >>> '<li> >>> Stéphane Ducasse and Damien Pollet, >>> Fingerprints, Journal >>> of Information System, 2010. >>> </li> >>> ' >>> >>> and when I do printIt in the debugger I get the following >>> >>> >>> "'<li> >>> Stéphane Ducasse and Damien >>> Pollet, Fingerprints, >> class=""journal"">Journal of Information System, >> class=""year"">2010. >>> </li> >>> '" >>> >>> I do not get why we doublequote the character " >>> inside string. >>> >>> It means that I have to remove all the " inside to string to be able >>> to express tests. >>> >>> Stef >>> >>> >>> >>> >>> >>> -- >>> Using Opera's mail client: http://www.opera.com/mail/ >> >> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ > > -- > www.tudorgirba.com > www.feenk.com > > "Innovation comes in the least expected form. > That is, if it is expected, it already happened." > > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 26, 2017