New and richer halt messages

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

New and richer halt messages

Stephane Ducasse-3
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Peter Uhnak
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Denis Kudriashov
In reply to this post by Stephane Ducasse-3
Hi

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. 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Denis Kudriashov
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?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

EstebanLM

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Denis Kudriashov
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]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Stephane Ducasse-3
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Stephane Ducasse-3
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?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Stephane Ducasse-3
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]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Sean P. DeNigris
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Denis Kudriashov

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 :)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Henrik-Nergaard

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 :)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Sean P. DeNigris
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Peter Uhnak
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Esteban A. Maringolo
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

CyrilFerlicot
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Stephane Ducasse-3
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Ben Coman


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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Stephane Ducasse-3
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...

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




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New and richer halt messages

Ben Coman


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





12
Loading...