Re: [Pharo-dev] New and richer halt messages

2017-06-06 Thread Ben Coman
phane > Ducasse <stepharo.s...@gmail.com> > *Sendt:* 5. juni 2017 20:57:43 > *Til:* Pharo Development List > *Emne:* Re: [Pharo-dev] New and richer halt messages > > Could be but I like to have message too. Relying too much on tools is > good but when suddently do not ha

Re: [Pharo-dev] New and richer halt messages

2017-06-06 Thread Henrik Nergaard
s, Henrik Fra: Pharo-dev <pharo-dev-boun...@lists.pharo.org> på vegne av Stephane Ducasse <stepharo.s...@gmail.com> Sendt: 5. juni 2017 20:57:43 Til: Pharo Development List Emne: Re: [Pharo-dev] New and richer halt messages Could be but I like to have message

Re: [Pharo-dev] New and richer halt messages

2017-06-05 Thread Stephane Ducasse
Could be but I like to have message too. Relying too much on tools is good but when suddently do not have tools because you are in a minimal kernel then having 3 extra messages should like a good win win situation. Stef On Mon, Jun 5, 2017 at 4:06 PM, Ben Coman wrote: > >

Re: [Pharo-dev] New and richer halt messages

2017-06-05 Thread Ben Coman
On Mon, Jun 5, 2017 at 5:01 PM, Stephane Ducasse 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

Re: [Pharo-dev] New and richer halt messages

2017-06-05 Thread Stephane Ducasse
> > 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

Re: [Pharo-dev] New and richer halt messages

2017-06-04 Thread Ben Coman
On Mon, Jun 5, 2017 at 5:06 AM, Stephane Ducasse 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

Re: [Pharo-dev] New and richer halt messages

2017-06-04 Thread Stephane Ducasse
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

Re: [Pharo-dev] New and richer halt messages

2017-06-04 Thread Cyril Ferlicot D.
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

Re: [Pharo-dev] New and richer halt messages

2017-06-04 Thread Esteban A. Maringolo
2017-06-04 6:40 GMT-03:00 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

Re: [Pharo-dev] New and richer halt messages

2017-06-04 Thread 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

Re: [Pharo-dev] New and richer halt messages

2017-06-03 Thread Sean P. DeNigris
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

Re: [Pharo-dev] New and richer halt messages

2017-06-03 Thread Henrik Nergaard
org> på vegne av Denis Kudriashov <dionisi...@gmail.com> 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 <s...@clipperadams.com<mailto:s...@clipperadams.com>>: To mirro

Re: [Pharo-dev] New and richer halt messages

2017-06-03 Thread Denis Kudriashov
2017-06-03 15:21 GMT+02:00 Sean P. DeNigris : > To mirror the existing API, what do you think of: > - haltOnlyInTest -> #haltIfTest > - haltOnlyOutOfTest -> #haltIfNotTest > - haltOnlyMe -> #haltOnly > good names. We need right english overview :)

Re: [Pharo-dev] New and richer halt messages

2017-06-03 Thread Sean P. DeNigris
To mirror the existing API, what do you think of: - haltOnlyInTest -> #haltIfTest - haltOnlyOutOfTest -> #haltIfNotTest - haltOnlyMe -> #haltOnly - Cheers, Sean -- View this message in context: http://forum.world.st/New-and-richer-halt-messages-tp4948920p4949162.html Sent from the

Re: [Pharo-dev] New and richer halt messages

2017-06-02 Thread Stephane Ducasse
Excellent! We should add them to the system. On Fri, Jun 2, 2017 at 10:00 AM, Denis Kudriashov wrote: > > 2017-06-02 9:26 GMT+02:00 Denis Kudriashov : > >> 2017-06-02 8:52 GMT+02:00 Stephane Ducasse : >> >>> - haltOnlyInTest

Re: [Pharo-dev] New and richer halt messages

2017-06-02 Thread Stephane Ducasse
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 wrote: > > 2017-06-02 8:52 GMT+02:00 Stephane Ducasse : > >> For example I would like to have >> >> -

Re: [Pharo-dev] New and richer halt messages

2017-06-02 Thread Stephane Ducasse
We will added back because it is nice indeed. On Fri, Jun 2, 2017 at 8:57 AM, Peter Uhnak wrote: > Also why was haltIfShiftPressed removed? (in favor of haltIf: [ Sensor > shiftPressed ], which is harder to write, remember, and without > autocompletion). > > Peter > > On Fri,

Re: [Pharo-dev] New and richer halt messages

2017-06-02 Thread Denis Kudriashov
2017-06-02 9:26 GMT+02:00 Denis Kudriashov : > 2017-06-02 8:52 GMT+02:00 Stephane Ducasse : > >> - haltOnlyInTest >> - haltOnlyOutOfTest >> > > With process specific variable CurrentExecutionEnvironment it should be > very easy to implement. Halt

Re: [Pharo-dev] New and richer halt messages

2017-06-02 Thread Esteban Lorenzano
> On 2 Jun 2017, at 09:28, Denis Kudriashov wrote: > > > 2017-06-02 8:52 GMT+02:00 Stephane Ducasse >: > For example I would like to have > > - haltOnlyInTest > - haltOnlyOutOfTest > - haltOnlyMe that

Re: [Pharo-dev] New and richer halt messages

2017-06-02 Thread Denis Kudriashov
2017-06-02 8:52 GMT+02:00 Stephane Ducasse : > 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

Re: [Pharo-dev] New and richer halt messages

2017-06-02 Thread Denis Kudriashov
Hi 2017-06-02 8:52 GMT+02:00 Stephane Ducasse : > - haltOnlyInTest > - haltOnlyOutOfTest > With process specific variable CurrentExecutionEnvironment it should be very easy to implement. Halt will be delegated to DefaultExecutionEnvironment or TestExecutionEnvironment

Re: [Pharo-dev] New and richer halt messages

2017-06-02 Thread 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

[Pharo-dev] New and richer halt messages

2017-06-02 Thread Stephane Ducasse
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