September 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] getting rid of these boring questions and popup

by StÃ©phane Ducasse

yeap good idea. A kind of log console. Stef >> >>> Stef, >>> >>> Yes, the popups should go away - far away :) A code mentor pane >>> with lint rule violations would be greatly appreciated, but the >>> modal messages are too much. Sometimes I want to save code that I >>> know will generate errors, with reasons ranging from "I'll let it >>> blow up and choose to implement it from the debugger" to "don't want >>> to lose this, so let's get it accepted before I do something >>> stupid." >> >> same here! >> At least we have a common vision and we can go slowly there. >> > > I having the same vision. Browser should not prevent you from > accepting the badly crafted code. It should allow it > unless there is syntax errors. > All warnings, like unused temps, use of unassigned temps etc, should > pop-up in a list pane below the code pane, > so user could see it and react, or just ignore and go & do something > else. Btw, this pane could be reused for more deeper/complex > code analyzing tools, like lint etc. > >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2009

Re: [Pharo-project] Problems with MC (was Re: May be some problems with MC history)

by StÃ©phane Ducasse

I just publish a couple of MC packages in the inbox one just to fix a bad reference to ChangeSorter instead of ChangesOrganizer (not needed so far) one for 309 (which was a kind of changes to support atomic loading) but did not really helped one for 321 where andreas patched that so that they could load closure fixes one with installAll menu in MCPatchBrowser :) So let me know if this is working. I could load eliot fixes for kernel (package two = step two of the eight) without problem. Stef (now I'm sick so going to bed).

Sept. 12, 2009

Re: [Pharo-project] getting rid of these boring questions and popup

by Igor Stasenko

2009/9/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Sep 11, 2009, at 11:32 PM, Schwab,Wilhelm K wrote: > >> Stef, >> >> Yes, the popups should go away - far away :) Â A code mentor pane >> with lint rule violations would be greatly appreciated, but the >> modal messages are too much. Â Sometimes I want to save code that I >> know will generate errors, with reasons ranging from "I'll let it >> blow up and choose to implement it from the debugger" to "don't want >> to lose this, so let's get it accepted before I do something stupid." > > same here! > At least we have a common vision and we can go slowly there. > I having the same vision. Browser should not prevent you from accepting the badly crafted code. It should allow it unless there is syntax errors. All warnings, like unused temps, use of unassigned temps etc, should pop-up in a list pane below the code pane, so user could see it and react, or just ignore and go & do something else. Btw, this pane could be reused for more deeper/complex code analyzing tools, like lint etc. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 12, 2009

Re: [Pharo-project] Problems with MC (was Re: May be some problems with MC history)

by StÃ©phane Ducasse

On Sep 12, 2009, at 8:51 PM, Michael Roberts wrote: > Stef, we need the changes to MCPackageLoader>>basicLoad from Squeak > trunk. It does a lot more to ensure correct loading of classes and > methods. Our version assumes all additions are the same, both new > methods and changes to existing methods. it's this assumption that > causes the blow up of loading a (pharo compatible) Kernel-eem.242. I > have tested that our version definitely can't load the closure fixes. > > I will start pulling MC changes in and see how it goes. You already > started a review of Pharo version of MC? Oh yes! This is why I started. I missed the changes in 3.10 this is why originally I said that there were no change changing the semantics. So what is left on my plate is 309 and 321. I will send them to you in a minute as cs so that you can try. Stef

Sept. 12, 2009

Re: [Pharo-project] getting rid of these boring questions and popup

by StÃ©phane Ducasse

> In past ESUG media (presentation slides) i saw and briliant example of > enchancing Shout (or paragraph editor) with interactive icons. Is this > work incomplete or it can be observed? In presentation it was named > OBEnchancments, but i didnt saw any of this features in Squeak or > Pharo. I do not know. Now what you have with OB (since lukas push the idea there), is that you can use the icons to navigate the class hierarchy and laucnh tests and others.

Sept. 12, 2009

Re: [Pharo-project] getting rid of these boring questions and popup

by StÃ©phane Ducasse

On Sep 12, 2009, at 7:39 PM, Schwab,Wilhelm K wrote: > Stef, > > I'm all for trying things like this, but have my reservation about > replacing a good text editor; adding alternatives is fine, of course. paragraphEditor is not inline with what we coudl expect from a paragraphEditor nowadays. Now building one is far from easy. > > Are you going to be in Orlando for OOPSLA? No > I do not have funding to register, but live close enough that it > would be a shame not to meet up on a free evening for you. Not only > would I enjoy meeting you and others, but I would like to give you a > brief tour of Dolphin's IDE (such as its definition/code/comment > panes) and a few goodies that I have found helpful. There are some > simple changes we could make that would greatly enhance the > usability of the browsers and other tools. Events or announcements > added to the tools would enable extensions like those that can be > very effective in the Dolphin IDE. I would welcome an opportunity > to demonstrate some simple changes that would help us. what you could do is a video :) Stef > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of StÃ©phane Ducasse > Sent: Saturday, September 12, 2009 12:03 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] getting rid of these boring questions > and popup > > I agree. :) > I would love to have that. > this is why we should really have a system to experiment these ideas. > > Stef > > On Sep 12, 2009, at 6:15 PM, Philippe Marschall wrote: > >> StÃ©phane Ducasse wrote: >>> well for this we will have to rewrite paragraphEditor :) So in >>> making >>> pharo moves forward we will have to accept losing some feedback. >> >> The feedback is still there. The piece of code is still marked as a >> problem. It just doesn't get in your way. >> >>> But yes your idea is cool. >> >> You'll have to do more than that. I think this whole 80ies style >> browser that's based on scrolling, clicking and popups doesn't cut it >> anymore and adding more tabs and buttons isn't gonna fix it. >> >> Example, why is the browser the size it currently is? Because that >> was >> more or less full screen in the 80ies. Consequence you'll always have >> to resize and scroll when you open a browser because the category and >> class panes are too small. I see how this was cool, exciting and new >> in the 80ies but today it gets in my way. >> >> Example, I want to go to a method in a class. Either I click '-- >> all--' >> and scroll, scroll, look, scroll, scroll back or I click through the >> protocols until I found on it. When I'm in Eclipse and want to open a >> variable or method declaration I hit Ctrl + O, Eclipse shows me a >> short outline of the class. Like in Firefox Awesome Bar it filters >> the >> list as I type part of the name. Once I select something it closes >> and >> goes there. Zero mouse activity. Zero additional window. When I'm >> in a >> method and want to go to a method invoked there either I Ctrl + click >> it or I hit F3. When I want to see the hierarchy of a class or the >> inheritance of a method I just do Ctrl + T and an inline window >> opens. >> It closes when I select something or hit Esc. Pharo stacks so many >> windows on top of each other that you're never going to find your way >> back. So at the end of the day you just close dozens of windows. >> >> Short anecdote, I our current project we don't ask the user for >> confirmation, ever. If he decides to delete Migros, we do it without >> asking. The previous version of the product did but users just >> developed a reflex to click popups away without even reading them. >> >> And don't get me started on breakpoints. Or blocking the UI. >> >> Cheers >> Philippe >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2009

Re: [Pharo-project] Graphics-Centric UI Capability?

by Igor Stasenko

Oops sorry for the dumb post.. (im using my friend laptop and not very handy with keyboard) There is a generic morph, which made specially for scrolling views which not fit fully within display. ScrollPaneMorph or ScrollableMorph (don't remember exactly) the purpose of this morph is provide a scrollers , while you can embed any view within it, having any dimensions and which can be controlled/changed dynamically. 2009/9/12 Igor Stasenko <siguctua(a)gmail.com>: > t > > 2009/9/12 Â <dmurphy(a)infratecture.com>: >> hello all, > >> i have been nabbling about the list archives, trying to figure out the right >> class to use for providing a scrolling graph pane on which i can draw >> shapes. >> >> suppose i were to take UITheme(class)>>exampleWindowWithToolbars and want to >> turn that into a simple Paint Program. >> >> what would i put in place of the >> StandardWindow>>newTextEditorFor:getText:setText:getEnabled: message send? >> >> are there any simple Paint Program examples i start with? >> >> thanks for any pointers! >> >> delbert >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Sept. 12, 2009

Re: [Pharo-project] Graphics-Centric UI Capability?

by Igor Stasenko

t 2009/9/12 <dmurphy(a)infratecture.com>: > hello all, > > i have been nabbling about the list archives, trying to figure out the right > class to use for providing a scrolling graph pane on which i can draw > shapes. > > suppose i were to take UITheme(class)>>exampleWindowWithToolbars and want to > turn that into a simple Paint Program. > > what would i put in place of the > StandardWindow>>newTextEditorFor:getText:setText:getEnabled: message send? > > are there any simple Paint Program examples i start with? > > thanks for any pointers! > > delbert > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 12, 2009

[Pharo-project] Problems with MC (was Re: May be some problems with MC history)

by Michael Roberts

Stef, we need the changes to MCPackageLoader>>basicLoad from Squeak trunk. It does a lot more to ensure correct loading of classes and methods. Our version assumes all additions are the same, both new methods and changes to existing methods. it's this assumption that causes the blow up of loading a (pharo compatible) Kernel-eem.242. I have tested that our version definitely can't load the closure fixes. I will start pulling MC changes in and see how it goes. You already started a review of Pharo version of MC? thanks, Mike On Sat, Sep 12, 2009 at 4:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks dave. > So far I found my way (but I will have a look) and I'm reading > carefully the code to see > the implication for the loading of the closure fixes. > > Stef > > On Sep 12, 2009, at 3:45 PM, David T. Lewis wrote: > >> On Fri, Sep 11, 2009 at 01:48:45PM +0200, Lukas Renggli wrote: >>>> a couple of bugs when understanding the history based merge (ugly) >>> >>> It is not a merge operation, as I said in my mail. You are merely >>> applying the changes representing a delta between two versions >>> manually. That's all, no magic involved. >>> >>>> ? ? ? ?- adding the new method to a cs does not work if you did >>>> not install >>>> the code before (ok) >>>> ? ? ? ?- class definition are not added (yeah) in the changeset. >>>> Really cool! >>> >>> I don't understand what this has to do with change-sets? >>> >>> Class definitions are part of the patch that is calculated by >>> Monticello. My guess is that the class didn't change for the delta >>> you >>> calculated. To illustrate, in the example above the changes between >>> b.1 and b.2 don't show a class change that happened between a.1 and >>> b.1, even if the delta depends on it. >>> >>> I use what I described all the time, it is maybe a bit tricky, but >>> works really well. >> >> Stef, >> >> I don't know if this is helpful or not, but FYI Edgar De Cleene has >> produced the list of change sets corresponding to the MC update stream >> for Squeak trunk. See this thread on squeak-dev: >> >> Â http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-September/13936… >> >> Dave >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 12, 2009

Re: [Pharo-project] getting rid of these boring questions and popup

by Andrey Larionov

In past ESUG media (presentation slides) i saw and briliant example of enchancing Shout (or paragraph editor) with interactive icons. Is this work incomplete or it can be observed? In presentation it was named OBEnchancments, but i didnt saw any of this features in Squeak or Pharo. On Sat, Sep 12, 2009 at 21:02, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I agree. :) > I would love to have that. > this is why we should really have a system to experiment these ideas. > > Stef > > On Sep 12, 2009, at 6:15 PM, Philippe Marschall wrote: > >> StÃ©phane Ducasse wrote: >>> well for this we will have to rewrite paragraphEditor :) >>> So in making pharo moves forward we will have to accept losing some >>> feedback. >> >> The feedback is still there. The piece of code is still marked as a >> problem. It just doesn't get in your way. >> >>> But yes your idea is cool. >> >> You'll have to do more than that. I think this whole 80ies style >> browser >> that's based on scrolling, clicking and popups doesn't cut it anymore >> and adding more tabs and buttons isn't gonna fix it. >> >> Example, why is the browser the size it currently is? Because that was >> more or less full screen in the 80ies. Consequence you'll always >> have to >> resize and scroll when you open a browser because the category and >> class >> panes are too small. I see how this was cool, exciting and new in the >> 80ies but today it gets in my way. >> >> Example, I want to go to a method in a class. Either I click '--all--' >> and scroll, scroll, look, scroll, scroll back or I click through the >> protocols until I found on it. When I'm in Eclipse and want to open a >> variable or method declaration I hit Ctrl + O, Eclipse shows me a >> short >> outline of the class. Like in Firefox Awesome Bar it filters the >> list as >> I type part of the name. Once I select something it closes and goes >> there. Zero mouse activity. Zero additional window. When I'm in a >> method >> and want to go to a method invoked there either I Ctrl + click it or I >> hit F3. When I want to see the hierarchy of a class or the inheritance >> of a method I just do Ctrl + T and an inline window opens. It closes >> when I select something or hit Esc. Pharo stacks so many windows on >> top >> of each other that you're never going to find your way back. So at the >> end of the day you just close dozens of windows. >> >> Short anecdote, I our current project we don't ask the user for >> confirmation, ever. If he decides to delete Migros, we do it without >> asking. The previous version of the product did but users just >> developed >> a reflex to click popups away without even reading them. >> >> And don't get me started on breakpoints. Or blocking the UI. >> >> Cheers >> Philippe >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 12, 2009