Indirect objects, adverbial arguments and whitespace
If I've got this right: mangle $foo :a;# mangle($foo, a => 1); mangle $foo: a;# $foo.mangle(a()); So these -- mangle $foo:a; mangle $foo : a; are ambiguous and, as far as I can tell from the synopses, undefined. So what's the rule: that indirect-object colon needs whitespace after but not before, and adverbial colon needs whitespace before but not after? The reason I ask is that I'm knocking up an intro to Perl 6 for C and C++ programmers. I expect some of Perl 6's whitespace rules to trip up people used to C++ (as they have me, in my clumsy attempts with Pugs), and I'd like to summarise all the whitespace dwimmery in one place. Many thanks, Markus
Re: Indirect objects, adverbial arguments and whitespace
Visually, I interpret ":a" as a token unto itself, though that's probably Ruby's fault. That interpretation would man that the dual-whitespace version would have to be an indirect object. I would argue for disallowing the all-jammed-together case, lest we run into longest-match arguments where "foobar:baz" is "foobar: baz" but "foo:barbaz" is "foo :barbaz". Yuck. On 7 Oct 2007 12:22:56 -, Markus Laker <[EMAIL PROTECTED]> wrote: > If I've got this right: > > mangle $foo :a;# mangle($foo, a => 1); > mangle $foo: a;# $foo.mangle(a()); > > So these -- > > mangle $foo:a; > mangle $foo : a; > > are ambiguous and, as far as I can tell from the synopses, undefined. So > what's the rule: that indirect-object colon needs whitespace after but not > before, and adverbial colon needs whitespace before but not after? > > The reason I ask is that I'm knocking up an intro to Perl 6 for C and C++ > programmers. I expect some of Perl 6's whitespace rules to trip up people > used to C++ (as they have me, in my clumsy attempts with Pugs), and I'd > like to summarise all the whitespace dwimmery in one place. > > Many thanks, > > Markus > -- Mark J. Reed <[EMAIL PROTECTED]>
[perl #46213] [PGE] Bug in longest token matching "||" ?
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #46213]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46213 >
hi,
while converting lang/PIR into the new Perl6Grammar syntax, I came across
the following.
token relational_operator {
|| '=='
|| '!='
|| '<='
|| '<'
|| '>'
|| '>='
}
At first, I used single bars, like '|'. However, tests failed. When
switching the last 2 entries ">" and ">=" it worked, probably because I put
the longest token first.
Then I figured I should make explicit I want the longest token. The operator
I should use is "||" instead of "|". However, using "||" didn't solve the
problem when I listed ">" before ">=".
I wonder if this is a bug, or that something else is going on.
regards,
kjs
Re: Indirect objects, adverbial arguments and whitespace
On 10/7/07, Mark J. Reed <[EMAIL PROTECTED]> wrote: > I would argue for disallowing the all-jammed-together case, lest we > run into longest-match arguments where "foobar:baz" is "foobar: baz" > but "foo:barbaz" is "foo :barbaz". Yuck. Uh, that doesn't make sense. Longest match arguments are leftmost, so if you consider the indirect object : to be part of the variable before it (I wouldn't), then you would always get the "foobar: baz" / "foo: barbaz" interpretation. I don't know about the all jammed together case, but mangle $foo : a is not ambiguous because : a is not a pair: there is no whitespace allowed between the colon and the name on that style of pair. Luke
[perl #46221] [PATCH] Resource leak fix in imcc.y (Coverity CID 30)
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46221] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=46221 > Coverity Prevent has managed to throw up some difficult-to-fix issues in Parrot, however, due to a lot of work by various people the list has been reduced from over 80 to roughly 30. The attached patch fixes the issue mentioned Coverity CID 30. I would commit this myself but I would rather some code review before I go ahead. If noone complains I'll commit the patch in about 3 days, or if the patch is recommended, earlier. Paul imcc_y.patch Description: Binary data
PDD17 - PMCs
Hi, some days ago near #parrot: 17:13 if you get a chance, allison has modified pdd17 (pmc). i'm reviewing it, but i think you'd be a better judge of its implications on gc, etc. 17:14 I'll have a look at it - thx Well, xx days after, I had a very brief look at it: - it's mostly a summary of current state - some new good things (roles) are defined, which aren't yet in src/role/ - the old "bugs", which IMHO, a rigid PMC structure and morph are, are still present: ... IMPLEMENTATION Internal structure All PMCs have the form: ... morph void morph(INTERP, PMC* self, INTVAL type) Turn the PMC into a PMC of type type. If the morphing can't be done in any reasonable way -- for instance if an integer is asked to turn into an Array -- then the PMC is first destroyed, then recreated as an empty PMC of the new type. This implies (for me), that whatever silly morph requests like above would be issued, a PMC always has the needs of 'one size fits all'. This will preclude any optimzations of creating smaller spezialised PMCs as well as it seems to going the "PMC_data indirection hell" forever, with all the negative impacts on internal code readability and visible performance. I'm sorry if I've misunterstood this document, leo
[perl #46223] [PATCH] Remove dead code in src/pmc/pair.pmc (Coverity CID 5)
# New Ticket Created by Paul Cochrane # Please include the string: [perl #46223] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=46223 > Coverity Prevent mentions that the code after the C comparison in src/pmc/pair.pmc can never be executed. Here is the offending chunk of code (the comments are mine): p1 = PMC_pmc_val(SELF); p2 = PMC_pmc_val(value); if (!p1 && !p2) return 1; /* when p1 = p2 = null, or p1 = p2 = non-null */ if (p1 || p2) return 0; /* when p1 = null, p2 = non-null, or p1 = non-null, p2 = null */ /* which handles all permutations of p1 and p2 */ /* hence, the following code can never be executed */ if (!mmd_dispatch_i_pp(INTERP, p1, p2, MMD_EQ)) return 0; return 1; The attached patch removes the dead code, and 'make test' passes. If there are no complaints, I'll apply this patch in about 3 days; if it is approved, as soon as I am able. Paul Index: src/pmc/pair.pmc === --- src/pmc/pair.pmc(revision 21951) +++ src/pmc/pair.pmc(working copy) @@ -202,11 +202,6 @@ if (p1 || p2) return 0; - -if (!mmd_dispatch_i_pp(INTERP, p1, p2, MMD_EQ)) -return 0; - -return 1; } /*
Re: [perl #46213] [PGE] Bug in longest token matching "||" ?
On Sun, Oct 07, 2007 at 08:52:26AM -0700, Klaas-Jan Stol wrote:
> hi,
>
> while converting lang/PIR into the new Perl6Grammar syntax, I came across
> the following.
>
> token relational_operator {
> || '=='
> || '!='
> || '<='
> || '<'
> || '>'
> || '>='
> }
>
> At first, I used single bars, like '|'. However, tests failed. When
> switching the last 2 entries ">" and ">=" it worked, probably because I put
> the longest token first.
>
> Then I figured I should make explicit I want the longest token. The operator
> I should use is "||" instead of "|". However, using "||" didn't solve the
> problem when I listed ">" before ">=".
> I wonder if this is a bug, or that something else is going on.
PGE doesn't implement longest-token matching semantics yet -- it's
still up to the grammar to correctly order the tokens so that
longest tokens appear first.
Pm
[perl #46225] [PATCH] Remove passing possible negative index to array in src/pmc.c (Coverity CID 22)
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46225]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46225 >
In Coverity CID 22 there is a warning about potentially passing a
negative index to an array. The attached patch corrects the issue,
and 'make test' passes. If noone complains I'll apply the patch in
about 3 days, or if approved, as soon as I can.
Paul
Files affected: src/pmc.c
Index: src/pmc.c
===
--- src/pmc.c (revision 21951)
+++ src/pmc.c (working copy)
@@ -380,9 +380,16 @@
return type;
}
if (type < enum_type_undef) {
-real_exception(interp, NULL, 1, "native type with name '%s' already
exists - "
-"can't register PMC", data_types[type].name);
-return 0;
+char *type_name;
+if (type < 0) {
+strcpy(type_name, "undefined type");
+}
+else {
+strcpy(type_name, data_types[type].name);
+}
+real_exception(interp, NULL, 1,
+"native type with name '%s' already exists - "
+"can't register PMC", type_name);
}
classname_hash = interp->class_hash;
Re: Pair notation for number radix
On 10/6/07, brian d foy wrote: That looks like it might mean that these are corresponding forms: 8 => 377:8<377>:8(377) Now, if I can do that, what happens to the pair form in a hash composer when I want the key of '8' and the value of :10<377>? What happened to the suggestion of using ` to designate units? Bases are a kind of unit (sort of -- counting the number of 10's or 2's or 16's), so if the colon-form is ambiguous, perhaps it could be 20`16==32`10? -David
[perl #46227] [PATCH] Remove passing negative index to array in compilers/imcc/optimizer.c (Coverity CID 20
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46227]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46227 >
This patch is brought to you by the RT command line utility because
parrotbug doesn't seem to think I'm the 'Hi' virus...
In compilers/imcc/optimizer.c there is the possiblity that a negative
number will be used as an index to an array; see Coverity CID 20. This
patch removes this issue. If noone complains, I'll apply the patch in
about 3 days; if it is approved, then I'll apply it at the first
opportunity.
Paul
Index: compilers/imcc/optimizer.c
===
--- compilers/imcc/optimizer.c (revision 21951)
+++ compilers/imcc/optimizer.c (working copy)
@@ -934,11 +934,16 @@
(next->type & IF_goto) &&
!strcmp(next->op, "branch") &&
strcmp(next->r[0]->name, get_branch_reg(ins)->name)) {
+const int regno = get_branch_regno(ins);
IMCC_debug(interp, DEBUG_OPT1,
"found branch to branch '%s' %I\n",
r->first_ins->r[0]->name, next);
unit->ostat.branch_branch++;
-ins->r[get_branch_regno(ins)] = next->r[0];
+if (regno < 0) {
+real_exception(interp, NULL, 1,
+"Register number determination failed in
branch_branch()");
+}
+ins->r[regno] = next->r[0];
changed = 1;
}
}
Re: Some questions about using NaN and Inf
In article <[EMAIL PROTECTED]>, Moritz Lenz <[EMAIL PROTECTED]> wrote: > brian d foy wrote: > > * If I can match $x to NaN (or its stand-in), what happens when $x is > > undef? > > undef is a property of the container variable (that it holds no value), > whereas NaN is a property of the content (like 1/0). so undef ~~ NaN > should be false IMHO. That's fine, but the question people are going to ask is "if undef isn't a number, why doesn't iot match 'not a number'". If it doesn't match, we have to talk about internals to explain it, which is generlaly not a good idea for beginners :)
Re: Some questions about using NaN and Inf
In article <[EMAIL PROTECTED]>, Darren Duncan <[EMAIL PROTECTED]> wrote: > At 3:20 PM -0500 10/6/07, brian d foy wrote: > >For comparisons, how are we going to use Inf and NaN? Are those going > >to be special flyweight objects, so: > > > >$x = 1 / 0; > > > >$x == Inf;# is it the same value > >$x === Inf; # it is always the same object > them. By contrast, the =:= operator always tests if 2 things are the > same object or not, even for those of value types. Maybe the belongs in "Comparison types" in S02 too :) So, then, back to the question. People don't care how it's implemented (and it would be great if we didn't have to explain it). What's the idiom for the comparison going to be?
[perl #45737] [PATCH] [NEW] Change interface to all configuration step runstep() methods
Applied to trunk in r21956.
wrapping up the OO implementation
From: Allison Randal <[EMAIL PROTECTED]> Date: Mon, 01 Oct 2007 15:58:24 -0700 My goal was to wrap up the pdd15oo branch by the end of September. We're quite close. The two remaining big things are PGE and multiple dispatch, and then test cleanup. Thanks to chromatic and particle for their work on the tests. I've been giving chromatic small tasks to work on, which seems to be a good way of breaking out the load. Here are a few anyone could tackle . . . I could only find a few find_type hits in t/**/*.t; these are now fixed. (I assume this is because I'm late to the party.) All of the rest (besides the implementation of the op itself) seems to be in documentation. Attatched are a few that ought to be changed (diff against the pdd15oo branch) -- but perhaps you are planning a wholesale rewrite of these sections? -- Bob Rogers http://rgrjr.dyndns.org/ * docs/compiler_faq.pod: * docs/imcc/calling_conventions.pod: + Replace some "find_type" references with "get_class". Diffs between last version checked in and current workfile(s): Index: docs/compiler_faq.pod === --- docs/compiler_faq.pod (revision 21955) +++ docs/compiler_faq.pod (working copy) @@ -396,15 +396,23 @@ =head2 How do I instantiate a class? -You can do so either with an integer type identifier: +You can do so either with the class name: -$I0 = find_type 'Dog' -new $P0, $I0# creates a Dog object and stores it in register $P0 +new $P0, 'Dog' -or with the class name: +or with the class object: -new $P0, 'Dog' +$P1 = get_class 'Dog' # find the 'Dog' class +unless null $P1 goto have_dog_class +printerr "Oops; can't find the 'Dog' class.\n" +.return () + have_dog_class: +new $P0, $P1# creates a Dog object and stores it in register $P0 +The chief difference is that using a string constant will produce the +specific error "Class 'Dog' not found" if that happens to be the case; +the other code has to check explicitly. + During the C opcode the constructor is called. =head2 How can I pass arguments to a constructor? Index: docs/imcc/calling_conventions.pod === --- docs/imcc/calling_conventions.pod (revision 21955) +++ docs/imcc/calling_conventions.pod (working copy) @@ -222,8 +222,7 @@ .local pmc class .local pmc obj newclass class, "Foo" - find_type $I0, "Foo" - new obj, $I0 + new obj, class .pcc_begin .arg x .arg y End of diffs.
Re: [perl #44353] [BUG] Configure.pl: verbose-step option not workingwith named step
James E Keenan wrote: Allison Randal wrote: So, how about we make both --fatal-step and --verbose-step accept either a step number or step name. Didn't I hear someone recently remark, "Simplification is a good idea"? ;-) This is doable, but it will take me at least 9 separate test files to thoroughly test it. Understood. Usability is important, though, especially in the part of the system that will be the first thing many users see of Parrot. Making the config process friendly to the average human is worth a little extra work in testing. Now, if you said it was impossible to test, that'd be a different matter. But this isn't impossible to test, just tedious to test. And some of the tedium can be relieved by generating the (nearly identical) tests for each step from a template. Allison
Re: [svn:parrot] r21891 - branches/pdd15oo/src/pmc
chromatic wrote: On Friday 05 October 2007 14:02:32 [EMAIL PROTECTED] wrote: Modified: branches/pdd15oo/src/pmc/namespace.pmc === === --- branches/pdd15oo/src/pmc/namespace.pmc (original) +++ branches/pdd15oo/src/pmc/namespace.pmc Fri Oct 5 14:02:31 2007 @@ -182,6 +182,7 @@ Parrot_NSInfo *nsinfo= PARROT_NSINFO(SELF); PMC *vtable= nsinfo->vtable; Parrot_sub*sub = PMC_sub(value); +PMC * const classobj = VTABLE_get_class(interp, SELF); [...] + +/* Insert it in class, if there is a class */ +if (!PMC_IS_NULL(classobj) && PObj_is_class_TEST(classobj)) + VTABLE_add_vtable_override(interp, classobj, key, value); } Is there a reason why classobj would *not* be a class if it's not PMCNULL? I don't understand this additional test. Yeah, there could be absolutely any kind of PMC stored in the namespace's 'class' slot. The PObj_is_class_FLAG is something classes set on themselves, agreeing to support the standard interface of a class object. (Currently it's only set by Class and PMCProxy, but it will also be set by the Proto PMC, if/when we add it.) In the future, that may be a check for VTABLE_does of "Class", though the flag check is cheaper. Allison
Re: [perl #46099] [TODO] Check for existing parent classes in add_parent()
Klaas-Jan Stol wrote:
I think it should be something like this:
/* RT46099 Check we don't already have this parent. */
/* If we have already added a method with this name... */
if (VTABLE_exists_keyed_str(interp, _class->all_parents,
VTABLE_name(interp, parent))) {
real_exception(interp, NULL, E_NotImplementedError,
"This class already has this parent.");
}
Great start. Change "method" to "parent" in the comment. You'll want to
check the immediate parents of the class, not all inherited parents, so
you need to be looking at _class->parents, instead of
_class->all_parents. And, unlike methods, parents are stored as an array
of class objects, not a hash keyed by class name, so you'll need to loop
over the parents array and check 'VTABLE_is_same' on each.
Also, it'd be good to add more information to the real_exception
message, like:
real_exception(interp, NULL, E_NotImplementedError,
"The class '%S' already has a parent class '%S'. "
"It may have been supplied by a role.",
VTABLE_get_string(interp, SELF),
VTABLE_get_string(interp, parent));
can't test this, parrot does not build in pdd15 branch.
it should be more or less like this, based on impl of add_attribute.
the headerfile classobject.h is missing in the branch, while it is there in
trunk. Is this right?
The pdd15oo branch does build (since Saturday), and passes most of its
tests. Try 'make realclean', as some files have moved (classobject.h,
for example, is now include/parrot/oo_private.h).
btw, the type of exception should be changed, also for other methods.
Agreed.
Thanks!
Allison
