[squeak-dev] re CM>>#hasBreakpoint

Eliot Miranda eliot.miranda at gmail.com
Mon Jul 6 18:11:21 UTC 2015


Hi Chris,

On Mon, Jul 6, 2015 at 9:05 AM, Chris Muller <asqueaker at gmail.com> wrote:

> Could someone teach me about breakpoints?  I've only ever done
> "breakpoints" by inserting a old-school send to #halt, I'm not
> familiar with these new ways of interrupting execution.  How are they
> done and what is the advantage over halt?
>

The "toggle breakpoint on entry" takes care of inserting the break and
running the compile, or undoing the break, in one menu selection.  So it's
faster than using halt.  Also, it does not disturb the current change set
(it is not considered a change), nor does it create a version of the method
nor leave source on the changes file.  So it's cleaner.  Now that it
preserves source I prefer it to halt.  Previously it used to install a
breakpointed method with decompiled source, which was horrible if one
wanted to read comments or had trouble with the formatting.

WrappedBreakpoint is a step towards a more complete debugging package, but
it isn't used yet.

As a somewhat relevant aside, Terry Raymond of Crafted Smalltalk
implemented the Professional Debug Package for VisualWorks which provides
conditional breakpoints along with a comprehensive UI.  It's powerful and
nice to use.  While it's relatively easy to roll your own conditional
breakpoints above halt, it's nice not to have to think about it to heavily
(it's easy to make a mistake and the effects can be terminal :-) ).
Perhaps we'll evolve BreakpointManager in that direction.  For example,
adding a "toggle one-shot breakpoint"would be easy to add; for example
inserting breakonce instead of break could cause the breakpointed method to
be uninstalled immediately.



> On Mon, Jul 6, 2015 at 11:01 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> >
> > On 06.07.2015, at 17:54, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> >> Hi Tobias,
> >>
> >> On Jul 6, 2015, at 8:07 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> >>
> >>> Hi Eliot
> >>> On 06.07.2015, at 15:40, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >>>
> >>>> Hi Tobias,
> >>>>
> >>>> there /are/ configurations.  Two if then :-(.
> >>>
> >>> Sorry, it was just a guess because of the stack trace.
> >>>
> >>> So, I investigated.
> >>>
> >>>   update-eem.319.mcm:
> >>>       (CompiledMethod methodDict includesKay: #hasBreakpoint) "true"
> >>>
> >>>       CompiledMethod>>#hasBreakpoint
> >>>           ^BreakpointManager methodHasBreakpoint: self
> >>>
> >>>   update-eem.320.mcm:
> >>>       (CompiledMethod methodDict includesKey: #hasBreakpoint) "true"
> >>>
> >>>       CompiledMethod>>#hasBreakpoint
> >>>           ^false
> >>>
> >>>   update-eem.320.mcm:
> >>>       (CompiledMethod methodDict includesKey: #hasBreakpoint) "true"
> >>>
> >>>       CompiledMethod>>#hasBreakpoint
> >>>           ^false
> >>>
> >>>   Kernel-eem.934
> >>>
> >>>       (CompiledMethod methodDict includesKey: #hasBreakpoint)  "false"
> >>>
> >>>
> >>> Ahaa.
> >>> System misses to use an actual override and monticello thought the
> method had gone
> >>> when it was saved for Kernel-eem.934.
> >>> Soo:
> >>>   Kernel-topa.935: Reinstall CompiledMethod>>#hasBreakpoint
> >>>   System-topa.753: Reinstall CompiledMethod>>#hasBreakpoint as an
> Override
> >>> Jenkins seems to be happy:
> >>>   http://build.squeak.org/job/SqueakTrunk/1549/console
> >>>   http://build.squeak.org/job/SqueakTrunk/1549/
> >>>
> >>> I hope this fits everyones :)
> >>>
> >>> Best regards
> >>>   -Tobias
> >>>
> >>>
> >>> PS: Have you looked at WrappedBreakpoint?
> >>
> >> No.  I'll try and take a look.  What do you think the issue is?
> >
> > No issue, just an alternative way of doing breakpoints
> >
> >>
> >>>> Eliot (phone)
> >>>>
> >>>> On Jul 6, 2015, at 3:03 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> we might need a configuration for Eliot's recent #hasBreakpoint
> changes,
> >>>>> the CI (and probably any update process) chokes on this:
> >>>>>
> >>>>> 2015-07-06T11:27:54.732+01:00: Installing Kernel-eem.934
> >>>>> vvvvvvvvvvvvvvvvvv MessageNotUnderstood:
> CompiledMethod>>hasBreakpoint vvvvvvvvvvvvvvvvvv
> >>>>> The time is 2015-07-06T11:27:54.848+01:00
> >>>>> CompiledMethod(Object)>>doesNotUnderstand: #hasBreakpoint
> >>>>> MCMcmUpdater
> class(ClassDescription)>>logMethodSource:forMethodWithNode:inCategory:withStamp:notifying:
> >>>>> MethodAddition>>writeSourceToLog
> >>>>> MethodAddition>>createCompiledMethod
> >>>>> [] in [] in [] in [] in [] in MCPackageLoader>>basicLoad
> >>>>> [] in [] in
> OrderedCollection(Collection)>>do:displayingProgress:every:
> >>>>> OrderedCollection>>do:
> >>>>> [] in OrderedCollection(Collection)>>do:displayingProgress:every:
> >>>>> [] in [] in MorphicUIManager>>displayProgress:at:from:to:during:
> >>>>> BlockClosure>>on:do:
> >>>>> [] in MorphicUIManager>>displayProgress:at:from:to:during:
> >>>>> BlockClosure>>ensure:
> >>>>> MorphicUIManager>>displayProgress:at:from:to:during:
> >>>>> ProgressInitiationException>>defaultResumeValue
> >>>>> ProgressInitiationException(Exception)>>resume
> >>>>> [] in [] in UndefinedObject>>DoIt
> >>>>>
> >>>>> Best regards
> >>>>> -Tobias
> >
> >
> >
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150706/2f93638c/attachment.htm


More information about the Squeak-dev mailing list