[squeak-dev] trunk and new vm etiquette
Eliot Miranda
eliot.miranda at gmail.com
Wed Jul 22 17:50:18 UTC 2020
> On Jul 22, 2020, at 7:44 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
>
>
> Hi Eliot,
>
> looks good. In "About Squeak", we point to "Visit https://github.com/OpenSmalltalk/opensmalltalk-vm".
Should we augment that with a direct pointer to the Appveyor CI server?
>
> 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/9622f5fd/attachment.html>
More information about the Squeak-dev
mailing list
|