[Simulation errors] ObjectTracer on: true

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

[Simulation errors] ObjectTracer on: true

Christoph Thiede

Hi all!

I rarely discovered that much errors with one single command :-)

Steps to reproduce

Print it:

(ObjectTracer on: true) ifTrue: [1]

Expected behavior

It is printed: 1

Actual behavior

The following tracer notifications appear (proceed them all):

  1. (3x) #printStringLimitedTo:#longPrintOn:limitedTo:indent: and again #printStringLimitedTo:, caused by SmalltalkImage >> #logSqueakError:inContext:
  2. #mustBeBoolean
  3. (3 more print message called by #logSqueakError:inContext: again, see the next error)
  4. Error: Where's the jump?
    Caused by #mustBeBooleanIn:#skipBackBeforeJump

If you still keep proceeding:

  1. (3 more print message called by #logSqueakError:inContext: again, see the next error)
  2. Finally, the NonBooleanReceiver error from 2.
  3. VM crashes.

Summarizing the bugs

ObjectTracer traces too much

The amount of messages printed by the ObjectTracer is an unintended side effect of the way it signals calls via the debugger. The debugger logs this error, including the stack trace. How can we avoid this? Should we suppress all further notifications from one ObjectTracer instance during the first one is debugged?

#mustBeBoolean is sent to boolean proxy

This is caused by the simulation of the inlined #ifTrue: call.
I don't know whether this is worth to be fixed before Scorch?
If yes, I think we would need to disable inlining for this particular selector or make inlining opt-out-able as proposed here (this would probably be way too slow).

#mustBoBoolean depends on caller chain

It turns out that #mustBeBoolean relies on being called from a context that just did a jump. This makes it impossible to forward this message as usual via a transparent proxy/decorator.

We use this pattern in other methods as well. How can we enable transparent wrappers not to collide with method contexts depending on their sender?


Best,

Christoph



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: [Simulation errors] ObjectTracer on: true

Tobias Pape

> On 25.03.2020, at 21:35, Thiede, Christoph <[hidden email]> wrote:
>
> Hi all!
>
> I rarely discovered that much errors with one single command :-)
>
> Steps to reproduce
>
> Print it:
>
> (ObjectTracer on: true) ifTrue: [1]
> Expected behavior
>
> It is printed: 1
>

No :D
true false nil are special. :)
The ObjectTracer on whatever cannot be ever true.

-t

> Actual behavior
>
> The following tracer notifications appear (proceed them all):
>
> • (3x) #printStringLimitedTo:, #longPrintOn:limitedTo:indent: and again #printStringLimitedTo:, caused by SmalltalkImage >> #logSqueakError:inContext:
> • #mustBeBoolean
> • (3 more print message called by #logSqueakError:inContext: again, see the next error)
> • Error: Where's the jump?
> Caused by #mustBeBooleanIn:, #skipBackBeforeJump
> If you still keep proceeding:
>
> • (3 more print message called by #logSqueakError:inContext: again, see the next error)
> • Finally, the NonBooleanReceiver error from 2.
> • VM crashes.
> Summarizing the bugs
>
> ObjectTracer traces too much
>
> The amount of messages printed by the ObjectTracer is an unintended side effect of the way it signals calls via the debugger. The debugger logs this error, including the stack trace. How can we avoid this? Should we suppress all further notifications from one ObjectTracer instance during the first one is debugged?
>
> #mustBeBoolean is sent to boolean proxy
>
> This is caused by the simulation of the inlined #ifTrue: call.
> I don't know whether this is worth to be fixed before Scorch?
> If yes, I think we would need to disable inlining for this particular selector or make inlining opt-out-able as proposed here (this would probably be way too slow).
>
> #mustBoBoolean depends on caller chain
>
> It turns out that #mustBeBoolean relies on being called from a context that just did a jump. This makes it impossible to forward this message as usual via a transparent proxy/decorator.
>
> We use this pattern in other methods as well. How can we enable transparent wrappers not to collide with method contexts depending on their sender?
>
> Best,
> Christoph



Reply | Threaded
Open this post in threaded view
|

Re: [Simulation errors] ObjectTracer on: true

Christoph Thiede

Hi Tobias,


true false nil are special. :)

> The ObjectTracer on whatever cannot be ever true.

I know they don't work like usual objects because many boolean/nil selectors are inlined ATM.
However, this only affects specific selectors.
The following worked - if ObjectTracer would not cause a recursion:
(ObjectTracer on: true) xor: (ObjectTracer on: false)

IMHO, everything in Smalltalk should be an object and should also behave like an object, especially in terms of message dispatching. Is there any other reason to deviate from these rules besides performance?

Best,
Christoph

PS: You cannot suppress the debuggers spawn by an ObjectTracer ... Should we maybe use some kind of notification for this? IWLT do the following:
[(ObjectTracer on: true) xor: (ObjectTracer on: false)] on: WarningOrSo do: #resume.


Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
Gesendet: Mittwoch, 25. März 2020 21:57:43
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] [Simulation errors] ObjectTracer on: true
 

> On 25.03.2020, at 21:35, Thiede, Christoph <[hidden email]> wrote:
>
> Hi all!
>
> I rarely discovered that much errors with one single command :-)
>
> Steps to reproduce
>
> Print it:
>
> (ObjectTracer on: true) ifTrue: [1]
> Expected behavior
>
> It is printed: 1
>

No :D
true false nil are special. :)
The ObjectTracer on whatever cannot be ever true.

-t

> Actual behavior
>
> The following tracer notifications appear (proceed them all):
>
>        • (3x) #printStringLimitedTo:, #longPrintOn:limitedTo:indent: and again #printStringLimitedTo:, caused by SmalltalkImage >> #logSqueakError:inContext:
>        • #mustBeBoolean
>        • (3 more print message called by #logSqueakError:inContext: again, see the next error)
>        • Error: Where's the jump?
> Caused by #mustBeBooleanIn:, #skipBackBeforeJump
> If you still keep proceeding:
>
>        • (3 more print message called by #logSqueakError:inContext: again, see the next error)
>        • Finally, the NonBooleanReceiver error from 2.
>        • VM crashes.
> Summarizing the bugs
>
> ObjectTracer traces too much
>
> The amount of messages printed by the ObjectTracer is an unintended side effect of the way it signals calls via the debugger. The debugger logs this error, including the stack trace. How can we avoid this? Should we suppress all further notifications from one ObjectTracer instance during the first one is debugged?
>
> #mustBeBoolean is sent to boolean proxy
>
> This is caused by the simulation of the inlined #ifTrue: call.
> I don't know whether this is worth to be fixed before Scorch?
> If yes, I think we would need to disable inlining for this particular selector or make inlining opt-out-able as proposed here (this would probably be way too slow).
>
> #mustBoBoolean depends on caller chain
>
> It turns out that #mustBeBoolean relies on being called from a context that just did a jump. This makes it impossible to forward this message as usual via a transparent proxy/decorator.
>
> We use this pattern in other methods as well. How can we enable transparent wrappers not to collide with method contexts depending on their sender?
>
> Best,
> Christoph





Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: [Simulation errors] ObjectTracer on: true

Tobias Pape

> On 26.03.2020, at 09:01, Thiede, Christoph <[hidden email]> wrote:
>
> Hi Tobias,
>
> > true false nil are special. :)
> > The ObjectTracer on whatever cannot be ever true.
>
> I know they don't work like usual objects because many boolean/nil selectors are inlined ATM.
> However, this only affects specific selectors.
> The following worked - if ObjectTracer would not cause a recursion:
> (ObjectTracer on: true) xor: (ObjectTracer on: false)
>
> IMHO, everything in Smalltalk should be an object and should also behave like an object, especially in terms of message dispatching. Is there any other reason to deviate from these rules besides performance?

No, but the only gain changing things here is some kind of artificial purity, which for its own sake yields nothing.


>
> Best,
> Christoph
>
> PS: You cannot suppress the debuggers spawn by an ObjectTracer ... Should we maybe use some kind of notification for this? IWLT do the following:
> [(ObjectTracer on: true) xor: (ObjectTracer on: false)] on: WarningOrSo do: #resume.
> Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
> Gesendet: Mittwoch, 25. März 2020 21:57:43
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] [Simulation errors] ObjectTracer on: true
>  
>
> > On 25.03.2020, at 21:35, Thiede, Christoph <[hidden email]> wrote:
> >
> > Hi all!
> >
> > I rarely discovered that much errors with one single command :-)
> >
> > Steps to reproduce
> >
> > Print it:
> >
> > (ObjectTracer on: true) ifTrue: [1]
> > Expected behavior
> >
> > It is printed: 1
> >
>
> No :D
> true false nil are special. :)
> The ObjectTracer on whatever cannot be ever true.
>
> -t
>
> > Actual behavior
> >
> > The following tracer notifications appear (proceed them all):
> >
> >        • (3x) #printStringLimitedTo:, #longPrintOn:limitedTo:indent: and again #printStringLimitedTo:, caused by SmalltalkImage >> #logSqueakError:inContext:
> >        • #mustBeBoolean
> >        • (3 more print message called by #logSqueakError:inContext: again, see the next error)
> >        • Error: Where's the jump?
> > Caused by #mustBeBooleanIn:, #skipBackBeforeJump
> > If you still keep proceeding:
> >
> >        • (3 more print message called by #logSqueakError:inContext: again, see the next error)
> >        • Finally, the NonBooleanReceiver error from 2.
> >        • VM crashes.
> > Summarizing the bugs
> >
> > ObjectTracer traces too much
> >
> > The amount of messages printed by the ObjectTracer is an unintended side effect of the way it signals calls via the debugger. The debugger logs this error, including the stack trace. How can we avoid this? Should we suppress all further notifications from one ObjectTracer instance during the first one is debugged?
> >
> > #mustBeBoolean is sent to boolean proxy
> >
> > This is caused by the simulation of the inlined #ifTrue: call.
> > I don't know whether this is worth to be fixed before Scorch?
> > If yes, I think we would need to disable inlining for this particular selector or make inlining opt-out-able as proposed here (this would probably be way too slow).
> >
> > #mustBoBoolean depends on caller chain
> >
> > It turns out that #mustBeBoolean relies on being called from a context that just did a jump. This makes it impossible to forward this message as usual via a transparent proxy/decorator.
> >
> > We use this pattern in other methods as well. How can we enable transparent wrappers not to collide with method contexts depending on their sender?
> >
> > Best,
> > Christoph



Reply | Threaded
Open this post in threaded view
|

Re: [Simulation errors] ObjectTracer on: true

marcel.taeumel
Hi Christoph.

I know they don't work like usual objects because many boolean/nil selectors are inlined ATM.

It's not only that. You can count special treatment for some basic objects throughout the system. Not just message dispatching.

It would be great to get some overview on that. :-)

Best,
Marcel

Am 26.03.2020 09:09:53 schrieb Tobias Pape <[hidden email]>:


> On 26.03.2020, at 09:01, Thiede, Christoph wrote:
>
> Hi Tobias,
>
> > true false nil are special. :)
> > The ObjectTracer on whatever cannot be ever true.
>
> I know they don't work like usual objects because many boolean/nil selectors are inlined ATM.
> However, this only affects specific selectors.
> The following worked - if ObjectTracer would not cause a recursion:
> (ObjectTracer on: true) xor: (ObjectTracer on: false)
>
> IMHO, everything in Smalltalk should be an object and should also behave like an object, especially in terms of message dispatching. Is there any other reason to deviate from these rules besides performance?

No, but the only gain changing things here is some kind of artificial purity, which for its own sake yields nothing.


>
> Best,
> Christoph
>
> PS: You cannot suppress the debuggers spawn by an ObjectTracer ... Should we maybe use some kind of notification for this? IWLT do the following:
> [(ObjectTracer on: true) xor: (ObjectTracer on: false)] on: WarningOrSo do: #resume.
> Von: Squeak-dev im Auftrag von Tobias Pape
> Gesendet: Mittwoch, 25. März 2020 21:57:43
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] [Simulation errors] ObjectTracer on: true
>
>
> > On 25.03.2020, at 21:35, Thiede, Christoph wrote:
> >
> > Hi all!
> >
> > I rarely discovered that much errors with one single command :-)
> >
> > Steps to reproduce
> >
> > Print it:
> >
> > (ObjectTracer on: true) ifTrue: [1]
> > Expected behavior
> >
> > It is printed: 1
> >
>
> No :D
> true false nil are special. :)
> The ObjectTracer on whatever cannot be ever true.
>
> -t
>
> > Actual behavior
> >
> > The following tracer notifications appear (proceed them all):
> >
> > • (3x) #printStringLimitedTo:, #longPrintOn:limitedTo:indent: and again #printStringLimitedTo:, caused by SmalltalkImage >> #logSqueakError:inContext:
> > • #mustBeBoolean
> > • (3 more print message called by #logSqueakError:inContext: again, see the next error)
> > • Error: Where's the jump?
> > Caused by #mustBeBooleanIn:, #skipBackBeforeJump
> > If you still keep proceeding:
> >
> > • (3 more print message called by #logSqueakError:inContext: again, see the next error)
> > • Finally, the NonBooleanReceiver error from 2.
> > • VM crashes.
> > Summarizing the bugs
> >
> > ObjectTracer traces too much
> >
> > The amount of messages printed by the ObjectTracer is an unintended side effect of the way it signals calls via the debugger. The debugger logs this error, including the stack trace. How can we avoid this? Should we suppress all further notifications from one ObjectTracer instance during the first one is debugged?
> >
> > #mustBeBoolean is sent to boolean proxy
> >
> > This is caused by the simulation of the inlined #ifTrue: call.
> > I don't know whether this is worth to be fixed before Scorch?
> > If yes, I think we would need to disable inlining for this particular selector or make inlining opt-out-able as proposed here (this would probably be way too slow).
> >
> > #mustBoBoolean depends on caller chain
> >
> > It turns out that #mustBeBoolean relies on being called from a context that just did a jump. This makes it impossible to forward this message as usual via a transparent proxy/decorator.
> >
> > We use this pattern in other methods as well. How can we enable transparent wrappers not to collide with method contexts depending on their sender?
> >
> > Best,
> > Christoph





Reply | Threaded
Open this post in threaded view
|

Re: [Simulation errors] ObjectTracer on: true

Eliot Miranda-2
In reply to this post by Christoph Thiede
Hi Christoph,

On Mar 26, 2020, at 1:01 AM, Thiede, Christoph <[hidden email]> wrote:

Hi Tobias,

true false nil are special. :)

> The ObjectTracer on whatever cannot be ever true.

I know they don't work like usual objects because many boolean/nil selectors are inlined ATM.
However, this only affects specific selectors.
The following worked - if ObjectTracer would not cause a recursion:
(ObjectTracer on: true) xor: (ObjectTracer on: false)

IMHO, everything in Smalltalk should be an object and should also behave like an object, especially in terms of message dispatching. Is there any other reason to deviate from these rules besides performance?

That’s not the issue.  The issue is whether nil true and false are singletons or not.  They are.  Alas this is not sufficiently explicit, but it is true of Smalltalk.  The inlining of ifTrue: et all is only practicable because they are singletons, not the other way around.

So if they are singletons (as U assert they are) then the rest of the system has to behave accordingly and not create other instances.  So the big lies in ObjectTracer not treating nil true and false as singletons.  (IMO)


Best,
Christoph

PS: You cannot suppress the debuggers spawn by an ObjectTracer ... Should we maybe use some kind of notification for this? IWLT do the following:
[(ObjectTracer on: true) xor: (ObjectTracer on: false)] on: WarningOrSo do: #resume.


Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
Gesendet: Mittwoch, 25. März 2020 21:57:43
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] [Simulation errors] ObjectTracer on: true
 

> On 25.03.2020, at 21:35, Thiede, Christoph <[hidden email]> wrote:
>
> Hi all!
>
> I rarely discovered that much errors with one single command :-)
>
> Steps to reproduce
>
> Print it:
>
> (ObjectTracer on: true) ifTrue: [1]
> Expected behavior
>
> It is printed: 1
>

No :D
true false nil are special. :)
The ObjectTracer on whatever cannot be ever true.

-t

> Actual behavior
>
> The following tracer notifications appear (proceed them all):
>
>        • (3x) #printStringLimitedTo:, #longPrintOn:limitedTo:indent: and again #printStringLimitedTo:, caused by SmalltalkImage >> #logSqueakError:inContext:
>        • #mustBeBoolean
>        • (3 more print message called by #logSqueakError:inContext: again, see the next error)
>        • Error: Where's the jump?
> Caused by #mustBeBooleanIn:, #skipBackBeforeJump
> If you still keep proceeding:
>
>        • (3 more print message called by #logSqueakError:inContext: again, see the next error)
>        • Finally, the NonBooleanReceiver error from 2.
>        • VM crashes.
> Summarizing the bugs
>
> ObjectTracer traces too much
>
> The amount of messages printed by the ObjectTracer is an unintended side effect of the way it signals calls via the debugger. The debugger logs this error, including the stack trace. How can we avoid this? Should we suppress all further notifications from one ObjectTracer instance during the first one is debugged?
>
> #mustBeBoolean is sent to boolean proxy
>
> This is caused by the simulation of the inlined #ifTrue: call.
> I don't know whether this is worth to be fixed before Scorch?
> If yes, I think we would need to disable inlining for this particular selector or make inlining opt-out-able as proposed here (this would probably be way too slow).
>
> #mustBoBoolean depends on caller chain
>
> It turns out that #mustBeBoolean relies on being called from a context that just did a jump. This makes it impossible to forward this message as usual via a transparent proxy/decorator.
>
> We use this pattern in other methods as well. How can we enable transparent wrappers not to collide with method contexts depending on their sender?
>
> Best,
> Christoph






Reply | Threaded
Open this post in threaded view
|

Re: [Simulation errors] ObjectTracer on: true

Christoph Thiede

Hi all,


ah, you mean because the following does not work either:


True basicNew ifFalse: [0] ifTrue: [1] "NonBooleanReceiver"


Again, this is a bit sad :-( Wouldn't it be possible to compare true and false by class rather than identity - both on image + VM side?

Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Donnerstag, 26. März 2020 13:07:44
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] [Simulation errors] ObjectTracer on: true
 
Hi Christoph,

On Mar 26, 2020, at 1:01 AM, Thiede, Christoph <[hidden email]> wrote:

Hi Tobias,

true false nil are special. :)

> The ObjectTracer on whatever cannot be ever true.

I know they don't work like usual objects because many boolean/nil selectors are inlined ATM.
However, this only affects specific selectors.
The following worked - if ObjectTracer would not cause a recursion:
(ObjectTracer on: true) xor: (ObjectTracer on: false)

IMHO, everything in Smalltalk should be an object and should also behave like an object, especially in terms of message dispatching. Is there any other reason to deviate from these rules besides performance?

That’s not the issue.  The issue is whether nil true and false are singletons or not.  They are.  Alas this is not sufficiently explicit, but it is true of Smalltalk.  The inlining of ifTrue: et all is only practicable because they are singletons, not the other way around.

So if they are singletons (as U assert they are) then the rest of the system has to behave accordingly and not create other instances.  So the big lies in ObjectTracer not treating nil true and false as singletons.  (IMO)


Best,
Christoph

PS: You cannot suppress the debuggers spawn by an ObjectTracer ... Should we maybe use some kind of notification for this? IWLT do the following:
[(ObjectTracer on: true) xor: (ObjectTracer on: false)] on: WarningOrSo do: #resume.


Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
Gesendet: Mittwoch, 25. März 2020 21:57:43
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] [Simulation errors] ObjectTracer on: true
 

> On 25.03.2020, at 21:35, Thiede, Christoph <[hidden email]> wrote:
>
> Hi all!
>
> I rarely discovered that much errors with one single command :-)
>
> Steps to reproduce
>
> Print it:
>
> (ObjectTracer on: true) ifTrue: [1]
> Expected behavior
>
> It is printed: 1
>

No :D
true false nil are special. :)
The ObjectTracer on whatever cannot be ever true.

-t

> Actual behavior
>
> The following tracer notifications appear (proceed them all):
>
>        • (3x) #printStringLimitedTo:, #longPrintOn:limitedTo:indent: and again #printStringLimitedTo:, caused by SmalltalkImage >> #logSqueakError:inContext:
>        • #mustBeBoolean
>        • (3 more print message called by #logSqueakError:inContext: again, see the next error)
>        • Error: Where's the jump?
> Caused by #mustBeBooleanIn:, #skipBackBeforeJump
> If you still keep proceeding:
>
>        • (3 more print message called by #logSqueakError:inContext: again, see the next error)
>        • Finally, the NonBooleanReceiver error from 2.
>        • VM crashes.
> Summarizing the bugs
>
> ObjectTracer traces too much
>
> The amount of messages printed by the ObjectTracer is an unintended side effect of the way it signals calls via the debugger. The debugger logs this error, including the stack trace. How can we avoid this? Should we suppress all further notifications from one ObjectTracer instance during the first one is debugged?
>
> #mustBeBoolean is sent to boolean proxy
>
> This is caused by the simulation of the inlined #ifTrue: call.
> I don't know whether this is worth to be fixed before Scorch?
> If yes, I think we would need to disable inlining for this particular selector or make inlining opt-out-able as proposed here (this would probably be way too slow).
>
> #mustBoBoolean depends on caller chain
>
> It turns out that #mustBeBoolean relies on being called from a context that just did a jump. This makes it impossible to forward this message as usual via a transparent proxy/decorator.
>
> We use this pattern in other methods as well. How can we enable transparent wrappers not to collide with method contexts depending on their sender?
>
> Best,
> Christoph






Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: [Simulation errors] ObjectTracer on: true

Tobias Pape

> On 26.03.2020, at 19:02, Thiede, Christoph <[hidden email]> wrote:
>
> Hi all,
>
> ah, you mean because the following does not work either:
>
> True basicNew ifFalse: [0] ifTrue: [1] "NonBooleanReceiver"
>
> Again, this is a bit sad :-( Wouldn't it be possible to compare true and false by class rather than identity - both on image + VM side?
>

That's possible but a different context. That would be Value classes, more or less anti-Singletons.

This is my view:

"""""
Values are used to model abstractions; however, besides simple abstractions like integers there are
compound abstractions. That is, they consist of not exactly one component.
However, there is one aspect to compound values that can be important for programming
systems. There is no concept of identity among values as there is among objects;
the question whether this 17 printed here is the same as this 17 one is not meaningful.
Both represent the abstraction over the integer seventeen. The same holds for compound values
and their components.

Further, the kind of abstraction itself plays a role in the relation between
two values. The complex number 3+i4 has components that
are equal to the components of (3,4), a point in two-dimensional space, and
the rational number 3/4. However, these three entities do not represent the
same abstraction. From an object oriented point of view, one could say that the
“class” of two entities has to match.

A compound value is a composition of other values and can be the
components of other values, for example, matrices of complex numbers.

 - * -

There can be compound values that have no components whatsoever, their arity is zero.
For example, given that members of vector spaces are indeed values, the sole
member of the zero-dimensional vector space certainly is a value, too. However,
since the space has no dimensions, its member vector  has no components.

As a consequence, the only information such Values can convey is  their
“grouping”, that is, what kind of abstraction they represent.

Under certain circumstances, such values can be used to convey the information of singleton-like
entities that are void of information beyond their existence, for example, the
abstract idea of an empty list or set, such as nil.
"""

Best regards
        -Tobias

> Best,
> Christoph
> Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
> Gesendet: Donnerstag, 26. März 2020 13:07:44
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] [Simulation errors] ObjectTracer on: true
>  
> Hi Christoph,
>
>> On Mar 26, 2020, at 1:01 AM, Thiede, Christoph <[hidden email]> wrote:
>> Hi Tobias,
>> > true false nil are special. :)
>> > The ObjectTracer on whatever cannot be ever true.
>>
>> I know they don't work like usual objects because many boolean/nil selectors are inlined ATM.
>> However, this only affects specific selectors.
>> The following worked - if ObjectTracer would not cause a recursion:
>> (ObjectTracer on: true) xor: (ObjectTracer on: false)
>>
>> IMHO, everything in Smalltalk should be an object and should also behave like an object, especially in terms of message dispatching. Is there any other reason to deviate from these rules besides performance?
>
> That’s not the issue.  The issue is whether nil true and false are singletons or not.  They are.  Alas this is not sufficiently explicit, but it is true of Smalltalk.  The inlining of ifTrue: et all is only practicable because they are singletons, not the other way around.
>
> So if they are singletons (as U assert they are) then the rest of the system has to behave accordingly and not create other instances.  So the big lies in ObjectTracer not treating nil true and false as singletons.  (IMO)
>
>
>> Best,
>> Christoph
>>
>> PS: You cannot suppress the debuggers spawn by an ObjectTracer ... Should we maybe use some kind of notification for this? IWLT do the following:
>> [(ObjectTracer on: true) xor: (ObjectTracer on: false)] on: WarningOrSo do: #resume.
>> Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
>> Gesendet: Mittwoch, 25. März 2020 21:57:43
>> An: The general-purpose Squeak developers list
>> Betreff: Re: [squeak-dev] [Simulation errors] ObjectTracer on: true
>>  
>>
>> > On 25.03.2020, at 21:35, Thiede, Christoph <[hidden email]> wrote:
>> >
>> > Hi all!
>> >
>> > I rarely discovered that much errors with one single command :-)
>> >
>> > Steps to reproduce
>> >
>> > Print it:
>> >
>> > (ObjectTracer on: true) ifTrue: [1]
>> > Expected behavior
>> >
>> > It is printed: 1
>> >
>>
>> No :D
>> true false nil are special. :)
>> The ObjectTracer on whatever cannot be ever true.
>>
>> -t
>>
>> > Actual behavior
>> >
>> > The following tracer notifications appear (proceed them all):
>> >
>> >        • (3x) #printStringLimitedTo:, #longPrintOn:limitedTo:indent: and again #printStringLimitedTo:, caused by SmalltalkImage >> #logSqueakError:inContext:
>> >        • #mustBeBoolean
>> >        • (3 more print message called by #logSqueakError:inContext: again, see the next error)
>> >        • Error: Where's the jump?
>> > Caused by #mustBeBooleanIn:, #skipBackBeforeJump
>> > If you still keep proceeding:
>> >
>> >        • (3 more print message called by #logSqueakError:inContext: again, see the next error)
>> >        • Finally, the NonBooleanReceiver error from 2.
>> >        • VM crashes.
>> > Summarizing the bugs
>> >
>> > ObjectTracer traces too much
>> >
>> > The amount of messages printed by the ObjectTracer is an unintended side effect of the way it signals calls via the debugger. The debugger logs this error, including the stack trace. How can we avoid this? Should we suppress all further notifications from one ObjectTracer instance during the first one is debugged?
>> >
>> > #mustBeBoolean is sent to boolean proxy
>> >
>> > This is caused by the simulation of the inlined #ifTrue: call.
>> > I don't know whether this is worth to be fixed before Scorch?
>> > If yes, I think we would need to disable inlining for this particular selector or make inlining opt-out-able as proposed here (this would probably be way too slow).
>> >
>> > #mustBoBoolean depends on caller chain
>> >
>> > It turns out that #mustBeBoolean relies on being called from a context that just did a jump. This makes it impossible to forward this message as usual via a transparent proxy/decorator.
>> >
>> > We use this pattern in other methods as well. How can we enable transparent wrappers not to collide with method contexts depending on their sender?
>> >
>> > Best,
>> > Christoph



Reply | Threaded
Open this post in threaded view
|

Re: [Simulation errors] ObjectTracer on: true

Eliot Miranda-2
In reply to this post by Christoph Thiede
Hi Christoph,

On Mar 26, 2020, at 11:03 AM, Thiede, Christoph <[hidden email]> wrote:



Hi all,


ah, you mean because the following does not work either:


True basicNew ifFalse: [0] ifTrue: [1] "NonBooleanReceiver"


Exactly.


Again, this is a bit sad :-( Wouldn't it be possible to compare true and false by class rather than identity - both on image + VM side?

Why do you find it sad? Booleans ste fungible.  We only need one true and one false.  Being able to Instantiate False, True, & UndefinedObject offers more benefits I can see.

The use of identity comparisons is a key element of Smalltalk. Symbols exist to permit identity comparison of unique strings, avoiding the costs of string comparison (which also involve indirecting through an oop).  If I were you I’d think this through and see if you can make peace with it.  It is good engineering.


Best,
Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Donnerstag, 26. März 2020 13:07:44
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] [Simulation errors] ObjectTracer on: true
 
Hi Christoph,

On Mar 26, 2020, at 1:01 AM, Thiede, Christoph <[hidden email]> wrote:

Hi Tobias,

true false nil are special. :)

> The ObjectTracer on whatever cannot be ever true.

I know they don't work like usual objects because many boolean/nil selectors are inlined ATM.
However, this only affects specific selectors.
The following worked - if ObjectTracer would not cause a recursion:
(ObjectTracer on: true) xor: (ObjectTracer on: false)

IMHO, everything in Smalltalk should be an object and should also behave like an object, especially in terms of message dispatching. Is there any other reason to deviate from these rules besides performance?

That’s not the issue.  The issue is whether nil true and false are singletons or not.  They are.  Alas this is not sufficiently explicit, but it is true of Smalltalk.  The inlining of ifTrue: et all is only practicable because they are singletons, not the other way around.

So if they are singletons (as U assert they are) then the rest of the system has to behave accordingly and not create other instances.  So the big lies in ObjectTracer not treating nil true and false as singletons.  (IMO)


Best,
Christoph

PS: You cannot suppress the debuggers spawn by an ObjectTracer ... Should we maybe use some kind of notification for this? IWLT do the following:
[(ObjectTracer on: true) xor: (ObjectTracer on: false)] on: WarningOrSo do: #resume.


Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
Gesendet: Mittwoch, 25. März 2020 21:57:43
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] [Simulation errors] ObjectTracer on: true
 

> On 25.03.2020, at 21:35, Thiede, Christoph <[hidden email]> wrote:
>
> Hi all!
>
> I rarely discovered that much errors with one single command :-)
>
> Steps to reproduce
>
> Print it:
>
> (ObjectTracer on: true) ifTrue: [1]
> Expected behavior
>
> It is printed: 1
>

No :D
true false nil are special. :)
The ObjectTracer on whatever cannot be ever true.

-t

> Actual behavior
>
> The following tracer notifications appear (proceed them all):
>
>        • (3x) #printStringLimitedTo:, #longPrintOn:limitedTo:indent: and again #printStringLimitedTo:, caused by SmalltalkImage >> #logSqueakError:inContext:
>        • #mustBeBoolean
>        • (3 more print message called by #logSqueakError:inContext: again, see the next error)
>        • Error: Where's the jump?
> Caused by #mustBeBooleanIn:, #skipBackBeforeJump
> If you still keep proceeding:
>
>        • (3 more print message called by #logSqueakError:inContext: again, see the next error)
>        • Finally, the NonBooleanReceiver error from 2.
>        • VM crashes.
> Summarizing the bugs
>
> ObjectTracer traces too much
>
> The amount of messages printed by the ObjectTracer is an unintended side effect of the way it signals calls via the debugger. The debugger logs this error, including the stack trace. How can we avoid this? Should we suppress all further notifications from one ObjectTracer instance during the first one is debugged?
>
> #mustBeBoolean is sent to boolean proxy
>
> This is caused by the simulation of the inlined #ifTrue: call.
> I don't know whether this is worth to be fixed before Scorch?
> If yes, I think we would need to disable inlining for this particular selector or make inlining opt-out-able as proposed here (this would probably be way too slow).
>
> #mustBoBoolean depends on caller chain
>
> It turns out that #mustBeBoolean relies on being called from a context that just did a jump. This makes it impossible to forward this message as usual via a transparent proxy/decorator.
>
> We use this pattern in other methods as well. How can we enable transparent wrappers not to collide with method contexts depending on their sender?
>
> Best,
> Christoph







Reply | Threaded
Open this post in threaded view
|

Re: [Simulation errors] ObjectTracer on: true

Levente Uzonyi
In reply to this post by Christoph Thiede
Hi Christoph,

On Thu, 26 Mar 2020, Thiede, Christoph wrote:

>
> Hi all,
>
>
> ah, you mean because the following does not work either:
>
>
> True basicNew ifFalse: [0] ifTrue: [1] "NonBooleanReceiver"

Here's a fix:

True class >> #basicNew

  ^true


On a more serious note, we should move the guards from #new to #basicNew
in these classes. Non-singleton immediates like SmallInteger, SmallFloat64
and Character already have their own guards in there.


Levente

>
>
> Again, this is a bit sad :-( Wouldn't it be possible to compare true and false by class rather than identity - both on image + VM side?
>
> Best,
> Christoph
>
> __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
> Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
> Gesendet: Donnerstag, 26. März 2020 13:07:44
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] [Simulation errors] ObjectTracer on: true  
> Hi Christoph,
>       On Mar 26, 2020, at 1:01 AM, Thiede, Christoph <[hidden email]> wrote:
>
>       Hi Tobias,
>
>       > true false nil are special. :)
>
>       > The ObjectTracer on whatever cannot be ever true.
>
> I know they don't work like usual objects because many boolean/nil selectors are inlined ATM.
> However, this only affects specific selectors.
> The following worked - if ObjectTracer would not cause a recursion:
> (ObjectTracer on: true) xor: (ObjectTracer on: false)
>
> IMHO, everything in Smalltalk should be an object and should also behave like an object, especially in terms of message dispatching. Is there any other reason to deviate from these rules besides performance?
>
>
> That’s not the issue.  The issue is whether nil true and false are singletons or not.  They are.  Alas this is not sufficiently explicit, but it is true of Smalltalk.  The inlining of ifTrue: et all is only practicable because they are singletons, not the other way around.
> So if they are singletons (as U assert they are) then the rest of the system has to behave accordingly and not create other instances.  So the big lies in ObjectTracer not treating nil true and false as singletons.  (IMO)
>
>
>       Best,
> Christoph
>
> PS: You cannot suppress the debuggers spawn by an ObjectTracer ... Should we maybe use some kind of notification for this? IWLT do the following:
> [(ObjectTracer on: true) xor: (ObjectTracer on: false)] on: WarningOrSo do: #resume.
>
> __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
> Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
> Gesendet: Mittwoch, 25. März 2020 21:57:43
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] [Simulation errors] ObjectTracer on: true  
>
> > On 25.03.2020, at 21:35, Thiede, Christoph <[hidden email]> wrote:
> >
> > Hi all!
> >
> > I rarely discovered that much errors with one single command :-)
> >
> > Steps to reproduce
> >
> > Print it:
> >
> > (ObjectTracer on: true) ifTrue: [1]
> > Expected behavior
> >
> > It is printed: 1
> >
>
> No :D
> true false nil are special. :)
> The ObjectTracer on whatever cannot be ever true.
>
> -t
>
> > Actual behavior
> >
> > The following tracer notifications appear (proceed them all):
> >
> >        • (3x) #printStringLimitedTo:, #longPrintOn:limitedTo:indent: and again #printStringLimitedTo:, caused by SmalltalkImage >> #logSqueakError:inContext:
> >        • #mustBeBoolean
> >        • (3 more print message called by #logSqueakError:inContext: again, see the next error)
> >        • Error: Where's the jump?
> > Caused by #mustBeBooleanIn:, #skipBackBeforeJump
> > If you still keep proceeding:
> >
> >        • (3 more print message called by #logSqueakError:inContext: again, see the next error)
> >        • Finally, the NonBooleanReceiver error from 2.
> >        • VM crashes.
> > Summarizing the bugs
> >
> > ObjectTracer traces too much
> >
> > The amount of messages printed by the ObjectTracer is an unintended side effect of the way it signals calls via the debugger. The debugger logs this error, including the stack trace. How can we avoid this? Should we suppress all further notifications from one ObjectTracer instance during the first one is
> debugged?
> >
> > #mustBeBoolean is sent to boolean proxy
> >
> > This is caused by the simulation of the inlined #ifTrue: call.
> > I don't know whether this is worth to be fixed before Scorch?
> > If yes, I think we would need to disable inlining for this particular selector or make inlining opt-out-able as proposed here (this would probably be way too slow).
> >
> > #mustBoBoolean depends on caller chain
> >
> > It turns out that #mustBeBoolean relies on being called from a context that just did a jump. This makes it impossible to forward this message as usual via a transparent proxy/decorator.
> >
> > We use this pattern in other methods as well. How can we enable transparent wrappers not to collide with method contexts depending on their sender?
> >
> > Best,
> > Christoph
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Simulation errors] ObjectTracer on: true

Eliot Miranda-2


> On Mar 26, 2020, at 11:59 AM, Levente Uzonyi <[hidden email]> wrote:
>
> Hi Christoph,
>
>> On Thu, 26 Mar 2020, Thiede, Christoph wrote:
>>
>> Hi all,
>> ah, you mean because the following does not work either:
>> True basicNew ifFalse: [0] ifTrue: [1] "NonBooleanReceiver"
>
> Here's a fix:
>
> True class >> #basicNew
>
>    ^true

<3 I love this :-)

>
>
> On a more serious note, we should move the guards from #new to #basicNew in these classes. Non-singleton immediates like SmallInteger, SmallFloat64 and Character already have their own guards in there.

Agreed.  The error messages can be explicit and informative.  But I do think your implementation above is cool.

>
> Levente
>
>> Again, this is a bit sad :-( Wouldn't it be possible to compare true and false by class rather than identity - both on image + VM side?
>> Best,
>> Christoph
>> __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
>> Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
>> Gesendet: Donnerstag, 26. März 2020 13:07:44
>> An: The general-purpose Squeak developers list
>> Betreff: Re: [squeak-dev] [Simulation errors] ObjectTracer on: true  
>> Hi Christoph,
>>      On Mar 26, 2020, at 1:01 AM, Thiede, Christoph <[hidden email]> wrote:
>>
>>      Hi Tobias,
>>
>>      > true false nil are special. :)
>>
>>      > The ObjectTracer on whatever cannot be ever true.
>> I know they don't work like usual objects because many boolean/nil selectors are inlined ATM.
>> However, this only affects specific selectors.
>> The following worked - if ObjectTracer would not cause a recursion:
>> (ObjectTracer on: true) xor: (ObjectTracer on: false)
>> IMHO, everything in Smalltalk should be an object and should also behave like an object, especially in terms of message dispatching. Is there any other reason to deviate from these rules besides performance?
>> That’s not the issue.  The issue is whether nil true and false are singletons or not.  They are.  Alas this is not sufficiently explicit, but it is true of Smalltalk.  The inlining of ifTrue: et all is only practicable because they are singletons, not the other way around.
>> So if they are singletons (as U assert they are) then the rest of the system has to behave accordingly and not create other instances.  So the big lies in ObjectTracer not treating nil true and false as singletons.  (IMO)
>>
>>      Best,
>> Christoph
>> PS: You cannot suppress the debuggers spawn by an ObjectTracer ... Should we maybe use some kind of notification for this? IWLT do the following:
>> [(ObjectTracer on: true) xor: (ObjectTracer on: false)] on: WarningOrSo do: #resume.
>> __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
>> Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
>> Gesendet: Mittwoch, 25. März 2020 21:57:43
>> An: The general-purpose Squeak developers list
>> Betreff: Re: [squeak-dev] [Simulation errors] ObjectTracer on: true  
>> > On 25.03.2020, at 21:35, Thiede, Christoph <[hidden email]> wrote:
>> >
>> > Hi all!
>> >
>> > I rarely discovered that much errors with one single command :-)
>> >
>> > Steps to reproduce
>> >
>> > Print it:
>> >
>> > (ObjectTracer on: true) ifTrue: [1]
>> > Expected behavior
>> >
>> > It is printed: 1
>> >
>> No :D
>> true false nil are special. :)
>> The ObjectTracer on whatever cannot be ever true.
>> -t
>> > Actual behavior
>> >
>> > The following tracer notifications appear (proceed them all):
>> >
>> >        • (3x) #printStringLimitedTo:, #longPrintOn:limitedTo:indent: and again #printStringLimitedTo:, caused by SmalltalkImage >> #logSqueakError:inContext:
>> >        • #mustBeBoolean
>> >        • (3 more print message called by #logSqueakError:inContext: again, see the next error)
>> >        • Error: Where's the jump?
>> > Caused by #mustBeBooleanIn:, #skipBackBeforeJump
>> > If you still keep proceeding:
>> >
>> >        • (3 more print message called by #logSqueakError:inContext: again, see the next error)
>> >        • Finally, the NonBooleanReceiver error from 2.
>> >        • VM crashes.
>> > Summarizing the bugs
>> >
>> > ObjectTracer traces too much
>> >
>> > The amount of messages printed by the ObjectTracer is an unintended side effect of the way it signals calls via the debugger. The debugger logs this error, including the stack trace. How can we avoid this? Should we suppress all further notifications from one ObjectTracer instance during the first one is
>> debugged?
>> >
>> > #mustBeBoolean is sent to boolean proxy
>> >
>> > This is caused by the simulation of the inlined #ifTrue: call.
>> > I don't know whether this is worth to be fixed before Scorch?
>> > If yes, I think we would need to disable inlining for this particular selector or make inlining opt-out-able as proposed here (this would probably be way too slow).
>> >
>> > #mustBoBoolean depends on caller chain
>> >
>> > It turns out that #mustBeBoolean relies on being called from a context that just did a jump. This makes it impossible to forward this message as usual via a transparent proxy/decorator.
>> >
>> > We use this pattern in other methods as well. How can we enable transparent wrappers not to collide with method contexts depending on their sender?
>> >
>> > Best,
>> > Christoph
>