- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #702: Remove extra buffered read stream

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #702 was: SUCCESS. The Pull Request #1118 was integrated: "Remove extra buffered read stream" Pull request url: https://github.com/pharo-project/pharo/pull/1118 Issue Url: https://pharo.fogbugz.com/f/cases/21604 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 17, 2018

[Pharo 7.0-dev] Build #701: 21487 Lint clean #testAtWrapPut

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #701 was: SUCCESS. The Pull Request #1125 was integrated: "21487 Lint clean #testAtWrapPut" Pull request url: https://github.com/pharo-project/pharo/pull/1125 Issue Url: https://pharo.fogbugz.com/f/cases/21487 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 16, 2018

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

by Stephane Ducasse

Yes this is that you cannot have a png embedded in stream. Just at the beginning. What funny concept. On Thu, Mar 15, 2018 at 2:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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 16, 2018

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

by Stephane Ducasse

Hi sven can you open a bug entry? Sven I have a APi question why we could not have decodeBase64: in something else than ZnUtils. I tend to stay away from class having Util in their names :) I still have the scars on my body of my battle against Utilities. Stef On Thu, Mar 15, 2018 at 1:08 PM, 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 16, 2018

Re: [Pharo-dev] Executive Summary of the recent FileStream Changes

by Stephane Ducasse

Sean you can really help on this one. Stef On Fri, Mar 16, 2018 at 5:47 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Stephane Ducasse-3 wrote >> we are planning to migrate a selection of the old >> deprecated methods (of Pharo 30, 40, 50, 60) into a MigrationPackage >> with deprecatedWithTransform rule >> to help the migration of the old code to new one. > > Cool!!! > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

March 16, 2018

Re: [Pharo-dev] FileHandle creates a buffered stream on a buffered stream

by Stephane Ducasse

Guille is a machine :) I'm amazed and love to see all this energy pushed into Pharo. Tx guille. On Fri, Mar 16, 2018 at 1:37 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 16 Mar 2018, at 11:46, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> Nice catch. The write stream is well defined in comparison. >> >> https://pharo.fogbugz.com/f/cases/21604/FileHandle-creates-a-buffered-strea… >> >> https://github.com/pharo-project/pharo/pull/1118 >> >> Can somebody review please? > > OK by me > >> Tx, >> Guille >> >> On Thu, Mar 15, 2018 at 4:00 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Hi (Guille), >> >> FileHandle creates a buffered stream on a buffered stream when sent #readStream. >> >> Note how #binaryReadStream adds a bufferer stream as well as #readStreamEncoded: >> >> Probably the latter should not do this >> >> Sven >> >> >> >> -- >> >> Guille Polito >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> CRIStAL - UMR 9189 >> French National Center for Scientific Research - http://www.cnrs.fr >> >> Web: http://guillep.github.io >> Phone: +33 06 52 70 66 13 > >

March 16, 2018

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

by Eliot Miranda

Hi Nicolas, Hi Marcus, > On Mar 15, 2018, at 4:05 AM, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: > > > >> 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) > <Screenshot from 2018-03-15 12-02-08.png> If the spotter packet was also a "are there updates (image and/or vm) available?" request then - it could be on by default - it would give as well as receive :-) Of course it should work in the background and not slow down image launch, and it should fail silently if there is no network connection. > nicolas > -- > Nicolas Anquetil > RMod team -- Inria Lille

March 16, 2018

[Pharo 7.0-dev] Build #700: 21600 Use "instance creation" protocol in Monticello

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #700 was: SUCCESS. The Pull Request #1114 was integrated: "21600 Use "instance creation" protocol in Monticello" Pull request url: https://github.com/pharo-project/pharo/pull/1114 Issue Url: https://pharo.fogbugz.com/f/cases/21600 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 16, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Thierry Goubier

Le 16/03/2018 Ã 18:37, Denis Kudriashov a Ã©critÂ : > > 2018-03-05 16:17 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>>: > > 2018-03-05 16:13 GMT+01:00 Cyril Ferlicot <cyril.ferlicot(a)gmail.com > <mailto:cyril.ferlicot@gmail.com>>: > > On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov > <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > Hi Pablo. > > > > Dev branch approach not really works. Because any merge into master will > > break master baseline. (notice that baseline is in same repo). > > And managing merges by hand all the time is not a solution. > > > > > Hi! > If you don't want to manage the merges by hand you can maybe > have two bsaelines? > BaselineOfCalypso and BaselineOfCalypsoDev? > > > At the end I found that this approach with two baselines is not really > working. > So I will adopt my projects to the following pattern: > > Each release will point to static version of dependencies. They all in > master branch. > Floating version like 0.5.x will be maintained in separate branch > instead of floating tag. In this branch baseline will reference > dependencies using similar "floating" branch in their repositories. > > So to get all minor fixes from all dependencies the code should be > loaded from such floating branch (0.5.x). The main project can be locked > to fix current version (only dependencies will be updated). > And all released versions (0.5.3 tag) will be completely reproducible. That sounds like a nice scheme. Thierry > > It should work. But is it right way that everybody should follow? > > With configurations it was easy to do in single class. > > > -- > Cyril Ferlicot > https://ferlicot.fr > > >

March 16, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Denis Kudriashov

2018-03-05 16:17 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 2018-03-05 16:13 GMT+01:00 Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: > >> On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> > Hi Pablo. >> > >> > Dev branch approach not really works. Because any merge into master will >> > break master baseline. (notice that baseline is in same repo). >> > And managing merges by hand all the time is not a solution. >> > >> > >> Hi! >> If you don't want to manage the merges by hand you can maybe have two >> bsaelines? >> BaselineOfCalypso and BaselineOfCalypsoDev? >> > At the end I found that this approach with two baselines is not really working. So I will adopt my projects to the following pattern: Each release will point to static version of dependencies. They all in master branch. Floating version like 0.5.x will be maintained in separate branch instead of floating tag. In this branch baseline will reference dependencies using similar "floating" branch in their repositories. So to get all minor fixes from all dependencies the code should be loaded from such floating branch (0.5.x). The main project can be locked to fix current version (only dependencies will be updated). And all released versions (0.5.3 tag) will be completely reproducible. > It should work. But is it right way that everybody should follow? > > With configurations it was easy to do in single class. > > >> >> -- >> Cyril Ferlicot >> https://ferlicot.fr >> >> >

March 16, 2018