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

Eliot Miranda eliot.miranda at gmail.com
Tue Nov 2 04:33:08 UTC 2021


Hi Christoph,

> On Nov 1, 2021, at 6:27 AM, Christoph.Thiede at student.hpi.uni-potsdam.de wrote:
> 
> ´╗┐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.

I agree.  I apologize for having broken this. If you submit a fix to inbox I promise to review it and move it to trunk promptly.

> 
> 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/4e679795/attachment.html>


More information about the Squeak-dev mailing list