[perl #62804] [TODO± implement \c and \C in Regexes
# New Ticket Created by Moritz Lenz # Please include the string: [perl #62804] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=62804 > Perl 6 regexes should support \c for a named (or decimal) character, and \C to match everything except that character. That's hidden in S02/Literals/ (not S05...) "(Within a regex you may also use \C to match a character that is not the specified character.)" Plenty of tests are in t/spec/S05-mass/named-chars.t Cheers, Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: [perl #62738] The use of 'use' before 'class Foo is Bar' in Rakudo
On Sun, Jan 25, 2009 at 07:41:04AM -0800, Carl Mäsak wrote:
> [...]
> masak: yes, STD allows use before class Foo is Bar;
> however it's not clear the p6 autorecognizer will work in that case
> so you might have to start with 'use v6'
> TimToady: I consider starting with 'use v6' good style anyway.
> thanks for the good news. submitting rakudobug. :)
>
> So, um, the bug is... that Rakudo currently doesn't allow 'use' before
> 'class Foo is Bar', whereas STD.pm does.
STD.pm currently (r25059) allows _any_ statement to occur prior to a
"class Foo is Bar;" declaration, which seems to contradict S11:
A module is declared with the C keyword. There are
two basic declaration syntaxes:
module Foo; # rest of scope is in module Foo
...
module Bar {...}# block is in module Bar
The first form is allowed only as the first statement in the file.
Rakudo is currently following the S11 definition. Perhaps we need
a bit of clarification on the synopsis or STD.pm here.
Pm
[perl #62810] [TODO] Implement Match.perl (Prelude)
# New Ticket Created by Moritz Lenz # Please include the string: [perl #62810] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=62810 > There's a basic implementation in http://code.google.com/p/rakudo-prelude/source/browse/trunk/lib/Match.pm It's nothing fancy, and I haven't yet tested if it produces a Match object when eval()ed, but as a debugging aid it's surely worth a patch - once we've got a Perl 6 Prelude in place. Cheers, Moritz
Re: Operator sleuthing...
On Thu, Jan 15, 2009 at 10:52:55PM -0800, Mark Lentczner wrote:
> I'm re-working my "Periodic Table of the Operators" chart to be up-to-
> date. I did the first major pass based on S03-operators. However, the
> last few days I've been plowing through STD.pm and have discovered that
> there some differences. Since STD.pm is considered more up to date, I'll
> be changing the chart to match that. However, I thought it would be
> useful to share the detailed list of differences I found. Besides, there
> are some embedded questions in there, I'd love to have answered.
>
> Thanks,
> - Mark
>
>
> STD.pm: r24855 | lwall | 2009-01-10
> S03-operators.pod r24895 | lwall | 2009-01-13
>
> == Associativity ==
>
> Prefix and postfix precedence levels have no associativity in STD, but
> are left (mostly) or right in S03. Levels affected are:
> %methodcall
> %autoincrement
> %symbolic_unary
> %named_unary
> %loose_unary
> %list_prefix
Fixed, but it took a while. :)
> Some levels have left associativity in STD, but are list in S03. Levels
> affected:
> %concatenation
> %tight_and
> %tight_or
> %loose_and
> %loose_or
Fixed.
> Oddly, sym<^^> ( --> Tight_or) is forced to :assoc in STD.
It is now naturally list.
> ?? Even though for most of these operators there is no computational
> difference between left and list assoc, list seems more "in the spirit"
> to me. I plan on leaving them listed as 'list' assoc in the chart unless
> there is a reason to make them left.
List is correct. And, in fact, list associativity now devolves to right
associativity rather than left.
> Conditional level is right in STD, and left in S03.
Is right.
> == Added ==
>
> STD has a new Methodcall operator construction:
> token privop ( --> Methodcall) {
> '!'
> }
> ?? What is this?
Private method call, described in S12.
> STD has postfix:sym. I understand this is the imaginary operator.
Yes.
> STD has infix:sym<.=>. I understand this to be the method call
> assigning form when there is space after the operator.
> ?? Is this right?
Putting no space before and a space after may be a syntax error.
We have a postfix form, and an infix form, but mixing the two
will look to the parser like an incomplete postfix. Then again,
it might backtrack and find it currently. It's arguable whether
"progress" has been made in a predictive parser sense.
> STD has <==, ==>, <<==, and ==>> as true operators. S03 groups them as
> terminators.
Fixed S03.
> STD has sym<;> as both an infix operator ( --> Sequencer), and as a
> terminator.
> ?? Which is it? Since I think most people think of it as a statement
> terminator, I plan on leaving it off the chart.
STD now parses it consistently as a statement terminator (or as a
special delimiter in argument lists, but that's more or less the same).
> STD is missing sym<\\> at Symbolic_unary level.
> ?? Did capture cease to be an operator?
It's a special form, primarily to distinguish it from "unspace", but
also to discourage its application to temporary results without use
of full \(...) capture notation. Or to look at it another way, it's
an operator at "term" precedence. :)
> STD is missing sym at Multiplicative level.
> ?? I'm assuming this is just an oversight.
Indeed.
> == Misc ==
>
> The ff and fff family are at %nonchaining precedence in STD, but at
> %conditional precedence in S03.
Conditional, since they involve thunks, and the right associativity
doesn't really hurt them (or help them). More practically, it lets
you use && and || in the conditionals.
> STD has infix:sym and infix:sym each declared as tokens
> twice. I'm assuming this is just some accidental duplication.
Yes.
> At Loose_unary, STD has which seems more general than the
> operator adverbs discussed in S03 at Loose unary precedence.
The cutoff is actually at "epsilon tighter than comma", which allows
for user-defined precedence levels in between.
> The infix:sym<:> invocant marker is at Comma precedence in STD, but List
> prefix in S03. It is also left assoc. in STD, but right in S03.
It is at comma precedence, which is list assoc. Since we switched to
right associative degeneracy
meth $x: 1,2,3
and since : and , are at the same level, it now groups as:
meth ($x : (1,2,3))
rather than the old
meth (($x : 1), 2, 3)
which I only discovered a couple days ago, and was greatly astonished. :)
An alternative would be to establish a category of list assoc operators
that pay no attention to changing operators. That might also allow us
to treat p5=> as exactly identical to comma. Basically we'd have
operators lying about their sym, which implies that they'd have to
store a "reallysym" somewhere to have any semantic effect downstream.
Still thinking about the ramifications of that, and whether there's
some more general idea I'm missing.
> The sigils used as operators at List_prefix in STD incl
Rakudo repository -- svn or git?
Well, we're now at the point where it's time to move the Rakudo repository, and thus we need a decision on continuing to use svn for the repository or switching to git. Obviously staying with svn is very easy to handle. The other repositories that we have to coordinate with (parrot and pugs) are likely to remain in svn for the time being, so we know that things will work out well there. Switching the rakudo repository to git means that it would likely live on github, at least for a short time. We'd also have to provide mechanisms for people to continue to obtain and be able to easily commit to the pugs subversion repository. I will be making a decision (and possibly starting the migration) tomorrow. If anyone has any strong opinions one way or another, please let them be known quickly. I'd also prefer that we not get into long discussions at this time -- there's been plenty of opportunity for that. Just state your preference and possibly a short statement of why you prefer that choice. (If you have no preference, state that also.) As decisions are made and things start moving, I'll make postings to the mailing lists, rakudo.org, use.perl, etc. Thanks! Pm
Re: Rakudo repository -- svn or git?
> > time -- there's been plenty of opportunity for that. Just state > your preference and possibly a short statement of why you > prefer that choice. > I prefer git. It's fast and distributed and it would be nice to be able to easily have local branches and whatnot. (I know SVK can do the last part.) -- -fREW http://blog.afoolishmanifesto.com
Re: Rakudo repository -- svn or git?
On Tue, Jan 27, 2009 at 08:18, Patrick R. Michaud wrote: > I will be making a decision (and possibly starting the > migration) tomorrow. If anyone has any strong opinions > one way or another, please let them be known quickly. > I'd also prefer that we not get into long discussions at this > time -- there's been plenty of opportunity for that. Just state > your preference and possibly a short statement of why you > prefer that choice. > please, svn, so i can do svn switch --relocate and move on with my life. ~jerry
Re: Rakudo repository -- svn or git?
Em Ter, 2009-01-27 às 10:18 -0600, Patrick R. Michaud escreveu: > Well, we're now at the point where it's time to move the > Rakudo repository, and thus we need a decision on continuing > to use svn for the repository or switching to git. I think it primarily depends on how you're planning to manage the development. If you intend to keep a centralized management of the repository, keeping track of all the committers and branches, svn is probably the best choice, and people who like git can always use git-svn, additionally one could keep a git repository hosted somewhere that was frequently sync-ed with the svn repo. On the other hand, if you'd like to make it have a more loose management, you should probably use git, which would allow branches to be hosted anywhere developers want and you would only manage the "official" branch of the code and the release branches as well. As a more incisive comment, I personally experienced bad merge behavior in svn several times, while git has positively surprised me several times.. daniel
r25060 - docs/Perl6/Spec src/perl6
Author: lwall
Date: 2009-01-27 18:43:18 +0100 (Tue, 27 Jan 2009)
New Revision: 25060
Modified:
docs/Perl6/Spec/S03-operators.pod
src/perl6/STD.pm
Log:
[STD] more operator hacking inspired by mtnviewmark++
[S03] added comparison-reversion metaoperator
Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.pod 2009-01-27 10:11:54 UTC (rev 25059)
+++ docs/Perl6/Spec/S03-operators.pod 2009-01-27 17:43:18 UTC (rev 25060)
@@ -12,9 +12,9 @@
Maintainer: Larry Wall
Date: 8 Mar 2004
- Last Modified: 24 Jan 2009
+ Last Modified: 27 Jan 2009
Number: 3
- Version: 149
+ Version: 150
=head1 Overview
@@ -1472,7 +1472,7 @@
$a < 1 && $b == 2 :carefully
does the C<&&> carefully because C<&&> is of
-tighter precedence than "loose unary". Use
+tighter precedence than "comma". Use
$a < 1 && ($b == 2 :carefully)
@@ -3400,7 +3400,7 @@
operators yourself. Similarly, the carets that exclude the endpoints
on ranges are there by convention only.
-In contrast to that, Perl 6 has five standard metaoperators for
+In contrast to that, Perl 6 has six standard metaoperators for
turning a given existing operator into a related operator that is
more powerful (or at least differently powerful). These differ from a
mere naming convention in that Perl automatically generates these new
@@ -3483,8 +3483,9 @@
=head2 Negated relational operators
-Any infix relational operator may be transformed into its negative
-by prefixing with C. A couple of these have traditional shortcuts:
+Any infix relational operator returning type C may be transformed
+into its negative by prefixing with C. A couple of these have
+traditional shortcuts:
Full form Shortcut
-
@@ -3506,6 +3507,23 @@
The precedence of any negated operator is the same as the base operator.
+Note that logical operators such as C<||> and C<^^> do not return a Bool,
+but rather one of the operands.
+
+=head2 Reversed comparison operators
+
+Any infix comparison operator returning type C may be transformed into
its reversed sense
+by prefixing with C<->.
+
+-cmp
+-leg
+-<=>
+
+To avoid confusion with the C<-=> operator, you may not modify
+any operator already beginning with C<=>.
+
+The precedence of any reversed operator is the same as the base operator.
+
=head2 Hyper operators
The Unicode characters C<»> (C<\x[BB]>) and C<«> (C<\x[AB]>) and
Modified: src/perl6/STD.pm
===
--- src/perl6/STD.pm2009-01-27 10:11:54 UTC (rev 25059)
+++ src/perl6/STD.pm2009-01-27 17:43:18 UTC (rev 25060)
@@ -150,7 +150,7 @@
chars graphs codes bytes
say print open close printf sprintf slurp unlink link symlink
-elems grep map first reduce sort uniq push reverse take splice
+elems grep map first reduce sort min max uniq push reverse take splice
lines getc
zip each roundrobin caller
@@ -233,7 +233,7 @@
constant %junctive_or = (:dba('junctive_or') , :prec,
:assoc, :assign);
constant %named_unary = (:dba('named_unary') , :prec,
:assoc, :uassoc);
constant %nonchaining = (:dba('nonchaining') , :prec, :assoc);
-constant %chaining= (:dba('chaining'), :prec,
:assoc, :bool);
+constant %chaining= (:dba('chaining'), :prec,
:assoc, :returns); # XXX Bool string, not type
constant %tight_and = (:dba('tight_and') , :prec,
:assoc, :assign);
constant %tight_or= (:dba('tight_or'), :prec,
:assoc, :assign);
constant %conditional = (:dba('conditional') , :prec,
:assoc);
@@ -272,7 +272,7 @@
} # end role
-class Hyper does PrecOp {
+class Transparent does PrecOp {
our %o = (:transparent);
} # end class
@@ -1031,6 +1031,7 @@
}
token infixish {
+:my $infix;
:dba('infix or meta-infix')
@@ -1050,7 +1051,7 @@
|
{ $ = $;
$ = $; }
-| )>
+| ; }>
{ $ = $.; $ =
$.; }
]
}
@@ -1129,20 +1130,32 @@
token postfix_prefix_meta_operator:sym< » >{ | '>>' }
-token infix_prefix_meta_operator:sym ( --> Chaining) {
+token infix_prefix_meta_operator:sym ( --> Transparent) {
= $; }>
[
-|| eq 'chain'}>
-|| and $ }>
-|| <.panic: "Only boolean infix operators may be negated">
+|| // '') eq 'Bool' }>
+|| <.worry: "Only boolean infix operators may be negated">
]
and $¢.panic("Negation of hyper operator not allowed") }>
+}
+token infix_prefix_meta_operator:sym<-> ( --> Transparent) {
+
+
+ = $; }>
+
+
+[
+|| // '') eq 'Order' }>
+|| <.worry: "Only comparison infix operators may be negated">
+]
+
+ and $¢.panic("Negation of hyper operator not allowed") }>
}
method lex1 (Str $s) {
@@ -1160,7 +1173,7 @@
}
-token infix_circumfix_meta_operat
Re: r25060 - docs/Perl6/Spec src/perl6
On Tue, Jan 27, 2009 at 9:43 AM, wrote: > +=head2 Reversed comparison operators > + > +Any infix comparison operator returning type C may be transformed > into its reversed sense > +by prefixing with C<->. > + > +-cmp > +-leg > +-<=> > + > +To avoid confusion with the C<-=> operator, you may not modify > +any operator already beginning with C<=>. > + > +The precedence of any reversed operator is the same as the base operator. If there are only a handful of operators to which the new meta-operator can be applied, why do it as a meta-operator at all? This could be generalized to allow any infix operator returning a signed type (which would include C) to reverse the sign. In effect, "$x -op $y" would be equivalent to "-($x op $y)". (Which suggests the possibility of a more generalized rule about creating "composite operators" by applying prefix or postfix operators to infix operators in an analogous manner; but that way probably lies madness.) Also, wouldn't the longest-token rule cause C<-=> to take precedence over C<=> prefixed with C<->? Or, in the original definition, the fact that C<=> isn't a comparison operator? -- Jonathan "Dataweaver" Lang
Re: r25060 - docs/Perl6/Spec src/perl6
On Tue, Jan 27, 2009 at 10:59:34AM -0800, Jon Lang wrote: : If there are only a handful of operators to which the new : meta-operator can be applied, why do it as a meta-operator at all? As a metaoperator it automatically extends to user-defined comparison operators, but I admit that's not a strong argument. Mostly I want to encourage the meme that you can use - to reverse a comparison operator, even in spots where the operator is named by strings, such as (potentially) in an OrderingPair, which currently can be written &extract_key => &infix:<-leg> but that might be abbreviate-able to :extract_key<-leg> or some such. That's not a terribly strong argument either, but perhaps they're additive, if not addictive. :) : This could be generalized to allow any infix operator returning a : signed type (which would include C) to reverse the sign. In : effect, "$x -op $y" would be equivalent to "-($x op $y)". (Which : suggests the possibility of a more generalized rule about creating : "composite operators" by applying prefix or postfix operators to infix : operators in an analogous manner; but that way probably lies madness.) Well, even -+ seems a bit mad. And Int/Num don't do Order, since that's an enum subset of Int, not a role. : Also, wouldn't the longest-token rule cause C<-=> to take precedence : over C<=> prefixed with C<->? Or, in the original definition, the : fact that C<=> isn't a comparison operator? It would be a tie, since both operators are the same length. The current tiebreaking rules would make it depend on which was declared first, which may or may not make sense. Arguably autogenerated operators should give way to hardwired ones, much like foo\w* gives way to foobar currently. Larry
Re: r25060 - docs/Perl6/Spec src/perl6
On Tue, Jan 27, 2009 at 11:56:16AM -0800, Larry Wall wrote: : Arguably autogenerated operators should give way to hardwired ones, : much like foo\w* gives way to foobar currently. Though I should point out that this wouldn't help with -=, since it's autogenerated either way, unless you divide the token into literal and wildcard like foo\w*, in which case literal - and meta = wins over meta - and literal =, since wildcardness currently treats the remainder of the token as wild even if there are additional literal components. Larry
[perl #62828] .clone inside while loop which shifts off an array doesn't clone properly in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #62828]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=62828 >
rakudo: class A { has $.b; }; while shift [A.new( :b(0) )] ->
$a { say $a.b; $a.clone( :b($a.b + 1) ); say $a.b; last; }
OUTPUT[01]
* masak submits rakudobug
[perl #62836] Null PMC access when calling user-declared sub in List:: class
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #62836]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=62836 >
rakudo: sub List::a {}; <1 2 3>.a
rakudo 36054: OUTPUT«Null PMC access in invoke() [...]
I'm not at all sure subs should be called that way, but a Null PMC
access is always wrong.
Re: spelunking in the meta-ops in STD.pm
On Sun, Jan 18, 2009 at 10:57:26PM -0800, Mark Lentczner wrote:
> I was looking through STD.pm at the parsing of metaops. I was exploring
> to see if the legal metaops for a given operator could be notated on the
> operator chart. What I found was some oddness...
Caveat: The actual autogeneration of metaop tokens needs to be
refactored somewhat. Currently any constraints are enforced
at match-time, which doesn't help trim down the list of possible
tokens. The absence of a declarative framework induces various
distortions in how the rules are formulated currently.
> op= (infix_postfix_meta_operator:sym<=>)
>
> The internal op is restricted to be not :assoc('chain') and not
> :assoc('non')... But, the various precedence groupings have a property,
> :assign on them that is never used. Yet, this property seem like just
> the thing. To my eye, :assign seems like the right set of operators that
> are expected to be used here. The current test is too liberal, allowing
> things like ,= and ==>>= (gasp!)
Agreed.
> !op (infix_prefix_meta_operator:sym)
> ---
> The internal op is restricted to be :assoc('chain'), or not have a
> default :assoc and be :bool. This seems overly defined: The only
> operators with :assoc('chain') have :bool. Like above, I think the
> internal op should be restricted on the :bool property alone.
Changed to :returns now.
> [op] (prefix_circumfix_meta_operator.reduce)
>
> This internal op is restricted to not have :assoc('non') nor be at the
> same precedence level as %conditional. That later test strikes me as
> strange. The restriction should be not having :assoc('chain') nor
> :assoc('non').
There maybe needs to be a restriction on "thunky" macro-operators.
> Now - the classes of what can be applied to what, especially considering
> other metaops, is a bit tangled:
>
> >>op -- op can be any >>op, postfix, dotty, privop, or postcircumfix
> the later is odd: what could >>(...) mean?
>
> op<< -- op can be any prefix, a [op], or another <
> I suppose these multiply applied ops might be useful? op and op
> ?
The intent was to restrict any kind of recursion for something that must
be recognized by LTM, where recursion means revisiting the same metaop.
I'd like all other allowed compositions of metaops, though. However,
the LTM is not yet powerful enough to handle that many tokens.
> op=, !op, >>op<< -- op can only be a (simple) infix operator
>
> [op], XopX -- op can an infix, or !op or XopX or >>op<<
> or, put another way, any simple or complex infix op, except op=
>
> I understand why op= and !op have highly restricted internal op sets.
> But why should >>op<< be so restricted as well? It means that >><=<<
> and >>~~<< are legal, but >>!<=<< and >>!~~<< are not.
The intent is to allow these eventually.
> And, if the prefix and postfix hyper metaops can be nested... then why
> not the infix: + anybody? (Not, mind you, that *I* would
> advocate for them, or such exotic beasts as [X>>+<>>>+ are disallowed because you can't use recursive
patterns in the LTM if it is to remain in the realm of regular
languages. [X>>+< Lastly, the token for [x] (prefix_circumfix_meta_operator.reduce) has an
> oddity that it allows an optional trailing << (acutally, only the
> Unicode version of that!). I'm not sure why the prefix hyper metaop is
> parsed here... especially since the code for token PRE clearly parses
> this construction.
Again has to do with faking out the LTM pattern generator for now. Should
get better later.
Larry
Re: Rakudo repository -- svn or git?
Not long ago, Patrick R. Michaud proclaimed... > Well, we're now at the point where it's time to move the > Rakudo repository, and thus we need a decision on continuing > to use svn for the repository or switching to git. > > Obviously staying with svn is very easy to handle. The other > repositories that we have to coordinate with (parrot and pugs) > are likely to remain in svn for the time being, so we know > that things will work out well there. > > Switching the rakudo repository to git means that it would > likely live on github, at least for a short time. We'd also > have to provide mechanisms for people to continue to obtain > and be able to easily commit to the pugs subversion repository. The existing mechanism (makefile calls svn to check out t/spec) will work fine unmodified with rakudo in git. > I will be making a decision (and possibly starting the > migration) tomorrow. If anyone has any strong opinions > one way or another, please let them be known quickly. > I'd also prefer that we not get into long discussions at this > time -- there's been plenty of opportunity for that. Just state > your preference and possibly a short statement of why you > prefer that choice. I prefer to work with git. I feel a lot more confident that I won't screw things up with git. I'm more comfortable working with server-side branches with git. Feel free to weight my preference against my recent inactivity, though.
Re: r25060 - docs/Perl6/Spec src/perl6
Larry Wall wrote: > Jon Lang wrote: > : If there are only a handful of operators to which the new > : meta-operator can be applied, why do it as a meta-operator at all? > > As a metaoperator it automatically extends to user-defined comparison > operators, but I admit that's not a strong argument. Mostly I want > to encourage the meme that you can use - to reverse a comparison > operator, even in spots where the operator is named by strings, such > as (potentially) in an OrderingPair, which currently can be written > >&extract_key => &infix:<-leg> > > but that might be abbreviate-able to > >:extract_key<-leg> > > or some such. That's not a terribly strong argument either, but > perhaps they're additive, if not addictive. :) So "$a -<=> $b" is equivalent to "$b <=> $a", not "-($a <=> $b)". OK. I'd suggest choosing a better character for the meta-operator (one that conveys the meaning of reversal of order rather than opposite value); but I don't think that there is one. > : Also, wouldn't the longest-token rule cause C<-=> to take precedence > : over C<=> prefixed with C<->? Or, in the original definition, the > : fact that C<=> isn't a comparison operator? > > It would be a tie, since both operators are the same length. I guess I don't understand the longest-token rules, then. I'd expect the parser to be deciding between operator "-=" (a single two-character token) vs. meta-operator "-" (a one-character token) followed by operator "=" (a separate one-character token). Since meta-op "-" is shorter than op "-=", I'd expect op "-=" to win out. -- Jonathan "Dataweaver" Lang
Re: Rakudo repository -- svn or git?
Patrick R. Michaud wrote: > Switching the rakudo repository to git means that it would > likely live on github, at least for a short time. We'd also > have to provide mechanisms for people to continue to obtain > and be able to easily commit to the pugs subversion repository. > > I will be making a decision (and possibly starting the > migration) tomorrow. If anyone has any strong opinions > one way or another, please let them be known quickly. > I'd also prefer that we not get into long discussions at this > time -- there's been plenty of opportunity for that. Just state > your preference and possibly a short statement of why you > prefer that choice. > > (If you have no preference, state that also.) I'm fine with both, and have no real preference atm, just a small bias towards git. Cheers, Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
[perl #62838] [BUG] typed array attributes are initially not empty
# New Ticket Created by mbere...@flashmail.com
# Please include the string: [perl #62838]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=62838 >
Compare the following two command lines, both should print
0:
perl6 -e 'class A { has @!a; method m { say @!a.elems; }; };
A.new.m;'
perl6 -e 'class A { has Str @!a; method m { say @!a.elems;
}; }; A.new.m;'
The latter prints 1, and a more extensive example using a
class type instead of Str suggests that the array contains a
protoobject. No bisect results yet, but r35309 (just
pre-rvar2) prints 0 both times.
Re: Rakudo repository -- svn or git?
Moritz (>): > I'm fine with both, and have no real preference atm, just a small bias > towards git. Same here. I like both systems, but ceteris paribus, I like git better. I find it hard to tell in advance whether it'd be worth the trouble switching, though. // Carl
Re: [svn:parrot] r36057 - in trunk: . config/auto config/auto/format config/gen/config_h include/parrot src t/compilers/imcc/syn t/op
On Tue, Jan 27, 2009 at 10:24:46AM -0800, parti...@cvs.perl.org wrote:
> -gen_sprintf_call(tc, &info, ch);
> -ts = cstr2pstr(tc);
> +/* check for Inf and NaN values */
> +if (thefloat == PARROT_FLOATVAL_INF_POSITIVE) {
> +ts = cstr2pstr(PARROT_CSTRING_INF_POSITIVE);
> +}
> +else if (thefloat ==
> PARROT_FLOATVAL_INF_NEGATIVE) {
> +ts = cstr2pstr(PARROT_CSTRING_INF_NEGATIVE);
> +}
> +/* XXX for some reason, this comparison isn't
> working
> +else if (thefloat == PARROT_FLOATVAL_NAN_QUIET) {
No, it is working :-)
NaN != NaN.
Hence why <=> has 4 possible return values.
> +ts = cstr2pstr(PARROT_CSTRING_NAN_QUIET);
> +}
> +*/
> +else if (thefloat != thefloat) {
The above is the valid test for a NaN.
Note, Intel chose that the default optimiser setting on their compiler should
be buggy. (Advice from Klortho #11912). The perl 5 Linux hints file suggests
that one needs to add -we147 to enable correct floating point behaviour.
The best test that I'm aware of for "is it NaN or Inf?" is val != val * 0;
Then, NaN is val != val, +Inf is val > 0, -Inf is val < 0;
Nicholas Clark
Re: Rakudo repository -- svn or git?
On Tue, Jan 27, 2009 at 11:25:29AM -0700, Stephen Weeks wrote: > > Switching the rakudo repository to git means that it would > > likely live on github, at least for a short time. We'd also > > have to provide mechanisms for people to continue to obtain > > and be able to easily commit to the pugs subversion repository. > > The existing mechanism (makefile calls svn to check out t/spec) will > work fine unmodified with rakudo in git. ...assuming that the system also has subversion installed and readily available. Pm
Re: Rakudo repository -- svn or git?
On Tue, Jan 27, 2009 at 10:49 AM, Daniel Ruoso wrote: > Em Ter, 2009-01-27 às 10:18 -0600, Patrick R. Michaud escreveu: > > Well, we're now at the point where it's time to move the > > Rakudo repository, and thus we need a decision on continuing > > to use svn for the repository or switching to git. > > I think it primarily depends on how you're planning to manage the > development. If you intend to keep a centralized management of the > repository, keeping track of all the committers and branches, svn is > probably the best choice, and people who like git can always use > git-svn, additionally one could keep a git repository hosted somewhere > that was frequently sync-ed with the svn repo. > > On the other hand, if you'd like to make it have a more loose > management, you should probably use git, which would allow branches to > be hosted anywhere developers want and you would only manage the > "official" branch of the code and the release branches as well. > > As a more incisive comment, I personally experienced bad merge behavior > in svn several times, while git has positively surprised me several > times.. I don't know ... I don't think it much matters how development is to be "managed". Git can be managed identically to subversion, so there's no difference there unless there's something that you want from git that svn doesn't provide. And for me, that's the advantage of git--you get things that you don't have or don't easily have with subversion. Here's a rough list in no particular order: - sane merges (you don't have to remember to annotate commits with merge info nor do you have to destroy your branches once you've reintegrated them with main development) - private branches (I think this one speaks for itself :) - git bisect (relatively easily find commits that broke something) - git supports multiple workflows - git lets you select just the changes you want to commit (say you've accidentally comingled two feature changes, but you want to commit them separately) - git lets you collapse or explode local commits before pushing them upstream (maybe it took you 5 commits to fully implement a feature, you can make that a single feature commit upstream if you desire) - git format-patch/git send-email/git am (if you're not a commiter, you can easily generate patches, send them, and developers can easily apply them. BTW, this triumvirate can be used independent of each other) - git is really fast (the larger the repo, the more you notice this) - github - git is more efficient WRT disk usage. Okay ... I really wasn't trying to proselytize git, but these are the features that attract me to git and why I use it (particularly those first few). There are also a few intangibles that make git a good fit for me. It seems to have the perl-nature of TMTOWTDI and the idea of "many histories" (as contrasted with svn's linear history), seems to be more the way the world really works. okay, I'll shut up now except to say this: I prefer git :-) -Scott -- Jonathan Scott Duff perlpi...@gmail.com
Re: Rakudo repository -- svn or git?
Patrick R. Michaud wrote: On Tue, Jan 27, 2009 at 11:25:29AM -0700, Stephen Weeks wrote: Switching the rakudo repository to git means that it would likely live on github, at least for a short time. We'd also have to provide mechanisms for people to continue to obtain and be able to easily commit to the pugs subversion repository. The existing mechanism (makefile calls svn to check out t/spec) will work fine unmodified with rakudo in git. ...assuming that the system also has subversion installed and readily available. Sure, but we assume that now. :-) To register my current thoughts here on the list: * I don't have much of a preference either way from the point of view of my regularish hacking on Rakudo. On the one hand, I have to learn something new. On the other, there may well be a win from that. * Enough people who have worthwhile opinions on other stuff seem to rate it, so I'm guessing there's substance rather than hype. * Enough people on #parrot/#perl6 know it, that I'm happy I can get hints as needed. Or just flame those who advocated it if I find it sucky. ;-) * I'm satisfied we can make a read-only svn frontend if need be, to keep folks happy who just want to quickly grab a checkout to compile and don't have git yet (since svn install base is wider). If we have to move to git-hub before hosting elsewhere first, perhaps let's set ourselves up a DNS CNAME alias, like git.rakudo.org. Then we don't have to change repository URL a second time. Thanks, Jonathan
Re: [svn:parrot] r36057 - in trunk: . config/auto config/auto/format config/gen/config_h include/parrot src t/compilers/imcc/syn t/op
On Tue, Jan 27, 2009 at 10:58, Nicholas Clark wrote:
> On Tue, Jan 27, 2009 at 10:24:46AM -0800, parti...@cvs.perl.org wrote:
>
>> -gen_sprintf_call(tc, &info, ch);
>> -ts = cstr2pstr(tc);
>> +/* check for Inf and NaN values */
>> +if (thefloat == PARROT_FLOATVAL_INF_POSITIVE) {
>> +ts = cstr2pstr(PARROT_CSTRING_INF_POSITIVE);
>> +}
>> +else if (thefloat ==
>> PARROT_FLOATVAL_INF_NEGATIVE) {
>> +ts = cstr2pstr(PARROT_CSTRING_INF_NEGATIVE);
>> +}
>> +/* XXX for some reason, this comparison isn't
>> working
>> +else if (thefloat == PARROT_FLOATVAL_NAN_QUIET)
>> {
>
> No, it is working :-)
>
> NaN != NaN.
>
> Hence why <=> has 4 possible return values.
>
>> +ts = cstr2pstr(PARROT_CSTRING_NAN_QUIET);
>> +}
>> +*/
>> +else if (thefloat != thefloat) {
>
> The above is the valid test for a NaN.
>
> Note, Intel chose that the default optimiser setting on their compiler should
> be buggy. (Advice from Klortho #11912). The perl 5 Linux hints file suggests
> that one needs to add -we147 to enable correct floating point behaviour.
>
> The best test that I'm aware of for "is it NaN or Inf?" is val != val * 0;
> Then, NaN is val != val, +Inf is val > 0, -Inf is val < 0;
>
thanks! patched up in r36071 and r36072.
~jerry
Re: [perl #37700] [TODO] Changing Default STDOUT/STDERR Filehandles for PIR Code
On Wed, Dec 17, 2008 at 12:52 AM, chromatic wrote:
> On Tuesday 16 December 2008 15:40:32 Allison Randal via RT wrote:
>
>> The simple solution is to add opcodes for 'setstdin', 'setstdout', and
>> 'setstderr' that change the interpreter's stored FileHandle PMCs to a
>> PMC passed in as an argument. This will not effect any C code that
>> directly calls the low-level read/write functions instead of using the
>> Parrot_io_* functions, but then C code should pretty much always use the
>> Parrot_io_* functions. (Some exceptions to the general rule apply, like
>> when the code specifically needs to override any user changes to
>> STD[IN|OUT|ERR]).
>
> Do these need to be opcodes? Can they be methods on the interpreter instead?
Here is patch:
Index: src/pmc/parrotinterpreter.pmc
===
--- src/pmc/parrotinterpreter.pmc (revision 36072)
+++ src/pmc/parrotinterpreter.pmc (working copy)
@@ -30,6 +30,8 @@
#include "parrot/dynext.h"
#include "pmc_class.h"
+#include "../io/io_private.h"
+
/*
=item C= PIO_STDIN_FILENO && fileno <= PIO_STDERR_FILENO) {
+handle = interp->piodata->table[fileno];
+if (!PMC_IS_NULL(newhandle))
+interp->piodata->table[fileno] = newhandle;
+}
+RETURN(PMC *handle);
+}
+
}
/*
And a test:
$ cat handle.pir
.sub main
.local pmc interp, nullout, stdout
interp = getinterp
nullout = open '/dev/null', 'w'
stdout = interp.'stdhandle'(1, nullout)
stdout.'print'("Hello\n")
say 'Hi'
interp.'stdhandle'(1, stdout)
say 'Bye'
.end
$ ./parrot handle.pir
Hello
Bye
--
Salu2
Re: [svn:parrot] r36057 - in trunk: . config/auto config/auto/format config/gen/config_h include/parrot src t/compilers/imcc/syn t/op
On Tue, 27 Jan 2009, Nicholas Clark wrote:
> On Tue, Jan 27, 2009 at 10:24:46AM -0800, parti...@cvs.perl.org wrote:
>
> > +else if (thefloat != thefloat) {
>
> The above is the valid test for a NaN.
>
> Note, Intel chose that the default optimiser setting on their compiler should
> be buggy. (Advice from Klortho #11912). The perl 5 Linux hints file suggests
> that one needs to add -we147 to enable correct floating point behaviour.
>
> The best test that I'm aware of for "is it NaN or Inf?" is val != val * 0;
> Then, NaN is val != val, +Inf is val > 0, -Inf is val < 0;
Well, if they are available, isnan() and isinf() are probably worth
trying. You can piggy back on perl 5's $Config{d_isnan} and
$Config{d_isinf}. To distinguish +NaN from -NaN, I suspect you might also
want to use signbit() (which, alas, perl 5 doesn't probe for).
Some of these functions might only be available under certain compiler
options or with certain extra libraries, depending on how a particular
system attempts to adhere to different standards, but it's probably worth
trying them.
--
Andy Dougherty dough...@lafayette.edu
[svn:parrot-pdd] r36076 - trunk/docs/pdds
Author: allison
Date: Tue Jan 27 20:35:00 2009
New Revision: 36076
Modified:
trunk/docs/pdds/pdd28_strings.pod
Log:
[pdd] Regularizing string API function names to fit the pattern of a
three-character subsystem identifier.
Modified: trunk/docs/pdds/pdd28_strings.pod
==
--- trunk/docs/pdds/pdd28_strings.pod (original)
+++ trunk/docs/pdds/pdd28_strings.pod Tue Jan 27 20:35:00 2009
@@ -340,7 +340,7 @@
=head3 Conversions between normalization form, encoding, and charset
-Conversion will be done with a function called C:
+Conversion will be done with a function called C:
INTVAL string_grapheme_copy(STRING *src, STRING *dst)
@@ -362,41 +362,41 @@
Parrot's external API will be renamed for the standard "Parrot_*" naming
conventions.
-=head3 Parrot_string_set (was string_set)
+=head3 Parrot_str_set (was string_set)
Set one string to a copy of the value of another string.
-=head3 Parrot_string_new_COW (was Parrot_make_COW_reference)
+=head3 Parrot_str_new_COW (was Parrot_make_COW_reference)
Create a new copy-on-write string. Creating a new string header, clone the
struct members of the original string, and point to the same string buffer as
the original string.
-=head3 Parrot_string_reuse_COW (was Parrot_reuse_COW_reference)
+=head3 Parrot_str_reuse_COW (was Parrot_reuse_COW_reference)
Create a new copy-on-write string. Clone the struct members of the original
string into a passed in string header, and point the reused string header to
the same string buffer as the original string.
-=head3 Parrot_string_write_COW (was Parrot_unmake_COW)
+=head3 Parrot_str_write_COW (was Parrot_unmake_COW)
If the specified Parrot string is copy-on-write, copy the string's contents
to a new string buffer and clear the copy-on-write flag.
-=head3 Parrot_string_concat (was string_concat)
+=head3 Parrot_str_concat (was string_concat)
Concatenate two strings. Takes three arguments: two strings, and one integer
value of flags. If both string arguments are null, return a new string created
according to the integer flags.
-=head3 Parrot_string_append (was string_append)
+=head3 Parrot_str_append (was string_append)
Append one string to another and return the result. In the default case, the
return value is the same as the first string argument (modifying that argument
in place). If the first argument is COW or read-only, then the return value is
a new string.
-=head3 Parrot_string_from_cstring (was string_from_cstring)
+=head3 Parrot_str_from_cstring (was string_from_cstring)
Create a Parrot string from a C string (a C). Takes two arguments, a C
string, and an integer length of the string (number of characters). If the
@@ -405,16 +405,16 @@
{{NOTE: the integer length isn't really necessary, and is under consideration
for deprecation.}}
-=head3 Parrot_string_new
+=head3 Parrot_str_new
Return a new string with the default encoding and character set. Accepts one
argument, a C string (C) to initialize the value of the string.
-=head3 Parrot_string_new_noinit (was string_make_empty)
+=head3 Parrot_str_new_noinit (was string_make_empty)
Returns a new empty string with the default encoding and chararacter set.
-=head3 Parrot_string_new_init (was string_make_direct)
+=head3 Parrot_str_new_init (was string_make_direct)
Returns a new string of the requested encoding, character set, and
normalization form, initializing the string value to the value passed in. The
@@ -429,49 +429,49 @@
C and C can look up the encoding or
character set structs. }}
-=head3 Parrot_constant_string_new (was const_string)
+=head3 Parrot_str_constant_new (was const_string)
Creates and returns a new Parrot constant string. Takes one C string (a C) as an argument, the value of the constant string. The length of the C
string is calculated internally.
-=head3 Parrot_string_resize (was string_grow)
+=head3 Parrot_str_resize (was string_grow)
Resize the string buffer of the given string adding the number of bytes passed
in the integer argument. If the argument is negative, remove the given number
of bytes. Throws an exception if shrinking the string buffer size will
truncate the string (if C will be longer than C).
-=head3 Parrot_string_length (was string_compute_strlen)
+=head3 Parrot_str_length (was string_compute_strlen)
Returns the number of characters in the string. Combining characters are each
counted separately. Variable-width encodings may lookahead.
-=head3 Parrot_string_grapheme_length
+=head3 Parrot_str_grapheme_length
Returns the number of graphemes in the string. Groups of combining characters
count as a single grapheme.
-=head3 Parrot_string_byte_length (was string_length)
+=head3 Parrot_str_byte_length (was string_length)
Returns the number of bytes in the string. The character width of
variable-width encodings is ignored. Combining characters are not treated any
dif
Re: r25060 - docs/Perl6/Spec src/perl6
On Jan 27, 2009, at 12:29 PM, Jon Lang wrote:
So "$a -<=> $b" is equivalent to "$b <=> $a", not "-($a <=> $b)". OK.
I'd suggest choosing a better character for the meta-operator (one
that conveys the meaning of reversal of order rather than opposite
value); but I don't think that there is one.
There are two I can think of:
~ is used in regex to mean inversion of order as in:
'(' ~ ')'
which is the same as
'(' ')'
Though, of course, ~ is the prefix a number of hardwired operators,
and they all pertain to strings, so this might be awkward.
^ is used to mean 'compliment' and is the prefix to only six operators
(where it means exclusive of start point: ^.. ^..^ ^ff ^ff^ ^fff and
^fff^)
So, I could easily see:
~cmp
~<=>
~leg
Or,
^cmp
^<=>
^leg
If you REALLY want to get creative, you just spell these operators
backwards:
pmc
>=<
gel
Okay.. forget I said that
- MtnViewMark
