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 op tree, and so
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 as a
# New Ticket Created by Will Coleda
# Please include the string: [perl #29771]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29771
The following inline patch removes what I think is currently a spurious warning
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 bytecode
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. One of
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
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 and
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.
Wouldn't
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-code
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 of a method
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.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29782
Hi,
this
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]
--- 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 decided to
13 matches
Mail list logo
