May 2018 - Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #912: 18180-whichSelectorsAccess-cannot-find-some-of-the-variables-using-slots

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #912 was: FAILURE. The Pull Request #1375 was integrated: "18180-whichSelectorsAccess-cannot-find-some-of-the-variables-using-slots" Pull request url: https://github.com/pharo-project/pharo/pull/1375 Issue Url: https://pharo.fogbugz.com/f/cases/18180 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 17, 2018

Re: [Pharo-dev] Idea and proof of concept: Accept for Test

by Marcus Denker

> On 17 May 2018, at 12:59, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2018-05-17 13:00 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > >> 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. >> >> Hm, I would like to see indication in method table that some methods have "uncommited" changes. But it is not necessary should be icon. It can be star prefix in name like in dirty tabs. >> > Yes, an indication is important (with some UI to just forget the non-accepted code). > > Could be a prefix in the tabâ¦ or/and something in the footer? In the footer I guess it would be easy to add a menu with some options (browse all un-accepted, accept, undo) > > Yes. And such method can open editor always in dirty state. Many options. > > Another issue is how to work with breakpoints and others. > What the target method for them? original or attached one? > ohâ¦ good question. As we recompile, I guess that old breakpoints should not be active, but one should be able to define new onesâ¦ (but how to visualise that?). If one thinks this through, what we really want is maybe a full-blown âLayerâ systemâ¦ But: this is a lot of work. With even more open Questions :-) Marcus

May 17, 2018

Re: [Pharo-dev] Idea and proof of concept: Accept for Test

by Denis Kudriashov

2018-05-17 13:00 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr>: > > 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. >> > > Hm, I would like to see indication in method table that some methods have > "uncommited" changes. But it is not necessary should be icon. It can be > star prefix in name like in dirty tabs. > > > Yes, an indication is important (with some UI to just forget the > non-accepted code). > > Could be a prefix in the tabâ¦ or/and something in the footer? In the > footer I guess it would be easy to add a menu with some options (browse all > un-accepted, accept, undo) > Yes. And such method can open editor always in dirty state. Many options. Another issue is how to work with breakpoints and others. What the target method for them? original or attached one? > > Marcus > >

May 17, 2018

Re: [Pharo-dev] Idea and proof of concept: Accept for Test

by Tim Mackinnon

You guys are awesome! Sent from my iPhone > On 17 May 2018, at 11:01, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >>> >>> 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. >> > I will first do the infrastructure for the breakpoints/watchpoints, then we see if it can be generalised. > > Marcus >

May 17, 2018

Re: [Pharo-dev] Idea and proof of concept: Accept for Test

by Marcus Denker

> > 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. > I will first do the infrastructure for the breakpoints/watchpoints, then we see if it can be generalised. Marcus

May 17, 2018

Re: [Pharo-dev] Idea and proof of concept: Accept for Test

by Marcus Denker

> On 17 May 2018, at 11:46, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2018-05-17 10:53 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > On 16 May 2018, at 18:21, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> Hi Marcus. >> I commented on github. >> >> 2018-05-16 18:34 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: >> >> >> > On 4 Apr 2018, at 18:02, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> 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 <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. > > Hm, I would like to see indication in method table that some methods have "uncommited" changes. But it is not necessary should be icon. It can be star prefix in name like in dirty tabs. > Yes, an indication is important (with some UI to just forget the non-accepted code). Could be a prefix in the tabâ¦ or/and something in the footer? In the footer I guess it would be easy to add a menu with some options (browse all un-accepted, accept, undo) Marcus

May 17, 2018

Re: [Pharo-dev] Idea and proof of concept: Accept for Test

by Denis Kudriashov

2018-05-17 10:53 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr>: > On 16 May 2018, at 18:21, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > Hi Marcus. > I commented on github. > > 2018-05-16 18:34 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> >> > On 4 Apr 2018, at 18:02, Marcus Denker <marcus.denker(a)inria.fr> 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. > Hm, I would like to see indication in method table that some methods have "uncommited" changes. But it is not necessary should be icon. It can be star prefix in name like in dirty tabs. > > 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â¦ > > Marcus > >

May 17, 2018

Re: [Pharo-dev] Idea and proof of concept: Accept for Test

by Denis Kudriashov

2018-05-17 10:53 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr>: > On 16 May 2018, at 18:21, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > Hi Marcus. > I commented on github. > > 2018-05-16 18:34 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> >> > On 4 Apr 2018, at 18:02, Marcus Denker <marcus.denker(a)inria.fr> 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 > >

May 17, 2018

[Pharo 7.0-dev] Build #911: 21902-Deprecate-old-Compiler-API-with-transforming-deprecation

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #911 was: SUCCESS. The Pull Request #1371 was integrated: "21902-Deprecate-old-Compiler-API-with-transforming-deprecation" Pull request url: https://github.com/pharo-project/pharo/pull/1371 Issue Url: https://pharo.fogbugz.com/f/cases/21902 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 17, 2018

Re: [Pharo-dev] Idea and proof of concept: Accept for Test

by Marcus Denker

> On 16 May 2018, at 18:21, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi Marcus. > I commented on github. > > 2018-05-16 18:34 GMT+03:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > > > > On 4 Apr 2018, at 18:02, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> 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 <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â¦ Marcus

May 17, 2018