Rob Kinyon wrote:
> > 1. choose one of a set of available methods to call its own.
> > 2. create a version of its own.
> > 3. pass the buck.
>
> #1 and #2 are identical. Stevan and I have always viewed #1 as a
> special case of #2. If you want to choose a method to call, then
> create a method of y
> 1. choose one of a set of available methods to call its own.
> 2. create a version of its own.
> 3. pass the buck.
#1 and #2 are identical. Stevan and I have always viewed #1 as a
special case of #2. If you want to choose a method to call, then
create a method of your own and have it wrap the on
When I began to write this posting, it was to get an answer to a
question. But I figured out a workaround halfway through, so now I'm
posting an answer.
I have happily been using Devel::Cover for more than a year on Perl
5.8.4 on Darwin (Mac OS X 10.3). Recently I upgraded to Perl 5.8.7.
To
On 11/1/05, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> In the third case, I'd be inclined to say that passing the buck is
> equivalent to creating an undefined version of your own - that is, not
> addressing a conflict involving method x is equivalent to saying
> "method x ($arg) { ... }". IOW, a
Yuval Kogman wrote:
> Stevan Little wrote:
> > If we allow the class to decide if things break or not, then we
> > potentially allow for the system to be in a very unstable state. A
> > method conflict means that neither method gets consumed, and at
> > that point we have a gapping hole in our cla
> Nice work, Geoff
:)
>
> A few issues:
>
> 1)
>
> % make testcover
> Cannot run testcover action unless Devel::Cover is installed
>
> and after installing Devel::Cover it still gives the same error, since
> it's hardcoded in Makefile.PL. May be adding a check and suggesting to
> rebuild Mak
On a grammar that worked in a recent version of PGE, I'm now getting
an error when I try to construct the grammar. The error disappears
when I eliminate all non-greedy quantifiers from the grammar (though,
of course, the constructed grammar parses the text incorrectly with
greedy quantifier
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #37578]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37578 >
>From a discussion earlier today on #irc...
It would be nice if the PIR compiler
# New Ticket Created by Nick Glencross
# Please include the string: [perl #37577]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37577 >
This patch fixes two classes of issue.
* Don't assign -1 to an unsigned variable;
On Tue, Nov 01, 2005 at 11:48:34AM +, Nicholas Clark wrote:
> On Tue, Nov 01, 2005 at 01:45:10AM -0600, Patrick R. Michaud wrote:
>
> > but I'm not a fan of writing the $S0 variables -- they seem to distract
> > the code. I may just go with something like
> >
> > code .="lastpos
hi all :)
I just commited a patch to Apache-Test in svn that removes all the
additional work involved with getting Devel::Cover to work for server side
tests. now a simple 'make testcover' should be all you need to do to get
coverage results from code within handler() subroutines - no more adding
Hi Michael!
Thanks for your commentary.
On Monday 10 October 2005 23:27, Michael G Schwern wrote:
> On Mon, Oct 10, 2005 at 10:53:34PM +0200, Shlomi Fish wrote:
> > Let me know what you think.
>
> $ perl -Ilib -wle 'use Test::Shlomif::Harness::Obj;
> Test::Shlomif::Harness::Obj->new->runtests(te
chromatic <[EMAIL PROTECTED]> writes:
> On Thu, 2005-10-27 at 10:26 -0700, jerry gay wrote:
>
>> we're missing some parts of a testing framework. we don't have the
>> ability to write test files in PIR, so we're dependent on a perl
>> install for testing. perl's a great language for writing tests
On Tue, Nov 01, 2005 at 01:45:10AM -0600, Patrick R. Michaud wrote:
> but I'm not a fan of writing the $S0 variables -- they seem to distract
> the code. I may just go with something like
>
> code .="lastpos = length target"
> code .="gpad = new PerlArray"
> code .=
Out of curiosity, might there be any convenient way to support
heredoc parameters in PIR function calls? (I suspect the answer
is "no", but thought I'd ask just in case.)
Currently PGE builds code to be compiled by emitting a sequence
of function calls, each call appends another line of output to
I just wanted to send a quick note to perl6-internals
and perl6-compiler that I've just checked in some major
changes to the PGE internals (r9681). Last week we
added a shift-reduce operator precedence parser,
this version uses that parser to parse perl 6 rules,
which should improve the parsing sp
On Fri, Oct 28, 2005 at 14:19:46 -0400, Stevan Little wrote:
> Yuval,
>
> On Oct 28, 2005, at 10:59 AM, Yuval Kogman wrote:
> >On Thu, Oct 27, 2005 at 22:19:16 -0400, Stevan Little wrote:
> >>Now, at this point we have a method conflict in suspension since
> >>(according to A/S-12) method confl
17 matches
Mail list logo
