oops, please ignore...

On Fri, Aug 21, 2020 at 12:06 PM Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> Hi Fabio,
>
>
> On Jul 28, 2020, at 12:10 PM, Fabio Niephaus <lists at fniephaus.com> wrote:
>
> 
> On Tue, 28 Jul 2020 at 8:31 pm, karl ramberg <karlramberg at gmail.com>
> wrote:
>
>> Who can update so that new bundles from http://files.squeak.org/trunk/
>> uses new VM ?
>>
>
> I can do that, but I wonder whether there should be a new VM release? I
> haven't fully followed the discussion: are the changes backwards compatible?
>
> Fabio
>
>
>> Best,
>> Karl
>>
>> On Mon, Jul 27, 2020 at 10:47 AM Marcel Taeumel <marcel.taeumel at hpi.de>
>> wrote:
>>
>>> Works:
>>> <image.png>
>>>
>>> Best,
>>> Marcel
>>>
>>> Am 23.07.2020 13:41:17 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
>>> Hmm... AppVeyor is just for the Windows builds. We might want to do a
>>> beta release for such crucial fixes and then point to the GitHub releases
>>> page?
>>>
>>> Best,
>>> Marcel
>>>
>>> Am 22.07.2020 19:50:31 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>>>
>>>
>>> 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
>>>
>>>
> _,,,^..^,,,_ (phone)
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200821/ecb828d7/attachment.html>