Having no time to write and/or maintain RFC's, I'll toss this up in the air
and see what happens.
Abigail has posted sorting benchmarks for 5.6.0 to 5.7.0 on clp.misc, and I've
extended that being curious to performance loss for anonymous blocks and named
subroutines
sub Xcmp { $a cmp $b
Dan Sugalski wrote:
> At 12:14 AM 9/6/00 -0400, Bradley M. Kuhn wrote:
> >Dan Sugalski wrote:
> > > The decisions should be based on technical merit and general availability.
> >
> >I would include "available under a free software license" as part of the
> >definition of "general availability".
On Wed, 6 Sep 2000 22:58:05 -0400, John Porter wrote:
> keys %hash = @things;
>
>is defined as being equivalent to
>
> @hash{ @things } = ();
>
>This is to support hash-based set operations in a more
>natural way, i.e.
>
> keys %hash = grep { exists $a{$_} } keys %b;
I have dou
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Everything in Perl becomes an object.
=head1 VERSION
Maintainer: Matt Youell <[EMAIL PROTECTED]>
Date: 25 Aug 2000
Last Updated: 7 Sep 2000
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Lightweight Threads
=head1 VERSION
Maintainer: Steven McDougall <[EMAIL PROTECTED]>
Date: 30 Aug 2000
Last Modified: 7 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 178
Version: 3
Status: D
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects: Revamp tie to support extensibility (Massive tie changes)
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 07 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Num
On 06 Sep 2000 18:04:18 -0700, Randal L. Schwartz wrote:
>I think the -1 indexing for "end of array" came from there. Or at
>least, it was in Perl long before it was in Python, and it was in Icon
>before it was in Perl, so I had always presumed Larry had seen Icon.
>Larry?
Do not assume that th
Chaim Frenkel wrote:
> UG> i don't see how you can do atomic ops easily. assuming interpreter
> UG> threads as the model, an interpreter could run in the middle of another
> UG> and corrupt it. most perl ops do too much work for any easy way to make
> UG> them atomic without explicit locks/mutexe
Alan Burlison <[EMAIL PROTECTED]> writes:
>Jarkko Hietaniemi wrote:
>
>> Multithreaded programming is hard and for a given program the only
>> person truly knowing how to keep the data consistent and threads not
>> strangling each other is the programmer. Perl shouldn't try to be too
>> helpful a
Alan Burlison <[EMAIL PROTECTED]> writes:
>
>Another good reason for having separate interpreter instances for each
>thread is it will allow people to write non-threaded modules that can
>still be safely used inside a threaded program. Let's not forget that
>the overwhelming bulk of CPAN modules
On Wed, 06 Sep 2000 11:23:37 -0400, Dan Sugalski wrote:
>>Here's some high-level emulation of what it should do.
>>
>> eval {
>> my($_a, $_b, $c) = ($a, $b, $c);
>> ...
>> ($a, $b, $c) = ($_a, $_b, $_c);
>> }
>
>Nope. That doesn't ge
Nick Ing-Simmons wrote:
> >Another good reason for having separate interpreter instances for each
> >thread is it will allow people to write non-threaded modules that can
> >still be safely used inside a threaded program. Let's not forget that
> >the overwhelming bulk of CPAN modules will probab
Adam Turoff wrote:
> On Wed, Sep 06, 2000 at 12:14:17AM -0400, Bradley M. Kuhn wrote:
> > Dan Sugalski wrote:
> > > The decisions should be based on technical merit and general availability.
> >
> > I would include "available under a free software license" as part of the
> > definition of "genera
2000-09-05-10:53:25 Dan Sugalski:
> >I don't think it's a good idea to build Perl6 development
> >infrastructure around non-free software.
>
> I don't think we should make decisions about the software we use
> for development based on political views. The decisions should be
> based on technical
Nick Ing-Simmons wrote:
> The tricky bit i.e. the _design_ - is to separate the op-ness from the
> var-ness. I assume that there is something akin to hv_fetch_ent() which
> takes a flag to say - by the way this is going to be stored ...
I'm not entirely clear on what you mean here - is it someth
The phrase "die a horrible death" clearly reads that something was
a bletcherous botch--a terribly brain-damaged mistake, if you
would--and so must necessarily be expurgated from the language.
For example, when Larry said, "...this does not mean that some of
us should not want, in a rather dispas
On Wed, 6 Sep 2000 16:24:41 -0500 , Garrett Goebel wrote:
>> > grep { $a > $_ and last } @b)
>>
>> So "last" should return true, or what?
>
>The last operator doesn't return anything does it? It immediately exits the
>loop/block in question.
But then, what is the value that would be retur
"Myers, Dirk" wrote:
> $mode = 0755 ;
> $file = "Foobar" ;
>
> #include
> #include
>
> chmod($mode, $file) ;
>
> Which chmod gets called, perl or C? What are the rules for figuring this
> out?
>
> Dirk
Following the documentation at
http://www.pe
From: Bart Lateur [mailto:[EMAIL PROTECTED]]
>
> On Wed, 6 Sep 2000 16:24:41 -0500 , Garrett Goebel wrote:
> >> > grep { $a > $_ and last } @b)
> >>
> >> So "last" should return true, or what?
> >
> >The last operator doesn't return anything does it? It
> >immediately exits the loop/block
Garrett Goebel wrote:
>
> Let's see if I've got this straight. To paraphrase Damian's
> RFC 77 for reduce:
>
> If a C's block were terminated by a call to C,
> grep immediately returns the last block value (i.e. C
> on the first block call, $_[0] otherwise). Or maybe that's @_
> otherwise...
Michael G Schwern wrote:
>
> On Sun, Sep 03, 2000 at 09:05:07PM -0700, Russ Allbery wrote:
> > I also think this may well be a good place to apply one of the ideas of XP
> > (Extreme Programming, a fairly flexible small-group software design
> > methodology), namely to write test cases *first* in
Bart wrote:
> >The last operator doesn't return anything does it? It immediately
> >exits the loop/block in question.
This is correct.
> But then, what is the value that would be returned to grep()? If you use
> 0 as the last value evaluated inside the block, grep() would return an
John wrote:
> > I don't know how grep works internally. I don't know if grep pushes
> > elements into @a one at a time, or if it returns a finished list of
> > elements which pass the conditional block. If it is the latter as I
> > assume, a short-circuited grep would return a list o
On Fri, 8 Sep 2000 05:59:02 +1100 (EST), Damian Conway wrote:
>But it makes "short-circuit as soon as C
>lets through a specific value" ugly:
>
>my $seen;
>$has_odd_elem = grep { $seen && last; $_%2 && ++$seen } @numbers;
Not just ugly. Useless.
--
Bart.
On Thu, Sep 07, 2000 at 10:05:58PM +0200, Bart Lateur wrote:
> On Fri, 8 Sep 2000 05:59:02 +1100 (EST), Damian Conway wrote:
>
> >But it makes "short-circuit as soon as C
> >lets through a specific value" ugly:
> >
> >my $seen;
> >$has_odd_elem = grep { $seen && last; $_%2 && ++$s
John Porter wrote:
>
> David L. Nicol wrote:
> >
> > A bareword inside doublequotes is not interpreted, in Perl or C.
>
> No; a "bareword" in quotes (any kind) is not a bareword.
>
> --
> John Porter
huh?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Garrett wrote:
> It almost feels like grep could have been written like this (in
> another life): @a = grep (@b) { $_ > 2 or last }
http://www.csse.monash.edu.au/~damian/TPC/2000/Romana/perligata.html
;-)
> While I'm at it, I'm curious as to why:
>
> $a = 2;
> @b = (1,
On Thu, Sep 07, 2000 at 03:42:01PM -0400, Eric Roode wrote:
> Richard Proctor wrote:
> >
> >I think what is needed is something along the line of :
> >
> > $re = qz{ '(' \$re ')'
> >| \$re \$re
> >| [^()]+
> > };
> >
> >Where qz is
> I think what is needed is something along the line of :
Joe McMahon and I are working on something along these lines.
- Original Message -
From: "Jonathan Scott Duff" <[EMAIL PROTECTED]>
Subject: Re: XML/HTML-specific ?< and ?> operators? (was Re: RFC 145
(alternate approach))
> How about qy() for Quote Yacc :-) This stuff is starting to look
> more and more like we're trying to fold lex and yacc int
Bart Lateur wrote:
>
> On 06 Sep 2000 18:04:18 -0700, Randal L. Schwartz wrote:
>
> >I think the -1 indexing for "end of array" came from there. Or at
> >least, it was in Perl long before it was in Python, and it was in Icon
> >before it was in Perl, so I had always presumed Larry had seen Icon
On Wed 06 Sep, Mark-Jason Dominus wrote:
>
> I've been thinking the same thing. It seems to me that the attempts to
> shoehorn parsers into regex syntax have either been unsuccessful
> (yielding an underpowered extension) or illegible or both.
>
>SNOBOL:
> parenstring = '(' *parenstrin
Richard Proctor wrote:
>
>I think what is needed is something along the line of :
>
> $re = qz{ '(' \$re ')'
>| \$re \$re
>| [^()]+
> };
>
>Where qz is some hypothetical new quoting syntax
Well, we currently have qr{}, and ??{} do
On Thu, Sep 07, 2000 at 08:20:42PM +0100, Richard Proctor wrote:
> I think what is needed is something along the line of :
>
>$re = qz{ '(' \$re ')'
> | \$re \$re
> | [^()]+
>};
>
> Where qz is some hypothetical new quoting s
> What would be useful, would be to leave REs the hell alone; they're
> great as-is, and are only getting hairier and hairier.
Amen!
> What would be useful, would be to create a new non-regular
> pattern-matching/parsing "language" within Perl, that combines
> the best of Perl
Bennett Todd wrote:
> So I ask again: do any _other_ projects,
> preferably ones that aren't regarded as procedural failures that
> need re-inventing from scratch, used perforce? Or is perl5, whose
> failure has brought us out today, its one poster project?
I think reports of perl5's death have
I found the following reference in the p5p archives to a paper
discussing open source development. I think this should be mandatory
reading for anyone contemplating a contribution to the RFC mountain.
http://www.firstmonday.dk/issues/issue4_10/bezroukov/index.html
Alan Burlison
At 11:49 AM 9/7/00 -0400, Bennett Todd wrote:
>2000-09-06-10:51:35 Dan Sugalski:
> > >Finally, most free software and open source projects have
> > >standardized on CVS. Do we really have a compelling reason to go
> > >against the standard?
> >
> > Perl 5 uses perforce, [...]
>
>I thought one of t
2000-09-07-17:11:50 Dan Sugalski:
> Perl 5's development issues have nothing to do with the code
> repository -- [...]
That's certainly possible, but since the reason we're gathered here
together working on trying to launch perl6 is a collective belief
that perl5 has become unmaintainable for fu
Bennett,
Perforce is a better source code control system than the source
alternatives, and certainly better for the task we face than CVS.
You're certainly not forced to use it. You can, if you rather, grab
snapshot archives, rsync from the repository directory, or even grab a copy
of the sou
In message <[EMAIL PROTECTED]>
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> > "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
>
> TH> Well if we allow value changes in the middle of iterating either
> TH> keys or values then that is a user visible behaviour change which
> TH> potential
Chaim Frenkel wrote:
> I'd like to make the easy things easy. By making _all_ shared variables
> require a user level lock makes the code cluttered. In some (I think)
> large percentage of cases, a single variable or queue will be use to
> communicate between threads. Why not make it easy for the
Chaim Frenkel wrote:
> I don't see where you are differing from me.
>
> And different interpreters doesn't completely isolate threads from each
> other. You are simply giving each thread its own work/scratch area.
> With the internals rewrite it may not need to be a full interpreter.
I think th
Chaim Frenkel wrote:
> AB> I'm sorry, but you are wrong. You are confusing transactions with
> AB> threading, and the two are fundamentally different. Transactions are
> AB> just a way of saying 'I want to see all of these changes, or none of
> AB> them'. You can do this even in a non-threaded
> "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
>> The only real issue is if the change effects the iterator order. Changes
>> to values should be allowed without out any adverse effects.
TH> Well if we allow value changes in the middle of iterating either
TH> keys or values then that is a
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
AB> Chaim Frenkel wrote:
>> The problem I have with this plan, is reconciling the fact that a
>> database update does all of this and more. And how to do it is a known
>> problem, its been developed over and over again.
AB> I'm sorry, but y
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
>> Perl will have to do atomic operations, if for no other reason than to
>> keep from core dumping and maintaining sane states.
AB> I don't see that this is necessarily true. The best suggestion I have
AB> seen so far is to have each thre
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
AB> The problem with saying that perl should ensure that the operation "$a =
AB> $a + $b" is atomic is that it is an unbounded problem. When should $a
AB> be automatically locked and unlocked? At the beginning and end of the
AB> += op? at
> I would propose that the C operation should short-circuit if the
> block throws an exception, with the value of the expection determining
> whether the final invocation of the block should accept the element it
> was filtering:
Otherwise nice but until now die() has been a serious thing, now it
> > I would propose that the C operation should short-circuit if the
> > block throws an exception, with the value of the expection determining
> > whether the final invocation of the block should accept the element it
> > was filtering:
>
> Otherwise nice but until now die() ha
The "assignment from a lazy list" section of RFC 123 suggests a system
for requesting the first however many items out of a map or grep by
making it lazy and then assigning it to an array of that size.
"last" is more flexible, if you are looking for a condition more
complex than the first one,
Jarkko Hietaniemi wrote:
>
> How about using 'return', then? That could, ahem, return both true and
> false values.
Hmm. I think it boils down to the fact that we'd like a grep block
to have characteristics of both a subroutine and a true loop block.
Here's a proposal which would mostly elim
Damian Conway wrote:
>
> The expression C<1 and last> does *not* evaluate to true -- it does not
> evaluate to *anything*. So the C is terminated by the C
> without the block having ever evaluated true. So no element of LIST is
> ever "passed through". So the C evaluates to zero.
Right. Well, pe
Johan Vromans wrote:
> my $file_format = qf(
> @<: @
> $name, $ssn
> );
>
> Now, $file_format would be a Format object (compare this with qr//,
> that produces a Regex object).
or the proposed qs// which would produce a packed structure definition
> If one were looking for the first matching item, last would work:
>
>grep { /pat/ and last } @foo
># return()s the value of $_=~/pat/, which will be true
Huh? I can't see how that could work unless you change the existing
semantics of C and C.
Let's take a step back and an
> Merge all these variables into one. Say for the sake of argument that it
> is C<$!> (for the mnemonic value of "something went bang").
First off, nice RFC. :-) I've liked this for a while now but haven't
commented on it.
Though you don't say so (or maybe I missed it), I'm assuming that $!
wil
At 03:55 PM 9/7/00 -0700, Nathan Wiger wrote:
> > Merge all these variables into one. Say for the sake of argument that it
> > is C<$!> (for the mnemonic value of "something went bang").
>
>First off, nice RFC. :-) I've liked this for a while now but haven't
>commented on it.
>
>Though you don't
On Thu, Sep 07, 2000 at 05:31:37PM -0400, Bennett Todd wrote:
> 2000-09-07-17:11:50 Dan Sugalski:
> That's certainly possible, but since the reason we're gathered here
> together working on trying to launch perl6 is a collective belief
> that perl5 has become unmaintainable for further development
On Thu, Sep 07, 2000 at 01:49:36PM -0400, Peter Allen wrote:
> They have a catchy slogan for it. They call it the
>
>test --> code --> design
>
> development cycle.
That sounds bad. I've heard about this style. Code now, refactor
later. Its supposed to avoid the need for swe
>I found the following reference in the p5p archives to a paper
>discussing open source development. I think this should be mandatory
>reading for anyone contemplating a contribution to the RFC mountain.
Amongst other things, amongst other things
>http://www.firstmonday.dk/issues/issue4_10/
> I think there may be a necessity for more than just a work area to be
> non-shared. There has been no meaningful discussion so far related to
> the fact that the vast majority of perl6 modules will *NOT* be threaded,
> but that people will want to use them in threaded programs. That is a
> non
> Ok, I'm not super familiar with threads so bear with me, and smack me upside
> the head when need be. But if we want threads written in Perl6 to be able
> to take advantage of mulitple processors, won't we inherently have to make
> perl6 multithreaded itself (and thus multiple instances of t
On Thu, 07 Sep 2000, Steven W McDougall wrote:
> RFC 1 proposes this model, and there was some discussion of it on
> perl6-language-flow.
Which is strange, since it was released for this group. Hmmm. But yes,
we did seem to hash out at least some of this before, which, to
Steven's credit, was
-Original Message-
From: Nick Ing-Simmons <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Cc: Jarkko Hietaniemi <[EMAIL PROTECTED]>; Dan Sugalski <[EMAIL PROTECTED]>;
Perl6-Internals <[EMAIL PROTECTED]>; Nick Ing-Simmons
<[EMAIL PROTECTED]>
Date: Thursday, September 07, 2000
> Shoot chop. and chomp. Unless you add unchop and unchomp.
C *has* an inverse.
Surely you know about the unary postfix C<.$/> operator?
Of course, you have to be careful. There's a known bug that
the C<.$/> doesn't properly "unchomp" if you've ever used the
C<$/&=``> operator.
;-)
Damian
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
The Predefined POD Streams are C, C, and C
=head1 VERSION
Maintainer: John Porter <[EMAIL PROTECTED]>
Mailing List: [EMAIL PROTECTED]
Date: 9 Aug 2000
Last Modified: 7 Sep 2000
Number: 79
Versio
(or "Allowing built-in functions to use loop blocks")
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Short-circuiting C, C, and C with C
(or "Allowing built-in functions to use loop blocks")
=head1 VERSION
Maintainer: Garr
Does this discussion pertain to a particular RFC? If so, could the RFC
number please be quoted in the subject?
If it's not already RFC'd, who will volunteer to do it?
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level
Shoot chop. and chomp. Unless you add unchop and unchomp. Parity issue. Like
a language with YES and no NO.
Just kill then both.
>From: Bryan C. Warnock <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: Michael G Schwern <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>Subject: Re: RFC 195 (v1) Ret
>Shoot chop. and chomp. Unless you add unchop and unchomp. Parity issue. Like
>a language with YES and no NO.
By that criterion, you have zillions of other things to kill.
>Just kill then both.
I don't think this will win us friends.
--tom
On Fri, Sep 08, 2000 at 02:50:37AM +, Ed Mills wrote:
> Shoot chop. and chomp. Unless you add unchop and unchomp. Parity issue. Like
> a language with YES and no NO.
>
> Just kill then both.
Although I'm rather fond of symmetry, it's not inherently good.
Rather boring if overused.
I admit
On Thu, Sep 07, 2000 at 10:52:18PM -0600, Nathan Torkington wrote:
> Then we can hear informed criticism and perhaps modify the plan if a
> better system is suggested.
Could we split this off into a working group and mailing list seperate
from perl6-meta?
--
Michael G Schwern http://www.p
On Thu, Sep 07, 2000 at 10:48:57PM -0600, Nathan Torkington wrote:
> Michael G Schwern writes:
> > There's one solution, now that we have a nifty source control stuff.
> > Branch like mad! Feature creep should be discouraged, but if a group
> > wants to go off and work on something which isn't go
Michael G Schwern writes:
> Could we split this off into a working group and mailing list seperate
> from perl6-meta?
Sure. I'm going to set an aggressive schedule for the decision,
though, because this has all the hallmarks of a religious war. Let's
work through the problems now and be forced
Michael G Schwern writes:
> In effect, instead of having one development track, we could have many
> development tracks, each focused on a single feature, or small group
> of features. This should make work easier, because on each track only
> one thing is changing, so its easier to track down ne
So we're three weeks away from the end of this. I've been thinking
about where we went right and where we went wrong (and in particular,
what I would do differently if I had it to do again).
The biggest thing is that I underestimated the volume of traffic. I
never thought there'd be so many RFC
Michael G Schwern writes:
> That sounds bad. I've heard about this style. Code now, refactor
> later. Its supposed to avoid the need for sweeping architectural
> decisions early in the project, allow you to recover from bad design
> decisions and return flexibilty to old code.
Well, yes, but a
On Thu, Sep 07, 2000 at 11:14:34PM -0600, Nathan Torkington wrote:
> I view branches in this initial version as highly unlikely to be
> useful. We need to have a trunk before we can have branches.
I was actually speaking of both the initial development and on from
there. You don't need a trunk
On Thu, Sep 07, 2000 at 11:55:17PM -0600, Nathan Torkington wrote:
> Any more? I'm keen to learn from mistakes (preferably those of
> others, but my own will do in a pinch :-).
How about: If you make an earthshaking decision on day three of a
conference, do not announce it on day five. Wait unt
On Thu, Sep 07, 2000 at 10:15:38PM -0600, Nathan Torkington wrote:
> The hard part is probably going to be resisting the urge to add
> features just because they're possible: once we come up with a design,
> we must code the design, and leave new features for later 6.x
> releases. Feature creep c
Michael G Schwern writes:
> There's one solution, now that we have a nifty source control stuff.
> Branch like mad! Feature creep should be discouraged, but if a group
> wants to go off and work on something which isn't going to make it
> into the next release they can branch and play.
That divi
Adam Turoff writes:
> 3) Those developers prefer Perforce and should not be forced
> to use CVS because non-committers prefer it.
>
> Is there anything more to be said about Perforce vs. CVS that *isn't* FUD?
You make it sound like we've decided on Perforce. Dan, how about you
sk
[I'll take off my black hat for a moment...]
Okay, this is the FIRST TIME I've ever seen indirect object syntax
used for anything useful. (That's praise, BTW)
I was going to suggest that KEYS and VALUES methods be added to tied
hashes, but this RFC makes it all moot. Well done.
[Black hat bac
Steven W McDougall <[EMAIL PROTECTED]> writes:
>> DS> Some things we can guarantee to be atomic.
>
>> This is going to be tricky. A list of atomic guarentees by perl will be
>> needed.
>
>>From RFC 178
>
>...we have to decide which operations are [atomic]. As a starting
>point, we can take all th
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>
>JH> Multithreaded programming is hard and for a given program the only
>JH> person truly knowing how to keep the data consistent and threads not
>JH> strangling each other is the programmer.
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>
>Some series of points (I can't remember what they are called in C)
Sequence points.
>where operations are consider to have completed will have to be
>defined, between these points operations will have to be atomic.
No, quite the reverse - absolutely
In message <[EMAIL PROTECTED]>
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> I'd rather not have the expansion performed. Some other mechanism, either
> under the covers or perhaps even specified in the language.
Absolutely. Both mechanisms have been suggested - my under the
covers proposal
Jarkko Hietaniemi wrote:
> Multithreaded programming is hard and for a given program the only
> person truly knowing how to keep the data consistent and threads not
> strangling each other is the programmer. Perl shouldn't try to be too
> helpful and get in the way. Just give user the bare mini
Chaim Frenkel wrote:
> The problem I have with this plan, is reconciling the fact that a
> database update does all of this and more. And how to do it is a known
> problem, its been developed over and over again.
I'm sorry, but you are wrong. You are confusing transactions with
threading, and t
Dlux <[EMAIL PROTECTED]> writes:
>| I've deemed to be "too complex".) (Also note that I'm not a
>| database
>| guru, so please bear with me, and don't ask me to write the code
>| :-)
>
>Implementing threads must be done in a very clever way. It may be
>put in a shared library (m
From: Damian Conway [mailto:[EMAIL PROTECTED]]
>
> From: Garrett Goebel
> > @passed = grep { 2 > $_ and last } (1, 2, 3, 2, 1);
> >
> > would leave
> > @passed = (1, 2)
>
> I believe the above would leave:
>
> @passed = ();
>
> since on the first call to the block 2 > 1 is true, so th
Bart Lateur wrote:
>
> >Currently, attempting to use objects in a string context
> >yields garbage:
> >
> > print "r is $r->func"; # "OBJ=HASH(0xef958)->func"
> > print "r is ", $r->func; # works, but clumsy
>
> Does this expand to regexes?
>
> /$foo->blah/
>
> To be conseque
On 14 Aug 2000 23:29:38 -, Perl6 RFC Librarian wrote:
>Currently, attempting to use objects in a string context
>yields garbage:
>
> print "r is $r->func"; # "OBJ=HASH(0xef958)->func"
> print "r is ", $r->func; # works, but clumsy
I've not seen any comments on this RFC yet. But thi
> But you said "lists" up there and that sparked an idea in me ... What
> does
>
> @a =~ /pattern/;
>
> currently do? AFAICT, nothing useful.
> Also, it'd be nice if
>
> @a =~ s/foo/bar/g;
>
> did something similar.
See RFC 170, "Generalize =~ to a special-purpose assignmen
On Wed, Sep 06, 2000 at 03:37:55PM -0400, David Corbin wrote:
> Question: Is there value in extending the regex/pattern engine to
> support matching patterns in a list of foobars?
>
> I can see this taking two forms (beyond the strings we have today).
>
> One is matching number patterns (fibonac
>Can be rewritten as the shorter and more readable:
> ($name) =~ split /\s+/;
> $string =~ quotemeta;
> @array =~ reverse;
> @vals =~ sort { $a <=> $b };
> $string =~ s/\s+/SPACE/;# looks familiar
> $string =~ m/\w+/; # this too
> @strs =~ m/\w+/;
Tom Christiansen wrote:
>
> carefully consider whether any scant benefit these cutesinesses
> might provide can be truly worth further exacerbating the rampant
> inscrutability problems (stemming mainly from punctuation in lieu
> of alphabetics and from magically implicit targets, arguments, and
> 2. Many people - including Larry - have voiced their desire
> to see =~ die a horrible death
Please provide a look-up-able reference to Larry's saying that he
wanted to =~ to die horrible death. That's very strongly worded
for him. Are you sure this tale hasn't merely grown in the tell
From: Tom Christiansen <[EMAIL PROTECTED]>
Sent: Thursday, September 07, 2000 11:20 AM
> Which can of course be written in an immeasuably more legible fashion
> using current Perl, a little-known language:
>
> ($name) = split /\s+/, $name;
> $string = quotemeta($string);
> @array =
> > 2. Many people - including Larry - have voiced their desire
> > to see =~ die a horrible death
>
> Please provide a look-up-able reference to Larry's saying that he
> wanted to =~ to die horrible death.
Larry said:
# Well, the fact is, I've been thinking about possible ways to get
1 - 100 of 126 matches
Mail list logo
