Hi Eliot,

On Mon, 20 Jul 2020, Eliot Miranda wrote:

> Hi All,
>     I've just found and fixed a VM bug in an as-yet-unpublished pair of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and Float64ArrayPlugin>>primitiveAt[Put].  The new replacement, which allows two methods
> (at:[put:]) in FloatArray to relace four methods (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times faster than the plugin methods.  The issue is when to publish the corrections to trunk.
> Since the existing VM is broken I don't want to simply push to trunk and have people inconvenienced by a sudden emergence of failures in the FoatArrayTests.  However, I do want to push the corrections soon, because they're a
> substantial improvement.  So the question is how long should I wait?
> 
> Is it OK if I push the fixes to FloatArray and subclasses in a week?  Do people using trunk keep an eye on the CI builds and upgrade, or would they appreciate a heads up?  If so, as soon as the AppVeyor builds succeed
> for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask that you upgrade your VM.

I think most people don't update their VMs often. I still tend to fire 
up the one shipped with the 5.3 release. So, IMO the question is not how 
long to wait but what to do when things are about to break.
I presume that without updating the VM, the image would not work properly.
So, I think the best would be if the user were warned during the update 
if the VM would be incompatible with the changes.
I'm thinking about checking the VM version in the preamble of the package 
and raising a Warning when it clearly lacks the required updates.
Users can still continute with a Warning or terminate the update process, 
while cli tools will act as if an error had occured.


Levente

> _,,,^..^,,,_
> best, Eliot
> 
>