[Pharo7] halt inside and outside tests
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
On 3 April 2018 at 03:12, Marcus Denker <marcus.denker@inria.fr> wrote:
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. I
Should the standard #halt default to one of these? Or left as is? (I've no clue, just the question arises). cheers -ben
On 3 Apr 2018, at 00:19, Ben Coman <btc@openinworld.com> wrote:
On 3 April 2018 at 03:12, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote: 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. I
Should the standard #halt default to one of these? Or left as is? (I've no clue, just the question arises).
I would keep it for now as is.. it is the simplest to have one âhaltâ that always halts and then variants (there is halt once, too, which makes often more sense than #halt). Marcus
+1 Doru
On Apr 3, 2018, at 9:09 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 3 Apr 2018, at 00:19, Ben Coman <btc@openinworld.com> wrote:
On 3 April 2018 at 03:12, Marcus Denker <marcus.denker@inria.fr> wrote: 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. I
Should the standard #halt default to one of these? Or left as is? (I've no clue, just the question arises).
I would keep it for now as is.. it is the simplest to have one âhaltâ that always halts and then variants (there is halt once, too, which makes often more sense than #halt).
Marcus
-- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."
+ 1 I really want to use these new friends because I use this pattern really a lot when coding. Tx I wanted to do that during the last sprint. On Tue, Apr 3, 2018 at 9:09 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 3 Apr 2018, at 00:19, Ben Coman <btc@openinworld.com> wrote:
On 3 April 2018 at 03:12, Marcus Denker <marcus.denker@inria.fr> wrote:
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. I
Should the standard #halt default to one of these? Or left as is? (I've no clue, just the question arises).
I would keep it for now as is.. it is the simplest to have one âhaltâ that always halts and then variants (there is halt once, too, which makes often more sense than #halt).
Marcus
Nice addition! I should say that names are not really intention revealing. What about haltIfTestExecutionEnvironment and haltIfDefaultExecutionEnvironment ?
Le 2 avr. 2018 à 21:12, Marcus Denker <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
demarey wrote
What about haltIfTestExecutionEnvironment and haltIfDefaultExecutionEnvironment ?
I thought the names were okay. What did you think was unclear about them? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Le 4 avr. 2018 à 04:34, Sean P. DeNigris <sean@clipperadams.com> a écrit :
demarey wrote
What about haltIfTestExecutionEnvironment and haltIfDefaultExecutionEnvironment ?
I thought the names were okay. What did you think was unclear about them?
At a first look #haltInsideTest and #haltOutsideTest do not tell me that they are conditional breakpoints. maybe just add a if would solve that: #haltIfInsideTest #haltIfOutsideTest
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. etc? Peter On Wed, Apr 4, 2018 at 8:36 AM, Christophe Demarey < christophe.demarey@inria.fr> wrote:
Le 4 avr. 2018 à 04:34, Sean P. DeNigris <sean@clipperadams.com> a écrit :
demarey wrote
What about haltIfTestExecutionEnvironment and haltIfDefaultExecutionEnvironment ?
I thought the names were okay. What did you think was unclear about them?
At a first look #haltInsideTest and #haltOutsideTest do not tell me that they are conditional breakpoints. maybe just add a if would solve that: #haltIfInsideTest #haltIfOutsideTest
That could be nice!! Maybe having a prototype allows us to see more usages! On Wed, Apr 4, 2018 at 9:58 AM, Peter Uhnák <i.uhnak@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.
etc?
Peter
On Wed, Apr 4, 2018 at 8:36 AM, Christophe Demarey < christophe.demarey@inria.fr> wrote:
Le 4 avr. 2018 à 04:34, Sean P. DeNigris <sean@clipperadams.com> a écrit :
demarey wrote
What about haltIfTestExecutionEnvironment and haltIfDefaultExecutionEnvironment ?
I thought the names were okay. What did you think was unclear about them?
At a first look #haltInsideTest and #haltOutsideTest do not tell me that they are conditional breakpoints. maybe just add a if would solve that: #haltIfInsideTest #haltIfOutsideTest
-- Pablo Tesone. tesonep@gmail.com
Why not RIght now I would like to use them to see how they fit my process. On Wed, Apr 4, 2018 at 9:58 AM, Peter Uhnák <i.uhnak@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.
etc?
Peter
On Wed, Apr 4, 2018 at 8:36 AM, Christophe Demarey <christophe.demarey@inria.fr> wrote:
Le 4 avr. 2018 à 04:34, Sean P. DeNigris <sean@clipperadams.com> a écrit :
demarey wrote
What about haltIfTestExecutionEnvironment and haltIfDefaultExecutionEnvironment ?
I thought the names were okay. What did you think was unclear about them?
At a first look #haltInsideTest and #haltOutsideTest do not tell me that they are conditional breakpoints. maybe just add a if would solve that: #haltIfInsideTest #haltIfOutsideTest
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
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@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
On 4 April 2018 at 22:20, Peter Uhnák <i.uhnak@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@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
On 5 Apr 2018, at 07:26, Alistair Grant <akgrant0710@gmail.com> wrote:
On 4 April 2018 at 22:20, Peter Uhnák <i.uhnak@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@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
We do not plan to remove self halt. We plan to have better code expansion :) like ctrl sh => self halt :) Stef On Thu, Apr 5, 2018 at 7:26 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
On 4 April 2018 at 22:20, Peter Uhnák <i.uhnak@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@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
On 4 Apr 2018, at 09:58, Peter Uhnák <i.uhnak@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
On 5 Apr 2018, at 09:12, Marcus Denker <marcus.denker@inria.fr> wrote:
On 4 Apr 2018, at 09:58, Peter Uhnák <i.uhnak@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
This is fun but I was confused and when I read with the if it makes a lot more sense. Tx christophe On Wed, Apr 4, 2018 at 8:36 AM, Christophe Demarey <christophe.demarey@inria.fr> wrote:
Le 4 avr. 2018 à 04:34, Sean P. DeNigris <sean@clipperadams.com> a écrit :
demarey wrote
What about haltIfTestExecutionEnvironment and haltIfDefaultExecutionEnvironment ?
I thought the names were okay. What did you think was unclear about them?
At a first look #haltInsideTest and #haltOutsideTest do not tell me that they are conditional breakpoints. maybe just add a if would solve that: #haltIfInsideTest #haltIfOutsideTest
On 3 Apr 2018, at 21:56, Christophe Demarey <christophe.demarey@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@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
2018-04-05 9:10 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:
On 3 Apr 2018, at 21:56, Christophe Demarey <christophe.demarey@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@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
Denis Kudriashov wrote
I would even shorten it to haltIfTest and haltIfNotTest.
Sounds good. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Marcus I think that the if is important because I had hard time to understand how I should use it and I proposed them. On Thu, Apr 5, 2018 at 9:10 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 3 Apr 2018, at 21:56, Christophe Demarey <christophe.demarey@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@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
On 5 Apr 2018, at 09:10, Marcus Denker <marcus.denker@inria.fr> wrote:
On 3 Apr 2018, at 21:56, Christophe Demarey <christophe.demarey@inria.fr <mailto:christophe.demarey@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.
https://github.com/pharo-project/pharo/pull/1187/files <https://github.com/pharo-project/pharo/pull/1187/files> I simplified them further and added test (will be in the next build) Marcus
Thanks!!!! On Tue, Apr 10, 2018 at 11:23 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 5 Apr 2018, at 09:10, Marcus Denker <marcus.denker@inria.fr> wrote:
On 3 Apr 2018, at 21:56, Christophe Demarey <christophe.demarey@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.
https://github.com/pharo-project/pharo/pull/1187/files
I simplified them further and added test (will be in the next build)
Marcus
participants (10)
-
Alistair Grant -
Ben Coman -
Christophe Demarey -
Denis Kudriashov -
Marcus Denker -
Peter Uhnák -
Sean P. DeNigris -
Stephane Ducasse -
tesonep＠gmail.com -
Tudor Girba