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

Guillermo Polito guillermopolito at gmail.com
Wed Jan 16 04:14:09 EST 2019


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 at stack.nl> wrote:
>
> Guillermo Polito <guillermopolito at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20190116/82d360ff/attachment.html>


More information about the Pharo-dev mailing list