[Reflectivity] Progress for Breakpoints

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

Yes! Thanks Marcus!!

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.

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

https://pharo.fogbugz.com/f/cases/15516/add-suggestion-for-breakpoint

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

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

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

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

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:

> 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

Thanks a lot Marcus. Your work is really appreciated!

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

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.