<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="m_1715343059872429135m_-7327258519156082806gmail_attr">Le mer. 16 janv. 2019 à 23:23, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div dir="ltr">Hi Sven,</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 16, 2019 at 2:37 AM Sven Van Caekenberghe <<a href="mailto:sven@stfx.eu" target="_blank">sven@stfx.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Still, one of the conclusions of previous discussions about the encoding of environment variables was/is that there is no single correct solution. OS's are not consistent in how the encoding is done in all (historical) contexts (like sometimes, 1 env var defines the encoding to use for others, different applications do different things, and other such nice stuff), and certainly not across platforms.<br>
<br>
So this is really complex.<br>
<br>
Do we want to hide this in some obscure VM C code that very few people can see, read, let alone help with ?<br>
<br>
The image side is perfectly capable of dealing with platform differences in a clean/clear way, and at least we can then use the full power of our language and our tools.<br></blockquote><div><br></div><div>Agreed.  At the same time I think it is very important that we don't reply on the FFI for environment variable access.  This is a basic cross-platform facility.  So I would like to see the environment accessed through primitives, but have the image place interpretation on the result of the primitive(s), and have the primitive(s) answer a raw result, just a sequence of uninterpreted bytes.</div><div><br></div><div>VisualWorks takes this approach and provides a class UninterpretedBytes that the VM is aware of.  That's always seemed like an ugly name and overkill to me.  I would just use ByteArray and provide image level conversion from ByteArray to String, which is what I believe we have anyway.</div><div><br></div></div></div></blockquote><div><br></div><div>What's important is to create abstract layers that insulate the un-needed complexity in lowest layers possible.</div><div>The VM excels at insulating of course.</div><div>At image side we have to assume the responsibility of not leaking too much by ourself.<br></div><div><br></div><div>As Eliot said, right now the VM (and FFI) just take sequences of uninterpreted bytes (ByteArray) and pass them to API.</div><div>The conversion ByteString/WideString <-> specifically-encoded ByteArray is performed at image side.</div><div><br></div><div>With FFI, we could eventually make this conversion platform specific instead of always UTF8.</div>The purpose would be to reduce back and forth conversions in chained API calls for example.<br><div>For sanity, then better follow those rules:</div><div>- the image does not 
attempt direct interaction with these opaque data (other than thru OS API)<br></div><div>- nor preserve them across 
snapshots.</div><div>Beware, conversion is not platform specific, but can be library specific (some library on windows will take UTF8).</div><div>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.<br></div><div>We would thus let complexity creep one more level, but only if we have good reason to do so.</div><div>We don't want to trade uniformity for small gains.<br></div><div><div>BTW, note that the xxxW API is already a huge uniformisation progress compared to the code-page specific xxxA API!<br></div></div><div><div><br></div><div>Another strategy is to create more complex abstractions (i.e. 
parameterized) that can deal with a zoo of different underlying 
conventions.</div><div>For example, this would be the EncodedString of VW.</div><div>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.<br></div><div>But I strongly advise to think twice (or more) before introducing such complexity:<br></div><div>- it breaks former invariants (thus potentially lot of code)</div><div>- complexity tends to spread in many places</div><div>I don't recommend it.<br></div></div><div><br></div><div>PS: oups, sorry for out of band message, I wanted to send, but it seems that I did not press the button properly...<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> On 16 Jan 2019, at 10:59, Guillermo Polito <<a href="mailto:guillermopolito@gmail.com" target="_blank">guillermopolito@gmail.com</a>> wrote:<br>
> <br>
> Hi Nicolas,<br>
> <br>
> On Wed, Jan 16, 2019 at 10:25 AM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
> 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.<br>
> I made progress recently in this area, but we should finish the job/test/consolidate.<br>
> <br>
> I'm following your changes for windows from the shadows and I think they are awesome :).<br>
>  <br>
> If someone bypass the VM and use direct windows API thru FFI, then he takes the responsibility, but uniformity doesn't hurt.<br>
> <br>
>  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.<br>
> 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 :).<br>
> <br>
> But this could be for a 7.1.0, and if you like I can surely give a hand on this.<br>
> <br>
> Guille<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_1715343059872429135m_-7327258519156082806gmail-m_-524591597337693510gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>
</blockquote></div></div>