Also:

'apicture.png' asFileReference inspect.

Will raise a "image format not recognised" because:

- AbstractFileReference>>binaryReadStreamDo: ultimately uses a
ZnBufferedReadStream
- ImageReadWriter>>on: sends #reset to the stream

and ZnBufferedReadStream doesn't implement #reset.

My guess is that ZnBufferedReadStream should implement #reset (it has
#position:).  But I'm not familiar with the current thinking on stream
rationalisation.

I'll raise some fogbugz issues a bit later.

Image downloaded today:

Pharo 7.0
Build information:
Pharo-7.0+alpha.build.696.sha.a26248bb90ee8dfba131f2f4d71ba2bbbad5d00d
(64 Bit)



Thanks,
Alistair


On 15 March 2018 at 13:08, Sven Van Caekenberghe <s...@stfx.eu> wrote:
> BTW, for the record, we should deprecate Base64MimeConverter, and 
> remove/change the following convenience methods:
>
> Remove
>
> String>>#base64Encoded.
>
> Change
>
> ByteArray>>#base64Encoded
>         "Encode the receiver using Base64, see ZnBase64Encoder"
>
>         ^ ZnBase64Encoder new encode: self
>
> String>>#base64Decoded
>         "Decode the receiver using Base64, see ZnBase64Encoder"
>
>         ^ ZnBase64Encoder new decode: self
>
> The thing is, Base64 is defined as going from bytes -> characters and vice 
> versa. Not as going from characters -> characters. For that you need to use 
> an explicit character encoder as in ZnUtils class>>#decodeBase64: and 
> ZnUtils>>#encodeBase64:
>
> So yes, this would be a breaking change, but an easy one to follow since 
> Base64 is really very simple as a concept.
>
>> On 15 Mar 2018, at 12:47, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>>
>>
>>
>>> On 15 Mar 2018, at 12:28, Alistair Grant <akgrant0...@gmail.com> wrote:
>>>
>>> Hi Guille & Pavel,
>>>
>>> On 6 Feb Guille changed Base64MimeConverter class>>mimeDecodeToBytes:
>>> so that it doesn't reset the dataStream position back to the start of
>>> the stream.  This breaks Pavel's PlayingCard, part of FreeCell (you
>>> can see that I only load important stuff :-)).
>>>
>>> PlayingCard class>>initialize
>>> "PlayingCard initialize"
>>> | forms f |
>>> "Read the stored forms from mime-encoded data in imageData."
>>> f := Base64MimeConverter mimeDecodeToBytes: (ReadStream on: self imageData).
>>> forms := OrderedCollection new.
>>> f next = 2 ifFalse: [self error: 'corrupted imageData'].
>>> [f atEnd] whileFalse: [forms add: (Form new readFrom: f)].
>>> ...
>>>
>>>
>>> Previously, f would be at the start of the stream (which makes sense
>>> given this usage), but now it is at the end of the stream, so returns
>>> nil and "f next = 2" fails.
>>>
>>> Guille, can you explain the change.  The commit log just says "make tests 
>>> run".
>>>
>>> Note that a lot of users of this won't fail as they just call
>>> #contents of the stream after #mimeDecodeToBytes:, which works
>>> regardless of the current position.
>>
>> So doing
>>
>>  f reset
>>
>> at the caller site would fix it then ?
>>
>> Note that there is the newer ZnBase64Encoder that can be used as follows:
>>
>>  f := (ZnBase64Encoder new decode: self imageData) readStream.
>>
>> Sven
>
>

Reply via email to