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

Re: [Pharo-project] Making pharo more tdd oriented

by Schwab,Wilhelm K

Hernan, A separate command in the debugger sounds like a great idea; that way it is accessible with none of the down side of prompting. There probably is a trail that I can find on OA's reaction to bypassing notifiers. IIRC, they were getting a lot of pressure to allow the option, added it, and almost immediately said "it's available - use at your own risk." The recursive situations involve another error triggered either by failing to clear some condition or simply by shaking up the display by moving windows around as the notifier/debugger opens. IMHO, any prayer of breaking out depends on having the lightweight notifiers vs. full debuggers trying to open. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Hernan Wilkinson Sent: Friday, June 19, 2009 12:32 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Making pharo more tdd oriented Hi Bill, thank you for your answer! There is no performance penalty on the OB. I'll think I'll add a button to the debugger to define the method. Same behavior as now but instead of going to the stack menu, just a button, much more faster. About the notifier, why did Object Arts went back? Are there any mail/info related? And I do not understand the recursive problem you mention, the debugger stops the process, why would it be different from a notifier? Bye, Hernan. 2009/6/18 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> Hernan, (1) going straight to a debugger is a really bad idea. Object Arts tried it, and promptly spoke out against it. If you want the option to skip the notifier, fine, but I want to the option to keep the buffer of the notifier. Imagine a recursive meltdown, and then make it an order of magnitude or two worse because every mention of the problem is a full debugger instead of a notifier. You've been warned :) (2) +1, maybe 2 (3) +3 :) Those prompts are seriously annoying. I even have places in my code that look like uninitializeTemp := uninitializeTemp. just to gag the "is it ok to remove xyz". It arises when I capture something in a temp knowing that I will need it later but have not coded that far yet. Not quite TTD, but not all that different. (4-5) options are generally good things. (6) Is there any impact on performance? OB is too slow as it is. Otherwise it's probably fine. (7) I'm not a big fan of the default action concept, but this is probably a good use. That said, I would probably not want to use it, and would ask that you make it optional. From a system stability standpoint, I am a little nervous about having an error invoke the GUI, especially if the tests make use of #fork: etc. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Hernan Wilkinson Sent: Thursday, June 18, 2009 4:09 PM To: pharo-project(a)lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr> Subject: [Pharo-project] Making pharo more tdd oriented Hi, I have made some changes to pharo to make it more tdd oriented. I want to share them with you to know your opinion and then make the code public. The changes I made are: 1) When there is an error, the debugger opens directly. Reason: I found that I always press Debug when an error occurs in the Notifier window. Question: Should this option be a preference? 2) The debugger opens in a big window. Reason: I always want to debug! and I want to see as much as possible when debugging. Before I found myself making the debugger window bigger all the time 3) When compiling a method that sends a message not defined, it does not ask anymore if I want to change it. Reason: When doing TDD we work top-down, so we are always sending messages that are not defined and that we are going to define when running the test. Question: Should this option be a preference? 4) I added an option to save and run the test from the code pane of the omni browser (ctr+t). If the test fails, opens a debugger to fix it. Reason: It is very handful 5) I added an option to save and step a test from the code pane of the omni browser (ctrl+r). Reason: It is very handful (Problem: The debugger does not work well with breakpoints...) 6) I added a debugCase: message to TestResult and make some changes to the omni browser to show the result of debugging a test. Reason: Before, when debugging a test the browser was showing the test as not runned. 7) When running a test, the defualtAction of the MessageNotUndertood exception will ask you if you want to implement the method (if the receiver is not nil) so you don't have to select that option from the debugger stack list menu. Reason: When running a test 95% of the time a message not understood will be implemented and answering yes or no is easier that going to the stack menu of the debugger to select the option implement. What do you think? Comments welcome. Bye, Hernan. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 19, 2009

Re: [Pharo-project] Making GUI'S

by Alexandre Bergel

I do not understand where're lost. With Polymorph, with Smalltalk? Open a workspace, cut and paste one of the line below, select, right click and doIt. Alexandre On 19 Jun 2009, at 15:01, Juan Pablo Cook wrote: > Thanks a lot, but I'm a bit lost in pharo... Could you make a little > example? Thanks a lot > > On Fri, Jun 19, 2009 at 3:36 PM, Alexandre Bergel > <alexandre(a)bergel.eu> wrote: > Hi Juan, > > Try : > UITheme exampleColorControls > UITheme exampleBasicControls > UITheme exampleGroups > UITheme exampleOtherControls > UITheme exampleWindowWithToolbars > > The code to create these widget is there. > > Alexandre > > > > On 19 Jun 2009, at 14:32, Juan Pablo Cook wrote: > > > Hi Everybody! Today I found this smalltalk IDE, and I have recently > > installed. I used to use VisualWorks. > > I like the general interface of this framework. What I want to know > > is where I make a "new Canvas"? or a GUI Window? There is a palette > > with widgets and these things? Thanks a lot, I've been finding a > > free IDE to develop in Smalltalk. > > > > Thanks a lot > > > > JP Cook - Argentina > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 19, 2009

Re: [Pharo-project] Making GUI'S

by Juan Pablo Cook

Thanks a lot, but I'm a bit lost in pharo... Could you make a little example? Thanks a lot On Fri, Jun 19, 2009 at 3:36 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Hi Juan, > > Try : > UITheme exampleColorControls > UITheme exampleBasicControls > UITheme exampleGroups > UITheme exampleOtherControls > UITheme exampleWindowWithToolbars > > The code to create these widget is there. > > Alexandre > > > > On 19 Jun 2009, at 14:32, Juan Pablo Cook wrote: > > > Hi Everybody! Today I found this smalltalk IDE, and I have recently > > installed. I used to use VisualWorks. > > I like the general interface of this framework. What I want to know > > is where I make a "new Canvas"? or a GUI Window? There is a palette > > with widgets and these things? Thanks a lot, I've been finding a > > free IDE to develop in Smalltalk. > > > > Thanks a lot > > > > JP Cook - Argentina > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 19, 2009

Re: [Pharo-project] Making pharo more tdd oriented

by Hernan Wilkinson

On Fri, Jun 19, 2009 at 7:32 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > I should say that I hate the popups "do you want to do that or remove > this variable but wait it is assigned tooo." > > May be we should have a menu > clean code! > but for now let is accept it I agree with that. When coding I do not pay to much attention to those things because after I'm done (or I thing the code is stable enough) I run SmallLint to fix all those things.... When I'm coding I want to be as fast as possible... of course, not everybody has to agree with this. > > > > Hi, > > I have made some changes to pharo to make it more tdd oriented. I > > want to share them with you to know your opinion and then make the > > code public. > > The changes I made are: > > > > 1) When there is an error, the debugger opens directly. Reason: I > > found that I always press Debug when an error occurs in the Notifier > > window. Question: Should this option be a preference? > > I'm not sure in fact because when you are not in TDD you just often > close the predebug. > but we could change. But what is the difference with closing the debugger? I worked with VisualAge that does not have the notifier and now with pharo/squeak I feel the notifier bothers me... > > > > 2) The debugger opens in a big window. Reason: I always want to > > debug! and I want to see as much as possible when debugging. Before > > I found myself making the debugger window bigger all the time > > larger but not to big :) > > > 3) When compiling a method that sends a message not defined, it does > > not ask anymore if I want to change it. Reason: When doing TDD we > > work top-down, so we are always sending messages that are not > > defined and that we are going to define when running the test. > > Question: Should this option be a preference? > > No preference. Now if the system could guess typos :) > > > > 4) I added an option to save and run the test from the code pane of > > the omni browser (ctr+t). If the test fails, opens a debugger to fix > > it. Reason: It is very handful > > Yes right now when you do alt-t you run the test but you cannot get a > debugger on them. Yes, but alt-t is if the focus is on the method list (or category list or class list or package list). The option I added is when the focus is in the code panel > I would love to > click to run the tests > get a small widgets with the result of the execution and that I can > rerun or get a debugger on the tests. I did this: 1) you write the test 2) when done, press ctr+t (I could not make alt+t) work... 3) It will not ask you for bad selectors (your are doing tdd, so you are sending messages that are not implemented) 4) It will save the method 5) Run the test. If it runs ok, the green button will appear on the method list 6) If it fails or err, the yellow/red button will appear on the method list and the debugger will open 7) If you fix the error, go to 3 :-). I think it is very helpful and agile. If you want to steep the test, just press ctrl+r > > > > 7) When running a test, the defualtAction of the MessageNotUndertood > > exception will ask you if you want to implement the method (if the > > receiver is not nil) so you don't have to select that option from > > the debugger stack list menu. Reason: When running a test 95% of the > > time a message not understood will be implemented and answering yes > > or no is easier that going to the stack menu of the debugger to > > select the option implement. > > in Squeak we could show the class and its superclass. Yes, but I found that I always implement the method in the class not in any of it superclasses... Anyway, I know it is not easy to satisfy everybody... I'll publish the code in squeak source so everybody can try it and give me feedback and make it better. Bye, Hernan. > > > > > > What do you think? Comments welcome. > > Bye, > > Hernan. > > > > > > > > > > _______________________________________________ > > 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 >

June 19, 2009

Re: [Pharo-project] Making GUI'S

by Alexandre Bergel

Hi Juan, Try : UITheme exampleColorControls UITheme exampleBasicControls UITheme exampleGroups UITheme exampleOtherControls UITheme exampleWindowWithToolbars The code to create these widget is there. Alexandre On 19 Jun 2009, at 14:32, Juan Pablo Cook wrote: > Hi Everybody! Today I found this smalltalk IDE, and I have recently > installed. I used to use VisualWorks. > I like the general interface of this framework. What I want to know > is where I make a "new Canvas"? or a GUI Window? There is a palette > with widgets and these things? Thanks a lot, I've been finding a > free IDE to develop in Smalltalk. > > Thanks a lot > > JP Cook - Argentina > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 19, 2009

[Pharo-project] Making GUI'S

by Juan Pablo Cook

Hi Everybody! Today I found this smalltalk IDE, and I have recently installed. I used to use VisualWorks. I like the general interface of this framework. What I want to know is where I make a "new Canvas"? or a GUI Window? There is a palette with widgets and these things? Thanks a lot, I've been finding a free IDE to develop in Smalltalk. Thanks a lot JP Cook - Argentina

June 19, 2009

[Pharo-project] Strange bug...

by StÃ©phane Ducasse

Hi guys Even if ObjectTracer may be broken when we evaluate (ObjectTracer on: Display) flash: (50@50 extent: 50@50) and try to understand the problem in the debugger, I get only decompileCode then when I navigate the stack I have even syntax error.... Stef

June 19, 2009

Re: [Pharo-project] Making pharo more tdd oriented

by Hernan Wilkinson

Hi Bill, thank you for your answer! There is no performance penalty on the OB. I'll think I'll add a button to the debugger to define the method. Same behavior as now but instead of going to the stack menu, just a button, much more faster. About the notifier, why did Object Arts went back? Are there any mail/info related? And I do not understand the recursive problem you mention, the debugger stops the process, why would it be different from a notifier? Bye, Hernan. 2009/6/18 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > Hernan, > > (1) going straight to a debugger is a really bad idea. Object Arts tried > it, and promptly spoke out against it. If you want the option to skip the > notifier, fine, but I want to the option to keep the buffer of the > notifier. Imagine a recursive meltdown, and then make it an order of > magnitude or two worse because every mention of the problem is a full > debugger instead of a notifier. You've been warned :) > > (2) +1, maybe 2 > (3) +3 :) Those prompts are seriously annoying. I even have places in my > code that look like > > uninitializeTemp := uninitializeTemp. > > just to gag the "is it ok to remove xyz". It arises when I capture > something in a temp knowing that I will need it later but have not coded > that far yet. Not quite TTD, but not all that different. > > (4-5) options are generally good things. > > (6) Is there any impact on performance? OB is too slow as it is. > Otherwise it's probably fine. > > (7) I'm not a big fan of the default action concept, but this is probably a > good use. That said, I would probably not want to use it, and would ask > that you make it optional. From a system stability standpoint, I am a > little nervous about having an error invoke the GUI, especially if the tests > make use of #fork: etc. > > Bill > > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *On Behalf Of *Hernan > Wilkinson > *Sent:* Thursday, June 18, 2009 4:09 PM > *To:* pharo-project(a)lists.gforge.inria.fr > *Subject:* [Pharo-project] Making pharo more tdd oriented > > Hi, > I have made some changes to pharo to make it more tdd oriented. I want to > share them with you to know your opinion and then make the code public. > The changes I made are: > > 1) When there is an error, the debugger opens directly. Reason: I found > that I always press Debug when an error occurs in the Notifier window. > Question: Should this option be a preference? > 2) The debugger opens in a big window. Reason: I always want to debug! and > I want to see as much as possible when debugging. Before I found myself > making the debugger window bigger all the time > 3) When compiling a method that sends a message not defined, it does not > ask anymore if I want to change it. Reason: When doing TDD we work top-down, > so we are always sending messages that are not defined and that we are going > to define when running the test. Question: Should this option be a > preference? > 4) I added an option to save and run the test from the code pane of the > omni browser (ctr+t). If the test fails, opens a debugger to fix it. Reason: > It is very handful > 5) I added an option to save and step a test from the code pane of the omni > browser (ctrl+r). Reason: It is very handful (Problem: The debugger does not > work well with breakpoints...) > 6) I added a debugCase: message to TestResult and make some changes to the > omni browser to show the result of debugging a test. Reason: Before, when > debugging a test the browser was showing the test as not runned. > 7) When running a test, the defualtAction of the MessageNotUndertood > exception will ask you if you want to implement the method (if the receiver > is not nil) so you don't have to select that option from the debugger stack > list menu. Reason: When running a test 95% of the time a message not > understood will be implemented and answering yes or no is easier that going > to the stack menu of the debugger to select the option implement. > > What do you think? Comments welcome. > Bye, > Hernan. > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 19, 2009

Re: [Pharo-project] New Extensible Inspector for Pharo-Core

by Mariano Martinez Peck

I am agree. I have used it for a while and seems more useful than the original. 2009/6/19 Frederic Pluquet <fpluquet(a)ulb.ac.be> > It is obviously perfect for me :) > I'll try soon to write a webpage to explain how to personalize easily this > inspector (for personal needs). > > FrÃ©d > ---- > FrÃ©dÃ©ric Pluquet > UniversitÃ© Libre de Bruxelles (ULB) > Assistant > http://www.ulb.ac.be/di/fpluquet > > > On Fri, Jun 19, 2009 at 3:44 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> I was wondering if we could remove explorer and viewexplorer and >> replace them by your inspector? >> Waht the people think? >> >> Stef >> >> On Jun 19, 2009, at 1:39 PM, Frederic Pluquet wrote: >> >> > It's done in the last version. >> > >> > Thanks for feedback :) >> > >> > FrÃ©d >> > ---- >> > FrÃ©dÃ©ric Pluquet >> > UniversitÃ© Libre de Bruxelles (ULB) >> > Assistant >> > http://www.ulb.ac.be/di/fpluquet >> > >> > >> > 2009/6/10 Antoine Marot <amarot(a)ulb.ac.be> >> > I would like to have a collection of the children to see them quickly. >> > >> > I think unfolding is only interesting to inspect a particular >> > children. When I click on Methods or Implementors, I expect to see >> > them rather than the object from which they are derived. >> > >> > >> > Le 10-juin-09 Ã 12:09, Frederic Pluquet a Ã©crit : >> > >> >> Yes because I wanted that :-) What do you propose to describe ? >> >> Always the children ? >> >> >> >> FrÃ©d >> >> ---- >> >> FrÃ©dÃ©ric Pluquet >> >> UniversitÃ© Libre de Bruxelles (ULB) >> >> Assistant >> >> http://www.ulb.ac.be/di/fpluquet >> >> >> >> >> >> 2009/6/10 Antoine Marot <amarot(a)ulb.ac.be> >> >> It happens as well for Implementors, Elements, ... >> >> >> >> >> >> Le 10-juin-09 Ã 11:59, Antoine Marot a Ã©crit : >> >> >> >>> When I click on "Methods", the item displayed on the right is not >> >>> the method dictionary but the parent object. >> >>> >> >>> Could you check that ? >> >>> >> >>> >> >>> Antoine >> >>> >> >>> Le 10-juin-09 Ã 10:49, Frederic Pluquet a Ã©crit : >> >>> >> >>>> I commited a new version of NewInspector, with new feartures : >> >>>> >> >>>> - add progress bar indicator when long collections are inspected >> >>>> (no freeze feeling) >> >>>> - limit the description string of collections to 5000 >> >>>> characters(speed) >> >>>> - add inst vars as direct children of an object (accessibility >> >>>> and speed) >> >>>> - children of first inspected object opened by default >> >>>> (accessibility and speed) >> >>>> >> >>>> Thanks for your feedback ! >> >>>> >> >>>> FrÃ©d >> >>>> ---- >> >>>> FrÃ©dÃ©ric Pluquet >> >>>> UniversitÃ© Libre de Bruxelles (ULB) >> >>>> Assistant >> >>>> http://www.ulb.ac.be/di/fpluquet >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> 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 >> >> >> >> _______________________________________________ >> >> 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 >> >> >> _______________________________________________ >> 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 >

June 19, 2009

Re: [Pharo-project] Monticello merge tool fail - need strikethrough fordeleted code - be friendly to red-green colour blind people!

by Gary Chambers

After some investigation the "standard" diff stuff had the colours/font changed by Damien Pollet late last year... As for the Polymorph diff views, could be tricky (especially with regards for printing since not just text). The colours used in the DiffMorphs could be made configurable, however. Regards, Gary ----- Original Message ----- From: "Oscar Nierstrasz" <oscar(a)iam.unibe.ch> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, June 18, 2009 9:02 AM Subject: [Pharo-project] Monticello merge tool fail - need strikethrough fordeleted code - be friendly to red-green colour blind people! > > Hi Folks, > > While updating the Monticello chapter of Pharo By Example to the > current Pharo GUI, I discovered that diffs in the merge tool (and > elsewhere) no longer show deleted code struck through, but only in > red, with new code in green. > > This is a major fail for colour blind people! It also does not show > when printed in grey-scale. > > Can we have the strike-through back? It is an important visual cue. > > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 19, 2009