Austin Hastings writes:
> > Those are actually:
> >
> > my $b = @m Â+Â 1;
> > my $c = [ map { +$^x } @m ];
>
> Boggle! Why wouldn't that be:
>
>my $c = [ map { $^x Â+Â 1 } @m ];
>
> for the last one?
Whoops. I thought I was preserving his original semantic, but I wasn't.
I had so
On Thu, May 20, 2004 at 08:08:19PM -0400, Geoffrey Young wrote:
> well, I was trying to be a good citizen and provide a useful test case
> (rather than a tarball that merely exhibited the issue). I did add
And I appreciate it.
> something to cond_or and ran 'make test TEST_FILES=t/acond_or.t' b
> This is unlikely to be the only case in which I have not fully
> understood the subtleties of the op tree, and so I am grateful for
> reports such as this.
I'll keep them coming, then :)
>
> The following patch should fix it, and will be in the next release,
> hopefully coming next week:
exce
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;
>
> I can't ever satisfy the first condition in the "condition coverage" matrix
> (0,0) since 1 is always true. is it desirable to remove fixed truth values
On Thursday 20 May 2004 17:40, Dan Sugalski wrote:
> $I0 = 1
> if $P0, done
> $I0 = 0
> done:
I see a similar problem with the isnull op:
getattribute $P0, ...
isnull $P0, INIT
branch DONE
INIT:
$P0 = new .Foo
setattribute ..., $P0
DON
hi paul.
I've found that in a statement like
$x{foo} ||= 1;
I can't ever satisfy the first condition in the "condition coverage" matrix
(0,0) since 1 is always true. is it desirable to remove fixed truth values
like this from the truth table?
I tried taking a look at adding the condition t
At 11:40 AM -0400 5/20/04, Dan Sugalski wrote:
Anyway, because of it I'm pondering non-flowcontrol logical ops.
That is, something like:
istrue I0, P5# I0 = 1 if P5 is true
isgt I0, P5, P6 # I0 = i if P5 > P6
Okay, it's pretty obvious that these would be useful and people have
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
key. So my compiler has to spit out about 20 lines of
code for every sub-element access
> Anyway, because of it I'm pondering
> non-flowcontrol logical ops.
Those would be very nice for us compiler-writers.
It's a bit (heh) late for me to bring this up, now,
but I always thought the flow-control ops should be
prefixed with 'j' or something. Like in most other
assemblies. You have "j
Dave Whipp writes:
> Is it possible to "hyper" a hyper operator?
>
> For example, given:
>
> my @m = ( [1,2], [3,4], [5,6] );
>
> my $a = @m + 1;
> my $b = @m +Â 1;
> my $c = @m +ÂÂ 1;
Those are actually:
my $b = @m Â+Â 1;
my $c = [ map { +$^x } @m ];
Hyper markers go on both
On Thu, May 20, 2004 at 10:18:06AM -0700, Brent 'Dax' Royal-Gordon wrote:
> Dan Sugalski wrote:
> > istrue I0, P5# I0 = 1 if P5 is true
> > isgt I0, P5, P6 # I0 = i if P5 > P6
>
> By all means! I've thought non-branching comparison ops would be a good
> idea for years...
My goo
Dan Sugalski wrote:
istrue I0, P5# I0 = 1 if P5 is true
isgt I0, P5, P6 # I0 = i if P5 > P6
By all means! I've thought non-branching comparison ops would be a good
idea for years...
--
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Oceania has always been
Dan Sugalski writes:
> Right now the only good way to find out if a value is true or not is
> to do something like:
>
> $I0 = 1
> if $P0, done
> $I0 = 0
> done:
>
> and look in $I0 for the result.
[snip]
> Anyway, because of it I'm pondering non-flowcontrol logical ops. That
> is, somethin
Is it possible to "hyper" a hyper operator?
For example, given:
my @m = ( [1,2], [3,4], [5,6] );
my $a = @m + 1;
my $b = @m +« 1;
my $c = @m +«« 1;
is it true that:
ok($a == 4);
ok($b »==« [ 3, 3, 3 ];
ok($c »»==«« [ [2,3], [4,5], [6,7] ];
Is there an "infinite depth" hyper oper
Dan Sugalski wrote:
> Right now the only good way to find out if a value is true or not is
> to do something like:
>
> $I0 = 1
> if $P0, done
> $I0 = 0
> done:
>
> and look in $I0 for the result. This is OK, but if you're dealing
> with a language with relatively primitive views of log
Okay, let me preface this by saying it is, in large part, directly
because of my current work project, so it feels a bit self-serving.
(One of the reasons I haven't just put them in)
But...
Right now the only good way to find out if a value is true or not is
to do something like:
$I0 = 1
if
# New Ticket Created by Adam Thomason
# Please include the string: [perl #29742]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29742 >
Attached patch brings jit_debug_xcoff.c up to date with ICU changes.
--
Adam Thomas
Jens Rieks <[EMAIL PROTECTED]> wrote:
> cvsuser 04/05/19 14:14:39
> Modified:src dynext.c packfile.c
> Log:
> added experimental parrotlib code that is used if _PARROTLIB is defined
I know that's too early to comment much WRT these changes. Could you
please outline the goals th
18 matches
Mail list logo
