[squeak-dev] trunk and new vm etiquette

Eliot Miranda eliot.miranda at gmail.com
Tue Jul 21 19:29:49 UTC 2020


Hi David,

On Tue, Jul 21, 2020 at 12:24 PM David T. Lewis <lewis at mail.msen.com> 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
> > <eliot.miranda at gmail.com>:
> > >
> > > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/c2da21d0/attachment.html>


More information about the Squeak-dev mailing list