Smalltalk › Squeak › Squeak - Dev

trunk and new vm etiquette

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

Eliot Miranda-2

trunk and new vm etiquette

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.
_,,,^..^,,,_
best, Eliot

Jakob Reschke

Re: trunk and new vm etiquette

Hi Eliot,

I only ever upgrade my VM if something breaks or if I am asked to. So
if you'd post a message with something like "Please upgrade your VM"
in the subject line to the list once you push the changes to Trunk,
that would be great for me!

Concerning the time span: in an ideal world I would say "as soon as
the CI is green", but I have my doubts that this will be enough for
Squeak. Assuming that you use the new VM immediately and frequently
(or anyone else does), I think a day of work up to a week after the VM
changes is fine. Or as soon as you are confident about it, however you
measure that. ;-)

Kind regards,
Jakob

Am Di., 21. Juli 2020 um 02:55 Uhr schrieb Eliot Miranda
<[hidden email]>:

>
> 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.
> _,,,^..^,,,_
> best, Eliot
>

Levente Uzonyi

Re: trunk and new vm etiquette

In reply to this post by Eliot Miranda-2

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
>
>

Eliot Miranda-2

Re: trunk and new vm etiquette

Hi Levente,

On Tue, Jul 21, 2020 at 11:21 AM Levente Uzonyi <[hidden email]> wrote:

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.

That's a great idea. I should have thought of that one myself. I'll do exactly that. Thanks!

Levente

> _,,,^..^,,,_
> best, Eliot
>
>

_,,,^..^,,,_

best, Eliot

David T. Lewis

Re: trunk and new vm etiquette

In reply to this post by Jakob Reschke

About a week's advance notice on the list(s) seems pretty reasonable,
possibly with an <ACK> from the CI folks to make sure. Switching VMs
might be an inconvenience, but this is trunk after all and that's what
it's for.

I'm assuming that "broken" means the the user would see some failing
tests due to the need for updated VM support, but the image would
still run and be somewhat functional on the previous VM.

This might also be an opportune time to add primitiveMultipleBytecodeSetsActive
if you are so inclined. It requires trunk users to update their VM before
the image format number can be updated, so it would be convenient if
it could come along with the primitiveAt[Put] changes.

Dave

On Tue, Jul 21, 2020 at 11:45:27AM +0200, Jakob Reschke wrote:

> Hi Eliot,
>
> I only ever upgrade my VM if something breaks or if I am asked to. So
> if you'd post a message with something like "Please upgrade your VM"
> in the subject line to the list once you push the changes to Trunk,
> that would be great for me!
>
> Concerning the time span: in an ideal world I would say "as soon as
> the CI is green", but I have my doubts that this will be enough for
> Squeak. Assuming that you use the new VM immediately and frequently
> (or anyone else does), I think a day of work up to a week after the VM
> changes is fine. Or as soon as you are confident about it, however you
> measure that. ;-)
>
> Kind regards,
> Jakob
>
> Am Di., 21. Juli 2020 um 02:55 Uhr schrieb Eliot Miranda
> <[hidden email]>:
> >
> > 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.
> > _,,,^..^,,,_
> > best, Eliot
> >
>

Eliot Miranda-2

Re: trunk and new vm etiquette

Hi David,

On Tue, Jul 21, 2020 at 12:24 PM David T. Lewis <[hidden email]> wrote:

About a week's advance notice on the list(s) seems pretty reasonable,
possibly with an <ACK> from the CI folks to make sure. Switching VMs
might be an inconvenience, but this is trunk after all and that's what
it's for.

I'm assuming that "broken" means the the user would see some failing
tests due to the need for updated VM support, but the image would
still run and be somewhat functional on the previous VM.

This might also be an opportune time to add primitiveMultipleBytecodeSetsActive
if you are so inclined. It requires trunk users to update their VM before
the image format number can be updated, so it would be convenient if
it could come along with the primitiveAt[Put] changes.

We still have to discuss this. I'm sorry, been too busy to do so. I still don't understand the intent here. The VM already provides a status bit in parameter 65 which says whether the VM supports multiple bytecode sets. If the intent is to mark an image when multiple bytecode sets have been used then the primitive doesn't appear to me to do what's required. I'll try and answer in the context of the thread soon, because I agree it's important. Ideally there would be a pair of flags set somewhere that said if the current image had ever executed a method in either bytecode set.

Dave

On Tue, Jul 21, 2020 at 11:45:27AM +0200, Jakob Reschke wrote:
> Hi Eliot,
>
> I only ever upgrade my VM if something breaks or if I am asked to. So
> if you'd post a message with something like "Please upgrade your VM"
> in the subject line to the list once you push the changes to Trunk,
> that would be great for me!
>
> Concerning the time span: in an ideal world I would say "as soon as
> the CI is green", but I have my doubts that this will be enough for
> Squeak. Assuming that you use the new VM immediately and frequently
> (or anyone else does), I think a day of work up to a week after the VM
> changes is fine. Or as soon as you are confident about it, however you
> measure that. ;-)
>
> Kind regards,
> Jakob
>
> Am Di., 21. Juli 2020 um 02:55 Uhr schrieb Eliot Miranda
> <[hidden email]>:
> >
> > 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.
> > _,,,^..^,,,_
> > best, Eliot
> >
>

_,,,^..^,,,_

best, Eliot

David T. Lewis

Re: trunk and new vm etiquette

He Eliot,

On Tue, Jul 21, 2020 at 12:29:49PM -0700, Eliot Miranda wrote:

> Hi David,
>
> On Tue, Jul 21, 2020 at 12:24 PM David T. Lewis <[hidden email]> wrote:
>
> > About a week's advance notice on the list(s) seems pretty reasonable,
> > possibly with an <ACK> from the CI folks to make sure. Switching VMs
> > might be an inconvenience, but this is trunk after all and that's what
> > it's for.
> >
> > I'm assuming that "broken" means the the user would see some failing
> > tests due to the need for updated VM support, but the image would
> > still run and be somewhat functional on the previous VM.
> >
> > This might also be an opportune time to add
> > primitiveMultipleBytecodeSetsActive
> > if you are so inclined. It requires trunk users to update their VM before
> > the image format number can be updated, so it would be convenient if
> > it could come along with the primitiveAt[Put] changes.
> >
>
> We still have to discuss this. I'm sorry, been too busy to do so. I still
> don't understand the intent here. The VM already provides a status bit in
> parameter 65 which says whether the VM supports multiple bytecode sets. If
> the intent is to mark an image when multiple bytecode sets have been used
> then the primitive doesn't appear to me to do what's required. I'll try
> and answer in the context of the thread soon, because I agree it's
> important.

Thanks :-)

> Ideally there would be a pair of flags set somewhere that said
> if the current image had ever executed a method in either bytecode set.
>

Yes, that would be better if it can be done without affecting performance.

Dave

>
> > Dave
> >
> >
> > On Tue, Jul 21, 2020 at 11:45:27AM +0200, Jakob Reschke wrote:
> > > Hi Eliot,
> > >
> > > I only ever upgrade my VM if something breaks or if I am asked to. So
> > > if you'd post a message with something like "Please upgrade your VM"
> > > in the subject line to the list once you push the changes to Trunk,
> > > that would be great for me!
> > >
> > > Concerning the time span: in an ideal world I would say "as soon as
> > > the CI is green", but I have my doubts that this will be enough for
> > > Squeak. Assuming that you use the new VM immediately and frequently
> > > (or anyone else does), I think a day of work up to a week after the VM
> > > changes is fine. Or as soon as you are confident about it, however you
> > > measure that. ;-)
> > >
> > > Kind regards,
> > > Jakob
> > >
> > > Am Di., 21. Juli 2020 um 02:55 Uhr schrieb Eliot Miranda
> > > <[hidden email]>:
> > > >
> > > > 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.
> > > > _,,,^..^,,,_
> > > > best, Eliot
> > > >
> > >
> >
> >
>
> --
> _,,,^..^,,,_
> best, Eliot

codefrau

Re: trunk and new vm etiquette

In reply to this post by Eliot Miranda-2

On Tue, Jul 21, 2020 at 12:30 PM Eliot Miranda <[hidden email]> wrote:

Hi David,

On Tue, Jul 21, 2020 at 12:24 PM David T. Lewis <[hidden email]> wrote:

This might also be an opportune time to add primitiveMultipleBytecodeSetsActive
if you are so inclined. It requires trunk users to update their VM before
the image format number can be updated, so it would be convenient if
it could come along with the primitiveAt[Put] changes.

We still have to discuss this. I'm sorry, been too busy to do so. I still don't understand the intent here. The VM already provides a status bit in parameter 65 which says whether the VM supports multiple bytecode sets. If the intent is to mark an image when multiple bytecode sets have been used then the primitive doesn't appear to me to do what's required. I'll try and answer in the context of the thread soon, because I agree it's important. Ideally there would be a pair of flags set somewhere that said if the current image had ever executed a method in either bytecode set.

All VMs check the image format to see if they can run the image. That's the only check they perform, as far as I know.

That's why it seems appropriate to use a bit in the image format to mean "no, you can't run this if your VM does not understand the new byte code set".

Otherwise e.g. SqueakJS or other Spur-compatible VMs would have to look at every single CompiledMethod to see if the alt byte code flag was set.

Btw, Squeak is not going to mix bytecode sets - it's going to recompile all methods, so when snapshotting, they all use one or the other. In that scenario, a simple primitive call like David's should work, if it's done right after recompiling all.

- Vanessa -

Eliot Miranda-2

Re: trunk and new vm etiquette

Hi Vanessa,

On Tue, Jul 21, 2020 at 4:52 PM Vanessa Freudenberg <[hidden email]> wrote:

On Tue, Jul 21, 2020 at 12:30 PM Eliot Miranda <[hidden email]> wrote:
Hi David,

On Tue, Jul 21, 2020 at 12:24 PM David T. Lewis <[hidden email]> wrote:

This might also be an opportune time to add primitiveMultipleBytecodeSetsActive
if you are so inclined. It requires trunk users to update their VM before
the image format number can be updated, so it would be convenient if
it could come along with the primitiveAt[Put] changes.

We still have to discuss this. I'm sorry, been too busy to do so. I still don't understand the intent here. The VM already provides a status bit in parameter 65 which says whether the VM supports multiple bytecode sets. If the intent is to mark an image when multiple bytecode sets have been used then the primitive doesn't appear to me to do what's required. I'll try and answer in the context of the thread soon, because I agree it's important. Ideally there would be a pair of flags set somewhere that said if the current image had ever executed a method in either bytecode set.

let's discuss this in the context of the thread David started.

All VMs check the image format to see if they can run the image. That's the only check they perform, as far as I know.

That's why it seems appropriate to use a bit in the image format to mean "no, you can't run this if your VM does not understand the new byte code set".

Otherwise e.g. SqueakJS or other Spur-compatible VMs would have to look at every single CompiledMethod to see if the alt byte code flag was set.

Btw, Squeak is not going to mix bytecode sets - it's going to recompile all methods, so when snapshotting, they all use one or the other. In that scenario, a simple primitive call like David's should work, if it's done right after recompiling all.

Alas no. We already mix bytecode sets. IOne can set the preference do some compiling, change the preference, do some compiling, etcd. And so far I've been too lazy to make the quick method generation use the preference. All quick methods are in the original bytecode set (since quick methods don't really use a bytecode other than the primitive bytecode).

But as I ask, I think we should discuss this in the thread David created.

- Vanessa -

_,,,^..^,,,_

best, Eliot

marcel.taeumel

Re: trunk and new vm etiquette

In reply to this post by Levente Uzonyi

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.

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"

Best,

Marcel

Am 21.07.2020 20:21:39 schrieb Levente Uzonyi <[hidden email]>:
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
>
>

Eliot Miranda-2

Re: trunk and new vm etiquette

In reply to this post by Eliot Miranda-2

On Jul 22, 2020, at 12:49 AM, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:
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
>
>

marcel.taeumel

Re: trunk and new vm etiquette

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 <[hidden email]>:

On Jul 22, 2020, at 12:49 AM, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:
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
>
>

timrowledge

triggering URLs from Squeak (was Re: trunk and new vm etiquette)

On 2020-07-22, at 7:43 AM, Marcel Taeumel <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
I am still waiting for the advent of the computer science groupie.

Eliot Miranda-2

Re: trunk and new vm etiquette

In reply to this post by marcel.taeumel

On Jul 22, 2020, at 7:44 AM, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:

On Jul 22, 2020, at 12:49 AM, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:
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
>
>

Jakob Reschke

Re: triggering URLs from Squeak (was Re: trunk and new vm etiquette)

In reply to this post by timrowledge

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 <[hidden email]>:

>
>
>
> On 2020-07-22, at 7:43 AM, Marcel Taeumel <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
> I am still waiting for the advent of the computer science groupie.
>
>
>

marcel.taeumel

Re: trunk and new vm etiquette

In reply to this post by Eliot Miranda-2

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 <[hidden email]>:

On Jul 22, 2020, at 7:44 AM, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:

On Jul 22, 2020, at 12:49 AM, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:
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
>
>

marcel.taeumel

Re: trunk and new vm etiquette

Works:

Best,

Marcel

Am 23.07.2020 13:41:17 schrieb Marcel Taeumel <[hidden email]>:
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 <[hidden email]>:

On Jul 22, 2020, at 7:44 AM, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:

On Jul 22, 2020, at 12:49 AM, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:
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
>
>

Karl Ramberg

Re: trunk and new vm etiquette

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 <[hidden email]> wrote:

Works:

Best,
Marcel

Am 23.07.2020 13:41:17 schrieb Marcel Taeumel <[hidden email]>:
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 <[hidden email]>:

On Jul 22, 2020, at 7:44 AM, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:

On Jul 22, 2020, at 12:49 AM, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:
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
>
>

fniephaus

Re: trunk and new vm etiquette

On Tue, 28 Jul 2020 at 8:31 pm, karl ramberg <[hidden email]> 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 <[hidden email]> wrote:
Works:

Best,
Marcel

Am 23.07.2020 13:41:17 schrieb Marcel Taeumel <[hidden email]>:
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 <[hidden email]>:

On Jul 22, 2020, at 7:44 AM, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:

On Jul 22, 2020, at 12:49 AM, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:
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
>
>

Eliot Miranda-2

Re: trunk and new vm etiquette

Hi Fabio,

On Jul 28, 2020, at 12:10 PM, Fabio Niephaus <[hidden email]> wrote:

On Tue, 28 Jul 2020 at 8:31 pm, karl ramberg <[hidden email]> 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 <[hidden email]> wrote:
Works:
<image.png>

Best,
Marcel

Am 23.07.2020 13:41:17 schrieb Marcel Taeumel <[hidden email]>:
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 <[hidden email]>:

On Jul 22, 2020, at 7:44 AM, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:

On Jul 22, 2020, at 12:49 AM, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:
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
>
>