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. [image: Inline images 1] *-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
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
On Sep 8, 2013, at 9:33 PM, Clara Allende <clari.allende@gmail.com> wrote:
-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 :)
I think the way to go is to first have a full and working an debugged version of Reflectivity for Pharo⦠and then build on top of that. The problem is that this is a project in itself. Marcus
Hi Clara, On Sun, Sep 8, 2013 at 9:32 PM, Clara Allende <clari.allende@gmail.com>wrote:
I will write a post on my blog to explain this in more detail, anyway.
could you please announce where your blog is? I would love to follow it. Thank you for your work -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
@Stef yes, the idea is to have those nice filters integrated as soon as they are done and well tested :) @Marcus I was thinking of Reflectivity too.. but as you said it, it is a project in itself. Nevertheless, I would like to take a look and see what we can do :) @Damien the blog is http://clariallende.wordpress.com :D I will write more on the filters during the week. Thank you all, I will keep you posted :) Cheers, Clara On 9 September 2013 05:54, Damien Cassou <damien.cassou@gmail.com> wrote:
Hi Clara,
On Sun, Sep 8, 2013 at 9:32 PM, Clara Allende <clari.allende@gmail.com>wrote:
I will write a post on my blog to explain this in more detail, anyway.
could you please announce where your blog is? I would love to follow it.
Thank you for your work
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
participants (4)
-
Clara Allende -
Damien Cassou -
Marcus Denker -
Stéphane Ducasse