The Trunk: System-eem.835.mcz

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

The Trunk: System-eem.835.mcz

commits-2
Eliot Miranda uploaded a new version of System to project The Trunk:
http://source.squeak.org/trunk/System-eem.835.mcz

==================== Summary ====================

Name: System-eem.835
Author: eem
Time: 5 July 2016, 6:13:25.980763 pm
UUID: 44354df1-cecb-414c-a705-daa84b7388dd
Ancestors: System-eem.834

Fix reading methods from DataStreams on Spur.  Old code used pre-Spur numLits header format, and was not 64-bit aware.

=============== Diff against System-eem.834 ===============

Item was changed:
  ----- Method: DataStream>>readMethod (in category 'write and read') -----
  readMethod
  "PRIVATE -- Read the contents of an arbitrary instance.
  ASSUMES: readDataFrom:size: sends me beginReference: after it
    instantiates the new object but before reading nested objects.
  NOTE: We must restore the current reference position after
    recursive calls to next.
  Let the instance, not the class read the data.  "
  | instSize refPosn newClass className xxHeader nLits byteCodeSizePlusTrailer newMethod lits |
 
  instSize := (byteStream nextNumber: 4) - 1.
  refPosn := self getCurrentReference.
  className := self next.
  newClass := Smalltalk at: className asSymbol.
 
  xxHeader := self next.
  "nArgs := (xxHeader >> 24) bitAnd: 16rF."
  "nTemps := (xxHeader >> 18) bitAnd: 16r3F."
  "largeBit := (xxHeader >> 17) bitAnd: 1."
+ nLits := xxHeader bitAnd: 16r7FFF.
+ byteCodeSizePlusTrailer := instSize - (newClass instSize "0") - (nLits + 1 * Smalltalk wordSize).
- nLits := (xxHeader >> 9) bitAnd: 16rFF.
- "primBits := ((xxHeader >> 19) bitAnd: 16r600) + (xxHeader bitAnd: 16r1FF)."
- byteCodeSizePlusTrailer := instSize - (newClass instSize "0") - (nLits + 1 * 4).
 
  newMethod := newClass
+ newMethod: byteCodeSizePlusTrailer
+ header: xxHeader.
- newMethod: byteCodeSizePlusTrailer
- header: xxHeader.
 
  self setCurrentReference: refPosn.  "before readDataFrom:size:"
  self beginReference: newMethod.
  lits := newMethod numLiterals + 1. "counting header"
  2 to: lits do:
  [:ii | newMethod objectAt: ii put: self next].
+ lits*Smalltalk wordSize+1 to: newMethod basicSize do:
- lits*4+1 to: newMethod basicSize do:
  [:ii | newMethod basicAt: ii put: byteStream next].
  "Get raw bytes directly from the file"
  self setCurrentReference: refPosn.  "before returning to next"
+ ^newMethod!
- ^ newMethod!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: System-eem.835.mcz

Tobias Pape

On 06.07.2016, at 01:13, [hidden email] wrote:

> Eliot Miranda uploaded a new version of System to project The Trunk:
> http://source.squeak.org/trunk/System-eem.835.mcz
>
> ==================== Summary ====================
>
> Name: System-eem.835
> Author: eem
> Time: 5 July 2016, 6:13:25.980763 pm
> UUID: 44354df1-cecb-414c-a705-daa84b7388dd
> Ancestors: System-eem.834
>
> Fix reading methods from DataStreams on Spur.  Old code used pre-Spur numLits header format, and was not 64-bit aware.
>

Does that mean that pre-Spur methods on datastreams cannot be read in Spur images?
That would be a bummer…

Best regards
        -Tobias

> =============== Diff against System-eem.834 ===============
>
> Item was changed:




Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: System-eem.835.mcz

Eliot Miranda-2


On Tue, Jul 5, 2016 at 10:21 PM, Tobias Pape <[hidden email]> wrote:

On 06.07.2016, at 01:13, [hidden email] wrote:

> Eliot Miranda uploaded a new version of System to project The Trunk:
> http://source.squeak.org/trunk/System-eem.835.mcz
>
> ==================== Summary ====================
>
> Name: System-eem.835
> Author: eem
> Time: 5 July 2016, 6:13:25.980763 pm
> UUID: 44354df1-cecb-414c-a705-daa84b7388dd
> Ancestors: System-eem.834
>
> Fix reading methods from DataStreams on Spur.  Old code used pre-Spur numLits header format, and was not 64-bit aware.
>

Does that mean that pre-Spur methods on datastreams cannot be read in Spur images?
That would be a bummer…

It needs some kind of version stamp on the stream.  Point me to some such and we can switch hit.
 

Best regards
        -Tobias

> =============== Diff against System-eem.834 ===============
>
> Item was changed:







--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: System-eem.835.mcz

Tobias Pape

On 06.07.2016, at 08:17, Eliot Miranda <[hidden email]> wrote:

> On Tue, Jul 5, 2016 at 10:21 PM, Tobias Pape <[hidden email]> wrote:
>
> On 06.07.2016, at 01:13, [hidden email] wrote:
>
> > Eliot Miranda uploaded a new version of System to project The Trunk:
> > http://source.squeak.org/trunk/System-eem.835.mcz
> >
> > ==================== Summary ====================
> >
> > Name: System-eem.835
> > Author: eem
> > Time: 5 July 2016, 6:13:25.980763 pm
> > UUID: 44354df1-cecb-414c-a705-daa84b7388dd
> > Ancestors: System-eem.834
> >
> > Fix reading methods from DataStreams on Spur.  Old code used pre-Spur numLits header format, and was not 64-bit aware.
> >
>
> Does that mean that pre-Spur methods on datastreams cannot be read in Spur images?
> That would be a bummer…
>
> It needs some kind of version stamp on the stream.  Point me to some such and we can switch hit.

There is none.
I would say, we store the data in the format DataStream already know (which happens to be
the Pre-Spur version) and adapt on read. That would ensure backward- and forward-compatibility:

- We could still read CMs serialized in pre-spur.
- We could also read Spur-CMs in pre-spur images.

Ok. -- break --
I just realized that what you changed was the read part. so no
problem here. We could change the part to do things differently
when running on spur or non-spur.

Best regards
        -Tobias


>  
>
> Best regards
>         -Tobias
>
> > =============== Diff against System-eem.834 ===============
> >
> > Item was changed:




Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: System-eem.835.mcz

Eliot Miranda-2
Hi Tobias,

On Wed, Jul 6, 2016 at 12:23 AM, Tobias Pape <[hidden email]> wrote:

On 06.07.2016, at 08:17, Eliot Miranda <[hidden email]> wrote:

> On Tue, Jul 5, 2016 at 10:21 PM, Tobias Pape <[hidden email]> wrote:
>
> On 06.07.2016, at 01:13, [hidden email] wrote:
>
> > Eliot Miranda uploaded a new version of System to project The Trunk:
> > http://source.squeak.org/trunk/System-eem.835.mcz
> >
> > ==================== Summary ====================
> >
> > Name: System-eem.835
> > Author: eem
> > Time: 5 July 2016, 6:13:25.980763 pm
> > UUID: 44354df1-cecb-414c-a705-daa84b7388dd
> > Ancestors: System-eem.834
> >
> > Fix reading methods from DataStreams on Spur.  Old code used pre-Spur numLits header format, and was not 64-bit aware.
> >
>
> Does that mean that pre-Spur methods on datastreams cannot be read in Spur images?
> That would be a bummer…
>
> It needs some kind of version stamp on the stream.  Point me to some such and we can switch hit.

There is none.
I would say, we store the data in the format DataStream already know (which happens to be
the Pre-Spur version) and adapt on read. That would ensure backward- and forward-compatibility:

- We could still read CMs serialized in pre-spur.
- We could also read Spur-CMs in pre-spur images.

Ok. -- break --
I just realized that what you changed was the read part. so no
problem here. We could change the part to do things differently
when running on spur or non-spur.

The thing is that the two header formats are incompatible.  The old one allows up to 2^9-1 literals, the new one up to 2^15-1.  So staying with the old format limits us.  We need some kind of version stamp.  Right now DataStream and ImageSegment are extremely version-dependent and hence restrictive formats.  It would be good for someone to revisit them and try and add some kind of versioning information, preferably supporting backward compatibility.
 

Best regards
        -Tobias


>
>
> Best regards
>         -Tobias
>
> > =============== Diff against System-eem.834 ===============
> >
> > Item was changed:







--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: System-eem.835.mcz

David T. Lewis
On Fri, Jul 08, 2016 at 03:35:35PM -0700, Eliot Miranda wrote:

> Hi Tobias,
>
> On Wed, Jul 6, 2016 at 12:23 AM, Tobias Pape <[hidden email]> wrote:
>
> >
> > On 06.07.2016, at 08:17, Eliot Miranda <[hidden email]> wrote:
> >
> > > On Tue, Jul 5, 2016 at 10:21 PM, Tobias Pape <[hidden email]> wrote:
> > >
> > > On 06.07.2016, at 01:13, [hidden email] wrote:
> > >
> > > > Eliot Miranda uploaded a new version of System to project The Trunk:
> > > > http://source.squeak.org/trunk/System-eem.835.mcz
> > > >
> > > > ==================== Summary ====================
> > > >
> > > > Name: System-eem.835
> > > > Author: eem
> > > > Time: 5 July 2016, 6:13:25.980763 pm
> > > > UUID: 44354df1-cecb-414c-a705-daa84b7388dd
> > > > Ancestors: System-eem.834
> > > >
> > > > Fix reading methods from DataStreams on Spur.  Old code used pre-Spur
> > numLits header format, and was not 64-bit aware.
> > > >
> > >
> > > Does that mean that pre-Spur methods on datastreams cannot be read in
> > Spur images?
> > > That would be a bummer???
> > >
> > > It needs some kind of version stamp on the stream.  Point me to some
> > such and we can switch hit.
> >
> > There is none.
> > I would say, we store the data in the format DataStream already know
> > (which happens to be
> > the Pre-Spur version) and adapt on read. That would ensure backward- and
> > forward-compatibility:
> >
> > - We could still read CMs serialized in pre-spur.
> > - We could also read Spur-CMs in pre-spur images.
> >
> > Ok. -- break --
> > I just realized that what you changed was the read part. so no
> > problem here. We could change the part to do things differently
> > when running on spur or non-spur.
> >
>
> The thing is that the two header formats are incompatible.  The old one
> allows up to 2^9-1 literals, the new one up to 2^15-1.  So staying with the
> old format limits us.  We need some kind of version stamp.  Right now
> DataStream and ImageSegment are extremely version-dependent and hence
> restrictive formats.  It would be good for someone to revisit them and try
> and add some kind of versioning information, preferably supporting backward
> compatibility.
>

While a bit ad-hoc, but we do have an image format number that is used
for a similar purpose in the saved image files. Would that provide enough
information to serve as a version stamp?

The current known formats are maintained in package ImageFormat in the
http://source.squeak.org/VMMaker repository. It is small and independent
of VMMaker, so we could consider moving it into the image if it is of
more general utility.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: System-eem.835.mcz

Eliot Miranda-2
Hi David,

On Fri, Jul 8, 2016 at 4:11 PM, David T. Lewis <[hidden email]> wrote:
On Fri, Jul 08, 2016 at 03:35:35PM -0700, Eliot Miranda wrote:
> Hi Tobias,
>
> On Wed, Jul 6, 2016 at 12:23 AM, Tobias Pape <[hidden email]> wrote:
>
> >
> > On 06.07.2016, at 08:17, Eliot Miranda <[hidden email]> wrote:
> >
> > > On Tue, Jul 5, 2016 at 10:21 PM, Tobias Pape <[hidden email]> wrote:
> > >
> > > On 06.07.2016, at 01:13, [hidden email] wrote:
> > >
> > > > Eliot Miranda uploaded a new version of System to project The Trunk:
> > > > http://source.squeak.org/trunk/System-eem.835.mcz
> > > >
> > > > ==================== Summary ====================
> > > >
> > > > Name: System-eem.835
> > > > Author: eem
> > > > Time: 5 July 2016, 6:13:25.980763 pm
> > > > UUID: 44354df1-cecb-414c-a705-daa84b7388dd
> > > > Ancestors: System-eem.834
> > > >
> > > > Fix reading methods from DataStreams on Spur.  Old code used pre-Spur
> > numLits header format, and was not 64-bit aware.
> > > >
> > >
> > > Does that mean that pre-Spur methods on datastreams cannot be read in
> > Spur images?
> > > That would be a bummer???
> > >
> > > It needs some kind of version stamp on the stream.  Point me to some
> > such and we can switch hit.
> >
> > There is none.
> > I would say, we store the data in the format DataStream already know
> > (which happens to be
> > the Pre-Spur version) and adapt on read. That would ensure backward- and
> > forward-compatibility:
> >
> > - We could still read CMs serialized in pre-spur.
> > - We could also read Spur-CMs in pre-spur images.
> >
> > Ok. -- break --
> > I just realized that what you changed was the read part. so no
> > problem here. We could change the part to do things differently
> > when running on spur or non-spur.
> >
>
> The thing is that the two header formats are incompatible.  The old one
> allows up to 2^9-1 literals, the new one up to 2^15-1.  So staying with the
> old format limits us.  We need some kind of version stamp.  Right now
> DataStream and ImageSegment are extremely version-dependent and hence
> restrictive formats.  It would be good for someone to revisit them and try
> and add some kind of versioning information, preferably supporting backward
> compatibility.
>

While a bit ad-hoc, but we do have an image format number that is used
for a similar purpose in the saved image files. Would that provide enough
information to serve as a version stamp?

Works for me.

The current known formats are maintained in package ImageFormat in the
http://source.squeak.org/VMMaker repository. It is small and independent
of VMMaker, so we could consider moving it into the image if it is of
more general utility.

+1

Dave

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