[squeak-dev] The Trunk: Kernel-eem.1366.mcz

christoph.thiede at student.hpi.uni-potsdam.de christoph.thiede at student.hpi.uni-potsdam.de
Mon Nov 1 13:20:28 UTC 2021


Hi all,

I would like to kindly push this debate again as it is kind of blocking my current efforts to port SimulationStudio to 5.3. 

Recap: In Context >> #primFailToken:, we send a message (#isArray) to the object in question. It is a bit faster but breaks the simulation with objects that implement #isArray in a special way:
> ObjectTracer on: Morph new
> ProtoObject new isNil
This violates the contract that objects from the simulated code should only be accessed via mirror primitives. To my knowledge, this is the only violation of this rule, and because I think that correctness is more important than speed (and I have not experienced any noticable slowdowns with my patch), I request to merge Kernel-ct.1407 which uses a safe mirror primitive instead of #isArray.

Your reaction would be very appreciated.

Best,
Christoph

---
Sent from Squeak Inbox Talk

On 2021-05-28T23:21:57+00:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:

> Hi Marcel,
> 
> 
> I think it is two completely different debates whether to use #isArray in the simulator, and whether to use it in general. In the simulator, the contract is pretty simple: You must not send any messages to the object under simulation because you must not make any assumptions about how the object will treat these messages. This #isArray in #isPrimFailToken: appears probably the single violation of that rule, and it makes the simulator unreliable as we have seen from multiple examples. Do you get my point? :-)
> 
> 
> Apart from that, the cleanness of ProtoObject is another ongoing story - which I also look forward to tackling later - I hope we can move on in this direction before the next release. But I do not think that we should mix both debates. Or am I missing your point?
> 
> 
> Best,
> 
> Christoph
> 
> ________________________________
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
> Gesendet: Mittwoch, 19. Mai 2021 18:19:41
> An: squeak-dev
> Betreff: Re: [squeak-dev] The Trunk: Kernel-eem.1366.mcz
> 
> > Well, that's another argument for my proposed fix, isn't it? :-)
> 
> Only if you would make a case for removing #isArray from the entire image. I suppose. Maybe #isArray is like a trade-off. You do not want to have to compare classes, but it might not be a good idea to implement #isArray in your domain object. Hmm...
> 
> To improve anything in this regard, I would suggest to widen our perspective on this issue. A list of the current challenges around ProtoObject (maybe in combination with object-as-method?) might be helpful to make informed decisions. This isolated discussion around "== Array" vs. "isArray" doesn't feel right.
> 
> Best,
> Marcel
> 
> Am 17.05.2021 13:08:07 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
> 
> Well, that's another argument for my proposed fix, isn't it? :-)
> 
> 
> Best,
> 
> Christoph
> 
> ________________________________
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
> Gesendet: Montag, 17. Mai 2021 12:54:50
> An: squeak-dev
> Betreff: Re: [squeak-dev] The Trunk: Kernel-eem.1366.mcz
> 
> > Given any object of a class that reimplements #isArray in an erroneous way
> 
> Given my recent slip in the FFI package, I have the feeling that #isArray has a really specific meaning for the class layout. No one should claim to also be an Array. :-D I mean, not even RawBitsArray does it. There is something going on. :-)
> 
> Best,
> Marcel
> 
> Am 17.05.2021 12:00:33 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
> 
> Hi Marcel,
> 
> 
> > Maybe an actual use case would help. Something bigger than "ProtoObject new isNil".
> 
> Of course, here are you:
> 
> Debug it:
> ObjectTracer on: Morph new
> 
> In the trunk, this spawns an embarrassing number of additional debuggers while debugging the expression. With my proposed fix, not a single additional debugger is opened before you actually send a message to the morph.
> 
> Here is another example. Given any object of a class that reimplements #isArray in an erroneous way, this will break the simulator, too:
> 
> Object newSubclass
> compile: 'isArray ^self notYetImplemented';
> new "step through this"
> 
> > My impression was that even the BasicInspector struggled to deal with proxies.
> 
> I think I have fixed this issue via Tools-ct.1056/ToolsTests-ct.105.
> 
> Best,
> Christoph
> 
> ________________________________
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
> Gesendet: Montag, 17. Mai 2021 08:08 Uhr
> An: squeak-dev
> Betreff: Re: [squeak-dev] The Trunk: Kernel-eem.1366.mcz
> 
> > Are you thinking about proxies (usually implemented as ProtoObject)?
> 
> To quote myself and expand the comment: Is this the only issue left that we are having with debugging/simulating ProtoObject? My impression was that even the BasicInspector struggled to deal with proxies. Well, it got better due to the mirror primitives in Context.
> 
> Maybe an actual use case would help. Something bigger than "ProtoObject new isNil".
> 
> Best,
> Marcel
> 
> Am 17.05.2021 07:54:59 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
> 
> Hi Christoph.
> 
> > The simulator should not stumble upon any objects that do not implement #isArray
> > in a conventional way.
> 
> #isArray is implemented in Object. So, all objects can answer to that. Where do you see a problem? Are you thinking about proxies (usually implemented as ProtoObject)?
> 
> Best,
> Marcel
> 
> Am 16.05.2021 19:07:34 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
> 
> Sorry for the confusion. Kernel-ct.1369 has been moved to treated with all justification. I just uploaded Kernel-ct.1407 instead which fixes the mentioned problem.
> 
> 
> Best,
> 
> Christoph
> 
> ________________________________
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Thiede, Christoph
> Gesendet: Sonntag, 16. Mai 2021 18:40:59
> An: squeak-dev at lists.squeakfoundation.org
> Betreff: Re: [squeak-dev] The Trunk: Kernel-eem.1366.mcz
> 
> Hi all,
> 
> in my humble opinion, this is still broken as of today in the Trunk. :-) The
> simulator should not stumble upon any objects that do not implement #isArray
> in a conventional way. The following should be debuggable, but at the
> moment, you get a DNU error from #isPrimFailToken: if you step through the
> expression:
> 
> ProtoObject new isNil
> 
> Efficiency is important, but IMHO correctness is even more important. Thus I
> think Kernel-ct.1369 is still relevant for the trunk. :-)
> 
> Best,
> Christoph
> 
> 
> 
> -----
> Carpe Squeak!
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210528/e24a4431/attachment.html>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211101/bf8bad24/attachment.html>


More information about the Squeak-dev mailing list