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

Re: [Pharo-dev] File/Stream changes: one Integer decoder/encoder to rule them all

by Marcus Denker

> > > For ByteArray, I didn't check recently in Pharo, but I know that it's quite a mess in Squeak because some methods are in Alien, other in FFI, other in base Squeak... > IMO all methods should be in core Squeak/Pharo because of general usage (like decoding binary data). > I want to move the methods from FFI to the base since yearsâ¦ I was told that this is impossible to ever happen because it is not important to do changes like that. Marcus

May 14, 2018

[Pharo 7.0-dev] Build #893: 21885-Simplify-ProcessList-classdumpPigStackOnandClose

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

There is a new Pharo build available! The status of the build #893 was: FAILURE. The Pull Request #1351 was integrated: "21885-Simplify-ProcessList-classdumpPigStackOnandClose" Pull request url: https://github.com/pharo-project/pharo/pull/1351 Issue Url: https://pharo.fogbugz.com/f/cases/21885 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 14, 2018

Re: [Pharo-dev] File/Stream changes: one Integer decoder/encoder to rule them all

by Nicolas Cellier

2018-05-14 13:22 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > > > On Fri, Apr 20, 2018 at 5:24 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Hi, >> >> After the File and Stream changes in Pharo 7, a binary read, resp. write >> stream from/to a file is actually a ZnBuffered(Read|Write)Stream on a >> BinaryFileStream. You access these using #binary(Read|Write)Stream[Do:] >> sent to a FileReference. >> >> As minimal streams the API of ZnBuffered(Read|Write)Stream was different >> from what existed before. >> >> Specifically, a number of Integer decoding/encoding methods were missing. >> It is probably best to add those (an alternative would be a subclass). >> >> When I looked at what was available, I thought I could improve upon the >> current situation. In fact, I think all existing ones can be written in >> terms of just one key method, one for reading and one for writing. The >> existing methods than become simple aliases, all while offering more >> functionality. >> >> (Incidentally this would be an ideal use of a Trait, can we use them >> again/still ?) >> >> The key method is #nextIntegerOfSize: numberOfBytes signed: signed >> bigEndian: bigEndian [put: value] and can be found in the latest version of >> Zinc-CharacterEncoding-Core with a comprehensive set of unit tests. >> >> For example, >> >> int32 >> ^ self nextIntegerOfSize: 4 signed: true bigEndian: true >> >> nextWord >> ^ self nextIntegerOfSize: 2 signed: false bigEndian: true > > >> or non-aliases ones like >> >> binaryStream nextIntegerOfSize: 3 signed: true bigEndian: false >> >> I think I nailed it, but I would love a second pair of eyes to check what >> I did. >> > > Sorry I arrive late. > > I'm thinking that this is only valid for binary streams, putting it in > buffered stream overloads the API... We can leave with it but... Two > thoughts that come to my mind about this: > > - first, when we are decoding like that from a stream, we are probably > parsing a binary format, so we want in general to have utility methods to > read different sizes. Maybe we could include a Reader class with methods > such as > * readSignedInt32 > * readUnsignedInt32 > * readSignedInt64 > * readUnsignedInt64 > * readFloat64 > > ... and so on? > > - Second, that Reader may be (or not) a new decorator alternative. > ZnBinaryDecoder? Wrapping a binary (buffered or not) stream. And this would > not overload the API ^^. > > What do you think? > Hi Guillermo, wouldn't a specialized wrapper work for adding this protocol where required? I have to add such BinaryStream wrapper in VW and Squeak http://www.squeaksource.com/STEM.html http://www.cincomsmalltalk.com/publicRepository/SYSEXT-BinaryStream.html For ByteArray, I didn't check recently in Pharo, but I know that it's quite a mess in Squeak because some methods are in Alien, other in FFI, other in base Squeak... IMO all methods should be in core Squeak/Pharo because of general usage (like decoding binary data). > >> The same functionality could be added to ByteArray in a slight variation >> (with offsets), where similar integer encoding/decoding methods exist. >> >> 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 > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 >

May 14, 2018

Re: [Pharo-dev] File/Stream changes: one Integer decoder/encoder to rule them all

by Guillermo Polito

On Fri, Apr 20, 2018 at 5:24 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > After the File and Stream changes in Pharo 7, a binary read, resp. write > stream from/to a file is actually a ZnBuffered(Read|Write)Stream on a > BinaryFileStream. You access these using #binary(Read|Write)Stream[Do:] > sent to a FileReference. > > As minimal streams the API of ZnBuffered(Read|Write)Stream was different > from what existed before. > > Specifically, a number of Integer decoding/encoding methods were missing. > It is probably best to add those (an alternative would be a subclass). > > When I looked at what was available, I thought I could improve upon the > current situation. In fact, I think all existing ones can be written in > terms of just one key method, one for reading and one for writing. The > existing methods than become simple aliases, all while offering more > functionality. > > (Incidentally this would be an ideal use of a Trait, can we use them > again/still ?) > > The key method is #nextIntegerOfSize: numberOfBytes signed: signed > bigEndian: bigEndian [put: value] and can be found in the latest version of > Zinc-CharacterEncoding-Core with a comprehensive set of unit tests. > > For example, > > int32 > ^ self nextIntegerOfSize: 4 signed: true bigEndian: true > > nextWord > ^ self nextIntegerOfSize: 2 signed: false bigEndian: true > or non-aliases ones like > > binaryStream nextIntegerOfSize: 3 signed: true bigEndian: false > > I think I nailed it, but I would love a second pair of eyes to check what > I did. > Sorry I arrive late. I'm thinking that this is only valid for binary streams, putting it in buffered stream overloads the API... We can leave with it but... Two thoughts that come to my mind about this: - first, when we are decoding like that from a stream, we are probably parsing a binary format, so we want in general to have utility methods to read different sizes. Maybe we could include a Reader class with methods such as * readSignedInt32 * readUnsignedInt32 * readSignedInt64 * readUnsignedInt64 * readFloat64 ... and so on? - Second, that Reader may be (or not) a new decorator alternative. ZnBinaryDecoder? Wrapping a binary (buffered or not) stream. And this would not overload the API ^^. What do you think? > The same functionality could be added to ByteArray in a slight variation > (with offsets), where similar integer encoding/decoding methods exist. > > 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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

May 14, 2018

[Pharo 7.0-dev] Build #892: 21890 Cleanup Collections-Sequenceable

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

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

May 14, 2018

[Pharo 7.0-dev] Build #891: 21738 Fix inconsistent method classifications (lint) in Collections

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

There is a new Pharo build available! The status of the build #891 was: SUCCESS. The Pull Request #1222 was integrated: "21738 Fix inconsistent method classifications (lint) in Collections" Pull request url: https://github.com/pharo-project/pharo/pull/1222 Issue Url: https://pharo.fogbugz.com/f/cases/21738 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 14, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #890: 21896-Cleanup-Shout

by Marcus Denker

Builds are failing du to CI problemsâ¦. e.g this one missing workspace /builds/workspace/branch_Pipeline_development-CMOUMEH7DVLJPL2EIJ6VPEHUQRS3W4AK3FD4ESTKJ3YGKZERQFUQ on pharo-ci-jenkins2-bootstrap-unix-2 But the granularity of PRs are very small (and they are tested on the PR level, too), so just one build in 6 or so is not that dangerous. (if the build for a merged PR fails, the merge still happened: the next PR merge then will build the system with the old one and the current oneâ¦) We need to track down the problems on the CI. Marcus > On 14 May 2018, at 12:06, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #890 was: FAILURE. > > The Pull Request #1350 was integrated: "21896-Cleanup-Shout" > Pull request url: https://github.com/pharo-project/pharo/pull/1350 > > Issue Url: https://pharo.fogbugz.com/f/cases/21896 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 14, 2018

[Pharo 7.0-dev] Build #890: 21896-Cleanup-Shout

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

There is a new Pharo build available! The status of the build #890 was: FAILURE. The Pull Request #1350 was integrated: "21896-Cleanup-Shout" Pull request url: https://github.com/pharo-project/pharo/pull/1350 Issue Url: https://pharo.fogbugz.com/f/cases/21896 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 14, 2018

Re: [Pharo-dev] Easy way to browse Hermes packages?

by Alistair Grant

Hi Pablo, Thanks! I'll take a look (my Pharo time is very limited at the moment, unfortunately). Cheers, Alistair On 12 May 2018 at 20:19, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hello, > having the Hermes files and any Pharo7 image it is easy to inspect the > Hermes package. > It only had to be read from the fileSystem. > > You can execute: > > reader := HEBinaryReader new > stream: ('AST-Core.hermes' asFileReference) binaryReadStream; > yourself. > > > package := HEPackage readFrom: reader. > > > If you inspect the package you will see all the content in the Hermes file > (the format allows us to have different root elements in the file, but we > are exporting a package per file). > If it is useful we can include it as an inspector. > > Cheers, > Pablo > > On Fri, May 11, 2018 at 10:55 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: >> >> Hi Everyone, >> >> Is there an easy way to browse the contents of .hermes files (from the >> Pharo 7 bootstrap process)? Or at least list the packages, classes >> and methods defined within? >> >> Thanks! >> Alistair >> > > > > -- > Pablo Tesone. > tesonep(a)gmail.com

May 14, 2018

[Pharo 7.0-dev] Build #889: 21889 Tag manifest in Collections-Arithmetic

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

There is a new Pharo build available! The status of the build #889 was: FAILURE. The Pull Request #1344 was integrated: "21889 Tag manifest in Collections-Arithmetic" Pull request url: https://github.com/pharo-project/pharo/pull/1344 Issue Url: https://pharo.fogbugz.com/f/cases/21889 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 14, 2018