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 <Das.Linux@gmx.de> wrote:
>
> >
> > On 06.07.2016, at 08:17, Eliot Miranda <eliot.miranda@gmail.com> wrote:
> >
> > > On Tue, Jul 5, 2016 at 10:21 PM, Tobias Pape <Das.Linux@gmx.de> wrote:
> > >
> > > On 06.07.2016, at 01:13, commits@source.squeak.org 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 > > > That would be a bummer???
> > > > 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?
> > >
> > > 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