- Pharo-dev - lists.pharo.org

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

by Holger Freyther

> On 5. Apr 2018, at 08:31, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > And it leads immediately (at least for me) that I start to get lots of ideasâ¦ > > so now we accept a single method for test. > > Why notâ¦ (random ideas) nice! Do we have this for collecting testcases and expected output as well? The tricky part might be to put the Class Under Test into the right state (and condense all duplicate test cases). holger

April 5, 2018

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

by Marcus Denker

> On 5 Apr 2018, at 09:09, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> 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. > And it leads immediately (at least for me) that I start to get lots of ideasâ¦ so now we accept a single method for test. Why notâ¦ (random ideas) -> For un-accepted code: Why not do something like this automatically at every keystroke? That is, after syntax highlight, we can just compile a method and store it as a method property on the original method (cost almost nothing). Then all those for an âimplicit layer" that e.g we can very easily activate for the dynamic extended of the exection of an expression in the playground. You could even open a playground that default to that. There can be a button in the browser ârun not acceptedâ. -> extend it so that you actually âaccept for layer Xâ, that is, you give a name to groups of these. -> and of course implement it that the whole group an be accepted as an atomic operation Marcus

April 5, 2018

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

by Marcus Denker

> On 5 Apr 2018, at 09:12, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> 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. > noteâ¦ I will make a note. Not a not. Marcus

April 5, 2018

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