Squeak 4.6 -- 2nd release candidate

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

Squeak 4.6 -- 2nd release candidate

Chris Muller-4
Squeak4.6-15093 is now available at http://ftp.squeak.org/4.6/.  It
addresses the issues we found with RC1.

The sources file was rebuilt again, which means the prior
SqueakV46.sources file should not be trusted.  For that reason, I
actually decided to remove the RC1 files.

Eliot said he wants to build the Cog VM one more time.  Then I'll try
to assemble the All-In-One.

Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

Eliot Miranda-2
Hi Chris,

On Mon, Jul 6, 2015 at 3:57 PM, Chris Muller <[hidden email]> wrote:
Squeak4.6-15093 is now available at http://ftp.squeak.org/4.6/.  It
addresses the issues we found with RC1.

The sources file was rebuilt again, which means the prior
SqueakV46.sources file should not be trusted.  For that reason, I
actually decided to remove the RC1 files.

Eliot said he wants to build the Cog VM one more time.  Then I'll try
to assemble the All-In-One.

The 3397 VMs are good to go. 
--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

David T. Lewis
In reply to this post by Chris Muller-4
On Mon, Jul 06, 2015 at 05:57:01PM -0500, Chris Muller wrote:
> Squeak4.6-15093 is now available at http://ftp.squeak.org/4.6/.  It
> addresses the issues we found with RC1.
>
> The sources file was rebuilt again, which means the prior
> SqueakV46.sources file should not be trusted.  For that reason, I
> actually decided to remove the RC1 files.
>
> Eliot said he wants to build the Cog VM one more time.  Then I'll try
> to assemble the All-In-One.

Thanks Chris!

The RC2 image has the same "crash the interpreter" issue as RC1. Based
on your earlier note, I tried this today:

- Start with Squeak4.5-13680.image from ftp.squeak.org

- Using Cog, updated the image to latest current trunk, producing "Squeak4.5 of 6 July 2015 update 15093"

- Save image and restart under interpreter VM.

- Open SqueakMap, update it, and load TwosComplement
    ==> no problem

- Quit image, no save.

- Restart image on interpreter VM

- Evaluate ReleaseBuilder prepareNewRelease (enter password)

  Notes:
  Warning: Tools-topa.520 not found in trunk.
  Warning: Kernel-topa.845 not found in trunk.
  Warning: Display extent not set to 800@600
  Error: Missing snapshot: Sound-nice.38
    ==> fail, errors related to sound package

- Try again under Cog, same errors. Maybe needs to run on Mac?

So at this point I can confirm that a trunk image fully updated
from Squeak 4.5 works fine, with the update done on a Cog VM. However
I am not able to run the prepareNewRelease to see its effect.

The errors I am getting in #prepareNewRelease seem to be related to
the sound package, so maybe it is some problem with my local system.

Any advice? I am assuming that you are doing the build on your own
system, so maybe you could give me a copy of the image that you produce
immediately prior to running #prepareNewRelease? That should be equivalent
to the image that I just updated (which works without problems), so
that might give us an indication of whether the problem is introduced
in #prepareNewRelease or somewhere else.

Thanks (and thanks for your patience in working through these issues),

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

Chris Muller-3
Hi Dave,

>> Squeak4.6-15093 is now available at http://ftp.squeak.org/4.6/.  It
>> addresses the issues we found with RC1.
>>
>> The sources file was rebuilt again, which means the prior
>> SqueakV46.sources file should not be trusted.  For that reason, I
>> actually decided to remove the RC1 files.
>>
>> Eliot said he wants to build the Cog VM one more time.  Then I'll try
>> to assemble the All-In-One.
>
> Thanks Chris!
>
> The RC2 image has the same "crash the interpreter" issue as RC1. Based
> on your earlier note, I tried this today:
>
> - Start with Squeak4.5-13680.image from ftp.squeak.org
>
> - Using Cog, updated the image to latest current trunk, producing "Squeak4.5 of 6 July 2015 update 15093"
>
> - Save image and restart under interpreter VM.
>
> - Open SqueakMap, update it, and load TwosComplement
>     ==> no problem

Ok, so the problem must be something in the #prepareRelease process.

> - Quit image, no save.
>
> - Restart image on interpreter VM
>
> - Evaluate ReleaseBuilder prepareNewRelease (enter password)

#prepareNewRelease is not meant to be run from a release image
(although that is not a bad idea to support).

Dave, for debugging this, you don't need to be doing the part of
prepareNewRelease which copies the mcz's because most likely that has
nothing to do with the VM crash.  You just need to look into all the
things prepareNewRelease does to make a educated guess about which is
causing the problem.

>   Notes:
>   Warning: Tools-topa.520 not found in trunk.
>   Warning: Kernel-topa.845 not found in trunk.
>   Warning: Display extent not set to 800@600
>   Error: Missing snapshot: Sound-nice.38
>     ==> fail, errors related to sound package

These are probably 4.5-specific packages, backported fixes.  Again,
#prepareNewRelease is not meant to be run in a release image..

> - Try again under Cog, same errors. Maybe needs to run on Mac?
>
> So at this point I can confirm that a trunk image fully updated
> from Squeak 4.5 works fine, with the update done on a Cog VM. However
> I am not able to run the prepareNewRelease to see its effect.
>
> The errors I am getting in #prepareNewRelease seem to be related to
> the sound package, so maybe it is some problem with my local system.
>
> Any advice? I am assuming that you are doing the build on your own
> system, so maybe you could give me a copy of the image that you produce
> immediately prior to running #prepareNewRelease? That should be equivalent
> to the image that I just updated

Yep.

(which works without problems), so
> that might give us an indication of whether the problem is introduced
> in #prepareNewRelease or somewhere else.

Please look into what prepareNewRelease does, it calls
prepareNewBuild, which is nothing magical or stripping or unloading or
anything.  Its just a bunch of minor cleanups followed by
condenseSources.  I would start with everything up to the
condenseSources first, see if that doesn't blow up..

Certainly, we want and need to still run on the classic interpreter
VM.  Please let me know soonish if you find the problem so we can
correct it for the release.

>
> Thanks (and thanks for your patience in working through these issues),
>
> Dave
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

Chris Muller-3
In reply to this post by David T. Lewis
Probably the Compiler recompileAll..?

On Mon, Jul 6, 2015 at 6:31 PM, David T. Lewis <[hidden email]> wrote:

> On Mon, Jul 06, 2015 at 05:57:01PM -0500, Chris Muller wrote:
>> Squeak4.6-15093 is now available at http://ftp.squeak.org/4.6/.  It
>> addresses the issues we found with RC1.
>>
>> The sources file was rebuilt again, which means the prior
>> SqueakV46.sources file should not be trusted.  For that reason, I
>> actually decided to remove the RC1 files.
>>
>> Eliot said he wants to build the Cog VM one more time.  Then I'll try
>> to assemble the All-In-One.
>
> Thanks Chris!
>
> The RC2 image has the same "crash the interpreter" issue as RC1. Based
> on your earlier note, I tried this today:
>
> - Start with Squeak4.5-13680.image from ftp.squeak.org
>
> - Using Cog, updated the image to latest current trunk, producing "Squeak4.5 of 6 July 2015 update 15093"
>
> - Save image and restart under interpreter VM.
>
> - Open SqueakMap, update it, and load TwosComplement
>     ==> no problem
>
> - Quit image, no save.
>
> - Restart image on interpreter VM
>
> - Evaluate ReleaseBuilder prepareNewRelease (enter password)
>
>   Notes:
>   Warning: Tools-topa.520 not found in trunk.
>   Warning: Kernel-topa.845 not found in trunk.
>   Warning: Display extent not set to 800@600
>   Error: Missing snapshot: Sound-nice.38
>     ==> fail, errors related to sound package
>
> - Try again under Cog, same errors. Maybe needs to run on Mac?
>
> So at this point I can confirm that a trunk image fully updated
> from Squeak 4.5 works fine, with the update done on a Cog VM. However
> I am not able to run the prepareNewRelease to see its effect.
>
> The errors I am getting in #prepareNewRelease seem to be related to
> the sound package, so maybe it is some problem with my local system.
>
> Any advice? I am assuming that you are doing the build on your own
> system, so maybe you could give me a copy of the image that you produce
> immediately prior to running #prepareNewRelease? That should be equivalent
> to the image that I just updated (which works without problems), so
> that might give us an indication of whether the problem is introduced
> in #prepareNewRelease or somewhere else.
>
> Thanks (and thanks for your patience in working through these issues),
>
> Dave
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

David T. Lewis
On Mon, Jul 06, 2015 at 09:46:09PM -0500, Chris Muller wrote:
> Probably the Compiler recompileAll..?

Confirmed.

Compiler recompileAll results in an image that crashes the interpreter VM.
A fully updated trunk image works fine, but recompiling it breaks the image.

Dave


>
> On Mon, Jul 6, 2015 at 6:31 PM, David T. Lewis <[hidden email]> wrote:
> > On Mon, Jul 06, 2015 at 05:57:01PM -0500, Chris Muller wrote:
> >> Squeak4.6-15093 is now available at http://ftp.squeak.org/4.6/.  It
> >> addresses the issues we found with RC1.
> >>
> >> The sources file was rebuilt again, which means the prior
> >> SqueakV46.sources file should not be trusted.  For that reason, I
> >> actually decided to remove the RC1 files.
> >>
> >> Eliot said he wants to build the Cog VM one more time.  Then I'll try
> >> to assemble the All-In-One.
> >
> > Thanks Chris!
> >
> > The RC2 image has the same "crash the interpreter" issue as RC1. Based
> > on your earlier note, I tried this today:
> >
> > - Start with Squeak4.5-13680.image from ftp.squeak.org
> >
> > - Using Cog, updated the image to latest current trunk, producing "Squeak4.5 of 6 July 2015 update 15093"
> >
> > - Save image and restart under interpreter VM.
> >
> > - Open SqueakMap, update it, and load TwosComplement
> >     ==> no problem
> >
> > - Quit image, no save.
> >
> > - Restart image on interpreter VM
> >
> > - Evaluate ReleaseBuilder prepareNewRelease (enter password)
> >
> >   Notes:
> >   Warning: Tools-topa.520 not found in trunk.
> >   Warning: Kernel-topa.845 not found in trunk.
> >   Warning: Display extent not set to 800@600
> >   Error: Missing snapshot: Sound-nice.38
> >     ==> fail, errors related to sound package
> >
> > - Try again under Cog, same errors. Maybe needs to run on Mac?
> >
> > So at this point I can confirm that a trunk image fully updated
> > from Squeak 4.5 works fine, with the update done on a Cog VM. However
> > I am not able to run the prepareNewRelease to see its effect.
> >
> > The errors I am getting in #prepareNewRelease seem to be related to
> > the sound package, so maybe it is some problem with my local system.
> >
> > Any advice? I am assuming that you are doing the build on your own
> > system, so maybe you could give me a copy of the image that you produce
> > immediately prior to running #prepareNewRelease? That should be equivalent
> > to the image that I just updated (which works without problems), so
> > that might give us an indication of whether the problem is introduced
> > in #prepareNewRelease or somewhere else.
> >
> > Thanks (and thanks for your patience in working through these issues),
> >
> > Dave
> >
> >

Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

Chris Muller-4
On Tue, Jul 7, 2015 at 7:33 AM, David T. Lewis <[hidden email]> wrote:
> On Mon, Jul 06, 2015 at 09:46:09PM -0500, Chris Muller wrote:
>> Probably the Compiler recompileAll..?
>
> Confirmed.
>
> Compiler recompileAll results in an image that crashes the interpreter VM.
> A fully updated trunk image works fine, but recompiling it breaks the image.

Interpreter VM will not be able to run Spur images going forward.  So
this is the last possible release to support the Interpreter VM anyway
is that right?

Maybe it is time to abandon Interpreter VMj?  Or release 4.6 without
the recompileAll and release 5.0 with it?

Please let me know how you would like to proceed.

Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

Tobias Pape

On 07.07.2015, at 17:11, Chris Muller <[hidden email]> wrote:

> On Tue, Jul 7, 2015 at 7:33 AM, David T. Lewis <[hidden email]> wrote:
>> On Mon, Jul 06, 2015 at 09:46:09PM -0500, Chris Muller wrote:
>>> Probably the Compiler recompileAll..?
>>
>> Confirmed.
>>
>> Compiler recompileAll results in an image that crashes the interpreter VM.
>> A fully updated trunk image works fine, but recompiling it breaks the image.
>
> Interpreter VM will not be able to run Spur images going forward.

Pardon?

>  So
> this is the last possible release to support the Interpreter VM anyway
> is that right?
>
> Maybe it is time to abandon Interpreter VMj?  Or release 4.6 without
> the recompileAll and release 5.0 with it?
>
> Please let me know how you would like to proceed.



Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

Chris Muller-3
>> Interpreter VM will not be able to run Spur images going forward.
>
> Pardon?

Download latest Spur image and changes:

    http://www.mirandabanda.org/files/Cog/VM/SpurImages/trunk46-spur.image

   http://www.mirandabanda.org/files/Cog/VM/SpurImages/trunk46-spur.changes

and latest interpreter VM.  Then try:

   squeak trunk46-spur.image

Results:

This interpreter (vers. 0) cannot read image file (vers. 6521).
Press CR to quit...

Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

Tobias Pape

On 07.07.2015, at 17:26, Chris Muller <[hidden email]> wrote:

>>> Interpreter VM will not be able to run Spur images going forward.
>>
>> Pardon?
>
> Download latest Spur image and changes:
>
>    http://www.mirandabanda.org/files/Cog/VM/SpurImages/trunk46-spur.image
>
>   http://www.mirandabanda.org/files/Cog/VM/SpurImages/trunk46-spur.changes
>
> and latest interpreter VM.  Then try:
>
>   squeak trunk46-spur.image
>
> Results:
>
> This interpreter (vers. 0) cannot read image file (vers. 6521).
> Press CR to quit...


Well, your sentence sounded as if there's no intention of making the interpreter
VM SPUR-aware whatsoever. Surely I got that wrong, didn't I?

Best regards
        -Tobias


Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

David T. Lewis
In reply to this post by Chris Muller-4
I am away and cannot follow up on this for a while.

My guess would be that there is something wrong in the compiler, and that
it needs to be fixed (but I cannot check now to find out). I don't know if
this affects SqueakJS or other VMs.

Dave

> On Tue, Jul 7, 2015 at 7:33 AM, David T. Lewis <[hidden email]>
> wrote:
>> On Mon, Jul 06, 2015 at 09:46:09PM -0500, Chris Muller wrote:
>>> Probably the Compiler recompileAll..?
>>
>> Confirmed.
>>
>> Compiler recompileAll results in an image that crashes the interpreter
>> VM.
>> A fully updated trunk image works fine, but recompiling it breaks the
>> image.
>
> Interpreter VM will not be able to run Spur images going forward.  So
> this is the last possible release to support the Interpreter VM anyway
> is that right?
>
> Maybe it is time to abandon Interpreter VMj?  Or release 4.6 without
> the recompileAll and release 5.0 with it?
>
> Please let me know how you would like to proceed.
>



Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

Karl Ramberg
This error kind of sound like the error that we had in Spur and Cog a while back. I'm not sure it is related. 


Karl

On Tue, Jul 7, 2015 at 8:31 PM, David T. Lewis <[hidden email]> wrote:
I am away and cannot follow up on this for a while.

My guess would be that there is something wrong in the compiler, and that
it needs to be fixed (but I cannot check now to find out). I don't know if
this affects SqueakJS or other VMs.

Dave

> On Tue, Jul 7, 2015 at 7:33 AM, David T. Lewis <[hidden email]>
> wrote:
>> On Mon, Jul 06, 2015 at 09:46:09PM -0500, Chris Muller wrote:
>>> Probably the Compiler recompileAll..?
>>
>> Confirmed.
>>
>> Compiler recompileAll results in an image that crashes the interpreter
>> VM.
>> A fully updated trunk image works fine, but recompiling it breaks the
>> image.
>
> Interpreter VM will not be able to run Spur images going forward.  So
> this is the last possible release to support the Interpreter VM anyway
> is that right?
>
> Maybe it is time to abandon Interpreter VMj?  Or release 4.6 without
> the recompileAll and release 5.0 with it?
>
> Please let me know how you would like to proceed.
>






Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

Chris Muller-4
In reply to this post by David T. Lewis
Maybe the problem is in the image, the interpreter VM or the
TwosComplement package, we don't know.  Since it does not appear
likely anyone will be able to investigate it soon, and the nature of
both releases is about all-new VM(s) anyway, we probably should not
hold up the release over this.

In fact, I could make another RC without the recompileAll.  Is it
really necessary?  I don't know any better about its purpose than why
it would be a problem.  I guess anyone could do it on their own if
they wanted..


On Tue, Jul 7, 2015 at 1:31 PM, David T. Lewis <[hidden email]> wrote:

> I am away and cannot follow up on this for a while.
>
> My guess would be that there is something wrong in the compiler, and that
> it needs to be fixed (but I cannot check now to find out). I don't know if
> this affects SqueakJS or other VMs.
>
> Dave
>
>> On Tue, Jul 7, 2015 at 7:33 AM, David T. Lewis <[hidden email]>
>> wrote:
>>> On Mon, Jul 06, 2015 at 09:46:09PM -0500, Chris Muller wrote:
>>>> Probably the Compiler recompileAll..?
>>>
>>> Confirmed.
>>>
>>> Compiler recompileAll results in an image that crashes the interpreter
>>> VM.
>>> A fully updated trunk image works fine, but recompiling it breaks the
>>> image.
>>
>> Interpreter VM will not be able to run Spur images going forward.  So
>> this is the last possible release to support the Interpreter VM anyway
>> is that right?
>>
>> Maybe it is time to abandon Interpreter VMj?  Or release 4.6 without
>> the recompileAll and release 5.0 with it?
>>
>> Please let me know how you would like to proceed.
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

David T. Lewis
It's definitely not related to the TwosComplement package. I just offered
that up as an easily repeatable test case. If you run the image for a
while, you will get all kinds of seeminging unrelated crashes, and it just
looks like random failures with no obvious relation to whatever you were
doing at the time.

An image that can't be recompiled is bad, but an image that crashes the
system is worse. Hopefully we can locate the underlying cause and make a
decision based on that.

Without knowing the actual root cause, I can't say much more.

Dave


> Maybe the problem is in the image, the interpreter VM or the
> TwosComplement package, we don't know.  Since it does not appear
> likely anyone will be able to investigate it soon, and the nature of
> both releases is about all-new VM(s) anyway, we probably should not
> hold up the release over this.
>
> In fact, I could make another RC without the recompileAll.  Is it
> really necessary?  I don't know any better about its purpose than why
> it would be a problem.  I guess anyone could do it on their own if
> they wanted..
>
>
> On Tue, Jul 7, 2015 at 1:31 PM, David T. Lewis <[hidden email]>
> wrote:
>> I am away and cannot follow up on this for a while.
>>
>> My guess would be that there is something wrong in the compiler, and
>> that
>> it needs to be fixed (but I cannot check now to find out). I don't know
>> if
>> this affects SqueakJS or other VMs.
>>
>> Dave
>>
>>> On Tue, Jul 7, 2015 at 7:33 AM, David T. Lewis <[hidden email]>
>>> wrote:
>>>> On Mon, Jul 06, 2015 at 09:46:09PM -0500, Chris Muller wrote:
>>>>> Probably the Compiler recompileAll..?
>>>>
>>>> Confirmed.
>>>>
>>>> Compiler recompileAll results in an image that crashes the interpreter
>>>> VM.
>>>> A fully updated trunk image works fine, but recompiling it breaks the
>>>> image.
>>>
>>> Interpreter VM will not be able to run Spur images going forward.  So
>>> this is the last possible release to support the Interpreter VM anyway
>>> is that right?
>>>
>>> Maybe it is time to abandon Interpreter VMj?  Or release 4.6 without
>>> the recompileAll and release 5.0 with it?
>>>
>>> Please let me know how you would like to proceed.
>>>
>>
>>
>



Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

David T. Lewis
In reply to this post by Karl Ramberg
Thanks Karl,

I don't recall the discussion on this, was it something that we covered in
the vm-dev list?

Dave


> This error kind of sound like the error that we had in Spur and Cog a
> while
> back. I'm not sure it is related.
>
>
> Karl
>
> On Tue, Jul 7, 2015 at 8:31 PM, David T. Lewis <[hidden email]>
> wrote:
>
>> I am away and cannot follow up on this for a while.
>>
>> My guess would be that there is something wrong in the compiler, and
>> that
>> it needs to be fixed (but I cannot check now to find out). I don't know
>> if
>> this affects SqueakJS or other VMs.
>>
>> Dave
>>
>> > On Tue, Jul 7, 2015 at 7:33 AM, David T. Lewis <[hidden email]>
>> > wrote:
>> >> On Mon, Jul 06, 2015 at 09:46:09PM -0500, Chris Muller wrote:
>> >>> Probably the Compiler recompileAll..?
>> >>
>> >> Confirmed.
>> >>
>> >> Compiler recompileAll results in an image that crashes the
>> interpreter
>> >> VM.
>> >> A fully updated trunk image works fine, but recompiling it breaks the
>> >> image.
>> >
>> > Interpreter VM will not be able to run Spur images going forward.  So
>> > this is the last possible release to support the Interpreter VM anyway
>> > is that right?
>> >
>> > Maybe it is time to abandon Interpreter VMj?  Or release 4.6 without
>> > the recompileAll and release 5.0 with it?
>> >
>> > Please let me know how you would like to proceed.
>> >
>>
>>
>>
>>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

Eliot Miranda-2
In reply to this post by Tobias Pape
Hi Tobias,

On Tue, Jul 7, 2015 at 8:31 AM, Tobias Pape <[hidden email]> wrote:

On 07.07.2015, at 17:26, Chris Muller <[hidden email]> wrote:

>>> Interpreter VM will not be able to run Spur images going forward.
>>
>> Pardon?
>
> Download latest Spur image and changes:
>
>    http://www.mirandabanda.org/files/Cog/VM/SpurImages/trunk46-spur.image
>
>   http://www.mirandabanda.org/files/Cog/VM/SpurImages/trunk46-spur.changes
>
> and latest interpreter VM.  Then try:
>
>   squeak trunk46-spur.image
>
> Results:
>
> This interpreter (vers. 0) cannot read image file (vers. 6521).
> Press CR to quit...


Well, your sentence sounded as if there's no intention of making the interpreter
VM SPUR-aware whatsoever. Surely I got that wrong, didn't I?

I certainly hope so!  I ant the Interpreter VM to be able to use the Spur memory manager.  But that will realy force a merge of VMMaker and VMMaker.oscog and right now I don't see we have a lot of resource. Volunteers are /very/ welcome!
 

Best regards
        -Tobias





--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

David T. Lewis
In reply to this post by Chris Muller-4
On Tue, Jul 07, 2015 at 02:34:48PM -0500, Chris Muller wrote:

>
> On Tue, Jul 7, 2015 at 1:31 PM, David T. Lewis <[hidden email]> wrote:
> > I am away and cannot follow up on this for a while.
> >
> > My guess would be that there is something wrong in the compiler, and that
> > it needs to be fixed (but I cannot check now to find out). I don't know if
> > this affects SqueakJS or other VMs.
> >
> > Dave
>
> Maybe the problem is in the image, the interpreter VM or the
> TwosComplement package, we don't know.  Since it does not appear
> likely anyone will be able to investigate it soon, and the nature of
> both releases is about all-new VM(s) anyway, we probably should not
> hold up the release over this.
>
> In fact, I could make another RC without the recompileAll.  Is it
> really necessary?  I don't know any better about its purpose than why
> it would be a problem.  I guess anyone could do it on their own if
> they wanted..
>

OK, I'm back now.

The problem was introduced in Compiler-eem.300, which does this:

    Use the size/emitPushNClosureTemps: api in block generation.

There are two affected methods:

    BlockNode>>sizeCodeForEvaluatedClosureValue:
    BlockNode>>emitCodeForEvaluatedClosureValue:encoder:

Reverting these two methods fixes the problem.

I don't know the background on this change but my guess would be that
it is something that works on a stack interpreter but not on a context
interpreter, so maybe the methods need to be tweaked to account for the
difference.

I would suggest rolling back these two methods until after the 4.6
release, see Compiler-dtl.303 in the inbox.

Eliot, does that sound right?

Thanks,
Dave


Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

Eliot Miranda-2
Hi David,

On Tue, Jul 7, 2015 at 4:33 PM, David T. Lewis <[hidden email]> wrote:
On Tue, Jul 07, 2015 at 02:34:48PM -0500, Chris Muller wrote:
>
> On Tue, Jul 7, 2015 at 1:31 PM, David T. Lewis <[hidden email]> wrote:
> > I am away and cannot follow up on this for a while.
> >
> > My guess would be that there is something wrong in the compiler, and that
> > it needs to be fixed (but I cannot check now to find out). I don't know if
> > this affects SqueakJS or other VMs.
> >
> > Dave
>
> Maybe the problem is in the image, the interpreter VM or the
> TwosComplement package, we don't know.  Since it does not appear
> likely anyone will be able to investigate it soon, and the nature of
> both releases is about all-new VM(s) anyway, we probably should not
> hold up the release over this.
>
> In fact, I could make another RC without the recompileAll.  Is it
> really necessary?  I don't know any better about its purpose than why
> it would be a problem.  I guess anyone could do it on their own if
> they wanted..
>

OK, I'm back now.

The problem was introduced in Compiler-eem.300, which does this:

    Use the size/emitPushNClosureTemps: api in block generation.

There are two affected methods:

    BlockNode>>sizeCodeForEvaluatedClosureValue:
    BlockNode>>emitCodeForEvaluatedClosureValue:encoder:

Reverting these two methods fixes the problem.

I don't know the background on this change but my guess would be that
it is something that works on a stack interpreter but not on a context
interpreter, so maybe the methods need to be tweaked to account for the
difference.

It should make no difference to the code produced.  It adds a new way of saying "push N nils" that allows the Sista bytecode set to use its "pushNClosureNils" bytecode to push several nils in one bytecode.  But with the standard encoder EncoderForV3PlusClosures exactly the same code as the previous version should be produced.

How do the changes in the compiler cause the crash?
 

I would suggest rolling back these two methods until after the 4.6
release, see Compiler-dtl.303 in the inbox.

Eliot, does that sound right?

No.  I don't see how the changes cause the crash.  The changes have no effect in the Encoder in effect in the release image.  I'd like to understand how the crash occurs before rolling back.  
 

Thanks,
Dave





--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

VM terminology (was: [squeak-dev] Squeak 4.6 -- 2nd release candidate)

David T. Lewis
In reply to this post by Tobias Pape
On Tue, Jul 07, 2015 at 05:31:38PM +0200, Tobias Pape wrote:

>
> On 07.07.2015, at 17:26, Chris Muller <[hidden email]> wrote:
>
> >>> Interpreter VM will not be able to run Spur images going forward.
> >>
> >> Pardon?
> >
> > Download latest Spur image and changes:
> >
> >    http://www.mirandabanda.org/files/Cog/VM/SpurImages/trunk46-spur.image
> >
> >   http://www.mirandabanda.org/files/Cog/VM/SpurImages/trunk46-spur.changes
> >
> > and latest interpreter VM.  Then try:
> >
> >   squeak trunk46-spur.image
> >
> > Results:
> >
> > This interpreter (vers. 0) cannot read image file (vers. 6521).
> > Press CR to quit...
>
>
> Well, your sentence sounded as if there's no intention of making the interpreter
> VM SPUR-aware whatsoever. Surely I got that wrong, didn't I?
>

We are probably tripping over some terminology issues here.

We used to refer to the "standard VM" as distinct from the "experimental"
Cog VMs. That terminology is no longer appropriate, because most people
now use Cog (and Spur), and IMHO the terms "standard" and "experimentalt"
are no longer helpful.

When Eliot and Andreas began the work that led to Cog (and now Spur), the
first step (see Eliot's blog) was development of the stack-oriented interpreter,
which was an improvement over the original context-based interpreter of the
standard Squeak VM. The idea was (and still is) that the standard interpreter
VMs would migrate to the stack interpreter model.

If you look at the VMMaker package (as opposed to VMMaker.oscog) you will
find additional refactoring of the interpreter and object memory classes to
support that original design intent. The VMs that we now call "interpreter
VM" are generated from that code base, currently building from the context
interpreter classes rather than the stack interpreter classes.

There is some work remaining to be done in order to be able to generate
an "interpreter VM" from the stack interpreter classes in the VMMaker
package. Once that is accomplished, the context interpreter will become
a historical artifact, and the "interpreter VM" builds will in fact deliver
the stack based interpreter VM as developed by Eliot and maintained in
the VMMaker.oscog branch.

Beyond that, my powers of prediction are less clear. There is significant
code merge work remaining to be done, but regardless of how (or when or
by whom) that gets done, there is no reason that the new Spur object model
should not be adopted, and no reason why an "interpreter VM" should not
be able to support it.

Dave
 

Reply | Threaded
Open this post in threaded view
|

Re: Squeak 4.6 -- 2nd release candidate

David T. Lewis
In reply to this post by Eliot Miranda-2
On Tue, Jul 07, 2015 at 05:20:52PM -0700, Eliot Miranda wrote:

> Hi David,
>
> On Tue, Jul 7, 2015 at 4:33 PM, David T. Lewis <[hidden email]> wrote:
> >
> > The problem was introduced in Compiler-eem.300, which does this:
> >
> >     Use the size/emitPushNClosureTemps: api in block generation.
> >
> > There are two affected methods:
> >
> >     BlockNode>>sizeCodeForEvaluatedClosureValue:
> >     BlockNode>>emitCodeForEvaluatedClosureValue:encoder:
> >
> > Reverting these two methods fixes the problem.
> >
> > I don't know the background on this change but my guess would be that
> > it is something that works on a stack interpreter but not on a context
> > interpreter, so maybe the methods need to be tweaked to account for the
> > difference.
> >
>
> It should make no difference to the code produced.  It adds a new way of
> saying "push N nils" that allows the Sista bytecode set to use its
> "pushNClosureNils" bytecode to push several nils in one bytecode.  But with
> the standard encoder EncoderForV3PlusClosures exactly the same code as the
> previous version should be produced.
>
> How do the changes in the compiler cause the crash?
>

I don't know.

I'm doing brute-force debugging, just rolling the versions back until the
problem goes away.

All I can say with confidence is that those two methods changes, followed by
a system recompile, result in an image that crashes a context interpreter VM.
Reverting these two methods and recompiling brings the image back to a sane
condition.

It might turn out to be a trivial problem, but I am suggesting that we should
temporarily revert and work it out after the 4.6 release.

Dave


12