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

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

by Schwab,Wilhelm K

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] 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.

June 18, 2009

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

by David Mitchell

1. +1 Direct to debug sounds good to me. Notifier window was for low power (in the 1980s). Don't care if it is a preference. Would prefer fewer preferences, but I can't bring myself to add a preference for it... 2. +1 Big Debugger. 3. -1 I work top-down as well and I still like the typo correction that comes from this step. 4. +1 Wish shortcuts weren't pane specific. 5. ? 6. ? 7. +1 2009/6/18 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > 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 18, 2009

Re: [Pharo-project] Can not make the right mouse button work

by Hernan Wilkinson

Something is wrong with the right mouse button... It started to work as expected after using the image for some time and then it stop working (I had to press the wheel instead of the right button)... Does anybody have the same problem? 2009/6/18 Mariano Martinez Peck <marianopeck(a)gmail.com> > See this thread: > http://n2.nabble.com/swapMouseButtons-doesn%27t-work-td3039209.html#a3039209 > > > 2009/6/17 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > >> I should have said that I'm using Ubuntu...(When I copy the image to a >> windows system, after some time, yes some time, it started to work...) >> >> 2009/6/17 Nicolas Chillo <nchillo(a)gmail.com> >> >> Take a look at the VM Mouse Mapping attributes (In windows> right click in >>> the squeak icon from taskbar). >>> Activate the 3 Buttons mouse and it should work. >>> >>> Nicolas >>> >>> >>> 2009/6/17 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> >>> >>>> Hi, in the latest image I can not make the right mouse button work.... >>>> Preferences swapMouseButtons returns false as in the previous image >>>> that worked... any idea? >>>> >>>> Thanks, >>>> 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 >>> >> >> >> _______________________________________________ >> 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 18, 2009

[Pharo-project] Making pharo more tdd oriented

by Hernan Wilkinson

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.

June 18, 2009

[Pharo-project] NewInspector

by Alexandre Bergel

Hi! When I right-click in the workspace panel of a newinspector I get a rollback 'The getMenuSelector must be a 1- or 2-keyword symbol' Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 18, 2009

Re: [Pharo-project] Automatic/periodic image saves

by Schwab,Wilhelm K

John, Which OS are you using? How long has it been up? I am *very* interested in your experience with it, because I am starting to take a similar path; **please** keep us posted on performance/reliability. Nice work, and good luck with it! Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Thornborrow Sent: Wednesday, June 17, 2009 5:12 AM To: Pharo Development Subject: [Pharo-project] Automatic/periodic image saves Hi, We've deployed a Pharo+Pier/Seaside image for our website, and (naturally) changes are made to the site via Pier. I'd like to know if there is a preferred method of saving the image to disk every, say, 12 hours? Many thanks, John. www.pinesoft.co.uk

June 18, 2009

[Pharo-project] #print:, #printOn: but without the quotes

by Schwab,Wilhelm K

Hello all, As far back as I can remember, Dolphin has distinguished between printing and displaying - results of the former are intended for consupmption by developers, the latter is for the benefit of the end user. Dolphin reserves #display:, #displayOn: for end-user-friendly behavior. The _apparent_ (maybe I'm just missing something) absense of this distinction in Squeak/Pharo really bit me in my recent effort to leverage Citezen for my evolving Seaside app. At one point, every pass through an edit feature added a set of quotes to various fields :( I realize that one can simly use #nextPutAll: for strings to avoid the quotes, but there is no polymorphic/intention-revealing alternative for the #displayOn: is taken by Morphic, something I noticed years ago to my great disappointment. To hack around the problem, I added #printForUser: and #printForUserOn:. Is there already an accepted idiom for this? If not, I would strongly suggest adding one; I like the Dolphin selectors, but the collision with Morphic probably favors sometihng along the lines of #printForUser:. What do you think? Bill

June 18, 2009

Re: [Pharo-project] BlockContextTest

by Marcus Denker

On 17.06.2009, at 21:02, Gabriel Cotelli wrote: > This is the list of methods missing in BlockClosure but covered by > the BlockContextTest: > â¢ copyStack > â¢ bottomContext > â¢ findContextSuchThat: > â¢ tempNamed: > â¢ tempNamed:put: > I don't known if has sense to implement that... > No, I don't think so. These are all related to the stack (thisContext), which used to be the same as the Block: before closures, this was true: (block := [thisContext]) value == block this means, the block object was identical to the context of the block. This is not the case anymore. The expression is false, and the context of the block [thisContext] value class is now a methodcontext, not a blockcontext, nor a bockclosure. The object representing blocks is not a context anymore, but a container that holds the values of the state that is local to the block. Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

June 18, 2009

Re: [Pharo-project] Can not make the right mouse button work

by Mariano Martinez Peck

See this thread: http://n2.nabble.com/swapMouseButtons-doesn%27t-work-td3039209.html#a3039209 2009/6/17 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > I should have said that I'm using Ubuntu...(When I copy the image to a > windows system, after some time, yes some time, it started to work...) > > 2009/6/17 Nicolas Chillo <nchillo(a)gmail.com> > > Take a look at the VM Mouse Mapping attributes (In windows> right click in >> the squeak icon from taskbar). >> Activate the 3 Buttons mouse and it should work. >> >> Nicolas >> >> >> 2009/6/17 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> >> >>> Hi, in the latest image I can not make the right mouse button work.... >>> Preferences swapMouseButtons returns false as in the previous image that >>> worked... any idea? >>> >>> Thanks, >>> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 18, 2009

Re: [Pharo-project] [ANN] MouseOverHandler refactoring

by Henrik Johansen

Got the problem yesterday, after some investigating: - senders of Project >> spawnNewProcessIfThisIsUI: suspendedProcess usually do not suspend the suspendedProcess parameter until later in the methods. (most of these are Debugger opening methods) It seems to me that for a short time in these methods, 2 UI processes can actually be active (But telling the same world to update). Thus, if one exits MouseOverHandler >> processMouseOver: while the other is in it (which resets leftMorphs to nil), could cause the described case to happen. Would be nice if someone familiar with Squeak threading model could confirm/disprove my theory :) Cheers, Henry On Jun 15, 2009, at 8:08 58PM, Gary Chambers wrote: > Which, of course, doesn't get to the bottom of the original problem. > That being, why there would be multiple processes (rather than just > UI process) modifying any Morph state... > > Regards, Gary > ----- Original Message ----- > From: Hernan Wilkinson > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Monday, June 15, 2009 6:51 PM > Subject: Re: [Pharo-project] [ANN] MouseOverHandler refactoring > > Done, issue 889 > > On Sat, Jun 13, 2009 at 5:48 AM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > > On Jun 13, 2009, at 01:59 , Hernan Wilkinson wrote: > > > ups! you are write!! sorry about that, I realize I did not put the > > name of > > the file :-)The file name is: Morphic-HernanWilkinson.327.mcz > > > > About the issue tracker, the error that Stef point me to is > > http://code.google.com/p/pharo/issues/detail?id=86 in his mail > > http://lists.gforge.inria.fr/pipermail/pharo-project/2009-June/009517.html > > but > > the description does not macth with the error I also fix. > > Do you think I should open a new defect? > > Yes, I think that would be best. > > Cheers, > Adrian > > > > > On Fri, Jun 12, 2009 at 5:37 PM, Adrian Lienhard <adi(a)netstyle.ch> > > wrote: > > > >> Hi Hernan, > >> > >> On Jun 12, 2009, at 21:55 , Hernan Wilkinson wrote: > >> > >>> I uploaded to the pharo inbox repository... is that right? > >> > >> Yes. But additionally it would be good to note which file(s) you > >> uploaded in the issue tracker. Like this we can track changes. If > no > >> report exists yet, just create a new one. > >> > >> Thanks, > >> Adrian > >> > >>> The only way to > >>> test it that I found of is just to install it and play with the > >>> mouse... if > >>> you do not have a debugger, it means it is working :-) > >>> > >>> On Fri, Jun 12, 2009 at 2:47 PM, Damien Cassou <damien.cassou(a)gmail.com > >>>> wrote: > >>> > >>>> 2009/6/12 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > >>>>> Hope you like it. > >>>> > >>>> Where can we find it? > >>>> How to test it? > >>>> > >>>> > >>>> -- > >>>> Damien Cassou > >>>> http://damiencassou.seasidehosting.st > >>>> > >>>> "Lambdas are relegated to relative obscurity until Java makes > them > >>>> popular by not having them." James Iry > >>>> > >>>> _______________________________________________ > >>>> 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 18, 2009