- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Problem with the OB debugger

by StÃ©phane Ducasse

I do not really know but they took the latest version of pharo-dev that was available the 13th (the first day oft the lecture). stef On Feb 20, 2009, at 8:24 PM, Dale Henrichs wrote: > Hmmm, > > Do you have a version on OB-Tools? I tested with OB-Tools-EL.60. > > Dale > > ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: > > | StÃ©phane, > | > | What did the method look like? I just tried putting halts into a > | method and was able to proceed and step across the second halt. > | > | Dale > | > | ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > | > | | Hi > | | > | | today I was giving lectures with the pahro-dev image and its OB- > | | debugger ad I noticed that > | | I could not have two halts else after proceeding the first one I > got > | a > | | > | | resume I do not what > | | and I could not see the other halt. > | | Is it only me? > | | > | | Stef > | | > | | _______________________________________________ > | | 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 >

Feb. 20, 2009

Re: [Pharo-project] Problem with the OB debugger

by StÃ©phane Ducasse

I do not have it. It was on two students code. So I'm sure that this is something that we can repeat because two of them got this behavior. When I run the tests and put halt in different methods I never succeeded to get to the second one. I had to remove the first halt. Else I got a resume I do not remember what. I could try to redo it. On Feb 20, 2009, at 8:22 PM, Dale Henrichs wrote: > StÃ©phane, > > What did the method look like? I just tried putting halts into a > method and was able to proceed and step across the second halt. > > Dale > > ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > > | Hi > | > | today I was giving lectures with the pahro-dev image and its OB- > | debugger ad I noticed that > | I could not have two halts else after proceeding the first one I > got a > | > | resume I do not what > | and I could not see the other halt. > | Is it only me? > | > | Stef > | > | _______________________________________________ > | 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 >

Feb. 20, 2009

[Pharo-project] [update] #10240

by Marcus Denker

#10240 ------- Issue 588: remove Object>>#isTransparent Issue 589: Project switching gives DNU Issue 592: add Unix epoch creation/conversion methods to DateAndTime Issue 593: fix seaside29 loading script Issue 590: fix some methods for newcompiler (. after method name) Issue 587: String >> #asCharacter documentation out of sync -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Feb. 20, 2009

Re: [Pharo-project] Problem with the OB debugger

by Dale Henrichs

Hmmm, Do you have a version on OB-Tools? I tested with OB-Tools-EL.60. Dale ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | StÃ©phane, | | What did the method look like? I just tried putting halts into a | method and was able to proceed and step across the second halt. | | Dale | | ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | | | Hi | | | | today I was giving lectures with the pahro-dev image and its OB- | | debugger ad I noticed that | | I could not have two halts else after proceeding the first one I got | a | | | | resume I do not what | | and I could not see the other halt. | | Is it only me? | | | | Stef | | | | _______________________________________________ | | 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

Feb. 20, 2009

Re: [Pharo-project] Problem with the OB debugger

by Dale Henrichs

StÃ©phane, What did the method look like? I just tried putting halts into a method and was able to proceed and step across the second halt. Dale ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | Hi | | today I was giving lectures with the pahro-dev image and its OB- | debugger ad I noticed that | I could not have two halts else after proceeding the first one I got a | | resume I do not what | and I could not see the other halt. | Is it only me? | | Stef | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 20, 2009

Re: [Pharo-project] Problem with the OB debugger

by Schwab,Wilhelm K

Stef, I had not, but (I think) just did and it worked as expected. See attached and let me know. 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: Friday, February 20, 2009 1:55 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Problem with the OB debugger did you tried in different methods? Stef On Feb 20, 2009, at 7:45 PM, Schwab,Wilhelm K wrote: > Stef, > > So far, it might be just you??? I tried the following in 10236 and > can proceed from the first halt (either on the notifier or in the full > debugger) and see the second. > > Have I matched your scenario? I've even tried going elsewhere in the > callstack and been ok. In fact, I would prefer the debugger to pick > an earlier frame in most (all?) situations; e.g. it selects the #halt > method rather than the sender, which is what Dolphin has lead me to > expect. > > Bill > > > > DoubleHale>>tryMe > > 2 + 3. > self halt. > 4+5. > self halt. > > " > DoubleHalt new tryMe. > " > > -----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: Friday, February 20, 2009 1:29 PM > To: Pharo Development > Subject: [Pharo-project] Problem with the OB debugger > > Hi > > today I was giving lectures with the pahro-dev image and its OB- > debugger ad I noticed that I could not have two halts else after > proceeding the first one I got a resume I do not what and I could not > see the other halt. > Is it only me? > > Stef > > _______________________________________________ > 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

Feb. 20, 2009

Re: [Pharo-project] Problem with the OB debugger

by StÃ©phane Ducasse

did you tried in different methods? Stef On Feb 20, 2009, at 7:45 PM, Schwab,Wilhelm K wrote: > Stef, > > So far, it might be just you??? I tried the following in 10236 and > can proceed from the first halt (either on the notifier or in the > full debugger) and see the second. > > Have I matched your scenario? I've even tried going elsewhere in > the callstack and been ok. In fact, I would prefer the debugger to > pick an earlier frame in most (all?) situations; e.g. it selects the > #halt method rather than the sender, which is what Dolphin has lead > me to expect. > > Bill > > > > DoubleHale>>tryMe > > 2 + 3. > self halt. > 4+5. > self halt. > > " > DoubleHalt new tryMe. > " > > -----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: Friday, February 20, 2009 1:29 PM > To: Pharo Development > Subject: [Pharo-project] Problem with the OB debugger > > Hi > > today I was giving lectures with the pahro-dev image and its OB- > debugger ad I noticed that > I could not have two halts else after proceeding the first one I got a > resume I do not what > and I could not see the other halt. > Is it only me? > > Stef > > _______________________________________________ > 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 >

Feb. 20, 2009

Re: [Pharo-project] Problem with the OB debugger

by Schwab,Wilhelm K

Stef, So far, it might be just you??? I tried the following in 10236 and can proceed from the first halt (either on the notifier or in the full debugger) and see the second. Have I matched your scenario? I've even tried going elsewhere in the callstack and been ok. In fact, I would prefer the debugger to pick an earlier frame in most (all?) situations; e.g. it selects the #halt method rather than the sender, which is what Dolphin has lead me to expect. Bill DoubleHale>>tryMe 2 + 3. self halt. 4+5. self halt. " DoubleHalt new tryMe. " -----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: Friday, February 20, 2009 1:29 PM To: Pharo Development Subject: [Pharo-project] Problem with the OB debugger Hi today I was giving lectures with the pahro-dev image and its OB- debugger ad I noticed that I could not have two halts else after proceeding the first one I got a resume I do not what and I could not see the other halt. Is it only me? Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 20, 2009

Re: [Pharo-project] Automatic focus on column upon moose enter

by StÃ©phane Ducasse

On Feb 20, 2009, at 6:26 PM, Gary Chambers wrote: > To be fair, there really isn't a well conceived command shortcut > framework > that works with the browsers/OB. > > Something to add to the list, perhaps a nice Summer of Code project. Yes if you mentor it I'm sure ESUG can finance one. > > > ParagraphEditor is the root of all evil to start with... yes > > > Nevetheless, a simple preference for the new OB behaviour will > settle the > argument for all in the meantime. Let's move on. OB is getting there > in > terms of look and feel now. > > Regards, Gary > > ----- Original Message ----- > From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Friday, February 20, 2009 5:00 PM > Subject: Re: [Pharo-project] Automatic focus on column upon moose > enter > > > David, > > Keyboard up/down are events that can be translated into commands, > and then > "fired" up the hierarchy. It's been done this way for a long time. > Very > few custom components are in actually needed. Think of it as another > incarnation (indeed literally in this case) of the old argument about > composition vs. inheritance. Inheritance is wonderful, but in this > case, it > can/should be avoided. Plugging code into the correct places in a > framework > will avoid the need for the customized list. That is not to say > that the OB > lists are not needed - I do not know enough about them. However, a > solid > event/command framework would be hard pressed not to do the same > thing, only > better. > > Commands serve a role somewhat like exceptions. The problem/need is > noticed > in one area, the message is put in the correct channel and reviewed > until > somebody knows what to do with it. The overhead is (Gary - disagree > if you > feel the need) not so severe as with exceptions because it is a much > more > focused task. > > As an example, control-t for tests: you might also want to fire the > same > command from menus. Doing what I advocate makes that trivial. > Dolphin does > a great job of this kind of thing, right down to enabling/disabling > commands > vs. individual widgets. > > This assumes that OB itself (as a top level component) take a role > in making > all of this work. But that's a good thing once you adapt to it. > > In response to an earlier comment you made: there is always another > way. > Commands are the preferred one here - trust me. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > David > RÃ¶thlisberger > Sent: Friday, February 20, 2009 11:25 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Automatic focus on column upon moose > enter > > Hi Bill, > >> Commands are a decoupling that allow the GUI to control how things >> get >> processed while allowing individual tools to control what happens >> when >> commands are processed. It's not direct, but it correct. > > I agree with you here. > But see, this change is not really about commands. Alex gave you an > example > where > this change is useful in the context of commands. But this was not the > motivating > example for me to do this change, I was not even aware that it could > also be > useful > in Alex' scenario involving commands. > The scenario I had in mind does not really employ commands at all, > but basic > keyboard > actions like key up, key down (see my first mail in this thread). > Maybe you > can look > at those as commands too, but the action they perform is certainly > dependent > on the > view in which they are meant to happen. > > So there is more behind this than just "easing" the execution of > commands. > > David > > >> ---- >> Wilhelm K. Schwab, Ph.D. >> bschwab AT anest DOT ufl DOT edu >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David >> RÃ¶thlisberger [squeak(a)webcitas.ch] >> Sent: Friday, February 20, 2009 10:33 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Automatic focus on column upon moose >> enter >> >> Hi Bill, >> >>> but your approach to it is not a small change: you are moving GUI >>> code >>> into the tools, which is bad practice. >> >> I do not really understand what you mean with "tools" here. >> I moved this code to the Morphic subclass we use to represent >> pluggable >> lists in OB >> (a subclass of PluggableListMorph), so this is the GUI code used in >> the >> tool and IMO >> the only place where I could possibly move this GUI code into, >> namely into >> other GUI >> code. ;) >> >>> Please let Gary help you do this properly. >> >> Gary actually suggested me to do it like this. As I said, it's >> really the >> only way to >> realize this change so that it only affects the columns in OB, >> trust me. >> >> To make the extent of the change clear: What it does is to give the >> columns in >> OB-based browsers the focus whenever the mouse is over them. This >> only >> affects >> columns, nothing else, in the OB browser, and certainly also no other >> browsers, >> tools, whatsoever not based on OB. >> >> The question that remains is just whether people want a pref to >> enable/disable this >> changed behavior or not, I think. >> I don't have the impression that we need to discuss the >> implementation of >> this change. >> >> I will answer separately to your other mail. >> >> >> David >> >>> ---- >>> Wilhelm K. Schwab, Ph.D. >>> bschwab AT anest DOT ufl DOT edu >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David >>> RÃ¶thlisberger [squeak(a)webcitas.ch] >>> Sent: Friday, February 20, 2009 9:17 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Automatic focus on column upon moose >>> enter >>> >>> Hi >>> >>>> First of all, I did not authored this change. David did it. I guess >>>> this was a request emanated by a bunch of people. >>> Yes. >>> >>>> Personally, the only reason why I am happy with the auto-focus, >>>> is by >>>> pressing Cmd-T to run tests. I find this quite convenient to simply >>>> accept a method, then move the moose to the column and press Cmd-T, >>>> without clicking. >>> yes. >>> Another scenario from Stef: >>> Having a method selected in the method list, going with the mouse >>> button >>> to the first >>> column while having selected the hierarchy button and press key up >>> or >>> down to >>> conveniently browse the same method in super- or subclasses. >>> >>>> Although I do not see a scenario where auto-focus is >>>> a real problem, I do understand that David made an arbitrary >>>> decision >>>> without much consultation. Sorry about that. So, what do we do? >>> Well, I did some "consultation" with Gary and Stef. >>> But they left the decision to me, so I "decided" to be it like >>> that for >>> the moment to >>> see how people react. >>> I don't mind to, as Gary suggested, introduce yet another preference >>> (there are >>> already two related to this "auto-focus") saying whether one wants >>> to >>> ignore the >>> mouseClickForKeyboardFocus preference in the browser's columns, >>> although >>> I personally >>> think that such a preference is not needed as I can't imagine that >>> this >>> auto-focus >>> for columns gets into the way too often (if at all). >>> But if people want me to add such a pref, fine by me. >>> >>> I don't think we want to start a much ado about nothing discussion >>> about >>> this small >>> change. ;) >>> >>> David >>> >>>> On 20 Feb 2009, at 14:38, Schwab,Wilhelm K wrote: >>>> >>>>> Alexandre, >>>>> >>>>> Can you give us an explanation or pointer to one? This sounds >>>>> like >>>>> something that Gary worked hard to stop from happening. I want >>>>> you >>>>> to have what you want from your image, and I need my future >>>>> users to >>>>> have what they will demand (loudly<g>). I am also convinced that >>>>> there are things (e.g. mouse wheel input) that should "follow the >>>>> mouse" without affecting keyboard focus, and this might be one of >>>>> them, but referring to focus gives me the idea that keyboard input >>>>> will go to the columns based on mouse position, and that >>>>> (PLEASE!!!!!) needs to be optional - it drives me batty. I type >>>>> quite fast, and if the input goes to what amount to commands >>>>> instead >>>>> of editing, it can get ugly. >>>>> >>>>> There are some preferences that control behavior like this, and >>>>> any >>>>> such overrides should be conditional on one being set, or moved >>>>> into >>>>> the themes, probably as an aspect vs. implied by the theme choice. >>>>> By the latter, I am assuming that you want Motif style mouse/focus >>>>> behavior in any old theme you happen to choose. That's fine, >>>>> but it >>>>> should be optional or we are taking a step backward in feel. >>>>> >>>>> Bill >>>>> >>>>> >>>>> ---- >>>>> Wilhelm K. Schwab, Ph.D. >>>>> bschwab AT anest DOT ufl DOT edu >>>>> >>>>> ________________________________________ >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>>>> [pharo-project-bounces(a)lists.gforge.inria.fr >>>>> ] On Behalf Of Alexandre Bergel [Alexandre.Bergel(a)inria.fr] >>>>> Sent: Friday, February 20, 2009 5:04 AM >>>>> To: Pharo Development >>>>> Subject: [Pharo-project] Automatic focus on column upon moose >>>>> enter >>>>> >>>>> David, >>>>> You're a hero! >>>>> Thanks for OB-Enhancements-dr.305 >>>>> >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 20, 2009

[Pharo-project] Problem with the OB debugger

by StÃ©phane Ducasse

Hi today I was giving lectures with the pahro-dev image and its OB- debugger ad I noticed that I could not have two halts else after proceeding the first one I got a resume I do not what and I could not see the other halt. Is it only me? Stef

Feb. 20, 2009