[squeak-dev] trunk and new vm etiquette
eliot.miranda at gmail.com
Wed Jul 22 14:40:53 UTC 2020
>> 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.
> 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 FloatArrayTest tests will fail. Please upgrade your VM. You may continue and upgrade later or abort and upgrade now.']!
>> 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.
>> > _,,,^..^,,,_
>> > best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev