/* 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 johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
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
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 johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
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, tim@rowledge.org, 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*"
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, tim@rowledge.org, 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 johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
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
In message 4297622C.9040309@gmx.de Andreas Raab andreas.raab@gmx.de 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, tim@rowledge.org, http://www.rowledge.org/tim Computer possessed? Try DEVICE=C:\EXOR.SYS
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
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, tim@rowledge.org, http://www.rowledge.org/tim Strange OpCodes: MW: Multiply Work
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, tim@rowledge.org, http://www.rowledge.org/tim Strange OpCodes: MW: Multiply Work
In message 42992B05.5000800@gmx.de Andreas Raab andreas.raab@gmx.de 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, tim@rowledge.org, http://www.rowledge.org/tim Strange OpCodes: ASBM: Add Soap to Bubble Memory
In message 42A50930.6090900@gmx.de Andreas Raab andreas.raab@gmx.de 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, tim@rowledge.org, http://www.rowledge.org/tim Strange OpCodes: WFL: Wave FLag
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.m...
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, tim@rowledge.org, 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?"
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
John M McIntosh -
Tim Rowledge