[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