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

Re: [Pharo-project] something really cool with VW debugger

by StÃ©phane Ducasse

>> > > This is much clearer but I have to disagree. I didn't know these > details but I was still able to understand and use this pane. It > contained valuable information to me in a lot of cases. Moreover, it > is sometimes the only way to get the information you want when the > statements have border effect (as it was the case when I developed the > Nile Stream library I understand what you are saying and I would certainly agree if I can see that. Because I do not care about the detail, I care about the user experience. If the user experience is cool than this is a step in the right direction. Stef

June 16, 2008

Re: [Pharo-project] something really cool with VW debugger

by StÃ©phane Ducasse

On Jun 16, 2008, at 9:48 AM, Lukas Renggli wrote: > On 6/16/08, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> We are talking about the same thing. However, I still do not >> understand your answer. > > Ok, let me backtrack: > > 1. In Smalltalk you have a stack of context frames, subinstances of > ContextPart. The frames are created when sending messages or when > activating blocks. > > 2. Each of these frames has a little (fixed size) stack that is used > on the byte-code level to remember intermediate results and to push > receiver and arguments of message sends. > > Stack 1 is what you commonly see in the debugger and what you usually > refer to as "the execution stack". You suggested to display stack 2 in > the debugger as well. I don't agree that this is useful, because it > violates levels of abstraction. I do not want to discuss that on the theorical level. I found that really efficient to use that to debug with VW. > Stack 2 is only meaningful on a bytecode level. It cannot be directly > manipulated using the Smalltalk code you see in the Debugger. Unless > you exactly know how the compiler generates bytecodes for the current > source code, it is not obvious what the stack displays or when it > grows or shrinks. Smalltalk debuggers work on the source-level (stack > 1), whereas bytecodes are on a level below (stack 2). I believe that > should not be mixed. > > It would be cool to have a Smalltak bytecode debugger, that steps > through the bytecodes and where it would make perfect sense to display > stack 2. However that was not the point of this discussion. I do not know about stack 2 and stakc 1 and personnally I do not care. This is not my point. What I mentioned was a USER experience: I saw that in VW I can see the result of executed expression within the debugger without having to click+ select + printit and this was really cool because as soon as I got it I went really fast debugging repetitive methods. > > > Hope this cleared up things. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 16, 2008

Re: [Pharo-project] something really cool with VW debugger

by Damien Cassou

On Mon, Jun 16, 2008 at 9:48 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > On 6/16/08, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> We are talking about the same thing. However, I still do not >> understand your answer. > > Ok, let me backtrack: > > 1. In Smalltalk you have a stack of context frames, subinstances of > ContextPart. The frames are created when sending messages or when > activating blocks. > > 2. Each of these frames has a little (fixed size) stack that is used > on the byte-code level to remember intermediate results and to push > receiver and arguments of message sends. > > Stack 1 is what you commonly see in the debugger and what you usually > refer to as "the execution stack". You suggested to display stack 2 in > the debugger as well. I don't agree that this is useful, because it > violates levels of abstraction. > > Stack 2 is only meaningful on a bytecode level. It cannot be directly > manipulated using the Smalltalk code you see in the Debugger. Unless > you exactly know how the compiler generates bytecodes for the current > source code, it is not obvious what the stack displays or when it > grows or shrinks. Smalltalk debuggers work on the source-level (stack > 1), whereas bytecodes are on a level below (stack 2). I believe that > should not be mixed. > > It would be cool to have a Smalltak bytecode debugger, that steps > through the bytecodes and where it would make perfect sense to display > stack 2. However that was not the point of this discussion. > > Hope this cleared up things. This is much clearer but I have to disagree. I didn't know these details but I was still able to understand and use this pane. It contained valuable information to me in a lot of cases. Moreover, it is sometimes the only way to get the information you want when the statements have border effect (as it was the case when I developed the Nile Stream library). -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

June 16, 2008

Re: [Pharo-project] something really cool with VW debugger

by Lukas Renggli

On 6/16/08, Damien Cassou <damien.cassou(a)gmail.com> wrote: > We are talking about the same thing. However, I still do not > understand your answer. Ok, let me backtrack: 1. In Smalltalk you have a stack of context frames, subinstances of ContextPart. The frames are created when sending messages or when activating blocks. 2. Each of these frames has a little (fixed size) stack that is used on the byte-code level to remember intermediate results and to push receiver and arguments of message sends. Stack 1 is what you commonly see in the debugger and what you usually refer to as "the execution stack". You suggested to display stack 2 in the debugger as well. I don't agree that this is useful, because it violates levels of abstraction. Stack 2 is only meaningful on a bytecode level. It cannot be directly manipulated using the Smalltalk code you see in the Debugger. Unless you exactly know how the compiler generates bytecodes for the current source code, it is not obvious what the stack displays or when it grows or shrinks. Smalltalk debuggers work on the source-level (stack 1), whereas bytecodes are on a level below (stack 2). I believe that should not be mixed. It would be cool to have a Smalltak bytecode debugger, that steps through the bytecodes and where it would make perfect sense to display stack 2. However that was not the point of this discussion. Hope this cleared up things. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

June 16, 2008

Re: [Pharo-project] Need code review

by Alexandre Bergel

> http://lists.gforge.inria.fr/pipermail/pharo-project/2008-June/000323.html >>> [Pharo-project] MVC removal step2 investigations This is a big removal. I reviewed the code. Here are my comments: - Few methods in Browser are redefined using the hypothesis that a browser cannot be open in an MVC project. Methods that refer to PluggableButtonView are also removed. This make sense since this class can be considered as obsolete: a PluggableButtonView cannot be open anymore. - ChangeList: optionalButtonsView is removed. This makes sense since it opens MVC button (PluggableButtonView). This method is called nowhere - ChangeSorter>>openView: topView offsetBy: offset is removed. This method is called nowhere, and refers to MVC code Few questions: - Inspector>>openOn: anObject withEvalPane: withEval withLabel: label valueViewClass: valueViewClass seems to be called by FormInspectView class>>openOn: aFormDictionary withLabel: aLabel Don't you think that removing this method might be a problem? - Why have you removed PasteUpMorph>>open ? TestRunner me dit: - Avant le removal: 2117 run, 2108 passes, 2 expected failures, 7 failures, 0 errors, 0 unexpected passes - AprÃ¨s le removal: 2068 run, 2059 passes, 2 expected failures, 7 failures, 0 errors, 0 unexpected passes Je n'ai vu aucun problÃ¨me aprÃ¨s avoir chargÃ© le removal. I favour an inclusion. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 16, 2008

Re: [Pharo-project] something really cool with VW debugger

by Damien Cassou

---------- Forwarded message ---------- From: Lukas Renggli <renggli(a)gmail.com> Date: Sun, Jun 15, 2008 at 9:54 PM Subject: Re: [Pharo-project] something really cool with VW debugger To: Damien Cassou <damien.cassou(a)gmail.com> > I also find this really cool. I think the obvious place to add this > feature is in Lukas's OB-based debugger. I have no time to do it > myself however. That was for a while in the OB-Debugger. I removed it, because I found it useless and I have the opinion that the stack within a single frame is something that doesn't make sense on the source code level at all. After all this stack is an implementation detail and only exists and makes sense on the bytecode level. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

June 16, 2008

Re: [Pharo-project] something really cool with VW debugger

by Damien Cassou

I also find this really cool. I think the obvious place to add this feature is in Lukas's OB-based debugger. I have no time to do it myself however. On Sat, Jun 14, 2008 at 12:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi all > > if somebody wants to add a really cool feature to the debugger.... > in VW we can see as intermediary variable the results of subsets of > expression > so we we step thru the execution we do not have to select the expression and > print it > all the time we can simply see the results in the variable. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

June 15, 2008

Re: [Pharo-project] Reintegration of StringSocket

by Damien Cassou

On Sat, Jun 14, 2008 at 9:25 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Ok but what is the solution right now to make universe work? > Damien may be you should include StringSocket into the Universe package. > Because it is strange to rely on nebraska. I will try to see what I can do. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

June 15, 2008

Re: [Pharo-project] call for fix: fixing browser names and stupid dead navigation that works

by Damien Cassou

On Fri, Jun 13, 2008 at 4:50 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jun 13, 2008, at 3:30 PM, Damien Cassou wrote: > >> On Fri, Jun 13, 2008 at 2:40 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> Hi guys >>> >>> I send to this list the email I sent to the great omnibrowser developer >>> list...... >>> Really cool features but seems to forget the basic. if it takes me more >>> than >>> 5 min to find something >>> may be the interface is BAD. >> >> Do you use pharo-dev? > > Not yet. > Why there is a better version of the browser? The version of the browser is the latest version from wiresong.ca. However, I'm taking care of names and open... menu content. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

June 15, 2008

Re: [Pharo-project] Undeclard continued

by Adrian Lienhard

On Jun 14, 2008, at 22:11 , StÃ©phane Ducasse wrote: > Ok thanks > > The problem with the slice is that I cannot see the changes just > clicking on them. if you click "Merge" instead of "Changes" you get a complete diff, i.e., including the changes from dependent packages. Adrian > > I had a question about your changes. There was a test on finalizer > that changes > if I remember correctly and I was wondering why the test changed > that much. > > Stef > > On Jun 14, 2008, at 6:57 PM, Norbert Hartl wrote: > >> Hi Stef, >> >> you somehow missed the updates in System from the >> FixUndeclared Slice. The class variables SmallPrimes >> and HighBitOfByte are still missing. >> >> Norbert >> >> >> _______________________________________________ >> 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 15, 2008