trunk and new vm etiquette

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

trunk and new vm etiquette

Eliot Miranda-2
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


Reply | Threaded
Open this post in threaded view
|

Re: trunk and new vm etiquette

Jakob Reschke-2
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
>

Reply | Threaded
Open this post in threaded view
|

Re: trunk and new vm etiquette

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

Reply | Threaded
Open this post in threaded view
|

Re: trunk and new vm etiquette

Eliot Miranda-2
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


Reply | Threaded
Open this post in threaded view
|

Re: trunk and new vm etiquette

David T. Lewis
In reply to this post by Jakob Reschke-2
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
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: trunk and new vm etiquette

Eliot Miranda-2
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


Reply | Threaded
Open this post in threaded view
|

Re: trunk and new vm etiquette

David T. Lewis
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

>


Reply | Threaded
Open this post in threaded view
|

Re: trunk and new vm etiquette

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



Reply | Threaded
Open this post in threaded view
|

Re: trunk and new vm etiquette

Eliot Miranda-2
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


Reply | Threaded
Open this post in threaded view
|

Re: trunk and new vm etiquette

marcel.taeumel
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.

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

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


Reply | Threaded
Open this post in threaded view
|

Re: trunk and new vm etiquette

Eliot Miranda-2
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
>
>



Reply | Threaded
Open this post in threaded view
|

Re: trunk and new vm etiquette

marcel.taeumel
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
>
>



Reply | Threaded
Open this post in threaded view
|

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

timrowledge


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.




Reply | Threaded
Open this post in threaded view
|

Re: trunk and new vm etiquette

Eliot Miranda-2
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
>
>




Reply | Threaded
Open this post in threaded view
|

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

Jakob Reschke-2
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.
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: trunk and new vm etiquette

marcel.taeumel
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
>
>




Reply | Threaded
Open this post in threaded view
|

Re: trunk and new vm etiquette

marcel.taeumel
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
>
>




Reply | Threaded
Open this post in threaded view
|

Re: trunk and new vm etiquette

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





Reply | Threaded
Open this post in threaded view
|

Re: trunk and new vm etiquette

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