[perl #58726] [PATCH] add the option "encoding" to Configure.pl
Allison Randal via RT
parrotbug-followup at parrotcode.org
Sat Dec 27 07:22:24 UTC 2008
On Sun Nov 23 13:17:16 2008, jkeen at verizon.net wrote:
> On Fri Sep 19 07:32:09 2008, pgerd wrote:
> > On Do. 18. Sep. 2008, 10:52:32, julianalbo wrote:
> > > Is not good that pir or pasm code meaning be dependent of locale
> > > specifics of the system.
> > >
> > > Also in several operating systems is not the computer who is working
> > > with some charset and encoding or other, is each process (depending of
> > > user settings on locale env vars, for example). So establishing an
> > > immutable global default is not a good idea.
Agreed, changing the behavior of strings by a compilation option breaks
bytecode/PIR/PASM portability.
> > I think Parrot use a global default (fixed_8) which should be
> > configurable at least. I think it would be nice to have a changeable
> > default as an Opcode.
>
> I think that this is a question which will call for a ruling from the
> architect and core developers. Allison, care to weigh in?
Parrot doesn't auto-detect string or file encodings/charsets for you, so
there's not really any advantage in changing the default. We could do
away with the default, and require an explicit encoding/charset on every
string, but it's convenient to have one encoding/charset in short form.
(And, makes sense to pick the cheapest one.)
Gerd, back to your reason for making the patch:
> I think I is necessary to tell parrot to work on a computer
> with utf-8 encoding also with the same encoding...
Even if your machine has UTF-8 set as the default encoding, you can have
files in any number of different encodings/charsets stored on it. The
sanest way to deal with our multiple-encoding world is to assume that
any given file or string may be in a different encoding/charset.
Allison
Allison
More information about the parrot-dev
mailing list