January 2019 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Bad baseline practices

by Norbert Hartl

> Am 16.01.2019 um 09:42 schrieb 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 > Wasnât the problem that the wildcard notation is likely to hit the github API request limit? Norbert

Jan. 16, 2019

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

by Stephan Eggermont

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

Jan. 16, 2019

Re: [Pharo-dev] Bad baseline practices

by Stephan Eggermont

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] IceGitHubError API rate limit exceeded

by Paul DeBruicker

hi - Once you get a no-scope token from https://github.com/settings/tokens You can configure Monticello to use it to access github by running MCGitHubRepository siteUsername: 'myUsername' sitePassword: 'token' Paul DeBruicker wrote > github allows 60 unauthenticated requests per hour per IP. IF you > authenticate your requests you can make 5,000 per hour. If you don't want > to wait an hour after hitting this error you should create a personal, no > scope token following the instructions here: > https://blog.github.com/2013-05-16-personal-api-tokens/ The no-scope token > can only be used to read public repository information and cannot make any > changes to any of your repos. > > You can use the token to authenticate your requests by setting your github > username as the username and the token as the password in a HTTP basic > authentication request to their servers. > > I know ZnClient has #username:password: and so guess that Iceberg has or > can > have a similar method. > > Dont share the token. > > > > bpi wrote >> Hi, >> >> I followed these instructions for contributing to Pharo: >> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo >> >> During Step 1 Repairing local repository missing I get the following >> error: >> IceGitHubError: API rate limit exceeded >> >> I retried with a new Pharo 7.0 - 64bit (development version) in Pharo >> Launcher and got the same error. >> >> I searched the mailing list but did not find anything. Am I really the >> only one who ever encountered this? Any tips? >> >> Cheers, >> Bernhard > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 16, 2019

Re: [Pharo-dev] Apparently Zodiac plugin can crash VM on Linux

by Sven Van Caekenberghe

Doing HTTPS client calls is part of the standard test suite, so it should work, else we would not have a green build. What exactly is he doing ? Is it reproducible ? Can he try with a fresh downloaded image+vm ? > On 15 Jan 2019, at 22:20, Max Leske <maxleske(a)gmail.com> wrote: > > Hi, > > I'm writing on behalf of Martin (eMBee) who's experiencing crashes when using SSL. You can find a VM crash stack trace here: http://ws.stfx.eu/AKVNLUPMPGLG. > > He says he hasn't updated openssl since December 15th but that the crashes started to happen only recently (within the last couple of days). I asked him to try HTTP only connections and those work. The VM crashes immediately when using SSL. To me it looks like the cuplrit is the Zodiac plugin, or at least the library it works with. > > His system: > linux, fedora 29, and from the system reporter i get: Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo > CoInterpreter VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 > VM: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > > cheers, > Max

Jan. 15, 2019