Ken Fox <[EMAIL PROTECTED]> wrote:
> David Mitchell wrote:
> > To get my head round PDD 2, I've just written the the outline
> > for the body of the add() method for a hypophetical integer PMC class:
>
> [... lots of complex code ...]
>
> I think this example is a good reason to consider only ha
On Thu, Feb 15, 2001 at 05:09:45PM -0800, Hong Zhang wrote:
> People in Japan/China/Korea have been using multi-byte encoding for
> long time. I personally have used it for more 10 years.
And now you have a chance to not do so. Isn't that *nice*?
--
Term, holidays, term, holidays, till we leav
On Thu, Feb 15, 2001 at 04:55:00PM -0800, Hong Zhang wrote:
> > On Thu, Feb 15, 2001 at 03:59:54PM -0800, Hong Zhang wrote:
> > > The concept of characters have nothing to do with codepoints.
> > > Many characters are composed by more than one codepoints.
> >
> > This isn't true.
>
> What do you
Simon Cozens wrote:
> On Thu, Feb 15, 2001 at 03:59:54PM -0800, Hong Zhang wrote:
> > The concept of characters have nothing to do with codepoints.
> > Many characters are composed by more than one codepoints.
>
> This isn't true.
>
Yes, for UTF-16 it is. For UTF-32 it isn't, but unless you want
On Fri, Feb 16, 2001 at 12:26:43PM +, Simon Cozens wrote:
> On Fri, Feb 16, 2001 at 10:24:51AM -0300, Branden wrote:
> > Yes, for UTF-16 it is. For UTF-32 it isn't
>
> Yes, it damned well is.
I mean, no, it damned well isn't. But you probably guessed that.
> You're confusing "codepoint" wit
On Fri, Feb 16, 2001 at 10:24:51AM -0300, Branden wrote:
> Yes, for UTF-16 it is. For UTF-32 it isn't
Yes, it damned well is.
You're confusing "codepoint" with "number of bytes in representation".
--
I would imagine most of the readers of this group would support abortion
as long as fifty or s
Dan Sugalski wrote:
> At 05:09 PM 2/15/2001 -0800, Hong Zhang wrote:
> >People in Japan/China/Korea have been using multi-byte encoding for
> >long time. I personally have used it for more 10 years. I never feel
> >much of the "pain". Do you think I are using my computer with O(n)
> >while you are
Hai,
as Beatie says byteperl is a standalone application that runs system
independent bytecode generated by O Module and Bmodule backend.
Perl will get another height if it is a success . As larry says perl will
generate C,C++ and Java codes(?)..
I am interested in developing a application tha
On Thu, Feb 15, 2001 at 02:26:10PM -0500, Uri Guttman wrote:
> > "TB" == Tim Bunce <[EMAIL PROTECTED]> writes:
>
> TB> As a part of that the weak reference concept, bolted recently into
> TB> perl5, could be made more central in perl6.
>
> TB> Around 92.769% of the time circular refere
> "TB" == Tim Bunce <[EMAIL PROTECTED]> writes:
TB> On Thu, Feb 15, 2001 at 02:26:10PM -0500, Uri Guttman wrote:
>> > "TB" == Tim Bunce <[EMAIL PROTECTED]> writes:
>>
TB> As a part of that the weak reference concept, bolted recently into
TB> perl5, could be made more central in
Larry has guaranteed that Perl 6 will be built "out of the same source tree"
as Perl 5. This is a major win for us in two areas. Firstly, we can reuse the
information determined by Perl 5's Configure process to help make Perl 6
portable: for instance, I expect we'll still be using the [UI](8|16|32
Is this (these) thread(s) to the point where it is worth spinning off a new
sublist? If a couple of the main contributors (Dan, Simon, Branden, etc)
say yes, can we get perl6-internals-gc created?
-spp
On Fri, Feb 16, 2001 at 02:54:04PM -0500, Stephen P. Potter wrote:
> Is this (these) thread(s) to the point where it is worth spinning off a new
> sublist? If a couple of the main contributors (Dan, Simon,
Hey, I proudly know *nothing* about GC.
> say yes, can we get perl6-internals-gc created?
> >People in Japan/China/Korea have been using multi-byte encoding for
> >long time. I personally have used it for more 10 years. I never feel
> >much of the "pain". Do you think I are using my computer with O(n)
> >while you are using it with O(1)? There are 100 million people using
> >variable-l
> > What do you mean? Have you seen people using multi-byte encoding
> > in Japan/China/Korea?
>
> You're talking to the wrong person. Japanese data handling is my graduate
> dissertation. :)
>
> The Unified Hangul/Kanji/Ha'nzi' Characters in Unicode (so-called
"Unihan")
> occupy one and only one
On Fri, Feb 16, 2001 at 12:32:10PM -0800, Hong Zhang wrote:
> Did it buy you much? I don't believe so. Can you give some examples why
> random character access is so important?
substr's already been mentioned.
Regular expressions. Perl does rather a lot of them. We've already found from
Perl 5 d
On Friday 16 February 2001 15:35, Simon Cozens wrote:
> On Fri, Feb 16, 2001 at 12:32:10PM -0800, Hong Zhang wrote:
> > Did it buy you much? I don't believe so. Can you give some examples why
> > random character access is so important?
>
> substr's already been mentioned.
>
> Regular expression
On Friday 16 February 2001 14:55, Simon Cozens wrote:
> Secondly and more importantly, it guarantees that we've got a copy of
Perl on
> hand before Perl 6 is built. This allows us to reduce the level of
> preprocessor muddling by effectively generating the C source to Perl 6
from
> templates and
At 12:32 PM 2/16/2001 -0800, Hong Zhang wrote:
> > > What do you mean? Have you seen people using multi-byte encoding
> > > in Japan/China/Korea?
> >
> > You're talking to the wrong person. Japanese data handling is my graduate
> > dissertation. :)
> >
> > The Unified Hangul/Kanji/Ha'nzi' Characte
At 12:20 PM 2/16/2001 -0800, Hong Zhang wrote:
> > >People in Japan/China/Korea have been using multi-byte encoding for
> > >long time. I personally have used it for more 10 years. I never feel
> > >much of the "pain". Do you think I are using my computer with O(n)
> > >while you are using it with
On Fri, Feb 16, 2001 at 07:55:10PM +, Simon Cozens wrote:
> Secondly and more importantly, it guarantees that we've got a copy of Perl on
> hand before Perl 6 is built. This allows us to reduce the level of
> preprocessor muddling by effectively generating the C source to Perl 6 from
> templa
On Fri, Feb 16, 2001 at 08:52:03PM +, Nicholas Clark wrote:
> macro languages and symbolic debuggers don't mix well.
Generated output would be Real Life C. I'm thinking something along the lines
of
perl vtable.pl < vtable.spec > vtable.c
which would work just fine with symbolic debuggers
On Fri, 16 Feb 2001, Simon Cozens wrote:
> On Fri, Feb 16, 2001 at 08:52:03PM +, Nicholas Clark wrote:
> > macro languages and symbolic debuggers don't mix well.
>
> Generated output would be Real Life C. I'm thinking something along the lines
> of
> perl vtable.pl < vtable.spec > vtable.
> substr's already been mentioned.
I have already given the counter argument. The codepoint position is useless
in many cases. They should be deprecated.
> Regular expressions. Perl does rather a lot of them. We've already found
from
> Perl 5 development that they get nasty when variable length
> And address arithmetic and mem(cmp|cpy) is faster than array iteration.
Ha Ha Ha. You must be kidding.
The mem(cmp|cpy) work just fine on UTF-8 string comparison and copy.
But the memcmp() can not be used for UTF-32 string comparison, because
of endian issue.
Hong
> Then you would be incorrect. To find the character at position 233253 in a
> variable-length encoding requires scanning the string from the beginning,
> and has a rather significant potential cost. You've got a test for every
> character up to that point with a potential branch or two on each on
On Fri, Feb 16, 2001 at 04:00:05PM -0500, Sam Tregar wrote:
> I think he meant that using a symbolic debugger is hard, not that it
> wouldn't work. After all, when GDB is tell you that:
>(*fooz).blazt[10].mark[0]->set(fungle(10));
> Is causing a seg fault and all you wrote was:
>$fooz->se
> >Did it buy you much? I don't believe so. Can you give some examples why
> >random character access is so important? Most people are processing text
> >linearly.
>
> Most, but not all. And as this is the internals list, we have to deal with
> all. We can't choose a convenient subset and ignore t
On Friday 16 February 2001 16:20, Hong Zhang wrote:
> > And address arithmetic and mem(cmp|cpy) is faster than array iteration.
>
> Ha Ha Ha. You must be kidding.
>
> The mem(cmp|cpy) work just fine on UTF-8 string comparison and copy.
> But the memcmp() can not be used for UTF-32 string compari
On Fri, 16 Feb 2001, Simon Cozens wrote:
> Larry has guaranteed that Perl 6 will be built "out of the same source tree"
> as Perl 5. This is a major win for us in two areas. Firstly, we can reuse the
> information determined by Perl 5's Configure process to help make Perl 6
> portable:
> Second
At 06:47 PM 2/16/2001 -0800, Hong Zhang wrote:
>I like to wrap up my argument.
>
>I recommend to use UTF-8 as the sole string encoding.
>If we end up with multiple encodings, there is absolutely
>no point for this argument.
Um, I hate to point this out, but perl isn't going to have a single strin
I like to wrap up my argument.
I recommend to use UTF-8 as the sole string encoding.
If we end up with multiple encodings, there is absolutely
no point for this argument.
Benefits of UTF-8 is more compact, less encoding conversion,
more friendly to C API. UTF-16 is variable length encoding
too,
At 09:30 PM 2/16/2001 +, Simon Cozens wrote:
>The real benefit would be that the Perl program would know about all the
>methods and be able to automatically construct the vtable definitions and
>the relevant enum's, and that all the system-specific crap wouldn't show
>up in the generated C fi
33 matches
Mail list logo
