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

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

Re: [Pharo-project] Collect all references to AnObsoleteFoo

by Mariano Martinez Peck

Martin, should be manage obsolete always that way (meaning to put such behavior directly inside Fuel)? If not, could be write your awesome code in the Fuel website? Thanks!!! :) On Sat, Apr 6, 2013 at 8:26 AM, roberto.minelli(a)usi.ch < roberto.minelli(a)usi.ch> wrote: > Martin, your solution is awesome. > > I've seen the presentation at Pharoconf about setting an analyzer to the > serializer and I was thinking in that direction. > > Thanks a lot, > R > > On Apr 5, 2013, at 4:59 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > > As Fernando said, probably is better for you to substitute the obsolete > class by a ring definition. Look here: > > > > http://ws.stfx.eu/OAVG8IXKWOYA > > > > Don't need to filein the workaround of my previous email. > > > > Martin > > > > > > On Fri, Apr 5, 2013 at 4:47 PM, Martin Dias <tinchodias(a)gmail.com> > wrote: > > Hi, > > I'm sorry for my delay. I didn't stop to think a good solution. There > were interesting answers before mine. But if it's a prototype... maybe this > workaround helps you. I played with this code: > > > > http://ws.stfx.eu/HYWM1ZB9R45K > > > > (the first time I use the shared workspace :-) > > > > if you file in the attached file, it materializes the new A class. > > > > But this will be not useful for you, if either: > > - you don't have the "original class" at materialization time > > - you don't want to know if the class was obsolete at serialization time > > > > HTH > > Martin > > > > > > > > On Tue, Apr 2, 2013 at 7:33 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > > On 02/04/13 12:50 AM, roberto.minelli-BHDiRLqP7qo(a)public.gmane.orgwrote: > > > > Is there any way to "browse" through such references to understand where > are they? > > > > From an inspector, choose the "Explore pointers", making sure you've > selected the object that you're trying to understand what is referencing it. > > > > It takes trial & error, and intuition on which pointers to follow. This > method has often been unsuccessful for me. > > > > Another approach (my memory is fuzzy), was to put a halt at a suitable > place during the Fuel serialization. Then explore the intermediate > structures used by Fuel, to try to find out why Fuel thinks it needs to > serialize that object. > > > > Yet another approach is to put a halt in the Fuel materialization, and > explore the intermediate structures used by Fuel. You might even set up a > mapping of the obsolete class to some temporary class, which allows Fuel to > fully materialize the saved objects. You can then explore the Fuel > intermediate structures, as well as the final de-serialized object > structure. > > > > > > > > > > > -- Mariano http://marianopeck.wordpress.com

April 6, 2013

Re: [Pharo-project] Collect all references to AnObsoleteFoo

by roberto.minelli＠usi.ch

Martin, your solution is awesome. I've seen the presentation at Pharoconf about setting an analyzer to the serializer and I was thinking in that direction. Thanks a lot, R On Apr 5, 2013, at 4:59 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > As Fernando said, probably is better for you to substitute the obsolete class by a ring definition. Look here: > > http://ws.stfx.eu/OAVG8IXKWOYA > > Don't need to filein the workaround of my previous email. > > Martin > > > On Fri, Apr 5, 2013 at 4:47 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi, > I'm sorry for my delay. I didn't stop to think a good solution. There were interesting answers before mine. But if it's a prototype... maybe this workaround helps you. I played with this code: > > http://ws.stfx.eu/HYWM1ZB9R45K > > (the first time I use the shared workspace :-) > > if you file in the attached file, it materializes the new A class. > > But this will be not useful for you, if either: > - you don't have the "original class" at materialization time > - you don't want to know if the class was obsolete at serialization time > > HTH > Martin > > > > On Tue, Apr 2, 2013 at 7:33 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 02/04/13 12:50 AM, roberto.minelli-BHDiRLqP7qo(a)public.gmane.org wrote: > > Is there any way to "browse" through such references to understand where are they? > > From an inspector, choose the "Explore pointers", making sure you've selected the object that you're trying to understand what is referencing it. > > It takes trial & error, and intuition on which pointers to follow. This method has often been unsuccessful for me. > > Another approach (my memory is fuzzy), was to put a halt at a suitable place during the Fuel serialization. Then explore the intermediate structures used by Fuel, to try to find out why Fuel thinks it needs to serialize that object. > > Yet another approach is to put a halt in the Fuel materialization, and explore the intermediate structures used by Fuel. You might even set up a mapping of the obsolete class to some temporary class, which allows Fuel to fully materialize the saved objects. You can then explore the Fuel intermediate structures, as well as the final de-serialized object structure. > > > >

April 6, 2013

Re: [Pharo-project] ConfigurationOf

by roberto.minelli＠usi.ch

On Apr 6, 2013, at 10:26 AM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > On Apr 5, 2013, at 11:58 AM, roberto.minelli(a)usi.ch wrote: > >> Hi, >> >> I build the ConfigurationOf for my current project and it works fine, but I have some doubts. >> My project has dependencies on two other projects, namely Spy and Fuel. >> In my ConfigurationOf I'm loading these two projects before fetching my code. >> >> The point is that, for example, I'm loading Fuel even if it is already loaded in the current image and the same for Spy. >> >> Could you help me in creating a ConfigurationOf which only loads those projects if not already in the image and eventually only updates them to the last version? > > > this is the default behavior of metacello so I do not understand what you mean. Good to know! Thanks. > Did you read the metacello chapter I wrote? > >> >> Thanks in advance, >> R >> >> P.s. Here (http://ws.stfx.eu/QOMGC86FZTG) is my current baseline for the ConfigurationOf. > >

April 6, 2013