@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

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

On Mon, Apr 25, 2011 at 5:39 PM, Alexandre Bergel <alexandre.bergel@me.com>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 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?"

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?" "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

On Mon, Apr 25, 2011 at 8:02 PM, Alexandre Bergel <alexandre.bergel@me.com>wrote:

...

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.

I understand. I was just pointing you the "backend" in case you were not aware.

...

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

I understand. But no matter the UI / environment / frontend , you will need first the "backend" (call it as you want). 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: 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 <alexandre.bergel@me.com>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

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

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

On Tue, Apr 26, 2011 at 1:54 PM, Toon Verwaest <toon.verwaest@gmail.com>wrote:

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.

I am not sure if I understood correctly, but you may want to take a look to Gemstone. As far as I remember they can have not only different versions of a certain class at the same time, but also instances of a specific class version all living together at the same time.

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

-- Mariano http://marianopeck.wordpress.com

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.