On Tue, May 31, 2016 at 12:35:12AM +0200, Levente Uzonyi wrote:
> Hi Dave,
> 
> It's an optimization, so it's not mandatory. Of course it's nice to have, 
> and #adoptInstance: should work (as it does in Spur).
> So the question is: why doesn't it work?
> 
> The answer is that in V3 ByteString is compact, but ByteArray is not. 
> Since the compact classes array has plenty of space, I suggest ByteArray 
> should be compact as well.
> If you evaluate [ByteArray becomeCompact] in a V3 image, then you'll find 
> that the change will work in those images, too.

Brilliant! Yes, [ByteArray becomeCompact] makes it work.

It still fails on interpreter VM (VM crash), but I think there is a bug
in the interpreter primitiveAdoptInstance so that is not directly related,
so that would be a separate issue.

> 
> I've mentioned it earlier that Spur made some optimizations possible, that 
> are not V3 compatible. Another widely used example is using #== for 
> Character comparison. These will of course not work in V3 images, and 
> detecting the problems due to these changes is extremely hard.
> 
> Levente

Not really so extremely hard, I noticed it because of failures on
http://build.squeak.org/job/FollowTrunkOnOldV3Image/ 

Overall, I am quite happy to see that the Spur/V3 differences remain
isolated to 4 packages for trunk. The one glitch that I noticed here
affects the Files package, but this is the first such case that I have
seen since the Spur conversion. So this seems really good to me.

Dave


> 
> On Mon, 30 May 2016, David T. Lewis wrote:
> 
> >We did this change recently:
> >
> > Name: Files-ul.154
> > Time: 15 May 2016, 11:17:08.015805 pm
> >
> > - use #adoptInstance: to convert between binary and ascii mode instead of 
> > creating new collections
> >
> >This assumes that we can convert a ByteString to a ByteArray using
> >Behavior>>adoptInstance. If the conversion does not work, as it the case
> >with a V3 image and Cog or interpreter VM, then we end up with a corrupt
> >image after trying to save the image as new version (and maybe other cases
> >as well).
> >
> >It does not seem that #ascii and #binary are called frequently, even when
> >doing Monticello updates, so I suspect that the optimization is not very
> >important.
> >
> >Do we need the #ascii and #binary optimizations in Files-ul.154?
> >
> >Dave
> >
> >