[squeak-dev] trunk and new vm etiquette

Marcel Taeumel marcel.taeumel at hpi.de
Wed Jul 22 14:43:45 UTC 2020


Hi Eliot,

looks good. In "About Squeak", we point to "Visit https://github.com/OpenSmalltalk/opensmalltalk-vm".

Best,
Marcel
Am 22.07.2020 16:41:08 schrieb Eliot Miranda <eliot.miranda at gmail.com>:


On Jul 22, 2020, at 12:49 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:



Hi Levente.

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

+1

A one-liner would be nice. The warning should also (roughly) point to the location of the new VM for download.

MCMcmUpdater checkVM: 202003021730. "and newer"

I wrote it like this:

 "Use of the Spur FloatArray>>at:[put:] prims requires at least VMMaker.oscog.2778"

Smalltalk vmVMMakerVersion < 2778 ifTrue:
    [Warning signal: 'This virtual machine is too old to support correct versions of the FloatArray>>at:[put:] primitives 238 and 239.  FloatArray subclasses will not behave correctly and FloatArray[64]Test tests will fail.  Please upgrade your VM.  You may continue and upgrade later or abort and upgrade now.']!

Best,
Marcel
Am 21.07.2020 20:21:39 schrieb Levente Uzonyi <leves at caesar.elte.hu>:
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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200722/313989b6/attachment.html>


More information about the Squeak-dev mailing list