Thanks Clara for these news.
Let us know how we can help you.
We love so much the object centric debugger :)

Also once you are in sync with andrei it would be good to see what should be pushed into Pharo.

Stef


On Sep 8, 2013, at 9:32 PM, Clara Allende <clari.allende@gmail.com> wrote:

Hi guys, sorry for the long time between updates :)

On these months of gsoc, I have been working mostly on two aspects:

-Adding support for filtering the stack
Andrei, Nicol�s and I agreed that we wanted filters to be rich objects, so that we can combine them and add new ones at will. After two or three iterations, we ended up having a hierarchy of filters that can combine with other filters by sending #and: and #or: messages, and also we can create filters from any boolean block :)
So we have something like:
fromBlockFilter := [:ctx | ctx isNotNil] asFilter.
doItFilter:= SelectorFilter forSelector: #doIt.

fromBlockFilter and: doItFilter. 

Which return a filter, that can decide if a context should be displayed or not, by sending #shouldDisplay: message.
This way, the filters handle a context, and the debugger handles the stack. I

filterStack

^self class filterCommonMessageSends ifTrue:[
self stack  reject: [:aContext | (self enabledFilters anySatisfy: 
                               [:aFilter | aFilter shouldDisplay: aContext]) 
                              and: [aContext = self currentContext ] ]
]
 I will write a post on my blog to explain this in more detail, anyway.

So far the default filters from the old debugger have their equivalent in this new filter api. Now I am working on having them as default configuration in settings browser; and the idea is 
a) enable/disable filters at will
b) to let the user add new filters in a per-debugger custom configuration.
c) let the users "publish" a custom configuration to be used as default.

<PharoScreenshot.1.png>

-Object-centric debugger
This is a tricky one. I had tried, and Nico tried too, to migrate Bifr�st to Pharo3.0, so far without success :( 
Bifr�st relies on the old compiler's ast dependencies and behavior, so it has not been easy to make it work with Opal. We have got in touch with Jorge Ressia and he promised us that he is going to take a look at this ASAP, to tell us whether it's likely or not that we migrate Bifr�st. Nevertheless, it's going to take a while.
That being said, I am interested on getting Bifr�st to work in Pharo3.0, and I'm a little sad that I couldn't get to play with object centric reflection for gsoc :( But I intend to keep on working on this after gsoc is over; so I promise I will let you know as soon as I have any news on this. 

Maybe if we can't integrate Bifr�st we could think of a rework, basing on Jorge's ideas... Or maybe try another approach.

Please let me know of any questions, suggestions,etc, I much appreciate them :)

Cheers!
Clara