- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [QA] Debugger buttons explained

by Andrei Chis

Seems that I made a small mistake before. DebugAction>>#asMenuRegistrationIn: is called only when creating the context menu. SpecDebuggerDynamicToolbar is the class that builds the toolbar with the step buttons. Then each button will be an instance of SpecDebugActionButton. Andrei On Tue, Feb 7, 2017 at 8:29 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Changed to the SpecDebugger in the method mentionned bellow does not > have action on newly debuggin session with SpecDebugger. This method is > not call. Any idea? > > Le 06/02/2017 Ã 21:57, Andrei Chis a Ã©crit : > > For the Spec interface of the debugger you need to adapt > > DebugAction>>#asMenuRegistrationIn: > > > > -- > Dr. Geo > http://drgeo.eu > > >

Feb. 7, 2017

Re: [Pharo-dev] [QA] Debugger buttons explained

by Hilaire

Changed to the SpecDebugger in the method mentionned bellow does not have action on newly debuggin session with SpecDebugger. This method is not call. Any idea? Le 06/02/2017 Ã 21:57, Andrei Chis a Ã©crit : > For the Spec interface of the debugger you need to adapt > DebugAction>>#asMenuRegistrationIn: > -- Dr. Geo http://drgeo.eu

Feb. 7, 2017

Re: [Pharo-dev] [QA] Debugger buttons explained

by Hilaire

Ok thanks for the tips. As labes was use as tooltip too I have to set the balloon text as bellow which is not great but should help for the transition. setBalloonText: ((anAction help ifNil: [ anAction title]) , Character tab asString , anAction shortcutAsString) trimBoth; I will look at the tips text now. Le 06/02/2017 Ã 21:57, Andrei Chis a Ã©crit : > The Glamour interface of the debugger uses DebugAction>>#asGlamourAction > to transform that into a Glamour action. This action is then rendered > in GLMMorphicActionRenderer>>#render:. > There the tooltip is set directly by concatenating the title and the > shortcut of the action. > Best solution would be to add a description attribute to DebugAction and > GLMAction and then > modify GLMMorphicActionRenderer>>#render: to use it. > For the Spec interface of the debugger you need to adapt > DebugAction>>#asMenuRegistrationIn: > -- Dr. Geo http://drgeo.eu

Feb. 7, 2017

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

by Ben Coman

cool. thx. On Tue, Feb 7, 2017 at 10:46 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > 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

Debugging "1 ifTrue: [2]" (was Re: Debugger hang when step throught)

by Ben Coman

On Tue, Feb 7, 2017 at 5:35 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Also I found another funny issue. Try debugIt following expression: > > 1 ifTrue: [2]. > > You will be wondering that debugger will not able to open. To quickly get to the point to observe the cause, you can insert... Halt if: [interruptedProcess suspendedContext receiver == nil]. into DebugSession>>stepInto: just after the send of #step. Then when you step into Context>>stepToSendOrReturn step once over "context := self step" and the second time step in until you get to Context>>jump:if: which substitutes the following context Context sender: self "=Undefined>>DoIt" receiver: rcvr "=1" method: newMethod "=Object>>#mustBeBoolean" arguments: args "=#()" such that in RubSmalltalkEditor>>debug:receiver:in: the condition block debugSession stepIntoUntil: [:currentContext | currentContext method == aCompiledMethod ] always fails, so in DebugSession>>stepIntoUntil: the #whileFalse: never exits. A possible fix (if a bit hacky) is... debugSession stepIntoUntil: [:currentContext | (currentContext method == aCompiledMethod) or: [currentContext method selector==#mustBeBoolean] ]. cheers -ben

Feb. 7, 2017

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