2018-05-17 10:53 GMT+03:00 Marcus Denker <[email protected]>: > On 16 May 2018, at 18:21, Denis Kudriashov <[email protected]> wrote: > > > Hi Marcus. > I commented on github. > > 2018-05-16 18:34 GMT+03:00 Marcus Denker <[email protected]>: > >> >> >> > On 4 Apr 2018, at 18:02, Marcus Denker <[email protected]> wrote: >> > >> > Hi, >> > >> > Some code is very “active”, executed all the time, e.g. collections, >> graphics… or imagine if you work on the compiler or debugger. >> > >> > It would really be nice if we could test a change before accepting it. >> Something like “Accept for Test” where magically the original method >> > does not change, yet, when running tests, the version of the code we >> accepted for testing is executed. >> > >> here is a version done using a Calypso command: >> >> https://github.com/pharo-project/pharo/pull/1372 >> >> missing: >> -we need to have some visual clue in the footer >> - a tool that lists all “accepted for test” method with the >> possibility to “commit” all at once. >> > > We will have it almost for free with Calypso as soon as this new metalink > will be managed similar way as breakpoints. > "Commit" is of course needs to be implemented. > > I really wonder if this is the same as breakpoint. E.g. it only applies to > the whole method, it is not an “action”, so a guter icon > seems to be not the right visualization. > > To me the fact that it uses a meta-link is purely an implementation > artefact, other than for breakpoints, watchpoints, where we annotate > the AST with actions… >
I only speak about management implementation. The way how registries of breakpoints and watchpoints are maintained and used by tools. They all needs some kind of reification of meta information to allow users distinguish between them. Even if we will avoid all these caches/registries, we will still need mechanizm to detect that this given metalink is breakpoint and not watchpoint. So I just want to have reusable mechanizm to manage all these kinds of meta information which is driven by metalinks. To me "MethodCodeForTest" is just another kind of them. Tools will need to detect them in methods and to distinguish them from breakpoints and others. > > Marcus > >
