Hi all,
1) I have just uploaded Kernel-ct.1548 to the inbox which fixes #ifTrue: and #ifFalse: for ObjectTracer on: true and True basicNew*. The idea is similar to fallback code in primitives: We can just revert the failing context by one step and proceed with the actual true resp. false. Can we merge this? :)
Just coincidentally, I understand that one should not use different instances of True or False -- see 2).
2) Regarding Levente's proposal:
True class >> #basicNew
^true
Is this better than raising an error here like in SmallInteger etc.?
Best, Christoph
--- Sent from Squeak Inbox Talk
On 2020-03-26T14:08:51-07:00, eliot.miranda@gmail.com wrote:
On Mar 26, 2020, at 11:59 AM, Levente Uzonyi <leves at caesar.elte.hu> 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 <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Eliot Miranda <eliot.miranda at gmail.com> 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 <Christoph.Thiede at student.hpi.uni-potsdam.de> 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 <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux at gmx.de> 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 <Christoph.Thiede at student.hpi.uni-potsdam.de> 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