In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> As things stand, that won't work, because you're doing a string lookup in one
> of the core functions, and you still need some way of registering incoming
> stuff. With an enum, you can keep hold of a fake encoding_m
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 se
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
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 st
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
> >
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 conv
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, ye
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.
Y
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
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 transcodi
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 c
L PROTECTED]
Subject: RE: 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 other
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 hav
ECTED]
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 p
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 wro
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
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 w
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
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,
>
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 lat
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 La
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
22 matches
Mail list logo
