Numbered primitives in images

Hi,

I tried running Scratch image with the current VM and found that it bombed
with cryptic "a primitive failed" message. Not that I expected to work
smoothly but I was surprised about the root cause - many numbered primitives
in primitiveTable (unix/src/vm/interp.c) were replaced with primitiveFail
instead of being redirected to their respective named primitive. In my case it
was primitive 207 (primNetNameResolverStatus).

Any reason why new VMs let primitives fail rather redirect them?

Is backward compability maintained only across the same major version of the
VM?

Should images warn if they are opened in a VM that may not be compatible?

Subbu

On 15.01.2010, at 09:18, K. K. Subramaniam wrote:
>
> Hi,
>
> I tried running Scratch image with the current VM and found that it bombed
> with cryptic "a primitive failed" message. Not that I expected to work
> smoothly but I was surprised about the root cause - many numbered primitives
> in primitiveTable (unix/src/vm/interp.c) were replaced with primitiveFail
> instead of being redirected to their respective named primitive. In my case it
> was primitive 207 (primNetNameResolverStatus).

Hmm, the 3.10 VM used to work fine with Scratch - that must be very recent? Which Scratch image did you try?

> Any reason why new VMs let primitives fail rather redirect them?
>
> Is backward compability maintained only across the same major version of the
> VM?

I think so far the VMs pretty much managed to be backwards-compatible even across major versions.

- Bert -

On Friday 15 January 2010 04:27:49 pm Bert Freudenberg wrote:
> > I tried running Scratch image with the current VM and found that it
> > bombed  with cryptic "a primitive failed" message. Not that I expected to
> > work smoothly but I was surprised about the root cause - many numbered
> > primitives in primitiveTable (unix/src/vm/interp.c) were replaced with
> > primitiveFail instead of being redirected to their respective named
> > primitive. In my case it was primitive 207 (primNetNameResolverStatus).
>
> Hmm, the 3.10 VM used to work fine with Scratch - that must be very recent?
>  Which Scratch image did you try?
Scratch 1.4 (Linux) of 30-Nov-2009 on 3.11-3 VM.
Break into Scratch and do "Socket initializeNetwork".

Subbu

On 15.01.2010, at 16:58, K. K. Subramaniam wrote:
So it does not occur in normal operation?

- Bert -

On Friday 15 January 2010 10:46:45 pm Bert Freudenberg wrote:
> On 15.01.2010, at 16:58, K. K. Subramaniam wrote:
> > Scratch 1.4 (Linux) of 30-Nov-2009 on 3.11-3 VM.
> > Break into Scratch and do "Socket initializeNetwork".
>
> So it does not occur in normal operation?
Only if you define "normal" as "offline" ;-). Any operation which uses networking
(url block) goes through this method and it will fail when run under the
3.11.3 VM built from unix-3.11.3-vmm or svn trunk.

BTW, Scratch image is just an example which has numbered primitives.

The 3.10-4 VM has primitiveObsoleteIndexedPrimitive in slot 207 in
platforms/unix/src/vm/interp.c while the 3.11.3 tar.gz and the trunk contain
primitiveFail. The change crept in r1935 through vmm-dtl-126.

Is this intentional or an oversight?

Subbu

(please reply to vm-dev only)

On 16.01.2010, at 03:46, K. K. Subramaniam wrote:
>
>
> The 3.10-4 VM has primitiveObsoleteIndexedPrimitive in slot 207 in
> platforms/unix/src/vm/interp.c while the 3.11.3 tar.gz and the trunk contain
> primitiveFail. The change crept in r1935 through vmm-dtl-126.
>
> Is this intentional or an oversight?
>
> Subbu

Looks like a bug to me ...

- Bert -