[Pharo-dev] Better management of encoding of environment variables
guillermopolito at gmail.com
Wed Jan 16 04:14:09 EST 2019
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.
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 at stack.nl> wrote:
> Guillermo Polito <guillermopolito at gmail.com>
> > Hi all,
> > following the meeting we had here @Inria headquarters, I'll be
> > some of the improvements we did in the launcher this last month
> > 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
> > 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)
> > 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
> > 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)
> > as ByteStrings.
> > - Windows requires calling the right *Wide version of the functions
> > C, plus the correct encoding routine. This could be implemented as
> > call or by modifying the VM to do it properly instead of calling the
> > version
> What is the conclusion from this and issue 22658? See PR 2238. #getEnv: is
> public API
Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - http://www.cnrs.fr
Phone: +33 06 52 70 66 13
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev