- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Resuming Issue Tracker Mailing List

by Esteban Lorenzano

but yes... even for this list or the other, it would be could be able to decide which kind of issue updates we want to be notified :S On Apr 6, 2013, at 6:22 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > well, but since I cannot imagine any of this list not subscribing to the other one, I do not see the difference, other than eliminate bureaucracy :) > > Esteban > > On Apr 6, 2013, at 6:07 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Apr 6, 2013, at 5:44 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> Hi, >>> >>> To be honest, I don't think a separate mailing list has much sense. >>> I would prefer to redirect mails to this list (this is a pharo-dev list, after all... ). >> >> >> Sorry, the bug racker sends a mail for every trivial change (re-categorization, whatever). >> We will drown in mail, it makes no sense. >> >> Marcus >

April 6, 2013

Re: [Pharo-project] Resuming Issue Tracker Mailing List

by Esteban Lorenzano

well, but since I cannot imagine any of this list not subscribing to the other one, I do not see the difference, other than eliminate bureaucracy :) Esteban On Apr 6, 2013, at 6:07 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Apr 6, 2013, at 5:44 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> Hi, >> >> To be honest, I don't think a separate mailing list has much sense. >> I would prefer to redirect mails to this list (this is a pharo-dev list, after all... ). > > > Sorry, the bug racker sends a mail for every trivial change (re-categorization, whatever). > We will drown in mail, it makes no sense. > > Marcus

April 6, 2013

Re: [Pharo-project] Resuming Issue Tracker Mailing List

by Marcus Denker

On Apr 6, 2013, at 5:44 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > To be honest, I don't think a separate mailing list has much sense. > I would prefer to redirect mails to this list (this is a pharo-dev list, after all... ). Sorry, the bug racker sends a mail for every trivial change (re-categorization, whatever). We will drown in mail, it makes no sense. Marcus

April 6, 2013

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

by Igor Stasenko

On 6 April 2013 08:22, 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? your change seems even better than mine. I just changed it in a way that tab = enter in terms of completion. (so you can use either tab or enter to do the same thing). > > 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 >> > > -- Best regards, Igor Stasenko.

April 6, 2013

Re: [Pharo-project] Resuming Issue Tracker Mailing List

by Esteban Lorenzano

Hi, To be honest, I don't think a separate mailing list has much sense. I would prefer to redirect mails to this list (this is a pharo-dev list, after all... ). With the filtering/labeling tools that every mail/webmail client has nowadays, it should be easy to the people who do not want to receive them to filter out or to put them in a separate place. my 2c Esteban On Apr 6, 2013, at 4:51 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Apr 6, 2013, at 3:49 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > >> Marcus Denker-4 wrote >>> The old list got a mail for every change done on the trackerâ¦ >>> >>> We can do that again: we can subscribe it to all the projects. But it >>> might be a bit >>> too much. >> >> Well since it's a special mailing list dedicated solely to the issue >> tracker, why would it be too much? For me, I found it very useful to track >> progress in a far less intrusive way then having every update come to my >> inbox. >> > > It's no problem to enable itâ¦ I will do it. (People then can decide if they > read the ML or if the configure FugBugz to send them a subset). > > Marcus

April 6, 2013

Re: [Pharo-project] Resuming Issue Tracker Mailing List

by Marcus Denker

On Apr 6, 2013, at 3:49 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Marcus Denker-4 wrote >> The old list got a mail for every change done on the trackerâ¦ >> >> We can do that again: we can subscribe it to all the projects. But it >> might be a bit >> too much. > > Well since it's a special mailing list dedicated solely to the issue > tracker, why would it be too much? For me, I found it very useful to track > progress in a far less intrusive way then having every update come to my > inbox. > It's no problem to enable itâ¦ I will do it. (People then can decide if they read the ML or if the configure FugBugz to send them a subset). Marcus

April 6, 2013

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

by ClÃ©ment Bera

This is exactly that. The tree coverage tool is a subclass of AST-interpreter, which adding to the interpretation marks the nodes. And then I use this marking to color the source code. And I use as you said RB ast. This is why I implemented it in a few hours, I had already an AST-interpreter, so I've just created a quick subclass and a spec UI. 2013/4/6 Frank Shearar <frank.shearar(a)gmail.com> > So if you don't mind me being very loose with terminology, you > interpret (RB) ASTs, and the act of interpreting marks the nodes in > these ASTs, which you can then use to colour source? > > frank > > On 6 April 2013 11:00, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Actually, it is quite different than Jejak. > > > > Implementation wise, Jejak used Opal so I guess it relies on bytecode > > modification to do its analysis where my tool relies on ast annotations. > > > > This implies some difference in features. It seems that Jejak record all > > calls, all values and all assignments in a method (which is byte code > level > > feature), whereas I record for each ast node if it was interpreted or not > > (which is ast level feature). I guess there would be a little difference > in > > the use cases. > > > > > > 2013/4/6 Frank Shearar <frank.shearar(a)gmail.com> > >> > >> On 6 April 2013 07:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >>> > >>> Clement built in a couple of hours the following nice branch > >>> analysecoverage tools :) > >>> It is dead slow but cool. > >> > >> > >> By "branch coverage tool" do you mean Jejak? > >> > >> frank > >> > >> > > > > > > > > -- > > ClÃ©ment BÃ©ra > > Mate Virtual Machine Engineer > > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > -- ClÃ©ment BÃ©ra Mate Virtual Machine Engineer BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq*

April 6, 2013

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

by Sean P. DeNigris

Johan Brichau-2 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 > > Maybe people should give this a try and see? Sounds cool. I will start using it and report back. Thanks! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-10219-Completion-enter-on-accept-awkwardness-tp… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 6, 2013

Re: [Pharo-project] Resuming Issue Tracker Mailing List

by Sean P. DeNigris

Marcus Denker-4 wrote > The old list got a mail for every change done on the trackerâ¦ > > We can do that again: we can subscribe it to all the projects. But it > might be a bit > too much. Well since it's a special mailing list dedicated solely to the issue tracker, why would it be too much? For me, I found it very useful to track progress in a far less intrusive way then having every update come to my inbox. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Resuming-Issue-Tracker-Mailing-List-tp4679712p4679960… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 6, 2013

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

by Frank Shearar

So if you don't mind me being very loose with terminology, you interpret (RB) ASTs, and the act of interpreting marks the nodes in these ASTs, which you can then use to colour source? frank On 6 April 2013 11:00, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Actually, it is quite different than Jejak. > > Implementation wise, Jejak used Opal so I guess it relies on bytecode > modification to do its analysis where my tool relies on ast annotations. > > This implies some difference in features. It seems that Jejak record all > calls, all values and all assignments in a method (which is byte code level > feature), whereas I record for each ast node if it was interpreted or not > (which is ast level feature). I guess there would be a little difference in > the use cases. > > > 2013/4/6 Frank Shearar <frank.shearar(a)gmail.com> >> >> On 6 April 2013 07:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> Clement built in a couple of hours the following nice branch >>> analysecoverage tools :) >>> It is dead slow but cool. >> >> >> By "branch coverage tool" do you mean Jejak? >> >> frank >> >> > > > > -- > ClÃ©ment BÃ©ra > Mate Virtual Machine Engineer > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

April 6, 2013