purple
>
> >> I might like to signal Devel::Cover that func() has a constant return (or
> >> lack thereof).
> >
> >
>
> however, in the process of development we are required to analyze any of the
> inevitable gaps and decide whether the unhit condition is valid. if it is
> we write a test f
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> I saw that one too with some files. Some bug lurking
> around related to line numbers. You could copy the
PASM
> source file and remove empty lines and comments.
>
> leo
I didn't have a chance to play with parrot at all this
week. Tonight, I decid
Attached patch brings jit_debug_xcoff.c up to date with ICU changes.
Applied, thanks.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
On Friday 21 May 2004 16:41, Bernhard Schmalhofer wrote:
> # New Ticket Created by Bernhard Schmalhofer
> # Please include the string: [perl #29782]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org:80/rt3/Ticket/Display.html?id=29782 >
>
>
> Hi,
>
> th
chromatic wrote:
> On Fri, 2004-05-21 at 09:02, Geoffrey Young wrote:
>
>
>>another thing that is keeping me from 100% right now is the
>>classic
>>
>> my $class = ref $self || $self;
>>
>>where the only way to satisfy the conditional is to call My::Foo::bar()
>>using functional syntax instead
>> I might like to signal Devel::Cover that func() has a constant return (or
>> lack thereof).
>
>
> I don't know if I would like this feature. To me it would allow you to
> falsely skew the results of the Devel::Cover output. I look at
> Devel::Cover as a harshly objective analysis of my test-c
On Fri, 2004-05-21 at 09:02, Geoffrey Young wrote:
> another thing that is keeping me from 100% right now is the
> classic
>
> my $class = ref $self || $self;
>
> where the only way to satisfy the conditional is to call My::Foo::bar()
> using functional syntax instead of a method syntax.
Woul
On May 21, 2004, at 12:02 PM, Geoffrey Young wrote:
Full coverage isn't always possible, and the lack of it isn't
necessarily a problem.
I fully agree. however, once you start using a tool like this,
management
will inevitably ask "what's that 93% about?" and the answer is
sometimes
complex an
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #29782]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29782 >
Hi,
this patch should make the 'Parrot m4' tests complete again.
The probl
> Full coverage isn't always possible, and the lack of it isn't
> necessarily a problem.
I fully agree. however, once you start using a tool like this, management
will inevitably ask "what's that 93% about?" and the answer is sometimes
complex and subject to judgement: "well, Devel::Cover is j
Hi,
the code is now in. To use it, uncomment the #define _PARROTLIB in
src/dynext.c:23 (for load_bytecode) and
imcc/imcc.l:815 (for .include instructions)
and create the parrotlib.pbc file:
./parrot -o runtime/parrot/include/parrotlib.pbc \
runtime/parrot/library/parrotlib.imc
WARNIN
Gabor Szabo wrote:
>
>> $x{foo} ||= 1;
>
> I have not tested you recent patch. That might have solved this one
> too as this is very similar.
>
> $a = func() || croak("we have some problem");
Actually, that's quite different.
> According to Devel::Cover the above statetement has 3 states. On
Hi,
On Thursday 20 May 2004, Leopold Toetsch wrote:
> I know that's too early to comment much WRT these changes. Could you
> please outline the goals that you want to achieve?
My goal is to replace the path handling code (imcc's include_file,
Parrot_load_bytecode and Parrot_load_lib) with bytecod
Le Thu, May 20, 2004 at 12:03:52PM -0700, le valeureux mongueur TOGoS a dit:
> Should aggregate PMCs (like PerlHash) be able to take
> PMCs as keys? I mean so that:
>
> $P0 = $P1[$P2]
>
> where $P1 is a PerlHash, would work. The way it works
> now is that it complains that you can't use a PMC a
# New Ticket Created by Will Coleda
# Please include the string: [perl #29771]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29771 >
The following inline patch removes what I think is currently a spurious warning in the
On Fri, 21 May 2004, Paul Johnson wrote:
> On Thu, May 20, 2004 at 04:34:39PM -0400, Geoffrey Young wrote:
>
> > hi paul.
> >
> > I've found that in a statement like
> >
> > $x{foo} ||= 1;
> >
>
> This is unlikely to be the only case in which I have not fully
> understood the subtleties of the
16 matches
Mail list logo
