[Vm-dev] $x nextObject
christoph.thiede at outlook.de
Fri Jul 19 07:56:43 UTC 2019
Thanks for the reply! Even if #nextObject & Co. do not have a real use case, I think they should be protected. It is kind of annoying for any Squeak beginner like me to "try out a method" and thereby get the whole image crashed. Would it be the right solution to override #nextObject and #nextInstance both in Number and Character by returning self shouldNotImplement?
By the way, if these selectors are obsoleted, why aren't they moved to any Deprecated package?
Von: Vm-dev <vm-dev-bounces at lists.squeakfoundation.org> im Auftrag von Levente Uzonyi <leves at caesar.elte.hu>
Gesendet: Freitag, 19. Juli 2019 01:05 Uhr
An: Open Smalltalk Virtual Machine Development Discussion <vm-dev at lists.squeakfoundation.org>
Betreff: Re: [Vm-dev] $x nextObject
No immediate object should ever receive #nextObject. I think the new
immediates (Character, SmallFloat64) lack the #shouldNotImplement
implementation. Same goes for #nextInstance.
Btw, #nextObject was obsoleted by the segmented memory model. Perhaps it
can still answer something, but you won't be able to iterate over all
objects with it. If that's what you want, then you should use #allObjects
On Thu, 18 Jul 2019, Christoph Thiede wrote:
> is it a known bug that the Squeak VM may crash when you perform #nextObject
> on any Character object? I can reproduce this issue on multiple Windows 10
> machines, using SqueakCog 201810071412. I am familiar not at all with the VM
> implementation, but for example, after evaluating $x nextObject, the used
> RAM strongly reduces and after a few seconds, the process terminates.
> Kind regards,
> Sent from: http://forum.world.st/Squeak-VM-f104410.html
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev