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 having one
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 leave
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 mean? Have
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 to read
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" with
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
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 using
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
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 references are known
"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 perl6.
TB
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
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-length
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 codepoint
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
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 expressions. Perl
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' Characters in Unicode
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.c
which
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
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-set(10);
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 the rest.
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 string
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
26 matches
Mail list logo
