$x nextObject

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

$x nextObject

Christoph Thiede
 
Hello,

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,
Christoph



--
Sent from: http://forum.world.st/Squeak-VM-f104410.html
Reply | Threaded
Open this post in threaded view
|

Re: $x nextObject

Levente Uzonyi
 
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
instead.

Levente

On Thu, 18 Jul 2019, Christoph Thiede wrote:

>
> Hello,
>
> 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,
> Christoph
>
>
>
> --
> Sent from: http://forum.world.st/Squeak-VM-f104410.html
Reply | Threaded
Open this post in threaded view
|

Re: $x nextObject

Christoph Thiede
 
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?

Christoph

Von: Vm-dev <[hidden email]> im Auftrag von Levente Uzonyi <[hidden email]>
Gesendet: Freitag, 19. Juli 2019 01:05 Uhr
An: Open Smalltalk Virtual Machine Development Discussion <[hidden email]>
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
instead.

Levente

On Thu, 18 Jul 2019, Christoph Thiede wrote:

>
> Hello,
>
> 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,
> Christoph
>
>
>
> --
> Sent from: http://forum.world.st/Squeak-VM-f104410.html
Reply | Threaded
Open this post in threaded view
|

Re: $x nextObject

Denis Kudriashov
In reply to this post by Levente Uzonyi
 
Hi

пт, 19 июл. 2019 г., 0:05 Levente Uzonyi <[hidden email]>:
 
No immediate object should ever receive #nextObject. I think the new
immediates (Character, SmallFloat64) lack the #shouldNotImplement
implementation. Same goes for #nextInstance.

VM protection would be also nice. Actually it looks like a bug in those primitives


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

Levente

On Thu, 18 Jul 2019, Christoph Thiede wrote:

>
> Hello,
>
> 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,
> Christoph
>
>
>
> --
> Sent from: http://forum.world.st/Squeak-VM-f104410.html
Reply | Threaded
Open this post in threaded view
|

Re: $x nextObject

Nicolas Cellier
 


Le ven. 19 juil. 2019 à 10:52, Denis Kudriashov <[hidden email]> a écrit :
 
Hi

пт, 19 июл. 2019 г., 0:05 Levente Uzonyi <[hidden email]>:
 
No immediate object should ever receive #nextObject. I think the new
immediates (Character, SmallFloat64) lack the #shouldNotImplement
implementation. Same goes for #nextInstance.

VM protection would be also nice. Actually it looks like a bug in those primitives

+1


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

Levente

On Thu, 18 Jul 2019, Christoph Thiede wrote:

>
> Hello,
>
> 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,
> Christoph
>
>
>
> --
> Sent from: http://forum.world.st/Squeak-VM-f104410.html
Reply | Threaded
Open this post in threaded view
|

Re: $x nextObject

Levente Uzonyi
 
On Fri, 19 Jul 2019, Nicolas Cellier wrote:

> VM protection would be also nice. Actually it looks like a bug in those
primitives

Indeed. As Dave pointed out in another thread, #nextInstance handles
immediates well (the primitive fails). I haven't checked the VM code, but
perhaps the checks could just be copied over to #nextObject.

Levente