Better debugging...
Locked
12
12
 
|
Hi guys
I'm chasing a strange bug since a couple of hours and what I would love to have is the possibility to change an instance variable into an object that says stop each time you are changed from this flow. Stef |
|
|
@Adrian Lienhard
Does that ring a bell? :D -> Object Flow VM... On 25.04.2011, at 10:34, Stéphane Ducasse wrote: > Hi guys > > I'm chasing a strange bug since a couple of hours and what I would love to have is > the possibility to change an instance variable into an object that says stop each time you are changed from this flow. > > Stef |
|
|
In reply to this post by Stéphane Ducasse
Debugging, as well as profiling, is a topic that everybody got it wrong. We still debug an application in oo in the same way that people debugged their C program: thinking in term of call stack and stack frame instead of objects.
Alexandre Le 25 avr. 2011 à 04:34, Stéphane Ducasse <[hidden email]> a écrit : > Hi guys > > I'm chasing a strange bug since a couple of hours and what I would love to have is > the possibility to change an instance variable into an object that says stop each time you are changed from this flow. > > Stef |
|
|
Hi Alexandre-- > Debugging, as well as profiling, is a topic that everybody got it > wrong. We still debug an application in oo in the same way that > people debugged their C program: thinking in term of call stack and > stack frame instead of objects. So tell us more! :) How do you express causality? -C -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547 |
Re: Better debugging...
|
|
In reply to this post by Stéphane Ducasse
On Mon, Apr 25, 2011 at 10:34 AM, Stéphane Ducasse <[hidden email]> wrote: Hi guys What about a proxy object plus certain logic in the interception that using thisContext knows whether to stop or to forward to a target object ? -- Mariano http://marianopeck.wordpress.com |
|
|
In reply to this post by ccrraaiigg
All Smalltalk (and Java profilers) tells us which method call stack appears the most during an execution. This is pretty poor. "What are the objects that makes an execution slow?" and "Which are message arguments responsible of a slow execution?" are the two questions I will probably work on for the next two years. We already have some preliminary: http://www.bergel.eu/download/papers/Berg10aProfiling.pdf
More to come in a few days. Same thing for debugging. Why should I see the execution as a bunch of stack frame? "How to set a breakpoint based on the object state?" "Are all objects responsible for an odd execution or is there just a particular one?" "What is the exact difference of execution if I slightly change a method?" "If I call #foo it works, if I call #foo2 it does not work. Why? What are the objects that appears with #foo2 that do not appear with #foo?" All these questions are essential in my opinion. Code profiler and code debugger are pretty poor. I can continue with test code coverage tools. After all, Computer Science is a pretty young science. Cheers, Alexandre On 25 Apr 2011, at 07:34, Craig Latta wrote: > > Hi Alexandre-- > >> Debugging, as well as profiling, is a topic that everybody got it >> wrong. We still debug an application in oo in the same way that >> people debugged their C program: thinking in term of call stack and >> stack frame instead of objects. > > So tell us more! :) How do you express causality? > > > -C > > -- > Craig Latta > www.netjam.org/resume > +31 06 2757 7177 > + 1 415 287 3547 > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Mariano Martinez Peck
> I'm chasing a strange bug since a couple of hours and what I would love to have is
> the possibility to change an instance variable into an object that says stop each time you are changed from this flow. > > > What about a proxy object plus certain logic in the interception that using thisContext knows whether to stop or to forward to a target object ? Yes Mariano. Providing the functionality is easy, indeed. However having a clean integration in the programming environment is where the difficulty lays. What button should I add to the debugger to have this? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Max Leske
> @Adrian Lienhard > Does that ring a bell? :D > > -> Object Flow VM... Yes I prosposed this topic to adrian :) Now I would like the get an halt on any attempt for example to modify an array. this would be good. Stef |
Re: Better debugging...
|
|
In reply to this post by abergel
On Mon, Apr 25, 2011 at 5:39 PM, Alexandre Bergel <[hidden email]> wrote: All Smalltalk (and Java profilers) tells us which method call stack appears the most during an execution. This is pretty poor. "What are the objects that makes an execution slow?" and "Which are message arguments responsible of a slow execution?" are the two questions I will probably work on for the next two years. We already have some preliminary: http://www.bergel.eu/download/papers/Berg10aProfiling.pdf self haltIf: "Are all objects responsible for an odd execution or is there just a particular one?" This is one of the things I was doing with the "used objects" stuff, where I used a bit (the last one) in the Object Header and I modify the VM to intercept all messages sent to such object and flag it as "used" when they receive a message. So you could do: | results | results := UsedObjectDiscover trace: [ self blah ]. and results understands amountOfUsedObjects, amountOfUnusedObjects, blah You can also query which objects where used for the [ self balh] in this case... "What is the exact difference of execution if I slightly change a method?" I agree. Code profiler and code debugger are pretty poor. I can continue with test code coverage tools. -- Mariano http://marianopeck.wordpress.com |
Re: Better debugging...
|
|
In reply to this post by abergel
On Mon, Apr 25, 2011 at 5:40 PM, Alexandre Bergel <[hidden email]> wrote:
hehehe good question. In addition, you should be able to put back the origianl at some point... Cheers, -- Mariano http://marianopeck.wordpress.com |
|
|
In reply to this post by Mariano Martinez Peck
> Same thing for debugging. Why should I see the execution as a bunch of stack frame?
> "How to set a breakpoint based on the object state?" > > self haltIf: I know this. But this is not an operation supported by the environment. It is like a refactoring. I do not need the refactoring browser to do refactoring. But since it is one-click away in the refactoring browser, I refactor my code constantly. > "Are all objects responsible for an odd execution or is there just a particular one?" > > This is one of the things I was doing with the "used objects" stuff, where I used a bit (the last one) in the Object Header and I modify the VM to intercept all messages sent to such object and flag it as "used" when they receive a message. So you could do: > > | results | > results := UsedObjectDiscover trace: [ self blah ]. > and results understands amountOfUsedObjects, amountOfUnusedObjects, blah > You can also query which objects where used for the [ self balh] in this case... Same thing. Having it embedded in the programming environment is challenging. Nobody has done this. The only significant improvement of debugger is omniscient. But we can go way further. Alexandre > > "What is the exact difference of execution if I slightly change a method?" > "If I call #foo it works, if I call #foo2 it does not work. Why? What are the objects that appears with #foo2 that do not appear with #foo?" > All these questions are essential in my opinion. > > > I agree. > > Code profiler and code debugger are pretty poor. I can continue with test code coverage tools. > After all, Computer Science is a pretty young science. > > Cheers, > Alexandre > > > > On 25 Apr 2011, at 07:34, Craig Latta wrote: > > > > > Hi Alexandre-- > > > >> Debugging, as well as profiling, is a topic that everybody got it > >> wrong. We still debug an application in oo in the same way that > >> people debugged their C program: thinking in term of call stack and > >> stack frame instead of objects. > > > > So tell us more! :) How do you express causality? > > > > > > -C > > > > -- > > Craig Latta > > www.netjam.org/resume > > +31 06 2757 7177 > > + 1 415 287 3547 > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: Better debugging...
|
|
On Mon, Apr 25, 2011 at 8:02 PM, Alexandre Bergel <[hidden email]> wrote:
I understand. I was just pointing you the "backend" in case you were not aware.
I understand. But no matter the UI / environment / frontend , you will need first the "backend" (call it as you want). Cheers Alexandre -- Mariano http://marianopeck.wordpress.com |
|
|
> I understand. But no matter the UI / environment / frontend , you will need first the "backend" (call it as you want).
Yeah, we need an implementation :-) Your work is indeed important. I foresee nice discussions at esug. Cheers, Alexandre > > > > > "What is the exact difference of execution if I slightly change a method?" > > "If I call #foo it works, if I call #foo2 it does not work. Why? What are the objects that appears with #foo2 that do not appear with #foo?" > > All these questions are essential in my opinion. > > > > > > I agree. > > > > Code profiler and code debugger are pretty poor. I can continue with test code coverage tools. > > After all, Computer Science is a pretty young science. > > > > Cheers, > > Alexandre > > > > > > > > On 25 Apr 2011, at 07:34, Craig Latta wrote: > > > > > > > > Hi Alexandre-- > > > > > >> Debugging, as well as profiling, is a topic that everybody got it > > >> wrong. We still debug an application in oo in the same way that > > >> people debugged their C program: thinking in term of call stack and > > >> stack frame instead of objects. > > > > > > So tell us more! :) How do you express causality? > > > > > > > > > -C > > > > > > -- > > > Craig Latta > > > www.netjam.org/resume > > > +31 06 2757 7177 > > > + 1 415 287 3547 > > > > > > > > > > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: Better debugging...
|
|
Alexandre: have you ever look to http://www.adrian-lienhard.ch/blog?dialog=smalltak-meets-dtrace ?
He has integrated DTrace into the SqueakVM. http://en.wikipedia.org/wiki/DTrace Maybe it is of help... Cheers mariano On Mon, Apr 25, 2011 at 8:31 PM, Alexandre Bergel <[hidden email]> wrote:
-- Mariano http://marianopeck.wordpress.com |
|
|
I read this some times ago. Thanks for the link. I am interested to see which kind of "query" we can formulate for an execution.
Cheers, Alexandre On 25 Apr 2011, at 13:50, Mariano Martinez Peck wrote: > Alexandre: have you ever look to http://www.adrian-lienhard.ch/blog?dialog=smalltak-meets-dtrace ? > He has integrated DTrace into the SqueakVM. > http://en.wikipedia.org/wiki/DTrace > > Maybe it is of help... > > Cheers > > mariano > > On Mon, Apr 25, 2011 at 8:31 PM, Alexandre Bergel <[hidden email]> wrote: > > I understand. But no matter the UI / environment / frontend , you will need first the "backend" (call it as you want). > > Yeah, we need an implementation :-) > Your work is indeed important. I foresee nice discussions at esug. > > Cheers, > Alexandre > > > > > > > > > "What is the exact difference of execution if I slightly change a method?" > > > "If I call #foo it works, if I call #foo2 it does not work. Why? What are the objects that appears with #foo2 that do not appear with #foo?" > > > All these questions are essential in my opinion. > > > > > > > > > I agree. > > > > > > Code profiler and code debugger are pretty poor. I can continue with test code coverage tools. > > > After all, Computer Science is a pretty young science. > > > > > > Cheers, > > > Alexandre > > > > > > > > > > > > On 25 Apr 2011, at 07:34, Craig Latta wrote: > > > > > > > > > > > Hi Alexandre-- > > > > > > > >> Debugging, as well as profiling, is a topic that everybody got it > > > >> wrong. We still debug an application in oo in the same way that > > > >> people debugged their C program: thinking in term of call stack and > > > >> stack frame instead of objects. > > > > > > > > So tell us more! :) How do you express causality? > > > > > > > > > > > > -C > > > > > > > > -- > > > > Craig Latta > > > > www.netjam.org/resume > > > > +31 06 2757 7177 > > > > + 1 415 287 3547 > > > > > > > > > > > > > > > > > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Mariano > > > http://marianopeck.wordpress.com > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
I think a nice way to have a decent debugger is to run the program on top of a changeable interpreter. Since a classical debugger is nothing else but an interpreter with slightly changed semantics.
The object flow VM does a great job at tracing back stuff.. however it might pose a massive overhead since it collects tons and tons of data. In Pinocchio[1] we implemented very nice and simple debuggers by "just" changing the current interpreter to take a user-action into account on each message send. Since this is implemented on top of a metacircular interpreter this was quite simple to achieve. So the whole implementation of the known debugger functionality (step, over...) maybe took an afternoon. Since you have access to the full interpreter protocol it is very easy to intercept different sorts of actions. As described in the linked paper, it was very easy to implement the object-flow behavior in Pinocchio. So for me there is only one real way to have a decent debugger. And that means that it is a first-class interpreter whose semantics I can change at will. Thus I can create a specific debugger for my applications. But I guess that making the first-class interpreters work right away in Pharo will take a while to do, hence I propose the following additions to the current interpreter to make it partly useable: - interception of message sends - per thread [ok] - of specific classes [missing] - of specific instances [missing] - interception of instance variable access, read/write - per thread [missing] - of specific classes [missing] - of specific instances [missing] - of specific instance variables [missing] Furthermore I really want to be able to script all of that stuff, eg. provide a simple test block that gets invoked on each message send. Returning true => halt, Returning false => continue execution. [1] http://scg.unibe.ch/archive/papers/Verw10aPinocchio.pdf |
|
|
Hi guys,
Stef, Bifröst was invented for this particular purpose. http://scg.unibe.ch/research/bifrost Bifröst is a unified approach to reflection. Stef, if you explain a little bit the use case I can quickly provide an adaptation solution. HTH, Jorge On Mon, Apr 25, 2011 at 11:29 PM, Camillo Bruni <[hidden email]> wrote: > I think a nice way to have a decent debugger is to run the program on top of a changeable interpreter. Since a classical debugger is nothing else but an interpreter with slightly changed semantics. > > The object flow VM does a great job at tracing back stuff.. however it might pose a massive overhead since it collects tons and tons of data. > > In Pinocchio[1] we implemented very nice and simple debuggers by "just" changing the current interpreter to take a user-action into account on each message send. Since this is implemented on top of a metacircular interpreter this was quite simple to achieve. So the whole implementation of the known debugger functionality (step, over...) maybe took an afternoon. Since you have access to the full interpreter protocol it is very easy to intercept different sorts of actions. As described in the linked paper, it was very easy to implement the object-flow behavior in Pinocchio. > > So for me there is only one real way to have a decent debugger. And that means that it is a first-class interpreter whose semantics I can change at will. Thus I can create a specific debugger for my applications. > > But I guess that making the first-class interpreters work right away in Pharo will take a while to do, hence I propose the following additions to the current interpreter to make it partly useable: > > - interception of message sends > - per thread [ok] > - of specific classes [missing] > - of specific instances [missing] > > - interception of instance variable access, read/write > - per thread [missing] > - of specific classes [missing] > - of specific instances [missing] > - of specific instance variables [missing] > > Furthermore I really want to be able to script all of that stuff, eg. provide a simple test block that gets invoked on each message send. Returning true => halt, Returning false => continue execution. > > > [1] http://scg.unibe.ch/archive/papers/Verw10aPinocchio.pdf > -- Jorge Ressia www.jorgeressia.com |
|
|
In reply to this post by Camillo Bruni
Yes soon or later we will clean the debugger code and principle too :)
I'm interested in any progress on that front. Stef On Apr 25, 2011, at 11:29 PM, Camillo Bruni wrote: > I think a nice way to have a decent debugger is to run the program on top of a changeable interpreter. Since a classical debugger is nothing else but an interpreter with slightly changed semantics. > > The object flow VM does a great job at tracing back stuff.. however it might pose a massive overhead since it collects tons and tons of data. > > In Pinocchio[1] we implemented very nice and simple debuggers by "just" changing the current interpreter to take a user-action into account on each message send. Since this is implemented on top of a metacircular interpreter this was quite simple to achieve. So the whole implementation of the known debugger functionality (step, over...) maybe took an afternoon. Since you have access to the full interpreter protocol it is very easy to intercept different sorts of actions. As described in the linked paper, it was very easy to implement the object-flow behavior in Pinocchio. > > So for me there is only one real way to have a decent debugger. And that means that it is a first-class interpreter whose semantics I can change at will. Thus I can create a specific debugger for my applications. > > But I guess that making the first-class interpreters work right away in Pharo will take a while to do, hence I propose the following additions to the current interpreter to make it partly useable: > > - interception of message sends > - per thread [ok] > - of specific classes [missing] > - of specific instances [missing] > > - interception of instance variable access, read/write > - per thread [missing] > - of specific classes [missing] > - of specific instances [missing] > - of specific instance variables [missing] > > Furthermore I really want to be able to script all of that stuff, eg. provide a simple test block that gets invoked on each message send. Returning true => halt, Returning false => continue execution. > > > [1] http://scg.unibe.ch/archive/papers/Verw10aPinocchio.pdf |
|
|
In reply to this post by Camillo Bruni
I'm working on porting this idea already to the Glamour debugger.
The idea is basically to use meta-circular interpreters as a way to specify what semantics you want, but for speed reasons you might want to flatten out the interpretation by combining both. This however should all be done behind the scenes, independent of the definition of the debugger. More elaborate debuggers such as the alias debugger can be implemented but there's no good way yet to separate the data spaces involved. That's where me and Erwann are looking at how to maybe use a GC that can run multiple different versions code at the same time while synchronizing the shared data between the versions of the code. For example in the case of the alias debugger, that needs aliases everwhere; but all the global data (classes, methods, ...) is not aliased. To make this work you actually want to have a "copy" of the global data that is aliased, but kept in sync with the original data. Here it starts making a lot of sense to have thread-local heaps + a versioned but synced global heap. Of course that's all still wishful thinking... step by step :) cheers, Toon On 04/25/2011 11:29 PM, Camillo Bruni wrote: > I think a nice way to have a decent debugger is to run the program on top of a changeable interpreter. Since a classical debugger is nothing else but an interpreter with slightly changed semantics. > > The object flow VM does a great job at tracing back stuff.. however it might pose a massive overhead since it collects tons and tons of data. > > In Pinocchio[1] we implemented very nice and simple debuggers by "just" changing the current interpreter to take a user-action into account on each message send. Since this is implemented on top of a metacircular interpreter this was quite simple to achieve. So the whole implementation of the known debugger functionality (step, over...) maybe took an afternoon. Since you have access to the full interpreter protocol it is very easy to intercept different sorts of actions. As described in the linked paper, it was very easy to implement the object-flow behavior in Pinocchio. > > So for me there is only one real way to have a decent debugger. And that means that it is a first-class interpreter whose semantics I can change at will. Thus I can create a specific debugger for my applications. > > But I guess that making the first-class interpreters work right away in Pharo will take a while to do, hence I propose the following additions to the current interpreter to make it partly useable: > > - interception of message sends > - per thread [ok] > - of specific classes [missing] > - of specific instances [missing] > > - interception of instance variable access, read/write > - per thread [missing] > - of specific classes [missing] > - of specific instances [missing] > - of specific instance variables [missing] > > Furthermore I really want to be able to script all of that stuff, eg. provide a simple test block that gets invoked on each message send. Returning true => halt, Returning false => continue execution. > > > [1] http://scg.unibe.ch/archive/papers/Verw10aPinocchio.pdf |
|
|
In reply to this post by Camillo Bruni
> In Pinocchio[1] we implemented very nice and simple debuggers by "just" changing the current interpreter to take a user-action into account on each message send. Since this is implemented on top of a metacircular interpreter this was quite simple to achieve. So the whole implementation of the known debugger functionality (step, over...) maybe took an afternoon. Since you have access to the full interpreter protocol it is very easy to intercept different sorts of actions. As described in the linked paper, it was very easy to implement the object-flow behavior in Pinocchio.
I have built a number of code profilers over the time. The instrumentation is done with Spy, a kind of method wrapper. It would cool to see whether Pinocchio can be a better replacement for my profilers. This will be a cool validation for Pinocchio Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |