[squeak-dev] trunk and new vm etiquette

karl ramberg karlramberg at gmail.com
Tue Jul 28 18:31:11 UTC 2020


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 at hpi.de>
wrote:

> Works:
>
> 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
> >
> >
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200728/9dad89b0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 86521 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200728/9dad89b0/attachment-0001.png>


More information about the Squeak-dev mailing list