On Jul 22, 2020, at 12:49 AM, Marcel Taeumel marcel.taeumel@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@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
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@gmail.com:
On Jul 22, 2020, at 12:49 AM, Marcel Taeumel marcel.taeumel@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@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
On 2020-07-22, at 7:43 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Eliot,
looks good. In "About Squeak", we point to "Visit https://github.com/OpenSmalltalk/opensmalltalk-vm".
That reminds me; currently the system would complain about o web browser and offer this -
We can do better, for certain probably interesting definitions of the word 'better'. In Scratch we use the ScratchPlugin primitive primOpenURL: and that defers to platform code within the plugin. In unix-land it uses the slightly scary xdg-open facility; I have no idea what the equivalent might be for other platforms but surely it must be doable.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim I am still waiting for the advent of the computer science groupie.
In my image I have wired this for Windows to ShellExecute via FFI. One could put it in a plugin as well.
Object subclass: #ExternalWindowsWebBrowser instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'jr'
initialize "ExternalWindowsWebBrowser initialize" WebBrowser register: self.
openOnUrl: aUrl ShellExecute execute: aUrl asString.
Object subclass: #ShellExecute instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'jr'
execute: aString self assert: aString isString. ^ self apiShellExecuteForWindow: nil operation: nil file: aString parameters: nil directory: nil show: 5 "SW_SHOW"
apiShellExecuteForWindow: hwnd operation: operationString file: fileString parameters: parametersString directory: directoryString show: aBitfieldInteger <apicall: void* 'ShellExecuteA' (void* char* char* char* char* long) module: 'Shell32.dll'> ^ self externalCallFailed
Am Mi., 22. Juli 2020 um 19:34 Uhr schrieb tim Rowledge tim@rowledge.org:
On 2020-07-22, at 7:43 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Eliot,
looks good. In "About Squeak", we point to "Visit https://github.com/OpenSmalltalk/opensmalltalk-vm".
That reminds me; currently the system would complain about o web browser and offer this -
We can do better, for certain probably interesting definitions of the word 'better'. In Scratch we use the ScratchPlugin primitive primOpenURL: and that defers to platform code within the plugin. In unix-land it uses the slightly scary xdg-open facility; I have no idea what the equivalent might be for other platforms but surely it must be doable.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim I am still waiting for the advent of the computer science groupie.
On Jul 22, 2020, at 7:44 AM, Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 12:49 AM, Marcel Taeumel marcel.taeumel@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@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
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@gmail.com:
On Jul 22, 2020, at 7:44 AM, Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 12:49 AM, Marcel Taeumel marcel.taeumel@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@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
Works:
Best, Marcel Am 23.07.2020 13:41:17 schrieb Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 7:44 AM, Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 12:49 AM, Marcel Taeumel marcel.taeumel@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@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
Who can update so that new bundles from http://files.squeak.org/trunk/ uses new VM ?
Best, Karl
On Mon, Jul 27, 2020 at 10:47 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Works:
Best, Marcel
Am 23.07.2020 13:41:17 schrieb Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 7:44 AM, Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 12:49 AM, Marcel Taeumel marcel.taeumel@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@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
On Tue, 28 Jul 2020 at 8:31 pm, karl ramberg karlramberg@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@hpi.de wrote:
Works:
Best, Marcel
Am 23.07.2020 13:41:17 schrieb Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 7:44 AM, Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 12:49 AM, Marcel Taeumel marcel.taeumel@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@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
Hi Fabio,
On Jul 28, 2020, at 12:10 PM, Fabio Niephaus lists@fniephaus.com wrote:
On Tue, 28 Jul 2020 at 8:31 pm, karl ramberg karlramberg@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.
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@hpi.de wrote: Works: <image.png>
Best, Marcel
Am 23.07.2020 13:41:17 schrieb Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 7:44 AM, Marcel Taeumel marcel.taeumel@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@gmail.com: > > > >>> On Jul 22, 2020, at 12:49 AM, Marcel Taeumel marcel.taeumel@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@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 >>> > >>> > >>
On Fri, Aug 21, 2020 at 3:29 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Fabio,
On Jul 28, 2020, at 12:10 PM, Fabio Niephaus lists@fniephaus.com wrote:
On Tue, 28 Jul 2020 at 8:31 pm, karl ramberg karlramberg@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?
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@hpi.de wrote:
Works: <image.png>
Best, Marcel
Am 23.07.2020 13:41:17 schrieb Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 7:44 AM, Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 12:49 AM, Marcel Taeumel marcel.taeumel@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@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
On Aug 21, 2020, at 6:51 AM, Fabio Niephaus lists@fniephaus.com wrote:
On Fri, Aug 21, 2020 at 3:29 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Fabio,
On Jul 28, 2020, at 12:10 PM, Fabio Niephaus lists@fniephaus.com wrote:
On Tue, 28 Jul 2020 at 8:31 pm, karl ramberg karlramberg@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@hpi.de wrote:
Works: <image.png>
Best, Marcel
Am 23.07.2020 13:41:17 schrieb Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 7:44 AM, Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 12:49 AM, Marcel Taeumel marcel.taeumel@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@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
Hi Fabio,
On Jul 28, 2020, at 12:10 PM, Fabio Niephaus lists@fniephaus.com wrote:
On Tue, 28 Jul 2020 at 8:31 pm, karl ramberg karlramberg@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@hpi.de wrote:
Works: <image.png>
Best, Marcel
Am 23.07.2020 13:41:17 schrieb Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 7:44 AM, Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 12:49 AM, Marcel Taeumel marcel.taeumel@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@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)
oops, please ignore...
On Fri, Aug 21, 2020 at 12:06 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Fabio,
On Jul 28, 2020, at 12:10 PM, Fabio Niephaus lists@fniephaus.com wrote:
On Tue, 28 Jul 2020 at 8:31 pm, karl ramberg karlramberg@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@hpi.de wrote:
Works: <image.png>
Best, Marcel
Am 23.07.2020 13:41:17 schrieb Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 7:44 AM, Marcel Taeumel marcel.taeumel@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@gmail.com:
On Jul 22, 2020, at 12:49 AM, Marcel Taeumel marcel.taeumel@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@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)
squeak-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Fabio Niephaus -
Jakob Reschke -
karl ramberg -
Marcel Taeumel -
tim Rowledge