Hi All,
another change planned for Squeak 6 is eliminating ContextPart & MethodContext in favor of Context. In reviewing the (very few) changes necessary I came across the following:
MethodContext>>printString "Answer an emphasized string in case of a breakpoint method"
^(self method notNil and: [self method hasBreakpoint]) ifTrue:[(super printString , ' [break]') asText allBold] ifFalse:[super printString]
Seriously? I don't object to modifying [Method]Conext>>printOn: to include [break] but having printString answer a text seems completely broken to me, and overriding printString is a hack; printOn: being the operative method for producing self-descriptions. Should we nuke it and add [break] to printOn:? Or...?
_,,,^..^,,,_ best, Eliot
Hi Eliot
Good catch.
As the method name #printString says it should return a string.
But
(super printString , ' [break]') asText allBold
returns an instance of the class Text which is wrong in this context.
What about just
super printString , ' [break]')
?
--Hannes
BTW the method has been there since 2007....
On 3/29/17, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
another change planned for Squeak 6 is eliminating ContextPart &MethodContext in favor of Context. In reviewing the (very few) changes necessary I came across the following:
MethodContext>>printString "Answer an emphasized string in case of a breakpoint method"
^(self method notNil and: [self method hasBreakpoint]) ifTrue:[(super printString , ' [break]') asText allBold] ifFalse:[super printString]
Seriously? I don't object to modifying [Method]Conext>>printOn: to include [break] but having printString answer a text seems completely broken to me, and overriding printString is a hack; printOn: being the operative method for producing self-descriptions. Should we nuke it and add [break] to printOn:? Or...?
_,,,^..^,,,_ best, Eliot
On Wed, 29 Mar 2017, Eliot Miranda wrote:
Hi All, another change planned for Squeak 6 is eliminating ContextPart & MethodContext in favor of Context. In reviewing the (very few) changes necessary I came across the following:
MethodContext>>printString "Answer an emphasized string in case of a breakpoint method"
^(self method notNil and: [self method hasBreakpoint]) ifTrue:[(super printString , ' [break]') asText allBold] ifFalse:[super printString]
Seriously? I don't object to modifying [Method]Conext>>printOn: to include [break] but having printString answer a text seems completely broken to me, and overriding printString is a hack; printOn: being the operative method for producing self-descriptions. Should we nuke it and add [break] to printOn:? Or...?
Nuke it. AFAIK breakpoints never worked.
Levente
_,,,^..^,,,_ best, Eliot
On 29.03.2017, at 23:16, Levente Uzonyi leves@caesar.elte.hu wrote:
On Wed, 29 Mar 2017, Eliot Miranda wrote:
Hi All, another change planned for Squeak 6 is eliminating ContextPart & MethodContext in favor of Context. In reviewing the (very few) changes necessary I came across the following: MethodContext>>printString "Answer an emphasized string in case of a breakpoint method" ^(self method notNil and: [self method hasBreakpoint]) ifTrue:[(super printString , ' [break]') asText allBold] ifFalse:[super printString] Seriously? I don't object to modifying [Method]Conext>>printOn: to include [break] but having printString answer a text seems completely broken to me, and overriding printString is a hack; printOn: being the operative method for producing self-descriptions. Should we nuke it and add [break] to printOn:? Or...?
Nuke it. AFAIK breakpoints never worked.
which?
Levente
_,,,^..^,,,_ best, Eliot
The one which allows you to break at any instruction. There is "toggle break on entry", which does nothing but recompile your method with `self break` at the start. I find that feature hardly useful.
Levente
On Wed, 29 Mar 2017, Tobias Pape wrote:
On 29.03.2017, at 23:16, Levente Uzonyi leves@caesar.elte.hu wrote:
On Wed, 29 Mar 2017, Eliot Miranda wrote:
Hi All, another change planned for Squeak 6 is eliminating ContextPart & MethodContext in favor of Context. In reviewing the (very few) changes necessary I came across the following: MethodContext>>printString "Answer an emphasized string in case of a breakpoint method" ^(self method notNil and: [self method hasBreakpoint]) ifTrue:[(super printString , ' [break]') asText allBold] ifFalse:[super printString] Seriously? I don't object to modifying [Method]Conext>>printOn: to include [break] but having printString answer a text seems completely broken to me, and overriding printString is a hack; printOn: being the operative method for producing self-descriptions. Should we nuke it and add [break] to printOn:? Or...?
Nuke it. AFAIK breakpoints never worked.
which?
Levente
_,,,^..^,,,_ best, Eliot
On 29.03.2017, at 23:43, Levente Uzonyi leves@caesar.elte.hu wrote:
The one which allows you to break at any instruction. There is "toggle break on entry", which does nothing but recompile your method with `self break` at the start. I find that feature hardly useful.
Well, there's WrappedBreakpoint, which can do that without recompiling…
Levente
On Wed, 29 Mar 2017, Tobias Pape wrote:
On 29.03.2017, at 23:16, Levente Uzonyi leves@caesar.elte.hu wrote: On Wed, 29 Mar 2017, Eliot Miranda wrote:
Hi All, another change planned for Squeak 6 is eliminating ContextPart & MethodContext in favor of Context. In reviewing the (very few) changes necessary I came across the following: MethodContext>>printString "Answer an emphasized string in case of a breakpoint method" ^(self method notNil and: [self method hasBreakpoint]) ifTrue:[(super printString , ' [break]') asText allBold] ifFalse:[super printString] Seriously? I don't object to modifying [Method]Conext>>printOn: to include [break] but having printString answer a text seems completely broken to me, and overriding printString is a hack; printOn: being the operative method for producing self-descriptions. Should we nuke it and add [break] to printOn:? Or...?
Nuke it. AFAIK breakpoints never worked.
which?
Levente
_,,,^..^,,,_ best, Eliot
Inserting `self half` is still superior.
Levente
On Wed, 29 Mar 2017, Tobias Pape wrote:
On 29.03.2017, at 23:43, Levente Uzonyi leves@caesar.elte.hu wrote:
The one which allows you to break at any instruction. There is "toggle break on entry", which does nothing but recompile your method with `self break` at the start. I find that feature hardly useful.
Well, there's WrappedBreakpoint, which can do that without recompiling…
Levente
On Wed, 29 Mar 2017, Tobias Pape wrote:
On 29.03.2017, at 23:16, Levente Uzonyi leves@caesar.elte.hu wrote: On Wed, 29 Mar 2017, Eliot Miranda wrote:
Hi All, another change planned for Squeak 6 is eliminating ContextPart & MethodContext in favor of Context. In reviewing the (very few) changes necessary I came across the following: MethodContext>>printString "Answer an emphasized string in case of a breakpoint method" ^(self method notNil and: [self method hasBreakpoint]) ifTrue:[(super printString , ' [break]') asText allBold] ifFalse:[super printString] Seriously? I don't object to modifying [Method]Conext>>printOn: to include [break] but having printString answer a text seems completely broken to me, and overriding printString is a hack; printOn: being the operative method for producing self-descriptions. Should we nuke it and add [break] to printOn:? Or...?
Nuke it. AFAIK breakpoints never worked.
which?
Levente
_,,,^..^,,,_ best, Eliot
On 29.03.2017, at 23:56, Levente Uzonyi leves@caesar.elte.hu wrote:
Inserting `self half` is still superior.
If i want to half myself, sure ;)
Well, I'd say, it depends. If I'm just exploring the system and dont want to change it, I typically use break on enty.
Levente
On Wed, 29 Mar 2017, Tobias Pape wrote:
On 29.03.2017, at 23:43, Levente Uzonyi leves@caesar.elte.hu wrote: The one which allows you to break at any instruction. There is "toggle break on entry", which does nothing but recompile your method with `self break` at the start. I find that feature hardly useful.
Well, there's WrappedBreakpoint, which can do that without recompiling…
Levente On Wed, 29 Mar 2017, Tobias Pape wrote:
On 29.03.2017, at 23:16, Levente Uzonyi leves@caesar.elte.hu wrote: On Wed, 29 Mar 2017, Eliot Miranda wrote:
Hi All, another change planned for Squeak 6 is eliminating ContextPart & MethodContext in favor of Context. In reviewing the (very few) changes necessary I came across the following: MethodContext>>printString "Answer an emphasized string in case of a breakpoint method" ^(self method notNil and: [self method hasBreakpoint]) ifTrue:[(super printString , ' [break]') asText allBold] ifFalse:[super printString] Seriously? I don't object to modifying [Method]Conext>>printOn: to include [break] but having printString answer a text seems completely broken to me, and overriding printString is a hack; printOn: being the operative method for producing self-descriptions. Should we nuke it and add [break] to printOn:? Or...?
Nuke it. AFAIK breakpoints never worked.
which?
Levente
_,,,^..^,,,_ best, Eliot
On Thu, Mar 30, 2017 at 12:01 AM, Tobias Pape Das.Linux@gmx.de wrote:
On 29.03.2017, at 23:56, Levente Uzonyi leves@caesar.elte.hu wrote:
Inserting `self half` is still superior.
If i want to half myself, sure ;)
Well, I'd say, it depends. If I'm just exploring the system and dont want to change it, I typically use break on enty.
I'd like to have proper breakpoints that are as convenient as "self halt" but don't modify the method source.
- Bert -
On 31.03.2017, at 15:46, Bert Freudenberg bert@freudenbergs.de wrote:
On Thu, Mar 30, 2017 at 12:01 AM, Tobias Pape Das.Linux@gmx.de wrote:
On 29.03.2017, at 23:56, Levente Uzonyi leves@caesar.elte.hu wrote:
Inserting `self half` is still superior.
If i want to half myself, sure ;)
Well, I'd say, it depends. If I'm just exploring the system and dont want to change it, I typically use break on enty.
I'd like to have proper breakpoints that are as convenient as "self halt" but don't modify the method source.
WrappedBreakpoint works for that if you just need the entry, tho
- Bert -
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Eliot Miranda -
H. Hirzel -
Levente Uzonyi -
Tobias Pape