[squeak-dev] Files-ul.154 seems dangerous, is it needed?

David T. Lewis lewis at mail.msen.com
Fri Jun 3 02:21:28 UTC 2016


Hi Levente,

On Wed, Jun 01, 2016 at 10:40:09AM +0200, Levente Uzonyi wrote:
> Hi Dave
> 
> On Tue, 31 May 2016, David T. Lewis wrote:
> 
> >That said, in the case of setting a stream to #binary or #ascii, the
> >#adoptInstance: approach does seem fragile compared to #asByteArray.
> >If Behavior>>adoptInstance: fails, the fallback code attempts to use
> >Object>>primitiveChangeClassTo: which also fails, this time with no 
> >fallback
> >path. Thus if the primitives for changing the class of an object fail,
> >there is no fallback and it may no longer be possible to write a new binary
> >file (such as new image and changes files).
> 
> You would still get a debugger in such case where you would have a chance 
> to fix/work around the problem, wouldn't you?

Theoretically yes, but in practice I have abandoned several images after
trying to play around with it. I think what probably is happening is the
changes file gets damaged as a result of not being able to reopen it in
binary mode. I'm not certain that this is the cause, but I seem to end
up with methods that have no source, so that would be the likely reason.

Cog seems to recover more gracefully than interpreter VM in this case,
so it may be that there are contributing issues in the interpreter VM.
I am not really sure, but it does seem like having a #binary method that
could fail without working fallback code is rather dangerous.

> 
> >
> >Another way to look at it - if the optimization is worthwhile, maybe it
> >belongs in the Collections package, which already needs to be different
> >for Spur versus V3.
> >
> >For Spur, shouldn't it just be this:
> >
> >ByteString>>asByteArray
> >    ByteArray adoptInstance: self
> >
> >I did not really test this, but it should give us the same performance
> >optimization in a more general way.
> 
> This would significantly change the behavior, because currently you know 
> that a copy will be returned.
> We might as well use a different selector (#toByteArray or #beByteArray), 
> but I don't know if that would help V3 images.
> 

D'oh! Yes of course you are right.

Dave



More information about the Squeak-dev mailing list