At 7:47 AM +0400 4/28/02, Ilya Martynov wrote:
>Hi,
>
>While reading PDDs I have noticed minor bug in pdd06_pasm.pod: missing
>new line char between two =item lines. Without it perldoc renders this
>PDD as
>
> clone Px, Py =item clone Sx, xy
Applied, thanks.
--
Hi,
While reading PDDs I have noticed minor bug in pdd06_pasm.pod: missing
new line char between two =item lines. Without it perldoc renders this
PDD as
clone Px, Py =item clone Sx, xy
Index: pdd06_pasm.pod
===
RCS file: /cvs/p
On Sat, Apr 27, 2002 at 12:50:49PM +0200, Paul Johnson wrote:
>
> Here's another possibility. People trust Larry to get it right and
> don't feel the need to weigh in with opinions.
I trust Larry. That's actually why I feel free to play the devil's
advocate. I trust him to toss the dross and
Okay, the first draft of PDD3, calling conventions, is in. Sync up,
rip in, and let fly... :)
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
Allison Randal wrote:
> Hmmm... some discussion generated on this subject, but fairly light. I
> take that as an indicator that an C on loops is a fairly popular
> idea. The other possibilities are that b) people don't want any form of
> "else" on loops and aren't saying so or c) people simply don
Allison wrote:
> > This leads me to conclude that a normal (trailing, un-nested) C
> > is a much more reasonable construct for a C -- and at least
> > arguable for a C.
>
> And C, I hope.
Sure. I always think of a C as just a C with delusions of
grandeur. ;-)
Of course, one would expect a comp
> For (1), maybe we should add an opcode: get_number_of_live_objects?
> Then you could write a test case that records the number of live
> objects, does stuff, forces a sweep and collect, and checks that the
> saved number + #expected live objects is equal to the currently live
> number?
I agree
On Sat, Apr 27, 2002 at 10:53:09PM +1000, Damian Conway wrote:
> Allison wrote:
>
> > And the discussion of scope led to (what I think is) an interesting
> > tidbit on NAMED blocks...
>
> Which I presume was that the proposed usage:
>
> while $result.get_next() -> $next {
> # do som
[modified repost due to warnock's dilemma]
Would something like these DWIM?
# match pat1 _ pat2 and capture pat2 match:
/ pat1 { ($foo) = / pat2 / } /
# match pat1 _ 'foo bar':
/ pat1 { 'foo bar' } /
# match pat2 if not pat1
/ { ! /pat1/ } pat2 } /
# match pat2 if
On Sat, Apr 27, 2002 at 12:30:56PM -0700, Steve Fink wrote:
> For (1), maybe we should add an opcode: get_number_of_live_objects?
> Then you could write a test case that records the number of live
> objects, does stuff, forces a sweep and collect, and checks that the
> saved number + #expected liv
I'll paste a diff -ub below to show the changes without the
reindentation noise.
I am about to commit a patch that:
- Fixes a bit test bug, changing to
bits == (bitA | bitB)
from
bits == (bitA & bitB))
- Count of elements in an array of PMCs was wrong. It was looping
over PMC*
Allison wrote:
> As I was talking to Damian, he came up with a compelling semantic
> argument why we would want C blocks to follow, which is a question
> that needed to be faced since we rejected C.
Specifically, the semantic argument with that idea is that CAPITAL blocks
attach automatic behavi
On Sat, Apr 27, 2002 at 05:20:06AM -0500, Allison Randal wrote:
> Hmmm... some discussion generated on this subject, but fairly light. I
> take that as an indicator that an C on loops is a fairly popular
> idea. The other possibilities are that b) people don't want any form of
> "else" on loops a
Hmmm... some discussion generated on this subject, but fairly light. I
take that as an indicator that an C on loops is a fairly popular
idea. The other possibilities are that b) people don't want any form of
"else" on loops and aren't saying so or c) people simply don't care,
but silence and apath
14 matches
Mail list logo
