2009/10/28 Will Coleda via RT :
> On Wed Oct 29 10:30:54 2008, alli...@perl.org wrote:
>> Original Message
>> Subject: Re: Segfault in Lua exception handler
>> Date: Sat, 11 Oct 2008 23:49:09 +0200
>> From: François Perrad
>>
>> 2008/10/8 François Perrad :
>> >
>> > I try to rest
On Wed Feb 25 16:08:29 2009, jk...@verizon.net wrote:
> On Thu Jan 29 06:15:28 2009, Whiteknight wrote:
> >
> > has the remove_pic branch landed yet?
>
>
> Well, it's still an active branch in SVN. So I would guess not.
Per discussion on the mailing list, we're removing the remove_pic branch
On Mon, Feb 02, 2009 at 09:27:10AM -0800, Andrew Whitworth via RT wrote:
> On Wed Jun 04 16:04:07 2008, pmichaud wrote:
> > I'm just about to commit a change to namespace.pmc that allows
> > the 'add_sub' method to store MultiSub PMCs as well as Sub PMCs.
> >
> > However, the change I'm committing
Will Coleda via RT wrote:
Apparently "remove the files" isn't exactly what was meant here. This probably removes the
need for the remove_pic branch, which is in the process of taking this to its literal extreme.
We do need to remove the files, and the remove_pic branch is on the
right track
On Thursday 25 December 2008 23:29:28 Allison Randal via RT wrote:
> CGP is too important to be deprecated over something as small as this.
If it were important, we'd test it and maintain the code. We don't, ergo
-- c
Will Coleda via RT wrote:
I created a branch (remove_pic) to remove src/pic.c; This led to the removal of pic.ops, and
changes in imc, packfile... lots of references to PIC.
chromatic mentioned on #parrot that if we remove PIC, we're going to break all the
predereferenced runcores. After som
On Wed, Dec 24, 2008 at 09:55:58AM -0600, Allison Randal wrote:
>> Within the cmp op bodies, we *know* the arity and most of the types of MMD-
>> participant arguments at compile time. We can get the types of PMC
>> participants within the body of the op itself. Thus we could
chromatic wrote:
Within the cmp op bodies, we *know* the arity and most of the types of MMD-
participant arguments at compile time. We can get the types of PMC
participants within the body of the op itself. Thus we could avoid most of
the argument marshalling and counting and analysis if we
ut performance numbers right now either, but the known
problems are the multiple calling conventions conversions to compare an
Integer PMC with anything else through MMD and our garbage collector. (I
suspect Parrot's calling conventions are likewise full of strange decisions.)
You (or any
On Tue, 2008-12-23 at 17:31 -0800, Will Coleda via RT wrote:
> chromatic mentioned on #parrot that if we remove PIC, we're going to break
> all the
> predereferenced runcores. After some discussion, this probably means ripping
> out:
>
> 16:42 <@chromatic> Everything other than the default core
- creates a new return PMC for all return argument
- creates a new CPointer for each return argument
- pushes arguments onto the CallSignature PMC
- builds a type tuple for MMD
- loops through signature stored i
Will Coleda via RT wrote:
* Parrot_mmd_add_function
- src/inter_create.c //make_interpreter
Delete that line from src/inter_create.c. Also delete the line before
which initializes 'interp->binop_mmd_funcs' to NULL.
These two lines are initializing the storage for the old
On Sun Oct 19 18:34:40 2008, [EMAIL PROTECTED] wrote:
> I probably spoke too soon. We have a Smolder failure report for this
> test on AIX. So I'm going to reopen the ticket and rename it "failing
> intermittently on various OSes."
The only data I have available on this is from our Smolder repor
# New Ticket Created by Jerry Gay
# Please include the string: [perl #60626]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60626 >
from DEPRECATED.pod:
=item Old-style MMD functions [post 0.
# New Ticket Created by François PERRAD
# Please include the string: [perl #60292]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60292 >
Since r32189, the following code gives a wrong result :
.HLL 'Lua', 'lua_group'
.sub
On Wed Oct 15 17:48:28 2008, Whiteknight wrote:
>
> With the pdd27mmd branch merged in now, what's the status of this request?
The MMD table is now just a namespace, and namespaces are shareable
between interpreters. So, resolved.
Allison
# New Ticket Created by Allison Randal
# Please include the string: [perl #60206]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60206 >
Original Message
Subject: Re: Segfault in Lua exception handler
Date
From: chromatic <[EMAIL PROTECTED]>
Date: Mon, 27 Oct 2008 20:00:50 -0700
On Monday 27 October 2008 19:36:58 chromatic wrote:
> I think I know how to promote primitive registers to their
> autoboxed PMCs in that function; Parrot's calling conventions should take
> care of the re
On Monday 27 October 2008 19:36:58 chromatic wrote:
> I think I know how to promote primitive registers to their
> autoboxed PMCs in that function; Parrot's calling conventions should take
> care of the rest.
Fixed in r32211. All tests pass (including the TODO test I added for this).
-- c
On Monday 27 October 2008 19:26:31 Bob Rogers wrote:
> All true. But it's unfortunate that the Parrot type system considers
> "int" and "Integer" unrelated. As a result, MMD prevents autoboxing
> (when chromatic and I had expected otherwise).
I'm not sur
applicable methods" is
actually what I would expect from the code given, since there are
no methods defined taking the 'string' or 'int' type as the first
argument.
All true. But it's unfortunate that the Parrot type system considers
"int" and &quo
On Sun, Oct 26, 2008 at 09:37:36PM -0400, Bob Rogers wrote:
> .sub 'main' :main
> foo('Hello')
> .end
> .sub foo :multi(String)
> .param pmc s
>
> say s
> .end
> [...]
>Which brings us to an interesting question: How can you decide wha
y.html?id=60124 >
I expect this code to dispatch properly; autoboxing works and :optional
parameters work, at least separately. When combined, they appear not to
work.
I think this is purely an autoboxing+MMD issue: The following
simplified version fails in the same way, even wi
# New Ticket Created by chromatic
# Please include the string: [perl #60124]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60124 >
I expect this code to dispatch properly; autoboxing works and :optional
parameters work, a
On Tue, Oct 21, 2008 at 11:01:21AM -0700, Andrew Whitworth via RT wrote:
> On Tue Oct 21 10:47:43 2008, Whiteknight wrote:
> > On Tue Oct 21 07:53:35 2008, pmichaud wrote:
> > > As of r31667 (pre-mmd), the following worked:
> > >$P0 = subclass 'Integer&
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #60036]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60036 >
As of r31667 (pre-mmd), the following worked:
r31667$ cat y.pir
.sub &#
On Sun Aug 15 13:21:16 2004, coke wrote:
> Make the MMD tables shareable between interpreters for faster
> startup. (Though there are issues with this)
>
> (From the TODO file)
With the pdd27mmd branch merged in now, what's the status of this request?
--
Andre
On Tue Oct 02 10:01:59 2007, pcoch wrote:
> In src/mmd.c there is the todo item within mmd_register():
>
> TODO - Currently the MMD system doesn't handle inheritance and best match
> searching, as it assumes that all PMC types have no parent type. This
> can be considere
On Tue Oct 02 10:00:49 2007, pcoch wrote:
> In src/mmd.c there is the todo item within mmd_add_function():
>
> TODO change this to a MMD register interface that takes a function *name*.
>
> This needs implementing.
Now in src/multidispatch.c; Parrot_mmd_add_function()
--
Will "Coke" Coleda
Patrick R. Michaud via RT wrote:
On Thu, Sep 25, 2008 at 05:05:16AM -0700, Vasily Chekalkin via RT wrote:
This bug caused by "runops_args" which doesn't populcate
interp->current_args which used in "mmd_arg_tuple_func" to calculate
signature for MMD.
chromatic
Hello.
This bug caused by "runops_args" which doesn't populcate
interp->current_args which used in "mmd_arg_tuple_func" to calculate
signature for MMD.
--
Bacek.
On Thu, Sep 25, 2008 at 05:05:16AM -0700, Vasily Chekalkin via RT wrote:
> This bug caused by "runops_args" which doesn't populcate
> interp->current_args which used in "mmd_arg_tuple_func" to calculate
> signature for MMD.
chromatic has suggested that we s
# New Ticket Created by Vasily Chekalkin
# Please include the string: [perl #59288]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=59288 >
Hello.
There is simple test case.
$ cat mmd.pid
.sub 'main'
.local pmc arr
chromatic wrote:
t/op/calling_61.pir crashes because Parrot's trying to treat the number -1 as
a PMC. Why?
The desired MMD sub should take two PMCs and returns an INTVAL (frame #5,
signature "PP->I"), but the invoked MMD sub takes two PMCs and returns a PMC.
The crash co
03acf "PP->I") at src/multidispatch.c:629
#6 0xb7e00166 in Parrot_default_cmp (interp=0x804f040, pmc=0x80f3930,
value=0x80f3914) at ./src/pmc/default.pmc:2447
#7 0xb7ccacfa in Parrot_lt_p_i_ic (cur_opcode=0x8127c88, interp=0x804f040)
at src/ops/cmp.ops:315
The desired MMD sub s
Cs as they all get compiled together into libparrot.
That's a real violation of encapsulation for dynpmcs though, and it's the
reason why we export some 12,000 functions from libparrot.
In the case of MMD, we also need to initialize MMD table entries for roles and
other abstract PMCs.
jerry gay wrote:
On Mon, Sep 8, 2008 at 1:09 AM, Allison Randal <[EMAIL PROTECTED]> wrote:
a) Do abstract base classes as currently implemented in Parrot serve any
useful purpose? If not, eliminate them.
can they be replaced by roles?
Potentially, yes. In the case of the scalar PMC it would
laced by roles?
Exactly my thought. We would need some way to:
* mix in VTABLE and METHOD entries at initialization time (preferably in the
former case by not referring to function pointers directly)
* register MMD entries only once
-- c
On Mon, Sep 8, 2008 at 1:09 AM, Allison Randal <[EMAIL PROTECTED]> wrote:
> a) Do abstract base classes as currently implemented in Parrot serve any
> useful purpose? If not, eliminate them.
>
can they be replaced by roles?
~jerry
chromatic wrote:
The scalar PMC is abstract, but it contains multis that need registration with
the MMD system at initialization time. PMCs containing multis register those
multis in their Parrot__class_init() functions.
At least, non-abstract PMCs do.
I ran into a similar problem with my
The scalar PMC is abstract, but it contains multis that need registration with
the MMD system at initialization time. PMCs containing multis register those
multis in their Parrot__class_init() functions.
At least, non-abstract PMCs do.
I ran into a similar problem with my vtable cloning work
I've posted the task list for the MMD branch to the wiki:
http://www.perlfoundation.org/parrot/index.cgi?pdd27mmd_tasklist
There's really only one task: merge the two MMD implementations into
one. But, I've split it out into a series of smaller tasks so we can
share the
n't participate properly in Parrot's MMD:
$ cat v.pir
.sub 'main' :main
$P0 = get_hll_namespace ['ABC']
$P1 = newclass $P0
$P2 = new $P1
'foo'($P2)
.end
.sub 'foo' :multi(_)
say 'wrong
# New Ticket Created by Vasily Chekalkin
# Please include the string: [perl #55506]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55506 >
Hello.
MMD try to deref parameters during dispatch.
rakudo: sub is($q, $e,
On Mon Jun 09 05:49:29 2008, bacek wrote:
> On Sun Jun 08 23:14:00 2008, bacek wrote:
> > Hello.
> >
> > MMD try to deref parameters during dispatch.
> >
>
> Trivial patch attached.
Patch rejected -- the solution here is to keep from generating NULL
parameter
On Sun Jun 08 23:14:00 2008, bacek wrote:
> Hello.
>
> MMD try to deref parameters during dispatch.
>
Trivial patch attached.
--
Bacek.
--- a/src/mmd.c
+++ b/src/mmd.c
@@ -1265,7 +1265,10 @@
arg = constants[idx]->u.key;
else
Jonathan Worthington wrote:
Yup. To be able to implement Perl 6's cmp as an MMD method on the
junction, the ability to return a PMC as well as just a -1, 0 or 1 would
be handy. Otherwise we just special case the implementation of the <=>
and cmp operators to get junctions to thr
language all of a==b, ab evaluate to false if a and b are of different types.
Yup. To be able to implement Perl 6's cmp as an MMD method on the
junction, the ability to return a PMC as well as just a -1, 0 or 1 would
be handy. Otherwise we just special case the implementation of the <=&g
We could maybe assume that the ordering is well defined between the
instances of a PMC class. But cmp needs to compare instances of
different PMC classes as well, for which a well defined ordering is
less probable.
I would not be surprised if in some dynamic language all of a==b, ab evaluate to fa
I agree. See
http://www.nntp.perl.org/group/perl.perl6.internals/2007/08/msg39889.html
false
I've run up against a Parrot issue that is kinda getting in the way.
Basically, all comparison operations have been implemented in Parrot
using the cmp function rather than having separate MMD methods for less
than and greater than. I've got equality to work by tweaking the =
/MMD_/;# TODO all
Which looks like if a vtable entry matches MMD then we skip this. My guess
is that we shouldn't be skipping such things here, although it's not too
clear from the todo comment exactly what should be done.
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46861]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46861 >
In t/pmc/exporter.t there is the todo item:
# TODO test exporting mmd subs
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46619]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46619 >
In src/pmc/integer.pmc there is the todo item (with some context):
/* XXX create
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #45943]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45943 >
In src/mmd.c there is the todo item within mmd_register():
TODO - Currently the
o a MMD register interface that takes a function *name*.
This needs implementing.
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #43737]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43737 >
In the file lib/Parrot/Pmc2c.pm there is the todo item:
# XXX quick hack - to get
# New Ticket Created by Ron Blaschke
# Please include the string: [perl #43535]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43535 >
It seems like function pointers were required to be aligned and the
extra bits were used
It seems to work in general, but in some cases (especially when I
allocate too much memory) it causes me a segfault
or an error like: Trace/breakpoint trap (core dumped)
It was caused by some unitialized memory in src/mmd.c. rt #43105 solves it.
--
Mehmet
re dumped)
~/parrot_svn/parrot/languages/pjs$ parrot --no-gc mmd.pir
43 bitwise_and P4, P2, P3 P4=PjsNumber=PMC(0xb60c0fa8)
P2=PjsNumber=PMC(0xb60c0fd0) P3=PjsNumber=PMC(0xb60c0fbc)
Segmentation fault (core dumped)
I am new to debugging, but (if I didn't do anything wrong) I t
# New Ticket Created by Jonathan Worthington
# Please include the string: [perl #42287]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42287 >
Multi-method dispatch needs to be documented in one of the PDDs or have
a PDD o
# New Ticket Created by Will Coleda
# Please include the string: [perl #41374]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41374 >
To replace removal of Perl PMCs* from core: still should test this
functionality.
See
table.
> That
> hack and the whole table needs to be replaced by a more densly packed infix
> MMD cache representation (that was mmd_table actually is).
Thanks for your explanations!
Ron
be replaced by a more densly packed infix
MMD cache representation (that was mmd_table actually is).
leo
chromatic wrote:
> On Wednesday 20 December 2006 11:24, Ron Blaschke wrote:
>
>> - The assertion seems to check that the lowest two bits of a function
>> pointer are zero. Why's that?
>
> Presumably because pointers need a specific alignment, so those two bits will
> always be zero on a raw poi
On Wednesday 20 December 2006 11:24, Ron Blaschke wrote:
> - The assertion seems to check that the lowest two bits of a function
> pointer are zero. Why's that?
Presumably because pointers need a specific alignment, so those two bits will
always be zero on a raw pointer -- and thus, they're ava
Sorry to bring this up again, but I hope someone can help me with this.
I'm trying to compile Parrot on Windows XP / Visual C++ with assertions
enabled, that is, without C.
When running miniparrot I receive the following error:
Assertion failed: (PTR2UINTVAL(mmd_table[i].func_ptr) & 3) == 0, fil
On Friday 24 November 2006 13:47, Matt Diephouse wrote:
> The attached patch does the following:
>
>* Removes MultiSub logic from Parrot_find_name_op
>* Removes the following functions
> - Parrot_MMD_search_default_inline (unused)
> - Parrot_MMD_search_default_func (unused after
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #40978]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40978 >
The attached patch does the following:
* Removes MultiSub logic from Parrot_find_n
.Sub F1 = "f1"
find_type $I0, "thread"
$P1 = new $I0, F1
$P2 = new $I0, F1
$P0 = add $P1, $P2
end
.end
.sub 'f1'
print "f1()\n"
end
.end
I obtain the following error :
MMD function __add not found for types (86, 86)
Am Sonntag, 16. Juli 2006 18:46 schrieb Ron Blaschke:
> Possible Solution: Attached patch adds a block around the MMD
> initializer code, which should bring the generated code back to valid C.
Thanks, applied - r13329.
leo
ollowing initialization, in the middle of
function Parrot_LuaNumber_class_init.
int my_enum_class_LuaString = pmc_type(interp,
string_from_const_cstring(interp, "LuaString", 0));
Possible Solution: Attached patch adds a block around the MMD
initializer code, which should bring th
Rather than adding another file, I'd recommend putting these under
DESIGN in docs/ROADMAP. Then they're all in one place for Chip when
he gets more tuits.
I added a link to this one there.
Regards.
On Jul 25, 2005, at 10:53 AM, Leopold Toetsch wrote:
Nicholas Clark wrote:
This all g
Nicholas Clark wrote:
This all got Warnocked, didn't it?
Having read it twice, I don't think I'm going to get closer to a decent
response than "er, this is really a call for the designer to make, isn't it?"
Mway be it's time to start a WARNOCKED file in parrot's root dir and
collect such und
On Mon, Apr 18, 2005 at 12:15:34PM +0200, Leopold Toetsch wrote:
> Below is some stuff, which I'm unsure of how it should be implemented
> eventually. Input is highly welcome.
> TODO items and design issues
>
> 1) bitwise or, and, xor
>
> We currently have two distin
On Wed, Jun 08, 2005 at 10:26:59PM +0100, The Perl 6 Summarizer wrote:
> Missing MMD default functions
> Dan was somewhat bemused to find that the MMD functions' defaults had
> disappeared when he did a sync with subversion. He wondered whether this
> was deliberat
At 8:14 PM -0400 6/3/05, Chip Salzenberg wrote:
On Fri, Jun 03, 2005 at 02:55:52PM -0400, Dan Sugalski wrote:
Dan was expecting sane defaults, that is when I do addition with two
PMCs that haven't otherwise said they behave specially that the
floating point values of the two PMCs are retrieve
On Fri, Jun 03, 2005 at 02:55:52PM -0400, Dan Sugalski wrote:
> Dan was expecting sane defaults, that is when I do addition with two
> PMCs that haven't otherwise said they behave specially that the
> floating point values of the two PMCs are retrieved and added
> together.
Is deriving from Flo
t;
> ++verbose please.
Perhaps I misunderstood, but I thought you were implying that MyFloat
would automatically have some features that Float did not, just by
virtue of the derivation. Sorry if I got that wrong.
> I still don't see the point that an arbitrary "Foo" class shal
On Fri, Jun 03, 2005 at 02:50:38PM +0200, Leopold Toetsch wrote:
> I've announced and summarized all these changes, e.g.
> http://xrl.us/gayp on Apr. 8th
I didn't realize the implications when that was posted. I think the
native fallbacks are important.
> cl = subclass "Float", "MyFloat"
In
At 2:21 PM -0400 6/3/05, Chip Salzenberg wrote:
One could argue that by providing __get_integer, Foo class is
automatically implying that it would serve where an Integer would.
This is obviously what Dan was expecting. :-,
Dan was expecting sane defaults, that is when I do addition with two
P
)
we have
MMD_DEFAULT: {
yada ..
exactly the code that was in mmd_default: .. _add_pmc
}
This installs the MMD funtion add(Float, Any)
With a little change in parsing inside the PMC compiler we could define,
that:
MMD_DEFAULT, MMD_DEFAULT: {}
also defines the LHS of the operation
... and probably dangerous. Given two array-ish instances of a class
that implements __get_integer (get array size), Parrot would happily
execute:
$P0 = a << b# or other bitwise operations
By just depending on the fact that a missing __get_integer or
__get_number would inhibit the exec
At 2:50 PM +0200 6/3/05, Leopold Toetsch wrote:
Dan Sugalski wrote:
Right, so to reduce code duplication you remove stuff that's
working so people have to go reimplement the code. That makes
*perfect* sense.
I've announced and summarized all these changes, e.g.
http://xrl.us/gayp on Apr. 8t
Dan Sugalski wrote:
Right, so to reduce code duplication you remove stuff that's working so
people have to go reimplement the code. That makes *perfect* sense.
I've announced and summarized all these changes, e.g.
http://xrl.us/gayp on Apr. 8th
And, what is wrong about:
cl = subclass "Flo
backs for pretty
much all of the MMD functions now we've got nothing and I'm having to
install a lot of crud I never used to have to.
You are not very verbose about what actually fails, but I presume that
you are speaking of ParrotObjects, which happened to call the mmd
fallback functions
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I sync'd up with subversion this afternoon, and I'm finding that a
> *lot* of things that used to work for me are now breaking really
> badly. Specifically where there used to be sane fallbacks for pretty
> much all of the
I sync'd up with subversion this afternoon, and I'm finding that a
*lot* of things that used to work for me are now breaking really
badly. Specifically where there used to be sane fallbacks for pretty
much all of the MMD functions now we've got nothing and I'm having to
ins
Jeff Horwitz wrote:
[ mmd test code ]
the pmc version of bar() is never called, even when passing a PMC.
This is fixed now. A differing argument count had a too low distance
penalty. But please note that the MMD system still has no clue what is
an invocant and what a plain call argument
[ cc'ed list ]
Chip Salzenberg wrote:
On Tue, May 24, 2005 at 02:42:47PM -0400, Jeff Horwitz wrote:
.sub bar method, @MULTI(Foo, pmc)
At first blush, I think mmd based on representation choice ($I vs. $P)
is a mistake. Why should an integer in a $P0 be mmd'd differently from
an
On Tue, 24 May 2005, Leopold Toetsch wrote:
> Multi subs and especially multi methods are barely tested. 'pmc' or '_'
> should match 'Any' PMC, so that's for sure a bug. Can you please provide
> a test-like sample file to investigate, thanks.
here you go. it should print "string PMC nothing", bu
Jeff Horwitz wrote:
for mod_parrot i want to support both passing both PMCs and native types
to the apache API, depending on the HLL. MMD was doing a great
job handling this for me until i ran into a problem.
given the following methods:
.sub bar method, @MULTI(Foo, string)
.sub bar method
for mod_parrot i want to support both passing both PMCs and native types
to the apache API, depending on the HLL. MMD was doing a great
job handling this for me until i ran into a problem.
given the following methods:
.sub bar method, @MULTI(Foo, string)
.sub bar method, @MULTI(Foo, pmc)
.sub
one of the
PMCs usually.
This sounds good to me.
Done, rev 8061
* logical ops C, C, C return the left or right PMC
* C may return a new scalar, which is set to VTABLE_set_bool(..,0)
(this is more a short term hack until we have HLL type mappings)
* This invalidates current bytecode as the MMD
On Wed, May 11, 2005 at 10:17:30AM +0200, Leopold Toetsch wrote:
>
> So the right thing for the logical functions seems to be, to just return
> the left or right side according to their boolean value (or return a new
> Boolean false in case of xor), i.e. you get a reference to one of the
> PMCs
The logical MMD functions currently try to set a passed in destination
PMCs value via assign, or they return a clone of themselves.
This is verly likely wrong: not all PMCs have to implement assign:
: That's why the destination controls assignment.
Additionaly we can't assign to singl
This snippet:
.local pmc cl, l, r, d
cl = subclass "Integer", "AInt"
l = new "AInt"
r = new "AInt"
d = l."__add"(r)# d = n_add l, r
now works as expected.
These infix methods always return a new destination PMC so that the
function signature matches an HLLs signature for infix operat
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I'm not *100%* sure this would be a win, but I'm finding that I'm
> currently writing an awful lot of code in my set_pmc vtable methods
> that is suspiciously MMD-like. As such, I think adding assignment to
> the list of
I'm not *100%* sure this would be a win, but I'm finding that I'm
currently writing an awful lot of code in my set_pmc vtable methods
that is suspiciously MMD-like. As such, I think adding assignment to
the list of MMD functions might not be a bad i
Cory Spencer <[EMAIL PROTECTED]> wrote:
> I've encountered some multimethod dispatch funnyness tonight. The
> included code which one would expect to produce a value of 1 ends up
> printing a value of 3.
It wasn't really a MMD problem, but the already described pr
1 - 100 of 270 matches
Mail list logo
