- Pharo-dev - lists.pharo.org

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

by Sven Van Caekenberghe

On 05 Apr 2013, at 11:20, Diego Lont <diego.lont(a)delware.nl> wrote: >> I feel that we are confusing lots of things. >> >> This is not a discussion about the browser or the IDE, it is about completion. >> And not just about which key does what but also about complex interactions in specific situations. >> >> Pharo 2.0 is out, Nautilus is the default browser, a massive amount of work went into cleaning and getting a workable completion system, choices were made - you/we basically have to live with that. >> >> There are options in Settings for some tuning, and we will continue to improve, absolutely. We have to discuss and iterate. >> >> Please do not underestimate the amount of work done to get 2.0 where it is now. >> >> Sven > > Sven, > > I agree that a lot of good work has been done to get 2.0 where it is now. I do not want to ignore that. And I think we all have to same goal: to make Pharo better. So when I think I have a point, I want an open discussion about this. > > On the PharoConf I said some things to Stef, and he answered: discuss this on the mailing list. Now I try to do so on the mailinglist and I get responses like: > "settings will not change" > " We did a lot of work, so do not complain" > > Please tell me, why do you think this is not worth discussing? > > Regards, > Diego Diego, Read my mail, I said: "We have to discuss and iterate." It is just that 2.0 is released, it cannot change, 2.x will never have drastic changes. 3.0 is the next line of development. To stay on the subject: I have worked with/in 2.0 for many months, maybe almost a year. Completion went through lots of iterations, there were many discussions. It is reasonably good or at least acceptable now (at some points it was completely broken). Some people worked very hard on this and I respect that enormously (they also had to deal with everybody's opinion as well as complex code). I am very confident that we can tune this a bit more to make it 'perfect'. The main issue IMHO is not so much the actual key binding, but the way to get out of the menu if you don't want to pick a suggestion (though ESC does that). It might be that Smalltalk is special here, but I doubt it. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

April 5, 2013

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

by Esteban Lorenzano

On Apr 4, 2013, at 7:02 PM, Diego Lont <diego.lont(a)delware.nl> wrote: >> On 4 April 2013 15:45, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> really? >>> please, add an issue in the tracker and submit a slice, as everybody else. >>> >> calm down, we're just discussing here. >> I provided code here intentionally for nay-sayers like you to try it >> and to check if it not breaks >> something else (your workflow). > > Esteban, > > Having a new Browser in Pharo 2.0 is a big change. Everyone needs to get used to it. And I agree it is probably a good thing. But â¦ there are some things that worked better in OB that I don't want to loose. There are a lot of people annoyed by how it works nowâ¦. but I think the mailing list is about exchanging arguments not about deciding. So I do not like that you try to end the discussion by shouting: the defaults will not change. So here I will add a new argument. I'm not closing the discussion. I'm just pointing that the reasons why we took that decision remains more relevant than your argument. And also I'm pointing that you have the settings to adapt to your desired behavior. Finally, I also pointing that if there is something bad or a feature not present (like the coexistence of tab and enter), there is always room to improvement :) > > Your argument about other languages is a valid point, but only holds if Smalltalk is similar as other languages. Why does this "enter" annoys me? Because in some cases it replaces my code by garbage. At least when I type a method invocation that does not exist yet, it replaces it by an existing method. And this is repeatable. So when you go back (using backspace and typing it again, because it also adds before the things I typed) and the press enter again, it does the same replacement. So there is a difference here between smalltalk and other languages. When I do test-driven development (that I do a lot), I first write my test, invoking a lot of methods that do not exist yet. I do not do this in another language, because my environment isn't good enough then. A feeble argument too. We are not talking about a language but about a language's IDE (and yes, I know that Pharo, as any other smalltalk is language+IDE, and you cannot separate them). The IDE should help the developer. The defaults should help the newcomers, and the settings should be available for power users to adapt the IDE to their preferred ways to do things. So, now... I know that completion is working bad, but the "enter" issue is not the problem. I can point several other problems: 1) the most important: the answers are not accurate, and not even close. Yes, it returns symbols starting with your entry, but they are not context aware (the old completion was doing a better job by just arranging results and presenting first the latest things you entered) 2) It offers completions in bad places (like appearing after you put colon and before letting you press space) 3) Some times it changes code intead inserting it, or inserts it in bad places. 4) There are some options users desire that are not present. So... your feedback is valuable, of course, and many many times you are right. But in this case I still thing you are just wrong, and your solution is use the settings. cheers, Esteban

April 5, 2013

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

by Diego Lont

> I feel that we are confusing lots of things. > > This is not a discussion about the browser or the IDE, it is about completion. > And not just about which key does what but also about complex interactions in specific situations. > > Pharo 2.0 is out, Nautilus is the default browser, a massive amount of work went into cleaning and getting a workable completion system, choices were made - you/we basically have to live with that. > > There are options in Settings for some tuning, and we will continue to improve, absolutely. We have to discuss and iterate. > > Please do not underestimate the amount of work done to get 2.0 where it is now. > > Sven Sven, I agree that a lot of good work has been done to get 2.0 where it is now. I do not want to ignore that. And I think we all have to same goal: to make Pharo better. So when I think I have a point, I want an open discussion about this. On the PharoConf I said some things to Stef, and he answered: discuss this on the mailing list. Now I try to do so on the mailinglist and I get responses like: "settings will not change" " We did a lot of work, so do not complain" Please tell me, why do you think this is not worth discussing? Regards, Diego

April 5, 2013

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

by Sven Van Caekenberghe

On 04 Apr 2013, at 19:02, Diego Lont <diego.lont(a)delware.nl> wrote: >> On 4 April 2013 15:45, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> really? >>> please, add an issue in the tracker and submit a slice, as everybody else. >>> >> calm down, we're just discussing here. >> I provided code here intentionally for nay-sayers like you to try it >> and to check if it not breaks >> something else (your workflow). > > Esteban, > > Having a new Browser in Pharo 2.0 is a big change. Everyone needs to get used to it. And I agree it is probably a good thing. But â¦ there are some things that worked better in OB that I don't want to loose. There are a lot of people annoyed by how it works nowâ¦. but I think the mailing list is about exchanging arguments not about deciding. So I do not like that you try to end the discussion by shouting: the defaults will not change. So here I will add a new argument. > > Your argument about other languages is a valid point, but only holds if Smalltalk is similar as other languages. Why does this "enter" annoys me? Because in some cases it replaces my code by garbage. At least when I type a method invocation that does not exist yet, it replaces it by an existing method. And this is repeatable. So when you go back (using backspace and typing it again, because it also adds before the things I typed) and the press enter again, it does the same replacement. So there is a difference here between smalltalk and other languages. When I do test-driven development (that I do a lot), I first write my test, invoking a lot of methods that do not exist yet. I do not do this in another language, because my environment isn't good enough then. I feel that we are confusing lots of things. This is not a discussion about the browser or the IDE, it is about completion. And not just about which key does what but also about complex interactions in specific situations. Pharo 2.0 is out, Nautilus is the default browser, a massive amount of work went into cleaning and getting a workable completion system, choices were made - you/we basically have to live with that. There are options in Settings for some tuning, and we will continue to improve, absolutely. We have to discuss and iterate. Please do not underestimate the amount of work done to get 2.0 where it is now. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

April 5, 2013

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

by S Krish

Process vs working out fixes quick is and will always be a quirky issue all developers grapple with. There is no ideal process solution that can fix all situations easily / conveniently. In such process boundaries, adaptability will be key while gently pushing for process in as much as the group of people will accept. win-win is when everyone aligns. To the point here.. the patch forwarded does work well... for tab and enter. I like it. "Complete common prefixes using TAB in the suggested completions" : I will presume this fix now removes call to #insertCommonPrefixes : should the fix not remove this item in Settings>>Code Completion. I would aver its tad confusing to do insertCommonPrefixes with TAB and nothing when you select other choices in the list. On Fri, Apr 5, 2013 at 11:59 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 4 April 2013 19:52, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > > On 2013-04-04, at 18:51, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > >> On 4 April 2013 17:38, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >>> > >>> On 2013-04-04, at 16:11, Igor Stasenko <siguctua(a)gmail.com> wrote: > >>> > >>>> On 4 April 2013 15:45, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >>>>> really? > >>>>> please, add an issue in the tracker and submit a slice, as everybody > else. > >>>>> > >>>> calm down, we're just discussing here. > >>>> I provided code here intentionally for nay-sayers like you to try it > >>>> and to check if it not breaks > >>>> something else (your workflow). > >>> > >>> Igor, not Esteban's workflow.. OUR WORKFLOW! > >>> > >> > >> Sure sure. Now have you tried the code which i sent if it works/breaks > for you? > >> > >> Or i should spend like 10 minutes filing the issue before figuring > >> that it is unacceptable? > > > > What the fuck do you think the rest does? > > > >> https://pharo.fogbugz.com/default.asp?10228 > > > > |( well the issue is the main entry point. If the code does not work > > you will be notified VIA the issue => manageed entity > > > > However how you solve this issue right now is by some fuzzy undefined > process > > nobody manages. If you think that this change is worth getting into > pharo then > > you open an issue and attach the SLICE (no changeset, SLICES). > > > > Then the whole machinery starts, people (INCLUDING YOU) look at the > issues. > > Issue get rejected, modified, adapted! > > > > What you show here is IGNORANCE on a higher level. > > YOU IGNORE A WHOLE DAMN DEVELOPMENT PROCESS PEOPLE USE EVERY DAY. > > And you put yourself into the brilliant exception position. > > > Not at all. > > > Believe me I am not the only one who is upset with that. (but usually the > > one who complains first). > > > > > > So why do I complain? > > > > - I know that you haven't filed a single issue on the new issue tracker > > - I know that you DO NOT like the new issue tracker > > - I know that you DO NOT like to use SLICES (even though everybody else > does) > > > > and.. > > - I am pretty convinced that you will never file an issue on the new > issue tracker > > > > Hmm.. I already did. Before you even wrote your outrageous post. > > > > > Why? I don't know, I really don't. I wish I could understand your point > > here, but I cannot. > > You did not replied to a most important question , which goes first: > does it works for you or not. > > Issue tracker (as its name states) helps with tracking the issue, but > it does not solves it. > > Putting things on issue tracker doesn't means that issue will be > solved. Because nothing forces you to look at issue, you can still > ignore it. > You can complain that it was not filed correctly, there's "field A is > empty", field B is wrong and all sorts of bureaucracy.. > > So, if there's no action (like trying the proposed solution) while > topic is hot on mailing list, > i am pretty sure that there will be no any action with that issue later. > The code will be just silently integrated, only to be found later that > change is inappropriate and breaks things here and there.. and then we > go over again, by opening one more issue, and spending our precious > time on following the process, instead of solving the real problems. > > > -- > Best regards, > Igor Stasenko. > >

April 5, 2013

Re: [Pharo-project] [FYI] Athens tutorial

by Igor Stasenko

On 4 April 2013 19:33, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Same error here on OSX. I guess it is because we need to use the FreeType > fonts instead of the default StrikeFonts. > Yes, Athens does not supports StrikeFont(s). Because they are not scalable and more than that, they using precomputed subpixel bitmaps, which assuming that your font will always match the pixel grid, which in case of scaling/rotating of course will not. > > 2013/4/4 Jimmie Houchin <jlhouchin(a)gmail.com> >> >> On 04/04/2013 11:34 AM, Igor Stasenko wrote: >>> >>> On 4 April 2013 17:38, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >>>> >>>> Hello, >>>> >>>> I am on Ubuntu 12.10 32bit. >>>> >>>> ... SNIP ... >>>> I then open the image and proceed with loading the code and the >>>> tutorial. >>>> >>>> I skip page 1 and "doit" on page 2 and I get this error. >>>> >>>> Error: failed to get a symbol address: cairo_image_surface_create >>>> >>>> As far as I can tell, I have Cairo installed on my system. I have >>>> libcairo2. >>> >>> check if path to the library is correct for your OS in >>> CairoLibraryLoader class. >> >> Thanks, that was the problem. >> >> On Ubuntu 12.10, I don't have a libcairo.so, but rather a libcairo.so.2 in >> /usr/lib/i386-linux-gnu. >> >> I created the link /usr/lib/libcairo.so as expected by Pharo, and it >> works. >> >> Now, when I get to screen 30, I enabled FreeType as instructed but I am >> getting an error >> MNU: StrikeFont>>glyphRenderOn: >> >> Thanks again. >> >> Jimmie >> > -- Best regards, Igor Stasenko.

April 5, 2013

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

by Igor Stasenko

On 4 April 2013 19:52, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-04-04, at 18:51, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 4 April 2013 17:38, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>> On 2013-04-04, at 16:11, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> On 4 April 2013 15:45, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> really? >>>>> please, add an issue in the tracker and submit a slice, as everybody else. >>>>> >>>> calm down, we're just discussing here. >>>> I provided code here intentionally for nay-sayers like you to try it >>>> and to check if it not breaks >>>> something else (your workflow). >>> >>> Igor, not Esteban's workflow.. OUR WORKFLOW! >>> >> >> Sure sure. Now have you tried the code which i sent if it works/breaks for you? >> >> Or i should spend like 10 minutes filing the issue before figuring >> that it is unacceptable? > > What the fuck do you think the rest does? > >> https://pharo.fogbugz.com/default.asp?10228 > > |( well the issue is the main entry point. If the code does not work > you will be notified VIA the issue => manageed entity > > However how you solve this issue right now is by some fuzzy undefined process > nobody manages. If you think that this change is worth getting into pharo then > you open an issue and attach the SLICE (no changeset, SLICES). > > Then the whole machinery starts, people (INCLUDING YOU) look at the issues. > Issue get rejected, modified, adapted! > > What you show here is IGNORANCE on a higher level. > YOU IGNORE A WHOLE DAMN DEVELOPMENT PROCESS PEOPLE USE EVERY DAY. > And you put yourself into the brilliant exception position. > Not at all. > Believe me I am not the only one who is upset with that. (but usually the > one who complains first). > > > So why do I complain? > > - I know that you haven't filed a single issue on the new issue tracker > - I know that you DO NOT like the new issue tracker > - I know that you DO NOT like to use SLICES (even though everybody else does) > > and.. > - I am pretty convinced that you will never file an issue on the new issue tracker > Hmm.. I already did. Before you even wrote your outrageous post. > > Why? I don't know, I really don't. I wish I could understand your point > here, but I cannot. You did not replied to a most important question , which goes first: does it works for you or not. Issue tracker (as its name states) helps with tracking the issue, but it does not solves it. Putting things on issue tracker doesn't means that issue will be solved. Because nothing forces you to look at issue, you can still ignore it. You can complain that it was not filed correctly, there's "field A is empty", field B is wrong and all sorts of bureaucracy.. So, if there's no action (like trying the proposed solution) while topic is hot on mailing list, i am pretty sure that there will be no any action with that issue later. The code will be just silently integrated, only to be found later that change is inappropriate and breaks things here and there.. and then we go over again, by opening one more issue, and spending our precious time on following the process, instead of solving the real problems. -- Best regards, Igor Stasenko.

April 5, 2013

Re: [Pharo-project] can no longer compile code without .changes file in Pharo-2.0

by Yanni Chiu

On 05/04/13 2:04 AM, Marcus Denker wrote: > > Instead of #copyWithTempsFromMethodNode: it should just call #copyWithSource: Yes, that fixed it - now running with Pharo-2.0 (more testing to do though).

April 5, 2013

Re: [Pharo-project] can no longer compile code without .changes file in Pharo-2.0

by Marcus Denker

On Apr 5, 2013, at 7:52 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > I deploy without a .changes file, but the image still compiles code at runtime. The methods are just accessor methods, and no image save is ever done. > > Using Pharo-2.0 (instead of Pharo-1.4), I now get a walkback: > > VM: unix - i686 - linux-gnu - NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 > > Image: Pharo2.0 [Latest update: #20593] > > CompiledMethod(Object)>>doesNotUnderstand: #copyWithTempsFromMethodNode: > CompiledMethod>>putSource:fromParseNode:inFile:withPreamble: > ... > > It seems that #putSource:fromParseNode:inFile:withPreamble: calls #copyWithTempsFromMethodNode:, when there is no .changes file, but that method is not in the image. > > Is it safe to just patch the code to do nothing? The method comment says that the method temp names are saved for decompilation. > Am a bugâ¦. in 2.0 I started to simplify the whole source code messâ¦ it turns out that the whole (quite tricky) concept of encoding temp names in the trailer is not needed. So it got replaced by just putting all source in the trailer if needed (e.g. dots or when not having the changes file). It seems that the method putSource:fromParseNode:inFile:withPreamble: got somehow a revert (or I forgot to change the sender when I did the change?). Instead of #copyWithTempsFromMethodNode: it should just call #copyWithSource: (I will out a bug report and fix for both 2.0 on the tracker later) In general, there is still quite some opportunity for radical simplification in the whole changes/sources storyâ¦ Marcus

April 5, 2013

[Pharo-project] can no longer compile code without .changes file in Pharo-2.0

by Yanni Chiu

I deploy without a .changes file, but the image still compiles code at runtime. The methods are just accessor methods, and no image save is ever done. Using Pharo-2.0 (instead of Pharo-1.4), I now get a walkback: VM: unix - i686 - linux-gnu - NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 Image: Pharo2.0 [Latest update: #20593] CompiledMethod(Object)>>doesNotUnderstand: #copyWithTempsFromMethodNode: CompiledMethod>>putSource:fromParseNode:inFile:withPreamble: ... It seems that #putSource:fromParseNode:inFile:withPreamble: calls #copyWithTempsFromMethodNode:, when there is no .changes file, but that method is not in the image. Is it safe to just patch the code to do nothing? The method comment says that the method temp names are saved for decompilation.

April 5, 2013