- Pharo-dev - lists.pharo.org

Pharo 7 new file stream encoders

by Thierry Goubier

Hi all, how does one create a file stream in Pharo 7 that forces a specific line end convention ? For example, for forcing all end of lines to be Character lf. The old way, fileStream lineEndConvention: #'lf'. does not work anymore. Thanks, Thierry

March 15, 2018

Re: [Pharo-dev] Base64MimeConverter class>>mimeDecodeToBytes: change breaks image load

by Sven Van Caekenberghe

And in PNGReadWriter>>nextImage we should remove stream reset and stream binary. This probably goes for the other image readers as well. > On 15 Mar 2018, at 13:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Yeah, right, good catch. > > But what is this nonsense: > > PNGReadWriter>>on: aStream > (stream := aStream) reset. > stream binary > "Note that 'reset' makes a file be text. Must do this after." > > Of course you can only read an image from a binary stream, there should be nothing else there but > > stream := aStream > >> On 15 Mar 2018, at 13:31, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> 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 <sven(a)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 <sven(a)stfx.eu> wrote: >>>> >>>> >>>> >>>>> On 15 Mar 2018, at 12:28, Alistair Grant <akgrant0710(a)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 >>> >>> >> >

March 15, 2018

Re: [Pharo-dev] Base64MimeConverter class>>mimeDecodeToBytes: change breaks image load

by Sven Van Caekenberghe

Yeah, right, good catch. But what is this nonsense: PNGReadWriter>>on: aStream (stream := aStream) reset. stream binary "Note that 'reset' makes a file be text. Must do this after." Of course you can only read an image from a binary stream, there should be nothing else there but stream := aStream > On 15 Mar 2018, at 13:31, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > 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 <sven(a)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 <sven(a)stfx.eu> wrote: >>> >>> >>> >>>> On 15 Mar 2018, at 12:28, Alistair Grant <akgrant0710(a)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 >> >> >

March 15, 2018

Re: [Pharo-dev] Base64MimeConverter class>>mimeDecodeToBytes: change breaks image load

by Alistair Grant

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 <sven(a)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 <sven(a)stfx.eu> wrote: >> >> >> >>> On 15 Mar 2018, at 12:28, Alistair Grant <akgrant0710(a)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 > >

March 15, 2018

Re: [Pharo-dev] Base64MimeConverter class>>mimeDecodeToBytes: change breaks image load

by Sven Van Caekenberghe

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 <sven(a)stfx.eu> wrote: > > > >> On 15 Mar 2018, at 12:28, Alistair Grant <akgrant0710(a)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

March 15, 2018

Re: [Pharo-dev] Base64MimeConverter class>>mimeDecodeToBytes: change breaks image load

by Alistair Grant

Hi Sven, On 15 March 2018 at 12:47, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 15 Mar 2018, at 12:28, Alistair Grant <akgrant0710(a)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 ? Yes, but I was thinking more about whether it was intended to put this responsibility on the caller (changing behaviour). > Note that there is the newer ZnBase64Encoder that can be used as follows: > > f := (ZnBase64Encoder new decode: self imageData) readStream. That works too. Thanks, Alistair

March 15, 2018

Re: [Pharo-dev] Base64MimeConverter class>>mimeDecodeToBytes: change breaks image load

by Sven Van Caekenberghe

> On 15 Mar 2018, at 12:28, Alistair Grant <akgrant0710(a)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

March 15, 2018

Base64MimeConverter class>>mimeDecodeToBytes: change breaks image load

by Alistair Grant

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. Thanks, Alistair

March 15, 2018

Re: [Pharo-dev] [Pharo-users] Something is happening...

by Nicolas Anquetil

On 15/03/2018 10:31, Marcus Denker wrote: > [...] > What I would like to have is a way to count âcurrently running imagesâ. > But I guess adding that by default (like all mobile apps now do) would > not > be wanted.. but one could add some config option. > spotter has it and nobody complained as it is off by default (not sure how much people turned it on) nicolas -- Nicolas Anquetil RMod team -- Inria Lille

March 15, 2018

Re: [Pharo-dev] [Pharo-users] Something is happening...

by Marcus Denker

> On 14 Mar 2018, at 19:02, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > Do we have any metrics on the number of visits we get on the pharo.org > website, which parts are the most visited, etc? > Yes, we have Google Analytics installedâ¦ but I did not look at it for a long time. It is no that spectacularâ¦ 200-300 users per day. But there is not much reason to visit it often, so a large part of that are real new visitors. > The same regarding web downloads, and so on. I understand that CI can > distort download count if using only access logs, but certainly if we > count a download through the webpage as a "conversion" (and track it > somehow) we would have a better idea how big this is becoming. > The new files.pharo.org <http://files.pharo.org/> keeps logs for one dayâ¦ So for today: 17.98 GB transfer until now (not even half day), so around 25 to 30GB per day. But CI is really a lotâ¦ it is not only the CI of Pharo itself, but others, too. E.g. just the ZWEIDENKER Jenkins builds quite oftenâ¦ Tracking the real downloads would be a better way, yes. What I would like to have is a way to count âcurrently running imagesâ. But I guess adding that by default (like all mobile apps now do) would not be wanted.. but one could add some config option. I want that for the Zweidenker pharo images: right now it is easy to count by counting the processes on the virtual beta-swarm and doubling (for production). But soon production will scale up and beta down *and* there will be a alpha swarmâ¦ > But back to your point and as a bystander these days, it is very hard > to be aware of everything that's going on in the Pharo world, and not > because of the associated noise, because there is actually a lot of > things going on. :) > It is interesting! Marcus

March 15, 2018