[perl #42609] [BUG] make html vs. DEVELOPING

2007-04-18 Thread via RT
# New Ticket Created by Will Coleda # Please include the string: [perl #42609] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=42609 > In a release tarball, 'make html' is still trying to process the file DEVELOPING which

Re: RT #41858, reasonable set of rules for splint (was: Re: Parrot Bug Summary)

2007-04-18 Thread Paul Cochrane
Mark, Random cage cleaner here. At Andy Lester's suggestion, I've begun working on this splint stuff. So everything below is all his fault. :) Great to have another cage cleaner around :-) There aren't many of us at this stage! In my (very limited) dealings with splint I too have found pro

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread Allison Randal
Alek Storm wrote: In the future, please keep in mind that I don't comment on anything unless I understand it. You've tried to explain things to me in several tickets that I already fully understand. I am especially surprised you would try to explain the current implementation of vtable over

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread Alek Storm
On 4/18/07, Allison Randal <[EMAIL PROTECTED]> wrote: Yes, that's how they're implemented now. Currently, in order to use the common feature of overriding the vtable entry without polluting the namespace you have to specify ":vtable :method :anon". Which is huge progress over what we had before

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread Allison Randal
Alek Storm wrote: I understand entirely how both features work. I should, as I implemented large sections of the code dealing with vtable overriding. Perhaps you should check the code, because they are *not* stored separately from each other. In the current revision, :vtable and :method u

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread Alek Storm
On 4/18/07, Allison Randal <[EMAIL PROTECTED]> wrote: Alek Storm wrote: >> > >> > So, that still means :method can mean two different things, depending >> > on whether :vtable is present or not. That's still bad. >> >> How so? Without :vtable, :method adds a method to the class. With >> :vtable

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread Alek Storm
On 4/18/07, chromatic <[EMAIL PROTECTED]> wrote: On Wednesday 18 April 2007 15:59, Alek Storm wrote: > Without :vtable, :method adds a method to the class. With :vtable, > :method doesn't add a method to the class - it makes the sub visible. > Two completely different things. I'd like to see s

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread Allison Randal
Alek Storm wrote: > > So, that still means :method can mean two different things, depending > on whether :vtable is present or not. That's still bad. How so? Without :vtable, :method adds a method to the class. With :vtable, :method adds a method to the class. Without :vtable, :method adds a

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread chromatic
On Wednesday 18 April 2007 15:59, Alek Storm wrote: > Without :vtable, :method adds a method to the class.  With :vtable, > :method doesn't add a method to the class - it makes the sub visible. > Two completely different things. I'd like to see some example code; this does not match my experience

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread Alek Storm
On 4/18/07, Allison Randal <[EMAIL PROTECTED]> wrote: Alek Storm wrote: > >> Again, the only part of :method that :vtable needs to imply is the >> part that >> sets the invocant in the proper register and makes 'self' available >> within >> the body of the method. > > So, that still means :method

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread Alek Storm
On 4/18/07, Allison Randal <[EMAIL PROTECTED]> wrote: Alek Storm wrote: > .sub get_string :vtable :method :anon # now we're in trouble Just like ":method :anon", but also stores it as a vtable entry. But herein lies the problem. Saying ":vtable :method :anon" is just like ":method :anon" does

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread Allison Randal
Alek Storm wrote: Again, the only part of :method that :vtable needs to imply is the part that sets the invocant in the proper register and makes 'self' available within the body of the method. So, that still means :method can mean two different things, depending on whether :vtable is prese

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread Allison Randal
Alek Storm wrote: This seems perfectly fine to me. The only change I think should be made is that :vtable automatically sets :method to true. Using :anon to exclude it from the namespace is what you originally proposed, so I'm curious why you've changed your mind. Because I realized that und

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread Alek Storm
On 4/18/07, chromatic <[EMAIL PROTECTED]> wrote: On Wednesday 18 April 2007 14:15, Alek Storm wrote: > > If that's true, then users have to *know* the implementation details of > > vtable methods. Is it in C code or is it in PIR code? > > I have no idea why you're saying this. Why does making

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread chromatic
On Wednesday 18 April 2007 14:15, Alek Storm wrote: > > If that's true, then users have to *know* the implementation details of > > vtable methods.  Is it in C code or is it in PIR code? > > I have no idea why you're saying this.  Why does making vtable methods > visible expose their implementatio

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread Alek Storm
Okay, I think we completely misunderstood each other. Honestly, most of what I said was a reply to Allison's proposal. On 4/18/07, chromatic <[EMAIL PROTECTED]> wrote: On Wednesday 18 April 2007 13:34, Alek Storm wrote: > Vtable methods defined in C are visible from C. Of course, otherwise n

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread chromatic
On Wednesday 18 April 2007 13:34, Alek Storm wrote: > Vtable methods defined in C are visible from C. Of course, otherwise nothing would be able to call them. > Therefore, it makes > sense that vtable methods defined in PIR are visible from PIR, at > least by default. That makes no sense to me

Re: [perl #42406] [PATCH] improper null testing in Parrot_instantiate_object

2007-04-18 Thread Alek Storm
This patch has been sitting for over a week. Is there a problem? It's just a bugfix. -- Alek Storm

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread Alek Storm
On 4/18/07, chromatic <[EMAIL PROTECTED]> wrote: > Making :method mean one thing when used with :vtable, and something > completely different without, seems like a really bad idea to me, and > is confusing to the user. The user will also be confused because > adding :vtable removes it from the n

Re: [perl #42602] [PATCH] Cleanup of additional C++ keywords

2007-04-18 Thread chromatic
On Wednesday 18 April 2007 11:09, Mark Glines wrote: > > Thanks to Mark Glines email, the following appears to be the > > remaining C++ keywords hanging about. > > Nice :) Your patch reduces the warning count further, from 35 to 9. > > Here's what I am getting currently: > > lib/Parrot/Pmc2c/PCCM

Re: [perl #42594] [PATCH] Probable buffer overflow in compilers/imcc/parser_util.c

2007-04-18 Thread Leopold Toetsch
Am Dienstag, 17. April 2007 23:48 schrieb Steve Peters: > +        strncpy(format, fmt, sizeof(format - 1)); Me thinks, that it's better to check the len of the format as it grows, considering the amount what would be strcat'ed. If an index really would overflow format, a proper syntax error cou

Re: [perl #42602] [PATCH] Cleanup of additional C++ keywords

2007-04-18 Thread Mark Glines
On Wed, 18 Apr 2007 09:19:09 -0700 Steve Peters (via RT) <[EMAIL PROTECTED]> wrote: > # New Ticket Created by Steve Peters > # Please include the string: [perl #42602] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=42602

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread chromatic
On Wednesday 18 April 2007 08:04, Alek Storm wrote: > Making :method mean one thing when used with :vtable, and something > completely different without, seems like a really bad idea to me, and > is confusing to the user.  The user will also be confused because > adding :vtable removes it from the

[perl #42602] [PATCH] Cleanup of additional C++ keywords

2007-04-18 Thread via RT
# New Ticket Created by Steve Peters # Please include the string: [perl #42602] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=42602 > Thanks to Mark Glines email, the following appears to be the remaining C++ keywords han

Re: [perl #42430] [PATCH] make :vtable imply :method

2007-04-18 Thread Alek Storm
On 4/16/07, Allison Randal <[EMAIL PROTECTED]> wrote: Here's the original post where I gave the rationale for making the flags work as they do: From the link: < This is the main thing Chip and I

Re: [perl #42594] [PATCH] Probable buffer overflow in compilers/imcc/parser_util.c

2007-04-18 Thread Steve Peters
On Wed, Apr 18, 2007 at 11:18:20AM +0200, Mehmet Yavuz Selim Soyturk wrote: > >+format[sizeof(format - 1)] = '\0'; > > > Shouldn't that be 'format[sizeof(format) - 1]' ? > Yes, thanks! Good catch! Steve

Re: [perl #42597] [CAGE] Add Tests for C++ and C Style

2007-04-18 Thread Steve Peters
On Tue, Apr 17, 2007 at 07:53:21PM -0700, Mark Glines wrote: > On Tue, 17 Apr 2007 18:53:32 -0700 > chromatic (via RT) <[EMAIL PROTECTED]> wrote: > > > In particular, we need to detect: > > > > - variable declarations with name 'class' > > - variable declarations with the name 'namespace'

Re: [perl #42594] [PATCH] Probable buffer overflow in compilers/imcc/parser_util.c

2007-04-18 Thread Mehmet Yavuz Selim Soyturk
+format[sizeof(format - 1)] = '\0'; Shouldn't that be 'format[sizeof(format) - 1]' ? -- Mehmet