[perl #41557] [BUG] addparent established heirarchies don't work with .Super
# New Ticket Created by Sam Vilain # Please include the string: [perl #41557] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41557 > Hi there, There seem to be some bugs with inheritance, possibly in the .Super PMC. When you call $P0 = new .Super, self If "self" was; - a .Super made by a superclass call in the previous sub-class - a superclass that was setup using "addparent" rather than subclass Then you get a "object has no parent" exception The tests added in r17031 demonstrate the issue (in t/pmc/object-meths.t). Sam.
[svn:parrot-pdd] r17085 - in trunk/docs: . art dev pdds pdds/draft req stm
Author: paultcochrane Date: Tue Feb 20 12:04:14 2007 New Revision: 17085 Modified: trunk/docs/pdds/README (props changed) trunk/docs/pdds/draft/pdd19_pir.pod (props changed) trunk/docs/pdds/draft/pdd24_events.pod (props changed) trunk/docs/pdds/draft/pdd25_concurrency.pod (props changed) trunk/docs/pdds/draft/pddXX_cstruct.pod (props changed) trunk/docs/pdds/draft/pddXX_pmc.pod (props changed) trunk/docs/pdds/pdd22_io.pod (props changed) trunk/docs/pdds/pdd23_exceptions.pod (props changed) Changes in other areas also in this revision: Modified: trunk/docs/BROKEN.pod (props changed) trunk/docs/art/pp001-intro.pod (props changed) trunk/docs/art/pp002-pmc.pod (props changed) trunk/docs/art/pp003-oop.pod (props changed) trunk/docs/dev/fhs.pod (props changed) trunk/docs/dev/optimizer.pod (props changed) trunk/docs/dev/pmc_object_design_meeting_notes.pod (props changed) trunk/docs/dev/wranglers.pod (props changed) trunk/docs/extend.pod (props changed) trunk/docs/optable.pod (props changed) trunk/docs/parrothist.pod (props changed) trunk/docs/pcc_state.pod (props changed) trunk/docs/req/model_users.pod (props changed) trunk/docs/roles_responsibilities.pod (props changed) trunk/docs/stability.pod (props changed) trunk/docs/stm/atomic.pod (props changed) trunk/docs/stm/howto.pod (props changed) trunk/docs/stm/internals.pod (props changed) trunk/docs/stm/stm_frontend.pod (props changed) trunk/docs/stm/thread-issues.pod (props changed) Log: Set svn:eol-style property to 'native' (part 2)
[perl #41558] [PATCH] Add ops summary doc generator
# New Ticket Created by Sartak
# Please include the string: [perl #41558]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41558 >
This patch adds a new utility script to generate a summary for all the
ops. It's fairly minimal. It combines docs/ops/*.pod (using
Pod::Parser) to generate another pod file (on stdout, but should be
directed to docs/ops/index.pod) similar to perldoc perlfunc. Right now
it doesn't run automatically during a make; I wasn't sure where to put
it in the Makefile.
Also, I did not add the new file to MANIFEST, nor did I add
docs/ops/index.pod to MANIFEST.SKIP. It was suggested that I let the
committer handle this.
Files affected:
(new) tools/build/ops_summary.pl
(edit) CREDITS
Shawn M Moore
Index: CREDITS
===
--- CREDITS (revision 17104)
+++ CREDITS (working copy)
@@ -485,6 +485,9 @@
N: Sebastian Riedel
+N: Shawn M Moore
+D: ops summary script
+
N: Simon Cozens
D: Release pumpking for 0.0.1-0.0.4
Index: tools/build/ops_summary.pl
===
--- tools/build/ops_summary.pl (revision 0)
+++ tools/build/ops_summary.pl (revision 0)
@@ -0,0 +1,122 @@
+#! perl
+# Copyright (C) 2001-2006, The Perl Foundation.
+# $Id: ops_summary.pl 17061 2007-02-19 19:30:30Z jkeenan $
+use warnings;
+use strict;
+
+package OpsSummary;
+use base 'Pod::Parser';
+
+my $current_file;
+my $current_op;
+
+my %blurb_for_file;
+my %blurbs_for_op;
+my %ops_in_file;
+
+sub command
+{
+ my ($parser, $command, $paragraph, $line_num) = @_;
+ 1 while chomp $paragraph;
+
+ undef $current_op;
+
+ # looks like a new opcode, let's try to add it
+ if ($command eq 'item')
+ {
+my ($opname) = $paragraph =~ /^B<([^>]+)>/;
+return unless defined $opname;
+push @{$blurbs_for_op{$opname}}, "=item $paragraph\n\n";
+$ops_in_file{$current_file}{$opname} = 1;
+$current_op = $opname;
+ }
+}
+
+sub verbatim
+{
+ my ($parser, $paragraph, $line_num) = @_;
+ 1 while chomp $paragraph;
+
+ if (defined $current_op)
+ {
+$blurbs_for_op{$current_op}[-1] .= "$paragraph\n";
+ }
+}
+
+sub interior_sequence
+{
+ my ($parser, $seq_command, $seq_argument) = @_;
+}
+
+sub textblock
+{
+ my ($parser, $paragraph, $line_num) = @_;
+ 1 while chomp $paragraph;
+
+ # get the short blurb for our file
+ if (not exists $blurb_for_file{$current_file})
+ {
+$blurb_for_file{$current_file} = "$paragraph\n";
+ }
+ if (defined $current_op)
+ {
+$blurbs_for_op{$current_op}[-1] .= "$paragraph\n";
+ }
+}
+
+die "OpsSummary is not meant to be used as a module" if caller;
+
[EMAIL PROTECTED] = grep {$_ !~ /index\.pod$/}
+ unless @ARGV;
+
+my $parser = new OpsSummary;
+
+for (@ARGV)
+{
+ next if $_ eq 'index.pod';
+ $current_file = $_;
+ $parser->parse_from_file($_);
+}
+
+print << "EOH";
+=head1 NAME
+
+Parrot opcodes summary
+
+=head2 Parrot Opcodes by Category
+
+=over 4
+
+EOH
+
+foreach my $file (sort keys %ops_in_file)
+{
+ print "=item $blurb_for_file{$file}\n";
+ print join ', ', map {"C<$_>"} sort keys %{$ops_in_file{$file}};
+ print "\n\n";
+}
+
+print << "EOH2";
+=back
+
+=head2 Alphabetical Listing of Parrot Opcodes
+
+=over 8
+
+EOH2
+
+foreach my $op (sort keys %blurbs_for_op)
+{
+ my $op_has_description = grep {/^.+\n+./} @{$blurbs_for_op{$op}};
+ $blurbs_for_op{$op}[-1] .= "-\n" unless $op_has_description;
+
+ foreach my $syntax (@{$blurbs_for_op{$op}})
+ {
+print "$syntax\n";
+ }
+}
+
+print << "EOH3";
+=back
+
+EOH3
Re: Cross-compiling Parrot
jerry gay ha scritto: On 2/20/07, Aldo Calpini <[EMAIL PROTECTED]> wrote: 1) does anybody have objections to patching the current build system for cross-compilation (even "yes, but not now because..." objections)? no objection here! this is a long-desired feature, and is currently unavailable. although i don't have a pocketpc to test on, i'll do my best to help. for years, the dependence on perl 5's configure probes has bothered me--just not enough to fix it. i'm glad to see this porting effort will renew that effort. that's all very good. 2) does anybody already have a .plan or something in mind about it (so that I may either learn from what others have thought, or avoiding reinventing some wheel)? [...] since this style hasn't been practiced as a rule in the past, it'll take some time to get used to--for all of us. but i believe it's the safest way to proceed to modify the critical-yet-undertested subsystem that is configure. are you willing to work in the way i described? how does the project team feel about this approach? I have no problems with this approach. modulo the fact that I'm an absolute beginner in the fine art of version control (some CVS, a little bit of SVN, but just basic checkout-checkin), so I have no idea how to go about branching and merging and all that stuff. but I'll find the time to RTFM on my own :-) speaking briefly about a technical plan--there have been discussions of a way forward in the past. the general consensus is that miniparrot be designed to be ANSI C-only, with as few platform-specific extensions as possible, and zero dependence on perl's configure. after miniparrot is built, it can be used to perform the remainder of the build tasks in a portable manner. this gives us a lot of code reuse, and should make future porting efforts easier. however, there's a lot of this design left to flesh out, and none of it is implemented. i think this is the right design, but we need to find one or more ways to get there, and work towards that. however that discussion merits one or more separate message threads. yuck. shortly after I sent my message I stumbled upon http://rt.perl.org/rt3/Public/Bug/Display.html?id=31136. and my first thought was "oh, no". having the build system done by a miniparrot isn't going to be convenient for cross-compiling. right now, I successfully built parrot tweaking the source here and there, but as I said in another message, the next steps in the Makefile (building the core Parrot library and finally installing the product) are going to be a huge pain. cross-compiling a simple, standalone, test executable to check for features, headers etc and running it on the target platform is, well, easy enough. on the other hand, running something (the miniparrot) which probably expects to have the whole build directory at hand, this isn't easy. copying files to and from the target device and generally exchanging data is slow, unsafe, and ultimately just a hack. add to this that we're talking about PDAs, which are usually much slower and severely resource-constrained (both in RAM and storage) than a regular desktop. for PocketPC's sake, using a miniparrot to do most of the build is a malus, not a bonus. but this wouldn't affect, for example, the Nokia N800 port, which uses scratchbox as an environment. this, however, comes at a cost: you can build for the N800 _only_ on a *nix host platform. probably developing something like scratchbox for CeGCC would be the Right Thing To Do. but that's a completely different story (and a completely different effort, alas). all in all, this is something that will need to be considered very carefully. and I guess I've ranted enough about it now :-) cheers, Aldo
Re: Y not
On Feb 20, 2007, at 3:42 PM, Larry Wall wrote: I think the ¥ and Y operators are going to have to change to something else. The current Y has at least four strikes against it: * It's an ASCII version of a cute Unicode picture, but other than that, the picture it doesn't remind you of "zip" at all, especially in the Y form. I bet calling it "ykk" would be Wrong. Pity. -jesse PGP.sig Description: This is a digitally signed message part
Re: Y not
Damian Conway schrieb: > If the very much more readable 'zip' and 'minmax' are > to be replaced with 'ZZ' and 'MM', then I think that's a serious step > backwards in usability. Fully agree here and I think that there are still even more places, where the usability could be improved: Say more words/letters, less symbols/special characters. Especially special characters (shift + num: [EMAIL PROTECTED]&*...) are harder to type (I think I can type a 5-char word a lot faster than shift-5 = % - additionally the shift-wrench disturbs the typing flow) and above all harder to read/intuitively understand/learn/remeber than plaintext keywords. Of course there will always be a trade-off and special characters are the most usable choice in many cases. But I also think that in many other cases "words" will be more usable. As the usability of a tool greatly influences it's acceptance and usage, this is a point, where we really should think about. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Cross-compiling Parrot
Joshua Isom ha scritto: Using perl 5's configure probes also somewhat limits us to how the vendor distributed perl. It should also be considered that we can't rely on perl5 being available, especially since we intend to replace it eventually, so rewriting all the perl to support cross compiling would likely not be the best thing. I don't second that. I agree that relaying on Perl5's configure is not the way to go, but I don't see any problem in using Perl5 as _the tool_ to build. while it's true that Parrot aims at replacing it, Perl5 is going to be there for years to come. and what alternatives are there? Perl5's own configuration/build system is based on bash and make, and they are far more less available than Perl5 itself. IMO, using Perl to configure is a much more powerful, maintainable, work-everywhere solution than some autoconf-based stuff. If we create a new configure system, we can essentially have two configuration methods in the trunk, and have tests for the new one to be sure it's working and portable before trying to get everyone to start using it. well, I didn't intend to build a whole new configure system from scratch. I'm afraid this would be far more expensive than the current amount of Free Time I have to spend on the project. I've noticed a lot that mentions miniparrot being used for building parrot, but at the same time, we don't have anything to work with to know just how limited miniparrot should be. Perhaps a step to work for before rebuilding the configure subsystem(which theoretically should be in pir to get rid of perl5 dependence), is to get an actual miniparrot working? Currently miniparrot just seems to be a macroparrot with a miniconfig. If we can't realistically get a miniparrot, maybe it should be considered if building a miniparrot for configuration is a good idea. Instead of rewriting everything now in perl5 to support cross compiling, maybe we should dive in and try to see if we can get it rewritten in pir. After all, we're getting more pir programmers than perl5 programmers it seems. woot! I am _not_ going to become a pir programmer, sorry :-) seriously, I'm not really sure that targeting "pir programmers" is a desiderable thing. I mean, in the long term, how many people are going to really learn pir and use it as a programming language? Parrot maintainers, sure, and HLL compiler authors, but how many of them there will be, as opposed to Perl(5..6) programmers? cheers, Aldo
Re: Y not
On 2/21/07, Thomas Wittek <[EMAIL PROTECTED]> wrote: Damian Conway schrieb: > If the very much more readable 'zip' and 'minmax' are > to be replaced with 'ZZ' and 'MM', then I think that's a serious step > backwards in usability. Fully agree here and I think that there are still even more places, where the usability could be improved: Say more words/letters, less symbols/special characters. Especially special characters (shift + num: [EMAIL PROTECTED]&*...) are harder to type (I think I can type a 5-char word a lot faster than shift-5 = % - additionally the shift-wrench disturbs the typing flow) and above all harder to read/intuitively understand/learn/remeber than plaintext keywords. Well, (IMO, of couse, but I can defend it!) typability is not nearly as important as readability. And not Java readability, where you can right-click on anything and read the documentation, but readability where, after sufficient orientation, you can look at most and not need any documentation; i.e. it is completely obvious what it is doing. Many times this can not be done simply by naming appropriately, although I admit Perl often takes this too far. Of course there will always be a trade-off and special characters are the most usable choice in many cases. But I also think that in many other cases "words" will be more usable. % as the "mod" operator is a good example of what you describe. There's no need for mod to be a symbolic operator: when you read 5 % 3 you say "5 mod 3". Why would we not write "5 mod 3": it is just as obvious what and how we are doing this operation. And % is uncommon enough that no huffman coding principals may apply. The only thing we have here is cultural baggage. As a good example of what I am referring to is hyper operators. Naming hyper operators would ultimately be detremental to readability among experienced programmers. Consider the difference between: my @data = @reading >>+<< @bias; # old hyper syntax; I don't know the new form yet my @data = hyper &infix:<+>, @reading, @bias; In which one of these is it more obvious what is going on? Now, if you're a beginner, neither may be totally obvious, but the first makes you think of addition, and the second makes you think of function references. As the usability of a tool greatly influences it's acceptance and usage, this is a point, where we really should think about. I completely agree. I am for operator-centric languages. As a mathematician and a human, I think an operator-centric language maps very closely to my brain, as opposed to a name-centric language (for some reason, I'm not sure why, but as an experienced perl and ruby programmer, perl just "flows" better). But I do think that Perl 6 is gathering some operator bloat, in that we are defining symbols for things that are not adding to the "obviousness" of the code. They may not be taking away, but all else being equal, we should choose the option of lower abstraction (as far as what level the user needs to be in order to understand what is *really* going on, for some definiton of "really"). Luke
Re: Y not
Thomas Wittek wrote: Damian Conway schrieb: If the very much more readable 'zip' and 'minmax' are to be replaced with 'ZZ' and 'MM', then I think that's a serious step backwards in usability. Fully agree here and I think that there are still even more places, where the usability could be improved: Say more words/letters, less symbols/special characters. Especially special characters (shift + num: [EMAIL PROTECTED]&*...) are harder to type (I think I can type a 5-char word a lot faster than shift-5 = % - additionally the shift-wrench disturbs the typing flow) and above all harder to read/intuitively understand/learn/remeber than plaintext keywords. Of course there will always be a trade-off and special characters are the most usable choice in many cases. But I also think that in many other cases "words" will be more usable. As the usability of a tool greatly influences it's acceptance and usage, this is a point, where we really should think about. It's madness, MADNESS I tell you! Beware: this way leads to PERLBOL! :-) -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Y not
Luke Palmer wrote: % as the "mod" operator is a good example of what you describe. There's no need for mod to be a symbolic operator: when you read 5 % 3 you say "5 mod 3". Why would we not write "5 mod 3": it is just as obvious what and how we are doing this operation. And % is uncommon enough that no huffman coding principals may apply. The only thing we have here is cultural baggage. I can think of one case where % would be preferable to 'mod': when you want to ask for a 'remainder' in the form of a non-integer. That is, '4.5 % 3' returns 1.5 (and parallels '/'), while '4.5 mod 3' returns 1 (and parallels 'div'). That said, if it's decided that the latter definition is inappropriate or unnecessary, then I'd be all in favor of completely dropping '%' in favor of 'mod' for the former definition. But I do think that Perl 6 is gathering some operator bloat, in that we are defining symbols for things that are not adding to the "obviousness" of the code. They may not be taking away, but all else being equal, we should choose the option of lower abstraction Hear, hear. Huffman coding is all well and good; but not when taken to the point that it starts interfering with legibility. That said, six-character words are the longest that I'd want to see, and I'd much prefer three- or four-character words if reasonable. Mind you, there are some cases where I'd like to see the symbol-based operators supplemented by name-based ones instead of being replaced by them. For instance, I could live with a few more word-based contextualizers: 'scalar' (same as '$:'), 'hash' (same as '%:'), and 'nested' (same as '@@:'); but I wouldn't want to remove '$:', '%:', or '@@:'. The only reason I don't also suggest 'sub' to supplement '&:' is the confusion that could arise between contextualization and declaration. -- Jonathan "Dataweaver" Lang
[svn:perl6-synopsis] r13699 - doc/trunk/design/syn
Author: larry
Date: Wed Feb 21 09:25:37 2007
New Revision: 13699
Modified:
doc/trunk/design/syn/S03.pod
Log:
¥ is replaced by Z. XX becomes simply X and old X must now be spelled X~X.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podWed Feb 21 09:25:37 2007
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 8 Mar 2004
- Last Modified: 8 Feb 2007
+ Last Modified: 21 Feb 2007
Number: 3
- Version: 100
+ Version: 101
=head1 Overview
@@ -46,7 +46,7 @@
Item assignment = := ::= => += -= **= xx= .=
Loose unary true not
Comma operator ,
-List infix ¥ minmax X XX X~X X*X XeqvX
+List infix Z minmax X X~X X*X XeqvX
List prefix = : print push say die map substr ... [+] [*] any all
Loose and and
Loose oror xor err
@@ -1069,13 +1069,13 @@
=item *
-infix:<¥>, the zip operator
+infix:, the zip operator
-1,2 ¥ 3,4 # (1,3),(2,4)
+1,2 Z 3,4 # (1,3),(2,4)
=item *
-The minmax operator
+infix:, the minmax operator
$min0, $max0 minmax $min1, $max1# ($min0 min $min1, $max0 max $max1)
@@ -1094,30 +1094,19 @@
=item *
-List and string cross operators
+infix:, the cross operator
-1,2 XX 3,4 # (1,3), (1,4), (2,3), (2,4)
-1,2 X 3,4 # '13', '14', '23', '24'
+1,2 X 3,4 # (1,3), (1,4), (2,3), (2,4)
-In contrast to the zip operator, the C operator returns all the
+In contrast to the zip operator, the C operator returns all the
permutations of its sublists. Hence you may say:
- XX <1 2>
+ X <1 2>
and you end up with
('a', '1'), ('a', '2'), ('b', '1'), ('b', '2')
-The C variant crosses the arrays but concatenates strings:
-
- X <1 2>
-
-produces
-
-'a1', 'a2', 'b1', 'b2'
-
-The resemblance to C and C is not entirely accidental.
-
=item *
Cross hyperoperators
@@ -1234,14 +1223,14 @@
precedence on the right sufficiently to govern list infix
operators:
- $: 1,2 ¥ 3,4 # [[1,3],[2,4]]
- @: 1,2 ¥ 3,4 # 1,3,2,4
-@@: 1,2 ¥ 3,4 # [1,3],[2,4]
- %: 1,2 ¥ 3,4 # { 1 => 3, 2 => 4 }
-
- $: 1,2 XX 3,4 # [[1,3],[1,4],[2,3],[2,4]]
- @: 1,2 XX 3,4 # 1,3,1,4,2,3,2,4
-@@: 1,2 XX 3,4 # [1,3],[1,4],[2,3],[2,4]
+ $: 1,2 Z 3,4 # [[1,3],[2,4]]
+ @: 1,2 Z 3,4 # 1,3,2,4
+@@: 1,2 Z 3,4 # [1,3],[2,4]
+ %: 1,2 Z 3,4 # { 1 => 3, 2 => 4 }
+
+ $: 1,2 X 3,4 # [[1,3],[1,4],[2,3],[2,4]]
+ @: 1,2 X 3,4 # 1,3,1,4,2,3,2,4
+@@: 1,2 X 3,4 # [1,3],[1,4],[2,3],[2,4]
These can also influence the result of functions that returns lists of
captures:
@@ -2892,7 +2881,7 @@
[//]() # undef
[=]() # undef(same for all assignment operators)
[,]() # []
-[¥]() # []
+[Z]() # []
User-defined operators may define their own identity values, but
there is no explicit identity property. The value is implicit in the
@@ -2998,17 +2987,17 @@
produces
-['a', 1, 'x'],
-['a', 1, 'y'],
-['a', 2, 'x'],
-['a', 2, 'y'],
-['b', 1, 'x'],
-['b', 1, 'y'],
-['b', 2, 'x'],
-['b', 2, 'y']
+('a', 1, 'x'),
+('a', 1, 'y'),
+('a', 2, 'x'),
+('a', 2, 'y'),
+('b', 1, 'x'),
+('b', 1, 'y'),
+('b', 2, 'x'),
+('b', 2, 'y')
-The string and list forms are common enough to have shortcuts, C
-and C respectively. See below.
+The list form is common enough to have a shortcut, C.
+See below.
For the general form, any existing, non-mutating infix operator
may be used.
@@ -3280,8 +3269,7 @@
print "Name: $name; Zip code: $zip\n";
}
-C has an infix synonym, the Unicode operator C<¥>, and its ASCII
-equivalent C.
+C has an infix synonym, the C operator.
To read arrays in parallel like C but just sequence the values
rather than generating tuples, use C instead of C.
Re: Y not
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> On 21/02/07, Damian Conway <[EMAIL PROTECTED]> wrote: >> [Off-list] DC> Apparently not. DC> Just pretend I'm not here. DC> ;-) we can't pretend as we can sense your mad scientist brain across the big waters. there ain't enough aluminum foil to protect us all! :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Relief for rw/ro
Recently $larry asked for ideas for better naming
the several states of write access.
There are some tentative thoughts, I like to offer.
Larry Wall wrote:
> That being said, in writing the Perl 6 grammar I keep running into the
> need for rw context variables. I'm getting tired of writing things
> like:
>
> my @heredoc_stubs is context is rw = ()
>
> so maybe there's some general syntactic relief for rw/ro that is
> orthogonal to everything else. But that means it wouldn't be a
> trait, a type, a sigil, or a twigil, if it's really orthogonal.
> I don't just want to go with bare rw and ro markers because I think
> they're too easy to confuse. It's more like we want an initializer
> that says "lock this after I change it". If used on the initializer
> of a declaration it would have the force of a readonly declaration.
> Some variant on or near the =, in other words, that could also be
> a variant on normal assignment. But maybe it also has to
> stand alone to declare it as a "write once" variable, I expect.
> Currently "is readonly" only works on the declaration, and only on
> items that are initialized by the declaration. Maybe that's good
> enough for most purposes.
My approach is:
In terms of writeability a variable/reference can be
(1) a variable, (2) a constant or (3) a "final"
(Don't wonder if you never heard of that "final", just my proposal)
That means it can be writeable (1),
not writeable since compile time (2) or
not writeable since that moment in runtime when it gets "final" (3).
This approach could work with an optional second declarator.
In the usual case the second declarator, that would be 'variable',
is simply omitted and nobody feels a difference.
- snip
my $number = 3; # OK, of course
my variable $number = 3; # The same, not really useful, -> warning?
# context variables default to readonly,
# so the 'variable' declaration has an effect
my variable @heredoc_stubs is context = (); # Writeable context!
# Compile time constant with local scope:
my constant $pi = 3.14;
# Package scoped constants can be useful!
say $Math::euler; # Prints constant value from package Math
# This data from database has to be 'readonly':
my final $temperature = db_temperature_of( $date_time_loc);
# But this is possible as well:
my $temperature = db_temperature_of( $date_time_loc);
if is_fine($temperature) {
final $temperature;
}
else {
$temperature = db_default_temperature();
final $temperature;
}
- /snip
I think this approach is quite expressive, readable and orthogonal
to everything else. In particular it is orthogonal to the scope.
Whenever you see the 'variable' declarator, you should think:
Attention, it is really variable.
With the "final" declarator you can lock a variable at
initialization and with the "final" build-in multi sub, you can
lock it at any time.
There may be better words than "final". I just thought, it matches
the meaning to some extend, its short and it can be used as a
verb and as a noun.
The approach is even extensible. I could imagine an otional
declarator for predeclared variables that requires that this
variables will really become defined.
Kind Regards
Stefan
-
Need a quick answer? Get one in minutes from people who know. Ask your question
on Yahoo! Answers.
[perl #39196] [TODO] tests - need to test addmethod
On Wed May 24 05:26:22 2006, coke wrote: > New addmethod opcode needs tests. > > -- > Will "Coke" Coleda > [EMAIL PROTECTED] > > Attached a patch that adds a test for "addmethod". It adds a method in the same (root) namespace, and also a method in a different namespace. I couldn't really think of other testcases. If anybody has any ideas, I'm willing to write the tests. regards, klaas-jan addmethodtest.patch Description: Binary data
[svn:parrot-pdd] r17119 - trunk/docs/pdds
Author: smash Date: Wed Feb 21 09:38:04 2007 New Revision: 17119 Modified: trunk/docs/pdds/pdd22_io.pod Log: [docs/pdds]: fix typo Modified: trunk/docs/pdds/pdd22_io.pod == --- trunk/docs/pdds/pdd22_io.pod(original) +++ trunk/docs/pdds/pdd22_io.podWed Feb 21 09:38:04 2007 @@ -554,7 +554,7 @@ =item poll - $I0 = $P1, $I2, $I3, $I4 + $I0 = poll $P1, $I2, $I3, $I4 Polls a stream or socket object for particular types of events (an integer flag) at a frequency set by seconds and microseconds (the final
[perl #29994] [BUG] "loadlib $P0, varname" not working correctly
On Tue Jun 15 08:13:06 2004, leo wrote: > Dan Sugalski <[EMAIL PROTECTED]> wrote: > > At 9:50 AM +0200 6/3/04, Leopold Toetsch wrote: > >>Dan Sugalski <[EMAIL PROTECTED]> wrote: > >> > >>> Option two here would be the right one. > >> > >>For dynamic PMC classes and NCI yes. *But* what about dynamic opcode > >>libs? The PASM/PIR compilers have to load in the lib to be able to emit > >>the opcode number. > > I've for now disabled C at compile time for variables. We still > need something for dynamic opcode libs. > > I think that a separate opcode would be simplest: > > load_ops Px, "myops"# constant filename only, compile time > loadlib Px, lib# runtime > > leo > I checked this bug on windows, and apparently, the loadlib op works. See for an example the attachment. It loads the library libnci_test, which is included in the Parrot distr. Both $P0 = loadlib myLib as $P0 = loadlib 'libnci_test' work. However, something else seems to be wrong: when loading a non-existent library (as in the example), no error message/exception is shown/raised. I think this should be the case, although I don't really know the specs for that. (it would make sense to do so, though) loadlibtest.pir Description: Binary data
[perl #41387] perlcritic.t picking up non-perl files
This ticket was resolved by chromatic++ in r17069.
[perl #41569] [BUG] t/distro/file_metadata.t fails on win32
# New Ticket Created by Jerry Gay # Please include the string: [perl #41569] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41569 > don't have time to debug the failure now since we're so close to a release, but here's the output on win32: http://nopaste.snit.ch:8001/9532 i've marked this test file as 'skip_all' until the problem is tracked down and fixed. ~jerry
Preliminary notes for 0.4.9 release
Hello, all-
I've been working on the 0.4.9 release; so far things seem to be
going reasonably well. Many thanks to Jerry Gay and others who
have come before me for cleaning up the release process and making
sure the various NEWS/STATUS docs are up to date! It's really quite
straightforward now.
I do have a couple of questions, however, especially for the
people who have been working on release management in the past.
I want to make sure I understand them a bit more before cutting
the release. (Also, for some reason I've been extremely fatigued
all day today and thus making small mistakes... so I think I prefer
to take one night's rest and get it right in the morning, than to
force it out this evening and perhaps have to clean up a lot of
small mistakes.)
1. The t/library/pg.t tests require libpq.so to be installed
in order to run -- should I be testing ('make fulltest') with
this library installed?
More generally, is there a specific set of platforms I should
be performing 'make fulltest' on prior to release? And do I
need to be maximizing test coverage by making sure certain
libraries or capabilities are available on my test platform(s)?
The libpg.o is one example... but what about things such as
ICU, readline, and the like?
Again, it's no problem for me to install the libraries -- I'm
just curious about the correct procedure so I can document it
for later release managers.)
2. In r17137, I'm getting one test failure from 'make fulltest':
Failed Test Stat Wstat Total Fail List of Failed
---
t/pmc/pmethod_test.t1 256 21 2
Anyone know anything more about this failure, and should it just
be marked 'TODO' or shall I see about fixing it?
3. The release instructions don't make any mention of verifying
MANIFEST or running 'make manitest' -- should this be a required
step in creating a release? Or is it happening somewhere that
I'm not seeing?
4. Anyone have a good name for the release? I'm satisfied with
leaving 0.4.9 unnamed unless there's a sense that we really
need to name it (in which case I'll come up with one or
accept suggestions from others :-).
Any answers will be greatly appreciated -- I'll update
RELEASE_INSTRUCTIONS with whatever we come up with, and then
publish 0.4.9!
Thanks!
Pm
Re: Preliminary notes for 0.4.9 release
On Wednesday 21 February 2007 21:21, Patrick R. Michaud wrote:
> 1. The t/library/pg.t tests require libpq.so to be installed
> in order to run -- should I be testing ('make fulltest') with
> this library installed?
They should skip without the library installed; if that doesn't work on your
platform, there's a problem with the test.
I did notice that with libpq.so, they had a problem with init_pmc, but I fixed
that and they should all work now. It would be good for someone with
PostgreSQL installed and running to run them.
> More generally, is there a specific set of platforms I should
> be performing 'make fulltest' on prior to release? And do I
> need to be maximizing test coverage by making sure certain
> libraries or capabilities are available on my test platform(s)?
> The libpg.o is one example... but what about things such as
> ICU, readline, and the like?
>
> Again, it's no problem for me to install the libraries -- I'm
> just curious about the correct procedure so I can document it
> for later release managers.)
>
>
> 2. In r17137, I'm getting one test failure from 'make fulltest':
>
> Failed Test Stat Wstat Total Fail List of Failed
> ---
> t/pmc/pmethod_test.t1 256 21 2
>
> Anyone know anything more about this failure, and should it just
> be marked 'TODO' or shall I see about fixing it?
Works for me on x86 Linux.
> 4. Anyone have a good name for the release? I'm satisfied with
> leaving 0.4.9 unnamed unless there's a sense that we really
> need to name it (in which case I'll come up with one or
> accept suggestions from others :-).
http://en.wikipedia.org/wiki/List_of_parrots
I claim Yellow Rosella for my turn.
-- c
Re: Cross-compiling Parrot
Aldo Calpini wrote: 1) does anybody have objections to patching the current build system for cross-compilation (even "yes, but not now because..." objections)? Not at all. Cross-compilation is definitely a core goal for Parrot. 2) does anybody already have a .plan or something in mind about it (so that I may either learn from what others have thought, or avoiding reinventing some wheel)? We do. Unfortunately we can't rely on Perl 5 for the configure system. It may seem like an easy way to gain cross-compilation in the short term, but in the long term it will hurt us. Miniparrot is the right way to go. It certainly needs work, though. As you're thinking of solutions think of what miniparrot would need to become cross-compiler aware. > woot! I am _not_ going to become a pir programmer, sorry :-) You'll be surprised at how easy it is to pick up, especially if you have experience with dynamic languages. There are, of course, plenty of Parrot tasks that don't require PIR skills, but don't give up before you try it. You might like it. > I have no problems with this approach. modulo the fact that I'm an > absolute beginner in the fine art of version control (some CVS, a little > bit of SVN, but just basic checkout-checkin), so I have no idea how to > go about branching and merging and all that stuff. but I'll find the > time to RTFM on my own :-) That being the case, let's start you out submitting patches. It's where everyone starts, and having a mentor to review patches at first is a great way to pass along the knowledge of the experienced Parrot hackers. For a change this size, we generally start with a proposal, review it as a group, and then dive into implementation. In this case, given the nature of the problem and your experience with the codebase, go ahead and start experimenting with code, but write up your plans as you go. We'll do an architecture review before too long to see how well the idea fits with the overall plans for Parrot. Patching the existing build system is a good way to start. It'll get you more familiar with the codebase, and give us all a better sense of the scope of the problem and the obstacles we're likely to encounter. Thanks for volunteering, Allison
