April 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Moose-dev] Re: Big thanks for the organization of the Pharo Conf and MooseDay

by Christoph Wysseier

Hi Stephan Am 05.04.13 18:44, schrieb Stephan Eggermont: >> The sessions were recorded, and once Stephan Eggermont will convert them, they will be posted. > > And for some ideas on when that will be: I just got back from Diego with 72 GB of video files. > This weekend I might find some time to proces them, but the whole week I'm at Accu2013 in Bristol. > So what's not posted on monday, will take at least a week more. > > If anyone has other material (sheets, screencasts, other video) please let me know I am also looking forward to the videos and would like to thank everyone who contributed more or less to this conference. It was really cool and inspring! The link to my Prezi "Selling Pharo-based Solutions": -> http://prezi.com/h_j_prkjjaxq/selling-pharo-based-solutions/ Cheers, Chris -- Christoph Wysseier netstyle.ch GmbH, CEO

April 6, 2013

[Pharo-project] [Preview] Branch test coverage analysis tool for Pharo 3.0 :)

by StÃ©phane Ducasse

Clement built in a couple of hours the following nice branch analysecoverage tools :) It is dead slow but cool. With the AST navigation Gisela just started to work on we will have a really cool system. Stef

April 6, 2013

Re: [Pharo-project] Issue 10219: Completion: enter on accept awkwardness

by Esteban Lorenzano

oh, I'm here too, but that's because I have insomnia, not kids :) On Apr 6, 2013, at 8:44 AM, Johan Brichau <johan(a)inceptive.be> wrote: > Indeed, I also increased the popup speed in the preferences to something like 100 or 200ms. > > But yes, you should wait for them to pop up. > I did not address any other issues than the 'completion keystroke'. > > btw, judging by the time of day, you can see who has small kids on this mailing list :-) > > On 06 Apr 2013, at 08:38, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> How can I get fast the choices? >> Because when I type >> >> printO >> >> and press tab I do not get >> >> printOn: >> but >> >> printO | >> Stef >> >> >> >>> fwiw, I changed the implementation of NECController to: >>> - accept both <enter> and <tab> for code completion >>> - still use <tab> to first complete the common prefixes, but a subsequent <tab> will select the suggestion >>> >>> i.e. this is the behavior in XCode, which imho is a very good one. >>> >>> _and_ I do not have to disable the completion of common prefixes if I want to disable <enter> for selection. >>> >>> Maybe people should give this a try and see? >>> >>> cheers >>> Johan >>> >>> >>> <NECController-Changes.cs> >>> >>> On 06 Apr 2013, at 02:18, Ben Coman <btc(a)openInWorld.com> wrote: >>> >>>> Alexandre Bergel wrote: >>>>> +1 >>>>> >>>>> Alexandre >>>>> >>>>> >>>>> On Apr 3, 2013, at 8:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>> >>>>> >>>>>> +1 >>>>>> >>>>>> Doru >>>>>> >>>>>> >>>>>> On Apr 4, 2013, at 2:19 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>> >>>>>> >>>>>>> On 3 April 2013 22:45, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>>>>> >>>>>>>> theres a setting to: >>>>>>>> >>>>>>>> - disable ENTER to accept the completion >>>>>>>> - to increase the popup delay >>>>>>>> >>>>>>>> so I think that is invalid bug report then... >>>>>>>> >>>>>>>> >>>>>>> i tend to disagree. >>>>>>> The defaults which we have now in 2.0 for autocompletion >>>>>>> is breaking my workflow badly too. >>>>>>> >>>>>>> Yes, i can go to settings and disable/reconfigure stuff but that doesn't >>>>>>> nullifying the fact, that my workflow is broken with ambiguous and inconsistent >>>>>>> reaction(s) to my keystrokes by UI if i keep defaults. >>>>>>> >>>>>>> For instance i am still clueless, why 'enter' is default for autocompletion, >>>>>>> and disabling it and enabling 'tab' simply doesn't works. >>>>>>> That leaves me with the only option: keep using 'enter' for >>>>>>> autocompletion, if i ever want to use it. >>>>>>> We have to fix that. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 2013-04-03, at 22:23, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> From >>>>>>>>> https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardn… >>>>>>>>> : >>>>>>>>> >>>>>>>>> >>>>>>>>>> The combination of enter on accept, with the current behavior to select >>>>>>>>>> the first completion suggestion by default = trouble. For example: >>>>>>>>>> >>>>>>>>>> 1. Type "printOn: aStream"... pretty common method start >>>>>>>>>> 2. Hit enter to go to the next line >>>>>>>>>> >>>>>>>>>> You will now have "printOn: MCDataStream" WTF!! I get burned by this >>>>>>>>>> pretty regularly and it's annoying. I'm not sure what the fix should be... >>>>>>>>>> probably no default selection in the suggestion menu, but possibly only >>>>>>>>>> when enter on accept is enabled (t would require an extra key press to >>>>>>>>>> complete and when do you ever type a tab in the middle of a line?) >>>>>>>>>> >>>>>>>>> >>>> I haven't used the 2.0 auto compeltion yet so I don't know if this is relevant, but just a passing thought... When Microsoft Word muck up using smart characters, one small saving grace is that it first enters my original typing before "smart-ifying" it, such that ctrl-z undoes back to my original typing. >>>> >>>> cheers -ben >>>> >>> >> >> > >

April 6, 2013

Re: [Pharo-project] Issue 10219: Completion: enter on accept awkwardness

by Johan Brichau

Indeed, I also increased the popup speed in the preferences to something like 100 or 200ms. But yes, you should wait for them to pop up. I did not address any other issues than the 'completion keystroke'. btw, judging by the time of day, you can see who has small kids on this mailing list :-) On 06 Apr 2013, at 08:38, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > How can I get fast the choices? > Because when I type > > printO > > and press tab I do not get > > printOn: > but > > printO | > Stef > > > >> fwiw, I changed the implementation of NECController to: >> - accept both <enter> and <tab> for code completion >> - still use <tab> to first complete the common prefixes, but a subsequent <tab> will select the suggestion >> >> i.e. this is the behavior in XCode, which imho is a very good one. >> >> _and_ I do not have to disable the completion of common prefixes if I want to disable <enter> for selection. >> >> Maybe people should give this a try and see? >> >> cheers >> Johan >> >> >> <NECController-Changes.cs> >> >> On 06 Apr 2013, at 02:18, Ben Coman <btc(a)openInWorld.com> wrote: >> >>> Alexandre Bergel wrote: >>>> +1 >>>> >>>> Alexandre >>>> >>>> >>>> On Apr 3, 2013, at 8:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>> >>>>> +1 >>>>> >>>>> Doru >>>>> >>>>> >>>>> On Apr 4, 2013, at 2:19 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> >>>>> >>>>>> On 3 April 2013 22:45, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>>>> >>>>>>> theres a setting to: >>>>>>> >>>>>>> - disable ENTER to accept the completion >>>>>>> - to increase the popup delay >>>>>>> >>>>>>> so I think that is invalid bug report then... >>>>>>> >>>>>>> >>>>>> i tend to disagree. >>>>>> The defaults which we have now in 2.0 for autocompletion >>>>>> is breaking my workflow badly too. >>>>>> >>>>>> Yes, i can go to settings and disable/reconfigure stuff but that doesn't >>>>>> nullifying the fact, that my workflow is broken with ambiguous and inconsistent >>>>>> reaction(s) to my keystrokes by UI if i keep defaults. >>>>>> >>>>>> For instance i am still clueless, why 'enter' is default for autocompletion, >>>>>> and disabling it and enabling 'tab' simply doesn't works. >>>>>> That leaves me with the only option: keep using 'enter' for >>>>>> autocompletion, if i ever want to use it. >>>>>> We have to fix that. >>>>>> >>>>>> >>>>>> >>>>>>> On 2013-04-03, at 22:23, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: >>>>>>> >>>>>>> >>>>>>>> From >>>>>>>> https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardn… >>>>>>>> : >>>>>>>> >>>>>>>> >>>>>>>>> The combination of enter on accept, with the current behavior to select >>>>>>>>> the first completion suggestion by default = trouble. For example: >>>>>>>>> >>>>>>>>> 1. Type "printOn: aStream"... pretty common method start >>>>>>>>> 2. Hit enter to go to the next line >>>>>>>>> >>>>>>>>> You will now have "printOn: MCDataStream" WTF!! I get burned by this >>>>>>>>> pretty regularly and it's annoying. I'm not sure what the fix should be... >>>>>>>>> probably no default selection in the suggestion menu, but possibly only >>>>>>>>> when enter on accept is enabled (t would require an extra key press to >>>>>>>>> complete and when do you ever type a tab in the middle of a line?) >>>>>>>>> >>>>>>>> >>> I haven't used the 2.0 auto compeltion yet so I don't know if this is relevant, but just a passing thought... When Microsoft Word muck up using smart characters, one small saving grace is that it first enters my original typing before "smart-ifying" it, such that ctrl-z undoes back to my original typing. >>> >>> cheers -ben >>> >> > >

April 6, 2013

Re: [Pharo-project] Issue 10219: Completion: enter on accept awkwardness

by stephane ducasse

How can I get fast the choices? Because when I type printO and press tab I do not get printOn: but printO | Stef > fwiw, I changed the implementation of NECController to: > - accept both <enter> and <tab> for code completion > - still use <tab> to first complete the common prefixes, but a subsequent <tab> will select the suggestion > > i.e. this is the behavior in XCode, which imho is a very good one. > > _and_ I do not have to disable the completion of common prefixes if I want to disable <enter> for selection. > > Maybe people should give this a try and see? > > cheers > Johan > > > <NECController-Changes.cs> > > On 06 Apr 2013, at 02:18, Ben Coman <btc(a)openInWorld.com> wrote: > >> Alexandre Bergel wrote: >>> +1 >>> >>> Alexandre >>> >>> >>> On Apr 3, 2013, at 8:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> >>>> +1 >>>> >>>> Doru >>>> >>>> >>>> On Apr 4, 2013, at 2:19 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>> >>>>> On 3 April 2013 22:45, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>>> >>>>>> theres a setting to: >>>>>> >>>>>> - disable ENTER to accept the completion >>>>>> - to increase the popup delay >>>>>> >>>>>> so I think that is invalid bug report then... >>>>>> >>>>>> >>>>> i tend to disagree. >>>>> The defaults which we have now in 2.0 for autocompletion >>>>> is breaking my workflow badly too. >>>>> >>>>> Yes, i can go to settings and disable/reconfigure stuff but that doesn't >>>>> nullifying the fact, that my workflow is broken with ambiguous and inconsistent >>>>> reaction(s) to my keystrokes by UI if i keep defaults. >>>>> >>>>> For instance i am still clueless, why 'enter' is default for autocompletion, >>>>> and disabling it and enabling 'tab' simply doesn't works. >>>>> That leaves me with the only option: keep using 'enter' for >>>>> autocompletion, if i ever want to use it. >>>>> We have to fix that. >>>>> >>>>> >>>>> >>>>>> On 2013-04-03, at 22:23, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: >>>>>> >>>>>> >>>>>>> From >>>>>>> https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardn… >>>>>>> : >>>>>>> >>>>>>> >>>>>>>> The combination of enter on accept, with the current behavior to select >>>>>>>> the first completion suggestion by default = trouble. For example: >>>>>>>> >>>>>>>> 1. Type "printOn: aStream"... pretty common method start >>>>>>>> 2. Hit enter to go to the next line >>>>>>>> >>>>>>>> You will now have "printOn: MCDataStream" WTF!! I get burned by this >>>>>>>> pretty regularly and it's annoying. I'm not sure what the fix should be... >>>>>>>> probably no default selection in the suggestion menu, but possibly only >>>>>>>> when enter on accept is enabled (t would require an extra key press to >>>>>>>> complete and when do you ever type a tab in the middle of a line?) >>>>>>>> >>>>>>> >> I haven't used the 2.0 auto compeltion yet so I don't know if this is relevant, but just a passing thought... When Microsoft Word muck up using smart characters, one small saving grace is that it first enters my original typing before "smart-ifying" it, such that ctrl-z undoes back to my original typing. >> >> cheers -ben >> >

April 6, 2013

Re: [Pharo-project] Issue 10219: Completion: enter on accept awkwardness

by stephane ducasse

thanks I will try. Stef On Apr 6, 2013, at 8:22 AM, Johan Brichau <johan(a)inceptive.be> wrote: > fwiw, I changed the implementation of NECController to: > - accept both <enter> and <tab> for code completion > - still use <tab> to first complete the common prefixes, but a subsequent <tab> will select the suggestion > > i.e. this is the behavior in XCode, which imho is a very good one. > > _and_ I do not have to disable the completion of common prefixes if I want to disable <enter> for selection. > > Maybe people should give this a try and see? > > cheers > Johan > > > <NECController-Changes.cs> > > On 06 Apr 2013, at 02:18, Ben Coman <btc(a)openInWorld.com> wrote: > >> Alexandre Bergel wrote: >>> +1 >>> >>> Alexandre >>> >>> >>> On Apr 3, 2013, at 8:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> >>>> +1 >>>> >>>> Doru >>>> >>>> >>>> On Apr 4, 2013, at 2:19 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>> >>>>> On 3 April 2013 22:45, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>>> >>>>>> theres a setting to: >>>>>> >>>>>> - disable ENTER to accept the completion >>>>>> - to increase the popup delay >>>>>> >>>>>> so I think that is invalid bug report then... >>>>>> >>>>>> >>>>> i tend to disagree. >>>>> The defaults which we have now in 2.0 for autocompletion >>>>> is breaking my workflow badly too. >>>>> >>>>> Yes, i can go to settings and disable/reconfigure stuff but that doesn't >>>>> nullifying the fact, that my workflow is broken with ambiguous and inconsistent >>>>> reaction(s) to my keystrokes by UI if i keep defaults. >>>>> >>>>> For instance i am still clueless, why 'enter' is default for autocompletion, >>>>> and disabling it and enabling 'tab' simply doesn't works. >>>>> That leaves me with the only option: keep using 'enter' for >>>>> autocompletion, if i ever want to use it. >>>>> We have to fix that. >>>>> >>>>> >>>>> >>>>>> On 2013-04-03, at 22:23, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: >>>>>> >>>>>> >>>>>>> From >>>>>>> https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardn… >>>>>>> : >>>>>>> >>>>>>> >>>>>>>> The combination of enter on accept, with the current behavior to select >>>>>>>> the first completion suggestion by default = trouble. For example: >>>>>>>> >>>>>>>> 1. Type "printOn: aStream"... pretty common method start >>>>>>>> 2. Hit enter to go to the next line >>>>>>>> >>>>>>>> You will now have "printOn: MCDataStream" WTF!! I get burned by this >>>>>>>> pretty regularly and it's annoying. I'm not sure what the fix should be... >>>>>>>> probably no default selection in the suggestion menu, but possibly only >>>>>>>> when enter on accept is enabled (t would require an extra key press to >>>>>>>> complete and when do you ever type a tab in the middle of a line?) >>>>>>>> >>>>>>> >> I haven't used the 2.0 auto compeltion yet so I don't know if this is relevant, but just a passing thought... When Microsoft Word muck up using smart characters, one small saving grace is that it first enters my original typing before "smart-ifying" it, such that ctrl-z undoes back to my original typing. >> >> cheers -ben >> >

April 6, 2013

Re: [Pharo-project] [update 3.0] #30022

by stephane ducasse

> Yep, very good example of faked quality. > Making changes at the rate of Pharo is demanding and I understand the will to by-pass some quality rules. But then, any one wanting to give lessons should observe the real usage of the bug tracker and think again, because this is far from being an isolated case. Nicolas this is always easier to talk than to do :) And you got the prove of it so can we look at the 95% of good practices instead of the 5% wrong? Stef > > Nicolas > > > 2013/4/5 Igor Stasenko <siguctua(a)gmail.com> > On 5 April 2013 17:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > There does not seem to be any description in the issue tracker either, or maybe I missed it. > > > indeed, the record on issue tracker looks very informative. (in the attached). > > >> On Fri, Apr 5, 2013 at 1:51 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> 30022 > >> ----- > >> > >> 10032 Integrate new debugger > >> https://pharo.fogbugz.com/f/cases/10032 > >> > >> Diff information: > >> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/DebuggerModel-EstebanLorenza… > >> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Spec-Debugger-EstebanLorenza… > > > > > > -- > Best regards, > Igor Stasenko. >

April 6, 2013

Re: [Pharo-project] [update 3.0] #30022

by stephane ducasse

Hi igor since you were at the meeting where we built the list of actions, you could also have edited the entry and add more information. Camille was nice to take notes for everbody and to open issues. I added contents. Now we can also use a bad and private wiki to store information that is clear for the core team but it will not be nice. Stef > On 5 April 2013 17:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> There does not seem to be any description in the issue tracker either, or maybe I missed it. >> > indeed, the record on issue tracker looks very informative. (in the attached). > >>> On Fri, Apr 5, 2013 at 1:51 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> 30022 >>> ----- >>> >>> 10032 Integrate new debugger >>> https://pharo.fogbugz.com/f/cases/10032 >>> >>> Diff information: >>> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/DebuggerModel-EstebanLorenza… >>> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Spec-Debugger-EstebanLorenza… >> > > > > -- > Best regards, > Igor Stasenko. > <Screen Shot 2013-04-05 at 9.23.06 PM.png>

April 6, 2013

Re: [Pharo-project] [update 3.0] #30022

by stephane ducasse

>> > > Indeed, sounds very promising but what does it mean ? > There does not seem to be any description in the issue tracker either, or maybe I missed it. What we integrated is a model (two classes) that andrei wrote based on the old debugger. The old debugger does not make the distinction cleanly between a model and the view. So the logic is mixed with the display. When andrei came at lille he wrote with ben a Spec interface. We should rethink it by the way because I prefer the glamourst one much more :). So this model is good because we can build tools on top. What we plan in the future is to have - to get a new UI based on the model and that this ui via this model still use the old logic (bytecode interpretation and the bugs we get with it) - an AST interpreter and plug it with this model so get a really new debugger execution logic (not a bytecode mapping range to text one) So Pharo30 will have at least two debuggers for a while - the old one but we are rewamped ui and using the model of andrei - the one based on AST interpretation using the rewamped ui and using the model of andrei Stef > >> On Fri, Apr 5, 2013 at 1:51 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> 30022 >> ----- >> >> 10032 Integrate new debugger >> https://pharo.fogbugz.com/f/cases/10032 >> >> Diff information: >> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/DebuggerModel-EstebanLorenza… >> http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Spec-Debugger-EstebanLorenza… >

April 6, 2013

Re: [Pharo-project] Issue 10219: Completion: enter on accept awkwardness

by Johan Brichau

fwiw, I changed the implementation of NECController to: - accept both <enter> and <tab> for code completion - still use <tab> to first complete the common prefixes, but a subsequent <tab> will select the suggestion i.e. this is the behavior in XCode, which imho is a very good one. _and_ I do not have to disable the completion of common prefixes if I want to disable <enter> for selection. Maybe people should give this a try and see? cheers Johan On 06 Apr 2013, at 02:18, Ben Coman <btc(a)openInWorld.com> wrote: > Alexandre Bergel wrote: >> +1 >> >> Alexandre >> >> >> On Apr 3, 2013, at 8:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> >>> +1 >>> >>> Doru >>> >>> >>> On Apr 4, 2013, at 2:19 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> >>>> On 3 April 2013 22:45, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>> >>>>> theres a setting to: >>>>> >>>>> - disable ENTER to accept the completion >>>>> - to increase the popup delay >>>>> >>>>> so I think that is invalid bug report then... >>>>> >>>>> >>>> i tend to disagree. >>>> The defaults which we have now in 2.0 for autocompletion >>>> is breaking my workflow badly too. >>>> >>>> Yes, i can go to settings and disable/reconfigure stuff but that doesn't >>>> nullifying the fact, that my workflow is broken with ambiguous and inconsistent >>>> reaction(s) to my keystrokes by UI if i keep defaults. >>>> >>>> For instance i am still clueless, why 'enter' is default for autocompletion, >>>> and disabling it and enabling 'tab' simply doesn't works. >>>> That leaves me with the only option: keep using 'enter' for >>>> autocompletion, if i ever want to use it. >>>> We have to fix that. >>>> >>>> >>>> >>>>> On 2013-04-03, at 22:23, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: >>>>> >>>>> >>>>>> From >>>>>> https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardn… >>>>>> : >>>>>> >>>>>> >>>>>>> The combination of enter on accept, with the current behavior to select >>>>>>> the first completion suggestion by default = trouble. For example: >>>>>>> >>>>>>> 1. Type "printOn: aStream"... pretty common method start >>>>>>> 2. Hit enter to go to the next line >>>>>>> >>>>>>> You will now have "printOn: MCDataStream" WTF!! I get burned by this >>>>>>> pretty regularly and it's annoying. I'm not sure what the fix should be... >>>>>>> probably no default selection in the suggestion menu, but possibly only >>>>>>> when enter on accept is enabled (t would require an extra key press to >>>>>>> complete and when do you ever type a tab in the middle of a line?) >>>>>>> >>>>>> > I haven't used the 2.0 auto compeltion yet so I don't know if this is relevant, but just a passing thought... When Microsoft Word muck up using smart characters, one small saving grace is that it first enters my original typing before "smart-ifying" it, such that ctrl-z undoes back to my original typing. > > cheers -ben >

April 6, 2013