Smalltalk › Squeak › Squeak VM

fetchWordofObject

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

johnmci

fetchWordofObject

/* This message is deprecated. Use fetchLong32, fetchLong64 or
fetchPointer */

sqInt fetchWordofObject(sqInt fieldIndex, sqInt oop) {
error("deprecated -- do not use -- and then delete me");
}

Yes, but Croquet invokes the FFI plugin which invokes
fetchWordofObject, and dies... Try Croquet and a mac carbon 3.8.8b2
VM and see what happens.
I'll further note the suggestion to use fetchLong32... is not
possible because I don't see fetchLong32 as an entry in the
sqVirtualMachine.h

So I'd suggest we change fetchWordofObject back to the original
logic, to avoid toasting all the plugins that use it?

--
========================================================================
===
John M. McIntosh <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===

Andreas.Raab

Re: fetchWordofObject

> So I'd suggest we change fetchWordofObject back to the original logic,
> to avoid toasting all the plugins that use it?

Actually no. We should bind the entry in struct VM to whatever the right
thing for 32 bit is (fetchLong32?) and rename the entries appropriately.
In other words: Remove the offending method and fix all the users at
their earliest appearance (I really don't understand why people leave
methods with fatal aborts around - I'd rather have the compiler tell me
the method doesn't exist).

Cheers,
- Andreas

johnmci

Re: fetchWordofObject

In this case I think you should keep fetchWordofObject as the
backward compatible offering. I'll note the original did the same as
fetchPointerofObject
What was done here was removal of a entry in the sqVirtualMachine
table thus breaking many plugins, we should attempt to maintain
backward compatibility in 32bit mode.

On May 27, 2005, at 12:02 AM, Andreas Raab wrote:

>> So I'd suggest we change fetchWordofObject back to the original
>> logic, to avoid toasting all the plugins that use it?
>>
>
> Actually no. We should bind the entry in struct VM to whatever the
> right thing for 32 bit is (fetchLong32?) and rename the entries
> appropriately. In other words: Remove the offending method and fix
> all the users at their earliest appearance (I really don't
> understand why people leave methods with fatal aborts around - I'd
> rather have the compiler tell me the method doesn't exist).
>
> Cheers,
> - Andreas
>
>

--
========================================================================
===
John M. McIntosh <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===

timrowledge

Re: fetchWordofObject

Surely the right thing to do is fix the plugins? We did explicitly say that
things would get broken in the transition and it's unfortunate that it is
taking so long but, well, tough luck to people that use a not yet completed VM
release.

tim
--
Tim Rowledge, [hidden email], http://www.rowledge.org/tim
"How many Puppeteers does it take to change a lightbulb?" "None. They hire
Beowulf Shaeffer to to it. Lightbulbs can be *dangerous*"

johnmci

Re: fetchWordofObject

Mmm, well no we're only asking for a 32bit word here, that we can do.
Dropping support breaks existing plugins, then newer plugins won't
work for older VMs

On May 27, 2005, at 11:00 AM, Tim Rowledge wrote:

> Surely the right thing to do is fix the plugins? We did explicitly
> say that
> things would get broken in the transition and it's unfortunate that
> it is
> taking so long but, well, tough luck to people that use a not yet
> completed VM
> release.
>
>
> tim
> --
> Tim Rowledge, [hidden email], http://www.rowledge.org/tim
> "How many Puppeteers does it take to change a lightbulb?" "None.
> They hire
> Beowulf Shaeffer to to it. Lightbulbs can be *dangerous*"
>
>

Andreas.Raab

Re: fetchWordofObject

In reply to this post by timrowledge

Tim Rowledge wrote:
> Surely the right thing to do is fix the plugins? We did explicitly say that
> things would get broken in the transition and it's unfortunate that it is
> taking so long but, well, tough luck to people that use a not yet completed VM
> release.

Yes, that was basically my point. But we can keep binary compatibility
for any external plugins that are run with a later VM by replacing the
entry in struct VM with the "proper" reference.

Cheers,
- Andreas

timrowledge

Re: fetchWordofObject

In message <[hidden email]>
Andreas Raab <[hidden email]> wrote:

> Yes, that was basically my point. But we can keep binary compatibility
> for any external plugins that are run with a later VM by replacing the
> entry in struct VM with the "proper" reference.
I accept the technical possibility but question whether it is actually
pragmatically sensible. How many external plugins are used by windows, unix &
mac VMs? RISC OS is, of course, the odd duck since I make all plugins external.
Is it a common enough usage pattern (using old external plugins) to be worth
supporting?

tim
--
Tim Rowledge, [hidden email], http://www.rowledge.org/tim
Computer possessed? Try DEVICE=C:\EXOR.SYS

Andreas.Raab

Re: fetchWordofObject

> I accept the technical possibility but question whether it is actually
> pragmatically sensible. How many external plugins are used by windows, unix &
> mac VMs?

I don't know and I think we'll only find out once we start breaking
things. So far, we have been 100% backward compatible and I just don't
see any particularly good reason to break that compatibility when we're
not even introducing anything new here.

> Is it a common enough usage pattern (using old external plugins) to be worth
> supporting?

Why break it if there isn't any benefit? All we're talking about is to
replace these two lines in sqVirtualMachine[.h|.c] from
fetchWordOfObject to fetchLong32 (or whatever). Compared to the amount
of time we're spending even having this discussion the amount of time
just fixing it seems comparadly small.

Cheers,
- Andreas

timrowledge

Re: fetchWordofObject

In reply to this post by Andreas.Raab

OK, my proposal is to:

a) add a method #obsoleteDontUseThisFetchWordOfObject, implemented as needed to
return the 32bit word etc.

b) change sqVirtualMachine.[ch] to _replace_
VM->fetchWordofObject = fetchWordofObject; with
VM->obsoleteDontUseThisFetchWordOfObject =
obsoleteDontUseThisFetchWordOfObject;

c) add VM->fetchLong32OfObject

Thus old plugins will be expecting the fetchWord stuff at that offset into the
vmproxy struct and will find something suitable. New code will probably not use
this 'new' method since everyone is too (hopefully) lazy to type that lot in.
An attempt to freshly compile 'old' code will fail with an error 'symbol not
found' or similar.

I'm not actually too keen on modifying an old part of sqVirtualMachine but if
we want to rescind a function we don't have much choice.

Does this suit people?

tim
--
Tim Rowledge, [hidden email], http://www.rowledge.org/tim
Strange OpCodes: MW: Multiply Work

Andreas.Raab

Re: fetchWordofObject

Sounds good to me.

Cheers,
- Andreas

Tim Rowledge wrote:

> OK, my proposal is to:
>
> a) add a method #obsoleteDontUseThisFetchWordOfObject, implemented as needed to
> return the 32bit word etc.
>
> b) change sqVirtualMachine.[ch] to _replace_
> VM->fetchWordofObject = fetchWordofObject; with
> VM->obsoleteDontUseThisFetchWordOfObject =
> obsoleteDontUseThisFetchWordOfObject;
>
> c) add VM->fetchLong32OfObject
>
> Thus old plugins will be expecting the fetchWord stuff at that offset into the
> vmproxy struct and will find something suitable. New code will probably not use
> this 'new' method since everyone is too (hopefully) lazy to type that lot in.
> An attempt to freshly compile 'old' code will fail with an error 'symbol not
> found' or similar.
>
> I'm not actually too keen on modifying an old part of sqVirtualMachine but if
> we want to rescind a function we don't have much choice.
>
> Does this suit people?
>
>
> tim
> --
> Tim Rowledge, [hidden email], http://www.rowledge.org/tim
> Strange OpCodes: MW: Multiply Work
>
>

timrowledge

Re: fetchWordofObject

In message <[hidden email]>
Andreas Raab <[hidden email]> wrote:

> Sounds good to me.
>
> Cheers,
> - Andreas
>
> Tim Rowledge wrote:
> > OK, my proposal is to:
> >
> > a) add a method #obsoleteDontUseThisFetchWordOfObject, implemented as
needed to
> > return the 32bit word etc.
> >
> > b) change sqVirtualMachine.[ch] to _replace_
> > VM->fetchWordofObject = fetchWordofObject; with
> > VM->obsoleteDontUseThisFetchWordOfObject =
> > obsoleteDontUseThisFetchWordOfObject;
> >
> > c) add VM->fetchLong32OfObject

Done and committed as SVN #1212 to go with MMaker-tpr.33.mcz New VM_PROXY_MINOR
level 7 introduced. Hope it all works for everyone.

tim
--
Tim Rowledge, [hidden email], http://www.rowledge.org/tim
Strange OpCodes: ASBM: Add Soap to Bubble Memory

Andreas.Raab

Re: fetchWordofObject

> Done and committed as SVN #1212 to go with MMaker-tpr.33.mcz New VM_PROXY_MINOR
> level 7 introduced. Hope it all works for everyone.

Thanks! We'll find out soon enough if it breaks ;-)

Cheers,
- Andreas

timrowledge

Re: fetchWordofObject

In message <[hidden email]>
Andreas Raab <[hidden email]> wrote:

> > Done and committed as SVN #1212 to go with MMaker-tpr.33.mcz New
VM_PROXY_MINOR
> > level 7 introduced. Hope it all works for everyone.
>
> Thanks! We'll find out soon enough if it breaks ;-)
It did. Why are my fingers incapable of typing what my brain says to them? SVN
#1214 compiles on RISC OS. http://www.rowledge.
org/tim/squeak/SqFiles/packages/VMMaker/VMMaker-tpr.34.mcz should get you the
package. Seems to rn ok for me, performance appears reasonable etc. You do need
to load the attached cs before VMMaker, it needs to get to update stream asap.

tim
--
Tim Rowledge, [hidden email], http://www.rowledge.org/tim
Strange OpCodes: WFL: Wave FLag

VMM38-64bit-imageUpdates.1.cs (3K) Download Attachment

timrowledge

Re: fetchWordofObject

John spotted that Croquet gained a blue screen with the new VMMaker, becasue I
forgot to actually return a value for obsoleteDontUseThisFetchofObject. Sigh.

Get
http://www.rowledge.org/tim/squeak/SqFiles/packages/VMMaker/VMMaker-tpr.35.mcz

Of course, this also reminds us the the Croquet stuff may need some changes.
Since I don't use it I couldn't even begin to say what those might be.

tim
--
Tim Rowledge, [hidden email], http://www.rowledge.org/tim
"How many Trinoc does it take to change a lightbulb?" "Why do you want to know
about our maintenance schedules? Are you planning to attack us in the dark?"