March 2018 - Pharo-dev - lists.pharo.org

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

by Stephan Eggermont

Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 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. > So your goal for released versions is to be only loadable on a specific pharo build? Stephan

March 17, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by Alexandre Bergel

Yesterday we also experienced many problem when using Launcher on OSX :-( Is the Launcher still maintained? Alexandre > On Mar 17, 2018, at 8:57 AM, kmo <voxkmp(a)gmail.com> wrote: > > I tried the default download of Pharo Launcher on my Windows 7 (32 bit) PC at > work. It installs. Runs fine - creates images and vms but when you try to > run them nothing happens. It fails to start the selected image. It just > fails to run the vm at all as far as I can see. > > I tried it on my Windows 10 (32 bit) laptop and got exactly the same result. > > This is not important for me as I use pharo on Linux - but I thought I'd > point it out. If having the launcher as the default download causes more > problems than the traditional vm and image download then perhaps it should > be reconsidered. A pity since I love the launcher. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

March 17, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by kmo

I tried the default download of Pharo Launcher on my Windows 7 (32 bit) PC at work. It installs. Runs fine - creates images and vms but when you try to run them nothing happens. It fails to start the selected image. It just fails to run the vm at all as far as I can see. I tried it on my Windows 10 (32 bit) laptop and got exactly the same result. This is not important for me as I use pharo on Linux - but I thought I'd point it out. If having the launcher as the default download causes more problems than the traditional vm and image download then perhaps it should be reconsidered. A pity since I love the launcher. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 17, 2018

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

by monty

The code is in XMLParser: see XMLEncodingDetector. I can port it, if you think the algorithm is appropriate. The YAML algorithm is actually a less restrictive version of this XML one: https://www.w3.org/TR/REC-xml/#sec-guessing The XML one is "Non-Normative" (ie optional), so I chose to implement the more general YAML algorithm instead. > Sent: Friday, March 16, 2018 at 6:44 AM > From: "Sven Van Caekenberghe" <sven(a)stfx.eu> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Executive Summary of the recent FileStream Changes > > > > > On 16 Mar 2018, at 07:05, monty <monty2(a)programmer.net> wrote: > > > >> Sent: Thursday, March 15, 2018 at 4:01 PM > >> From: "Sven Van Caekenberghe" <sven(a)stfx.eu> > >> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > >> Subject: [Pharo-dev] Executive Summary of the recent FileStream Changes > >> > >> Executive Summary of the recent FileStream Changes > >> > >> In Pharo 7 Guille Polito recently committed a heroic set of changes that we were planning to do for a long time but were afraid to take on. > >> > >> The idea is to replace a couple of fat, overly complex, multi-functional, do-all classes with a set of simpler single purpose classes that can be combined as needed. > >> > >> The classes that we want to get rid of can be found in the package DeprecatedFileSystem, in particular FileStream, StandardFileStream, MultiByteFileStream, MultiByteBinaryOrTextStream and RWBinaryOrTextStream. > > > > StandardFileStream, at least, should remain for backwards compatibility and cross-platform compatibility with Squeak. It's a no-frills, non-decoding, non-LE normalizing stream that is heavily depended on. > > Hmm, maybe. > > The standard (no pun intended) interface to the file system in Pharo has been FileSystem (FileReference) for quite a while. Many packages dealing with either different Pharo versions or different Smalltalk implementations have constructed their own portability facade (heck, I even did it in ZnFileSystemUtils myself). > > Note however that some aspects (API, behaviour) about the streams themselves changed as well (no longer being bivalent, separating reading/writing, smaller/simpler API, sometimes no positioning). > > >> The replacements are can be found in packages Files and Zinc-Character-Encoding-Core. > >> > >> Encoding and decoding characters to and from bytes is done using classes that you wrap around a more primitive binary stream. The same goes for buffering or translating line endings. > >> > >> For example, > >> > >> '/Users/sven/Desktop/foo.txt' asFileReference binaryReadStream. > >> > >> gives you a ZnBufferedWriteStream wrapping a BinaryWriteStream. > >> > >> While, > >> > >> '/Users/sven/Desktop/foo.txt' asFileReference readStream. > > > > What do you think about this algorithm for encoding detection: http://www.yaml.org/spec/1.2/spec.html#id2771184 > > > > I have an implementation (with tests), if you're interested. (I was waiting to propose it until the FileSystem API switched over to using Zn streams and encoders. The TextConverter API doesn't support UTF-32.) > > I did a primitive one in ZnCharacterEncoding class>>#detectEncoding: but I am not happy with it. I will read your reference and I am certainly interested in seeing your code ! > > >> gives a ZnCharacterReadStream wrapping a ZnBufferedWriteStream wrapping a BinaryWriteStream. > >> > >> To translate line endings, we would wrap a ZnCharacterWriteStream using a ZnCrPortableWriteStream. > >> > >> There are a couple of more specialised streams to cover special cases (like read and writing at the same time). > >> > >> SocketStream remains another fat, overly complex, multi-functional, do-all class, for which usable replacements exist in the form of ZdcSocketStream and ZdcSecureSocketStream, which are simpler, cleaner and binary only. > >> > >> Of course, switching is more than replacing one class with a 100% compatible alternative, that would give us the same complex result. The challenge is to use a simpler API as well, to rethink how the streams are used. You know, KISS. > >> > >> Of course, we are far from done and need more testing, debugging and help from as many people as possible. > >> > >> Sven > >> > >> > >> -- > >> Sven Van Caekenberghe > >> Proudly supporting Pharo > >> http://pharo.org > >> http://association.pharo.org > >> http://consortium.pharo.org > > >

March 17, 2018

[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