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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Jan 18 08:38:09 EST 2019

Le ven. 18 janv. 2019 à 14:35, ducasse <stepharo at netcourrier.com> a écrit :

> What's important is to create abstract layers that insulate the un-needed
> complexity in lowest layers possible.
> The VM excels at insulating of course.
> At image side we have to assume the responsibility of not leaking too much
> by ourself.
> As Eliot said, right now the VM (and FFI) just take sequences of
> uninterpreted bytes (ByteArray) and pass them to API.
> The conversion ByteString/WideString <-> specifically-encoded ByteArray is
> performed at image side.
> With FFI, we could eventually make this conversion platform specific
> instead of always UTF8.
> The purpose would be to reduce back and forth conversions in chained API
> calls for example.
> For sanity, then better follow those rules:
> - the image does not attempt direct interaction with these opaque data
> (other than thru OS API)
> - nor preserve them across snapshots.
> Beware, conversion is not platform specific, but can be library specific
> (some library on windows will take UTF8).
> So we may reify the library and always double dispatch to the library, or
> we create upper level abstract messages that may chain several low level OS
> API calls.
> We would thus let complexity creep one more level, but only if we have
> good reason to do so.
> We don't want to trade uniformity for small gains.
> BTW, note that the xxxW API is already a huge uniformisation progress
> compared to the code-page specific xxxA API!
> Hi nicolas
> I’m reading and trying to understand. but the xxx lost me. :)
> Sorry, I was talking of the windows API variants, W for Wide characters, A
for ASCII (or rather current-code-page in effect)

> Another strategy is to create more complex abstractions (i.e.
> parameterized) that can deal with a zoo of different underlying conventions.
> For example, this would be the EncodedString of VW.
> This strategy could be tempting, because it enables dealing with lower
> level platform-specific-encoded objects and still interact with them in the
> image transparently.
> But I strongly advise to think twice (or more) before introducing such
> complexity:
> - it breaks former invariants (thus potentially lot of code)
> - complexity tends to spread in many places
> I don't recommend it.
> PS: oups, sorry for out of band message, I wanted to send, but it seems
> that I did not press the button properly...
>>> > On 16 Jan 2019, at 10:59, Guillermo Polito <guillermopolito at gmail.com>
>>> wrote:
>>> >
>>> > Hi Nicolas,
>>> >
>>> > On Wed, Jan 16, 2019 at 10:25 AM Nicolas Cellier <
>>> nicolas.cellier.aka.nice at 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
>> --
>> _,,,^..^,,,_
>> best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20190118/0e5c17fb/attachment.html>

More information about the Pharo-dev mailing list