On Sat, Oct 27, 2001 at 04:23:48PM +0100, Tom Hughes wrote:
The encoding_lookup() and chartype_lookup() routines will obviously
need to load the relevant libraries on the fly when we have support
for that.
Could you try rewriting them using an enum, like the vtable stuff and
the original
In message [EMAIL PROTECTED]
Simon Cozens [EMAIL PROTECTED] wrote:
On Sat, Oct 27, 2001 at 04:23:48PM +0100, Tom Hughes wrote:
The encoding_lookup() and chartype_lookup() routines will obviously
need to load the relevant libraries on the fly when we have support
for that.
Could
On Thu, Nov 01, 2001 at 02:18:17PM +, Tom Hughes wrote:
Could you try rewriting them using an enum, like the vtable stuff and
the original string encoding stuff does?
Allocating them globally is not possible if we're going allow people
to add arbitrary encodings and character sets -
In message [EMAIL PROTECTED]
Tom Hughes [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED]
Dan Sugalski [EMAIL PROTECTED] wrote:
At 04:23 PM 10/27/2001 +0100, Tom Hughes wrote:
Attached is my first pass at this - it's not fully ready yet but
is something for
At 07:16 PM 10/29/2001 -0500, James Mastros wrote:
Yeah. But that's a convention thing, I think. I also think that most
people won't go to the bother of writing conversion functions that they
don't have to. What we need to worry about is both, say, big5 and shiftjis
writing both of the
In message [EMAIL PROTECTED]
James Mastros [EMAIL PROTECTED] wrote:
On Mon, Oct 29, 2001 at 11:20:47PM +, Tom Hughes wrote:
I suspect that the encode and decode methods in the encoding vtable
are enough for doing chr/ord aren't they?
Hmm... come to think of it, yes. chr
In message [EMAIL PROTECTED]
James Mastros [EMAIL PROTECTED] wrote:
That leaves the third, which is what I have implemented. When looking to
transcode from A to B it will first ask A if can it transcode to B and
if that fails then it will ask B if it can transcode from A.
I
On Mon, Oct 29, 2001 at 11:20:47PM +, Tom Hughes wrote:
2) But either can support converting directly if it wants.
The danger is that everybody tries to be clever and support direct
conversion to and from as many other character sets as possible, which
leads to lots of duplication.
Yeah.
In message [EMAIL PROTECTED]
Dan Sugalski [EMAIL PROTECTED] wrote:
At 04:23 PM 10/27/2001 +0100, Tom Hughes wrote:
Attached is my first pass at this - it's not fully ready yet but
is something for people to cast an eye over before I spend lots of
time going down the wrong path ;-)
At 02:52 PM 10/29/2001 -0500, Stephen Howard wrote:
You might consider requiring all character sets be able to convert to Unicode,
That's already a requirement. All character sets must be able to go to or
come from Unicode. They can do others if they want, but it's not required.
(And we'll
]
Subject: Re: String rationale
In message [EMAIL PROTECTED]
Dan Sugalski [EMAIL PROTECTED] wrote:
At 04:23 PM 10/27/2001 +0100, Tom Hughes wrote:
Attached is my first pass at this - it's not fully ready yet but
is something for people to cast an eye over before I spend lots
: String rationale
At 02:52 PM 10/29/2001 -0500, Stephen Howard wrote:
You might consider requiring all character sets be able to convert to Unicode,
That's already a requirement. All character sets must be able to go to or
come from Unicode. They can do others if they want, but it's not required
In message [EMAIL PROTECTED]
Stephen Howard [EMAIL PROTECTED] wrote:
right. I had just keyed in on this from Tom's message:
My code currently allows either set to provide the transform on the
grounds that otherwise the unicode module would have to either know
how to convert to
On Mon, Oct 29, 2001 at 08:32:16PM +, Tom Hughes wrote:
We have established that the first two will not work because of the
unicode problem.
Hm. I think instead of requiring Unicode to support everything, we should
require Unicode to support /nothing/. If A and B have no mutual
In message [EMAIL PROTECTED]
Tom Hughes [EMAIL PROTECTED] wrote:
Other than that it looked quite good and I'll probably start looking at
bending the existing code into the new model over the weekend.
Attached is my first pass at this - it's not fully ready yet but
is something for
In message [EMAIL PROTECTED]
Tom Hughes [EMAIL PROTECTED] wrote:
Attached is my first pass at this - it's not fully ready yet but
is something for people to cast an eye over before I spend lots of
time going down the wrong path ;-)
Before anybody else spots, let me just add what I
At 04:23 PM 10/27/2001 +0100, Tom Hughes wrote:
In message [EMAIL PROTECTED]
Tom Hughes [EMAIL PROTECTED] wrote:
Other than that it looked quite good and I'll probably start looking at
bending the existing code into the new model over the weekend.
Attached is my first pass at
'Kay, here's the string background info I promised. If things are missing
or unclear let me know and I'll fix it up until it is.
==Cut here with a very sharp knife===
=head1 TITLE
A parrot string backgrounder
=head1 Overview
Strings, in parrot, are
On Thu, 25 Oct 2001, Dan Sugalski wrote:
The only bits of the interpreter that much care about the
string data are the regex engine parts, and those only operate on
fixed-sized data.
Care to elaborate? I thought the mandate from Larry was to have regexes
compile down to a stream of string
At 12:19 PM 10/25/2001 -0400, Sam Tregar wrote:
On Thu, 25 Oct 2001, Dan Sugalski wrote:
The only bits of the interpreter that much care about the
string data are the regex engine parts, and those only operate on
fixed-sized data.
Care to elaborate? I thought the mandate from Larry was
In message [EMAIL PROTECTED]
Dan Sugalski [EMAIL PROTECTED] wrote:
=item type
What the character set or type of data is encoded in the buffer. This
includes things like ASCII, EBCDIC, Unicode, Chinese Traditional,
Chinese Simplified, or Shift-JIS. (And yes, I know the latter's a
At 11:59 PM 10/25/2001 +0100, Tom Hughes wrote:
In message [EMAIL PROTECTED]
Dan Sugalski [EMAIL PROTECTED] wrote:
=item type
What the character set or type of data is encoded in the buffer. This
includes things like ASCII, EBCDIC, Unicode, Chinese Traditional,
Chinese
22 matches
Mail list logo
