[Reflectivity] Progress for Breakpoints

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[Reflectivity] Progress for Breakpoints

Marcus Denker-4
Hi,

50040 now has these changes:

- Smart Suggestions used to re-parse even when the editor window is not dirty.
        ==> now we work on the AST we get from the method in this case.
- Reflectivity: FIX: when removing the last link, make sure to recompile the method.
- Breakpoints: added (and simplified a bit) the class Breakpoint from Clara’s SmartBreakpoint
  project.

Next: integrate enable setting/removing breakpoints using suggestions.

        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: [Reflectivity] Progress for Breakpoints

Marcus Denker-4

On 08 May 2015, at 11:52, Marcus Denker <[hidden email]> wrote:

Hi,

50040 now has these changes:

- Smart Suggestions used to re-parse even when the editor window is not dirty.
==> now we work on the AST we get from the method in this case.
- Reflectivity: FIX: when removing the last link, make sure to recompile the method.
- Breakpoints: added (and simplified a bit) the class Breakpoint from Clara’s SmartBreakpoint
 project.

Next: integrate enable setting/removing breakpoints using suggestions.



this is of course completely untested… it works only when there is no unaccepted
text in the editor and maybe only within Nautilus.

And of course existing breakpoints are not yet in any form visualised in the editor.


Marcus

Reply | Threaded
Open this post in threaded view
|

Re: [Reflectivity] Progress for Breakpoints

Marcus Denker-4

On 08 May 2015, at 14:58, Marcus Denker <[hidden email]> wrote:


On 08 May 2015, at 11:52, Marcus Denker <[hidden email]> wrote:

Hi,

50040 now has these changes:

- Smart Suggestions used to re-parse even when the editor window is not dirty.
==> now we work on the AST we get from the method in this case.
- Reflectivity: FIX: when removing the last link, make sure to recompile the method.
- Breakpoints: added (and simplified a bit) the class Breakpoint from Clara’s SmartBreakpoint
 project.

Next: integrate enable setting/removing breakpoints using suggestions.



this is of course completely untested… it works only when there is no unaccepted
text in the editor and maybe only within Nautilus.

And of course existing breakpoints are not yet in any form visualised in the editor.

This is in 50041. Please use with care… still needs work to be really usable.

Marcus

Reply | Threaded
Open this post in threaded view
|

Re: [Reflectivity] Progress for Breakpoints

Tudor Girba-2
Thanks a lot for this work.

Doru

On Fri, May 8, 2015 at 4:23 PM, Marcus Denker <[hidden email]> wrote:

On 08 May 2015, at 14:58, Marcus Denker <[hidden email]> wrote:


On 08 May 2015, at 11:52, Marcus Denker <[hidden email]> wrote:

Hi,

50040 now has these changes:

- Smart Suggestions used to re-parse even when the editor window is not dirty.
==> now we work on the AST we get from the method in this case.
- Reflectivity: FIX: when removing the last link, make sure to recompile the method.
- Breakpoints: added (and simplified a bit) the class Breakpoint from Clara’s SmartBreakpoint
 project.

Next: integrate enable setting/removing breakpoints using suggestions.



this is of course completely untested… it works only when there is no unaccepted
text in the editor and maybe only within Nautilus.

And of course existing breakpoints are not yet in any form visualised in the editor.

This is in 50041. Please use with care… still needs work to be really usable.

Marcus




--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: [Reflectivity] Progress for Breakpoints

abergel
Yes! Thanks Marcus!!
This kind of improvement may impact all of us

Cheers,
Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 8, 2015, at 5:46 PM, Tudor Girba <[hidden email]> wrote:

Thanks a lot for this work.

Doru

On Fri, May 8, 2015 at 4:23 PM, Marcus Denker <[hidden email]> wrote:

On 08 May 2015, at 14:58, Marcus Denker <[hidden email]> wrote:


On 08 May 2015, at 11:52, Marcus Denker <[hidden email]> wrote:

Hi,

50040 now has these changes:

- Smart Suggestions used to re-parse even when the editor window is not dirty.
==> now we work on the AST we get from the method in this case.
- Reflectivity: FIX: when removing the last link, make sure to recompile the method.
- Breakpoints: added (and simplified a bit) the class Breakpoint from Clara’s SmartBreakpoint
 project.

Next: integrate enable setting/removing breakpoints using suggestions.



this is of course completely untested… it works only when there is no unaccepted
text in the editor and maybe only within Nautilus.

And of course existing breakpoints are not yet in any form visualised in the editor.

This is in 50041. Please use with care… still needs work to be really usable.

Marcus




--

"Every thing has its own flow"

Reply | Threaded
Open this post in threaded view
|

Re: [Reflectivity] Progress for Breakpoints

Glenn Cavarlé
In reply to this post by Marcus Denker-4
Thanks Marcus !
I just updated my pharo image, I'll test it (with care) !
It will be really great when it will be fully integrated within Nautilus, i look forward.

regards,
Glenn.
Glenn Cavarlé
Reply | Threaded
Open this post in threaded view
|

Re: [Reflectivity] Progress for Breakpoints

Marcus Denker-4
In reply to this post by Marcus Denker-4


this is of course completely untested… it works only when there is no unaccepted
text in the editor and maybe only within Nautilus.

And of course existing breakpoints are not yet in any form visualised in the editor.

This is in 50041. Please use with care… still needs work to be really usable.


I now finished to add everything from Clara’s original SmartBreakpoints project.

There are still lots of things that need to be done

-> Something goes wrong when re-adding a one-shot breakpoint again.
-> Adding should be disabled when the editor has non-submitted code.
-> The experience in the debugger is not that nice
 (need to think about using the <debuggerCompleteToSender> trick and
         explore the filtering capabilities of the debugger)

I am now continuing to flesh out the Reflectivity features:

-> hook AST generation is now done by HookGenerator
-> correct hooks are already generated for the case that a link passes
    arguments to the meta object (see the RFReification hierarchy, for now
    we have only #object *and* actual compiling does not yet work due to missing 
    semantic analysis of the AST snippets for the hooks)
-> We have support for “virtual” meta objects. Any valid reification can be the metaObject
    (this is fun for #node).

TODO
- add all reifications for all nodes (#arguments, #node, #context, #value #name, #arg1…)
- do semantic analysis correctly and add test for links with arguments
- add conditions with parameters (e.g. for object specific links: [:object | object == myObject])
- handle primitives: when putting a link on a primitive method, wrap the compiledMethod instead
  of AST manipulation.
- ….

I will continue to flesh it out and send examples to the list as these things start to work for real.


Marcus

Reply | Threaded
Open this post in threaded view
|

Re: [Reflectivity] Progress for Breakpoints

Clara Allende


2015-05-22 8:53 GMT-03:00 Marcus Denker <[hidden email]>:


this is of course completely untested… it works only when there is no unaccepted
text in the editor and maybe only within Nautilus.

And of course existing breakpoints are not yet in any form visualised in the editor.

This is in 50041. Please use with care… still needs work to be really usable.


I now finished to add everything from Clara’s original SmartBreakpoints project.

There are still lots of things that need to be done

-> Something goes wrong when re-adding a one-shot breakpoint again.

Yep, I'm aware of that bug, I couldn't figure out why it does it happen :/
At one point I got it work and randomly fail, so it was difficult to debug :( If right now it fails consistently, I would like to take a look.
 
-> Adding should be disabled when the editor has non-submitted code.
-> The experience in the debugger is not that nice
 (need to think about using the <debuggerCompleteToSender> trick and
         explore the filtering capabilities of the debugger)

I'm aware of this one too. I did add a filter for the Reflectivity/breakpoints contexts, but in my experience, the top most of those contexts remained on the debugger stack (because we need it in case we want to go back to that point after a lot of step into/out etc), making it a little bit confusing... I mean, when I saw it, I put myself in the place of the user, and could imagine him/her wondering wtf does that mean.
I agree we need to re-think it :/ 

I am now continuing to flesh out the Reflectivity features:

-> hook AST generation is now done by HookGenerator
-> correct hooks are already generated for the case that a link passes
    arguments to the meta object (see the RFReification hierarchy, for now
    we have only #object *and* actual compiling does not yet work due to missing 
    semantic analysis of the AST snippets for the hooks)
-> We have support for “virtual” meta objects. Any valid reification can be the metaObject
    (this is fun for #node).

TODO
- add all reifications for all nodes (#arguments, #node, #context, #value #name, #arg1…)
- do semantic analysis correctly and add test for links with arguments
- add conditions with parameters (e.g. for object specific links: [:object | object == myObject])
- handle primitives: when putting a link on a primitive method, wrap the compiledMethod instead
  of AST manipulation.
- ….

I will continue to flesh it out and send examples to the list as these things start to work for real.


Marcus


Reply | Threaded
Open this post in threaded view
|

Re: [Reflectivity] Progress for Breakpoints

stepharo
In reply to this post by Marcus Denker-4
Marcus

with franck and alain we worked on using Rubric instead of pluggableTextMorph in Nautilus.
so you will be able to display icons or other for the breakpoints.

Stef

Le 22/5/15 11:53, Marcus Denker a écrit :


this is of course completely untested… it works only when there is no unaccepted
text in the editor and maybe only within Nautilus.

And of course existing breakpoints are not yet in any form visualised in the editor.

This is in 50041. Please use with care… still needs work to be really usable.


I now finished to add everything from Clara’s original SmartBreakpoints project.

There are still lots of things that need to be done

-> Something goes wrong when re-adding a one-shot breakpoint again.
-> Adding should be disabled when the editor has non-submitted code.
-> The experience in the debugger is not that nice
 (need to think about using the <debuggerCompleteToSender> trick and
         explore the filtering capabilities of the debugger)

I am now continuing to flesh out the Reflectivity features:

-> hook AST generation is now done by HookGenerator
-> correct hooks are already generated for the case that a link passes
    arguments to the meta object (see the RFReification hierarchy, for now
    we have only #object *and* actual compiling does not yet work due to missing 
    semantic analysis of the AST snippets for the hooks)
-> We have support for “virtual” meta objects. Any valid reification can be the metaObject
    (this is fun for #node).

TODO
- add all reifications for all nodes (#arguments, #node, #context, #value #name, #arg1…)
- do semantic analysis correctly and add test for links with arguments
- add conditions with parameters (e.g. for object specific links: [:object | object == myObject])
- handle primitives: when putting a link on a primitive method, wrap the compiledMethod instead
  of AST manipulation.
- ….

I will continue to flesh it out and send examples to the list as these things start to work for real.


Marcus


Reply | Threaded
Open this post in threaded view
|

Re: [Reflectivity] Progress for Breakpoints

Marcus Denker-4
In reply to this post by Marcus Denker-4
>
> -> The experience in the debugger is not that nice
> (need to think about using the <debuggerCompleteToSender> trick and
>          explore the filtering capabilities of the debugger)
>

I implemented the “Debug test” Feature again using a one-shot breakpoint.
This is a good testcase to see how to improve the user experience.


debugTest: aMethod
        (Breakpoint inNode: aMethod ast)
                level: nil;
                once.
        aMethod methodClass run: aMethod selector.

(reflective API to create breakpoints will evolve as needed, e.g. no meta level might be the default)

> I am now continuing to flesh out the Reflectivity features:
>
...
> - add conditions with parameters (e.g. for object specific links: [:object | object == myObject])

HookGenerator now generates AST snippets for hooks with conditions that have arguments.

Next:
- add all reifications
- code gen for the complex hooks (need to add name analysis for hooks for that)

        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: [Reflectivity] Progress for Breakpoints

Marcus Denker-4

> - code gen for the complex hooks (need to add name analysis for hooks for that)
>

This is now in 50063.

It does work (for now) only for for #object as a parameter and not yet on all kinds of nodes, but the
machinery is working…

For a very simple example, see #testLinkWithMetaArg:

We can define a Metalink were we hand over reified information from the base level to the
meta object:

link := MetaLink new
                metaObject: self;          “meta object is the test class itself"
                selector: #tagExec:;      “we call that method, it just stored the parameter in an ivar tag"
                arguments: #(object).   “arguments are defined by symbols, there is plug architecture to define them"

in this case, it is the object at runtime of the method where we install the link in.

Lets grab a send node:

        sendNode := (ReflectivityExamples>>#exampleMethod) ast body statements first value.

install the link:
       
        sendNode link: link.

#tagExec: is just recording the parameter, so this will be green:

        instance := ReflectivityExamples new.
        self assert: (instance exampleMethod = 5).
        self assert: (tag = instance).

And it works!

TODO next:
        - add all possible reifications (#arguments, #context, #newvalue, #name…. depending on
          where the link is installed on, we are interesting in different things).

        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: [Reflectivity] Progress for Breakpoints

Marcus Denker-4
>
> TODO next:
> - add all possible reifications (#arguments, #context, #newvalue, #name…. depending on
>  where the link is installed on, we are interesting in different things).
>

I have now added #link, #newValue (for assignments), #node, #selector (for method and send), #arguments
(block, send, method), #context and #value (variable and assignment).

These symbols work
        -> as arguments for the meta object
                someLink
                        arguments: #(receiver selector arguments)
        -> as a “virtual meta object”
                        MetaLinks new metaObject: #node; selector: #tagExecuted
        -> as arguments for the link condition
                        someLink
                                condition: [:object | object == myObject ]

I added (hopefully) all methods so that links can be installed on any kind of node.

Next needed: Tests + Demos….

        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: [Reflectivity] Progress for Breakpoints

Ben Coman
Great to hear this progress, but I don't really understand the
applicatoin of them. Looking for to reviewing the Tests & Demos.
cheers -ben

On Mon, May 25, 2015 at 11:23 PM, Marcus Denker <[hidden email]> wrote:

>>
>> TODO next:
>>       - add all possible reifications (#arguments, #context, #newvalue, #name…. depending on
>>         where the link is installed on, we are interesting in different things).
>>
>
> I have now added #link,         #newValue (for assignments), #node, #selector (for method and send), #arguments
> (block, send, method), #context and #value (variable and assignment).
>
> These symbols work
>         -> as arguments for the meta object
>                 someLink
>                         arguments: #(receiver selector arguments)
>         -> as a “virtual meta object”
>                         MetaLinks new metaObject: #node; selector: #tagExecuted
>         -> as arguments for the link condition
>                         someLink
>                                 condition: [:object | object == myObject ]
>
> I added (hopefully) all methods so that links can be installed on any kind of node.
>
> Next needed: Tests + Demos….
>
>         Marcus

Reply | Threaded
Open this post in threaded view
|

Re: [Reflectivity] Progress for Breakpoints

Marcus Denker-4

> On 26 May 2015, at 08:17, Ben Coman <[hidden email]> wrote:
>
> Great to hear this progress, but I don't really understand the
> applicatoin of them. Looking for to reviewing the Tests & Demos.
> cheers -ben
>

Yes, I am aware that these mails are not understandable… I think they are more a trick
for myself to do something tiny every day that moves the project forward.

And it works: soon it will be in a state that it can be used for lots of interesting things.

Demos I want to do
        -> statement level code coverage using MetaLinks
        -> Implementing a CLOS style MOP for ivar/global/message send
        -> Implement MethodWrappers using meta links
        -> Plugin for nautilus to warn when looking at a method that is currently executed
            (some red button that get red on call and slowly fades)
        -> Implement the test coverage in the test runner using meta links on methods
        -> Extend Breakpoints to general “watch” points.
        -> Logging: provide a framework so that we can easily add logging reflectively

Marcus
Reply | Threaded
Open this post in threaded view
|

Re: [Reflectivity] Progress for Breakpoints

roberto.minelli@usi.ch
Thanks a lot Marcus. Your work is really appreciated!

> On 26 May 2015, at 08:46, Marcus Denker <[hidden email]> wrote:
> Yes, I am aware that these mails are not understandable… I think they are more a trick
> for myself to do something tiny every day that moves the project forward.
>
> And it works: soon it will be in a state that it can be used for lots of interesting things.
>
> Demos I want to do
> -> statement level code coverage using MetaLinks
> -> Implementing a CLOS style MOP for ivar/global/message send
> -> Implement MethodWrappers using meta links

Can’t wait for this one! ( -> Implement MethodWrappers using meta links ) and many other applications. Keep us up to date!


> -> Plugin for nautilus to warn when looking at a method that is currently executed
>    (some red button that get red on call and slowly fades)
> -> Implement the test coverage in the test runner using meta links on methods
> -> Extend Breakpoints to general “watch” points.
> -> Logging: provide a framework so that we can easily add logging reflectively
>
> Marcus

Reply | Threaded
Open this post in threaded view
|

Re: [Reflectivity] Progress for Breakpoints

Sean P. DeNigris
Administrator
In reply to this post by Marcus Denker-4
Marcus Denker-4 wrote
I think they are more a trick for myself to do something tiny every day that moves the project forward.
Ha ha, whatever works! I find them interesting even if I don't totally understand and it's good to know that progress is being made.
Cheers,
Sean