# New Ticket Created by Stephane Payrard
# Please include the string: [perl #53100]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53100 >
I will give it a try but does not promise anything.
--
cognominal stef
Patch applied to trunk in r20628 Aug 14 2007.
cc
---
Flags:
category=core
severity=low
ack=no
---
Where we can use the qr// operator rather than a string 'eval', let's do
so. Here is a patch for Parrot::Vtable. It should have no impact on
performance but makes coverage by tests clearer.
I will apply to trunk in about
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #41670]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41670 >
hi,
attached a patch for lang/pynie.
fixing:
* added transform for is [not] and [not
Markus Laire writes:
> [EMAIL PROTECTED] kirjoitti:
> >Please,
> >I have a question if exists in Perl somethink like keyword
> >'operator' in C++ ?
>
> That will exist in perl6.
And to quite a larger extent. Not only can you overload existing
operators, y
[EMAIL PROTECTED] kirjoitti:
Please,
I have a question if exists in Perl somethink like keyword
'operator' in C++ ?
That will exist in perl6.
for example we can write in C++ :
class A {
A() { printf("Constructor of object class A\n"); }
~A() { printf("Destructor of o
Please,
I have a question if exists in Perl somethink like keyword
'operator' in C++ ?
for example we can write in C++ :
class A {
A() { printf("Constructor of object class A\n"); }
~A() { printf("Destructor of object class A\n"); }
};
A &operator + (A &
Sam Ruby wrote:
Leopold Toetsch wrote:
class_self."__super"(args)
so again the invocant is the first argument after interpreter.
Believe it or not, I think we are agreeing.
*g*
To invoke a method on an object using Parrot Calling Conventions, P2
needs to be the object used for dispatch purposes
Leopold Toetsch wrote:
Sam Ruby wrote:
A few observations, first from an Parrot Internal perspective... in
general, the code for the opcodes tend to do things like the following:
$1->vtable->get_string(interpreter, $1)
Note that the object tends to be repeated as the first argument. It
often th
Sam Ruby wrote:
A few observations, first from an Parrot Internal perspective... in
general, the code for the opcodes tend to do things like the following:
$1->vtable->get_string(interpreter, $1)
Note that the object tends to be repeated as the first argument. It
often the case that the first a
Leopold Toetsch wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
Leopold Toetsch writes:
Why do we have the special notion of current_object in the first place?
Why not just pass all in as P5, P6, ...?
I agree that this is the way to go. Especially if we have some marker
somewhere that tells us that
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
>> Why do we have the special notion of current_object in the first place?
>> Why not just pass all in as P5, P6, ...?
> I agree that this is the way to go. Especially if we have some marker
> somewhere that tells us that we were ca
Leopold Toetsch writes:
> Why do we have the special notion of current_object in the first place?
> Why not just pass all in as P5, P6, ...?
I agree that this is the way to go. Especially if we have some marker
somewhere that tells us that we were called as a method.
Luke
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The note here is that Parrot's MMD function signature for binary ops
> doesn't match what Python needs. Parrot is:
> void binary_mmd_op(pmc left, pmc right, pmc dest)
> where Python is:
> pmc dest = left.add(pmc right)
Perl6 allows (according
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 7:45 AM +0100 12/11/04, Leopold Toetsch wrote:
>>Thinking more about that it seems that we don't have much chance to keep
>>the current scheme that the destination is passed in.
> I fully expected this to be an issue. Perl 5 and perl 6 are going to
> ha
At 7:45 AM +0100 12/11/04, Leopold Toetsch wrote:
Thinking more about that it seems that we don't have much chance to keep
the current scheme that the destination is passed in.
(This is probably out of order -- I've a lot of mail I'm backed up on
unfortunately, but since it was CC'd directly to me
Leopold Toetsch wrote:
Comments?
leo
As enjoyable as this discussion has been, I'd like to ask that it be put
on hold for a few days. I've nearly got all the previously defined
languages/python/t/basic tests running, and once they are running, I'd
like to do a bit of refactoring and documentat
arrot is passing in the destination argument
> while these languages are returning the operator result.
> E.g.
> def myadd(self, r):
> return self - r
> class I(int):
> __add__ = myadd
> i = I(44)
> print i, i + 2
> Parrot is expecting and calling a su
g the operator result.
E.g.
def myadd(self, r):
return self - r
class I(int):
__add__ = myadd
i = I(44)
print i, i + 2
Parrot is expecting and calling a subroutine like:
.sub __add
.param left
.param right
.param dest
...
.end
and it's run in void context. This calling
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> There I got a error from 'parrot' claiming that he can't find the op
> 'exists_i_p_sc'.
exists I0, P0["the_key"]
is the syntax.
> I have added this case in 't/pmc/perlhash.t'. A patch is attached.
> If that op is indeed missing, I could go ahe
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #23427]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=23427 >
Hi,
I'm just working on a Getopt::Long::GetOptions subroutine for Parrot m4.
Of
At 10:22 PM 10/26/2002 +0530, Gopal V wrote:
If memory serves me right, Ramesh Ananthakrishnan wrote:
> I have this code
>
> set S12 ""
> set I0 0
> WHILE:
> concat S12 "hi"
> add I0 1
> lt I0 10 WHILE
> print S12
> ret
...
> Right version of Parrot, so i
At 8:46 AM -0700 10/26/02, Ramesh Ananthakrishnan wrote:
Well S12 does not Concatenate. I tried it a
million other times. If S12 is "" or " " or 0 it does
not concatenate but just stores "hi" once.
Right version of Parrot, so is this a bug? I hunted
round the bugdatabase for some time, but co
Clinton A. Pierce wrote:
At 08:46 AM 10/26/2002 -0700, Ramesh Ananthakrishnan wrote:
I have this code
set S12 ""
set I0 0
WHILE:
concat S12 "hi"
add I0 1
lt I0 10 WHILE
print S12
ret
Well S12 does not Concatenate.
> The example seems to run fine here.
If memory serves me right, Ramesh Ananthakrishnan wrote:
> I have this code
>
> set S12 ""
> set I0 0
> WHILE:
> concat S12 "hi"
> add I0 1
> lt I0 10 WHILE
> print S12
> ret
...
> Right version of Parrot, so is this a bug?
I get
No entries on stack!
hi
At 08:46 AM 10/26/2002 -0700, Ramesh Ananthakrishnan wrote:
I have this code
set S12 ""
set I0 0
WHILE:
concat S12 "hi"
add I0 1
lt I0 10 WHILE
print S12
ret
Well S12 does not Concatenate. I tried it a
million other times. If S12 is "" or " " or 0 it does
n
I have this code
set S12 ""
set I0 0
WHILE:
concat S12 "hi"
add I0 1
lt I0 10 WHILE
print S12
ret
Well S12 does not Concatenate. I tried it a
million other times. If S12 is "" or " " or 0 it does
not concatenate but just stores "hi" once.
Right version of P
[EMAIL PROTECTED] (Jeff) writes:
> The subject pretty much says it all. The format pretty much corresponds
> to the upcoming Exegesis. Major changes were to the modifiers, and a few
> syntax changes in the depths.
I've started rewriting my Shishi P6 RE module since it was becoming
way too clutter
The subject pretty much says it all. The format pretty much corresponds
to the upcoming Exegesis. Major changes were to the modifiers, and a few
syntax changes in the depths.
Sean, feel free to take what you can use (if anything) from this and
delete the rest.
--
Jeff <[EMAIL PROTECTED]>
In message <[EMAIL PROTECTED]>
Jeff <[EMAIL PROTECTED]> wrote:
> string.c - Added string_ord() and a _string_index() helper function to
> help making accommodating different encodings easier. Patched concat()
> to deal with null strings.
I have just committed an amendment to this to ma
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 03:35 AM 11/11/2001 -0500, James Mastros wrote:
>
> >No, it isn't. I'm not sure s->strlen is always gaurnteed to be correct;
> >string_length(s) is. (I found a case where it was wrong when coding my
> >version
ing_ord
>anywhere, and cvs logs don't show a string.c update.
>
> R.
>
> > -Original Message-
> > From: Jeff [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, November 12, 2001 11:46 PM
> > To: [EMAIL PROTECTED]
> > Subject: [PATCHES] or
D]
> Subject: [PATCHES] ord(i,s|sc(,i|ic)?) operator committed,
> fixed bug in
> concat()
>
>
> Documentation updated, and tests added to t/op/string.t.
> The CVS log details most of the changes, but basically:
>
> core.ops - Added ord() opcode
> string.c - Added s
Documentation updated, and tests added to t/op/string.t.
The CVS log details most of the changes, but basically:
core.ops - Added ord() opcode
string.c - Added string_ord() and a _string_index() helper function to
help making accommodating different encodings easier. Patched concat()
to deal with
On Mon, Nov 12, 2001 at 12:05:04PM -0500, Dan Sugalski wrote:
> Will. Docs, darn it! Must have docs! Tests, too, but if you have docs you
> can rope someone into writing the tests and the lot of 'ya can submit a
> chunk of patches. :)
And if you have docs and tests, you might be able to convinc
At 03:35 AM 11/11/2001 -0500, James Mastros wrote:
>On Sun, 11 Nov 2001, Alex Gough wrote:
> > On Sun, 11 Nov 2001, Alex Gough wrote:
> > > ook, cool, but string_length returns an INTVAL, not an int.
> > Remember that people who say "negative" usually mean "positive", they
> > just don't know it y
On Sun, 11 Nov 2001, Alex Gough wrote:
> On Sun, 11 Nov 2001, Alex Gough wrote:
> > ook, cool, but string_length returns an INTVAL, not an int.
> Remember that people who say "negative" usually mean "positive", they
> just don't know it yet. Always look on the bright si-ide of life, de
> do, de d
On Sun, 11 Nov 2001, Alex Gough wrote:
(but not quite enough...)
> On Sat, 10 Nov 2001, Jeff wrote:
>
> > string.pasm patches the operators mentioned
> > The other file, 'parrot.pasm', is a miniature Parrot compiler, written
> > in Parrot.
> >
> > The patches in the string.diff file are requir
On Sat, 10 Nov 2001, Jeff wrote:
> string.pasm patches the operators mentioned
> The other file, 'parrot.pasm', is a miniature Parrot compiler, written
> in Parrot.
>
> The patches in the string.diff file are required to make this work.
ook, cool, but string_length returns an INTVAL, not an int
to collect the number
of operators, write that, then write the operator stream out.
--Jeff
<[EMAIL PROTECTED]>
#--
#
# read_file
#
# read_file STRING, FILE_NAME
#
read_file macro R, S, CHUNK_SIZE, TEMP_STR
At 11:02 AM 10/3/2001 -0400, Bryan C. Warnock wrote:
>On Wednesday 03 October 2001 10:57 am, Dan Sugalski wrote:
> > Having said that, if you're looking to add optimizations into the
> > assembler, you're probably OK, but I'm not sure it's worth the effort at
> > the moment.
>
>Investigating what
On Wednesday 03 October 2001 10:57 am, Dan Sugalski wrote:
> Having said that, if you're looking to add optimizations into the
> assembler, you're probably OK, but I'm not sure it's worth the effort at
> the moment.
Investigating what effect a non-duplicated, non-overridable set of opcodes
(name
At 10:51 AM 10/3/2001 -0400, Bryan C. Warnock wrote:
>Is there anything that might alter an operation involving only constants
>and/or the constant registers at a time other than compile time (ie, when
>the opcode is generated.)?
For integer, string, and float constants (i.e. I, N, and S regs) n
Is there anything that might alter an operation involving only constants
and/or the constant registers at a time other than compile time (ie, when
the opcode is generated.)?
--
Bryan C. Warnock
[EMAIL PROTECTED]
D: Assembler does it
set_s_n # We don't have this
set_s_sc # We have this
set_s_s # We don't have this
I'd like to see the *to* ops renamed according to this plan for
symmetry reasons. "Set" is taken to mean: "load, copy or conv
45 matches
Mail list logo