re CM>>#hasBreakpoint
Locked
 
|
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 |
|
|
Hi Tobias,
there /are/ configurations. Two if then :-(. Eliot (phone) On Jul 6, 2015, at 3:03 AM, Tobias Pape <[hidden email]> 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 > > |
|
|
Hi Eliot
On 06.07.2015, at 15:40, Eliot Miranda <[hidden email]> 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? > Eliot (phone) > > On Jul 6, 2015, at 3:03 AM, Tobias Pape <[hidden email]> 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 |
|
|
Hi Tobias,
On Jul 6, 2015, at 8:07 AM, Tobias Pape <[hidden email]> wrote: > Hi Eliot > On 06.07.2015, at 15:40, Eliot Miranda <[hidden email]> 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? >> Eliot (phone) >> >> On Jul 6, 2015, at 3:03 AM, Tobias Pape <[hidden email]> 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 > > > |
|
|
On 06.07.2015, at 17:54, Eliot Miranda <[hidden email]> wrote: > Hi Tobias, > > On Jul 6, 2015, at 8:07 AM, Tobias Pape <[hidden email]> wrote: > >> Hi Eliot >> On 06.07.2015, at 15:40, Eliot Miranda <[hidden email]> 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 <[hidden email]> 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 |
|
|
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? On Mon, Jul 6, 2015 at 11:01 AM, Tobias Pape <[hidden email]> wrote: > > On 06.07.2015, at 17:54, Eliot Miranda <[hidden email]> wrote: > >> Hi Tobias, >> >> On Jul 6, 2015, at 8:07 AM, Tobias Pape <[hidden email]> wrote: >> >>> Hi Eliot >>> On 06.07.2015, at 15:40, Eliot Miranda <[hidden email]> 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 <[hidden email]> 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 > > > |
|
|
Hi Chris,
On Mon, Jul 6, 2015 at 9:05 AM, Chris Muller <[hidden email]> wrote: Could someone teach me about breakpoints? I've only ever done 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.
best,
Eliot |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |