Smalltalk › Pharo › Pharo Smalltalk Developers

New and richer halt messages

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

Stephane Ducasse-3

New and richer halt messages

I would love to have better halt messages.

For example I would like to have

- haltOnlyInTest

- haltOnlyOutOfTest

- haltOnlyMe that when I use this one disables all the other halt in the system.

Marcus it would be nice to brainstorm on these to improve our halt vocabulary.

Stef

Peter Uhnak

Re: New and richer halt messages

Also why was haltIfShiftPressed removed? (in favor of haltIf: [ Sensor shiftPressed ], which is harder to write, remember, and without autocompletion).

Peter

On Fri, Jun 02, 2017 at 08:52:39AM +0200, Stephane Ducasse wrote:

> I would love to have better halt messages.
>
> For example I would like to have
>
> - haltOnlyInTest
> - haltOnlyOutOfTest
> - haltOnlyMe that when I use this one disables all the other halt in the
> system.
>
> Marcus it would be nice to brainstorm on these to improve our halt
> vocabulary.
> Stef

Denis Kudriashov

Re: New and richer halt messages

In reply to this post by Stephane Ducasse-3

2017-06-02 8:52 GMT+02:00 Stephane Ducasse <[hidden email]>:

- haltOnlyInTest
- haltOnlyOutOfTest

With process specific variable CurrentExecutionEnvironment it should be very easy to implement. Halt will be delegated to DefaultExecutionEnvironment or TestExecutionEnvironment depending on current value.

Denis Kudriashov

Re: New and richer halt messages

In reply to this post by Stephane Ducasse-3

2017-06-02 8:52 GMT+02:00 Stephane Ducasse <[hidden email]>:

For example I would like to have

- haltOnlyInTest
- haltOnlyOutOfTest
- haltOnlyMe that when I use this one disables all the other halt in the system.

Another question: do we really want new halt messages or it is better to extend breakpoints based on metalinks?

EstebanLM

Re: New and richer halt messages

On 2 Jun 2017, at 09:28, Denis Kudriashov <[hidden email]> wrote:

2017-06-02 8:52 GMT+02:00 Stephane Ducasse <[hidden email]>:
For example I would like to have

- haltOnlyInTest
- haltOnlyOutOfTest
- haltOnlyMe that when I use this one disables all the other halt in the system.

Another question: do we really want new halt messages or it is better to extend breakpoints based on metalinks?

I would go for metalinks.

Esteban

Denis Kudriashov

Re: New and richer halt messages

In reply to this post by Denis Kudriashov

2017-06-02 9:26 GMT+02:00 Denis Kudriashov <[hidden email]>:

2017-06-02 8:52 GMT+02:00 Stephane Ducasse <[hidden email]>:
- haltOnlyInTest
- haltOnlyOutOfTest

With process specific variable CurrentExecutionEnvironment it should be very easy to implement. Halt will be delegated to DefaultExecutionEnvironment or TestExecutionEnvironment depending on current value.

And you are able to do it right now with following scripts:

- haltOnlyInTest

self haltIf: [ CurrentExecutionEnvironment value isKindOf: TestExecutionEnvironment]

- haltOnlyOutOfTest

self haltIf: [ CurrentExecutionEnvironment value isKindOf: DefaultExecutionEnvironment]

Stephane Ducasse-3

Re: New and richer halt messages

In reply to this post by Peter Uhnak

We will added back because it is nice indeed.

On Fri, Jun 2, 2017 at 8:57 AM, Peter Uhnak <[hidden email]> wrote:

Also why was haltIfShiftPressed removed? (in favor of haltIf: [ Sensor shiftPressed ], which is harder to write, remember, and without autocompletion).

Peter

On Fri, Jun 02, 2017 at 08:52:39AM +0200, Stephane Ducasse wrote:
> I would love to have better halt messages.
>
> For example I would like to have
>
> - haltOnlyInTest
> - haltOnlyOutOfTest
> - haltOnlyMe that when I use this one disables all the other halt in the
> system.
>
> Marcus it would be nice to brainstorm on these to improve our halt
> vocabulary.
> Stef

Stephane Ducasse-3

Re: New and richer halt messages

In reply to this post by Denis Kudriashov

I would go for simplicity. If we have a simple way to build then no need for metalink machinery

On Fri, Jun 2, 2017 at 9:28 AM, Denis Kudriashov <[hidden email]> wrote:

2017-06-02 8:52 GMT+02:00 Stephane Ducasse <[hidden email]>:
For example I would like to have

- haltOnlyInTest
- haltOnlyOutOfTest
- haltOnlyMe that when I use this one disables all the other halt in the system.

Another question: do we really want new halt messages or it is better to extend breakpoints based on metalinks?

Stephane Ducasse-3

Re: New and richer halt messages

In reply to this post by Denis Kudriashov

Excellent!

We should add them to the system.

On Fri, Jun 2, 2017 at 10:00 AM, Denis Kudriashov <[hidden email]> wrote:

2017-06-02 9:26 GMT+02:00 Denis Kudriashov <[hidden email]>:
2017-06-02 8:52 GMT+02:00 Stephane Ducasse <[hidden email]>:
- haltOnlyInTest
- haltOnlyOutOfTest

With process specific variable CurrentExecutionEnvironment it should be very easy to implement. Halt will be delegated to DefaultExecutionEnvironment or TestExecutionEnvironment depending on current value.

And you are able to do it right now with following scripts:

- haltOnlyInTest

self haltIf: [ CurrentExecutionEnvironment value isKindOf: TestExecutionEnvironment]

- haltOnlyOutOfTest

self haltIf: [ CurrentExecutionEnvironment value isKindOf: DefaultExecutionEnvironment]

Sean P. DeNigris

Re: New and richer halt messages

Administrator

In reply to this post by Stephane Ducasse-3

To mirror the existing API, what do you think of:
- haltOnlyInTest -> #haltIfTest
- haltOnlyOutOfTest -> #haltIfNotTest
- haltOnlyMe -> #haltOnly

Cheers,
Sean

Denis Kudriashov

Re: New and richer halt messages

2017-06-03 15:21 GMT+02:00 Sean P. DeNigris <[hidden email]>:

To mirror the existing API, what do you think of:
- haltOnlyInTest -> #haltIfTest
- haltOnlyOutOfTest -> #haltIfNotTest
- haltOnlyMe -> #haltOnly

good names. We need right english overview :)

Henrik-Nergaard

Re: New and richer halt messages

Sounds like a good idea, but please implement them as constructors/class side methods in Halt instead of adding even more methods to Object.

"self haltIfTest -> Halt ifTest"

Best regards,

Henrik

Fra: Pharo-dev <[hidden email]> på vegne av Denis Kudriashov <[hidden email]>
Sendt: 3. juni 2017 21:30:37
Til: Pharo Development List
Emne: Re: [Pharo-dev] New and richer halt messages

2017-06-03 15:21 GMT+02:00 Sean P. DeNigris <[hidden email]>:

To mirror the existing API, what do you think of:
- haltOnlyInTest -> #haltIfTest
- haltOnlyOutOfTest -> #haltIfNotTest
- haltOnlyMe -> #haltOnly

good names. We need right english overview :)

Sean P. DeNigris

Re: New and richer halt messages

Administrator

Henrik-Nergaard wrote

Sounds like a good idea, but please implement them as constructors/class side methods in Halt instead of adding even more methods to Object.

You're speaking my language! When Stephan Eggermont and I paired at ESUG creating the Halt API, we wanted to remove all the Object methods, but we were advised not to scare the users too much ha ha. Maybe the time has finally come?!

Cheers,
Sean

Peter Uhnak

Re: New and richer halt messages

On Sat, Jun 03, 2017 at 02:46:30PM -0700, Sean P. DeNigris wrote:
> Henrik-Nergaard wrote
> > Sounds like a good idea, but please implement them as constructors/class
> > side methods in Halt instead of adding even more methods to Object.
>
> You're speaking my language! When Stephan Eggermont and I paired at ESUG
> creating the Halt API, we wanted to remove all the Object methods, but we
> were advised not to scare the users too much ha ha. Maybe the time has
> finally come?!

But then I wouldn't be able to write 1halt. :(

Peter

Esteban A. Maringolo

Re: New and richer halt messages

2017-06-04 6:40 GMT-03:00 Peter Uhnak <[hidden email]>:

> On Sat, Jun 03, 2017 at 02:46:30PM -0700, Sean P. DeNigris wrote:
>> Henrik-Nergaard wrote
>> > Sounds like a good idea, but please implement them as constructors/class
>> > side methods in Halt instead of adding even more methods to Object.
>>
>> You're speaking my language! When Stephan Eggermont and I paired at ESUG
>> creating the Halt API, we wanted to remove all the Object methods, but we
>> were advised not to scare the users too much ha ha. Maybe the time has
>> finally come?!
>
> But then I wouldn't be able to write 1halt. :(

I'd only leave #halt in Object, anything else goes to Halt class.

I became a user of "1 halt" as well.

Esteban A. Maringolo

CyrilFerlicot

Re: New and richer halt messages

In reply to this post by Peter Uhnak

Le 04/06/2017 à 11:40, Peter Uhnak a écrit :
> But then I wouldn't be able to write 1halt. :(
>
> Peter
>

You can still add some startup script :)

I have one compiling a "h" method in object calling halt to be able to
write "1h" :)

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

signature.asc (836 bytes) Download Attachment

Stephane Ducasse-3

Re: New and richer halt messages

What we should consider is that well packaged methods can be in Object.

The problem is when method in Object are used everywhere and that they have nothing to do there.

About

Halt only does not convey anything to me.

Halt onlyMe means clearly what is it

For the

Halt ifTest

Halt ifNotTest

Why not. But I would prefer to be really clear.

I would prefer

Halt ifInsideTest

Halt ifOutsideTest

Because we are not about a couple of characters.

Stef

On Sun, Jun 4, 2017 at 3:09 PM, Cyril Ferlicot D. <[hidden email]> wrote:

Le 04/06/2017 à 11:40, Peter Uhnak a écrit :
> But then I wouldn't be able to write 1halt. :(
>
> Peter
>

You can still add some startup script :)

I have one compiling a "h" method in object calling halt to be able to
write "1h" :)

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

Ben Coman

Re: New and richer halt messages

On Mon, Jun 5, 2017 at 5:06 AM, Stephane Ducasse <[hidden email]> wrote:

What we should consider is that well packaged methods can be in Object.
The problem is when method in Object are used everywhere and that they have nothing to do there.

About
Halt only does not convey anything to me.
Halt onlyMe means clearly what is it

To me it seems strange/awkward that code in one method will change global debugging state,

and it would feel better via direct UI action to add a metalink (IIUC how that would work.)

Plus also a global GUI tool to manage breakpoints/metalinks would be good.

For the
Halt ifTest
Halt ifNotTest

Why not. But I would prefer to be really clear.
I would prefer

Halt ifInsideTest
Halt ifOutsideTest

These sound good.

cheers -ben

Because we are not about a couple of characters.

Stef

On Sun, Jun 4, 2017 at 3:09 PM, Cyril Ferlicot D. <[hidden email]> wrote:
Le 04/06/2017 à 11:40, Peter Uhnak a écrit :
> But then I wouldn't be able to write 1halt. :(
>
> Peter
>

You can still add some startup script :)

I have one compiling a "h" method in object calling halt to be able to
write "1h" :)

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

Stephane Ducasse-3

Re: New and richer halt messages

About
Halt only does not convey anything to me.
Halt onlyMe means clearly what is it

To me it seems strange/awkward that code in one method will change global debugging state,

and it would feel better via direct UI action to add a metalink (IIUC how that would work.)

Plus also a global GUI tool to manage breakpoints/metalinks would be good.

Yes but when you need you need it.

Else what is the alternative:

- remove all the halt during the execution.

- execute yours

- put back the halt if something wrong happens.

- create manually a global.

- rewrite all your halt to depend on this global

- turn on and off the global to get the desired effects...

Tedious, cumbersome and boring.

We can do better.

On Mon, Jun 5, 2017 at 4:09 AM, Ben Coman <[hidden email]> wrote:

On Mon, Jun 5, 2017 at 5:06 AM, Stephane Ducasse <[hidden email]> wrote:
What we should consider is that well packaged methods can be in Object.
The problem is when method in Object are used everywhere and that they have nothing to do there.

About
Halt only does not convey anything to me.
Halt onlyMe means clearly what is it

To me it seems strange/awkward that code in one method will change global debugging state,
and it would feel better via direct UI action to add a metalink (IIUC how that would work.)
Plus also a global GUI tool to manage breakpoints/metalinks would be good.

For the
Halt ifTest
Halt ifNotTest

Why not. But I would prefer to be really clear.
I would prefer

Halt ifInsideTest
Halt ifOutsideTest

These sound good.
cheers -ben

Because we are not about a couple of characters.

Stef

On Sun, Jun 4, 2017 at 3:09 PM, Cyril Ferlicot D. <[hidden email]> wrote:
Le 04/06/2017 à 11:40, Peter Uhnak a écrit :
> But then I wouldn't be able to write 1halt. :(
>
> Peter
>

You can still add some startup script :)

I have one compiling a "h" method in object calling halt to be able to
write "1h" :)

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

Ben Coman

Re: New and richer halt messages

On Mon, Jun 5, 2017 at 5:01 PM, Stephane Ducasse <[hidden email]> wrote:

About
Halt only does not convey anything to me.
Halt onlyMe means clearly what is it

To me it seems strange/awkward that code in one method will change global debugging state,
and it would feel better via direct UI action to add a metalink (IIUC how that would work.)
Plus also a global GUI tool to manage breakpoints/metalinks would be good.

Yes but when you need you need it.
Else what is the alternative:
- remove all the halt during the execution.
- execute yours
- put back the halt if something wrong happens.

or
- create manually a global.
- rewrite all your halt to depend on this global
- turn on and off the global to get the desired effects...

or hypothetically something like... right-click code and menu select "break here, disable others"

cheers -ben

Tedious, cumbersome and boring.
We can do better.

On Mon, Jun 5, 2017 at 4:09 AM, Ben Coman <[hidden email]> wrote:

On Mon, Jun 5, 2017 at 5:06 AM, Stephane Ducasse <[hidden email]> wrote:
What we should consider is that well packaged methods can be in Object.
The problem is when method in Object are used everywhere and that they have nothing to do there.

About
Halt only does not convey anything to me.
Halt onlyMe means clearly what is it

To me it seems strange/awkward that code in one method will change global debugging state,
and it would feel better via direct UI action to add a metalink (IIUC how that would work.)
Plus also a global GUI tool to manage breakpoints/metalinks would be good.

For the
Halt ifTest
Halt ifNotTest

Why not. But I would prefer to be really clear.
I would prefer

Halt ifInsideTest
Halt ifOutsideTest

These sound good.
cheers -ben

Because we are not about a couple of characters.

Stef

On Sun, Jun 4, 2017 at 3:09 PM, Cyril Ferlicot D. <[hidden email]> wrote:
Le 04/06/2017 à 11:40, Peter Uhnak a écrit :
> But then I wouldn't be able to write 1halt. :(
>
> Peter
>

You can still add some startup script :)

I have one compiling a "h" method in object calling halt to be able to
write "1h" :)

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France