fetchWordofObject

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

fetchWordofObject

johnmci
/*    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
========================================================================
===


Reply | Threaded
Open this post in threaded view
|

Re: fetchWordofObject

Andreas.Raab
> 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

Reply | Threaded
Open this post in threaded view
|

Re: fetchWordofObject

johnmci
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
========================================================================
===


Reply | Threaded
Open this post in threaded view
|

Re: fetchWordofObject

timrowledge
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*"

Reply | Threaded
Open this post in threaded view
|

Re: fetchWordofObject

johnmci
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*"
>
>

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


Reply | Threaded
Open this post in threaded view
|

Re: fetchWordofObject

Andreas.Raab
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

Reply | Threaded
Open this post in threaded view
|

Re: fetchWordofObject

timrowledge
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

Reply | Threaded
Open this post in threaded view
|

Re: fetchWordofObject

Andreas.Raab
> 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

Reply | Threaded
Open this post in threaded view
|

Re: fetchWordofObject

timrowledge
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

Reply | Threaded
Open this post in threaded view
|

Re: fetchWordofObject

Andreas.Raab
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: fetchWordofObject

timrowledge
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

Reply | Threaded
Open this post in threaded view
|

Re: fetchWordofObject

Andreas.Raab
> 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

Reply | Threaded
Open this post in threaded view
|

Re: fetchWordofObject

timrowledge
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
Reply | Threaded
Open this post in threaded view
|

Re: fetchWordofObject

timrowledge
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?"