> On Aug 21, 2020, at 6:51 AM, Fabio Niephaus <lists at fniephaus.com> wrote:
> 
> On Fri, Aug 21, 2020 at 3:29 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?
>> 
>> 
>> Always, by policy.  Until a major release new VMs are always backwards-compatible.  If a particular VM change breaks backward compatibility then then it is a buggy VM unless the old behaviour was suspect/a bug.  At a major release, and only at a major release, significant backward compatibility support may be dropped.
> 
> The problem is that I have been the one publishing releases, but I
> don't know whether a release should be marked as major or not. That's
> why I asked. So I understand this one is a minor fix and I can release
> the current tip as a new minor release?

I would want us to use the most recent vm to pass all the tests.  In my own work with 3dicc and my own daily work I always use the most up-to-date vm I have available (given that naturally I build my own VMs).

But that degree of churn might be unnecessary; often a change is minor, little more than a clean up.  If creating and releasing a new bundle can be automated once tests pass then make this the case.  Otherwise do what feels comfortable, say once a month.

> 
> Fabio
> 
>> 
>> But the basic idea of the VM, which should be true for most VMs, be they Smalltalk or VMWare, is that they get better, but continue to implement the same machine with no change to existing semantics and functionality.
>> 
>> You can see in the progression from V3 VMs to Spur VMs an example of a major change.  Lots of backwards compatibility was dropped to allow substantial improvement.
>> 
>> You can see Nicolas’ work on X11 events (IIRC) as an example of a minor change that broke some older images which were working around a VM bug with events.  We judged it better to fix and clarify the convoluted X11 event handling code rather than continue to support perfect backwards compatibility hete.
>> 
>> But in general day-to-day vm changes are bug fixes and enhancements they *do not* break backwards compatibility.  If they did this wouldn’t be a production VM but some kind of research vehicle.  The OpenSmalltalk-vm attempts very much to be a production vm.
>> 
>> Eliot,
>> _,,,^..^,,,_ (phone)
>> 
>> 
>> 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
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>