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

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

by Denis Kudriashov

2018-04-05 9:10 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 3 Apr 2018, at 21:56, Christophe Demarey <christophe.demarey(a)inria.fr> > wrote: > > Nice addition! > I should say that names are not really intention revealing. > What about haltIfTestExecutionEnvironment and > haltIfDefaultExecutionEnvironment ? > > To long and too implementation centered. > > I would even shorten it to haltIfTest and haltIfNotTest. > +1 > > Le 2 avr. 2018 Ã 21:12, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : > > Hi, > > As we can not very easily decide if we are inside a test execution or not > there was the idea to have special #halt messages > > https://pharo.fogbugz.com/f/cases/20151/new-halt-messages > > This PR implements them: > > https://github.com/pharo-project/pharo/pull/1177 > > There is now #haltIfInsideTest and #haltfOutsideTest. In addition, the PR > adds a helper method to make checking if the current > execution environment is a test run a bit easier: > "CurrentExecutionEnvironment value isTestâ. > > Marcus > > > >

April 5, 2018

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

by Marcus Denker

> On 5 Apr 2018, at 07:26, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > On 4 April 2018 at 22:20, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> If we remove self halt, then I won't be able to use `1halt.`. :-D which is >> actually what I always do, because writing `self halt` is 4 characters tooo >> long. :) >> >> On Wed, Apr 4, 2018 at 9:40 PM, Sean P. DeNigris <sean(a)clipperadams.com> >> wrote: >>> >>> Peter UhnÃ¡k wrote >>>> Would it be possible to instead have a #haltIf object to which you can >>>> send >>>> additional conditions? >>> >>> Maybe we could use that as an excuse to clean more halting out of object >>> completely e.g. >>> self halt now >>> self halt once >>> self halt ifInsideTest >>> self halt ifOutsideTest >>> self halt xyz >>> >>> Although IIRC when we first started cleaning the idea was too eventually >>> remove all halt-related stuff from Object and only have `Halt xyz`. At the >>> time, it seemed that was a little too scary, but even today I do not >>> understand what objectively is gained by `self halt` vs. `Halt now`â¦ > > One (very small) advantage of having 'self halt' is that a few times > I've had a single, long, expression that I want to halt in, and since > #halt returns self it is easy to insert it in the middle of an > expression. > Yes, and we should make sure to keep that. Marcus

April 5, 2018

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

by Marcus Denker

> On 4 Apr 2018, at 09:58, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Would it be possible to instead have a #haltIf object to which you can send additional conditions? > > E.g. > > self haltIf insideTest > self haltIf outsideTest > > Makes it (imho) a bit more readable, adds just a single method to Object, and allows for more potential extensions... > > self haltIf nil. > self haltIf count: 3. > Interesting. I will make a not. Another thing to think about is that all this âcombinationâ stuff might be where a BreakPoint system with a good UI actually starts to be better than a textual halt. The power of the Smalltalk #halt lies to some extend it its radical simplicity. Marcus

April 5, 2018

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

by Marcus Denker

> On 3 Apr 2018, at 21:56, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > > Nice addition! > I should say that names are not really intention revealing. > What about haltIfTestExecutionEnvironment and haltIfDefaultExecutionEnvironment ? > To long and too implementation centered. I would even shorten it to haltIfTest and haltIfNotTest. >> Le 2 avr. 2018 Ã 21:12, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> a Ã©crit : >> >> Hi, >> >> As we can not very easily decide if we are inside a test execution or not there was the idea to have special #halt messages >> >> https://pharo.fogbugz.com/f/cases/20151/new-halt-messages <https://pharo.fogbugz.com/f/cases/20151/new-halt-messages> >> >> This PR implements them: >> >> https://github.com/pharo-project/pharo/pull/1177 <https://github.com/pharo-project/pharo/pull/1177> >> >> There is now #haltIfInsideTest and #haltfOutsideTest. In addition, the PR adds a helper method to make checking if the current >> execution environment is a test run a bit easier: "CurrentExecutionEnvironment value isTestâ. >> >> Marcus >

April 5, 2018

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

by Marcus Denker

> On 4 Apr 2018, at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Very cool. Impressive combination of unique Pharo features. > It shows, too, that âdoing an experiment on topâ and then writing a paper is one thing, but that true progress happens if you can actually integrate the results back into the system. Marcus

April 5, 2018

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

by Marcus Denker

> On 4 Apr 2018, at 22:41, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Yes this is cool. > I was wondering what if you try and modify the Meta-Link architecture itself, but my brain did not reach this second meta level... > for now all Links are ignored that are put in the MetaLink itselfâ¦ but that was more a bootstrap thing. Now that we added more fine-grained control and better recession stopping, this can for sure be simplified. But for âmeta useâ to put a knot in the brain, the next level is not that, but instead âjustâ using links to install links at runtime or Links that enable/disable other links. Marcus

April 5, 2018

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

by Alistair Grant

On 4 April 2018 at 22:20, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > If we remove self halt, then I won't be able to use `1halt.`. :-D which is > actually what I always do, because writing `self halt` is 4 characters tooo > long. :) > > On Wed, Apr 4, 2018 at 9:40 PM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: >> >> Peter UhnÃ¡k wrote >> > Would it be possible to instead have a #haltIf object to which you can >> > send >> > additional conditions? >> >> Maybe we could use that as an excuse to clean more halting out of object >> completely e.g. >> self halt now >> self halt once >> self halt ifInsideTest >> self halt ifOutsideTest >> self halt xyz >> >> Although IIRC when we first started cleaning the idea was too eventually >> remove all halt-related stuff from Object and only have `Halt xyz`. At the >> time, it seemed that was a little too scary, but even today I do not >> understand what objectively is gained by `self halt` vs. `Halt now`â¦ One (very small) advantage of having 'self halt' is that a few times I've had a single, long, expression that I want to halt in, and since #halt returns self it is easy to insert it in the middle of an expression. Cheers, Alistair

April 5, 2018

[Pharo 7.0-dev] Build #755: 21676-TabMorph-throw-an-error-when-the-theme-change

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

There is a new Pharo build available! The status of the build #755 was: SUCCESS. The Pull Request #1181 was integrated: "21676-TabMorph-throw-an-error-when-the-theme-change" Pull request url: https://github.com/pharo-project/pharo/pull/1181 Issue Url: https://pharo.fogbugz.com/f/cases/21676 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 4, 2018

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

by Nicolas Cellier

Yes this is cool. I was wondering what if you try and modify the Meta-Link architecture itself, but my brain did not reach this second meta level... 2018-04-04 21:50 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Very cool. Impressive combination of unique Pharo features. > > > 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. > > > > So how do we implement that? > > > > 1) menu in the browser. I did a quick hack, a Suggestions AST menu shows > for all nodes (to be replaced with the âcorrectâ way later). > > > > SugsSuggestion subclass: #SugsAcceptForTest > > instanceVariableNames: '' > > classVariableNames: '' > > package: 'SmartSuggestions-Suggestionâ > > > > label > > ^'Accept for testâ > > > > So, now we can do everything in the #execute method. > > > > What do we need? > > > > 1) How we know that we are in a test? â> CurrentExecutionEnvironment > value isTest > > 2) can we compile the buffer even if there are syntax errors (kind of > what I expect to happen in non-accepted code)? > > â> yes, remember, we use the same Parser for syntax highlighting > and we extended code-generation for SyntaxError Nodes > > in the past (it raises a syntax error at runtime, isnât > that kind off odd in a fun way?). > > > > newMethod := context selectedClass compiler > > source: context code; > > options: #(+ optionParseErrors); > > compile. > > > > 3) Now how to we âhook intoâ the execution of the original unchanged > method? We use a MetaLink. We install it as a before link on > > the RBMethodNode, the meta-object is a block. This block gets as > arguments the thisContext and the arguments of the original method > > and then just does what you want it do do: if we are in test, return > the result of the execution of the method we just compiled. > > (Closures are fun, we can just reference the outer temp newMethod, no > need to store it anywhere else explicitly): > > > > [ :aContext :args | > > CurrentExecutionEnvironment value isTest > > ifTrue: [ aContext return: (newMethod > valueWithReceiver: aContext receiver arguments: args) ] ]; > > > > Thus, all the code is this: > > > > execute > > | newMethod metaLink | > > âwe compile a new method from the not-accepted text editor. Allow > syntax errors" > > newMethod := context selectedClass compiler > > source: context code; > > options: #(+ optionParseErrors); > > compile. > > "the link executes the method we just created and returns" > > metaLink := MetaLink new > > metaObject: [ :aContext :args | > > CurrentExecutionEnvironment value isTest > > ifTrue: [ aContext return: (newMethod > valueWithReceiver: aContext receiver arguments: args) ] ]; > > selector: #value:value:; > > arguments: #(context arguments). > > context selectedMethod ast link: metaLink > > > > Cleanup we do not care as everything will be GCed as soon as we accept > the method for real. > > > > And it works! I did not test it too much, but it seems to do what it is > supposed to do. (but more tests and testing are for sure needed) > > https://github.com/pharo-project/pharo/pull/1182 > > > > Next step: move it to a better place in the menu. > > > > Marcus > > > > > > >

April 4, 2018

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

by Peter UhnÃ¡k

If we remove self halt, then I won't be able to use `1halt.`. :-D which is actually what I always do, because writing `self halt` is 4 characters tooo long. :) On Wed, Apr 4, 2018 at 9:40 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Peter UhnÃ¡k wrote > > Would it be possible to instead have a #haltIf object to which you can > > send > > additional conditions? > > Maybe we could use that as an excuse to clean more halting out of object > completely e.g. > self halt now > self halt once > self halt ifInsideTest > self halt ifOutsideTest > self halt xyz > > Although IIRC when we first started cleaning the idea was too eventually > remove all halt-related stuff from Object and only have `Halt xyz`. At the > time, it seemed that was a little too scary, but even today I do not > understand what objectively is gained by `self halt` vs. `Halt now`â¦ > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

April 4, 2018