Hi Eliot,<br>
<br>
> 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.<br>
<br>
Thank you. Please see Kernel-ct.1407. :-)<br>
<br>
Best,<br>
Christoph<br>
<br>
<font color="#808080">---<br>
</font><i><font color="#808080">Sent from </font></i><i><u><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><font color="#808080">Squeak Inbox Talk</font></a></u></i><br>
<br>
On 2021-11-01T21:33:08-07:00, eliot.miranda@gmail.com wrote:<br>
<br>
> Hi Christoph,<br>
> <br>
> > On Nov 1, 2021, at 6:27 AM, Christoph.Thiede at student.hpi.uni-potsdam.de wrote:<br>
> > <br>
> > Hi all,<br>
> > <br>
> > I would like to kindly push this debate again as it is kind of blocking my current efforts to port SimulationStudio to 5.3. <br>
> > <br>
> > 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:<br>
> > > ObjectTracer on: Morph new<br>
> > > ProtoObject new isNil<br>
> > 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.<br>
> <br>
> 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.<br>
> <br>
> > <br>
> > Your reaction would be very appreciated.<br>
> > <br>
> > Best,<br>
> > Christoph<br>
> > <br>
> > ---<br>
> > Sent from Squeak Inbox Talk<br>
> > <br>
> > On 2021-05-28T23:21:57+00:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:<br>
> > <br>
> > > Hi Marcel,<br>
> > > <br>
> > > <br>
> > > 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? :-)<br>
> > > <br>
> > > <br>
> > > 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?<br>
> > > <br>
> > > <br>
> > > Best,<br>
> > > <br>
> > > Christoph<br>
> > > <br>
> > > ________________________________<br>
> > > Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel<br>
> > > Gesendet: Mittwoch, 19. Mai 2021 18:19:41<br>
> > > An: squeak-dev<br>
> > > Betreff: Re: [squeak-dev] The Trunk: Kernel-eem.1366.mcz<br>
> > > <br>
> > > > Well, that's another argument for my proposed fix, isn't it? :-)<br>
> > > <br>
> > > 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...<br>
> > > <br>
> > > 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.<br>
> > > <br>
> > > Best,<br>
> > > Marcel<br>
> > > <br>
> > > Am 17.05.2021 13:08:07 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:<br>
> > > <br>
> > > Well, that's another argument for my proposed fix, isn't it? :-)<br>
> > > <br>
> > > <br>
> > > Best,<br>
> > > <br>
> > > Christoph<br>
> > > <br>
> > > ________________________________<br>
> > > Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel<br>
> > > Gesendet: Montag, 17. Mai 2021 12:54:50<br>
> > > An: squeak-dev<br>
> > > Betreff: Re: [squeak-dev] The Trunk: Kernel-eem.1366.mcz<br>
> > > <br>
> > > > Given any object of a class that reimplements #isArray in an erroneous way<br>
> > > <br>
> > > 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. :-)<br>
> > > <br>
> > > Best,<br>
> > > Marcel<br>
> > > <br>
> > > Am 17.05.2021 12:00:33 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:<br>
> > > <br>
> > > Hi Marcel,<br>
> > > <br>
> > > <br>
> > > > Maybe an actual use case would help. Something bigger than "ProtoObject new isNil".<br>
> > > <br>
> > > Of course, here are you:<br>
> > > <br>
> > > Debug it:<br>
> > > ObjectTracer on: Morph new<br>
> > > <br>
> > > 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.<br>
> > > <br>
> > > Here is another example. Given any object of a class that reimplements #isArray in an erroneous way, this will break the simulator, too:<br>
> > > <br>
> > > Object newSubclass<br>
> > > compile: 'isArray ^self notYetImplemented';<br>
> > > new "step through this"<br>
> > > <br>
> > > > My impression was that even the BasicInspector struggled to deal with proxies.<br>
> > > <br>
> > > I think I have fixed this issue via Tools-ct.1056/ToolsTests-ct.105.<br>
> > > <br>
> > > Best,<br>
> > > Christoph<br>
> > > <br>
> > > ________________________________<br>
> > > Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel<br>
> > > Gesendet: Montag, 17. Mai 2021 08:08 Uhr<br>
> > > An: squeak-dev<br>
> > > Betreff: Re: [squeak-dev] The Trunk: Kernel-eem.1366.mcz<br>
> > > <br>
> > > > Are you thinking about proxies (usually implemented as ProtoObject)?<br>
> > > <br>
> > > 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.<br>
> > > <br>
> > > Maybe an actual use case would help. Something bigger than "ProtoObject new isNil".<br>
> > > <br>
> > > Best,<br>
> > > Marcel<br>
> > > <br>
> > > Am 17.05.2021 07:54:59 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:<br>
> > > <br>
> > > Hi Christoph.<br>
> > > <br>
> > > > The simulator should not stumble upon any objects that do not implement #isArray<br>
> > > > in a conventional way.<br>
> > > <br>
> > > #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)?<br>
> > > <br>
> > > Best,<br>
> > > Marcel<br>
> > > <br>
> > > Am 16.05.2021 19:07:34 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:<br>
> > > <br>
> > > 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.<br>
> > > <br>
> > > <br>
> > > Best,<br>
> > > <br>
> > > Christoph<br>
> > > <br>
> > > ________________________________<br>
> > > Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Thiede, Christoph<br>
> > > Gesendet: Sonntag, 16. Mai 2021 18:40:59<br>
> > > An: squeak-dev at lists.squeakfoundation.org<br>
> > > Betreff: Re: [squeak-dev] The Trunk: Kernel-eem.1366.mcz<br>
> > > <br>
> > > Hi all,<br>
> > > <br>
> > > in my humble opinion, this is still broken as of today in the Trunk. :-) The<br>
> > > simulator should not stumble upon any objects that do not implement #isArray<br>
> > > in a conventional way. The following should be debuggable, but at the<br>
> > > moment, you get a DNU error from #isPrimFailToken: if you step through the<br>
> > > expression:<br>
> > > <br>
> > > ProtoObject new isNil<br>
> > > <br>
> > > Efficiency is important, but IMHO correctness is even more important. Thus I<br>
> > > think Kernel-ct.1369 is still relevant for the trunk. :-)<br>
> > > <br>
> > > Best,<br>
> > > Christoph<br>
> > > <br>
> > > <br>
> > > <br>
> > > -----<br>
> > > Carpe Squeak!<br>
> > > --<br>
> > > Sent from: http://forum.world.st/Squeak-Dev-f45488.html<br>
> > > <br>
> > > -------------- next part --------------<br>
> > > An HTML attachment was scrubbed...<br>
> > > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210528/e24a4431/attachment.html><br>
> > > <br>
> > > <br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211101/4e679795/attachment.html><br>
> <br>
>