PMCs exact allocated size
Hi, It could be useful to have a way to know the exact memory footprint of any PMC. For instance, suppose that each PMC must override/implement a method get_allocated_size(), it could be used to optimize programs that takes too much memory, or to debug/optimize PMC implementation. That method could run in non constant time, e.g for a linked list. What do you think ? Karl
[QUESTION] PMC Pre-allocation
Hi, Is there a way to specify a minimum allocation size for PMCs like strings or arrays ? Something like in perl : %h = 1000 ? It could boost execution times when you have a good idea of the space you need. For example, I'd like to do: #ensure that the array has enough allocated storage for 100 elements without need for allocationg memory new P0, .Array, 100 and then push 1,000,000 elements. N.B: it is not the same as new P0, .Array P0 = 100 Thx Karl
Re: Edge case: incongruent roles
TSa wrote: Pinning the return type to Num is bad e.g. if you want multi targets like :(Complex,Complex-->Complex). Should that also numerify complex values when stored in a Num container? If yes, how? If at all possible, I would expect Complex to compose Num, thus letting a Complex be used anywhere that a Num is requested. -- Jonathan "Dataweaver" Lang
Re: class interface of roles
I think I found the core of the issue here; it has to do with the
differences between roles and mixins, with an analogous difference
between compile-time composition and runtime composition. Details
follow.
TSa wrote:
Jonathan Lang wrote:
> Just to make sure we're speaking the same language: by "superclass",
> you're referring to classes brought in via "is"; right?
No. I used the term 'superclass interface' as it appears in the
article I referred to. There the role has a type constraint interface
to the uncomposed class which is available through the super keyword.
Ah. Unfortunately, said article is part 15 of a series. While it's
true that only a handful of them are directly referenced by the
article, that's still more than I've had time to read so far - and the
unreferenced articles still matter in that they provide the
grammatical context in which Article 15 is phrased.
Let's settle for the terms 'uncomposed class' and 'composed class'.
Then I meant the interface of the role to the uncomposed class.
Let me figure out what you mean by 'uncomposed class' and 'composed
class' before I agree to the terminology. The original article seems
to be making an assumption that you will always take an existing class
and a mixin in order to create a new class. If this is the
assumption, then the existing class would be the 'uncomposed class',
the mixin would be the 'role', and the new class would be the
'composed class'.
This, however, is not the default paradigm used by Perl 6. If you
want to do this sort of thing in perl 6, you say something like:
class ComposedClass is UncomposedClass does Role { ... }
In particular, perl 6 does not assume the existence of an uncomposed
class when using roles unless you explicitly specify one: there is
just the role and the composed class that fleshes out that role.
This, I believe, is the fundamental difference between roles and
mixins: the latter assumes that it's being mixed in to something
pre-existing to produce something new; the former doesn't.
Just to clarify some terminology: in the above statement,
'ComposedClass' composes 'Role', and 'ComposedClass' inherits from
'UncomposedClass'. Conversely, 'Role' is composed into
'ComposedClass'.
'UncomposedClass' is a superclass of 'ComposedClass', 'ComposedClass'
is a subclass of 'UncomposedClass', and 'Role' is a role of
'ComposedClass'. AFAIK, there's no standard term for what
'ComposedClass' is in relation to 'Role' - though personally, I'd tend
to say that 'ComposedClass' is an implementation of 'Role'.
My understanding is that mixin terminology would be that 'role' is
mixed into 'UncomposedClass' to produce 'ComposedClass'.
It might be the case that you should think of the role composition
to happen on a new anonymous class that inherits everything from the
uncomposed class and therefore has a proper superclass interface.
The only situation in perl6 that I know of where an anonymous class is
generated when a role is composed is when you compose the role at
runtime.
Incidently, your comments to date are much more compatable with
runtime composition than they are with compile-time composition. In
fact, a case could be made that runtime composition always uses the
mixin paradigm, whereas compile-time composition doesn't.
The paradigm used by compile-time composition is that the role acts as
a blueprint for building the class. It does not get "mixed in" to
anything; it instead provides requirements that the class must meet,
and an optional toolkit that the class may use in meeting those
requirements.
Conflicts between roles prevent the installation of a composed method
and hence leave the task of defining it to the composed class.
This is how things work now, during compile-time: if two roles provide
potentially incompatable method implementations, the class is required
to supply a replacement for them.
If I understand runtime composition correctly, undefined methods in a
role fall back on the uncomposed class' definitions; this means that
it is an error to compose a role at runtime that declares a method
that the uncomposed class lacks without defining it, even if a later
role in the sequence provides a definition for it.
I admit that the distinction between these cases can come as a surprise
to class developers. But composing more than one role is equal in
complexity as multiple inheritance. So a warning is a good thing here.
The 'is override' trait might be needed to silence the warning. Well,
and you can switch it off with a pragma or the trait on the class.
The distinction _does_ come as a surprise to me, but only because perl
handles single-role composition in a way that's fully compatable with
the multiple-role composition strategy that you just outlined. That
is, perl doesn't make a distinction; it assumes single-role
composition to be a special case of multiple-role composition.
The whole point of the article is to calculate the composed class type.
This process is akin to i
Re: [perl #40543] [NEW] Test for space after curly braces
On Oct 17, 2006, at 4:25 PM, Jerry Gay via RT wrote: On Tue Oct 17 07:33:02 2006, [EMAIL PROTECTED] wrote: Well, the verdict defnitely seems to be that trailing space and tab characters are annoyances that should go away :-) This patch adds a new test (in place of the curly-space test I posted earlier) which searches for superfluous trailing spaces in source files. Comments definitely welcome! this is too noisy as ~700 tests. please convert it to one test, like the other coding standard tests. t/codingstd/perlcritic.pl at least, has a test per file. also, it should apply to perl files, as well. in fact, it should probably apply to most files in MANIFEST and MANIFEST.skip, except for a few where the spaces are required (like some test data files.) however, i'd accept this patch if it were extended only to cover the perl files. This is covered by perlcritic already, and if not, should be. I'm happy to keep this targeted at the c-only files. These tests already take too long to run, no need to test everything 2x. thanks for your hard work! ~jerry -- Will "Coke" Coleda [EMAIL PROTECTED]
Re: Coding Standard Questions
Am Dienstag, 17. Oktober 2006 23:19 schrieb Kevin Tew: > > I view lines as a valuable resource. I like to fit whole functions on > > the screen when possible so I'm more of a fan of If you are out of lines: $ perl -e'++$lines for 1..1000' helps for some time, then pleae restart. > > if (foo) bar(); > > else bat(); That's an unreadable mess. EOT (this one) leo
Re: Coding Standard Questions MAKE IT STOP
Please, let's go with whatever's written in the PDD. Coding standards discussions = much heat, little light. I'm sorry I responded to anything in this thread in the first place. Please. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Coding Standard Questions
Am Dienstag, 17. Oktober 2006 23:19 schrieb Kevin Tew:
> if ( foo )
> bar();
> else
> bat();
> if ( foo )
no spaces in the parens. No example in pdd07 is looking like this. There where
some ident rules in that pdd some time ago regarding that.
Above vs.:
if (foo) {
bar();
}
else {
bat();
}
Anything that has the smallest smell of ever needing an extra statement after
if or else shall use braces in the first place (IMHO).
if (ending)
return 1;/* ok for me */
if (foo) {
do_something(); /* might need something else too */
}
leo
Re: Coding Standard Questions
Kevin Tew wrote:
> 1) *s should go right next to the type in function declarations and
> definitions
>
> /* incorrect */
> do_thaw(Parrot_Interp interpreter, PMC * pmc, visit_info *info)
> /* correct */
> do_thaw(Parrot_Interp interpreter, PMC* pmc, visit_info* info)
Disagree. Consider:
char* foo ()
{
char* str1, str2;
...
}
As compared to:
char *foo()
{
char *str1, *str2;
...
}
I seen this error many times. Because of the way C associates the * with
the variable, not the type, you should write the code that way.
>
> 2) All structs should be typedefed
>
> 3) Single line if and elses are acceptable
>
> /*old*/
>if (!info->thaw_result)
> info->thaw_result = pmc;
>else
> *info->thaw_ptr = pmc;
>
> /*new*/
>if (!info->thaw_result) info->thaw_result = pmc;
>else *info->thaw_ptr = pmc;
Disagree. Subsequences should always be blocked.
if( ! info->thaw_result ){
info->thaw_result = pmc;
}else{
info->thaw_result = pmc;
}
Reasons:
1. It clear what is associated with what.
2. It's closer to what Perl does.
3. Statements can be added eaiser.
>
>
> 4) c89 allows declaration and initialization on the same line right?
> INTVAL counter = 0;
>
> Kevin
>
--
__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: Coding Standard Questions
Am Dienstag, 17. Oktober 2006 22:33 schrieb Kevin Tew: > While exploring Parrot internals I started cleaning up some code. > I'll post patches to the list, but here are some things that are not > defined by the coding standards, but of which I'm a fan. > So the question is are they acceptable in the parrot code base. > > 1) *s should go right next to the type in function declarations and > definitions > > /* incorrect */ > do_thaw(Parrot_Interp interpreter, PMC * pmc, visit_info *info) > /* correct */ > do_thaw(Parrot_Interp interpreter, PMC* pmc, visit_info* info) Both look wrong to me, my POV is: do_thaw(Interp *interpreter, PMC *pmc, visit_info *info) a) Parrot_Interp was removed for some reason long time ago in almost all of the code (it's usage ought to be in embed land). Please lookup p6i history. b) Re PMC* a vs. PMC *a: the former might make one think of PMC* is declaring some pointers: PMC* a, b; # oops wrong b isn't a pointer at all PMC *a, *b; # all fine > 2) All structs should be typedefed No. Commonly used structs might be typedefed, but that should never be enforced. > 3) Single line if and elses are acceptable Nevva. > 4) c89 allows declaration and initialization on the same line right? > INTVAL counter = 0; of course. > Kevin leo
Re: Coding Standard Questions
Kevin Tew wrote:
Jerry thanks for finding the reference in pdd07.
Note I'm not trying to start a preference war here, I would just like
Chip to rule on some things that are not in the coding spec yet.
Thanks,
Kevin
Prvious mail should have read:
if ( foo )
bar();
else
bat();
I cant find it in the spec pdd07 but I though Chip said no curlies on
single statements bodies of ifs
if ( foo )
bar(); else
bat();
I view lines as a valuable resource. I like to fit whole functions on
the screen when possible so I'm more of a fan of
if (foo) bar();
else bat();
Curlies are ok with me too, but I think a decision against curlies was
made.
if (foo) { bar(); }
else { bat(); }
Andy Lester wrote:
On Oct 17, 2006, at 3:33 PM, Kevin Tew wrote:
if (!info->thaw_result) info->thaw_result = pmc;
else *info->thaw_ptr = pmc;
No, definitely not.
if ( foo ) {
bar();
}
else {
bat();
}
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Coding Standard Questions
I cant find it in the spec pdd07 but I though Chip said no curlies on
single statements bodies of ifs
if ( foo )
bar();
else
bat();
I view lines as a valuable resource. I like to fit whole functions on
the screen when possible so I'm more of a fan of
if (foo) bar();
else bat();
Curlies are ok with me too, but I think a decision against curlies was made.
if (foo) { bar(); }
else { bat(); }
Andy Lester wrote:
On Oct 17, 2006, at 3:33 PM, Kevin Tew wrote:
if (!info->thaw_result) info->thaw_result = pmc;
else *info->thaw_ptr = pmc;
No, definitely not.
if ( foo ) {
bar();
}
else {
bat();
}
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Coding Standard Questions
On Tuesday 17 October 2006 14:01, Andy Lester wrote:
> On Oct 17, 2006, at 3:33 PM, Kevin Tew wrote:
> >if (!info->thaw_result) info->thaw_result = pmc;
> >else *info->thaw_ptr = pmc;
>
> No, definitely not.
>
> if ( foo ) {
> bar();
> }
> else {
> bat();
> }
Chip already weighed in the other way.
-- c
Re: Coding Standard Questions
On 10/17/06, Andy Lester <[EMAIL PROTECTED]> wrote:
On Oct 17, 2006, at 3:33 PM, Kevin Tew wrote:
>if (!info->thaw_result) info->thaw_result = pmc;
>else *info->thaw_ptr = pmc;
No, definitely not.
if ( foo ) {
bar();
}
else {
bat();
}
if (foo)
bar();
else
bat();
is specced in the code formatting section of pdd07. specifically, "Do
not routinely put single statements in statement blocks" and
"parentheses should not have space immediately after the opening
parenthesis nor immediately before the closing parenthesis" apply
here.
~jerry
Re: Coding Standard Questions
On Oct 17, 2006, at 3:33 PM, Kevin Tew wrote:
if (!info->thaw_result) info->thaw_result = pmc;
else *info->thaw_ptr = pmc;
No, definitely not.
if ( foo ) {
bar();
}
else {
bat();
}
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Coding Standard Questions
On 10/17/06, Kevin Tew <[EMAIL PROTECTED]> wrote:
1) *s should go right next to the type in function declarations and
definitions
I disagree; they should go right next to the name being declared,
since C declarations are designed to reflect the way the declared item
is later used: PMC *pmc, visit_info *info.
2) All structs should be typedefed
That seems reasonable. What about struct names? Around here we
require that all structs have both a struct name and a typedef, and
the two names match:
typedef struct foo {...} foo;
It's redundant except when you need to declare a self-referential
pointer, of course, but consistency for consistency's sake isn't
always bad. :)
3) Single line if and elses are acceptable
I personally don't like that. I'd rather go tthe other way and
require curlies always.
4) c89 allows declaration and initialization on the same line right?
INTVAL counter = 0;
Sure. Even pre-ANSI C allows that.
--
Mark J. Reed <[EMAIL PROTECTED]>
Coding Standard Questions
While exploring Parrot internals I started cleaning up some code. I'll post patches to the list, but here are some things that are not defined by the coding standards, but of which I'm a fan. So the question is are they acceptable in the parrot code base. 1) *s should go right next to the type in function declarations and definitions /* incorrect */ do_thaw(Parrot_Interp interpreter, PMC * pmc, visit_info *info) /* correct */ do_thaw(Parrot_Interp interpreter, PMC* pmc, visit_info* info) 2) All structs should be typedefed 3) Single line if and elses are acceptable /*old*/ if (!info->thaw_result) info->thaw_result = pmc; else *info->thaw_ptr = pmc; /*new*/ if (!info->thaw_result) info->thaw_result = pmc; else *info->thaw_ptr = pmc; 4) c89 allows declaration and initialization on the same line right? INTVAL counter = 0; Kevin
[perl #40543] [NEW] Test for space after curly braces
On Tue Oct 17 07:33:02 2006, [EMAIL PROTECTED] wrote: > Well, the verdict defnitely seems to be that trailing space and tab > characters are annoyances that should go away :-) This patch adds a > new test (in place of the curly-space test I posted earlier) which > searches for superfluous trailing spaces in source files. > > Comments definitely welcome! > this is too noisy as ~700 tests. please convert it to one test, like the other coding standard tests. also, it should apply to perl files, as well. in fact, it should probably apply to most files in MANIFEST and MANIFEST.skip, except for a few where the spaces are required (like some test data files.) however, i'd accept this patch if it were extended only to cover the perl files. thanks for your hard work! ~jerry
Re: [perl #40559] AutoReply: $FindBin::Bin has a trailing / in scripts on Perl 5.8.3
looks like a valid problem, and a valid solution... commit away!
~jerry
On 10/17/06, Kevin Tew <[EMAIL PROTECTED]> wrote:
Used Cwd::abs_path like FindBin in perl 5.8.6 does.
defaults.pm |3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
Index: config/init/defaults.pm
===
--- config/init/defaults.pm (revision 14936)
+++ config/init/defaults.pm (working copy)
@@ -21,6 +21,7 @@
use Config;
use FindBin;# see build_dir
use Parrot::Configure::Step;
+use Cwd qw(abs_path);
$description = q{Setting up Configure's default values};
@@ -35,7 +36,7 @@
debugging => $conf->options->get('debugging') ? 1 : 0,
optimize => '',
verbose => $conf->options->get('verbose'),
-build_dir => $FindBin::Bin,
+build_dir => abs_path($FindBin::Bin),
# Compiler -- used to turn .c files into object files.
# (Usually cc or cl, or something like that.)
Re: [perl #40559] AutoReply: $FindBin::Bin has a trailing / in scripts on Perl 5.8.3
Used Cwd::abs_path like FindBin in perl 5.8.6 does.
defaults.pm |3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
Index: config/init/defaults.pm
===
--- config/init/defaults.pm (revision 14936)
+++ config/init/defaults.pm (working copy)
@@ -21,6 +21,7 @@
use Config;
use FindBin;# see build_dir
use Parrot::Configure::Step;
+use Cwd qw(abs_path);
$description = q{Setting up Configure's default values};
@@ -35,7 +36,7 @@
debugging => $conf->options->get('debugging') ? 1 : 0,
optimize => '',
verbose => $conf->options->get('verbose'),
-build_dir => $FindBin::Bin,
+build_dir => abs_path($FindBin::Bin),
# Compiler -- used to turn .c files into object files.
# (Usually cc or cl, or something like that.)
Re: Parrot::Coroutine
Am Dienstag, 17. Oktober 2006 10:47 schrieb François PERRAD: > Now, Lua doesn't depend of the deprecated Coroutine PMC. Coroutine PMC isn't deprecated, it's limited in its functionality. leo
[perl #40559] $FindBin::Bin has a trailing / in scripts on Perl 5.8.3
# New Ticket Created by Kevin Tew
# Please include the string: [perl #40559]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40559 >
defaults.pm |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
Fixes this problem
Generating makefiles and other build files...
step gen::makefiles died during execution:
config/gen/makefiles/bcg.in:73: line ends in a slash
at Configure.pl line 501
Index: config/init/defaults.pm
===
--- config/init/defaults.pm (revision 14936)
+++ config/init/defaults.pm (working copy)
@@ -31,11 +31,13 @@
my ($self, $conf) = @_;
# We need a Glossary somewhere!
+my $findbin = $FindBin::Bin;
+$findbin =~ s/\/$//g;
$conf->data->set(
debugging => $conf->options->get('debugging') ? 1 : 0,
optimize => '',
verbose => $conf->options->get('verbose'),
-build_dir => $FindBin::Bin,
+build_dir => $findbin,
# Compiler -- used to turn .c files into object files.
# (Usually cc or cl, or something like that.)
Re: Edge case: incongruent roles
HaloO, TSa wrote: I know that the return type of / could be Num in "reality" but that spoils the example. Sorry if the above is a bad example. Pinning the return type to Num is bad e.g. if you want multi targets like :(Complex,Complex-->Complex). Should that also numerify complex values when stored in a Num container? If yes, how? --
Re: Edge case: incongruent roles
HaloO, Larry Wall wrote: On Fri, Oct 13, 2006 at 04:56:05PM -0700, Jonathan Lang wrote: : Trey Harris wrote: : >All three objects happen to be Baz's, yes. But the client code doesn't : >see them that way; the first snippet wants a Foo, the second wants a Bar. : >They should get what they expect, or Baz can't be said to "do" either. : : In principle, I agree; that's how it _should_ work. I'm pointing out : that that's not how things work in practice according to the current : documentation. The current documentation already conjectures this sort of disambiguation at S12:996, I believe. Help me to get that right with a little, more concrete example. my Num $a = 5; # dynamic type is Int my Num $b = 4; say $a/$b; # 1 or 1.25? When we assume that Int is a subtype of Num and leave co- and contravariance issues of container types out of the picture and further assume the availability of dispatch targets :(Int,Int-->Int) and :(Num,Num-->Num) in multi infix: then there is a conflict between the static type information of the container and the dynamic type of the values. And it resolves to the static container type unless it is typed as Any, then the dynamic type is used. Right? I know that the return type of / could be Num in "reality" but that spoils the example. Sorry if the above is a bad example. Regards, TSa. --
Re: class interface of roles
HaloO, Jonathan Lang wrote: Shouldn't the 'divert' be a trait of the method instead of a key/value pair on the class? I thought about doing it that way; but then the class wouldn't know to look for it when composing the role. I figure you see the class in a very active role when composing roles. I see them more as a passive entity that the class composer is dealing with. My scope is on producing a predictable result from the typing point of view. Dispatch comes later. Regards, TSa. --
Re: class interface of roles
HaloO, Jonathan Lang wrote: > TSa wrote: Note that I think the conflict detection of role methods prevents the composition of the equal method through the superclass interface. Just to make sure we're speaking the same language: by "superclass", you're referring to classes brought in via "is"; right? No. I used the term 'superclass interface' as it appears in the article I referred to. There the role has a type constraint interface to the uncomposed class which is available through the super keyword. Let's settle for the terms 'uncomposed class' and 'composed class'. Then I meant the interface of the role to the uncomposed class. It might be the case that you should think of the role composition to happen on a new anonymous class that inherits everything from the uncomposed class and therefore has a proper superclass interface. Conflicts between roles prevent the installation of a composed method and hence leave the task of defining it to the composed class. I admit that the distinction between these cases can come as a surprise to class developers. But composing more than one role is equal in complexity as multiple inheritance. So a warning is a good thing here. The 'is override' trait might be needed to silence the warning. Well, and you can switch it off with a pragma or the trait on the class. The whole point of the article is to calculate the composed class type. This process is akin to inheritance but needs two implicit type parameters to model it in F-bounded polymorphism. Free mixins just go into the composed class unconstraint. Constraint mixins require certain features from the class. This inevitably shifts the balance between roles and classes towards roles which is OK in my eyes. In particular since roles have taken on the meaning of type in Perl 6 and as such make the stronger claims when used where a type is expected. If so, you're correct: the presence of a valid method in any of the roles that a class composes is sufficient to prevent the dispatch process from ever reaching any of the superclasses. I'm more thinking along the lines of closure composition and a flattened view of the class. That is conceptually the class' namespace directly maps slot names to methods. That this mapping is searching the inheritance graph behind the scenes is an implementation detail. In the case of roles the composed method calls the uncomposed one that's all. In your terms this means 'dispatch starts at the role' I guess. On a side track I want to note: the optimizer might munge all combined methods into an optimized version that doesn't walk the class graph. In the GenSquare case this method reads return self.side == $p.side and self.x == $p.x and self.y == $p.y and is installed in the equal slot of the composed class. I'm interpreting roles from a type theoretical background. This is viable because all information needed is available at compile time whereas classes are open. Note that the combination process as I see it nicely explains runtime role composition in the same way as compile time role composition. There is no special rule that at runtime the role takes precedence or forces its definition of methods. Also the difference between successive does and a precomposed role with | falls out naturally. In the latter case conflicts let role methods drop out and leave the class method as "disambiguation". But the compiler can easily issue a warning for that. Regards, TSa. --
Re: class interface of roles
TSa wrote: Jonathan Lang wrote: > Of course, you then run into a problem if the class _doesn't_ redefine > method equal; if it doesn't, then what is GenPointMixin::equal > calling? This is the reason why there is a type bound on the class that should result in a composition error when the equal method is missing. But it isn't missing; it's being inherited from the role. Shouldn't the 'divert' be a trait of the method instead of a key/value pair on the class? I thought about doing it that way; but then the class wouldn't know to look for it when composing the role. And what does your syntax mean? Looks like the key is indicating the method and the value is the namespace where method lookup starts. That was the idea. > And you also run into a problem if you want the class to > track the position in polar coordinates instead of rectilinear ones - > it would still represent a point conceptually, but the implementation > of method equal (at least) would need to be overridden. Oh, yes. Doing the right thing is difficult. Changing representation of the point while keeping the interface can only be done in the class. OTOH, the interface would include the rectilinear accessor methods. And these are called in the equal method. ...unless the equal method is rewritten so that it doesn't call them. That said, you're right that the rectlinear access methods will still be there - but they won't neccessarily work the same way. In particular, I can see .x being rewritten to return $.r * cos($.a) when used to retrieve the value. Internally, the representation would be in polar notation; externally, rectilinear accessors could still be used - though they wouldn't be as efficient as polar accessors. In the case of the equal method the dispatch slot contains the role's closure which calls into the class' closure. There is no dispatch to the role because the role is flattened out in the composition process. Conceptually, yes; you can think of it in that way. In practice, this is implemented by having the class dispatch to the role if none of the class' signatures match the call. Bear in mind, though, that _every_ call follows this route: even a method call that originates in a role's method (such as an attribute accessor) will start the dispatch process with the class, then move to the roles if the class doesn't work, and then move up the class hierarchy if the roles don't work. It is interesting to think of another PolarPoint role that also has an equal method that would conflict with the GenPoint one. Then the class has to disambiguate. Which in turn requires the class to provide an equal method that overrides both role versions. Agreed. Note that I think the conflict detection of role methods prevents the composition of the equal method through the superclass interface. Just to make sure we're speaking the same language: by "superclass", you're referring to classes brought in via "is"; right? If so, you're correct: the presence of a valid method in any of the roles that a class composes is sufficient to prevent the dispatch process from ever reaching any of the superclasses. I admit that this warps the meaning of the class' equal method from being an aspect in the role's method to the definer of the method. This can be a source of subtle bugs. That is the class composer can't distinguish an aspect method from a disambiguation one unless we introduce e.g. an 'is disambig' trait. And e.g. an 'is override' trait when the class designer wishes to replace a role method even if there's no conflict. ...and you would then have to apply the 'override' trait to every class method that is used instead of the role method. Note that as written, this is the default approach, and you only have to do something exotic in the (comparatively) rare situation where you want the class to complete the role's method instead of replacing it. > What inspired that comment? Sorry, I didn't want to intimidate you. I wasn't intimidated; just curious. -- Jonathan "Dataweaver" Lang
Re: [perl #40543] [NEW] Test for space after curly braces
Well, the verdict defnitely seems to be that trailing space and tab
characters are annoyances that should go away :-) This patch adds a
new test (in place of the curly-space test I posted earlier) which
searches for superfluous trailing spaces in source files.
Comments definitely welcome!
Regards,
Paul
files affected:
MANIFEST
t/codingstd/trailing_space.t
Index: MANIFEST
===
--- MANIFEST (revision 14936)
+++ MANIFEST (working copy)
@@ -2449,6 +2449,7 @@
t/codingstd/linelength.t[]
t/codingstd/perlcritic.t[]
t/codingstd/tabs.t []
+t/codingstd/trailing_space.t[]
t/compilers/imcc/imcpasm/cfg.t []
t/compilers/imcc/imcpasm/opt0.t []
t/compilers/imcc/imcpasm/opt1.t []
Index: t/codingstd/trailing_space.t
===
--- t/codingstd/trailing_space.t (revision 0)
+++ t/codingstd/trailing_space.t (revision 0)
@@ -0,0 +1,100 @@
+#! perl
+# Copyright (C) 2006, The Perl Foundation.
+# $Id$
+
+use strict;
+use warnings;
+
+use lib qw( . lib ../lib ../../lib );
+use Parrot::Distribution;
+use Test::More;
+
+=head1 NAME
+
+t/codingstd/trailing_space.t - checks for superfluous trailing space or tab characters
+
+=head1 SYNOPSIS
+
+# test all files
+% prove t/codingstd/trailing_space.t
+
+# test specific files
+% perl t/codingstd/trailing_space.t src/foo.c include/parrot/bar.h
+
+=head1 DESCRIPTION
+
+Checks that files don't have trailing space or tab characters between the
+last nominal character on the line and the end of line character.
+
+=head1 SEE ALSO
+
+L
+
+=cut
+
+my $DIST = Parrot::Distribution->new;
+
+my @files = @ARGV ? @ARGV : source_files();
+
+if ( scalar @files ) {
+plan tests => scalar @files;
+}
+else {
+exit;
+}
+
+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>;
+}
+
+# check the file
+ok( ($buf !~ m{.?[ \t]+$}m), 'No trailing spaces or tabs' )
+or diag( "Trailing space or tab char found in " . $path );
+}
+
+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 ),
+
+map( $_->files_of_type('Yacc file'),
+$DIST->yacc_source_file_directories ),
+
+map( $_->files_of_type('Lex file'),
+$DIST->lex_source_file_directories ),
+);
+}
+
+# Local Variables:
+# mode: cperl
+# cperl-indent-level: 4
+# fill-column: 100
+# End:
+# vim: expandtab shiftwidth=4:
Re: class interface of roles
HaloO Jonathan, you wrote: > Of course, you then run into a problem if the class _doesn't_ redefine > method equal; if it doesn't, then what is GenPointMixin::equal > calling? This is the reason why there is a type bound on the class that should result in a composition error when the equal method is missing. Shouldn't the 'divert' be a trait of the method instead of a key/value pair on the class? And what does your syntax mean? Looks like the key is indicating the method and the value is the namespace where method lookup starts. > And you also run into a problem if you want the class to > track the position in polar coordinates instead of rectilinear ones - > it would still represent a point conceptually, but the implementation > of method equal (at least) would need to be overridden. Oh, yes. Doing the right thing is difficult. Changing representation of the point while keeping the interface can only be done in the class. OTOH, the interface would include the rectilinear accessor methods. And these are called in the equal method. Thus a class doing the GenPoint role correctly needs to provide .x and .y methods even if they aren't simple auto-generated accessors of attributes. But note that these two are not going through the superclass interface but the self type. In the case of the equal method the dispatch slot contains the role's closure which calls into the class' closure. There is no dispatch to the role because the role is flattened out in the composition process. It is interesting to think of another PolarPoint role that also has an equal method that would conflict with the GenPoint one. Then the class has to disambiguate. Which in turn requires the class to provide an equal method that overrides both role versions. Note that I think the conflict detection of role methods prevents the composition of the equal method through the superclass interface. I admit that this warps the meaning of the class' equal method from beeing an aspect in the role's method to the definer of the method. This can be a source of subtle bugs. That is the class composer can't distinguish an aspect method from a disambiguation one unless we introduce e.g. an 'is disambig' trait. And e.g. an 'is override' trait when the class designer wishes to replace a role method even if there's no conflict. > A cleaner solution would be to define a private helper method which > the role then demands that the class override. This is _very_ similar > to the solution that you described as "clumsy" a few posts back, with > the main difference being that the helper method, being private, can't > be called outside of the class. To me, the only clumsiness of this > solution comes directly from the cluminess of the overall example, and > I consider your proposed alternative to be equally clumsy - it merely > trades one set of problems for another. There's a lot of truth in that. But I don't consider the example as clumsy. It is an important issue that arises whenever method recombination is needed to deal with the guarantees that the role as a type makes. Calculation of a type bound on the class that has to be met in the composition is a strong tool. >> And yes, in Perl 6 the method isn't called equal but eqv or === and >> has a default implementation that retrieves the .WHICH of both args. > > What inspired that comment? Sorry, I didn't want to intimidate you. But I wanted to prevent comments that choosing a method equal is not the right approach and MMD should be used instead. But I think all of what we discussed so far stays valid if the equal method is a multi. IIRC there is just one namespace slot for the short name. And we are discussing how this slot is filled in the class composition process. BTW, why have you gone off-list? Regards, TSa. --
class interface of roles
TSa wrote:
Jonathan Lang wrote:
> TSa wrote:
>> This is exactly what I don't want. Such an equal method needs to be
>> written in each and every class the role GenPoint is composed into.
>
> No, it doesn't. It only needs to be written in those classes where
> the 'equal' method is supposed to behave differently than the one
> found in GenPoint.
Grumpf, yes. But I think that equality checking is something that needs
to deal with some class specific data. And hence the care-taking for
the role needs to be implemented many times while it could come out of
the composition process almost for free. I assume the class specific
part needs writing anyway.
OK; I think I see where you're coming from.
I don't think that the behaviour that you're describing should be Perl
6's default behavior; but I _could_ see implementing a sort of
"reverse delegation" trait that causes a role's class to start the
dispatch process for a given method with the role instead of the
class. Something like:
role GenPointMixin
{
is divert(:equal);
has Int $.x;
has Int $.y;
method equal( ::?CLASS GenEqual $self: ::?CLASS $p --> Bool )
{
return $self.::?CLASS::equal($p) and $self.x == $p.x and
$self.y == $p.y;
}
}
Of course, you then run into a problem if the class _doesn't_ redefine
method equal; if it doesn't, then what is GenPointMixin::equal
calling? And you also run into a problem if you want the class to
track the position in polar coordinates instead of rectilinear ones -
it would still represent a point conceptually, but the implementation
of method equal (at least) would need to be overridden.
Or you could change the dispatch rules throughout the lexical scope
where the classes are defined with a 'use' statement; all's fair if
you predeclare, after all. But you'd still have the above issues.
A cleaner solution would be to define a private helper method which
the role then demands that the class override. This is _very_ similar
to the solution that you described as "clumsy" a few posts back, with
the main difference being that the helper method, being private, can't
be called outside of the class. To me, the only clumsiness of this
solution comes directly from the cluminess of the overall example, and
I consider your proposed alternative to be equally clumsy - it merely
trades one set of problems for another.
And yes, in Perl 6 the method isn't called equal but eqv or === and
has a default implementation that retrieves the .WHICH of both args.
What inspired that comment?
--
Jonathan "Dataweaver" Lang
[ANNOUNCE] Pugs 6.2.13 released!
After nearly four months of development and 3400+ commits, I'm very glad
to announce that Pugs 6.2.13 is now available:
http://pugs.blogs.com/dist/Perl6-Pugs-6.2.13.tar.gz
SIZE: 6839270
SHA1: b06b8434c64e9bb5e3ab482282fbae0a6ba69218
Motivated by increasing use of Pugs in production, this is an extra
release
in the 6.2.x series, offering another 200%+ improvement in performance,
comprehensive support for interoperability with Perl 5 modules, a
built-in
grammar engine via native perl5 embedding, and much better support for
roles, classes and objects.
The web-based presence of Pugs and Perl 6 has improved as well:
* http://run.pugscode.org/ puts the Pugs shell in your browser.
* http://spec.pugscode.org/ annotates the Synopses with "smart-
linked" tests.
* http://smoke.pugscode.org/ annotates that further with fail/
pass/todo records.
* http://rakudo.org/perl6/ is a Wiki dedicated to collect Perl 6
related information.
* http://www.programmersheaven.com/2/Perl6-FAQ offers a
comprehensive FAQ on Perl 6.
Thanks again to all lambdacamels on #perl6 for building this new ship
together;
it is truly an exhilarating voyage. :-)
Have -Ofun!
Audrey
(The change log below is also available in HTML format:
http://pugs.blogs.com/pugs/2006/10/pugs_6213_relea.html#more
)
= Changes for 6.2.13 (r14401) - October 17, 2006
== Build System
* Perl 5 embedding is now enabled by default
** For Windows users, Perl 5.8.x is required
** Set the `PUGS_EMBED` environment variable to `noperl5` to disable
this
* Prompting for Parrot embedding is now disabled by default
** Set the `PUGS_EMBED` environment variable to `parrot` to enable this
* Support for compiling using GHC 6.6
** GHC 6.4.1+ is still supported, but 6.6 will be required in the
next release
== Feature Changes
=== Interactive Shell and Command-Line Flags
* New `pugs -d` flag to display a trace for debugging
* The `:r` command now resets the environment once, not twice
* The return value of blocks, such as `gather {...}`, is displayed
correctly
* `$_` is no longer clobbered with the result of each expression's
evaluation
=== Perl 5 Interoperability
* Arrays and Hashes now round-trip from Pugs to Perl 5 land and back
* Importing functions from Perl 5: `use perl5:CGI `
* Passing unboxed values across runtimes no longer leaks memory
* When embedding Perl 5.8+, Unicode flag is now on for Pugs-to-Perl5
strings
* `eval($str, :lang)` now accepts non-ASCII characters in `$str`
=== Lexical Syntax
* Capture literals: `\($bar: 1, 2, 3, named => 4)`
* Here-docs now work as specced; also warns against inconsistent
indentation
* Interpolation of chained calls: `"$foo.meth.meth.meth.meth()"`
* List comprehension: `for 0 < list(@x) < 10 {...}`
* Named character escapes: `"\c[LATIN CAPITAL LETTER Y]"`
* New grammatical category `term:`, separated from the `prefix:`
category
* New magical variables: `$?COMPILER` and `$?VERSION`
* Parse for `LABEL: STMT`, although it's currently treated the same
as `STMT`
* Pod directives: `=begin`/`=end` and `=for` now terminate without
`=cut`
* Pod variables: `$=FOO` and [EMAIL PROTECTED] give you access to the Pod
section FOO
* Quote adverbs no longer take non-parens brackets: `rx:P5{...}` is
valid again
* Shell-like quoting rules implemented for `<< $x "qq" 'q' >>`
* Signature literals: `:($foo is copy = 42, $, @)`
* Support for UTF-8, UTF-16 and UTF-32 encoded source files
* Support for backquotes and `qx/.../` for capturing external command
output
* User-defined infix associativity: `sub infix: is assoc
('right') {...}`
* `"\123"` and `"\03"` are now errors; write `"\d123"` and `"\o03"`
instead
* `$::x` now means exactly the same a `$x`, instead of `$*x`
* `%h<>` now means `%h{}` -- the entire hash, not the empty string as
key
* `($::('x'))` with two adjacent closing parens now parses correctly
* `0_123_456` now parses as `0d123456`, not an error
* `1<2>` is now a fatal error: Odd number of elements in Hash
* `q()` and `qw()` with parentheses are parsed as functions, not quotes
=== Declarators and Operators
* Argument interpolation via prefix `|` and `|<<`
* Binding to qualified uninitialised symbols: `&fully::qualify := sub
{...}`
* Contextual variables are now declared with `my $x is context`, not
`env $x`
* Hyperised reduce operators: `[>>+<<]` and `[\>>+<<]`
* Implicit invocation assignment: `.= uc` is parsed as `$_ = $_.uc`
* Mid-block redeclaration no longer allowed: `my $x; { $x = 1; my $x
= 2 }`
* Negated comparison operators: `!eqv`, `!=:=` etc; `!~~` replaces `!~`
* New infix comparison operators: `===` and `eqv`
* New infix non-short-circuiting boolean AND operator: `?&`
* Nullary reduction of builtin operators gives identity values: `[*]
() === 1`
* Postfix operators can be called with a dot: `.++`, `$x.++`, `$x.\ ++`
* Prefix `=` now iterates on arrays as well: [EMAIL PROTECTED]
* Short-circuiting chained comparison: `1 > 2
Re: Parrot::Coroutine
At 13:48 14/10/2006 -0400, Bob Rogers wrote: So while we could redesign Coroutine.pmc now, I don't think we are ready to reimplement it. In the mean time, having an alternative implementation allows those who want a full implementation (hi, Fran,Ag(Bois!) to get on with it. I've removed the LuaThread PMC (in r14936). Now, Lua doesn't depend of the deprecated Coroutine PMC. François.
