Re: specifying the key Type for a Hash

On Sat, 04 Dec 2004 08:01:46 -0700, [EMAIL PROTECTED] (David Green) wrote: > In article <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] (Larry Wall) wrote: > >S9 talk about it. We current have things like: > >my Cat %pet is shape(Str); > >and parameters to types are in square brackets, so it's more

Re: [perl #27304] [PATCH] move libnci.def out of root directory

Will Coleda via RT wrote: Can we get a ruling on this? I tend to agree with the statement "Random build files do not belong in the root directory". The patch has been un-ACK'd for nine months at the moment. While we are at it, shouldn't we rename 'libnci.so' and 'libnci.def' to 'libnci_test.so'

C implementation of Test::Harness' TAP protocol

Having done the initial work to get most of FreeBSD's regression testing infrastructure producing Test::Harness TAP compatible output, I've started putting together a C library that makes it easier to write tests in C. This is a few hours work at the moment, but it's functional, and I'd appreciate

Re: specifying the key Type for a Hash

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Larry Wall) wrote: >Maybe type parameters are just subscripts? [...] >my Fight %fight does key{Dog;Cat}; I like that. >But if English-like is the criterion that'd still read better as >my Fight %fight has key{Dog;Cat}; I like that even

Re: Premature pessimization

Luke Palmer <[EMAIL PROTECTED]> wrote: > Leopold Toetsch writes: >> This term came up in a recent discussion[1]. But I'd like to give this >> term a second meaning. > Except what you're talking about here is premature *optimzation*. No. I don't think so. >> During design considerations we (inclu

Re: continuation enhanced arcs

Piers Cawley <[EMAIL PROTECTED]> wrote: > Leopold Toetsch <[EMAIL PROTECTED]> writes: >> Matt Fowles <[EMAIL PROTECTED]> wrote: >> >>> Thanks for the clear explanation. I did not realize that S registers >>> could switch pointers, that does make things a little harder. I have >>> a recommendatio

Re: iteration (was Re: Angle quotes and pointy brackets)

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Matt Diephouse) wrote: >On Sat, 04 Dec 2004 08:59:24 -0700, David Green <[EMAIL PROTECTED]> wrote: >C signifies a role named "Iterate". Roles are sort of a >mix of interfaces and mixins (as I understand it -- I'm still waiting >for E12). So sayin

Re: specifying the key Type for a Hash

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Smylers) wrote: >No! Avoid synonyms. They're initially tempting, because then everybody >gets to pick the one he/she wants to use, but then it turns out you need >to learn all of them so as to read other people's code, and that's worse >than no

Re: [perl #27304] [PATCH] move libnci.def out of root directory

Will Coleda via RT <[EMAIL PROTECTED]> wrote: > Can we get a ruling on this? I tend to agree with the statement > "Random build files do not belong in the root directory". There's a stricter rule too (IIRC proposed by Nick or Jarkko). No build files in the Parrot tree, because this prevents a sha

Re: pull & put (Was: Angle quotes and pointy brackets)

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Luke Palmer) wrote: >But what we'd really like to do is: given the user knows what push/pop >do, what would they *guess* to mean shift (I tend to think that this >is a very good technique for naming). >And, well, I'm thinking pull. So it's a t

Re: specifying the key Type for a Hash

David Green writes: > In article <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] (Larry Wall) wrote: > >Maybe type parameters are just subscripts? [...] > >my Fight %fight does key{Dog;Cat}; > > I like that. Yeah, me too. Except I'm having trouble seeing how key is a role. It's not adding anythi

Re: pull & put (Was: Angle quotes and pointy brackets)

David Green writes: > I guess we could always use prepend/append, pull/pop. No! C and C are a well-defined pair, not just in Perl, for dealing with stacks; we should keep those as they are. (And no synonyms, before somebody suggests any!) Smylers

Re: Premature pessimization

Leopold Toetsch wrote: "correct". I've discovered and analysed the problem with continuations. I've made a proposal to fix that. No one has said that it's technically wrong or couldn't work. It seems you are liking the idea, but Dan doesn't. Now what? I would suggest focusing on one issue at a time

Re: Premature pessimization

Ashley Winters wrote: On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer <[EMAIL PROTECTED]> wrote: Leopold Toetsch writes: This term came up in a recent discussion[1]. But I'd like to give this term a second meaning. Except what you're talking about here is premature *optimzation*. You're expecting ce

Re: [perl #27304] [PATCH] move libnci.def out of root directory

Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > Will Coleda via RT wrote: >> Can we get a ruling on this? I tend to agree with the statement "Random >> build files do not >> belong in the root directory". >> >> The patch has been un-ACK'd for nine months at the moment. > While we are at it, sho

Re: Premature pessimization

Sam Ruby <[EMAIL PROTECTED]> wrote: > Leopold Toetsch wrote: >> >> "correct". I've discovered and analysed the problem with continuations. >> I've made a proposal to fix that. No one has said that it's technically >> wrong or couldn't work. It seems you are liking the idea, but Dan >> doesn't. Now

Re: Arglist I/O [Was: Angle quotes and pointy brackets]

Larry Wall wrote: But here's the kicker. The null filename can again represent the standard filter input, so we end up with Perl 5's while (<>) {...} turning into for =<> {...} Two more issues: idiom, and topification = Topification: There are cases in P5 when I *don't* want while (<

Re: pull & put (Was: Angle quotes and pointy brackets)

Smylers wrote: Larry Wall writes: But then are we willing to rename shift/unshift to pull/put? Yes. C is a terrible name; when teaching Perl I feel embarrassed on introducing it. No! But I'd be willing to rename them to get/put. 'Pull' is the opposite of 'push', but 'pop' already works.

Re: Premature pessimization

Leopold Toetsch wrote: Sam Ruby <[EMAIL PROTECTED]> wrote: Leopold Toetsch wrote: "correct". I've discovered and analysed the problem with continuations. I've made a proposal to fix that. No one has said that it's technically wrong or couldn't work. It seems you are liking the idea, but Dan doesn't

Re: Arglist I/O [Was: Angle quotes and pointy brackets]

On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote: for =<> {...} I dub the...the fish operator! :-) David

Re: specifying the key Type for a Hash

On Mon, Dec 06, 2004 at 05:43:16AM +, Nigel Sandever wrote: : I probably missed teh comprehensive dismissal thread, but why not 'type'? : : my %pet is Hash[:type(Str) :returns(Cat)]; Well, "type" is just a little off in a couple of ways. On the one hand, it's not specific enough, insof

Re: Arglist I/O [Was: Angle quotes and pointy brackets]

On Mon, Dec 06, 2004 at 09:06:22AM -0800, David Wheeler wrote: : On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote: : : >> for =<> {...} : : I dub the...the fish operator! : : :-) Mmm. Next thing you'll know, people will name their files oddly just so they can write things like: for = {

Re: [perl #32877] parrot build broken in Tru64, cc/ld confusion

On Sun, 5 Dec 2004, Jarkko Hietaniemi wrote: > I am pretty certain that parrot was building fine in Tru64 back in > 2004/11/07 15:12:42 when I submitted a patch (directly to CVS) > for jit/alpha/jit_emit.h to get alpha JITing to compile at all. > > Since then something has broken building parrot i

Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote: : Two more issues: idiom, and topification : : = Topification: : : There are cases in P5 when I *don't* want : : while (<>) {...} : : but prefer : : while ($input = <>) {...} : : so that I can have something else be the to

while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote: : = Idiom: : : The other concern is idiom. Using C suggests "start at the : beginning, continue to the end". OTOH, using C is a little : "weaker" -- "keep doing this until it's time to stop". Obviously they'll : usually be use

Re: Arglist I/O [Was: Angle quotes and pointy brackets]

Or even the dead fish operator: while =<###x> -> $net {...} And here's a flounder: while =<:> Larry

Re: pull & put (Was: Angle quotes and pointy brackets)

On Mon, Dec 06, 2004 at 10:45:22AM -0500, Austin Hastings wrote: : But I'd be willing to rename them to get/put. If I went with "get", the opposite would be "unget" for both historical and huffmaniacal reasons. Larry

Re: [perl #32877] parrot build broken in Tru64, cc/ld confusion

Andrew Dougherty wrote: The offending line in config/gen/makefiles/dynclasses_pl.in is probably this one: $LD $CFLAGS $LDFLAGS $LD_LOAD_FLAGS $LIBPARROT That CFLAGS doesn't belong there. CFLAGS are intended to be sent to $CC, not to $LD. The command being called here is $LD, which is defined i

Re: Arglist I/O [Was: Angle quotes and pointy brackets]

David Wheeler wrote: On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote: for =<> {...} I dub the...the fish operator! :-) Back before there was a WWW, I used an editor called "tgif". It was written in france, and part of the idiom was to have two GUI buttons showing respectively the head (" <

Re: while Idiom (Was: Arglist I/O)

Austin Hastings writes: > The other concern is idiom. Using C suggests "start at the > beginning, continue to the end". OTOH, using C is a little > "weaker" -- "keep doing this until it's time to stop". Obviously they'll > usually be used in the same way: > > for =<> {...} vs. while (<>)

Re: specifying the key Type for a Hash

On Mon, 6 Dec 2004, Larry Wall wrote: Hmm. Also says maybe you could attach a block to a hash or array to define what subscripting does. Hmm. That's tantalizing. Did you have something like this in mind: # Count number of accesses to each key our %counter_hash; my %hash is subscripted -> $subs

Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

Larry Wall writes: > Currently it does. There have been some rumblings in the design team > that maybe it shouldn't. But it occurs to me that this might be another > spot to have our cake and eat it to. We could say that > > for @foo -> $input { ... $input ... } > > doesn't set the topic i

Re: while Idiom (Was: Arglist I/O)

Smylers writes: > To me C makes sense when you've got a pile of stuff you're > intending to process (such as array items or lines in a file), and > C makes sense when you're waiting for a condition (such as the > user correctly entering her/his password) and you couldn't possibly know > in advance

Re: while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote: > On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote: > : Can we ditch C in the examples in favor of C, for a while? :) > > Okay. Have an example: > > while =$IN -> $line {...} > > I think that works. I'm back to thin

Re: pull & put (Was: Angle quotes and pointy brackets)

If I went with "get", the opposite would be "unget" for both historical and huffmaniacal reasons. But "get" has too strong a class accessor connotation in most OO. "unpull?" ;-)

Re: while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

On Mon, Dec 06, 2004 at 12:45:18PM -0600, Jonathan Scott Duff wrote: : On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote: : > On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote: : > : Can we ditch C in the examples in favor of C, for a while? :) : > : > Okay. Have an example

Re: while Idiom (Was: Arglist I/O)

On Monday 06 December 2004 01:26 pm, Smylers wrote: > I think that C reads much better than C for English-ness. > Having taught Perl 5 beginners that C can be used to iterated > over each item in a list, many of them then instinctively try to use the > same keyword for iterating over each line in

Re: while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

On Mon, Dec 06, 2004 at 10:59:18AM -0800, Larry Wall wrote: > On Mon, Dec 06, 2004 at 12:45:18PM -0600, Jonathan Scott Duff wrote: > : On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote: > : > On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote: > : > : Can we ditch C in the exa

Re: Premature pessimization

Sam Ruby <[EMAIL PROTECTED]> wrote: > Leopold Toetsch wrote: > My philosophy is simple: things without test cases tend not not get > fixed, and when fixed, tend not to stay fixed. There is of course a test case. I have mentioned it at least 20 times ;) t/op/gc_13.imc - currently using lexicals.

Re: pull & put (Was: Angle quotes and pointy brackets)

Dan Brian wrote: If I went with "get", the opposite would be "unget" for both historical and huffmaniacal reasons. But "get" has too strong a class accessor connotation in most OO. "unpull?" ;-) pushf/popf. f is for "front". But I still don't see anything wrong with shift/unshift. I'd prefer to

slight discrepancy between S2 and S7

S2: my $foo = 42; say %MY::<$foo>;# prints "42" S6: Perl5ish subroutine declarations ... sub say { print qq{"@_"\n}; } # args appear in @_ Because C has no final newline, I would expect C will have one. Final newline or not. What is your say? -- stef

Re: pull & put (Was: Angle quotes and pointy brackets)

On Mon, Dec 06, 2004 at 01:25:29PM -0600, Rod Adams wrote: > Dan Brian wrote: > > >>If I went with "get", the opposite would be "unget" for both historical > >>and huffmaniacal reasons. > > > > > >But "get" has too strong a class accessor connotation in most OO. > > > >"unpull?" ;-) > > > > > push

Re: pull & put (Was: Angle quotes and pointy brackets)

On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote: : >If I went with "get", the opposite would be "unget" for both historical : >and huffmaniacal reasons. : : But "get" has too strong a class accessor connotation in most OO. : : "unpull?" ;-) Given the existence of a unary = for abbrevia

Re: specifying the key Type for a Hash

On Mon, Dec 06, 2004 at 03:11:15AM -0700, David Green wrote: [snip] : I like that. [snip] : I like that even better. [snip] : I'm happy with those too (perhaps because I do want to be a bit : mathematical). [snip] : "is FAT"? Yeah, that works for me too. =) [snip] : I would take that as an abbre

Re: iterators and functions (and lists)

On Sun, Dec 05, 2004 at 12:05:46AM +, Matthew Walton wrote: : I'm sorry, but from a C++ background, overriding postcircumfix:<( )> : feels far more natural to me than setting 'is default' on some method. That only works for disambiguation if you know which .() to call in the first place. It

Re: C implementation of Test::Harness' TAP protocol

Keeping in mind I'm not a C programmer so my user expectations may be all wrong. On Mon, Dec 06, 2004 at 10:00:32AM -, Clayton, Nik wrote: > Then you have one of ok() or ok2() at your disposal. ok()'s first parameter > is the code to test. The second parameter is the test name. This is a

Re: slight discrepancy between S2 and S7

On Mon, Dec 06, 2004 at 08:26:48PM +0100, Stéphane Payrard wrote: : S2: : : my $foo = 42; : say %MY::<$foo>;# prints "42" : : S6: : : Perl5ish subroutine declarations : ... : sub say { print qq{"@_"\n}; } # args appear in @_ : : : Because C has no final new

Re: Container method calls

On Sat, Dec 04, 2004 at 03:28:12PM -0800, Ashley Winters wrote: : On Sat, 4 Dec 2004 11:15:14 -0800, Larry Wall <[EMAIL PROTECTED]> wrote: : > On Sat, Dec 04, 2004 at 10:25:49AM -0700, Luke Palmer wrote: : > : But this convention provides much more accuracy than memorizing a list : > : of methods t

Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

Luke Palmer wrote: The remaining problem is what to do about unary dot. Repeated here for the, er, benefit? of p6l: class Duple { has $.left; has $.right; method perform (&oper) { &oper($.left); &oper($.right); } } Let's change that i

Re: while Idiom (Was: Arglist I/O)

Elyse M. Grasso wrote: But you need to process the file while you haven't reached the end yet, or until you reach the end. And I can't think of an occasion where I knew going in what the length of the file I was processing was going to be. I suppose foreach might make sense if you sucked in the

Re: Premature pessimization

Leopold Toetsch wrote: Sam Ruby <[EMAIL PROTECTED]> wrote: Leopold Toetsch wrote: My philosophy is simple: things without test cases tend not not get fixed, and when fixed, tend not to stay fixed. There is of course a test case. I have mentioned it at least 20 times ;) t/op/gc_13.imc - currently u

Re: pull & put (Was: Angle quotes and pointy brackets)

Larry Wall wrote: On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote: : >If I went with "get", the opposite would be "unget" for both historical : >and huffmaniacal reasons. Why? (I get the huffman, not the history.) Is it just a nod to unshift? Given the existence of a unary = for abbrev

Re: pull & put (Was: Angle quotes and pointy brackets)

On Mon, Dec 06, 2004 at 03:50:42PM -0500, Austin Hastings wrote: : Larry Wall wrote: : : >On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote: : >: >If I went with "get", the opposite would be "unget" for both historical : >: >and huffmaniacal reasons. : > : > : Why? (I get the huffman, not

Re: C implementation of Test::Harness' TAP protocol

--- Michael G Schwern <[EMAIL PROTECTED]> wrote: > Why add that extra auto-sprintf complexity? Can't the user do the exact > same thing with: > > ok(some_func(i), sprintf("some_func(%d)", i)); No. sprintf in C needs a buffer and you don't know how big to make it. > > ok2() is for situatio

Re: C implementation of Test::Harness' TAP protocol

On Mon, Dec 06, 2004 at 02:25:42PM -0800, Andrew Savige wrote: > --- Michael G Schwern <[EMAIL PROTECTED]> wrote: > > Why add that extra auto-sprintf complexity? Can't the user do the exact > > same thing with: > > > > ok(some_func(i), sprintf("some_func(%d)", i)); > > No. sprintf in C needs

Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

Matthew Walton writes: > Luke Palmer wrote: > > >The remaining problem is what to do about unary dot. Repeated here for > >the, er, benefit? of p6l: > > > >class Duple { > >has $.left; > >has $.right; > > > >method perform (&oper) { > >&oper($.left); > >

Re: iterators and functions (and lists)

Larry Wall writes: > Any foo() can return a list. That list can be a Lazy list. So the > ordinary return can say: > > return 0...; > > to return an infinite list, or even > > return 0..., 0...; Is it just me, or did you just return Ï*2? http://en.wikipedia.org/wiki/Ordinal#Arithmeti

Re: iterators and functions (and lists)

Luke Palmer wrote: Larry Wall writes: Any foo() can return a list. That list can be a Lazy list. So the ordinary return can say: return 0...; to return an infinite list, or even return 0..., 0...; Is it just me, or did you just return Ï*2? http://en.wikipedia.org/wiki/Ordinal#Arit

Re: iterators and functions (and lists)

On Mon, Dec 06, 2004 at 06:14:56PM -0500, Austin Hastings wrote: (B: Luke Palmer wrote: (B: (B: >Larry Wall writes: (B: > (B: > (B: >>Any foo() can return a list. That list can be a Lazy list. So the (B: >>ordinary return can say: (B: >> (B: >> return 0...; (B: >> (B: >>to return a

Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]

Luke Palmer wrote: class MyStream { has $.stream; method :send_one ($item) { $.stream.send($item); } method send ([EMAIL PROTECTED]) { .:send_one("BEGIN"); for @data { .:send_one($_); } .:send_one("

Re: pull & put (Was: Angle quotes and pointy brackets)

stuff & grab :-) -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- > On Mon, Dec 06, 2004 at 10:45:22AM -0500, Austin Hastings wrote: > : But I'd be willing to rename them to get/put. > > If I went with "get", the opposite

Re: continuation enhanced arcs

Leopold Toetsch <[EMAIL PROTECTED]> writes: > Piers Cawley <[EMAIL PROTECTED]> wrote: >> Leopold Toetsch <[EMAIL PROTECTED]> writes: > >>> Matt Fowles <[EMAIL PROTECTED]> wrote: >>> Thanks for the clear explanation. I did not realize that S registers could switch pointers, that does mak

Re: continuation enhanced arcs

Leopold Toetsch <[EMAIL PROTECTED]> writes: > Piers Cawley <[EMAIL PROTECTED]> wrote: >> Leopold Toetsch <[EMAIL PROTECTED]> writes: > >>> Matt Fowles <[EMAIL PROTECTED]> wrote: >>> Thanks for the clear explanation. I did not realize that S registers could switch pointers, that does mak

Re: Premature pessimization

Leopold Toetsch writes: > > On a semi-related note, can I get a classoffset without doing a hash > lookup? That is, can I store the class number I get assigned somewhere > for quick fetching? Hey now, you're citing the Luke Palmer that writes code. Don't confuse him with the Luke Palmer who doe

[perl #32906] Can't make TCL

# New Ticket Created by Matthew Zimmerman # Please include the string: [perl #32906] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=32906 > --- osname= linux osvers= 2.4.21-4.elsmp arch= i386-linux-thread-multi cc=

Re: C implementation of Test::Harness' TAP protocol

--- Michael G Schwern <[EMAIL PROTECTED]> wrote: > On Mon, Dec 06, 2004 at 02:25:42PM -0800, Andrew Savige wrote: > > --- Michael G Schwern <[EMAIL PROTECTED]> wrote: > > > Why add that extra auto-sprintf complexity? Can't the user do the exact > > > same thing with: > > > > > > ok(some_func(i

Re: pull & put (Was: Angle quotes and pointy brackets)

On Mon, 6 Dec 2004 11:34:24 -0800, Larry Wall <[EMAIL PROTECTED]> wrote: > Though it's awfully tempting to fill in the holes in the periodic table: > > ($a, $b, $c) = @foo *<< 3; > > And then just say all the corresponding unaries default to 1 (or the arity > of the left): > > $bit = +<<

Re: C implementation of Test::Harness' TAP protocol

--- "Clayton, Nik" <[EMAIL PROTECTED]> wrote: > Having done the initial work to get most of FreeBSD's regression testing > infrastructure producing Test::Harness TAP compatible output, I've started > putting together a C library that makes it easier to write tests in C. Great! This is something I

Perl 6 Summary for 2004-11-29 through 2004-12-06

Perl 6 Summary for 2004-11-29 through 2004-12-06 All~ Last week I asked for help identifying the source of a quotation. One friendly soul suggested Alan J. Perlis, but could not find an actual attribution. It did lead me to find a very applicable (and in my mind funny) quote fr

Re: C implementation of Test::Harness' TAP protocol

On Tue, Dec 07, 2004 at 12:55:01PM +1100, Andrew Savige wrote: > 3) Implementing cmp_ok() in C is a challenge. ;-) > > xUnit/cutest have things like: > > AssertStrEquals > AssertIntEquals > ... > > The trouble with plain old ok() is that investigating test failures > is a pest. I suppose you cou

Re: Perl 6 Summary for 2004-11-29 through 2004-12-06

Matt Fowles wrote: keyword arguments Sam Ruby wondered how he out to handle keyword arguments to functions. Dan admitted that this is complex and outlined the cheat he has been contemplating. No one has either commented on or implemented it yet. Oh, yes, I di

Re: [perl #32906] Can't make TCL

You mean, someone actually tried to use Tcl? *Rub eyes* Whoops. File got added to the tcl makefile based on a local copy of the command. Committed update to MANIFEST and the join file (which isn't complete or tested, btw.) Try again? Matthew Zimmerman (via RT) wrote: # New Ticket Created by Matth

Re: C implementation of Test::Harness' TAP protocol

--- Michael G Schwern <[EMAIL PROTECTED]> wrote: > Yucko. > > Test::More implements cmp_ok() using an eval. Could a macro prove useful > here to do something similar? > > cmp_ok(foo, 'int', '==', bar); Good idea Schwern. These test suites inevitably degenerate into macro crack-pipe smoking ses

Test labels

I think even better than ok( $expr, "name" ); or ok( $expr, "comment" ); is ok( $expr, "label" ); RJBS points out that "comment" implies "not really worth doing", and I still don't like "name" because it implies (to me) a unique identifier. We also talked about "description", but "desc

Re: [perl #32877] parrot build broken in Tru64, cc/ld confusion

> > The offending line in config/gen/makefiles/dynclasses_pl.in > is probably this one: > > $LD $CFLAGS $LDFLAGS $LD_LOAD_FLAGS $LIBPARROT > > That CFLAGS doesn't belong there. CFLAGS are intended to be sent to $CC, > not to $LD. The command being called here is $LD, which is defined in > c

Re: [perl #32877] parrot build broken in Tru64, cc/ld confusion

Sam Ruby via RT wrote: > Andrew Dougherty wrote: > >>The offending line in config/gen/makefiles/dynclasses_pl.in >>is probably this one: >> >>$LD $CFLAGS $LDFLAGS $LD_LOAD_FLAGS $LIBPARROT >> >>That CFLAGS doesn't belong there. CFLAGS are intended to be sent to $CC, >>not to $LD. The command

Re: C implementation of Test::Harness' TAP protocol

On Tue, Dec 07, 2004 at 03:18:17PM +1100, Andrew Savige wrote: > Good idea Schwern. > These test suites inevitably degenerate into macro crack-pipe > smoking sessions. Lacking 'eval', it is always going to be very > hard work to even get close to Perl's Test::More functionality > and ease-of-use in

Re: iterators and functions (and lists)

Larry Wall writes: > As far as I can recall we haven't renamed C<.specs> to anything else yet. That sounds like a challenge ... Smylers