Re: MMD and VTABLE_find_method
Sam Ruby wrote:
Leopold Toetsch wrote:
A foo PMC could represent an entire row in a two dimensional MMD, or
an entire plane in a three dimensional MMD, ... etc.
What does it mean: represent a row...? What about the namespace
pollution? Again: where does this hypothetical MMD PMC come from?
A Perl6 compiler could translate the above to:
87 find_lex P5, a
90 find_lex P6, b
93 find_lex P7, c
96 find_global P0, foo
108 set I0, 1
111 set I1, 0
114 set I2, 0
117 set I3, 3
120 set I4, 0
126 invokecc
You seem to like double dispatching :-)
The foo PMC could know how many of the arguments are relevant for MMD
dispatch. Should only the first two arguments be relevant, this code
could be as simple as:
void* invoke(void* next) {
...
if (cache-type == (Py-vtable-base_type
16|Pz-vtable-base_type)
return VTABLE_invoke( cache-function );
...
}
Where ist the Ccache coming from? Please read again my articles WRT
*inline* cache.
Where does this hypothetical MMD PMC come from? Where is it created?
The opcode is just:
add Px, Py, Pz
Py or Pz can be plain PyInts or Integers. Where does that MMD PMC come
from?
Once MMD is solved connecting it up to the PerlScalar PMC (for example)
would be rather straightforward. Syntax like the following would result
in an appropriate entry being added to the MMD dispatch table:
How do you connect MMD to the scalar PMC? And to which scalar PMC?
Which MMD dispatch table?
multi sub infix:+ (Us $us, Us $ustoo) {...}
The Parrot_PerlScalar_add function (which would revert back to being a
vanilla vtable) would know about the portion of the MMD dispatch table
that is relevant to Perl scalar add operations, and invoke it.
So Perl is unable to add an integer that originated from Python code.
Sam that all doesn't play together.
(Note: one thing that hasn't been discussed to date is how registers
will be handled. The current add opcode doesn't have any side effects)
That's obvious: overloaded operations don't have side effects WRT
register usage, and the current implementation in Parrot core preserves
all registers.
- Sam Ruby
leo
Re: MMD and VTABLE_find_method
Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: A foo PMC could represent an entire row in a two dimensional MMD, or an entire plane in a three dimensional MMD, ... etc. What does it mean: represent a row...? What about the namespace pollution? Again: where does this hypothetical MMD PMC come from? Since you are going to snip away everything, let's start all over. First, a direct quote from http://www.perl.com/pub/a/2004/04/16/a12.html?page=10: As we mentioned, multiple dispatch is enabled by agreement of both caller and callee. From the caller's point of view, you invoke multiple dispatch simply by calling with subroutine call syntax instead of method call syntax. It's then up to the dispatcher to figure out which of the arguments are invocants and which ones are just options. (In the case where the innermost visible subroutine is declared non-multi, this degenerates to the Perl 5 semantics of subroutine calls.) This approach lets you refactor a simple subroutine into a more nuanced set of subroutines without changing how the subroutines are called at all. That makes this sort of refactoring drop-dead simple. (Or at least as simple as refactoring ever gets...) In the general case, a call to a subroutine with three arguments can have four possibilities: anywhere from zero to three arguments may be involved in the dispatch. I also read this to say that whatever code is generated by a subroutine call is independent of the number of arguments involved in the dispatch. If you read this differently, perhaps we can get a ruling from the Per6 language folks. If I am correct, this will have the nice side benefit that any such methods can be invoked transparently by all languages. None of this precludes a Polymorphic Inline Cache. Or Multidimensional Multimethod Dispatch. Or 30 to 70% performance improvements. But it does constrain where the logic needs to be placed. And it does rule out syntax changes and using a different opcode for invoking MMD subroutines than non-MMD subroutines. - Sam Ruby
Re: MMD and VTABLE_find_method
Sam Ruby wrote: First, a direct quote from http://www.perl.com/pub/a/2004/04/16/a12.html?page=10: Please let's stay at the basics. Please describe your counter proposal for a very elementary add Px, Py, Pz operation. There's really no need to procede to Perl6 objects, if we can't even find a common interoperating implementation that is suited for Parrot's target languages. And it does rule out syntax changes and using a different opcode for invoking MMD subroutines than non-MMD subroutines. Yep. - Sam Ruby leo
Re: MMD and VTABLE_find_method
Leopold Toetsch wrote:
Sam Ruby wrote:
First, a direct quote from
http://www.perl.com/pub/a/2004/04/16/a12.html?page=10:
Please let's stay at the basics. Please describe your counter proposal
for a very elementary
add Px, Py, Pz
operation.
There's really no need to procede to Perl6 objects, if we can't even
find a common interoperating implementation that is suited for Parrot's
target languages.
And it does rule out syntax changes and using a different opcode for
invoking MMD subroutines than non-MMD subroutines.
Yep.
First, a few things to note: the semantics of add vary from language
to language. In particular, add is not guaranteed to be commutative in
Python (think string addition).
As my proposal is primarily focused on where the logic is placed in the
system, not how it works, I'll like to use your proposal
http://xrl.us/egvp as a starting point. Just to make sure that I
don't mischaracterize your proposal, can you take a look at the attached
and either agree that it represents a reasonable first approximation of
what you had in mind, or modify it so that it is?
Once that's done, I'll sketch out all of the changes required to enable
Perl and Python to each have their own separate semantics for this
operation, and yet be able to have meaningful interop when it comes to
adding a PerlInt and a PyInt, or vice versa.
- Sam Ruby
Index: math.ops
===
RCS file: /cvs/public/parrot/ops/math.ops,v
retrieving revision 1.32
diff -u -r1.32 math.ops
--- math.ops7 Dec 2004 17:24:53 - 1.32
+++ math.ops22 Dec 2004 16:08:50 -
@@ -171,7 +171,32 @@
}
inline op add (in PMC, in PMC, in PMC) :base_core {
- mmd_dispatch_v_ppp(interpreter, $2, $3, $1, MMD_ADD);
+ if (1) { /* this is here to allow declarations, even in C89 */
+ struct Parrot_Context ctx;
+ struct parrot_regs_t *bp = interpreter-ctx.bp;
+ STRING *__add = const_string(interpreter, __add);
+ INTVAL mmd_flag;
+ PMC *addsub;
+
+ /* we probably don't need to save the full context, just a few regs... */
+ save_context(interpreter, ctx);
+
+ /* let's ignore the complexities of a distance_func for now... */
+ mmd_flag = 0;
+ addsub = VTABLE_find_method(INTERP, $1, __add, 0, mdd_flag);
+ if (!addsub)
+ mmd_flag = 0;
+ addsub = VTABLE_find_method(INTERP, $2, __add, 1, mdd_flag);
+
+ /* assume NCI for now */
+ VTABLE_invoke(interpreter, sub, NULL);
+
+ /* note: this was allocated by __add */
+ $3 = BP_REG_PMC(bp,5);
+
+ /* again, probably overkill */
+ restore_context(interpreter, ctx);
+ }
goto NEXT();
}
Re: [perl #33094] [PATCH] Clean Up POD Errors and Warnings
On Fri, 2004-12-17 at 16:40 -0800, chromatic wrote: # New Ticket Created by chromatic # Please include the string: [perl #33094] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=33094 Here's a patch to clean up all of the POD errors I found and most of the warnings, too. If no one objects, I'll commit it myself in a few days. Thanks, applied. -- c
Re: MMD and VTABLE_find_method
Sam Ruby wrote:
First, a few things to note: the semantics of add vary from language
to language. In particular, add is not guaranteed to be commutative in
Python (think string addition).
Yes, of course.
As my proposal is primarily focused on where the logic is placed in the
system, not how it works, I'll like to use your proposal
http://xrl.us/egvp as a starting point. Just to make sure that I
don't mischaracterize your proposal, can you take a look at the attached
and either agree that it represents a reasonable first approximation of
what you had in mind, or modify it so that it is?
It's a reasonable respresentation, yes. Finding the right functions is
more complex, though, as described in my proposal.
I'd just outline the functionality of the add opcode like this:
inline op add (out PMC, in PMC, in PMC) :base_core {
PRESERVE_CONTEXT;
add_func = mmd_find(__add...) // via VTABLE_find_method
REG_PMC(5) = $2;
REG_PMC(6) = $3;
VTABLE_invoke(interp, add_func, 0);
res = REG_PMC(5);
RESTORE_CONTEXT;
$1 = res;
}
the basics are:
* the destination PMC $1 is created by the opcode
* no other registers are changed, nor the context
* finding the __add method uses VTABLE_find_method to
find all possible __add methods and a distance
function to get the best match
* the best matching function is invoked
Once that's done, I'll sketch out all of the changes required to enable
Perl and Python to each have their own separate semantics for this
operation, and yet be able to have meaningful interop when it comes to
adding a PerlInt and a PyInt, or vice versa.
Great, thanks.
- Sam Ruby
leo
Re: Test::Builder versus Unicode
On Dec 20, 2004, at 6:44 PM, David Wheeler wrote: PS Somebody should drag autrijus into this. I'll try to grab him on IRC in the morning... I got him this morning. Here's the discussion: 09:50am] Theory: seen autrijus [09:50am] purl: autrijus was last seen on #p5p 1 hour and 32 minutes ago, saying: rofl [09:50am] autrijus: you seek me? [09:50am] modred: you didn't even need to say his name three times [09:50am] xantus: seek(0) [09:50am] Theory: autrijus: I do! [09:51am] autrijus: pray tell(), why? [09:51am] Theory: autrijus: Are you on perl-qa? [09:51am] autrijus: nay, I am not [09:51am] Theory: autrijus: Let me find an archive link for a unicode Test::Builder discussion there. [09:51am] Theory: I have a feeling you'll already be familiar with the issue... [09:51am] autrijus: http://www.nntp.perl.org/group/perl.qa/3404 [09:52am] Theory: autrijus: D'oh! [09:52am] Theory: You're way ahead of me. [09:52am] Theory: autrijus: What do you think? [09:52am] purl: I think Theory should try flossing more often! [09:52am] autrijus: give me a test case that involves big5? [09:52am] Theory vomits on purl [09:53am] Theory: autrijus: Hrm. I'd have to dig up some Big5. [09:53am] Theory: autrijus: The problem won't come up with Big5 unless you binmode Test::Builder's FHs to utf8. [09:54am] Theory: autrijus: Schwern was suggesting that they just always be utf8, but I thought that'd break things when you used non-utf8 characters. [09:54am] autrijus: if it's always in utf8 and you send random binary data there [09:54am] autrijus: it could be unhappy. [09:54am] Theory: autrijus: Exactly, and that's when Schwern threw up his hands in disgust. [09:54am] Theory: seen Schwern [09:54am] purl: Schwern was last seen on #perl 24 minutes ago, saying: crab: I've read Naked [09:55am] Schwern left the chat room. (Ping timeout: 240 seconds) [09:56am] Theory: autrijus: So it seems to me that there needs to be some way to tell Test::Builder what binmode to use on its file handles. [09:56am] autrijus: so T::B uses its own fh [09:56am] autrijus: apart from STDOUT [09:56am] autrijus: and it does not inherid STDOUT's layers. [09:56am] autrijus: is it that? [09:56am] Theory: autrijus: Yes, it dupes STDOUT and STDERR, but the duping doesn't preserve binmode. [09:56am] Theory: right [09:57am] autrijus: so it seems to me that the right fix is for the duping to fix binmode. [09:57am] Theory: It does the duping so it can know what it's outputting to STDOUT (and STDERR) as opposed to what the scripts are outputting. [09:57am] Theory: autrijus: Me too, but I don't know if there's a way to detect the layer assigned to a file handle. Do you? [09:57am] autrijus: I do. [09:57am] uri: Theory: i bet dupping occurs at the system level so binmode (which is perl i/o level) is lost [09:58am] autrijus: I don't want to go there. [09:58am] Theory: uri: Good point. [09:58am] autrijus thinks. [09:58am] Theory: autrijus: Uh, why not? What is it? [09:58am] uri: Theory: perl prolly calls dup() or variant to do it [09:58am] Theory: uri: Yeah [09:59am] uri: and just returns a plain handle. it should be smart about copying i/o flags [09:59am] autrijus: you can use a layer to read io layers. [09:59am] uri: but you can write a smart dup sub [09:59am] autrijus: I don't think there is an api for that. [09:59am] hachi: dup sub! [09:59am] autrijus: and even if we write one, T::B could not ship it [09:59am] autrijus: because it's, well, XS [10:01am] Theory: autrijus: I was afraid of that. [10:01am] autrijus: and sometimes it does not make sense. [10:01am] Theory: autrijus: So the workaround is to have some way to tell Test::Builder what mode to use. [10:01am] autrijus: yes. [10:02am] autrijus: and in this regard I agree your binmode proposal. [10:02am] Theory: autrijus: Okay. [10:02am] Theory: pokes schwern Ovid: Autrijus: what about using Ingy's Devel::Pointer to get down to that flag info? It's pure Perl and relatively cross-platform. [10:11am] hachi: you can't actually twiddle the flag with that, I thought [10:12am] Ovid: But you should be able to read them and create a new handle with appropriate flags, yes? [10:12am] Theory: uri: I agree that it should be smarter about copying i/o flags. [10:12am] Theory: Maybe I should mention it on #p5p [10:12am] crab: what are we talking about again? [10:12am] hachi: Ovid: I think the problem is that you can't actually touch the FH that is in question here... otherwise they would just do a binmode() on it [10:13am] Ovid: Oh, I take it back. Devel::Pointer is Cozens' module. It's http://search.cpan.org/~ingy/Pointer-0.10/ that I meant. [10:13am] Ovid: Yes, but aren't the filehandles getting duped in T::B? If so, you can read the flags on the handles they're getting duped from. [10:14am] Theory: ovid: Yes, the ideal solution would be for Test::B to detect the flags on the STDERR and STDOUT file handles and copy them to its duped versions. [10:14am] Theory: ovid: Even better would be if Perl did it for you,
Re: Test::Builder versus Unicode
On Wed, Dec 22, 2004 at 10:26:02AM -0800, David Wheeler wrote: 1. Perl gets smarter about duping file handles, so that the dupes get the same i/o layer settings as the handles they dupe. Changing this going forwards doesn't change any of the installed perls out there in the wild. So whatever happens in the future, if we want things to work on existing installations, we need to work round the problem in some way. (I don't currently have time to look into or think about whether it's a bug. Or how to fix it if it is. Or who could fix it.) Nicholas Clark
Re: Test::Builder versus Unicode
--- Nicholas Clark [EMAIL PROTECTED] wrote: On Wed, Dec 22, 2004 at 10:26:02AM -0800, David Wheeler wrote: 1. Perl gets smarter about duping file handles, so that the dupes get the same i/o layer settings as the handles they dupe. Changing this going forwards doesn't change any of the installed perls out there in the wild. So far, given that this problem has only surfaced in relation to Unicode, I can't say I'm overly concerned about fixing it on versions of Perl where Unicode is already known to be broken. Of course, as soon as someone comes up with other layers for which we have a definite problem, I'll shut up. Cheers, Ovid = Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Test::Builder versus Unicode
On Wed, Dec 22, 2004 at 11:41:56AM -0800, Ovid wrote: --- Nicholas Clark [EMAIL PROTECTED] wrote: On Wed, Dec 22, 2004 at 10:26:02AM -0800, David Wheeler wrote: 1. Perl gets smarter about duping file handles, so that the dupes get the same i/o layer settings as the handles they dupe. Changing this going forwards doesn't change any of the installed perls out there in the wild. So far, given that this problem has only surfaced in relation to Unicode, I can't say I'm overly concerned about fixing it on versions of Perl where Unicode is already known to be broken. Of course, as Which you're sort of implying is all versions up to and including 5.8.6 :-) (Well, I can misread it as that. I don't think that you really are implying this). Personally I'd be quite happy using anything 5.8.3 or later with Unicode. The later the better, as more bugs have got fixed. But I feel that Unicode isn't more broken than any other existing part of perl by 5.8.1. And they are out there, and they aren't going away rapidly. Nicholas Clark
Fwd: Out of Office Contact
OK, everyone send Mr. Cowgilll a polite message letting him know that, in the future, he needs to not send these messages to mailing lists. He'll feel really bad about his poor etiquette and we can say only Cowgills get the blues. Ooh, that was awful, awful, awful. Never let me near a pun again, please. Cheers, Ovid --- [EMAIL PROTECTED] wrote: Subject: Out of Office Contact From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 22 Dec 2004 19:55:11 + I will be out of the office starting 21/12/2004 and will not return until 31/12/2004. I am away today. Talk to Simon Fairey if you have any urgent issues. = Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Fwd: Out of Office Contact
Mr. Cowgill's computer did not send such a message to the list. (It's not in the archive.) He sent it to you directly. -R At Wed, 22 Dec 2004 12:27:51 -0800 (PST), Ovid wrote: OK, everyone send Mr. Cowgilll a polite message letting him know that, in the future, he needs to not send these messages to mailing lists. He'll feel really bad about his poor etiquette and we can say only Cowgills get the blues. Ooh, that was awful, awful, awful. Never let me near a pun again, please. Cheers, Ovid --- [EMAIL PROTECTED] wrote: Subject: Out of Office Contact From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 22 Dec 2004 19:55:11 + I will be out of the office starting 21/12/2004 and will not return until 31/12/2004. I am away today. Talk to Simon Fairey if you have any urgent issues. = Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: MMD and VTABLE_find_method
Hi, a lurker here.
Probably you forgot the braces:
+ /* let's ignore the complexities of a distance_func for now... */
+ mmd_flag = 0;
+ addsub = VTABLE_find_method(INTERP, $1, __add, 0, mdd_flag);
+ if (!addsub)
{
+ mmd_flag = 0;
+ addsub = VTABLE_find_method(INTERP, $2, __add, 1, mdd_flag);
}
+
Bye.
Re: Let the hacking commence!
Luke Palmer writes: Also, don't use rule parameters, conditionals, or code blocks. Those things require us to know Perl 6 before we're done defining Perl 6. Keep it essentially BNF with Perl 6 syntax (it's okay to use groups and quantifiers though, since those can always be converted to formal BNF). Change in plan on this one: We're going to shoot for the grammar as Perl will see it, and then factor it down into a bootstrappable grammar later. So whatever hook hashes we're going to use should be in there (though they may not be named properly). Basically, pretend Perl 6 exists and write it for Perl 6. Luke
Re: Fwd: Out of Office Contact
Robert Spier wrote: Mr. Cowgill's computer did not send such a message to the list. (It's not in the archive.) He sent it to you directly. This is (almost always) Microsoft Exchange BS. I used to monitor some of the ActiveState mailing lists, try to answer questions and help people. But every time I post to one of their lists, my mailbox gets filled with nearly a dozen of these things. Every single time. I've tried replying politely, sending them back to the list hoping a moderator might take action (and, of course, my reply to the list generats another dozen OoO auto replies). I've tried forwarding back to the author, postmaster@, and to the company from which the person usually sent the message, CCing every address listed in the mail which often refers to managers or supervisors. Nothing. There doesn't seem to be any way to avoid these @[EMAIL PROTECTED] I hope this doesn't happen on the perl.org lists... At Wed, 22 Dec 2004 12:27:51 -0800 (PST), Ovid wrote: OK, everyone send Mr. Cowgilll a polite message letting him know that, in the future, he needs to not send these messages to mailing lists. He'll feel really bad about his poor etiquette and we can say only Cowgills get the blues. Ooh, that was awful, awful, awful. Never let me near a pun again, please. Cheers, Ovid --- [EMAIL PROTECTED] wrote: Subject: Out of Office Contact From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 22 Dec 2004 19:55:11 + I will be out of the office starting 21/12/2004 and will not return until 31/12/2004. I am away today. Talk to Simon Fairey if you have any urgent issues. = Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Fwd: Out of Office Contact
Randy W. Sims wrote: This is (almost always) Microsoft Exchange BS. On one list I manage on Topica, this is a fairly frequent problem. I'm convinced that part of the problem is that Topica doesn't set a Precedence: bulk header. Sometimes the messages go only as a reply to the poster, but other times it goes out as a group reply to the whole list. Why Exchange would do a group reply is beyond me (I don't use a Reply-To address for my lists). When I place the offenders on moderated status, they tell me that their IT group can do nothing to fix the problem. One even asked me to revoke the penalty because of that. Nothing doing - most are repeat offenders, and not a single one has sent a message that is worthy of being approved for posting. Back to our regularly scheduled Perl discussion... -- Danny R. Faught Tejas Software Consulting http://tejasconsulting.com/
