Damien Neil wrote:
> Using object lifetime to control state is almost never a good idea,
> even if you have deterministic finalization. A much better approach
> is to have methods which allow holders of the object to control it,
> and a finalizer (DESTROY method) which cleans up only if necessary
Hong Zhang
> > A deterministic finalization means we shouldn't need to force
programmers
> > to have good ideas. Make it easy, remember? :)
>
> I don't believe such an algorithm exists, unless you stick with reference
> count.
>
Either doesn't exist, or is more expensive than refcounting. I guess
On Thu, Feb 15, 2001 at 08:21:03AM -0300, Branden wrote:
> Hong Zhang
> > > A deterministic finalization means we shouldn't need to force
> programmers
> > > to have good ideas. Make it easy, remember? :)
> >
> > I don't believe such an algorithm exists, unless you stick with reference
> > count.
Tim Bunce wrote:
> On Thu, Feb 15, 2001 at 08:21:03AM -0300, Branden wrote:
> > And don't forget that if we stick with refcounting, we should try to
find a
> > way to break circular references, too.
>
> As a part of that the weak reference concept, bolted recently into perl5,
> could be made more
- Forwarded message from [EMAIL PROTECTED] -
Date: Wed, 14 Feb 2001 20:13:17 -0600
From: [EMAIL PROTECTED]
Subject: perl6 not stagnant
To: [EMAIL PROTECTED]
X-Real-To: <[EMAIL PROTECTED]>
X-Mailer: Mozilla 4.76 (Macintosh; U; PPC)
X-Accept-Language: English,en
perhaps another way perl6 c
On Tue, 13 Feb 2001 11:35:16 -0800, Glenn Linderman wrote:
>In the perl 5 pocket reference 3rd edition page 63, it claims that $@ is
>set to the result of an eval or do. How does this impact exception
>handling tests on $@ to determine if an exception was thrown, if $@ can
>be set by a do ? OR
Bart Lateur wrote:
>
> No, it's a misunderstanding between you and Tony. The "do" your
> reference is talking about, is of the form
>
> do FILE
>
> where file is a string containing a filename, while Tony is talking
> about the
>
> do BLOCK
>
> form. do FILE behaves just like eval() (except it rea
On Wed, Feb 14, 2001 at 10:58:57PM -0500, Steve Simmons wrote:
> > > Note that it may not be possible to satisfy conflicting requests. If
> > > module C and module C demand two different versions of the same
> > > module C, the compiler should halt and state the module conflicts.
> >
> > Pardon
With Perl 6, it will (probably) be possible to have values with boolean
value independent of integer or string values, so that it will be possible
to have a value that when viewed as string or number will be "" or 0, but
will evaluate as true in a condition.
I think this should be applied to the
Paul Johnson wrote:
> > > > Note that it may not be possible to satisfy conflicting requests.
If
> > > > module C and module C demand two different versions of the
same
> > > > module C, the compiler should halt and state the module
conflicts.
> > >
> > > Pardon me for sniping at a great RFC, but
On Thu, Feb 15, 2001 at 10:43:38AM -0300, Branden wrote:
> Paul Johnson wrote:
> >
> > Has anyone considered the problems associated with XS code, or whatever
> > its replacement is?
> >
>
> The big problem about having more than one version of a module loaded at the
> same time is with namespace
Branden wrote:
>
> I think this should be applied to the `defined' function,
Oh, no, here we go again. Branden, why do you insist on dredging
up every contentious issue which has already been beaten to death?
Maybe you need to read the archives first.
--
John Porter
You can't keep Perl6 Pe
On Thu, Feb 15, 2001 at 09:57:13AM -0500, Kirrily Skud Robert wrote:
> Would anyone like to volunteer to do weekly summaries
Well, don't forget that I *do* have people helping me out with the weekly
summaries. I don't know how people want to play this. Do you want:
* One weekly summary of e
On Sun, Feb 11, 2001 at 07:13:30PM -0500, Adam Turoff wrote:
> On Sun, Feb 11, 2001 at 05:03:12PM +, Simon Cozens wrote:
> > There's obvious FUD out there and we don't seem to be giving the impression of
> > getting much done, or doing anything to counter it.
>
> Let's be fair. We're not ge
As many of you may know, I've recently moved to the other side of the
world, and my life's a bit hectic. I hadn't counted on p6-l bursting
into life just now, and while I'd like to keep right up to date with it
I really can't guarantee daily reading.
Would anyone like to volunteer to do weekly s
First of all, sorry to bother you again with this issue, but I guess it
didn't have the appropriate discussion. If you're not interested, please
don't read further...
I wrote:
> I expect Perl 6 will have some way to define its variables as being
> lexical-scoped in the sub they are used as defa
On Thu, 15 Feb 2001 15:23:52 +, Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 15, 2001 at 09:57:13AM -0500, Kirrily Skud Robert wrote:
> > Would anyone like to volunteer to do weekly summaries
>
> Well, don't forget that I *do* have people helping me out with the weekly
> summaries.
On Thu, Feb 15, 2001 at 01:40:53PM -0300, Branden wrote:
> I propose the introduction of two new keywords (just like `my' and `our')
> for specifying a different scope: `global' and `outer'. `global' would be
> used to say that a specific variable or a list of them would refer to the
> global vari
Jonathan Scott Duff wrote:
> On Thu, Feb 15, 2001 at 01:40:53PM -0300, Branden wrote:
> > I propose the introduction of two new keywords (just like `my' and
`our')
> > for specifying a different scope: `global' and `outer'. `global' would
be
> > used to say that a specific variable or a list of th
On Sun, 11 Feb 2001 22:44:38 +, Simon Cozens <[EMAIL PROTECTED]> wrote:
> I was being serious. But first, a plea:
>
> This is much harder than doing the Perl 5 summaries, because I have to
> watch over a lot more things. I'd appreciate some help; if you feel this
> is a useful exercise and yo
On Thu, Feb 15, 2001 at 04:46:08PM +0100, H.Merijn Brand wrote:
> Would it be possible to make this summary subsribable, so I can drop my
> subscribtions to p6-internal?
To you, and to everyone else who has asked, yes. I'm working on setting
up a list right now, hosted at netthink. It's currently
At 09:23 AM 2/15/2001, Simon Cozens wrote:
>On Thu, Feb 15, 2001 at 09:57:13AM -0500, Kirrily Skud Robert wrote:
> > Would anyone like to volunteer to do weekly summaries
>
>Well, don't forget that I *do* have people helping me out with the weekly
>summaries. I don't know how people want to play t
Sorry, I didn't make myself clear on the "mailing list organization" bit.
What the job really is, someone to spot out-of-control threads (for
instance, the "par" discussion on perl6-language), split off a new
mailing list for it (by requesting from Ask), appointing a chair
(probably the person wh
On Thu, 15 Feb 2001, Simon Cozens wrote:
[...]
> To you, and to everyone else who has asked, yes. I'm working on setting
> up a list right now, hosted at netthink. It's currently subscribable, but
> there are some teething problems with posting. (Which needn't concern you,
> except that if you s
On Thu, Feb 15, 2001 at 10:11:33AM -0800, Ask Bjoern Hansen wrote:
> > [EMAIL PROTECTED] is the magic address;
>
> -digest has a specific meaning with many mailing list managers. I
> would suggest calling it perl6-summaries or such to avoid confusion.
Yuh, I thought of that the second after tell
Branden wrote:
>
> Take PHP and Python, for example.
O.k., that's two out of the three modern languages.
That's "most". Sorry, I stand corrected.
> > Silly beginner gotchas. It's not an inconsistency of the
> > language by any means.
>
> Yeah. Beginners. I was one too. And I remember always
> Take PHP and Python, for example.
>
>
> > > my $a, $b, $c;# only $a is lexically scoped
> > RTFM.
> > > my ($a) = ; # after deducing (by the above) . . .
> > > # when I wanted only the first line.
> > Silly beginner gotchas. It's not an i
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:38 PM 2/15/2001 -0300, Branden wrote:
>
> >Yeah. Beginners. I was one too. And I remember always falling on
these...
> >But that's OK, since we probably don't want any new Perl
programmers...
>
> I've skipped pretty much all this thread so fa
Branden wrote:
>
> Well, I checked the archives, and I found that the discussion begun in
> http:[EMAIL PROTECTED]/msg01441.html
That thread was rather tame; even so, I believe the end result,
if one can be deduced, is that the proposal is not a good one.
There was more heated discussion in th
John Porter wrote:
> > Well, first let me say why I think a way (pragma) to do lexical-scope by
> > default (for one file/block/scope) would be good. Most (modern)
languages do
> > it
> This is false. Even languages in which lexical variables are the
> norm still require a variable declaration; i
At 01:15 PM 2/15/01 -0500, John Porter wrote:
> > my $a, $b, $c;# only $a is lexically scoped
>
>RTFM.
Quite. But on a tangent, I see no good reason why this shouldn't be given
the same interpretation as "my ($a, $b, $c)" on the grounds that functions
taking list arguments that
At 04:38 PM 2/15/2001 -0300, Branden wrote:
>Yeah. Beginners. I was one too. And I remember always falling on these...
>But that's OK, since we probably don't want any new Perl programmers...
I've skipped pretty much all this thread so far, but I do need to point out
that perl isn't targeted at
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:
chiefly to get a feel for how it needs to handle all the various
permutations, like whether the destination pmc is trashable etc.
Could you Wise Ones tell me whethe
On Thu, Feb 15, 2001 at 08:07:39AM -0300, Branden wrote:
> I think you just said all about why we shouldn't bother giving objects
> deterministic finalization, and I agree with you. If we explicitly want to
> free resources (files, database connections), then we explicitly call close.
> Otherwise,
Damien Neil wrote:
> On Thu, Feb 15, 2001 at 08:07:39AM -0300, Branden wrote:
> > I think you just said all about why we shouldn't bother giving objects
> > deterministic finalization, and I agree with you. If we explicitly want
to
> > free resources (files, database connections), then we explicit
> "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 to be
TB> circular by the code that creates them (like a
> "Peter" == Peter Scott <[EMAIL PROTECTED]> writes:
Peter> Quite. But on a tangent, I see no good reason why this shouldn't be
Peter> given the same interpretation as "my ($a, $b, $c)" on the grounds that
Peter> functions taking list arguments that omit their parentheses swallow up
Peter> t
Branden wrote:
>
> > If you had this 'use scope' pragma, this auto-error checking would be
> > compromised severely.
>
> Actually, I think sometimes it can be done with -w (``Variable xyz used only
> once, probably spelling error'').
Except that only applies to un-declared variables, which curr
John Porter wrote:
> Branden wrote:
> >
> > Well, I checked the archives, and I found that the discussion begun in
> > http:[EMAIL PROTECTED]/msg01441.html
>
> That thread was rather tame; even so, I believe the end result,
> if one can be deduced, is that the proposal is not a good one.
>
> There
On Thu, Feb 15, 2001 at 10:31:34AM -0300, Branden wrote:
> With Perl 6, it will (probably) be possible to have values with boolean
> value independent of integer or string values, so that it will be possible
> to have a value that when viewed as string or number will be "" or 0, but
> will evaluat
<[EMAIL PROTECTED]> wrote:
> On Thu, Feb 15, 2001 at 10:04:51AM -0300, Branden wrote:
> > Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
> > little too much not-orthogonal? Why don't we require `eval { do FILE }'
to
> > have the behaviour of not dying and setting $@ ?
>
>
Peter Scott wrote:
>
> At 01:15 PM 2/15/01 -0500, John Porter wrote:
> > > my $a, $b, $c;# only $a is lexically scoped
>
> Quite. But on a tangent, I see no good reason why this shouldn't be given
> the same interpretation as "my ($a, $b, $c)" on the grounds that functions
> tak
At 11:49 AM 2/15/01 -0800, Randal L. Schwartz wrote:
> > "Peter" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>Peter> Quite. But on a tangent, I see no good reason why this shouldn't be
>Peter> given the same interpretation as "my ($a, $b, $c)" on the grounds that
>Peter> functions taking lis
On Thu, Feb 15, 2001 at 11:08:47AM -0800, Edward Peschko wrote:
>
> However, that still doesn't get rid of the gotchas - personally I think that:
>
> my $a, $b, $c;
>
> should be an error, a warning, or DWIM. Especially:
Personally, I don't think so.
GetOptions (foo => \my $foo,
On Thu, Feb 15, 2001 at 11:49:44AM -0800, Randal L. Schwartz wrote:
> > "Peter" == Peter Scott <[EMAIL PROTECTED]> writes:
>
> Peter> Quite. But on a tangent, I see no good reason why this shouldn't be
> Peter> given the same interpretation as "my ($a, $b, $c)" on the grounds that
> Peter> f
On Thu, Feb 15, 2001 at 11:23:10AM -0800, Nathan Wiger wrote:
>
> I agree with this statement. Perhaps someone who was around during the
> initial 'my' discussions can shed some light on why it binds so tightly.
> I have observed you can do something like this:
>
>my $OUTER = '';
>
>if
On Thu, Feb 15, 2001 at 02:47:55PM -0500, Steve Simmons wrote:
> Paul Johnson wrote:
>
> > Has anyone considered the problems associated with XS code, or whatever
> > its replacement is?
>
> Pardon my ignorance, but what's XS code?
perldoc perlxs
perldoc perlxstut
I don't think any proposal of
On Thu, Feb 15, 2001 at 10:44:24AM -0800, Peter Scott wrote:
>
> Quite. But on a tangent, I see no good reason why this shouldn't be given
> the same interpretation as "my ($a, $b, $c)" on the grounds that functions
> taking list arguments that omit their parentheses swallow up the following
On Thu, Feb 15, 2001 at 09:05:55PM +0100, [EMAIL PROTECTED] wrote:
> On Thu, Feb 15, 2001 at 11:23:10AM -0800, Nathan Wiger wrote:
> > But I have never found a situation where this is so useful to justify
> > the other problems it creates. However, there may well be true technical
> > reasons why
On Thu, Feb 15, 2001 at 05:58:34PM -0300, Branden wrote:
> <[EMAIL PROTECTED]> wrote:
> > On Thu, Feb 15, 2001 at 10:04:51AM -0300, Branden wrote:
> > > Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
> > > little too much not-orthogonal? Why don't we require `eval { do FIL
Edward Peschko wrote:
> > Tell me one. I couldn't find it.
>
> The main problem I see is cross checking. I *like* having to declare
things as
> 'my' - it catches my errors for me:
>
> my $variable;
> $varaible = 1; # mis-spelled - caught by 'use strict'.
>
Still would be able to do it with `use s
On Thu, Feb 15, 2001 at 10:04:51AM -0300, Branden wrote:
> Bart Lateur wrote:
> >
> > No, it's a misunderstanding between you and Tony. The "do" your
> > reference is talking about, is of the form
> >
> > do FILE
> >
> > where file is a string containing a filename, while Tony is talking
> > about
Paul Johnson wrote:
> Has anyone considered the problems associated with XS code, or whatever
> its replacement is?
Pardon my ignorance, but what's XS code?
Branden wrote:
> Just set autoflush, if you're lazy...
And say goodbye to performance...
> > The problem is
> > that you can not only count on $fh's DESTROY being called at the end of
> > the block, you often can't count on it ever happening.
>
> Anyway, the file would be flushed and closed...
> {
> my $fh = IO::File->new("file");
> print $fh "foo\n";
> }
> {
> my $fh = IO::File->new("file");
> print $fh "bar\n";
> }
>
> At present "file" will contain "foo\nbar\n". Without DF it could just
> as well be "bar\nfoo\n". Make no mistake, this is a major change to t
On Thu, Feb 15, 2001 at 02:40:52PM -0600, Jonathan Scott Duff wrote:
> On Thu, Feb 15, 2001 at 12:25:44PM -0800, Edward Peschko wrote:
> > well, I was thinking about this - there really should be an extra switch that
> > makes this possible, rather than typing 'no strict; no warn;' ie:
> >
> > #!
At 12:43 PM 2/15/01 -0800, Edward Peschko wrote:
>On Thu, Feb 15, 2001 at 02:40:52PM -0600, Jonathan Scott Duff wrote:
> > On Thu, Feb 15, 2001 at 12:25:44PM -0800, Edward Peschko wrote:
> > > well, I was thinking about this - there really should be an extra
> switch that
> > > makes this possibl
On Thu, Feb 15, 2001 at 05:58:34PM -0300, Branden wrote:
> > I find a "let's require some extra hoops and red tape" not very-Perl like.
> > Perl is there for the programmer; not the other way around.
>
> Please read ``Larry's talk in Atlanta about Perl 6'', the text is in
> http://dev.perl.org/~a
> >And in any case, make '-e' have the additional connotation that implies
> >'no strict', and 'no warn'.
>
> no 'warnings'
thanks. 'no warnings'
> > Seems simple enough to me.
> Yes, that's what I thought; but this has generated more heat than light, at
> least on the times I've brought it
At 01:03 PM 2/15/01 -0800, Edward Peschko wrote:
> > http:[EMAIL PROTECTED]/msg00025.html
>
>Well, I agree with pretty much everything you said, except I like '-q' better
>than '-z' for aesthetic reasons.
>
>So... what was the rationale against it?
Best read the archives... I am the wrong person
> Still would be able to do it with `use strict'. My proposal isn't going to
> replace it! As it didn't replace the default global variables! As I said, I
> don't want you to use it or even like it, I'm only wanting YAWTDI.
Right, but your approach isn't going to help in the cases where it is nee
Peter Scott wrote:
>
> >And in any case, make '-e' have the additional connotation that implies
> >'no strict', and 'no warn'.
>
> no 'warnings'
>
> > Seems simple enough to me.
>
> Yes, that's what I thought; but this has generated more heat than light, at
> least on the times I've brought i
> >So... what was the rationale against it?
>
> Best read the archives... I am the wrong person to ask for a statement of
> the opposing viewpoint...
hey... I'm a lazy guy.. ;-) So - I guess coming from someone who holds the
opposing viewpoint, what was it?
Ed
Branden wrote:
> >
> > There was more heated discussion in the thread rooted at
> > http://www.mail-archive.com/perl6-language@perl.org/msg01089.html
> > the discussion of RFC 16.
>
> Well, actually, I read that, and it pretty much discusses making `strict'
> default or not (which I believe is no
Steve Simmons <[EMAIL PROTECTED]> wrote:
> Paul Johnson wrote:
>
> > Has anyone considered the problems associated with XS code, or
whatever
> > its replacement is?
>
> Pardon my ignorance, but what's XS code?
Simply put (and paraphrastically, so don't nitpick, anyone), XS is using a
funk
On Thu, Feb 15, 2001 at 12:25:44PM -0800, Edward Peschko wrote:
> well, I was thinking about this - there really should be an extra switch that
> makes this possible, rather than typing 'no strict; no warn;' ie:
>
> #!/usr/local/bin/perl -q # for quick and dirty.
We already have a switch that me
Hong Zhang wrote:
> This code should NEVER work, period. People will just ask for trouble
> with this kind of code.
Actually I meant to have specified ">>" as the mode, i.e. append, then
what I originally said holds true. This behaviour is predictable and
dependable in the current perl implemen
> Hong Zhang wrote:
>
> > This code should NEVER work, period. People will just ask for trouble
> > with this kind of code.
>
> Actually I meant to have specified ">>" as the mode, i.e. append, then
> what I originally said holds true. This behaviour is predictable and
> dependable in the curre
On Thu, Feb 15, 2001 at 08:52:01PM +0100, [EMAIL PROTECTED] wrote:
> You mean the beaten-to-death ??, formely known as |||, operator?
>
> It has torn p5p to shreds repeatedly.
Could be worse, could be url open().
duck && cover;
On Thu, Feb 15, 2001 at 08:19:27PM +, Nicholas Clark wrote:
> On Thu, Feb 15, 2001 at 09:05:55PM +0100, [EMAIL PROTECTED] wrote:
> > On Thu, Feb 15, 2001 at 11:23:10AM -0800, Nathan Wiger wrote:
> > > But I have never found a situation where this is so useful to justify
> > > the other problem
Many thanks to all for the pointers.
Paul Johnson wrote:
> I don't think any proposal of this nature would be conplete without a
> consideration of these aspects.
Agreed.
> If I have:
>
> (my $foo1, $bar1) = (my $foo2, $bar2) = ("foo", "bar");
>
> then '(my $foo1, $bar1)' is in void context, while '(my $foo2, $bar2)'
> isn't.
>
> Do you really want them to behave differently?
>
> > best way to shoot down my suggestion is an example where existing behaviour
From: Steve Simmons [mailto:[EMAIL PROTECTED]]
> Paul Johnson wrote:
>
> > Has anyone considered the problems associated with XS
> > code, or whatever its replacement is?
>
> Pardon my ignorance, but what's XS code?
Extra code is. Which knack had you obfuscation
for could left out have been. --
Hong Zhang wrote:
> That was not what I meant. Your code already assume the existence of
> reference counting. It does not work well with any other kind of garbage
> collection. If you translate the same code into C without putting in
> the close(), the code will not work at all.
Wrong, it does
Hi, All,
I want to give some of my thougts about string encoding.
Personally I like the UTF-8 encoding. The solution to the
variable length can be handled by a special (virtual)
function like
class String {
virtual UV iterate(/*inout*/ int* index);
};
So in typical string iteration, the co
> > http://news.bbc.co.uk/hi/english/sci/tech/newsid_1156000/1156212.stm
This nuclear/dynamite stuff is making me sad.
Wanna contribute in the name of perl ?? Lets see... China + UN = $perl_revenue
On Thu, Feb 15, 2001 at 02:03:21PM -0800, Edward Peschko wrote:
> > If I have:
> >
> > (my $foo1, $bar1) = (my $foo2, $bar2) = ("foo", "bar");
> >
> > then '(my $foo1, $bar1)' is in void context, while '(my $foo2, $bar2)'
> > isn't.
> >
> > Do you really want them to behave differently?
> >
[resent to perl6-language, sorry for any duplicates]
Edward Peschko wrote:
>
> > I personally think that this is something Larry is going to have to
> > decide. However, I would like to note that leaving these off by default
> > lowers the transition curve to Perl 6 immensely for those people th
> It was suggested to DWIM when I use my in void context, and not when
> my isn't used in void context. With the above example, such a rule
> would mean '$bar1' is my()ed, and '$bar2' isn't. That's IMO, very hard
> to explain, very hard to bugtrack and totally unexpected. Even if not
> everyone us
On Thu, Feb 15, 2001 at 03:02:10PM -0800, Nathan Wiger wrote:
> If we're interested in increased CPAN quality, there's a bunch of stuff
> we can do.
See also, CPANTS (totally vaporware, but its a plan)
http:[EMAIL PROTECTED]/msg00148.html
> Heck, I'd even volunteer to head up a project to do th
With the help of a couple of volunteers, I'll now be bringing you a
weekly summary of all the important traffic on the Perl 6 mailing lists,
to complement the existing summaries of the perl5-porters list.
Each week, the following things will happen:
1) I'll write the summary on Sunday or
On Thu, Feb 15, 2001 at 03:07:51PM -0800, Edward Peschko wrote:
>
> > Also, if I have:
> >
> > @a = (1 .. 10);
> > $a, $b, $c = @_;
>
> How about 'an implicit parens around a set of statements separated by commas
> in any context'? This is consistent
>
> $a, $b, $c = $d, $e, $f; # ($a,
At 09:01 PM 2/15/01 +0100, [EMAIL PROTECTED] wrote:
>On Thu, Feb 15, 2001 at 11:08:47AM -0800, Edward Peschko wrote:
> > However, that still doesn't get rid of the gotchas - personally I think
> that:
> >
> > my $a, $b, $c;
> >
> > should be an error, a warning, or DWIM. Especially:
>
>Personally
On Thu, Feb 15, 2001 at 10:29:33PM +0100, [EMAIL PROTECTED] wrote:
> On Thu, Feb 15, 2001 at 08:19:27PM +, Nicholas Clark wrote:
> > On Thu, Feb 15, 2001 at 09:05:55PM +0100, [EMAIL PROTECTED] wrote:
> > > On Thu, Feb 15, 2001 at 11:23:10AM -0800, Nathan Wiger wrote:
> > > > But I have never f
On Thu, Feb 15, 2001 at 02:31:03PM -0800, Hong Zhang wrote:
> Personally I like the UTF-8 encoding. The solution to the
> variable length can be handled by a special (virtual)
> function like
I'm expecting that the virtual, internal representation will not
be in a UTF but will simply be an array
> On Thu, Feb 15, 2001 at 02:31:03PM -0800, Hong Zhang wrote:
> > Personally I like the UTF-8 encoding. The solution to the
> > variable length can be handled by a special (virtual)
> > function like
>
> I'm expecting that the virtual, internal representation will not
> be in a UTF but will simpl
On Thu, Feb 15, 2001 at 11:16:29PM +, Simon Cozens wrote:
> On Thu, Feb 15, 2001 at 02:31:03PM -0800, Hong Zhang wrote:
> > Personally I like the UTF-8 encoding. The solution to the
> > variable length can be handled by a special (virtual)
> > function like
>
> I'm expecting that the virtual,
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.
--
* DrForr digs around for a fresh IV drip bag and proceeds to hook up.
Coffee port.
Firewa
On Thu, Feb 15, 2001 at 02:54:37PM -0800, Nathan Wiger wrote:
> Edward Peschko wrote:
> > Right, but what I don't understand is that its two extra characters at the end
> > of a command line... whats the big deal about typing '-q' on one line in
> > scripts? Its easy enough to advertise '-q' and
On Thursday 15 February 2001 19:21, Edward Peschko wrote:
> How many times have I wanted to put 'use strict' in a module and
forgotten
> about it?
Then it isn't, technically, a perl problem.
> How many times have I wanted to use '-w' but was not able to because
> of all the junk that comes ou
Kirrily Skud Robert writes:
> Wasn't he meant to be keeping us up to date with snippets of what he's
> doing/thinking about? I recall Nat posting a couple of months ago that
> he'd talked to Larry and Larry had said he'd do this.
I think the problem is that the RFCs aren't really a list of the
t
> 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 you seen people using multi-byte encoding
in Japan/China/Korea
Alan Burlison wrote:
> I think you'll find that both GC *and* reference counting scheme will
> require the heay use of mutexes in a MT program.
There are several concurrent GC algorithms that don't use
mutexes -- but they usually depend on read or write barriers
which may be really hard for us to
> ...and because of this you can't randomly access the string, you are
> reduced to sequential access (*). And here I thought we could have
> left tape drives to the last millennium.
>
> (*) Yes, of course you could cache your sequential access so you only
> need to do it once, and build balance
> There are several concurrent GC algorithms that don't use
> mutexes -- but they usually depend on read or write barriers
> which may be really hard for us to implement. Making them run
> well always requires help from the OS memory manager and that
> would hurt portability. (If we don't have OS
On Fri, Feb 16, 2001 at 12:32:01AM +0100, [EMAIL PROTECTED] wrote:
> On Thu, Feb 15, 2001 at 03:07:51PM -0800, Edward Peschko wrote:
> >
> > > Also, if I have:
> > >
> > > @a = (1 .. 10);
> > > $a, $b, $c = @_;
> >
> > How about 'an implicit parens around a set of statements separated b
I guess this was what was meant by 'put your asbestos gloves on'.
On Thu, Feb 15, 2001 at 07:57:31PM -0500, Bryan C. Warnock wrote:
> On Thursday 15 February 2001 19:21, Edward Peschko wrote:
> > How many times have I wanted to put 'use strict' in a module and
> forgotten
> > about it?
>
> T
Damien Neil wrote:
DN> {
DN>my $fh = IO::File->new("file");
DN>do_stuff($fh);
DN> }
DN>
DN> sub do_stuff { ... }
Simon Cozens wrote:
SC> No, it can't, but it can certainly put a *test* for not having
SC> references there.
Dan Sugalski wrote:
DS> Yes it can tell, actually--we do have the
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
argument math ops. Instead of dst->add(a
Hong Zhang wrote:
> The memory barriers are always needed on SMP, whatever algorithm
> we are using.
I was just pointing out that barriers are an alternative to mutexes.
Ref count certainly would use mutexes instead of barriers.
> The memory barrier can be easily coded in assembly, or intrinsic
1 - 100 of 108 matches
Mail list logo
