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

Re: [Pharo-dev] Fix Base64 madness for good

by Guillermo Polito

YESS! On Thu, May 10, 2018 at 10:33 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > Am 10.05.2018 um 21:42 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > Hi, > > > > I propose the following: > > > > https://pharo.manuscript.com/f/cases/21870/Fix-Base64-madness-for-good > > https://github.com/pharo-project/pharo/pull/1331 > > > > This is a much needed cleanup, IMHO. It is a breaking change however, > since it changes the signature (return type) of an existing method. > > > > #base64Decoded used to wrongly return a String, while that should be a > ByteArray since Base64 encoding is a way to encode bytes as ASCII text, > hence decoding it should give you back the original bytes. > > > Please do. It is obviously the right move. The times where strings > contained bytes and it makes sense is over for a long time. > > Norbert > > -- 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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

May 10, 2018

Re: [Pharo-dev] Fix Base64 madness for good

by Norbert Hartl

> Am 10.05.2018 um 21:42 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > Hi, > > I propose the following: > > https://pharo.manuscript.com/f/cases/21870/Fix-Base64-madness-for-good > https://github.com/pharo-project/pharo/pull/1331 > > This is a much needed cleanup, IMHO. It is a breaking change however, since it changes the signature (return type) of an existing method. > > #base64Decoded used to wrongly return a String, while that should be a ByteArray since Base64 encoding is a way to encode bytes as ASCII text, hence decoding it should give you back the original bytes. > Please do. It is obviously the right move. The times where strings contained bytes and it makes sense is over for a long time. Norbert

May 10, 2018

Re: [Pharo-dev] Fix Base64 madness for good

by Esteban A. Maringolo

10/05/2018 16:42, Sven Van Caekenberghe wrote: > Hi, > > I propose the following: > > https://pharo.manuscript.com/f/cases/21870/Fix-Base64-madness-for-good > https://github.com/pharo-project/pharo/pull/1331 > > This is a much needed cleanup, IMHO. It is a breaking change however, since it changes the signature (return type) of an existing method. > > #base64Decoded used to wrongly return a String, while that should be a ByteArray since Base64 encoding is a way to encode bytes as ASCII text, hence decoding it should give you back the original bytes. Those who were using these methods expecting a string can send #asString to the returned bytarray. Of course that would be wrong, but it would be "as wrong as before", and hence, compatible. So please go ahead and change it. Also, having a "proper" implementation in a live environment serves a teaching vehicle for those learning how stuff works. Regards, -- Esteban A. Maringolo

May 10, 2018

File, FileHandle and FileReference

by Alistair Grant

In a separate email I suggested deprecating FileReference>>openWritable: (I'm still planning to submit a PR), but on further inspection... Does anyone know the history and plans for File and FileHandle? The comments for FileHandle to me suggest it is a layer between a stream and the primitives (FilePlugin). But as far as I can tell, it is never used. The stream creation methods in FileReference (readStream, writeStream, binaryReadStream, binaryWriteStream) use FileHandle during the stream creation, but the end result doesn't actually include a FileHandle. The main method called (in the case of the write variants) is: -- FileHandle>>binaryWriteStream ^ (File named: reference fullName) writeStream -- which obviously doesn't actually need FileHandle at all. Streams have a handle, but it is a ByteArray, which is the associated SQFile structure used by the VM. Presumably the intention was that the streams would hold on to a FileHandle, which would keep the ByteArray. This makes sense since it gives us an object that can take responsibility for some operations (as opposed to using a ByteArray as the handle). On the other side, the class comment for File says: -- I represent a sequential binary File. I provide the minimum operations to: - move the cursor fo the file - reading - writing ... -- And then goes on to mention several methods that aren't actually implemented, e.g. seekAbsolute:, seekRelative:, nextPutAll:, next:, etc. It ends up just being a set of utility methods to facilitate the creation of streams. It would be great if someone is able to fill in the gaps. If not, I can think of two paths we can take (apart from leaving things as they are, which seems a bit messy): 1. Remove (deprecate) both File and FileHandle and move the responsibility of creating the BinaryFileStream to the FileSystemStore. 2. Make FileHandle really responsible for representing an open file and modify streams, etc., to use FileHandle. I prefer the second approach as it provides more granular responsibility and a natural place to put functionality that is not directly stream related (as an example, I'm planning to extend the file attributes functionality so we can stat() an open file to find out the mode, etc.). But I'd want to think about the performance implications of adding a layer between streams and FilePluginPrims. What am I missing? Cheers, Alistair

May 10, 2018

Re: [Pharo-dev] [ Umbrella Issue ] Cleanup remaining DeprecatedFileSystem users

by Alistair Grant

Hi Sven, On 9 May 2018 at 16:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > ... > > Of course we should keep the good stuff and help in maintaining OSProcess. > That will probably mean that OSProcess will need dialect specific sub packages for some of its implementation. > > And Alistair, you did a lot of good work in this area already, we/I need you to help along. Thanks very much for your kind words (again). Hopefully I can continue to contribute and help improve Pharo, including all the great work you've done. Thanks again, Alistair

May 10, 2018

Fix Base64 madness for good

by Sven Van Caekenberghe

Hi, I propose the following: https://pharo.manuscript.com/f/cases/21870/Fix-Base64-madness-for-good https://github.com/pharo-project/pharo/pull/1331 This is a much needed cleanup, IMHO. It is a breaking change however, since it changes the signature (return type) of an existing method. #base64Decoded used to wrongly return a String, while that should be a ByteArray since Base64 encoding is a way to encode bytes as ASCII text, hence decoding it should give you back the original bytes. Sven

May 10, 2018

[Pharo 7.0-dev] Build #866: 21859-basicRemoveSelector-not-needed

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

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

May 10, 2018

[Pharo 7.0-dev] Build #865: 21868-Compiler-wrongly-defined-as-a-dependency-of-Collections-Tests

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

There is a new Pharo build available! The status of the build #865 was: FAILURE. The Pull Request #1329 was integrated: "21868-Compiler-wrongly-defined-as-a-dependency-of-Collections-Tests" Pull request url: https://github.com/pharo-project/pharo/pull/1329 Issue Url: https://pharo.fogbugz.com/f/cases/21868 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 10, 2018

[Pharo 7.0-dev] Build #864: 21866-Remove-Compiler-from-ignored-dependencies-of-OpalCompiler

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

There is a new Pharo build available! The status of the build #864 was: FAILURE. The Pull Request #1328 was integrated: "21866-Remove-Compiler-from-ignored-dependencies-of-OpalCompiler" Pull request url: https://github.com/pharo-project/pharo/pull/1328 Issue Url: https://pharo.fogbugz.com/f/cases/21866 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 10, 2018

[Pharo 7.0-dev] Build #863: 21611-Adapt-ImageReadWriter-hierarchy-to-need-only-pure-binary-streams

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

There is a new Pharo build available! The status of the build #863 was: FAILURE. The Pull Request #1323 was integrated: "21611-Adapt-ImageReadWriter-hierarchy-to-need-only-pure-binary-streams" Pull request url: https://github.com/pharo-project/pharo/pull/1323 Issue Url: https://pharo.fogbugz.com/f/cases/21611 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 10, 2018