Disable halt and breakpoints globally

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Disable halt and breakpoints globally

Esteban A. Maringolo
Hi,

I was bit by a bug in production I couldn't identify and it ended up
being a lost halt in the code that was hanging my whole image. So no
bug at all, a feature :-)

Is there a way to disable the #halt and breakpoints?
This way I could add such an expression (if existent) to my server
startup and avoid issues like this.

Regards!

Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Disable halt and breakpoints globally

Tim Mackinnon
Hi Esteban - its a good question (and I'm intrigued what can be done) - but for production aren't you automatically building a fresh image with a CI system... its pretty easy to do these days and this would stop that. Additionally you could add something to search for self halt, as a build step and fail your build on a non-zero result as well.

Tim

On Tue, 18 Aug 2020, at 9:46 PM, Esteban Maringolo wrote:

> Hi,
>
> I was bit by a bug in production I couldn't identify and it ended up
> being a lost halt in the code that was hanging my whole image. So no
> bug at all, a feature :-)
>
> Is there a way to disable the #halt and breakpoints?
> This way I could add such an expression (if existent) to my server
> startup and avoid issues like this.
>
> Regards!
>
> Esteban A. Maringolo
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Disable halt and breakpoints globally

hogoww
I never tried it, but doesn't the command debugging >> "remove all
breakpoints" fits for this purpose?

Pierre

On 19/08/2020 08:23, Tim Mackinnon wrote:

> Hi Esteban - its a good question (and I'm intrigued what can be done) - but for production aren't you automatically building a fresh image with a CI system... its pretty easy to do these days and this would stop that. Additionally you could add something to search for self halt, as a build step and fail your build on a non-zero result as well.
>
> Tim
>
> On Tue, 18 Aug 2020, at 9:46 PM, Esteban Maringolo wrote:
>> Hi,
>>
>> I was bit by a bug in production I couldn't identify and it ended up
>> being a lost halt in the code that was hanging my whole image. So no
>> bug at all, a feature :-)
>>
>> Is there a way to disable the #halt and breakpoints?
>> This way I could add such an expression (if existent) to my server
>> startup and avoid issues like this.
>>
>> Regards!
>>
>> Esteban A. Maringolo
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Disable halt and breakpoints globally

Steven Costiou-2
In reply to this post by Esteban A. Maringolo

Hi,

in Pharo 9/NewTools we added the possibility to disable a halt or a breakpoint through a checkbox in the inspector or from a view in the debugger.
For example this is an inspector on a test object:

When a halt is disabled this way, it is still in your code but instead of halting it logs into the Transcript.
We planned to have a global view somewhere with a global "checkbox" to enable/disable them all.
But this will be only for Pharo 9.

But to me it has interest only if you want to keep dormant debugging capabilities in production, that you awake when you have a problem that you need to debug.
Otherwise, I would do as Tim suggested and make sure there are no halts in the production image.

Steven.

 

Le 2020-08-18 22:46, Esteban Maringolo a écrit :

Hi,

I was bit by a bug in production I couldn't identify and it ended up
being a lost halt in the code that was hanging my whole image. So no
bug at all, a feature :-)

Is there a way to disable the #halt and breakpoints?
This way I could add such an expression (if existent) to my server
startup and avoid issues like this.

Regards!

Esteban A. Maringolo

 

Reply | Threaded
Open this post in threaded view
|

Re: Disable halt and breakpoints globally

Stéphane Ducasse
In reply to this post by Esteban A. Maringolo
Hi Esteban

We worked on being able to turn all the halt into dormant halt. (so that we could put a break point and toggle it when running scenario)
Now I do not know the status of it. But the idea was nice. 
@thomas? 

@esteban
What I would like is a simple widgets showing all the halts of the system 

package | class | method | and some actions to remove them or do something on them 

If you want to give a try doing this is Spec2 we will happily improve it and include it in Pharo.

S

On 18 Aug 2020, at 22:46, Esteban Maringolo <[hidden email]> wrote:

Hi,

I was bit by a bug in production I couldn't identify and it ended up
being a lost halt in the code that was hanging my whole image. So no
bug at all, a feature :-)

Is there a way to disable the #halt and breakpoints?
This way I could add such an expression (if existent) to my server
startup and avoid issues like this.

Regards!

Esteban A. Maringolo


--------------------------------------------
Stéphane Ducasse
03 59 35 87 52
Assistant: Aurore Dalle 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France

Reply | Threaded
Open this post in threaded view
|

Re: Disable halt and breakpoints globally

Steven Costiou-2
In reply to this post by Steven Costiou-2

So, I just checked and we have this view in Pharo 9 with all halts and breakpoints.

We just need to put a global checkbox to (de)activate everything at once (and polish a little bit the view).

 

Le 2020-08-19 10:11, Steven Costiou a écrit :

Hi,

in Pharo 9/NewTools we added the possibility to disable a halt or a breakpoint through a checkbox in the inspector or from a view in the debugger.
For example this is an inspector on a test object:

When a halt is disabled this way, it is still in your code but instead of halting it logs into the Transcript.
We planned to have a global view somewhere with a global "checkbox" to enable/disable them all.
But this will be only for Pharo 9.

But to me it has interest only if you want to keep dormant debugging capabilities in production, that you awake when you have a problem that you need to debug.
Otherwise, I would do as Tim suggested and make sure there are no halts in the production image.

Steven.

 

Le 2020-08-18 22:46, Esteban Maringolo a écrit :

Hi,

I was bit by a bug in production I couldn't identify and it ended up
being a lost halt in the code that was hanging my whole image. So no
bug at all, a feature :-)

Is there a way to disable the #halt and breakpoints?
This way I could add such an expression (if existent) to my server
startup and avoid issues like this.

Regards!

Esteban A. Maringolo

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Disable halt and breakpoints globally

Esteban A. Maringolo
In reply to this post by Tim Mackinnon
Hi Tim,

For production I'm building a new Smalltalk image (and a Docker image
as well) on each commit to master in my Gitlab repo.
I was suggested to add Lint check to the build process in order to
avoid being caught by something like this again.

But the halt that got me was a notification from the Glorp cache
telling the object that it was removed from it. So it was a particular
condition that doesn't happen very often in my development image, and
because I'm used to put halts here and there, ended up being commited
and pushed to master.

Best regards!

Esteban A. Maringolo

On Wed, Aug 19, 2020 at 3:24 AM Tim Mackinnon <[hidden email]> wrote:

>
> Hi Esteban - its a good question (and I'm intrigued what can be done) - but for production aren't you automatically building a fresh image with a CI system... its pretty easy to do these days and this would stop that. Additionally you could add something to search for self halt, as a build step and fail your build on a non-zero result as well.
>
> Tim
>
> On Tue, 18 Aug 2020, at 9:46 PM, Esteban Maringolo wrote:
> > Hi,
> >
> > I was bit by a bug in production I couldn't identify and it ended up
> > being a lost halt in the code that was hanging my whole image. So no
> > bug at all, a feature :-)
> >
> > Is there a way to disable the #halt and breakpoints?
> > This way I could add such an expression (if existent) to my server
> > startup and avoid issues like this.
> >
> > Regards!
> >
> > Esteban A. Maringolo
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: Disable halt and breakpoints globally

Esteban A. Maringolo
In reply to this post by Steven Costiou-2
There is a similar view in Pharo 8, the Browse breakpoints show breakpoints and halts as well.

However, I avoid using breakpoints because you cannot add/remove them within the debugger, and sometimes with nested blocks it is hard to specify which expression should get it.

Regards!

Esteban A. Maringolo


On Wed, Aug 19, 2020 at 5:27 AM Steven Costiou <[hidden email]> wrote:

So, I just checked and we have this view in Pharo 9 with all halts and breakpoints.

We just need to put a global checkbox to (de)activate everything at once (and polish a little bit the view).

 

Le 2020-08-19 10:11, Steven Costiou a écrit :

Hi,

in Pharo 9/NewTools we added the possibility to disable a halt or a breakpoint through a checkbox in the inspector or from a view in the debugger.
For example this is an inspector on a test object:

When a halt is disabled this way, it is still in your code but instead of halting it logs into the Transcript.
We planned to have a global view somewhere with a global "checkbox" to enable/disable them all.
But this will be only for Pharo 9.

But to me it has interest only if you want to keep dormant debugging capabilities in production, that you awake when you have a problem that you need to debug.
Otherwise, I would do as Tim suggested and make sure there are no halts in the production image.

Steven.

 

Le 2020-08-18 22:46, Esteban Maringolo a écrit :

Hi,

I was bit by a bug in production I couldn't identify and it ended up
being a lost halt in the code that was hanging my whole image. So no
bug at all, a feature :-)

Is there a way to disable the #halt and breakpoints?
This way I could add such an expression (if existent) to my server
startup and avoid issues like this.

Regards!

Esteban A. Maringolo

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Disable halt and breakpoints globally

Steven Costiou-2

Le 2020-08-19 15:24, Esteban Maringolo a écrit :

There is a similar view in Pharo 8, the Browse breakpoints show breakpoints and halts as well.
 
The P8 view does not allow for dynamic activation, and that logic is only in P9.
 
Steven.
 
 
 
 
However, I avoid using breakpoints because you cannot add/remove them within the debugger, and sometimes with nested blocks it is hard to specify which expression should get it.
 
Regards!

Esteban A. Maringolo

On Wed, Aug 19, 2020 at 5:27 AM Steven Costiou <[hidden email]> wrote:

So, I just checked and we have this view in Pharo 9 with all halts and breakpoints.

We just need to put a global checkbox to (de)activate everything at once (and polish a little bit the view).

Le 2020-08-19 10:11, Steven Costiou a écrit :

Hi,

in Pharo 9/NewTools we added the possibility to disable a halt or a breakpoint through a checkbox in the inspector or from a view in the debugger.
For example this is an inspector on a test object:

When a halt is disabled this way, it is still in your code but instead of halting it logs into the Transcript.
We planned to have a global view somewhere with a global "checkbox" to enable/disable them all.
But this will be only for Pharo 9.

But to me it has interest only if you want to keep dormant debugging capabilities in production, that you awake when you have a problem that you need to debug.
Otherwise, I would do as Tim suggested and make sure there are no halts in the production image.

Steven.

Le 2020-08-18 22:46, Esteban Maringolo a écrit :

Hi,

I was bit by a bug in production I couldn't identify and it ended up
being a lost halt in the code that was hanging my whole image. So no
bug at all, a feature :-)

Is there a way to disable the #halt and breakpoints?
This way I could add such an expression (if existent) to my server
startup and avoid issues like this.

Regards!

Esteban A. Maringolo