- Pharo-dev - lists.pharo.org

[Pharo 7.0] Build #124: 22737-The-changelog-for-Pharo-7-needs-update

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

There is a new Pharo build available! The status of the build #124 was: FAILURE. The Pull Request #2251 was integrated: "22737-The-changelog-for-Pharo-7-needs-update" Pull request url: https://github.com/pharo-project/pharo/pull/2251 Issue Url: https://pharo.fogbugz.com/f/cases/22737 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 16, 2019

[Pharo 7.0] Build #123: 22890-IconListModelbackgroundColorBlock-does-not-work

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

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

Jan. 16, 2019

Re: [Pharo-dev] Better management of encoding of environment variables

by Sven Van Caekenberghe

Still, one of the conclusions of previous discussions about the encoding of environment variables was/is that there is no single correct solution. OS's are not consistent in how the encoding is done in all (historical) contexts (like sometimes, 1 env var defines the encoding to use for others, different applications do different things, and other such nice stuff), and certainly not across platforms. So this is really complex. Do we want to hide this in some obscure VM C code that very few people can see, read, let alone help with ? The image side is perfectly capable of dealing with platform differences in a clean/clear way, and at least we can then use the full power of our language and our tools. > On 16 Jan 2019, at 10:59, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi Nicolas, > > On Wed, Jan 16, 2019 at 10:25 AM Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion because the purpose of a VM is to provide an OS independant faÃ§ade. > I made progress recently in this area, but we should finish the job/test/consolidate. > > I'm following your changes for windows from the shadows and I think they are awesome :). > > If someone bypass the VM and use direct windows API thru FFI, then he takes the responsibility, but uniformity doesn't hurt. > > So far we are using FFI for this, as you say we create first Win32WideStrings from utf8 strings and then we use ffi calls to the *W functions. > I don't think we can make it for Pharo7.0.0. The cycle to build, do some acceptance tests, and then bless a new VM as stable is far too long for our inminent release :). > > But this could be for a 7.1.0, and if you like I can surely give a hand on this. > > Guille

Jan. 16, 2019

Re: [Pharo-dev] Better management of encoding of environment variables

by Guillermo Polito

Hi Nicolas, On Wed, Jan 16, 2019 at 10:25 AM Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion > because the purpose of a VM is to provide an OS independant faÃ§ade. > I made progress recently in this area, but we should finish the > job/test/consolidate. > I'm following your changes for windows from the shadows and I think they are awesome :). > If someone bypass the VM and use direct windows API thru FFI, then he > takes the responsibility, but uniformity doesn't hurt. > So far we are using FFI for this, as you say we create first Win32WideStrings from utf8 strings and then we use ffi calls to the *W functions. I don't think we can make it for Pharo7.0.0. The cycle to build, do some acceptance tests, and then bless a new VM as stable is far too long for our inminent release :). But this could be for a 7.1.0, and if you like I can surely give a hand on this. Guille

Jan. 16, 2019

Re: [Pharo-dev] Better management of encoding of environment variables

by Stephan Eggermont

Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion because > the purpose of a VM is to provide an OS independant faÃ§ade. > I made progress recently in this area, but we should finish the > job/test/consolidate. > If someone bypass the VM and use direct windows API thru FFI, then he takes > the responsibility, but uniformity doesn't hurt. That sounds like a very good idea. Do you suggest to do that after the Pharo 7 release? Or is it simple enough that it can be done in time? On the unix side, do I need the explicit encoding or can I ask the OSEnvironment for the one I need? Before the Pharo 7 release we need at least a #getEnv: back and a class comment corresponding to what is expected. If we want to change to the new API it needs to be deprecated. Stephan

Jan. 16, 2019

Re: [Pharo-dev] Better management of encoding of environment variables

by Stephan Eggermont

Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Stephan, > > I'm sorry for the noise. No problem, just trying to understand where we want to go. Stephan

Jan. 16, 2019

Re: [Pharo-dev] Better management of encoding of environment variables

by Nicolas Cellier

IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion because the purpose of a VM is to provide an OS independant faÃ§ade. I made progress recently in this area, but we should finish the job/test/consolidate. If someone bypass the VM and use direct windows API thru FFI, then he takes the responsibility, but uniformity doesn't hurt. Le mer. 16 janv. 2019 Ã 10:14, Guillermo Polito <guillermopolito(a)gmail.com> a Ã©crit : > Hi Stephan, > > I'm sorry for the noise. > > At the time, both #at: and #getEnv: variants existed. The changes > backported from the PharoLauncher were only using the getter versions of > getEnv, but for Pharo I decided to implement also the setter versions. And > after checking the code and its users in image, I've finally decided to go > for an at:[[ifAbsent]put:] version. So I'd say that the leading > **guideline** was at the end the one here in the mailing list, but also if > you check the PR I've introduced a more complete and consistent API, > following the one of dictionaries. > > https://github.com/pharo-project/pharo/pull/1980/files > > at: > at:ifAbsent: > at:ifPresent: > at:ifPresent:ifAbsent: > at:put: > removeKey: > > Plus, in *nix, variants where an encoding can be specified. > > I'm sorry if I've introduced some confussion. > > > On Wed, Jan 16, 2019 at 9:47 AM Stephan Eggermont <stephan(a)stack.nl> > wrote: > > > > Guillermo Polito <guillermopolito(a)gmail.com> > > wrote: > > > Hi all, > > > > > > following the meeting we had here @Inria headquarters, I'll be > backporting > > > some of the improvements we did in the launcher this last month > regarding > > > the encoding of environment variables. > > > > > > I've opened for this issue https://pharo.fogbugz.com/f/cases/22658/ > > > > > > We have already studied possible alternatives with Pablo and > Christophe and > > > we have some conclusions and we propose some changes: > > > > > > API Proposal for OSEnvironment > > > ========================= > > > > > > > > > - > > > *at: aVariableName * > > > > > > Gets the String value of an environment variable called `aVariableName` > > > It is the system reponsibility to manage the encoding. > > > Rationale: A common denominator for all platforms providing an already > > > decoded string, because windows does not (compared to *nix systems) > provide > > > a encoded byte representation of the value. Windows has instead its own > > > wide string representation. > > > > > > - *[optionally] rawAt: anEncodedVariableName* > > > > > > Gets the Byte value of an environment variable called > > > `anEncodedVariableName`. > > > It is the user responsibility to encode and decode argument and return > > > values in the encoding of this preference. > > > Rationale: Some systems may want to have the liberty to use different > > > encodings, or even to put binary data in the variables. > > > > > > - *[optionally] at: aVariableName encoding: anEncoding* > > > > > > Gets the value of an environment variable called `aVariableName` using > > > `anEncoding` to encode/decode arguments and return values. > > > Rationale: *xes could potentially use different encodings for their > > > environment variables or even use different encodings in different > parts of > > > their file system. > > > > > > Other Implementation details > > > ========================= > > > > > > - VM primitives returning paths Strings should be carefuly managed > to > > > decode them, since they are actually C strings (so byte arrays) > disguised > > > as ByteStrings. > > > - Windows requires calling the right *Wide version of the functions > from > > > C, plus the correct encoding routine. This could be implemented as > an FFI > > > call or by modifying the VM to do it properly instead of calling > the Ascii > > > version > > > > > > > > > > What is the conclusion from this and issue 22658? See PR 2238. #getEnv: > is > > public API > > > > Stephan > > > > > > > > > -- > > > > 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 >

Jan. 16, 2019

Re: [Pharo-dev] Better management of encoding of environment variables

by Guillermo Polito

Hi Stephan, I'm sorry for the noise. At the time, both #at: and #getEnv: variants existed. The changes backported from the PharoLauncher were only using the getter versions of getEnv, but for Pharo I decided to implement also the setter versions. And after checking the code and its users in image, I've finally decided to go for an at:[[ifAbsent]put:] version. So I'd say that the leading **guideline** was at the end the one here in the mailing list, but also if you check the PR I've introduced a more complete and consistent API, following the one of dictionaries. https://github.com/pharo-project/pharo/pull/1980/files at: at:ifAbsent: at:ifPresent: at:ifPresent:ifAbsent: at:put: removeKey: Plus, in *nix, variants where an encoding can be specified. I'm sorry if I've introduced some confussion. On Wed, Jan 16, 2019 at 9:47 AM Stephan Eggermont <stephan(a)stack.nl> wrote: > > Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Hi all, > > > > following the meeting we had here @Inria headquarters, I'll be backporting > > some of the improvements we did in the launcher this last month regarding > > the encoding of environment variables. > > > > I've opened for this issue https://pharo.fogbugz.com/f/cases/22658/ > > > > We have already studied possible alternatives with Pablo and Christophe and > > we have some conclusions and we propose some changes: > > > > API Proposal for OSEnvironment > > ========================= > > > > > > - > > *at: aVariableName * > > > > Gets the String value of an environment variable called `aVariableName` > > It is the system reponsibility to manage the encoding. > > Rationale: A common denominator for all platforms providing an already > > decoded string, because windows does not (compared to *nix systems) provide > > a encoded byte representation of the value. Windows has instead its own > > wide string representation. > > > > - *[optionally] rawAt: anEncodedVariableName* > > > > Gets the Byte value of an environment variable called > > `anEncodedVariableName`. > > It is the user responsibility to encode and decode argument and return > > values in the encoding of this preference. > > Rationale: Some systems may want to have the liberty to use different > > encodings, or even to put binary data in the variables. > > > > - *[optionally] at: aVariableName encoding: anEncoding* > > > > Gets the value of an environment variable called `aVariableName` using > > `anEncoding` to encode/decode arguments and return values. > > Rationale: *xes could potentially use different encodings for their > > environment variables or even use different encodings in different parts of > > their file system. > > > > Other Implementation details > > ========================= > > > > - VM primitives returning paths Strings should be carefuly managed to > > decode them, since they are actually C strings (so byte arrays) disguised > > as ByteStrings. > > - Windows requires calling the right *Wide version of the functions from > > C, plus the correct encoding routine. This could be implemented as an FFI > > call or by modifying the VM to do it properly instead of calling the Ascii > > version > > > > > > What is the conclusion from this and issue 22658? See PR 2238. #getEnv: is > public API > > Stephan > > > -- 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

Jan. 16, 2019

Re: [Pharo-dev] Bad baseline practices

by Denis Kudriashov

Hi Stephan. There was discussion about it. And idea is to have reproducible builds for Pharo. With floating versions we can't achieve it (at least with current tools). In addition I maintain floating branches for those projects (v0.15.x). So for your own projects you can reference them instead of static versions. ÑÑ, 16 ÑÐ½Ð². 2019 Ð³., 8:45 Stephan Eggermont stephan(a)stack.nl: > Cyril Ferlicot <cyril.ferlicot(a)gmail.com> > wrote: > > On Tue, Jan 15, 2019 at 6:03 PM Stephan Eggermont via Pharo-dev > > <pharo-dev(a)lists.pharo.org> wrote: > >> > >> > >> > >> Iâm not sure why, but Iâve noticed baselines being changed to refer to > >> patch versions for releases. Why are the old configuration problems > >> repeated? > > > > Which project are you talking about? > > In a plain Pharo 7 image > > BaselineOfCalypso > BaselineOfCommander > BaselineOfSystemCommands > > Stephan > > > >

Jan. 16, 2019

Re: [Pharo-dev] Bad baseline practices

by Cyril Ferlicot

On Wed, Jan 16, 2019 at 9:59 AM Norbert Hartl <norbert(a)hartl.name> wrote: > > > > > > > In a plain Pharo 7 image > > > > BaselineOfCalypso > > BaselineOfCommander > > BaselineOfSystemCommands > > In which version? Because in the latest I do not see any floating version. I know that Denis uses floating version but only for the development version, not for release. > > Stephan > > > Wasnât the problem that the wildcard notation is likely to hit the github API request limit? > No, Denis is uring branches name v0.9.x for example to not use tags. > Norbert > > -- Cyril Ferlicot https://ferlicot.fr

Jan. 16, 2019