[squeak-dev] Files-ul.154 seems dangerous, is it needed?
David T. Lewis
lewis at mail.msen.com
Tue May 31 01:38:12 UTC 2016
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
> >
> >
More information about the Squeak-dev
mailing list
|