Re: Runtime Role Issues
--- Audrey Tang <[EMAIL PROTECTED]> wrote: > > I always thought when a role is applied to a class at runtime you > > get a new (anonymous) subclass. The original class isn't affected. > > Right, that's what usually happens with: > > my Dog $fido .= new; > $fido does Catlike; Am I missing something here? That's applying a role to an instance of a class, not the class itself, and thus *should* create a new anonymous class. > To forcefully add a role to a class at a distance during runtime, use > a class object call (see Moose::Meta::Class for more about these > APIs): > > ^Dog.add_role(^Catlike); That's more of what I was thinking, but where is this documented? I can't find it in http://dev.perl.org/perl6/doc/design/syn/S12.html. I see it in the Moose docs, but is this in Perl 6? I thought it was. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Synposis 26 - Documentation [alpha draft]
Dave Whipp wrote: I'm not a great fan of this concept of "reservation" when there is no mechanism for its enforcement (and this is perl...). What makes you assume there will be no mechanism for enforcement? The standard Pod parser (of which I have a 95% complete Perl 5 implementation) will complain bitterly--as in cyanide--when unknown pure-upper or pure-lower block names are used. The whole point of reserving these namespaces is not to prevent users from misusing them, but to ensure that when we eventually get around to using a particular block name, and those same users start screaming about it, we can mournfully point to the passage in the original spec and silently shake our heads. ;-) Damian
Re: s[pattern] = { doit } illegal, why?
In short, nearly every case where I'm looking to use a "raw" closure can be handled almost as easily by prefacing it with C (if the block doesn't take parameters) or C (if it does). A bit more wordy than I'd like, but acceptable; it still reads well. Although I'd recommend pointing this option out in S05, right after you say that s[pat] = { doit() } won't work. On 10/11/06, Larry Wall <[EMAIL PROTECTED]> wrote: s:s:g[<,> (\w+): (.+) <,>] = do for @().each -> $key, $val { $key => $val } Minor point: Since the right side gets called for each left-side match, isn't the C<.each> redundant? For that matter, isn't the C overkill as well? C<@()> will only ever have two elements per call, after all... : Could closures be : an exception to the "implicit curlies" rule? That is: if you supply : your own closure on the right, the substitution algorithm accepts it : as is; if you supply anything else, it gets wrapped in a closure as : described. Could do that too (and there's even precedent with attribute defaults), but outlawing it (at least for now) keeps people from cargo culting P5's s{foo}{bar} into P6's s{foo}={bar}. This would be the "ye olde code doesn't do a text substitution anymore" issue, right? And there _is_ still the possibility of permitting it in some later subversion of Perl 6, once people have gotten Perl 5 out of their systems... -- Jonathan "Dataweaver" Lang
Re: s[pattern] = { doit } illegal, why?
On Wed, Oct 11, 2006 at 06:29:00PM -0700, Larry Wall wrote: : s:s:g[<,> (\w+): (.+) <,>] = -> $key, $val { $key => $val }.(@()) Hmm, that won't work, since @() is a single argument. It'd have to be one of: s:s:g[<,> (\w+): (.+) <,>] = -> [$key, $val] { $key => $val }.(@()) s:s:g[<,> (\w+): (.+) <,>] = -> $key, $val { $key => $val }.(|@()) Larry
Re: s[pattern] = { doit } illegal, why?
On Wed, Oct 11, 2006 at 05:55:45PM -0700, Jonathan Lang wrote: : While I agree with most of the changes made to the s[]... notation, : there's one oddity that I just spotted: : : S05 says: : >This is not a normal assigment, since the right side is : >evaluated each time the substitution matches (much like the : >pseudo-assignment to declarators can happen at strange times). : >It is therefore treated as a "thunk", that is, as if it has : >implicit curlies around it. In fact, it makes no sense at all : >to say : > : >s[pattern] = { doit } : > : >because that would try to substitute a closure into the string. : : So I can't say something like : :s[(\d+)!] = { my $num = 1; $num *= $_ for 0..$0; return $num; } s[(\d+)!] = "{ my $num = 1; $num *= $_ for 0..$0; return $num; }" s[(\d+)!] = { my $num = 1; $num *= $_ for 0..$0; return $num; }.() s[(\d+)!] = do { my $num = 1; $num *= $_ for 0..$0; return $num; } : or : :s:s:g[(\w+): (\d+) dB] = : @() -> $name, $num { :$num = exp($num/10, 10); :say "$name has excessive wattage: $num Watts" if $num > 100; : :"$name: $num Watts"; : } s:s:g[(\w+): (\d+) dB] = do given @() -> [$name, $num] { $num = exp($num/10, 10); say "$name has excessive wattage: $num Watts" if $num > 100; "$name: $num Watts"; } : or : :s:s:g[<,> (\w+): (.+) <,>] = @() -> $key, $val { $key => $val } s:s:g[<,> (\w+): (.+) <,>] = -> $key, $val { $key => $val }.(@()) s:s:g[<,> (\w+): (.+) <,>] = do for @().each -> $key, $val { $key => $val } : ? That seems like a pretty significant limitation. Could closures be : an exception to the "implicit curlies" rule? That is: if you supply : your own closure on the right, the substitution algorithm accepts it : as is; if you supply anything else, it gets wrapped in a closure as : described. Could do that too (and there's even precedent with attribute defaults), but outlawing it (at least for now) keeps people from cargo culting P5's s{foo}{bar} into P6's s{foo}={bar}. Larry
s[pattern] = { doit } illegal, why?
While I agree with most of the changes made to the s[]... notation, there's one oddity that I just spotted: S05 says: This is not a normal assigment, since the right side is evaluated each time the substitution matches (much like the pseudo-assignment to declarators can happen at strange times). It is therefore treated as a "thunk", that is, as if it has implicit curlies around it. In fact, it makes no sense at all to say s[pattern] = { doit } because that would try to substitute a closure into the string. So I can't say something like s[(\d+)!] = { my $num = 1; $num *= $_ for 0..$0; return $num; } or s:s:g[(\w+): (\d+) dB] = @() -> $name, $num { $num = exp($num/10, 10); say "$name has excessive wattage: $num Watts" if $num > 100; "$name: $num Watts"; } or s:s:g[<,> (\w+): (.+) <,>] = @() -> $key, $val { $key => $val } ? That seems like a pretty significant limitation. Could closures be an exception to the "implicit curlies" rule? That is: if you supply your own closure on the right, the substitution algorithm accepts it as is; if you supply anything else, it gets wrapped in a closure as described. -- Jonathan "Dataweaver" Lang
Re: Runtime Role Issues
在 Oct 12, 2006 5:43 AM 時,Tim Bunce 寫到: On Tue, Oct 10, 2006 at 01:31:59PM -0700, Ovid wrote: Hi all, In doing a bit of work with traits (roles) in Perl 5 (http://perlmonks.org/?node_id=577477), I've realized some edge cases which could be problematic. First, when a role is applied to a class at runtime, a instance of that class in another scope may specifically *not* want that role. I always thought when a role is applied to a class at runtime you get a new (anonymous) subclass. The original class isn't affected. Right, that's what usually happens with: my Dog $fido .= new; $fido does Catlike; Here $fido's class become a new (memoized, anonymous) class that still has "Dog" as its name, but is no longer equivalent to the vanilla ^Dog class object. To forcefully add a role to a class at a distance during runtime, use a class object call (see Moose::Meta::Class for more about these APIs): ^Dog.add_role(^Catlike); Thanks, Audrey
Re: Cage Cleaner Wrangler?
i'd volunteer but what skills/duties are involved? hal chicago On Oct 11, 2006, at 4:34 PM, Andy Lester wrote: On Oct 11, 2006, at 4:32 PM, chromatic wrote: Who's looking after the Cage Cleaners these days? I've noticed a few people applying the patches, but it would be nice to have someone making sure we don't miss anything. I should be, but I've clearly been very lax. Would someone like to wear my cap? -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Runtime Role Issues
On Tue, Oct 10, 2006 at 01:31:59PM -0700, Ovid wrote: > Hi all, > > In doing a bit of work with traits (roles) in Perl 5 > (http://perlmonks.org/?node_id=577477), I've realized some edge cases > which could be problematic. > > First, when a role is applied to a class at runtime, a instance of that > class in another scope may specifically *not* want that role. I always thought when a role is applied to a class at runtime you get a new (anonymous) subclass. The original class isn't affected. Tim. > Is there > a way of restricting a role to a particular lexical scope short of > merely applying that role to instances instead of classes? > > Second, how can I remove roles from classes? I've create some code > which adds an "is_selected" method to some classes but when I'm done, > I'd like top easily remove that role. How do I do that? Seems closely > related to my first question, but it's still a distinct issue, I think. > > Third, http://dev.perl.org/perl6/doc/design/syn/S12.html says: > > You can also mixin a precomposed set of roles: > > $fido does Sentry | Tricks | TailChasing | Scratch; > > Should that be the following? > > $fido does Sentry & Tricks & TailChasing & Scratch; > > Cheers, > Ovid > > -- > > Buy the book -- http://www.oreilly.com/catalog/perlhks/ > Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Cage Cleaner Wrangler?
On Oct 11, 2006, at 4:32 PM, chromatic wrote: Who's looking after the Cage Cleaners these days? I've noticed a few people applying the patches, but it would be nice to have someone making sure we don't miss anything. I should be, but I've clearly been very lax. Would someone like to wear my cap? -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Null PMC access while parsing javascript
On Wed, Oct 11, 2006 at 10:56:39PM +0200, Mehmet Yavuz Selim Soyturk wrote: > I have rewritten the grammar. There are some problems though. > > - I don't know how to express thinks like: an identifier is > <[a..zA..Z_$]>*, but not a . Something like: rule identifier > {<[a..zA..Z_$]>*} seems not to allow identifiers that have > keywords as prefix. For now, try adding a \b at the ends of the rule: token keyword { \b [ if | else | for | while | ... ] \b } Then will match only the exact keyword. However, the "\b" metacharacter is disappearing soon, to be replaced by and . In its place will be "<<" and ">>", making the above: token keyword { << [ if | else | for | while | ... ] >> } I'll get << and >> added into PGE today/tomorrow. > - I couldn't make comments work. > - I don't know how to handle unicode, > - How to accomplish semicolon insertion? I'll have to look at the grammar a bit and see what I can come up with here. Pm
Cage Cleaner Wrangler?
Hi all, Who's looking after the Cage Cleaners these days? I've noticed a few people applying the patches, but it would be nice to have someone making sure we don't miss anything. -- c
Re: [svn:parrot-pdd] r14903 - in trunk: . docs/pdds/clip
Am Mittwoch, 11. Oktober 2006 22:37 schrieb [EMAIL PROTECTED]: > Log: > [EMAIL PROTECTED]: allison | 2006-10-11 13:18:42 -0700 > Partial update of Threads PDD with collected wisdom from prior discussion. I know the pdd is partial, but don't forget STM, which is a) implemented and b) solves a lot of described PMC sharing troubles e.g. hierachical locking needs. leo
Re: Null PMC access while parsing javascript
I have rewritten the grammar. There are some problems though. - I don't know how to express thinks like: an identifier is <[a..zA..Z_$]>*, but not a . Something like: rule identifier {<[a..zA..Z_$]>*} seems not to allow identifiers that have keywords as prefix. - I couldn't make comments work. - I don't know how to handle unicode, - How to accomplish semicolon insertion? - With some programs it doesn't stop. I don't know if it gets in an infinite loop or it is too slow, I didn't have time to look at it. Comments are welcome. -- Mehmet jsparser.tar.gz Description: GNU Zip compressed data
[svn:parrot-pdd] r14903 - in trunk: . docs/pdds/clip
Author: allison Date: Wed Oct 11 13:37:08 2006 New Revision: 14903 Modified: trunk/docs/pdds/clip/pdd25_threads.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: [EMAIL PROTECTED]: allison | 2006-10-11 13:18:42 -0700 Partial update of Threads PDD with collected wisdom from prior discussion. Modified: trunk/docs/pdds/clip/pdd25_threads.pod == --- trunk/docs/pdds/clip/pdd25_threads.pod (original) +++ trunk/docs/pdds/clip/pdd25_threads.pod Wed Oct 11 13:37:08 2006 @@ -20,7 +20,748 @@ =head1 DESCRIPTION -Description of the subject. +=head1 DEFINITIONS + +So we can all talk about things the same way, the following +definitons apply. Some of these are drawn from the POSIX thread spec, +and as such we should have a translation section at the end. + +=over 4 + +=item THREAD + +An OS level thread. If that makes no sense, neither will any of the +rest of this, in which case I recommend picking up "Programming with +POSIX Threads" by Dave Butenhof, and coming back when you have. + +=item MUTEX + +This is a low level, under the hood, not exposed to users, thing that +can be locked. They're non-recursive, non-read/write, exclusive +things. When a thread gets a mutex, any other attempt to get that +mutex will block until the owning thread releases the mutex. The +platform-native lock construct will be used for this. + +{{ - Nigel Sandever: Will this be macroised to hide the platform native +implementation from the main body of the code? +- Dan: Yes. }} + +=item LOCK + +This is an exposed-to-HLL-code thing that can be locked. Only PMCs can +be locked, and the lock may or may not be recursive or read/write. + +=item CONDITION VARIABLE + +The "sleep until something pings me" construct. Useful for queue +construction. Not conceptually associated with a MUTEX. (POSIX +threads require this, so we're going to hide it there behind macros +and/or functions) + +{{ - Nigel Sandever: Could you elaborate on the nature of what would constitute +a "ping"? +- Dan: POSIX has a function cond_signal (and cond_broadcast, which is +similar). What happens is a thread grabs the condition variable and +goes to sleep, and sleeps until another thread does a cond_signal, +which then wakes it up. If there are multiple threads sleeping on the +condition variable, only one is woken. (cond_broadcast wakes them all +up) }} + +=item RENDEZVOUS POINT + +A HLL version of a condition variable. + +=item INTERPRETER + +Those bits of the Parrot_Interp structure that are absolutely required +to be thread-specific. This includes the current register sets and +stack pointers, as well as security context information. Basically if +a continuation captures it, it's the interpreter. + +=item INTERPRETER ENVIRONMENT + +Those bits of the Parrot_Interp structure that aren't required to be +thread-specific (though I'm not sure there are any) I anything +pointed to that doesn't have to be thread-specific. + +The environment includes the global namespaces, pads, stack chunks, +memory allocation regions, arenas, and whatnots. Just because the +pointer to the current pad is thread-specific doesn't mean the pad +I has to be. It can be shared. + +=item INDEPENDENT THREAD + +A thread that has no contact I with the internal data of any +other thread in the current process. Independent threads need no +synchronization for anything other than what few global things we +have. And the fewer the better, though alas we can't have none at all. + +Note that independent threads may still communicate back and forth by +passing either atomic things (ints, floats, and pointers) or static +buffers that can become the property of the destination thread. + +=item SHARED THREAD + +A thread that's part of a group of threads sharing a common +interpreter environment. + +{{ - Leo: I presume that this "group of threads" is one thread pool or +interpreter pool. Could you expand the definition to cover "pool". +- Dan: Ah, damn, I needed to fix that up before sending it out. Should've been +"SHARED INTERPRETER". A shared interpreter is one that's in an interpreter +pool. + +An interpreter pool is a set of interpreters that share common +resources. They're essentially threads in the OS sense, and they have +shared access to pretty much everything. The memory pools, arenas, +and global namespace are shared--pretty much everything except what's +in the interpreter structure itself. }} + +=back + +=head1 REQUIREMENTS + +=head2 Supported Models + +=over 4 + +=item POSIX threads + +The threading scheme must be sufficient to support a POSIX +share-everything style of threading, such as is used in perl 5's +"pthread" model, as well as the thread models for Ruby and Python. + +=item "Process-type" threads + +The scheme must also support the perl 5 "iThreads" threading +model. In this model no data is shared implicitly, and all sharing +must be done on purpose and e
Re: [perl #40513] [CAGE] add flex/bison files to c coding standard tests
Jerry Gay (via RT) wrote: > *.l and *.y are c files, and must meet the coding standards for this filetype. > ~jerry > By "this filetype" I assume you mean the C standard. Although these files contain C code and that code should be written to the C standard, they are not C files. Each should have its own standard and part of that standard is: "Where C code appears, it should be written to the C standard as describe in (reference to C standard documentation)." This means that standards must be written for flex and bison. Neither is part of C and cannot be part of its standard. But because C is part of their files, the C standard must be part of their standards. To put it in C terms: the flex and bison standards must include the C standard, not the other way around. -- __END__ Just my 0.0002 million dollars worth, Shawn "For the things we have to learn before we can do them, we learn by doing them." Aristotle "Where you find the greatest fear, you find the greatest courage." BRIAN: You're all individuals! CROWD: We're all individuals! LONE VOICE IN THE BACK: I'm not!
Re: Synposis 26 - Documentation [alpha draft]
Jonathan Lang wrote: The only thing that I'd like to see changed would be to allow a more flexible syntax for formatting codes - in particular, I'd rather use something analogous to the 'embedded comments' described in S02, replacing the leading # with an appropriate capital letter (as defined by Unicode) and insisting on a word break just prior to it. It was a deliberate decision to restrict the delimiters to angles. Unlike embedded comments, formatting codes are predominantly embedded in text, not code, so it's important to keep them easy-to-locate (i.e. with a consistent delimiter) and not to allow too many syntaxes (which increases the chance of unintended codes in normal text). A leading word break is not really practical either, since documenters will need to use codes in the middle of words: PractI (and then practI) saying "GarEon!" I'd also prefer a more Wiki-like dialect at some point (e.g., '__underlined text__', '_italicized text_' and '*bold*' instead of 'U', 'I' and 'B'); but that can wait. That's Kwid. Which Ingy has proposed as a standard Perldoc dialect. You'll be able to flip into kwid mode (for Perldoc parsers that support it) using: =begin kwid =end kwid Damian
Re: [perl #40505] [PATCH] Addition of pmc files to codingstd tests
On Wednesday 11 October 2006 01:19, Paul Cochrane wrote: > This is because I was too fast with the "Send" button, and forgot to > attach the patch. Apologies for the doubled-up email. Nit: you can reply to a previous RT mail and attach the patch there. That saves a duplicate bug report that someone has to read, consider, and finally close as a duplicate. -- c
Re: [perl #40483] [PATCH] removal of cuddled else's in C source
On 10/11/06, Bernhard Schmalhofer via RT <[EMAIL PROTECTED]> wrote: On Mi. 11. Okt. 2006, 08:10:45, [EMAIL PROTECTED] wrote: > Yes, I got exacly the same output from r14895. Actually, this patch > was already applied by Bernhard in r14870, which explains why the > effected files list looks different. Sorry for creating confusion. I forgot to close this ticket after applying the patch in r14870. ah, no problem. thanks for applying. now that you (and paul) mention it, i think i remember ++ing you earlier for it :) ~jerry
Re: Runtime role issues
--- TSa <[EMAIL PROTECTED]> wrote: > > First, when a role is applied to a class at runtime, a instance of > > that class in another scope may specifically *not* want that role. > > Is there a way of restricting a role to a particular lexical scope > > short of applying that role to instances instead of classes? > > I think you'll need an intermediate class that you use to apply your > role. Classes are open and that implies the possibility to merge > further roles into them. But this applies for all users of the class. > How this works when there are already instances I don't know. Ah, that makes sense. > > Second, how can I remove roles from classes? > > Is that a wise thing to do? Roles are not assigned and removed > as a regular operation. What is your use case? I don't think I have a clear use case here because the examples that come to mind all involve adding and then quickly removing the extra behaviors when I'm done with them. That's going to be fraught with bugs. The "intermediate class" solves the problem but it instantly suggests that we have a new "design pattern" we have to remember. Basically, if I can't lexically scope the additional behavior a role offers, I potentially need to remove the role or use the "intermediate class" pattern. I suppose one could look at this as "separation of concerns". If I have an MVC framework, instances of objects in the M, V, or C portions might want to exhibit different behaviors, depending upon what I'm doing with them, but I don't necessarily want those behaviors to bleed over to the other layers of my application. Whether or not this is a clean way of looking at the problem, I don't know. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: signature subtyping and role merging
This is the "dog does bark" vs "tree does bark" problem. You can assume that the two methods "blahh" have naything semantically to do with each other at all. Unless ther is a specif annotation from the programmer creating the Role union that they are the same you must assume that they are different. Therefore your proposed signiture merge is nonsense in the general case. Even if the signature are the same the only case where you are justified in assuming that are the "same" method is if both composed Roles inherited the method from a common ancestor and even then you must solve the diamond inheritence problem. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- From: TSa <[EMAIL PROTECTED]> > HaloO, > > with my idea of deriving a type lattice from all role definitions > the problem of subtyping signatures arises. Please help me to think > this through. Consider > > role Foo > { > sub blahh(Int, Int) {...} > } > role Bar > { > sub blahh(Str) {...} > } > role Baz does Foo does Bar # Foo|Bar lub > { ># sub blahh(Int&Str,Int?) {...} > } > > The role Baz has to be the lub (least upper bound) of Foo and Bar. > That is the join of two nodes in the lattice. This means first of > all the sub blahh has to be present. And its signature has to be > in a subtype relation <: to :(Int,Int) and :(Str). Note that > Int <: Int&Str and Int|Str <: Int. The normal contravariant subtyping > rules for functions gives > > +- :> ---+ > || > :(Int&Str,Int?) <: :(Int,Int) >| | >+--- :> ---+ > and > > +- :> ---+ > || > :(Int&Str,Int?) <: :(Str) > > I hope you see the contravariance :) > > The question mark shall indicate an optional parameter that > allows the subtype to be applicable in both call sites that > have one or two arguments. > > The choice of glb for the first parameter makes the sub in Baz > require the implementor to use the supertype of Int and Str > which in turn allows the substitution of Int and Str arguments > which are subtypes---that is types with a larger interface. > > Going the other way in the type lattice the meet Foo&Bar of the > two roles Foo and Bar is needed. But here the trick with the > optional parameter doesn't work and it is impossible to reconcile > the two signatures. This could simply mean to drop sub blahh from > the interface. But is there a better way? Perhaps introducing a > multi? > > Apart from the arity problem the lub Int|Str works for the first > parameter: > > +- <: ---+ > || > :(Int|Str,Int) :> :(Int,Int) >| | >+--- <: ---+ > > + <: ---+ > | | > :(Int|Str) :> :(Str) > > > Regards, TSa. > --
Re: signature subtyping and role merging
On 10/11/06, TSa <[EMAIL PROTECTED]> wrote: HaloO, with my idea of deriving a type lattice from all role definitions the problem of subtyping signatures arises. Please help me to think this through. Consider role Foo { sub blahh(Int, Int) {...} } role Bar { sub blahh(Str) {...} } role Baz does Foo does Bar # Foo|Bar lub { # sub blahh(Int&Str,Int?) {...} } Please, no attempts to merge signatures. Instead, use multiple dispatch (though technically this doesn't kick in until the role is composed into a class). Thus: role Foo { multi blahh(Int, Int) {...} } role Bar { multi blahh(Str) {...} } role Baz does Foo does Bar # Foo|Bar lub { # multi blahh(Int, Int) {...} # multi blahh(Str) {...} } Remember that the name and the signature are used together to identify the routine for dispatch and composition purposes. Also, sub is an odd choice to use while illustrating role composition; while subs _are_ allowed in roles AFAIK, they're generally not put there. Methods and submethods are by far more common. -- Jonathan "Dataweaver" Lang
Re: class interface of roles
TSa wrote: Jonathan Lang wrote: > What do you mean by "uncomposed class"? The self always refers to the object as instance of the composed class. Methods are therefore resolving to the outcome of the composition process. But super in a role refers to methods from the class definition even when the final method comes from method combination in the composition process. Still not following. Can you give an example? > I hope not; that's exactly what declaring an unimplemented method in > a role is supposed to do. My idea is that the type system calculates a type bound for the class from the definition of the role. That includes attributes and their accessor methods. It's a matter of taste how explicit this interface is declared or how much of it is inferred. Note that it's entirely possible for attributes to not make it into the final class, if the accessor methods get redefined in such a way as to remove reference to the attributes. This is part of the notion that roles supply an outline of what the class should do, but only the class actually supplies the definitive details of how to do it. As I see it: "is" and "does" declarations in a role impose requirements on the final class: it must derive from another class ("is"), or it must compose another role ("does"). "method" and "has" are each one part requirement and one part suggestion: for "method", the class is required to include a method that matches the given name (which, of course, includes the method's signature), and a particular closure is suggested that the class can accept or override. For "has", the class is required to provide accessor methods corresponding to the attribute's read/write capabilities (a rw method if it's a rw attribute; a regular method if it's a regular attribute; and no method if it's a private attribute); like any other method, a closure is suggested that the class may accept or override. In addition, the role suggests that a given attribute be added to the class' state information. This suggestion is implicitly accepted if any of the methods that are used by the final class refer to the attribute; it is implicitly rejected if none of them do. The same rule applies to private methods. Thus, the only things that I'd recommend using to calculate a type-boundary would be the superclasses (provided by "is") and the method names (provided by "method" and "has"). > (And declaring an implemented method does > the same thing, with the addition that it also suggests an > implementation that the class is free to use or ignore as it sees > fit.) We have a priority conflict here. The question is if the class or the role is seeing the other's methods for method combination. I believe that I address this later on; if not, please clarify. >> (There does need to be a way to call, in a Role A, both the "blah" >> defined in A and whatever the "blah" the final class may use. Yes, this is the subject of the current debate. I'm opting for a method combination semantics that allows the role to call the class method. Agreed. >> $self.blah() is the later, $self.A::blah() or similar is likely to >> be the former.) > > No, there doesn't. Given that C and C B>, There needs to be a way to call, in class Foo, both the "blah" > defined in Foo, the "blah" defined in A (so that Foo can reimplement > A's version as a different method or as part of its own), and the > "blah" defined in B; From the class all composed parts are available through namespace qualified names. But a role is a classless and instanceless entity. The self refers to the objects created from the composed class. The role is not relevant in method dispatch. That is a method is never dispatched to a role. But the role should be able to participate in the method definition of the composed class. Also agreed. In particular, I'm referring to _how_ a role should participate in the method definition of the composed class; I am not referring to method dispatch, which is limited to the class hierarchy. > and there needs to be a way to call, in role A, > both the "blah" defined in Foo and the "blah" defined B; but role A > does not need a way to explicitly call a method defined in A. I'm not sure if I get this right. But as I said above a role can not be dispatched to. Which method do you think should take precedence the role's or the class's? That is who is the defining entity in the method combination process? I agree with the idea behind the current definition of this: if the class provides its own definition for a method, that should take precedence over the role's definition. If it doesn't, then it adopts the role's definition as its own. I would hope it is the role if a as of now unknown syntax has declared it. Perhaps it should be even the default. The rational for my claim is that a role is composed several times and then every class doing the role automatically gets the correct version. Otherwise all classes are burdened with caring for the role
[perl #40513] [CAGE] add flex/bison files to c coding standard tests
# New Ticket Created by Jerry Gay # Please include the string: [perl #40513] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40513 > *.l and *.y are c files, and must meet the coding standards for this filetype. ~jerry
signature subtyping and role merging
HaloO, with my idea of deriving a type lattice from all role definitions the problem of subtyping signatures arises. Please help me to think this through. Consider role Foo { sub blahh(Int, Int) {...} } role Bar { sub blahh(Str) {...} } role Baz does Foo does Bar # Foo|Bar lub { # sub blahh(Int&Str,Int?) {...} } The role Baz has to be the lub (least upper bound) of Foo and Bar. That is the join of two nodes in the lattice. This means first of all the sub blahh has to be present. And its signature has to be in a subtype relation <: to :(Int,Int) and :(Str). Note that Int <: Int&Str and Int|Str <: Int. The normal contravariant subtyping rules for functions gives +- :> ---+ || :(Int&Str,Int?) <: :(Int,Int) | | +--- :> ---+ and +- :> ---+ || :(Int&Str,Int?) <: :(Str) I hope you see the contravariance :) The question mark shall indicate an optional parameter that allows the subtype to be applicable in both call sites that have one or two arguments. The choice of glb for the first parameter makes the sub in Baz require the implementor to use the supertype of Int and Str which in turn allows the substitution of Int and Str arguments which are subtypes---that is types with a larger interface. Going the other way in the type lattice the meet Foo&Bar of the two roles Foo and Bar is needed. But here the trick with the optional parameter doesn't work and it is impossible to reconcile the two signatures. This could simply mean to drop sub blahh from the interface. But is there a better way? Perhaps introducing a multi? Apart from the arity problem the lub Int|Str works for the first parameter: +- <: ---+ || :(Int|Str,Int) :> :(Int,Int) | | +--- <: ---+ + <: ---+ | | :(Int|Str) :> :(Str) Regards, TSa. --
[perl #40507] [PATCH] Removal of cuddled else in pmc files
thanks, applied as r14897. ~jerry
Re: [perl #40483] [PATCH] removal of cuddled else's in C source
Jerry, 1) the patch leaves trailing spaces after the closing brackets (this isn't a coding standard (yet) but is a pet peeve of mine. if it were this alone, i'd modify the patch myself and apply. I can add a test for this to t/codingstd/cuddled_else.t if you want. 2) many of the source files you modified didn't show up in the output from the test. compare the list of files you modified to the list of failed files (here's my run from r14895): can you repeat this result? Yes, I got exacly the same output from r14895. Actually, this patch was already applied by Bernhard in r14870, which explains why the effected files list looks different. The cuddled else patch I most recently sent in ([perl #40507]) applied only to pmc files and is (indirectly) a result of the patch of t/codingstd/cuddled_else.t in r14985. Regards, Paul
Re: P5's s[pat][repl] syntax is dead
On Wed, Oct 11, 2006 at 10:32:13AM -0400, Aaron Sherman wrote: : @larry[0] wrote: : : >Log: : >P5's s[pat][repl] syntax is dead, now use s[pat] = "repl" : : Wow, I really missed this one! That's a pretty big thing to get my head : around. Are embedded closures in the string handled correctly so that: : : s:g[\W] = qq{\\{$/}}; : : Will do what I seem to be expecting it will? Yes, the right side is implicitly closurized and evaluated repeatedly by the left side. : How will that be defined in the Perl6-based parser? Will macros be able : to act as an LVALUE and modify their RVALUE in this way, or is this just : some unholy magic in the parser? This is just a macro with a fancy "is parsed" rule, I think. It eats the = in complete disregard for precedence. Nothing much to generalize, I think. : >+ s[pattern] = doit() : >+ s[pattern] = eval doit() : [...] : >+There is no syntactic sugar here, so in order to get deferred : >+evaluation of the replacement you must put it into a closure. The : >+syntactic sugar is provided only by the quotelike forms. : [...] : >+This is not a normal assigment, since the right side is evaluated each : >+time the substitution matches (much like the pseudo-assignment to : >declarators : >+can happen at strange times). It is therefore treated as a "thunk", that : >is, : >+as if it has implicit curlies around it. In fact, it makes no sense at : >+all to say : >+ : >+s[pattern] = { doit } : : Please clarify "quotelike forms", since to my untrained eye, the above : appeared to be contradictory at first (I read "quotelike forms" as s/// : not s{...}). s{...} is also a quotelike form. Basically I mean anything where you get to choose your own quote characters, whether or not they are brackets. : Very interesting. Yeah, we whacked on possible syntaxes a goodly long time on IRC the other night. Trying to balance out history and visuals and semantics and failure modes was all quite interesting, but in the absence of more Unicode keys on the keyboard I'm liking this notation pretty well, particularly since we've already used pseudo assignment in other places to thunkize the right side. Larry
Re: Runtime role issues
> First, when a role is applied to a class at runtime, a instance of that > class in another scope may specifically *not* want that role. Is there a > way of restricting a role to a particular lexical scope short of applying > that role to instances instead of classes? Seems like you could use an empty intermediate role to accomplish the same thing while leaving the shared class alone. Shared Class A Mixin Role B Class C isa A does B Class D isa A Shared Class A is unmodified. Otherwise, I think that any runtime modification of a class should affect all instances and future instances of that class. On closer inspection, is it even possible to add a Role to a Class at runtime? I thought that Class and Role composition outside of compile time resulted in a new pseudo Class for the subsequent instances of that composition - in which case the original Class would remain unmodified. Paul
P5's s[pat][repl] syntax is dead
@larry[0] wrote: Log: P5's s[pat][repl] syntax is dead, now use s[pat] = "repl" Wow, I really missed this one! That's a pretty big thing to get my head around. Are embedded closures in the string handled correctly so that: s:g[\W] = qq{\\{$/}}; Will do what I seem to be expecting it will? How will that be defined in the Perl6-based parser? Will macros be able to act as an LVALUE and modify their RVALUE in this way, or is this just some unholy magic in the parser? + s[pattern] = doit() + s[pattern] = eval doit() [...] +There is no syntactic sugar here, so in order to get deferred +evaluation of the replacement you must put it into a closure. The +syntactic sugar is provided only by the quotelike forms. [...] +This is not a normal assigment, since the right side is evaluated each +time the substitution matches (much like the pseudo-assignment to declarators +can happen at strange times). It is therefore treated as a "thunk", that is, +as if it has implicit curlies around it. In fact, it makes no sense at +all to say + +s[pattern] = { doit } Please clarify "quotelike forms", since to my untrained eye, the above appeared to be contradictory at first (I read "quotelike forms" as s/// not s{...}). Very interesting.
Re: [perl #40503] [PATCH] Removal of .imc filename change paragraph
On 10/11/06, Paul Cochrane <[EMAIL PROTECTED]> wrote: > i'm not 100% sure this is the right thing to do, either. the most > recent version of "perl 6 and parrot essentials" still makes reference > to '.imc' files. with this paragraph in deprecated.pod, there's > something to grep for that might help readers make the transition to > '.pir'. True. Thought it wouldn't hurt to ask. I won't be offended if the patch is rejected. :-) i've assigned the ticket to chip. i'm sure he'll make a decision and take action. ~jerry
Re: Fwd: [perl #40508] [PATCH] Removal of C++ comments in pmc files
On 10/11/06, Jonathan Worthington <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: > What's a "C++ comment"? If you mean //...\n comments, those are legal > in ANSI-99 C Parrot is using ANSI-98 C, I believe. And //\N+\n comments are not legal in that. jonathan ment C89 of course. some compilers on major platforms do not conform to C99, so until they do (or until chip decides to change the coding standards) that's the standard we're using. ~jerry
Re: [perl #40503] [PATCH] Removal of .imc filename change paragraph
i'm not 100% sure this is the right thing to do, either. the most recent version of "perl 6 and parrot essentials" still makes reference to '.imc' files. with this paragraph in deprecated.pod, there's something to grep for that might help readers make the transition to '.pir'. True. Thought it wouldn't hurt to ask. I won't be offended if the patch is rejected. :-) Paul
Re: [perl #40503] [PATCH] Removal of .imc filename change paragraph
On 10/11/06, via RT Paul Cochrane <[EMAIL PROTECTED]> wrote: # http://rt.perl.org/rt3/Ticket/Display.html?id=40503 > This patch removes the paragraph in DEPRECATED.pod mentioning that the .imc file extension is deprecated since there are no longer any .imc files in Parrot (having all been turned into .pir). I *think* this is the right thing to do, but I'm not 100% sure, and I hope I'm not overstepping any bounds or anything. i'm not 100% sure this is the right thing to do, either. the most recent version of "perl 6 and parrot essentials" still makes reference to '.imc' files. with this paragraph in deprecated.pod, there's something to grep for that might help readers make the transition to '.pir'. ~jerry
Re: Fwd: [perl #40508] [PATCH] Removal of C++ comments in pmc files
[EMAIL PROTECTED] wrote: What's a "C++ comment"? If you mean //...\n comments, those are legal in ANSI-99 C Parrot is using ANSI-98 C, I believe. And //\N+\n comments are not legal in that. Jonathan
[perl #40508] [PATCH] Removal of C++ comments in pmc files
Mark, What's a "C++ comment"? If you mean //...\n comments, those are legal in ANSI-99 C (and the syntax goes back to BCPL). If the coding standard specifies multiline-style comments only, fine, but please don't use misleading terminology. In my own defence, I was using terminology from pdd07, namely: Code Structure The following must apply: · C code must use C-style comments only, i.e. "/* comment */". (Not all C compilers handle C++-style comments.) And the files I patched failed the t/codingstd/cppcomments.t test when pmc files are added to the test. Apologies for causing confusion. Regards, Paul
Fwd: [perl #40508] [PATCH] Removal of C++ comments in pmc files
What's a "C++ comment"? If you mean //...\n comments, those are legal in ANSI-99 C (and the syntax goes back to BCPL). If the coding standard specifies multiline-style comments only, fine, but please don't use misleading terminology. -- Forwarded message -- From: via RT Paul Cochrane <[EMAIL PROTECTED]> Date: Wed, 11 Oct 2006 01:32:55 -0700 Subject: [perl #40508] [PATCH] Removal of C++ comments in pmc files To: [EMAIL PROTECTED] # New Ticket Created by "Paul Cochrane" # Please include the string: [perl #40508] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40508 > Hi, This patch changes C++ comments found in pmc files to C comments. Regards, Paul files affected: languages/APL/src/pmc/aplvector.pmc languages/pugs/pmc/pugscapture.pmc -- Mark J. Reed <[EMAIL PROTECTED]> Index: languages/APL/src/pmc/aplvector.pmc === --- languages/APL/src/pmc/aplvector.pmc (revision 14877) +++ languages/APL/src/pmc/aplvector.pmc (working copy) @@ -124,11 +124,15 @@ * we use our own type here. Perhaps a better way to * specify it? */ -//array_t = pmc_type(INTERP, -//string_from_const_cstring(INTERP, "APLVector", 0) -//); +/* +array_t = pmc_type(INTERP, +string_from_const_cstring(INTERP, "APLVector", 0) +); +*/ shape = pmc_new(INTERP,VTABLE_type(INTERP,SELF)); -//#array_t); +/* +#array_t); +*/ VTABLE_set_integer_native(INTERP, shape, 1); VTABLE_set_integer_keyed_int(INTERP,shape,0, VTABLE_get_integer(INTERP, SELF) Index: languages/pugs/pmc/pugscapture.pmc === --- languages/pugs/pmc/pugscapture.pmc (revision 14877) +++ languages/pugs/pmc/pugscapture.pmc (working copy) @@ -35,7 +35,9 @@ } siva; static PMC* intret; -// STRING * parrot_hash_get_idx(Interp *interpreter, Hash *hash, PMC * key); +/* +STRING * parrot_hash_get_idx(Interp *interpreter, Hash *hash, PMC * key); +*/ static PMC* undef_pmc; /*
[perl #40506] [PATCH] Removal of hard tabs in pmc files
# New Ticket Created by "Paul Cochrane" # Please include the string: [perl #40506] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40506 > Hi, This patch removes hard tabs found in .pmc files. Regards, Paul files affected: src/pmc/hash.pmc src/pmc/retcontinuation.pmc src/pmc/continuation.pmc src/pmc/closure.pmc src/pmc/namespace.pmc src/dynpmc/foo.pmc src/dynpmc/subproxy.pmc languages/cardinal/src/pmc/rubyclass.pmc languages/cardinal/src/pmc/rubyobject.pmc languages/tcl/src/pmc/tclstring.pmc languages/tcl/src/pmc/tclobject.pmc languages/dotnet/pmc/dotnetbytecode.pmc languages/dotnet/pmc/dotnetsignature.pmc languages/dotnet/pmc/dotnetmemberrefmetadata.pmc languages/dotnet/pmc/dotnetclassmetadata.pmc languages/dotnet/pmc/dotnettyperefmetadata.pmc languages/dotnet/pmc/dotnetassembly.pmc Index: src/pmc/hash.pmc === --- src/pmc/hash.pmc (revision 14877) +++ src/pmc/hash.pmc (working copy) @@ -413,12 +413,12 @@ HashBucket * const b = parrot_hash_get_bucket(INTERP, (Hash*) PMC_struct_val(SELF), key); if (b == NULL) { - /* - * TODO current behaviour of $S0 = hsh['no_such_key'] in - * PGE and possibly more code needs an empty STRING - * (--leo) - */ - return string_make_empty(INTERP,enum_stringrep_one,0); +/* + * TODO current behaviour of $S0 = hsh['no_such_key'] in + * PGE and possibly more code needs an empty STRING + * (--leo) + */ +return string_make_empty(INTERP,enum_stringrep_one,0); } return VTABLE_get_string(INTERP, (PMC*) b->value); } @@ -458,12 +458,12 @@ } b = parrot_hash_get_bucket(INTERP, hash, keystr); if (b == NULL) { - /* - * TODO current behaviour of $S0 = hsh['no_such_key'] in - * PGE and possibly more code needs an empty STRING - * (--leo) - */ - return string_make_empty(INTERP,enum_stringrep_one,0); +/* + * TODO current behaviour of $S0 = hsh['no_such_key'] in + * PGE and possibly more code needs an empty STRING + * (--leo) + */ +return string_make_empty(INTERP,enum_stringrep_one,0); } nextkey = key_next(INTERP, key); valpmc = b->value; Index: src/pmc/retcontinuation.pmc === --- src/pmc/retcontinuation.pmc (revision 14877) +++ src/pmc/retcontinuation.pmc (working copy) @@ -87,8 +87,8 @@ parrot_context_t *from_ctx = cc->from_ctx; struct PackFile_ByteCode * const seg = cc->seg; - next = SUPER(next); - Parrot_free_context(INTERP, from_ctx, 1); +next = SUPER(next); +Parrot_free_context(INTERP, from_ctx, 1); #ifdef NDEBUG /* the continuation is dead - delete and destroy it */ mem_sys_free(cc); Index: src/pmc/continuation.pmc === --- src/pmc/continuation.pmc (revision 14877) +++ src/pmc/continuation.pmc (working copy) @@ -240,7 +240,7 @@ int ret_continuation_p = SELF->vtable->base_type == enum_class_RetContinuation; - if (interpreter->current_runloop_id != cc->runloop_id +if (interpreter->current_runloop_id != cc->runloop_id /* it's ok if we are exiting to "runloop 0"; there is no such runloop, but the only continuation that thinks it came from runloop 0 is for the return from the initial sub call. */ @@ -249,11 +249,11 @@ outer frame, exiting to the inner run loop does the right thing, since it normally returns to the next outer runloop anyway. */ && ! ret_continuation_p) { - fprintf(stderr, "[oops; continuation %p of type %d " +fprintf(stderr, "[oops; continuation %p of type %d " "is trying to jump from runloop %d to runloop %d]\n", - SELF, (int) SELF->vtable->base_type, +SELF, (int) SELF->vtable->base_type, interpreter->current_runloop_id, cc->runloop_id); - } +} #if CTX_LEAK_DEBUG if (Interp_debug_TEST(interpreter, PARROT_CTX_DESTROY_DEBUG_FLAG)) { fprintf(stderr, Index: src/pmc/closure.pmc === --- src/pmc/closure.pmc (revision 14877) +++ src/pmc/closure.pmc (working copy) @@ -200,10 +200,10 @@ struct Parrot_sub * sub = PMC_sub(SELF); #if CTX_LEAK_DEBUG if (Interp_debug_TEST(INTERP, PARROT_CTX_DESTROY_DEBUG_FLAG)) { - fprintf(stderr, "[destroy closure %p, context %p, refs=%d]\n", - SELF, sub->outer_ctx, - (sub->outer_ctx ? sub->outer_ctx->ref_count : 0)); - } +fprintf(stderr, "[destroy cl
[perl #40503] [PATCH] Removal of .imc filename change paragraph
# New Ticket Created by "Paul Cochrane" # Please include the string: [perl #40503] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40503 > Hi, This patch removes the paragraph in DEPRECATED.pod mentioning that the .imc file extension is deprecated since there are no longer any .imc files in Parrot (having all been turned into .pir). I *think* this is the right thing to do, but I'm not 100% sure, and I hope I'm not overstepping any bounds or anything. Regards, Paul Index: DEPRECATED.pod === --- DEPRECATED.pod (revision 14877) +++ DEPRECATED.pod (working copy) @@ -10,17 +10,6 @@ =back -=head1 .imc file extension - -http://xrl.us/jc4u - - IMC vs. PIR - Two names enter - One name leaves - - /me giggles - -- Chip Salzenberg - =head1 Deprecated APIs =over 4
[perl #40510] [PATCH] Correction of pod in c_code_coda.t test
# New Ticket Created by "Paul Cochrane" # Please include the string: [perl #40510] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40510 > Hi, This patch corrects some of the pod in the t/codingstd/c_code_coda.t test. Regards, Paul Index: t/codingstd/c_code_coda.t === --- t/codingstd/c_code_coda.t (revision 14877) +++ t/codingstd/c_code_coda.t (working copy) @@ -11,19 +11,19 @@ =head1 NAME -t/codingstd/code_coda.t - checks for editor hint coda in source +t/codingstd/c_code_coda.t - checks for editor hint coda in C source =head1 SYNOPSIS # test all files -% prove t/codingstd/code_coda.t +% prove t/codingstd/c_code_coda.t # test specific files -% perl t/codingstd/code_coda.t src/foo.c include/parrot/bar.h +% perl t/codingstd/c_code_coda.t src/foo.c include/parrot/bar.h =head1 DESCRIPTION -Checks that all source files have the proper editor hints coda, +Checks that all C language source files have the proper editor hints coda, as specified in PDD07. =head1 SEE ALSO @@ -92,7 +92,7 @@ return ( map( $_->files_of_type('C code'), $DIST->c_source_file_directories ), map( $_->files_of_type('C header'), $DIST->c_header_file_directories ), -map( $_->files_of_type('PMC code'), $DIST->pmc_source_file_directories ), +map( $_->files_of_type('PMC code'), $DIST->pmc_source_file_directories ), ); }
[perl #40509] [NEW] Line endings test
# New Ticket Created by "Paul Cochrane" # Please include the string: [perl #40509] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40509 > Hi, This test checks for DOS line endings in C-language files, and I guess should go as part of the codingstd tests. Regards, Paul Index: t/codingstd/line_endings.t === --- t/codingstd/line_endings.t (revision 0) +++ t/codingstd/line_endings.t (revision 0) @@ -0,0 +1,84 @@ +#! perl +# Copyright (C) 2006, The Perl Foundation. +# $Id$ + +use strict; +use warnings; + +use lib qw( . lib ../lib ../../lib ); +use Test::More tests => 1; +use Parrot::Distribution; + +=head1 NAME + +t/codingstd/line_endings.t - checks for DOS line endings in source + +=head1 SYNOPSIS + +# test all files +% prove t/codingstd/line_endings.t + +# test specific files +% perl t/codingstd/line_endings.t src/foo.c include/parrot/bar.h + +=head1 DESCRIPTION + +Checks that source files do not have DOS (CRLF) line endings. + +=head1 SEE ALSO + +L + +=cut + +my $DIST = Parrot::Distribution->new; +my @files = @ARGV ? @ARGV : source_files(); +my @dos_files; + +foreach my $file (@files) { +my $buf; +my $path; + +## get the full path of the file +# if we have command line arguments, the file is the full path +if (@ARGV) { +$path = $file; +} + +# otherwise, use the relevant Parrot:: path method +else { +$path = $file->path; +} + +# slurp in the file +open( my $fh, '<', $path ) +or die "Cannot open '$path' for reading: $!\n"; +{ +local $/; +$buf = <$fh>; +} + +# append to the dos_files array if the code matches +push @dos_files => "$path\n" +if $buf =~ m{\015}; +} + +ok( !scalar(@dos_files), 'Line endings correct' ) +or diag( "DOS line ending found in " . scalar @dos_files . " files:[EMAIL PROTECTED]" ); + +exit; + +sub source_files { +return ( +map( $_->files_of_type('C code'), $DIST->c_source_file_directories ), +map( $_->files_of_type('C header'), $DIST->c_header_file_directories ), +map( $_->files_of_type('PMC code'), $DIST->pmc_source_file_directories ), +); +} + +# Local Variables: +# mode: cperl +# cperl-indent-level: 4 +# fill-column: 100 +# End: +# vim: expandtab shiftwidth=4:
[perl #40504] [PATCH] Addition of pmc files to codingstd tests
# New Ticket Created by "Paul Cochrane" # Please include the string: [perl #40504] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40504 > Hi, This patch adds pmc files to the list of files to test in the C-language coding standard tests. Regards, Paul files affected: t/codingstd/cppcomments.t t/codingstd/tabs.t t/codingstd/cuddled_else.t
[perl #40507] [PATCH] Removal of cuddled else in pmc files
# New Ticket Created by "Paul Cochrane" # Please include the string: [perl #40507] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40507 > Hi, This patch removes occurrences of "cuddled else" in pmc files. I guess this patch should probably go in after the pmc hard tab patch I just sent in. Regards, Paul files affected: src/pmc/os.pmc src/pmc/env.pmc src/pmc/tqueue.pmc src/pmc/delegate.pmc src/pmc/fixedpmcarray.pmc src/pmc/parrotobject.pmc src/pmc/undef.pmc src/pmc/stmvar.pmc src/pmc/file.pmc src/pmc/default.pmc src/pmc/integer.pmc src/pmc/fixedbooleanarray.pmc src/dynpmc/matchrange.pmc src/dynpmc/match.pmc languages/python/pmc/pybuiltin.pmc languages/python/pmc/pygen.pmc languages/amber/lib/kernel/pmc/amber_pathname.pmc languages/cardinal/src/pmc/rubyfloat.pmc languages/tcl/src/pmc/tclfloat.pmc languages/dotnet/pmc/dotnetassembly.pmc Index: src/pmc/os.pmc === --- src/pmc/os.pmc (revision 14877) +++ src/pmc/os.pmc (working copy) @@ -83,7 +83,8 @@ scwd = string_from_cstring(interpreter, cwd, strlen(cwd)); mem_sys_free(cwd); return scwd; -} else { +} +else { char *errmsg = strerror(errno); real_exception(interpreter, NULL, E_SystemError, errmsg); return NULL; @@ -142,7 +143,8 @@ char *errmsg = strerror(errno); real_exception(interpreter, NULL, E_SystemError, errmsg); } -} else { +} +else { error = remove(cpath); string_cstring_free(cpath); if (error) { Index: src/pmc/env.pmc === --- src/pmc/env.pmc (revision 14877) +++ src/pmc/env.pmc (working copy) @@ -138,7 +138,8 @@ case KEY_integer_FLAG: if(PMC_int_val(key) < 0) { retval = string_from_cstring(interpreter, "", 0); -} else { +} +else { envp = environ[PMC_int_val(key)]; p = strchr(envp, '='); retval = string_from_cstring(interpreter, envp, (p-envp)); @@ -152,10 +153,12 @@ string_cstring_free(keyname); if (val) { retval = string_from_cstring(interpreter, val, 0); -} else { +} +else { retval = string_from_cstring(interpreter, "", 0); } -} else { +} +else { retval = string_from_cstring(interpreter, "", 0); } if (free_it && val) mem_sys_free(val); @@ -187,10 +190,12 @@ string_cstring_free(keyname); if (val) { retval = string_from_cstring(INTERP, val, 0); -} else { +} +else { retval = string_from_cstring(INTERP, "", 0); } -} else { +} +else { retval = string_from_cstring(INTERP, "", 0); } if (free_it && val) mem_sys_free(val); Index: src/pmc/tqueue.pmc === --- src/pmc/tqueue.pmc (revision 14877) +++ src/pmc/tqueue.pmc (working copy) @@ -197,7 +197,8 @@ if (queue->tail) { queue->tail->next = entry; queue->tail = entry; -} else { +} +else { queue->head = entry; queue->tail = entry; } Index: src/pmc/delegate.pmc === --- src/pmc/delegate.pmc (revision 14877) +++ src/pmc/delegate.pmc (working copy) @@ -74,7 +74,8 @@ get_attrib_num((SLOTTYPE *)PMC_data(class), PCD_CLASS_NAME))) ); -} else { +} +else { real_exception(interpreter, NULL, E_LookupError, "Can't find method '%s' - erroneous PMC", string_to_cstring(interpreter, meth) Index: src/pmc/fixedpmcarray.pmc === --- src/pmc/fixedpmcarray.pmc (revision 14877) +++ src/pmc/fixedpmcarray.pmc (working copy) @@ -534,7 +534,8 @@ nextkey = key_next(INTERP, key); if (nextkey == NULL) { DYNSELF.set_number_keyed_int(k, value); -} else { +} +else { PMC* box; box = SELF.get_pmc_keyed_int(k); @@ -627,7 +628,8 @@ nextkey = key_next(INTERP, key); if (!nextkey) { DYNSELF.set_pmc_keyed_int(k, value); -} else { +} +else { PMC* box; box = S
[perl #40511] [PATCH] Removal of deprecated fetchmethod opcode
# New Ticket Created by "Paul Cochrane" # Please include the string: [perl #40511] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40511 > Hi, This patch removes the deprecated fetchmethod opcode from various ops files, and most of the documentation concerning the opcode. I've specifically not removed the corresponding paragraph in DEPRECATED.pod since I've already put in a patch affecting that file; I can patch it later if desired. I've also not patched PBC_COMPAT noting the pbc compatibility change as I think someone should review the patch first to make sure I've not stuffed something up (and a committer username is required in the file anyway). Hope this helps! Regards, Paul files affected: src/ops/ops.num src/ops/object.ops docs/pdds/clip/pdd15_objects.pod editor/pir-mode.el Index: src/ops/ops.num === --- src/ops/ops.num (revision 14877) +++ src/ops/ops.num (working copy) @@ -646,598 +646,596 @@ tailcallmethod_p_s 616 tailcallmethod_p_sc 617 tailcallmethod_p_p 618 -DELETED_fetchmethod_p_p_s 619 -DELETED_fetchmethod_p_p_sc 620 -addmethod_p_s_p 621 -addmethod_p_sc_p622 -can_i_p_s 623 -can_i_p_sc 624 -does_i_p_s 625 -does_i_p_sc 626 -isa_i_p_s 627 -isa_i_p_sc 628 -isa_i_p_p 629 -isa_i_p_pc 630 -newclass_p_s631 -newclass_p_sc 632 -newclass_p_p633 -newclass_p_pc 634 -subclass_p_p635 -subclass_p_p_s 636 -subclass_p_p_sc 637 -subclass_p_p_p 638 -subclass_p_p_pc 639 -subclass_p_pc 640 -subclass_p_s641 -subclass_p_sc 642 -subclass_p_pc_s 643 -subclass_p_pc_sc644 -subclass_p_s_s 645 -subclass_p_sc_s 646 -subclass_p_s_sc 647 -subclass_p_sc_sc648 -subclass_p_pc_p 649 -subclass_p_pc_pc650 -subclass_p_s_p 651 -subclass_p_sc_p 652 -subclass_p_s_pc 653 -subclass_p_sc_pc654 -getclass_p_s655 -getclass_p_sc 656 -getclass_p_p657 -getclass_p_pc 658 -singleton_p 659 -class_p_p 660 -classname_s_p 661 -addparent_p_p 662 -removeparent_p_p663 -addattribute_p_s664 -addattribute_p_sc 665 -removeattribute_p_s 666 -removeattribute_p_sc667 -removeattribute_p_i 668 -removeattribute_p_ic669 -getattribute_p_p_i 670 -getattribute_p_p_ic 671 -getattribute_p_p_s 672 -getattribute_p_p_sc 673 -setattribute_p_i_p 674 -setattribute_p_ic_p 675 -setattribute_p_s_p 676 -setattribute_p_sc_p 677 -classoffset_i_p_s 678 -classoffset_i_p_sc 679 -pic_infix___ic_p_p 680 -pic_inline_sub___ic_p_p 681 -pic_get_params___pc 682 -pic_set_returns___pc683 -pic_callr___pc 684 -new_p_i 685 -new_p_ic686 -new_p_i_p 687 -new_p_ic_p 688 -new_p_i_pc 689 -new_p_ic_pc 690 -new_p_sc691 -new_p_sc_p 692 -new_p_sc_pc 693 -new_p_pc694 -new_p_pc_p 695 -new_p_pc_pc 696 -typeof_s_p 697 -typeof_i_p 698 -typeof_i_p_k699 -typeof_i_p_kc 700 -typeof_i_p_ki 701 -typeof_i_p_kic 702 -typeof_s_i 703 -typeof_s_ic 704 -find_type_i_s 705 -find_type_i_sc 706 -find_type_i_p 707 -find_type_i_pc 708 -valid_type_i_i 709 -valid_type_i_ic 710 -get_repr_s_p711 -find_method_p_p_s 712 -find_method_p_p_sc 713 -defined_i_p 714 -defined_i_p_ki 715 -defined_i_p_kic 716 -defined_i_p_k 717 -defined_i_p_kc 718 -exists_i_p_ki 719 -exists_i_p_kic 720 -exists_i_p_k721 -exists_i_p_kc
[perl #40508] [PATCH] Removal of C++ comments in pmc files
# New Ticket Created by "Paul Cochrane" # Please include the string: [perl #40508] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40508 > Hi, This patch changes C++ comments found in pmc files to C comments. Regards, Paul files affected: languages/APL/src/pmc/aplvector.pmc languages/pugs/pmc/pugscapture.pmc Index: languages/APL/src/pmc/aplvector.pmc === --- languages/APL/src/pmc/aplvector.pmc (revision 14877) +++ languages/APL/src/pmc/aplvector.pmc (working copy) @@ -124,11 +124,15 @@ * we use our own type here. Perhaps a better way to * specify it? */ -//array_t = pmc_type(INTERP, -//string_from_const_cstring(INTERP, "APLVector", 0) -//); +/* +array_t = pmc_type(INTERP, +string_from_const_cstring(INTERP, "APLVector", 0) +); +*/ shape = pmc_new(INTERP,VTABLE_type(INTERP,SELF)); -//#array_t); +/* +#array_t); +*/ VTABLE_set_integer_native(INTERP, shape, 1); VTABLE_set_integer_keyed_int(INTERP,shape,0, VTABLE_get_integer(INTERP, SELF) Index: languages/pugs/pmc/pugscapture.pmc === --- languages/pugs/pmc/pugscapture.pmc (revision 14877) +++ languages/pugs/pmc/pugscapture.pmc (working copy) @@ -35,7 +35,9 @@ } siva; static PMC* intret; -// STRING * parrot_hash_get_idx(Interp *interpreter, Hash *hash, PMC * key); +/* +STRING * parrot_hash_get_idx(Interp *interpreter, Hash *hash, PMC * key); +*/ static PMC* undef_pmc; /*
[perl #40505] [PATCH] Addition of pmc files to codingstd tests
# New Ticket Created by "Paul Cochrane" # Please include the string: [perl #40505] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40505 > This is because I was too fast with the "Send" button, and forgot to attach the patch. Apologies for the doubled-up email. Hi, This patch adds pmc files to the list of files to test in the C-language coding standard tests. Regards, Paul files affected: t/codingstd/cppcomments.t t/codingstd/tabs.t t/codingstd/cuddled_else.t Index: t/codingstd/cppcomments.t === --- t/codingstd/cppcomments.t (revision 14877) +++ t/codingstd/cppcomments.t (working copy) @@ -65,6 +65,7 @@ return ( map( $_->files_of_type('C code'), $DIST->c_source_file_directories ), map( $_->files_of_type('C header'), $DIST->c_header_file_directories ), +map( $_->files_of_type('PMC code'), $DIST->pmc_source_file_directories ), ); } Index: t/codingstd/tabs.t === --- t/codingstd/tabs.t (revision 14877) +++ t/codingstd/tabs.t (working copy) @@ -59,6 +59,7 @@ return map { $_->path } ( map( $_->files_of_type('C code'), $DIST->c_source_file_directories ), map( $_->files_of_type('C header'), $DIST->c_header_file_directories ), +map( $_->files_of_type('PMC code'), $DIST->pmc_source_file_directories ), ); } Index: t/codingstd/cuddled_else.t === --- t/codingstd/cuddled_else.t (revision 14877) +++ t/codingstd/cuddled_else.t (working copy) @@ -59,6 +59,7 @@ return map { $_->path } ( map( $_->files_of_type('C code'), $DIST->c_source_file_directories ), map( $_->files_of_type('C header'), $DIST->c_header_file_directories ), +map( $_->files_of_type('PMC code'), $DIST->pmc_source_file_directories ), ); }
Re: Runtime role issues
HaloO, Ovid wrote: First, when a role is applied to a class at runtime, a instance of that class in another scope may specifically *not* want that role. Is there a way of restricting a role to a particular lexical scope short of applying that role to instances instead of classes? I think you'll need an intermediate class that you use to apply your role. Classes are open and that implies the possibility to merge further roles into them. But this applies for all users of the class. How this works when there are already instances I don't know. Second, how can I remove roles from classes? Is that a wise thing to do? Roles are not assigned and removed as a regular operation. What is your use case? Regards, TSa. --
Re: Runtime role issues
HaloO, Ovid wrote: Third, http://dev.perl.org/perl6/doc/design/syn/S12.html says: You can also mixin a precomposed set of roles: $fido does Sentry | Tricks | TailChasing | Scratch; Should that be the following? $fido does Sentry & Tricks & TailChasing & Scratch; If you follow my idea of a type lattice build from roles with | as join and & as meet operator these two mean something completely different. The first is the join or union of the roles while the second is their meet or intersection. The first creates a subtype of the roles the second a supertype. But the typishness of roles is debated. Regards, TSa. --
Runtime role issues
Hi all, I posted this to Perl6 users, but I was Warnocked, it was the wrong list, or both. Here's another stab at it. In doing a bit of work with traits (roles) in Perl 5 (http://perlmonks.org/?node_id=577477), I've realized some edge cases which could be problematic. First, when a role is applied to a class at runtime, a instance of that class in another scope may specifically *not* want that role. Is there a way of restricting a role to a particular lexical scope short of applying that role to instances instead of classes? Second, how can I remove roles from classes? I've create some code which adds an "is_selected" method to some classes but when I'm done, I'd like top easily remove that role. How do I do that? Seems closely related to my first question, but it's still a distinct issue, I think. Third, http://dev.perl.org/perl6/doc/design/syn/S12.html says: You can also mixin a precomposed set of roles: $fido does Sentry | Tricks | TailChasing | Scratch; Should that be the following? $fido does Sentry & Tricks & TailChasing & Scratch; Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: class interface of roles
HaloO, Jonathan Lang wrote: So if I'm reading this right, a class that does both A and B should be "lower" in the partial ordering than a class that does just one or the other. And if A does B, then you'll never have a class that does just A without also doing B, which trims out a few possible nodes and paths from the lattice for practical purposes: Any={} | \ | \ |\ | \ | \ B={y} C={z} / \ | / \ | / \| / \ | / \ | / \ | A|B={x,y} B|C={y,z} \ / \ / \ / \ / \ / A|B|C={x,y,z} Correct. The lattice is a structural analysis of the roles. I note that while the lattice is related to whatever role hierarchies may or may not exist, it is not the same as them. In particular, roles that have no hierarchal relationship to each other _will_ exist in the same lattice. In fact, all roles will exist in the same lattice, on the first row under "Any". Right? Yes, if they are disjoined structurally. Otherwise intersection roles appear as nodes under Any. Or does the fact that "A does B" mean that A would be placed where "A|B" is, and "A|C" would end up in the same node as "A|B|C"? To get at the node labeled A|B above you either need a definition role A does B { has $.x } or an outright full definition role A { has $.x; has $.y } So, yes the node should be called A and A|C coincides with A|B|C. I'm not sure if this ordering of roles can be called duck typing because it would put roles that have the same content into the same lattice node. The well known bark method of Dog and Tree comes to mind. But the arrow types of the methods will be different. One has type :(Dog --> Dog) the other :(Tree --> Tree) and a joined node will have type :(Dog&Tree --> Dog|Tree). This might just give enough information to resolve the issues surrounding the DogTree class. By "most specific", you'd mean "closest to the top"? No, closer to the bottom. The join operator | of the lattice produces subtypes with a larger interface that is more specific. It's like the more derived class in a class hierarchy. Regards, TSa. --
Re: class interface of roles
HaloO, Jonathan Lang wrote: What do you mean by "uncomposed class"? The self always refers to the object as instance of the composed class. Methods are therefore resolving to the outcome of the composition process. But super in a role refers to methods from the class definition even when the final method comes from method combination in the composition process. I think the word "super" is already to overloaded to be used for this purpose. Setting that aside for now... Better ideas? Is there a super keyword already? Or do you mean overloaded in general OO and type speak? Do you mean that super.blah() appearing in a method defined in a role A should require that all classes which do A need to provide a blah implementation? (or produce a composition time error if they don't) Yes, this is exactly what I mean with superclass interface of roles. I hope not; that's exactly what declaring an unimplemented method in a role is supposed to do. My idea is that the type system calculates a type bound for the class from the definition of the role. That includes attributes and their accessor methods. It's a matter of taste how explicit this interface is declared or how much of it is infered. (And declaring an implemented method does the same thing, with the addition that it also suggests an implementation that the class is free to use or ignore as it sees fit.) We have a priority conflict here. The question is if the class or the role is seeing the other's methods for method combination. A Role should be able to say "to do this Role you need to implement these methods" and have a compile/composition time error if not. Agreed. I agree as well. But on a wider scope then just method provision. (There does need to be a way to call, in a Role A, both the "blah" defined in A and whatever the "blah" the final class may use. Yes, this is the subject of the current debate. I'm opting for a method combination semantics that allows the role to call the class method. $self.blah() is the later, $self.A::blah() or similar is likely to be the former.) No, there doesn't. Given that C and CB>, There needs to be a way to call, in class Foo, both the "blah" defined in Foo, the "blah" defined in A (so that Foo can reimplement A's version as a different method or as part of its own), and the "blah" defined in B; From the class all composed parts are available through namespace qualified names. But a role is a classless and instanceless entity. The self refers to the objects created from the composed class. The role is not relevant in method dispatch. That is a method is never dispatched to a role. But the role should be able to participate in the method definition of the composed class. and there needs to be a way to call, in role A, both the "blah" defined in Foo and the "blah" defined B; but role A does not need a way to explicitly call a method defined in A. I'm not sure if I get this right. But as I said above a role can not be dispatched to. Which method do you think should take precedence the role's or the class's? That is who is the defining entity in the method combination process? I would hope it is the role if a as of now unknown syntax has declared it. Perhaps it should be even the default. The rational for my claim is that a role is composed several times and then every class doing the role automatically gets the correct version. Otherwise all classes are burdened with caring for the role's part in the method. It should assume that if Foo overrides A's implementation of blah, Foo knows what it's doing; by the principle of least surprise, Foo should never end up overriding A's implementation of blah only to find that the original implementation is still being used by another of the methods acquired from A. Could you make an example because I don't understand what you mean with original implementation and how that would be used by role methods. Method dispatch is on the class never on the role. As far as dispatch is concerned the role is flattend out. But the question is how the class's method is composed in the first place. Regards, --