- Pharo-dev - lists.pharo.org

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

by Stephane Ducasse

Super tx guille!!! On Tue, Feb 7, 2017 at 12:18 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > 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. 8, 2017

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

by Hilaire

As we are here, what are your best proposals for these buttons: Full stack Run to here Where is? Le 06/02/2017 Ã 21:25, Sean P. DeNigris a Ã©crit : > How about... -- Dr. Geo http://drgeo.eu

Feb. 7, 2017

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

by Hilaire

ok got it! Le 07/02/2017 Ã 20:49, Andrei Chis a Ã©crit : > 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. > -- Dr. Geo http://drgeo.eu

Feb. 7, 2017

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