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>