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

Debugger "Through" acting like "Into"

by Martin McClure

In the latest Pharo 7 (Pharo-7.0.0+rc1.build.1384.sha.c34d6a69d9d01a2816df1f9fdc7388580163df29 (32 Bit)) it seems like clicking "Through" in the debugger often (but not always) has the effect of "Into", which seems wrong and makes stepping through code difficult. I don't know how new this behavior is. Is this a known behavior? If not, I'll characterize it further. Regards, -Martin

Nov. 14, 2018

Re: [Pharo-dev] How do I create a binary stream

by Stephane Ducasse

Thanks you all for the discussion. We should improve the comment of File and probably the one of FileReference. Tx Sven for the improvement of the comment of ImageReadWriter. Good comments are so important! We underestimate their impact. S On Sun, Nov 11, 2018 at 2:10 PM Hilaire <hilaire(a)drgeo.eu> wrote: > > I am quite happy with the new FileReference API. > > Le 11/11/2018 Ã 13:51, Sven Van Caekenberghe a Ã©crit : > > API changes are always annoying, but splitting reading and writing as well as binary and character streams is a clear improvement overall. > > > -- > Dr. Geo > http://drgeo.eu > > >

Nov. 13, 2018

[Pharo 7.0-dev] Build #1393: 22659-generated-artifacts-should-have-the-version-tag (V5)

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

There is a new Pharo build available! The status of the build #1393 was: FAILURE. The Pull Request #1987 was integrated: "22659-generated-artifacts-should-have-the-version-tag (V5)" Pull request url: https://github.com/pharo-project/pharo/pull/1987 Issue Url: https://pharo.fogbugz.com/f/cases/22659 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

[Pharo 7.0-dev] Build #1392: 22659-generated-artifacts-should-have-the-version-tag (V4)

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

There is a new Pharo build available! The status of the build #1392 was: FAILURE. The Pull Request #1986 was integrated: "22659-generated-artifacts-should-have-the-version-tag (V4)" Pull request url: https://github.com/pharo-project/pharo/pull/1986 Issue Url: https://pharo.fogbugz.com/f/cases/22659 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

[Pharo 7.0-dev] Build #1391: 22659-generated-artifacts-should-have-the-version-tag (V3)

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

There is a new Pharo build available! The status of the build #1391 was: FAILURE. The Pull Request #1984 was integrated: "22659-generated-artifacts-should-have-the-version-tag (V3)" Pull request url: https://github.com/pharo-project/pharo/pull/1984 Issue Url: https://pharo.fogbugz.com/f/cases/22659 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

[Pharo 7.0-dev] Build #1390: 22659-generated-artifacts-should-have-the-version-tag (V2)

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

There is a new Pharo build available! The status of the build #1390 was: FAILURE. The Pull Request #1983 was integrated: "22659-generated-artifacts-should-have-the-version-tag (V2)" Pull request url: https://github.com/pharo-project/pharo/pull/1983 Issue Url: https://pharo.fogbugz.com/f/cases/22659 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

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

by Guillermo Polito

I have to add also > 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. > - Similar changes had to be applied to correctly obtain the current > working directory in case it is a wide string. > > - The default encoding assumed so far in *nixes is utf8. A more robust implementation could obtain this from the locale, but this would be too much of a change as all the locale code should be revisited too.

Nov. 13, 2018

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

by Guillermo Polito

Hi all, Thanks Ben for reading. For those wanting a follow up, I've proposed this pull request: https://github.com/pharo-project/pharo/pull/1980. I'm still working on avoiding dependencies against UFFI, fixing one other test. This is however almost finished, and given that I had to adapt the original *abstract proposal* to fit the real system, here is an updated version: API Proposal for OSEnvironment and friends ========================= OSEnvironment is the common denominator for all platforms. They should implement at least the following messages with the following semantics: - *at: aVariableName [ifAbsent:/ifAbsentPut:/ifPresent:ifAbsent:]* Gets the String value of an environment variable called `aVariableName`. It is the system reponsibility to manage the encoding of *both arguments and return values*. - *at: aVariableName put: aValue* Sets the environment variable called `aVariableName` to value `aValue`. It is the system reponsibility to manage the encoding of *both arguments and return values*. - *removeKey: aVariableName* Removes the environment variable called `aVariableName`. It is the system reponsibility to manage the encoding of *both arguments and return values*. API Extensions for *Nix Systems (OSX & Linux) ========================= Since *Nixes environment variables are binary data that could be encoded in any encoding, the following methods provide more flexibility to access such data in the encoding of the choice of the user, or even in binary form. - *at: aVariableName encoding: anEncoding [ifAbsent:/ifAbsentPut:/ifPresent:ifAbsent:/put:] / removeKey:** aVariableName encoding: anEncoding* Variants of the common API from OSEnvironment. The encoding used as argument will be used to encode/decode *both arguments and return values*. - *rawAt: anEncodedVariableName encoding: anEncoding [ifAbsent:/ifAbsentPut:/ifPresent:ifAbsent:/put:] / removeRawKey:* *anEncodedVariableName* Variants of the common API from OSEnvironment. These methods assume arguments and return values are encoded/decoded by the user, so no marshalling or decoded is done by it. Rationale ========================= - Encoding/Decoding should be applied not only to values but to variables names too. In most cases Ascii overlaps with utf* and Latin* encodings, but this cannot be simply assumed. - 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. - Unix FileSystems and environment variables could mix strings in different encodings, thus the flexibility added by the low level *Nix extensions. 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. - Similar changes had to be applied to correctly obtain the current working directory in case it is a wide string. On Mon, Nov 12, 2018 at 1:31 PM Ben Coman <btc(a)openinworld.com> wrote: > > > On Mon, 12 Nov 2018 at 18:02, 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 >> >> > I haven't been using environment variables a lot so I don't have a strong > technical opinion (although at a glance it makes reasonable sense). > But I wanted to say I really like the way you've presented your offline > discussion, conclusions and proposal. Thanks. > > cheers -ben > > -- 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

Nov. 13, 2018

[Pharo 7.0-dev] Build #1389: 22659-generated-artifacts-should-have-the-version-tag (V2)

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

There is a new Pharo build available! The status of the build #1389 was: FAILURE. The Pull Request #1983 was integrated: "22659-generated-artifacts-should-have-the-version-tag (V2)" Pull request url: https://github.com/pharo-project/pharo/pull/1983 Issue Url: https://pharo.fogbugz.com/f/cases/22659 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018

[Pharo 7.0-dev] Build #1388: 22657-The-closing-of-a-window-using-a-keyboard-can-close-a-window-without-focus

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

There is a new Pharo build available! The status of the build #1388 was: FAILURE. The Pull Request #1971 was integrated: "22657-The-closing-of-a-window-using-a-keyboard-can-close-a-window-without-focus" Pull request url: https://github.com/pharo-project/pharo/pull/1971 Issue Url: https://pharo.fogbugz.com/f/cases/22657 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2018