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

christoph.thiede at student.hpi.uni-potsdam.de christoph.thiede at student.hpi.uni-potsdam.de
Tue Nov 2 10:29:02 UTC 2021


Hi Eliot,

> 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.

Thank you. Please see Kernel-ct.1407. :-)

Best,
Christoph

---
Sent from Squeak Inbox Talk

On 2021-11-01T21:33:08-07:00, eliot.miranda at gmail.com wrote:

> 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>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211102/c9f02903/attachment-0001.html>


More information about the Squeak-dev mailing list