7, The Perl Foundation.
+# Copyright (C) 2001-2008, The Perl Foundation.
# $Id$
use strict;
@@ -7,7 +7,7 @@
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test tests => 97;
+use Parrot::Test tests => 98;
=head1 NAME
@@ -2489,6 +2489,37 @@
/too many argument
On Sun Mar 16 09:20:55 2008, [EMAIL PROTECTED] wrote:
> On Mon Mar 12 05:40:14 2007, [EMAIL PROTECTED] wrote:
> > I'm still working on my use case, but it appears the new MetaClass PMC
> > (src/pmc/metaclass.pmc) could use this vtable method as well;
currently it
> > only has an add_attribute PMETH
Hello
> Just popping in to say that we cannot const any parms to vtable methods.
> Parrot can't impose promises on the called code.
The attached patch drops the :const attribute in isa and get_class
methods. A lot of cast warnings disappear, and all tests pass in my
system.
--
On Sat, Apr 19, 2008 at 01:55:18PM -0700, Mark Glines wrote:
> On Sat, 19 Apr 2008 21:45:49 +0200
> NotFound <[EMAIL PROTECTED]> wrote:
> > The same applies to some parameters attributed as non null, and
> > explicitly called with NULL argument in several locations. How can a
> > cleaner figure wh
On Apr 20, 2008, at 2:37 PM, Mark Glines wrote:
Failure to do so
results in an "incompatible pointer" warning, just like any other kind
of prototype mismatch.
And that in my mind is equivalent to "can't."
xoxo,
Andy
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
On Sun, 20 Apr 2008 21:01:01 +0200
NotFound <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 20, 2008 at 12:17 AM, Andy Lester <[EMAIL PROTECTED]>
> wrote:
>
> > Just popping in to say that we cannot const any parms to vtable
> > methods. Parrot can't impose promis
On Sun, Apr 20, 2008 at 12:17 AM, Andy Lester <[EMAIL PROTECTED]> wrote:
> Just popping in to say that we cannot const any parms to vtable methods.
> Parrot can't impose promises on the called code.
So take for example In default.pmc the method get_class:
VTABLE PMC *get_cla
Just popping in to say that we cannot const any parms to vtable methods.
Parrot can't impose promises on the called code.
Take for example whatever the vtable method is to return the count of
elements in the array. You'd think this would easily be constable, but
we cannot at this poi
looks to me
> like a problem, not a solution.
I agree. So I'm not blindly consting get_string() and hoping nothing
breaks. Instead, I'm whining about it on RT and p2, and hoping the
designers will say something useful. :)
(Hopefully either:
* "rip it all out, no vtable met
Hello.
> This is where I ran into problems. Is get_string constable? It seems
> possible that someone somewhere would want to cache a stringification
> that was computationally intensive, for later reuse. So now (as
> bernhard kindly pointed out to me), this is starting to sound like a
> d
le? It seems
possible that someone somewhere would want to cache a stringification
that was computationally intensive, for later reuse. So now (as
bernhard kindly pointed out to me), this is starting to sound like a
design issue.
Am I going down the wrong path here? If I can't consti
On Mon Mar 12 05:40:14 2007, [EMAIL PROTECTED] wrote:
> I'm still working on my use case, but it appears the new MetaClass PMC
> (src/pmc/metaclass.pmc) could use this vtable method as well; currently it
> only has an add_attribute PMETHOD.
>
Alek, Are you still planning work on this patch? (No
Will Coleda wrote:
The
short-term hack for accessing the low-level PMC within the object is
to grab the proxy object for that parent:
$P4 = getattribute $P3, ['String'], 'proxy'
$P4 = 'urk'
urk indeed. Yah, I wouldn't have gotten that from reading PDD15.
It's not part of the spec, an
On Oct 22, 2007, at 11:26 PM, Allison Randal wrote:
Will Coleda (via RT) wrote:
$ ./parrot foo.pir
Method 'set_string_native' not found
current instr.: 'test' pc 20 (foo.pir:8)
We wanted to do this in Tcl to simplify TclConst, but were unable
to. Presumably it's just that it's a vtable we'r
Will Coleda (via RT) wrote:
$ ./parrot foo.pir
Method 'set_string_native' not found
current instr.: 'test' pc 20 (foo.pir:8)
We wanted to do this in Tcl to simplify TclConst, but were unable to.
Presumably it's just that it's a vtable we're trying to super, not a
method...
The problem here
# New Ticket Created by Will Coleda
# Please include the string: [perl #46731]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46731 >
$ cat foo.pir
.sub test :main
$P1 = get_class 'String'
$P2 = subclass $P1, 'Goofy'
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #42969]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42969 >
In r18267, pre Parrot 0.4.11, Jonathan deprecated following :vtable meth
On 5/7/07, Bram Geron <[EMAIL PROTECTED]> wrote:
Alek, I made the bulk of the patch before I dug through the other mails
and saw your mail. I'm sorry if you were still planning on sending it.
Don't feel sorry at all. I got halfway through the patch before I got
distracted by other things.
/* params signature pmc if it is non-const */
PMC *returns_signature; /* returns signature pmc if it is non-const */
Index: t/op/calling.t
===
--- t/op/calling.t (revision 18433)
+++ t/op/calling.t (working c
I believe you're
thinking of properties. I'll put together some sketch code with what
I already have and post that.
Thanks,
Alek Storm
On 3/5/07, chromatic <[EMAIL PROTECTED]> wrote:
> On Sunday 04 March 2007 19:13, Alek Storm wrote:
>
> > In fact, these vtable method
orm wrote:
> In fact, these vtable methods *encourage* the use of many languages in
> a single application. For example, without these methods, programmers
> have to be aware of the semantics of the Smalltalk object system and
> use extra code when dealing with Smalltalk objects, breaki
On Sunday 04 March 2007 19:13, Alek Storm wrote:
> In fact, these vtable methods *encourage* the use of many languages in
> a single application. For example, without these methods, programmers
> have to be aware of the semantics of the Smalltalk object system and
> use extra code
Perl strings work differently than Python
strings is cited as one of the reasons why Parrot is so useful for
interoperating between languages, and the object system is a logical
addition to this.
In fact, these vtable methods *encourage* the use of many languages in
a single application. For ex
On Mar 4, 2007, at 12:40 PM, Alek Storm wrote:
For the same reason we have set_attr, set_attr_str, get_attr, and
get_attr_str, even though they're only used by ParrotObject - it
allows for
multiple, concurrent object systems. This goal is mentioned in PDD
15, in
"What The Bytecode Sees". Why
I'm almost done with a different patch that preserves the parent context for
the purpose of returning values into it. All further tailcalled contexts
are freed as normal. That's pretty vague, but it's easier just to see the
code. I just haven't had time to finish and release it.
Thanks,
Alek S
a RT) wrote:
>
> This patch adds the add_attr, rem_attr, and rem_attr_str vtable
> methods. These will come in handy for Ruby's metaclasses or
> Smalltalk's class objects. The only PMC currently affected by this is
> ParrotClass, and the rem_attr and rem_attr_str methods are
Bram Geron (via RT) wrote:
Tail calls from within v-table methods are broken, the tail-called sub
(or method) will not return correct values.
When method A tailcalls sub B, B's set_returns stores its opcode
number (and with it, which registers should be returned), but the
low-level vtable code g
Alek Storm (via RT) wrote:
This patch adds the add_attr, rem_attr, and rem_attr_str vtable
methods. These will come in handy for Ruby's metaclasses or
Smalltalk's class objects. The only PMC currently affected by this is
ParrotClass, and the rem_attr and rem_attr_str methods
Alek Storm wrote:
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #41619]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41619 >
This patch adds the add_attr, rem_attr, and rem_at
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #41619]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41619 >
This patch adds the add_attr, rem_attr, and rem_attr_str vtable
methods
# New Ticket Created by Bram Geron
# Please include the string: [perl #41583]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41583 >
---
osname= linux
osvers= 2.6.18.3
arch= i486-linux-gnu-thread-multi
cc= cc
---
Flag
Bob Rogers wrote:
>
>There's no way to get full Continuations working around such C code
> barriers,
>except by *not* entering secondary runloops at all for these cases[1].
> This
>could be achieved by (optionally) returning a new PC for all vtable/MMD
>functions that is, by c
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Sun, 30 Jul 2006 21:58:36 +0200
Am Sonntag, 30. Juli 2006 04:50 schrieb Bob Rogers:
> The attached patch detects cases where a continuation tries to enter a
> runloop different from the one that is executing, and prints a warning
>
Am Sonntag, 30. Juli 2006 04:50 schrieb Bob Rogers:
> The attached patch detects cases where a continuation tries to enter a
> runloop different from the one that is executing, and prints a warning
> to stderr.
Looks very sane and appliable to me.
Thanks,
leo
From: chromatic <[EMAIL PROTECTED]>
Date: Sat, 29 Jul 2006 21:52:59 -0700
You should be able to replace this with pir_output_is( ..., todo => '...' );
Good idea; thank you. (I had forgotten about that syntax.)
-- Bob
On Saturday 29 July 2006 19:50, Bob Rogers wrote:
> +local $TODO = 'runloop shenanigans';
> +# stringification is handled by a vtable method, which runs in a second
> +# runloop. when an error in the method tries to go to a Error_Handler
> defined +# outside it, it winds up going to the inner runl
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Thu, 27 Jul 2006 20:50:18 +0200
Am Donnerstag, 27. Juli 2006 19:44 schrieb Matt Diephouse:
> Running this gives:
>
> caught
> No exception to pop.
PIR code running on behalf of a vtable (or MMD) function is implemented
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Thu, 27 Jul 2006 20:50:18 +0200
Am Donnerstag, 27. Juli 2006 19:44 schrieb Matt Diephouse:
> Running this gives:
>
> caught
> No exception to pop.
PIR code running on behalf of a vtable (or MMD) function is implemented
Am Donnerstag, 27. Juli 2006 19:44 schrieb Matt Diephouse:
> .sub __get_string :method
> $P0 = new .Exception
> throw $P0
> .end
>
> Running this gives:
>
> caught
> No exception to pop.
PIR code running on behalf of a vtable (or MMD) function is implemented by
entering a se
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #39988]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39988 >
The example:
.sub main :main
$P0 = get_hll_global ['Foo'], 'load'
$P0()
Sam,
Just wondering what the status is on python/parrot/pirate/pyrate.
These both look outdated.
http://www.intertwingly.net/stories/2004/10/05/pyrate.zip
http://pirate.versionhost.com/viewcvs.cgi/pirate/
Is there a up to date cvs repo?
Can we get this code checked into the parrot svn repo?
Kevin T
Sam Ruby <[EMAIL PROTECTED]> wrote:
> As long as find_method itself can be overridden, this above is merely a
> description of the default behavior, not a hard requirement.
Yes, of course. C *is* overridable and, as all method lookup
is calling C, the code can do whatever is needed. I'm
describin
"()# $x = ~$y string kontext
This easily allows overloading of all the vtable methods. The PIC code
gets even rid of the additional indirection as the function is called
directly from opcodes. The vtable slots are just for calling these
methods from within C source.
As long as find_
as methods, like now with the METHOD keyword. This allows
eventually code like this:
Px = Py."__pop_pmc"()
or
Px = Py."__string"()# $x = ~$y string kontext
This easily allows overloading of all the vtable methods. The PIC code
gets even rid of the additional
Sam Ruby <[EMAIL PROTECTED]> wrote:
> How about:
>METHOD INTVAL find(PMC* substr) {
Sure, we need a return value ;)
> Patch attached. Should the Object parameter be named "pmc" or "self"?
Great. I'd say for consistency "pmc".
> - Sam Ruby
Thanks, applied.
leo
gt;>I'm not overly concerned about __init methods, in fact, my concern is
>>the opposite: I'd like to solicit opinions on the viability of extending
>>pmc2c2.pl to enable non-vtable methods to be defined, in C, in the .pmc
>>file itself.
>
> That sounds great.
>
overriden directly. It could be
useful that they first do their intended job and then call out to user
code, if present.
> I'm not overly concerned about __init methods, in fact, my concern is
> the opposite: I'd like to solicit opinions on the viability of extending
> pmc2c2.
hods
won't get called. However, any subclasses will be aware of both the
__init and regular methods. I've attached the test I produced.
I'm not overly concerned about __init methods, in fact, my concern is
the opposite: I'd like to solicit opinions on the viability of extend
At 11:29 PM -0700 8/18/02, Brian Ingerson wrote:
>On 18/08/02 16:06 -0400, Dan Sugalski wrote:
>> Okay, here's two new vtable methods
>>
>> freeze(PMC) - Responsible for freezing a PMC to the current freeze
>> data stream. Throws an exception on error
>
On 18/08/02 16:06 -0400, Dan Sugalski wrote:
> Okay, here's two new vtable methods
>
>freeze(PMC) - Responsible for freezing a PMC to the current freeze
> data stream. Throws an exception on error
>
>thaw(PMC) - A class method that thaws a PMC from the c
Okay, here's two new vtable methods
freeze(PMC) - Responsible for freezing a PMC to the current freeze
data stream. Throws an exception on error
thaw(PMC) - A class method that thaws a PMC from the current thaw data stream
Both of these should use the freeze/thaw API--I'l
At 6:23 PM -0300 5/20/02, Daniel Grunblatt wrote:
>On Mon, 20 May 2002, David M. Lloyd wrote:
>
>> What about subroutines? Are bsr & jsr the way it's gonna be or is there
>> a rework in the works?
>
>docs/pdds/pdd03_calling_conventions.pod :)
Ans I think I need to get that tidied up soon, as t
#x27;ve looked it over but it doesn't say "Subroutines are called via
bsr" or "Subroutines are called via vtable methods" or whatever. It seems
just to talk about stack usage and so on.
The regular expression PDD talks about using bsr to call into a regular
expression.
- D
<[EMAIL PROTECTED]>
On Mon, 20 May 2002, David M. Lloyd wrote:
> What about subroutines? Are bsr & jsr the way it's gonna be or is there
> a rework in the works?
docs/pdds/pdd03_calling_conventions.pod :)
On Mon, 20 May 2002, David M. Lloyd wrote:
> Has anyone given any thought to this problem yet?
>
> Will we be able to do this or do we need a special vtable whose entries
> automatically do a callback to Parrot?
For that matter, what about calling C functions from Parrot? Loading PMCs
dynamical
Has anyone given any thought to this problem yet?
Will we be able to do this or do we need a special vtable whose entries
automatically do a callback to Parrot?
- D
<[EMAIL PROTECTED]>
Okay, I'm working on redoing the vtable docs, since they're both
deficient and decaying. A question came up a while back about what to
do with P1 in an opcode such as:
add P1, P2, P3
And the answer is that opcode function looks like:
p1->vtable->assign_pmc(p1, p2->vtable->add_pm
On Sun, Feb 03, 2002 at 09:29:27PM +0100, Juergen Boemmels wrote:
> Hi there,
>
> I played again a little with the vtables.
> I noticed that all *.pmc function implement the methods type and name
> are implemented the same way. Then I was wondering if its possible to
> autogenerate this functions
Hi there,
I played again a little with the vtables.
I noticed that all *.pmc function implement the methods type and name
are implemented the same way. Then I was wondering if its possible to
autogenerate this functions in the pmc2c.pl
This patch implements autogeneration of this functions, and
At 11:40 PM + 1/30/02, Nicholas Clark wrote:
>On Wed, Jan 30, 2002 at 06:23:43PM -0500, Dan Sugalski wrote:
>> We're adding the following:
>>
>> INTVAL get_character(PMC *, INTVAL)
>> INTVAL get_character(PMC *, KEY *, INTVAL)
>>
>> to return the character at position INTVAL in the p
On Wed, Jan 30, 2002 at 06:23:43PM -0500, Dan Sugalski wrote:
> We're adding the following:
>
>INTVAL get_character(PMC *, INTVAL)
>INTVAL get_character(PMC *, KEY *, INTVAL)
>
> to return the character at position INTVAL in the passed in PMC.
are characters really INTVAL? I have this g
We're adding the following:
INTVAL get_character(PMC *, INTVAL)
INTVAL get_character(PMC *, KEY *, INTVAL)
to return the character at position INTVAL in the passed in PMC.
--
Dan
--"it's like this"
At 12:42 PM 1/4/01 +, Simon Cozens wrote:
>It's time to design the RTL and API. Can I have suggestions for vtable
>methods, please?
I can go you one better--I've a partial vtable PDD done. I'll patch it up a
bit when I get into the office later and send it on.
One thi
It's time to design the RTL and API. Can I have suggestions for vtable
methods, please?
--
In related wibbling, I can see an opening for the four lusers of the
Apocalypse... "I didn't change anything", "My e-mail doesn't work",
"I can't print&quo
64 matches
Mail list logo
