Leopold Toetsch <[EMAIL PROTECTED]> wrote:
[ fullquote ]
> A recent discussion with Sam has shown that the current calling
> conventions for overloaded operators don't match Python semantics (nor
> Perl6 when I interpret S06 and S13 correctly).
> The difference is that Parrot is passing in the d
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The register coloring algorithm's not dirtying registers right, and
> looks to be assuming that things are in registers across method calls
> when they really aren't.
Fixed and thanks for the test case,
leo
On Sat, Dec 11, 2004 at 04:42:54AM +0100, Leopold Toetsch wrote:
> Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
>
> > Just as C returns its first non-false argument, the interpretation
> > of C would be that it returns its single non-false argument, or 1 if
> > both (all?) arguments logically eva
Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> Just as C returns its first non-false argument, the interpretation
> of C would be that it returns its single non-false argument, or 1 if
> both (all?) arguments logically evaluate to false.
Yep, except *0* if both evaluate to either true or false.
James deBoer <[EMAIL PROTECTED]> wrote:
> I would even go further than that and say that if we went with
> PGE::Rule's "split", the split opcode should be obsoleted.
All these function/method like opcodes will be refactured somewhen.
WRT split (you write):
PGE::Rule."split"()
in general
$
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> The register coloring algorithm's not dirtying registers right,
> There are still some compatibility hooks inside parrot that set P1 on
> the caller's end (or on both sides). I'll remove this remenants RSN.
L
On Fri, Dec 10, 2004 at 01:28:10PM -0500, Sam Ruby wrote:
> Mike Guy wrote:
> >
> >Perl5 C always returns a "standard" boolean value, i.e.
> >dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same
> >thing.
>
> Try:
>
> perl -le "print 'day' xor 'night'"
>
> On the version of
[ From p6i ]
Patrick R. Michaud writes:
> On Fri, Dec 10, 2004 at 08:50:46PM +0100, Leopold Toetsch wrote:
> > Not quite. It gives one value if one is true or 0 (false). This is more
> > information then the perl5 implementation returns. The returned value (if
> > any) is still true but usable, if
Sam Ruby writes:
> Mike Guy wrote:
> >
> >Perl5 C always returns a "standard" boolean value, i.e.
> >dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same
> >thing.
>
> Try:
>
> perl -le "print 'day' xor 'night'"
>
> On the version of Perl I have installed, I get "day" as the
Patrick R. Michaud wrote:
On Fri, Dec 10, 2004 at 01:34:03PM -0500, James deBoer wrote:
Currently, the split opcode is declared as 'split(out PMC, in STR, in
STR)' where $2 is a regex.
PGE, however, currently supports three types of regular expressions, and
more are likely going to be added.
On Fri, 2004-12-10 at 07:23 -0800, via RT wrote:
> trying to compile parrot (cvs) in a linux ppc machine I get the following
> error. It looks like the configure process gets confused and does not compile
> the ppc jit code when it is under linux:
This is a duplicate of #32514, which still awai
On Fri, Dec 10, 2004 at 08:50:46PM +0100, Leopold Toetsch wrote:
> >> We need language lawyers ;)
>
> > IANAL, but I am a mathematician.Because C necessarily always
> > depends on *both* its arguments, analogies with C and C are
> > inappropriate.C cannot short-circuit, and it is not sensi
Mike Guy <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> wrote
>> dropping bitwise xor, and including "undef xor undef" reveals that Perl5
> has a different opinion then Parrot (or Perl6?).
> inline op xor(out INT, in INT, in INT) :base_core {
> $1 = ($2 && ! $3) ? $2 : ($3 && !
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The register coloring algorithm's not dirtying registers right,
There are still some compatibility hooks inside parrot that set P1 on
the caller's end (or on both sides). I'll remove this remenants RSN.
leo
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #32996]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32996 >
The register coloring algorithm's not dirtying registers right, and
looks to be assu
On Fri, Dec 10, 2004 at 01:34:03PM -0500, James deBoer wrote:
> Currently, the split opcode is declared as 'split(out PMC, in STR, in
> STR)' where $2 is a regex.
>
> PGE, however, currently supports three types of regular expressions, and
> more are likely going to be added. So, which type of r
Mike Guy wrote:
Perl5 C always returns a "standard" boolean value, i.e.
dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same
thing.
Try:
perl -le "print 'day' xor 'night'"
On the version of Perl I have installed, I get "day" as the result.
- Sam Ruby
Precedence.
print("day\n" xor "night\n");
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
-Original Message-
From: Sam Ruby [mailto:[EMAIL PROTECTED]
Sent: Friday December 10, 2004 13:28
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [CVS ci] class refact
Currently, the split opcode is declared as 'split(out PMC, in STR, in
STR)' where $2 is a regex.
PGE, however, currently supports three types of regular expressions, and
more are likely going to be added. So, which type of regular expression
should split use?
The Perl6's split function will li
Leopold Toetsch <[EMAIL PROTECTED]> wrote
> dropping bitwise xor, and including "undef xor undef" reveals that Perl5
has a different opinion then Parrot (or Perl6?).
inline op xor(out INT, in INT, in INT) :base_core {
$1 = ($2 && ! $3) ? $2 : ($3 && ! $2) ? $3 : 0;
goto NEXT();
}
> We need la
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #32989]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32989 >
---
osname= linux
osvers= 2.6.9-gentoo-r9
arch= powerpc-linux-thread-multi
cc=
Klaas-Jan Stol wrote:
Sam Ruby wrote:
Klaas-Jan Stol wrote:
Hello,
I just got a fresh cvs checkout, compiled it, compiled pge and tried
to make tcl.
This is what I get:
(cd ../../ && ./parrot --output=languages/tcl/lib/tcllib.pbc
languages/tcl/lib/tcllib.imc)
Couldn't load 'tcl_group': tcl_group
Sam Ruby wrote:
Klaas-Jan Stol wrote:
Hello,
I just got a fresh cvs checkout, compiled it, compiled pge and tried
to make tcl.
This is what I get:
(cd ../../ && ./parrot --output=languages/tcl/lib/tcllib.pbc
languages/tcl/lib/tcllib.imc)
Couldn't load 'tcl_group': tcl_group: cannot open shared o
Eirik Berg Hanssen <[EMAIL PROTECTED]> wrote:
> Which Perl5 (xor, undef) would this be? It does not look like the
> result is undef around here:
> [EMAIL PROTECTED]:~$ perl -le 'print defined($_)?"defined":"undef", ": «$_»"
> for map {(undef xor $_), ($_ xor undef), (undef ^ $_), ($_ ^ undef)}
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> # find_method class 'A' method '__absolute': Sub
>> # Calling sub '__absolute'
> But only for classes that inherit from delegate.
Yes of course. Objects's derived from ParrotObject (i.e. Parrot standard
objects) dispatch to overload
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Sam Ruby <[EMAIL PROTECTED]> wrote:
>
>> I took a look into this. Apparently, in Perl5, the result of xor'ing
>> undef with anything is undef. I'm not suggesting that this is either
>> right or wrong (it actually was surprising to me),
>
> Yep. It do
Eirik Berg Hanssen wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I took a look into this. Apparently, in Perl5, the result of xor'ing
undef with anything is undef. I'm not suggesting that this is either
right or wrong (it actually was surprising to me),
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I took a look into this. Apparently, in Perl5, the result of xor'ing
undef with anything is undef. I'm not suggesting that this is either
right or wrong (it actually was surprising to me),
Yep. It doesn't really follow the definition of x
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> -=item C
> IMHO, all of these can go. The invoke methods need to be on the PMCs
> returned by get_class.
That's exactly how it worked - the PMCs get_class returns a PMC of the
same type, so they act as their own class. But the "i
Sam Ruby <[EMAIL PROTECTED]> wrote:
> I took a look into this. Apparently, in Perl5, the result of xor'ing
> undef with anything is undef. I'm not suggesting that this is either
> right or wrong (it actually was surprising to me),
Yep. It doesn't really follow the definition of xor, nor does it
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I continue to disagree with the part of this conclusion where you insert
find_method into the discussion. To give a concrete example: at the
moment the lookup involved in abs_p_p does not involve the use of
find_method.
$ cat abs.imc
.sub
Leopold Toetsch wrote:
Leopold Toetsch wrote:
Currently one test (t/pmc/pmc_43.pasm) is failing due to wrong
inheritance.
Actually not because of inheritance. The implementation of
PerlUndef.logical_xor was bogus. I've fixed this and the test.
I took a look into this. Apparently, in Perl5, the r
Klaas-Jan Stol wrote:
Hello,
I just got a fresh cvs checkout, compiled it, compiled pge and tried to
make tcl.
This is what I get:
(cd ../../ && ./parrot --output=languages/tcl/lib/tcllib.pbc
languages/tcl/lib/tcllib.imc)
Couldn't load 'tcl_group': tcl_group: cannot open shared object file: No
William Coleda wrote:
Can you give us a copy of the generated "myconfig" file in the top
level parrot directory?
yep,
this is it:
=
Summary of my parrot 0.1.1 configuration:
configdate='Thu Dec 9 23:53:50 2004'
Platform:
osname=linux, archname=i486-linux
34 matches
Mail list logo
