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

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

by Andrei Chis

Done. Cheers, Andrei On Tue, Feb 7, 2017 at 1:35 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Tue, Feb 7, 2017 at 8:00 PM, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > > > > > > On Sat, Feb 4, 2017 at 4:40 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> > >> > On Fri, Feb 3, 2017 at 3:13 AM, Ben Coman <btc(a)openinworld.com> > wrote: > >> >> > >> >> Just curious what the magic numbers here relate to... > >> >> and can they be factored out to a meaningful method name? > >> >> > >> >> Context>>gtInspectorVariableValuePairs > >> >> "This is a helper method that returns a collection of > >> >> variable_name -> value > >> >> for the current object. > >> >> Subclasses can override it to specialize what appears in the > variables > >> >> presentation" > >> >> | bindings | > >> >> bindings := OrderedCollection new. > >> >> 1 to: (self basicSize min: 21) do: [ :index | > >> >> bindings add: (index "asString""asTwoCharacterString" -> (self > basicAt: > >> >> index)) ]. > >> >> ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index | > >> >> "self > >> >> haltIf: [ index = 99 ]." > >> >> bindings add: (index "asString" -> (self basicAt: index)) ]. > >> >> bindings > >> >> addAll: ((self class allSlots > >> >> collect: [ :slot | slot name -> (slot read: self) ]) sort > >> >> asOrderedCollection). > >> >> ^ bindings > >> >> > >> >> > >> >> cheers -ben > >> > > >> > > >> > >> On Fri, Feb 3, 2017 at 11:20 PM, Andrei Chis < > chisvasileandrei(a)gmail.com> > >> wrote: > >> > Yes these numbers should be refactored > >> > For collections only the first and the last 21 elements are displayed > in > >> > the > >> > Raw view. Don't remember why 21. > >> > > >> > Cheers, > >> > Andrei > >> > > >> > >> Ahhh. Nice to know. Here I was thinking it was based on some intrinsic > >> restriction on the number of variables or something. > >> > >> I'm a fan of overusing redundant variables for documenting purposes... > >> > >> Object>>gtInspectorVariableValuePairs > >> | indexableDisplayLimit bottom topLimit bottomLimit bindings | > >> > >> indexableDisplayLimit := 21. > >> top := 1. > >> bottom := self basicSize. > >> topLimit := bottom min: indexableDisplayLimit. > >> bottomLimit := (bottom - indexableDisplayLimit) max: > indexableDisplayLimit. > >> > >> bindings := OrderedCollection new. > >> "Return top and bottom of indexable elements" > >> top to: topLimit do: [ :index | bindings add: (index -> (self basicAt: > >> index)) ]. bottomLimit + 1 to: bottom do: [ :index | bindings add: > (index -> > >> (self basicAt: index)) ]. > >> > >> "Return named variables" > >> bindings > >> addAll: ((self class allSlots > >> collect: [ :slot | slot name -> (slot read: self) ]) sort > >> asOrderedCollection). > >> ^ bindings > >> > >> If this looks reasonable I'll do up a slice. > > > > > > Looks good. I'll commit this to the inspector repo and will be picked by > the > > next integration. > > Thanks Andre. > > Very minor thing if its not too late. Looking at it again I'd actually > rearrange these two lines like this... > topLimit := indexableDisplayLimit min: bottom. > bottomLimit := indexableDisplayLimit max: (bottom - > indexableDisplayLimit) . > > But don't worry if you've already done the first way. > cheers -ben > > > > > Cheers, > > Andrei > > > >> > >> > >> Perhaps defining "top" is overkill - but it does read nice below that. > >> btw, in general I understand that some smart optimising compilers will > >> substitute 1 for "top" directly since its assigned a literal and not > >> reassigned before its use. I notice from the bytecode this doesn't > happen > >> here. Is there some intrinsic difficulty in our domain stopping this to > >> happen, or its just not been a priority. I guess while stepping > through the > >> debugger "top" a user might set a new value for "top" and reverting the > >> substitution of "1" for "top" needs the sort of facility that Sista will > >> provide?? > >> > >> > >> On Sat, Feb 4, 2017 at 12:08 AM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >>> > >>> There is very little meaning behind the number. > >>> > >>> The previous inspector showed the first 100 and the last 10 elements. > 100 > >>> is anyway too large for a quick inspection, so we picked another > number. I > >>> wanted 42 but that was still large, so we are now at 21. > >> > >> > >> Well 21 top and bottom gives you 42, and I know life, the universe and > >> everything depends on that number - so this seems reasonable. > >> > >> > >> On Sat, Feb 4, 2017 at 12:39 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> > >> wrote: > >>> > >>> They could be extracted to class vars for example TWENTY_ONE := 21. > Later > >>> if performance is still not good enough they may be changed for > example to > >>> TWENTY_ONE := 15. > >>> (joke) > >> > >> > >> You mean something like this... > >> https://xkcd.com/221/ > >> > >> > >> cheers -ben > > > > > >

Feb. 7, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60378 Home: https://github.com/pharo-project/pharo-core

Feb. 7, 2017

[pharo-project/pharo-core] 240c87: 60378

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 240c87af5240f6b8e4e8484afac580fd61c77feb https://github.com/pharo-project/pharo-core/commit/240c87af5240f6b8e4e8484a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-07 (Tue, 07 Feb 2017) Changed paths: M Nautilus.package/NautilusUI.class/instance/private dispatch/removePackageCategory_.st A RPackage-Core.package/RPackage.class/instance/removing/removeFromSystem.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60377.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60378.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60377.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60378.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60378 19664 Removing a package with extensions let the extensions in the system and break their reload https://pharo.fogbugz.com/f/cases/19664 http://files.pharo.org/image/60/60378.zip

Feb. 7, 2017

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

by Ben Coman

On Tue, Feb 7, 2017 at 8:00 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > > On Sat, Feb 4, 2017 at 4:40 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> > On Fri, Feb 3, 2017 at 3:13 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> Just curious what the magic numbers here relate to... >> >> and can they be factored out to a meaningful method name? >> >> >> >> Context>>gtInspectorVariableValuePairs >> >> "This is a helper method that returns a collection of >> >> variable_name -> value >> >> for the current object. >> >> Subclasses can override it to specialize what appears in the variables >> >> presentation" >> >> | bindings | >> >> bindings := OrderedCollection new. >> >> 1 to: (self basicSize min: 21) do: [ :index | >> >> bindings add: (index "asString""asTwoCharacterString" -> (self basicAt: >> >> index)) ]. >> >> ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index | >> >> "self >> >> haltIf: [ index = 99 ]." >> >> bindings add: (index "asString" -> (self basicAt: index)) ]. >> >> bindings >> >> addAll: ((self class allSlots >> >> collect: [ :slot | slot name -> (slot read: self) ]) sort >> >> asOrderedCollection). >> >> ^ bindings >> >> >> >> >> >> cheers -ben >> > >> > >> >> On Fri, Feb 3, 2017 at 11:20 PM, Andrei Chis <chisvasileandrei(a)gmail.com> >> wrote: >> > Yes these numbers should be refactored >> > For collections only the first and the last 21 elements are displayed in >> > the >> > Raw view. Don't remember why 21. >> > >> > Cheers, >> > Andrei >> > >> >> Ahhh. Nice to know. Here I was thinking it was based on some intrinsic >> restriction on the number of variables or something. >> >> I'm a fan of overusing redundant variables for documenting purposes... >> >> Object>>gtInspectorVariableValuePairs >> | indexableDisplayLimit bottom topLimit bottomLimit bindings | >> >> indexableDisplayLimit := 21. >> top := 1. >> bottom := self basicSize. >> topLimit := bottom min: indexableDisplayLimit. >> bottomLimit := (bottom - indexableDisplayLimit) max: indexableDisplayLimit. >> >> bindings := OrderedCollection new. >> "Return top and bottom of indexable elements" >> top to: topLimit do: [ :index | bindings add: (index -> (self basicAt: >> index)) ]. bottomLimit + 1 to: bottom do: [ :index | bindings add: (index -> >> (self basicAt: index)) ]. >> >> "Return named variables" >> bindings >> addAll: ((self class allSlots >> collect: [ :slot | slot name -> (slot read: self) ]) sort >> asOrderedCollection). >> ^ bindings >> >> If this looks reasonable I'll do up a slice. > > > Looks good. I'll commit this to the inspector repo and will be picked by the > next integration. Thanks Andre. Very minor thing if its not too late. Looking at it again I'd actually rearrange these two lines like this... topLimit := indexableDisplayLimit min: bottom. bottomLimit := indexableDisplayLimit max: (bottom - indexableDisplayLimit) . But don't worry if you've already done the first way. cheers -ben > > Cheers, > Andrei > >> >> >> Perhaps defining "top" is overkill - but it does read nice below that. >> btw, in general I understand that some smart optimising compilers will >> substitute 1 for "top" directly since its assigned a literal and not >> reassigned before its use. I notice from the bytecode this doesn't happen >> here. Is there some intrinsic difficulty in our domain stopping this to >> happen, or its just not been a priority. I guess while stepping through the >> debugger "top" a user might set a new value for "top" and reverting the >> substitution of "1" for "top" needs the sort of facility that Sista will >> provide?? >> >> >> On Sat, Feb 4, 2017 at 12:08 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> There is very little meaning behind the number. >>> >>> The previous inspector showed the first 100 and the last 10 elements. 100 >>> is anyway too large for a quick inspection, so we picked another number. I >>> wanted 42 but that was still large, so we are now at 21. >> >> >> Well 21 top and bottom gives you 42, and I know life, the universe and >> everything depends on that number - so this seems reasonable. >> >> >> On Sat, Feb 4, 2017 at 12:39 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> >> wrote: >>> >>> They could be extracted to class vars for example TWENTY_ONE := 21. Later >>> if performance is still not good enough they may be changed for example to >>> TWENTY_ONE := 15. >>> (joke) >> >> >> You mean something like this... >> https://xkcd.com/221/ >> >> >> cheers -ben > >

Feb. 7, 2017

Re: [Pharo-dev] Debugger hang when step throught

by phil＠highoctane.be

I regularly got hit by this kind of lockup. Do not know exactly why it locks up but then it is "kill pharo" "recover changes" and "change sorter" fun session... Got one an hour ago, drives me up the wall. It is one of the reasons that made me add the Save with Timetag feature. [image: Inline image 1] Will be nicer when the image compaction will work because this makes me a couple of huge files (space is cheap, but the size seems to affect autocompletion speed for some reason). Phil On Tue, Feb 7, 2017 at 10:35 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-02-07 10:30 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> More simple way to reproduce: >> >> #(2) select: [:i| i] >> >> >> Problem somehow related to mustBeBoolean error. If you try debug >> >> #(2) select: [:i| i / 0] >> >> >> Debugger will fallback into #/ method at ZeroDivide statement. But with >> mustBeBoolean trick it's not work. >> > > I open issue 19662 > <https://pharo.fogbugz.com/f/cases/19662/Debugger-step-through-mustBeBoolean…> > . > > Also I found another funny issue. Try debugIt following expression: > > 1 ifTrue: [2]. > > You will be wondering that debugger will not able to open. > >

Feb. 7, 2017

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

by Andrei Chis

On Sat, Feb 4, 2017 at 4:40 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Fri, Feb 3, 2017 at 3:13 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> Just curious what the magic numbers here relate to... > >> and can they be factored out to a meaningful method name? > >> > >> Context>>gtInspectorVariableValuePairs > >> "This is a helper method that returns a collection of > >> variable_name -> value > >> for the current object. > >> Subclasses can override it to specialize what appears in the variables > >> presentation" > >> | bindings | > >> bindings := OrderedCollection new. > >> 1 to: (self basicSize min: 21) do: [ :index | > >> bindings add: (index "asString""asTwoCharacterString" -> (self basicAt: > >> index)) ]. > >> ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index | > "self > >> haltIf: [ index = 99 ]." > >> bindings add: (index "asString" -> (self basicAt: index)) ]. > >> bindings > >> addAll: ((self class allSlots > >> collect: [ :slot | slot name -> (slot read: self) ]) sort > >> asOrderedCollection). > >> ^ bindings > >> > >> > >> cheers -ben > > > > > > On Fri, Feb 3, 2017 at 11:20 PM, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > > Yes these numbers should be refactored > > For collections only the first and the last 21 elements are displayed in > the > > Raw view. Don't remember why 21. > > > > Cheers, > > Andrei > > > > Ahhh. Nice to know. Here I was thinking it was based on some intrinsic > restriction on the number of variables or something. > > I'm a fan of overusing redundant variables for documenting purposes... > > Object>>gtInspectorVariableValuePairs > | indexableDisplayLimit bottom topLimit bottomLimit bindings | > > indexableDisplayLimit := 21. > top := 1. > bottom := self basicSize. > topLimit := bottom min: indexableDisplayLimit. > bottomLimit := (bottom - indexableDisplayLimit) max: indexableDisplayLimit. > > bindings := OrderedCollection new. > "Return top and bottom of indexable elements" > top to: topLimit do: [ :index | bindings add: (index -> (self basicAt: > index)) ]. bottomLimit + 1 to: bottom do: [ :index | bindings add: (index > -> (self basicAt: index)) ]. > > "Return named variables" > bindings > addAll: ((self class allSlots > collect: [ :slot | slot name -> (slot read: self) ]) sort > asOrderedCollection). > ^ bindings > > If this looks reasonable I'll do up a slice. > Looks good. I'll commit this to the inspector repo and will be picked by the next integration. Cheers, Andrei > > Perhaps defining "top" is overkill - but it does read nice below that. > btw, in general I understand that some smart optimising compilers will > substitute 1 for "top" directly since its assigned a literal and not > reassigned before its use. I notice from the bytecode this doesn't happen > here. Is there some intrinsic difficulty in our domain stopping this to > happen, or its just not been a priority. I guess while stepping through > the debugger "top" a user might set a new value for "top" and reverting the > substitution of "1" for "top" needs the sort of facility that Sista will > provide?? > > > On Sat, Feb 4, 2017 at 12:08 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> There is very little meaning behind the number. >> >> The previous inspector showed the first 100 and the last 10 elements. 100 >> is anyway too large for a quick inspection, so we picked another number. I >> wanted 42 but that was still large, so we are now at 21. > > > Well 21 top and bottom gives you 42, and I know life, the universe and > everything depends on that number - so this seems reasonable. > > > On Sat, Feb 4, 2017 at 12:39 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: > >> They could be extracted to class vars for example TWENTY_ONE := 21. Later >> if performance is still not good enough they may be changed for example to >> TWENTY_ONE := 15. >> (joke) >> > > You mean something like this... > https://xkcd.com/221/ > > > cheers -ben >

Feb. 7, 2017

Re: [Pharo-dev] Pharo 60 needs help because Removing-a-package-with-extensions-let-the-extensions-in-the-system-and-break-their-reload

by Guillermo Polito

I proposed a slice in the inbox for this. - added RPackage>>removeFromSystem - this version removes defined classes and also extension methods defined in the package. - make Nautilus ask the RPackage to remove itself (instead of doing it in the UI) I tested it with the fileout of a package with extension methods, removing the package and filing it in again. On Tue, Feb 7, 2017 at 11:41 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > https://pharo.fogbugz.com/f/cases/19664/Removing-a- > package-with-extensions-let-the-extensions-in-the-system- > and-break-their-reload >

Feb. 7, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60377 Home: https://github.com/pharo-project/pharo-core

Feb. 7, 2017

[pharo-project/pharo-core] ab7ee8: 60377

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: ab7ee87bf0bba53324987797b37402d486688cca https://github.com/pharo-project/pharo-core/commit/ab7ee87bf0bba53324987797… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-07 (Tue, 07 Feb 2017) Changed paths: M Polymorph-Widgets.package/Pharo3Theme.class/instance/fill-styles-buttons/buttonSelectedFillStyleFor_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60376.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60377.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60376.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60377.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A WriteBarrierTests.package/WriteBarrierStub.class/README.md A WriteBarrierTests.package/WriteBarrierStub.class/definition.st A WriteBarrierTests.package/WriteBarrierStub.class/instance/accessing/var1.st A WriteBarrierTests.package/WriteBarrierStub.class/instance/accessing/var10.st A WriteBarrierTests.package/WriteBarrierStub.class/instance/accessing/var10_.st A WriteBarrierTests.package/WriteBarrierStub.class/instance/accessing/var1_.st M WriteBarrierTests.package/WriteBarrierTest.class/instance/setup/expectedFailures.st A WriteBarrierTests.package/WriteBarrierTest.class/instance/tests - object/testMutateFirstInstVarOfObjectWithManyVars.st A WriteBarrierTests.package/WriteBarrierTest.class/instance/tests - object/testMutateInstVarShouldCatchRightFailure.st A WriteBarrierTests.package/WriteBarrierTest.class/instance/tests - object/testMutateLastInstVarOfObjectWithManyVars.st Log Message: ----------- 60377 19657 white theme color for button is not good https://pharo.fogbugz.com/f/cases/19657 19639 More tests for write barrier to cover that modification failure catch right parameters https://pharo.fogbugz.com/f/cases/19639 http://files.pharo.org/image/60/60377.zip

Feb. 7, 2017

Re: [Pharo-dev] Esteban's ChangeLog week of 30 January 2017

by Stephane Ducasse

I love such reports :) I like when I have smart ideas that work :) On Mon, Feb 6, 2017 at 4:54 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > EstebanLM wrote > > This is my weekly ChangeLog, from 30 January 2017 to 5 February 2017. > > Go, go, go, Esteban!!! > > > EstebanLM wrote > > the new process we are starting to create for Pharo, we need to be able > to > > do things like... > > Sounds great :) > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Esteban- > s-ChangeLog-week-of-30-January-2017-tp4933097p4933165.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Feb. 7, 2017