Re: ***SPAM*** Re: perl 6 grammar
cdumont wrote:
> In japanese it could even be :
>
> wa {
> '' no baai ni { ... }
> }
>
> Getting rid off the thema or I guess here taking $_ as the default.
>
> is this possible :
>
> given $operator {
> '' {}
> '' {}
> }
>
> ?
>
>
If Larry doesn't mind me elbowing into the conversation... The
unmentioned detail here is that given and when are decoupled; they're
not two keywords in the same construct. In other words, given can be
used without when and when can be used inside any block.
C only binds $_ and executes a block, it's kind of a single-shot
C. So you can do this:
given $long_expression_that_is_difficult_to_type_more_than_once {
.trim;
s:g///;
.prettify;
.indent;
say $_;
}
And C simply matches the current $_ with its argument. So you can,
for example, use it inside C or C:
@encoded = map @list:{
when 'black' { 1 }
when 'white' { 2 }
when /#(.*)/ { $<1> }
}
Miro
parrotsketch
Reminder, parrotsketch is today at the usual time; lurkers welcome. Anyone using their commit bits should consider presenting a report on their status. From http://www.parrotcode.org/misc/parrotsketch.html : "This meeting currently occurs each Tuesday at 18:30 UTC, in the #parrotsketch channel on irc (irc.perl.org)." Note that with the end of DST a few weeks ago, your local time for the meeting may have changed. Regards.
Re: Pair notation for number radix
On Sun, Oct 07, 2007 at 03:01:06PM -0600, David Green wrote: > On 10/6/07, brian d foy wrote: >> That looks like it might mean that these are corresponding forms: >>8 => 377:8<377>:8(377) >> >> Now, if I can do that, what happens to the pair form in a hash composer >> when I want the key of '8' and the value of :10<377>? > > What happened to the suggestion of using ` to designate units? It's kinda caught between two other notions. On the one hand, we're trying to reserve ` for user definition, in part because it's so difficult to tell from ' in many fonts so we're avoiding it for standard usage. On the other hand, it's not clear that units aren't generally just simple multiplication by a scaling factor: 1*in, where 1*in == 2.54*cm, for instance. Units could also be viewed as type conversion, which would give us kg(1) and 1.kg as conversion forms in current Perl 6. Since 1.kg is essentially using the units as a postfix, presumably the 1kg form could also work on literals, just as we currently allow 1i to convert 1 to i via the postfix: operator. (And I suppose there's a sense in which 10e-2 is specifying the scaling factor of the left side explicitly.) In any case, though, if we treated them as type names rather than just methods, we'd probably want to require predeclaration of unit names since a type name like "kg" or "in" or "fortnight" could easily collide with a user-defined routine. Or maybe they still want some special sigil-ish mark to stay in their own namespace. Dunno. I don't think we have to solve that for 6.0.0 in any case, especially if we require predeclaration of which unit names are wanted, in which case there might just be a units pragma that can pull in selections of the predefined units: use units :cgs, :nasa, <μfortnight gibibyte>; my newton $thrust = 42.lbf; But with a sigilish mark we could just pull in all the units from /usr/share/units.dat, I suppose. > Bases are a > kind of unit (sort of -- counting the number of 10's or 2's or 16's), so if > the colon-form is ambiguous, perhaps it could be 20`16==32`10? Hmm, well, kinda... I think that would be a bit of an end-weight mistake, like the /x modifiers in Perl 5, where you when you get to the end of the regex you mentally have to backtrack and reparse. Though numeric literals are rarely that long, so the end-weight argument doesn't carry a lot of weight when you take in the construct as a single visual unit. I think the killer is that the two ends are visually ambiguous: 10`8 would be misread as 8 in base 10 half the time. 2.54`cm doesn't have that problem so much. And in any case, I like the current prefix form more better. Larry
Re: perl 6 and web open source projects
[[ This message was both posted and mailed: see the "To," "Cc," and "Newsgroups" headers for details. ]] In article <[EMAIL PROTECTED]>, cdumont <[EMAIL PROTECTED]> wrote: > oh, it might not be relevant in many ways but : > > http://iamseb.com/seb/2007/12/perl-on-rails-why-the-bbc-fails-at-the-internet/ > > http://www.bbc.co.uk/blogs/radiolabs/2007/11/perl_on_rails.shtml > > There's one thing I would like perl6 to shine in, is web and open source. As Trey pointed out, this sort of discussion belongs somewhere else. Note that no language really shines on the web: it's something that someone makes with the language (e.g. Catalyst, Rails, Seaside, Django) that shines on the web :)
[perl #48108] [BUG] downcase opcode fails on unicode strings w/o icu
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #48108] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48108 > If ICU isn't present, Parrot's C opcode always throws an exception. It does this even if the string contains codepoints only in the ascii and/or iso-8859-1 range. For example: $ cat x.pir .sub main :main $S0 = unicode:"hello world" $S1 = downcase $S0 say $S1 .end $ ./parrot x.pir no ICU lib loaded current instr.: 'main' pc 3 (x.pir:3) This may cause a problem for Perl 6 programs, since the source code is always read as Unicode, and particularly affects the C< « > and C< » > characters (codepoints U+00ab and U+00bb). So far the major place I've run into this is in PGE, and I have a workaround there [1], but it will certainly crop up in many other places as we get more Perl 6 programs going. Pm [1] PGE only has to downcase a single character at a time, so instead of doing "$S1 = downcase $S0" it can cheat with $I0 = ord $S0 $S1 = chr $I0 $S1 = downcase $S1 This works because chr with codepoints < 256 produces strings as either ascii or iso-8859-1, and downcase can work with that.
Re: Pair notation for number radix
On 4 Dec 2007, at 15:39, Larry Wall wrote: It's kinda caught between two other notions. On the one hand, we're trying to reserve ` for user definition, in part because it's so difficult to tell from ' in many fonts so we're avoiding it for standard usage. On the other hand, it's not clear that units aren't generally just simple multiplication by a scaling factor: 1*in, where 1*in == 2.54*cm, for instance. Units could also be viewed as type conversion, which would give us kg(1) and 1.kg as conversion forms in current Perl 6. Since 1.kg is essentially using the units as a postfix, presumably the 1kg form could also work on literals, just as we currently allow 1i to convert 1 to i via the postfix: operator. (And I suppose there's a sense in which 10e-2 is specifying the scaling factor of the left side explicitly.) I've missed prior discussions about this - apologies. Is there any thought of doing dimensional analysis? 2m/s * 3s = 6m Is there any thought of using units to denote, e.g. string encoding? my $amp = '&'; # No unit, plain text my $body = "$amp"html; # gets & In other words interpolating plain text into a string that has the unit 'html' would force a (user defined) html upgrade on the interpolated text. On the other hand my $amp = '&'html; my $body = "$amp"html; # gets & -- Andy Armstrong, Hexten
Re: Pair notation for number radix
On 4 Dec 2007, at 16:19, Andy Armstrong wrote: my $amp = '&'; # No unit, plain text my $body = "$amp"html; # gets & Per http://search.cpan.org/~andya/String-Smart/ I should say. -- Andy Armstrong, Hexten
Re: Pair notation for number radix
In article <[EMAIL PROTECTED]>, Larry Wall
<[EMAIL PROTECTED]> wrote:
> : Later in the "Literals" section of S02, there's a chart of the
> : corresponding forms for fat arrow, pair, and paren notation. It has
> :
> :a => 'foo' :a :a()
> :
> : That looks like it might mean that these are corresponding forms:
> :
> :8 => 377:8<377>:8(377)
>
> The first is just a pair of 8 and 377, and has no special numeric
> significance. The adverbial syntax is special in that, for ordinary
> pairs, what follows the colon must be an identifier, so :8<377>
> would ordinarily be illegal.
Did I miss this in the spec somewhere? I've basically assked the same
question in regards to file tests. I wouldn't be asking the question if
the spec didn't keep talking about pairs and adverbs being the same
thing. If the Pair and adverbs aren't different syntax for the same
thing, how should that affect that chart in S02?
> The :8(377) above is a bit wrong, by the way, and works only because
> decimal 377 happens to stringify to something that looks like an
> octal number. You couldn't, for instance, say :16(deadbeef) unless
> deadbeef() was a 0-ary (or listop with no args) function returning
> a hex string.
Could you have :16('deadbeef')? Should the :8(377) still work (so, does
'wrong' mean it won't do what I'm thinking it will do, or that it does
mean that Perl 6 won't compile it, or some other sort of wrong)?
Re: perl 6 grammar
Another thing to note about given ... when: you don't have to use them
together. All that "given" does is to set $_ to the variable
provided; this can be used in a manner similar to "with" statements in
other languages. And "when" doesn't have to be inside a "given"
block, either: it can be used in any block that sets $_. For example:
for @list {
when *..^0 { say "$_ is negative" }
when 0 {say "$_ is zero" }
when 0^..* { say "$_ is positive" }
default { say "$_ is something else" }
}
or (I think):
method test ($value) {
setup();
when $value { doit() } #[smart-match the calling object $_ against $value.]
}
(Question: assuming that the above is valid, would breaking out of the
when block be the same as returning from the method? Or would it
qualify as an abnormal termination of the method?)
--
Jonathan "Dataweaver" Lang
[perl #48112] [BUG] cloning a hash also clones its values
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #48112] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48112 > Cloning a Hash also causes its values to be cloned. Perhaps this is the desired behavior, but if so, it's inconsistent with cloning other aggregates. The following program shows that cloning a Hash also clones the elements in the Hash: $ cat z1.pir .sub main .local pmc value value = new 'String' value = 'xyz' # create a hash with the above value .local pmc agg0, agg1 agg0 = new 'Hash' agg0['xyz'] = value # clone it agg1 = clone agg0 # now change the value value = 'abc' # see what the hashes say $S0 = agg0['xyz'] say $S0 $S0 = agg1['xyz'] say $S0 .end $ ./parrot z1.pir abc xyz $ This is consistent with the behavior of at least ResizablePMCArray, which doesn't clone its elements: $ cat z2.pir .sub main .local pmc value value = new 'String' value = 'xyz' # create an array with the above value .local pmc agg0, agg1 agg0 = new 'ResizablePMCArray' agg0[12] = value # clone it agg1 = clone agg0 # now change the value value = 'abc' # see what the arrays say $S0 = agg0[12] say $S0 $S0 = agg1[12] say $S0 .end $ ./parrot z2.pir abc abc $ I think clone ought to be fairly consistent here, whatever it does. If we decide that clone should have deepcopy semantics, then we need a note somewhere that explains the recommended way to do shallow copies. Also, if we decide to keep the deepcopy clone semantics for Hash, we need to fix it so that we can clone NULL entries in the hash (this is how I ran across the problem in the first place). Thanks, Pm
Re: [perl #47011] [DEPRECATED] VTABLE entry 'new_from_string'
Kevin Tew wrote: The logic was present in FIA, before PCC was written. It was reused in an attempt to "don't repeat yourself". Probably would be better as a literal key than a string that has to be parsed. Allison
Re: Pair notation for number radix
On Tue, Dec 04, 2007 at 08:28:48AM -0800, brian d foy wrote:
: In article <[EMAIL PROTECTED]>, Larry Wall
: <[EMAIL PROTECTED]> wrote:
:
: > : Later in the "Literals" section of S02, there's a chart of the
: > : corresponding forms for fat arrow, pair, and paren notation. It has
: > :
: > :a => 'foo' :a :a()
: > :
: > : That looks like it might mean that these are corresponding forms:
: > :
: > :8 => 377:8<377>:8(377)
: >
: > The first is just a pair of 8 and 377, and has no special numeric
: > significance. The adverbial syntax is special in that, for ordinary
: > pairs, what follows the colon must be an identifier, so :8<377>
: > would ordinarily be illegal.
:
: Did I miss this in the spec somewhere? I've basically assked the same
: question in regards to file tests. I wouldn't be asking the question if
: the spec didn't keep talking about pairs and adverbs being the same
: thing. If the Pair and adverbs aren't different syntax for the same
: thing, how should that affect that chart in S02?
You're confusing various levels here when you say "same thing".
They're the same in some ways and different in others.
Syntactically, only the :foo forms can be considered literals. =>
is just a Pair composer operator and takes two scalar expressions of
arbitrary complexity. => always creates a Pair object in the abstract
(which may be interpreted as a named argument when used in an argument
list). The => syntax may only ever be used where a term is expected.
The :foo forms, when used where a term is expected, behave like =>
but are restricted to an identifier for the key. (The value can be any
subscriptlike expression.) But unlike =>, the :foo forms can also be
used as adverbs where an *operator* is expected, as in
1..20 :by(3)
The => form cannot be used in this syntactic slot because it would end
up looking like two terms in a row to the parser:
1..20 'by' => 3
or alternately would look like an attempt to use infix::
1..20 by => 3
Basically, => shouldn't be used for adverbials. It's only for real Pair
programming. (Or in a pinch, named args, but maybe we should just force
people to use :foo for that.)
: > The :8(377) above is a bit wrong, by the way, and works only because
: > decimal 377 happens to stringify to something that looks like an
: > octal number. You couldn't, for instance, say :16(deadbeef) unless
: > deadbeef() was a 0-ary (or listop with no args) function returning
: > a hex string.
:
: Could you have :16('deadbeef')?
Certainly, why not? It's a hex string passed as a normal arg. But usually
you'd reserve that parenthesized form for when you don't know the arg:
:16($randomvar)
and instead write the above as
:16
since in that case you want a complete literal. :16($x) is really
kind of a pseudoliteral, like "this is a $randomvar string" is a
pseudoliteral that really is one or more operators in disguise.
:[EMAIL PROTECTED] would also be a pseudo-literal, but :16[1,2,3,4] could
be construed as a real literal only via constant folding of a
real expression, just as :16('deadbeef') could be constant folded.
But we don't yet spec what must be constant folded and what isn't.
This could be construed as a weakness in the spec, since it could
result in non-portabilities. On the other hand, maybe we should
just claim that every operation known to be pure at compile time
is constant folded. That would be simpler to learn and to teach,
except for the part about teaching what "pure" means. :)
: Should the :8(377) still work (so, does
: 'wrong' mean it won't do what I'm thinking it will do, or that it does
: mean that Perl 6 won't compile it, or some other sort of wrong)?
Er, "should"? In one sense of "should", it shouldn't. But as I
said, it does work, but not the way it appears to work, because 377
is parsed as a decimal number, not an octal string. It's just a
mathematical accident that octal can be encoded in decimal that way,
and it misleads people to think that the () are functioning as quotes
rather than real expression delimiters. Then they'll cargocult it
to write :16(deadbeef) as well and it Simply Won't Work.
Larry
Re: Pair notation for number radix
On Tue, Dec 04, 2007 at 07:39:16AM -0800, Larry Wall wrote:
> On Sun, Oct 07, 2007 at 03:01:06PM -0600, David Green wrote:
> > What happened to the suggestion of using ` to designate units?
>
> It's kinda caught between two other notions. On the one hand,
> we're trying to reserve ` for user definition, in part because it's
> so difficult to tell from ' in many fonts so we're avoiding it for
> standard usage. On the other hand, it's not clear that units aren't
> generally just simple multiplication by a scaling factor: 1*in, where
> 1*in == 2.54*cm, for instance. Units could also be viewed as type
> conversion, which would give us kg(1) and 1.kg as conversion forms
> in current Perl 6. Since 1.kg is essentially using the units as a
> postfix, presumably the 1kg form could also work on literals, just as
> we currently allow 1i to convert 1 to i via the postfix: operator.
> (And I suppose there's a sense in which 10e-2 is specifying the
> scaling factor of the left side explicitly.)
>
> In any case, though, if we treated them as type names rather than
> just methods, we'd probably want to require predeclaration of unit
> names since a type name like "kg" or "in" or "fortnight" could easily
> collide with a user-defined routine. Or maybe they still want some
> special sigil-ish mark to stay in their own namespace. Dunno. I don't
> think we have to solve that for 6.0.0 in any case, especially if we
> require predeclaration of which unit names are wanted, in which case
> there might just be a units pragma that can pull in selections of
> the predefined units:
>
> use units :cgs, :nasa, <μfortnight gibibyte>;
> my newton $thrust = 42.lbf;
>
> But with a sigilish mark we could just pull in all the units from
> /usr/share/units.dat, I suppose.
I don't know if I ever mentioned it on the mailing list, but a while
back I did some work on a units module that uses units.dat
(examples/rules/unitsdat-grammar.pm in the pugs repo). I think
that a simple postfix syntax (e.g.) doesn't give you the ability to
specify the kind of composite units that are common in scientific
applications where units are heavily used (e.g. Gauss per square root
Hertz). Those kind of units also rule out simple type-based units, e.g.
having roles for length, mass, etc. - you can't do a role to the -7/3
power. I settled on a syntax that allows a mini-language similar to
units(1):
9.8.:as
$field_noise.:as
But someone may be able to come up with something better. My
implementation does unit type-checking at runtime, but compile-time
checking would be much nicer where possible. It would also be cool to
be able to define roles that can represent themselves in several
different units:
role Photon does NumUnit { ??? }
my Photon $p .=new( energy => 42.:as );
say "energy is $p.:as zeptojoules";
say "wavelength is $p.:as Å";
say "frequency is $p.:as THz";
-ryan
Re: [perl #47011] [DEPRECATED] VTABLE entry 'new_from_string'
Francois PERRAD wrote: 'new_from_string' is widely used by .const, for example : .const .String key_print = "print" That's the one case I consider a valid use of 'new_from_string', actually creating a string constant during initialization. Other hackery has been piled on top of the feature, just because it was there. or .const .Sub _create = 'create' What becomes this kind of constructor ? How about fixing the .const directive so it supports the full set of options in PMC initialization? (We need to change .const anyway, so it stops using type IDs.) .const _create = new "Sub", $P0 or .const _create = new "FixedIntegerArray", [ 1; 3; 5; 7; 9 ] Allison
[perl #47924] [BUG] test failures in t/oo/mro-c3.t
Resolved in r23461.
[perl #47890] [BUG] t/oo not part of 'make test'
Resolved in r23462. Pm
[perl #48112] [BUG] cloning a hash also clones its values
On Tue Dec 04 08:40:12 2007, pmichaud wrote: > Cloning a Hash also causes its values to be cloned. > Perhaps this is the desired behavior, but if so, it's > inconsistent with cloning other aggregates. After thinking about it a bit more, I'm not sure I want Hash's behavior with clone to change -- perhaps ResizablePMCArray should change to match Hash. Either way, I'm simply going to use this ticket to note the inconsistency between the two and let others decide if anything should be done about it. Thanks, Pm
[perl #48118] [PATCH] Replace additional instances of '$/'
# New Ticket Created by James Keenan
# Please include the string: [perl #48118]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=48118 >
The patch replaces Perl special variable $/ with \n in 8 locations in modules
under config/.
kid51
Index: config/init/hints/linux.pm
===
--- config/init/hints/linux.pm (revision 23449)
+++ config/init/hints/linux.pm (working copy)
@@ -16,7 +16,7 @@
my $verbose;
$verbose = $conf->options->get('verbose');
-print $/ if $verbose;
+print "\n" if $verbose;
# should find g++ in most cases
my $link = $conf->data->get('link') || 'c++';
Index: config/auto/m4.pm
===
--- config/auto/m4.pm (revision 23449)
+++ config/auto/m4.pm (working copy)
@@ -37,7 +37,7 @@
my ( $self, $conf ) = @_;
$verbose = $conf->options->get( 'verbose' );
-print $/ if $verbose;
+print "\n" if $verbose;
my $archname = $conf->data->get_p5('archname');
my ( $cpuarch, $osname ) = split m/-/, $archname, 2;
Index: config/auto/warnings.pm
===
--- config/auto/warnings.pm (revision 23449)
+++ config/auto/warnings.pm (working copy)
@@ -131,7 +131,7 @@
my ( $self, $conf ) = @_;
$verbose = $conf->options->get('verbose');
-print $/ if $verbose;
+print "\n" if $verbose;
# add on some extra warnings if requested
push @potential_warnings, @cage_warnings
@@ -164,7 +164,7 @@
my $output_file = 'test.cco';
-$verbose and print "trying attribute '$warning'$/";
+$verbose and print "trying attribute '$warning'\n";
my $cc = $conf->option_or_data('cc');
cc_gen('config/auto/warnings/test_c.in');
@@ -173,24 +173,24 @@
my $tryflags = "$ccflags $warning";
my $command_line = Parrot::Configure::Step::_build_compile_command( $cc,
$tryflags );
-$verbose and print " ", $command_line, $/;
+$verbose and print " ", $command_line, "\n";
# Don't use cc_build, because failure is expected.
my $exit_code =
Parrot::Configure::Step::_run_command( $command_line, $output_file,
$output_file );
-$verbose and print " exit code: $exit_code$/";
+$verbose and print " exit code: $exit_code\n";
$conf->data->set( $warning => !$exit_code | 0 );
return if $exit_code;
my $output = Parrot::BuildUtil::slurp_file($output_file);
-$verbose and print " output: $output$/";
+$verbose and print " output: $output\n";
if ( $output !~ /error|warning|not supported/i ) {
$conf->data->set( ccflags => $tryflags );
my $ccflags = $conf->data->get("ccflags");
-$verbose and print " ccflags: $ccflags$/";
+$verbose and print " ccflags: $ccflags\n";
return 1;
}
else {
[perl #45479] [CAGE] config/gen/PodText.pm: Find better location
No one has spoken up for retaining this module in the distribution. I
searched anew for references to it and found them only in the MANIFEST
and the file itself. We have other means of generating plain-text
documentation. I therefore recommend deleting the file from trunk.
Index: MANIFEST
===
--- MANIFEST (revision 23465)
+++ MANIFEST (working copy)
@@ -1,7 +1,7 @@
# ex: set ro:
# $Id$
#
-# generated by tools/dev/mk_manifest_and_skip.pl Tue Dec 4 20:01:00 2007 UT
+# generated by tools/dev/mk_manifest_and_skip.pl Tue Dec 4 20:57:18 2007 UT
#
# See tools/dev/install_files.pl for documentation on the
# format of this file.
@@ -273,7 +273,6 @@
config/auto/va_ptr/test_c.in[]
config/auto/warnings.pm []
config/auto/warnings/test_c.in []
-config/gen/PodText.pm []
config/gen/config_h.pm []
config/gen/config_h/config_h.in []
config/gen/config_h/feature_h.in[]
Index: config/gen/PodText.pm
===
--- config/gen/PodText.pm (revision 23465)
+++ config/gen/PodText.pm (working copy)
@@ -1,100 +0,0 @@
-# Copyright (C) 2001-2007, The Perl Foundation.
-# $Id$
-
-=head1 NAME
-
-config/gen/PodText.pm - generate plain text docs from Pod files
-
-=head1 SYNOPSIS
-
-use gen::PodText;
-
-gen::PodText->runstep($conf,
-"source1.pod" => "dest1.pod"
-"source2.pod" => "dest2.pod"
-);
-
-=head1 DESCRIPTION
-
-Uses L to convert Pod documents into their plain text equivalents.
-
-=head1 USAGE
-
-=head2 Methods
-
-=head3 Class Methods
-
-=over
-
-=item * C
-
-Converts Pod documents into plain text. Documents to be converted as specified
-as a hash with the keys being the source Pod document and the values being the
-destination plain text file.
-
-Accepts a L object followed by a flattened hash.
-
-=back
-
-=cut
-
-package gen::PodText;
-
-use strict;
-use warnings;
-use vars qw($description $result @args);
-
-use base qw(Parrot::Configure::Step::Base);
-
-use Pod::Text;
-
-$description = 'Generating plain text docs from Pod';
-
[EMAIL PROTECTED] = qw(verbose);
-
-sub runstep {
-my ( $self, $conf, %docs ) = @_;
-
-my $verbose = $conf->options->get('verbose');
-
-my $parser = Pod::Text->new( width => 79 );
-
-my $count = 0;# number of processed files
-foreach my $pod ( keys %docs ) {
-$count++;
-
-my $plain = $docs{$pod};
-$parser->parse_from_file( $pod, $plain );
-
-# append a header to the generated plain text
-open( my $fh, '+<', $plain )
-or die "can not open file $plain: $!";
-my $text = do { local $/; <$fh> };
-$text =
- "# DO NOT EDIT THIS FILE\n"
-. "# Generated by "
-. __PACKAGE__
-. " from $pod\n" . "\n"
-. $text;
-
-# the filehandle was opened for update so the files 'position' has to
-# be reset to the begining of the file so we don't end up just
-# appending to the end of the file.
-seek $fh, 0, 0;
-print $fh $text;
-close($fh) or die "can not close file $plain: $!";
-}
-
-$self->set_result( $count ? 'done' : 'no files to process' );
-
-return 1;
-}
-
-1;
-
-# Local Variables:
-# mode: cperl
-# cperl-indent-level: 4
-# fill-column: 100
-# End:
-# vim: expandtab shiftwidth=4:
[perl #45479] [CAGE] config/gen/PodText.pm: Find better location
On Tue Dec 04 13:00:10 2007, [EMAIL PROTECTED] wrote: > No one has spoken up for retaining this module in the distribution. I > searched anew for references to it and found them only in the MANIFEST > and the file itself. We have other means of generating plain-text > documentation. I therefore recommend deleting the file from trunk. [Duplicate comment, going to the list this time]] If there are no references to it anywhere, +1; we have more than enough desirable items in the repository, and no need to cling to relics.
[perl #48120] [TODO] [C] Remove nonportable signbit code from perlnum.pmc
# New Ticket Created by Paul Cochrane # Please include the string: [perl #48120] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48120 > In languages/perl5/src/pmc/perlnum.pmc:get_string() there is the todo item: /* XXX signbit isn't portable and as we are calling Parrot_sprintf_c * anyway, we can use the builtin number formatting too * this might still be a problem with -0.0 */ The code using the signbit() call is commented out, so I vote for just deleting the offending code. Any objections?
[perl #48122] [TODO] [C] PerlInt should extend PerlAny or PerlScalar in perlint.pmc (?)
# New Ticket Created by Paul Cochrane # Please include the string: [perl #48122] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48122 > In languages/perl5/src/pmc/perlint.pmc there is the todo item: /* TODO extends PerlAny or perlscalar or whatever */ This is when extending Integer to get a PerlInt for Perl 5 integers. The todo item isn't actually that clear about what it wants to be done, but it looks like PerlInt should also be extending PerlScalar and/or PerlAny.
[perl #48124] [TODO] [C] Fix arithmetic ops in perlarray.pmc
# New Ticket Created by Paul Cochrane # Please include the string: [perl #48124] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48124 > In languages/perl5/src/pmc/perlarray.pmc there is the todo item: """ Fix the arithmetic ops (right now they just corrupt the array length and possibly seg fault). """ In short, do (please).
[perl #48128] [TODO] [dotnet] Does a null first byte need special handling in dotnetsignature.pmc?
# New Ticket Created by Paul Cochrane # Please include the string: [perl #48128] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48128 > In languages/dotnet/pmc/dotnetsignature.pmc:read_compressed() there is the todo item: /* Otherwise, it's a null byte. XXX Need special handling? */ This is when reading in the first byte to decide if it's a single encoded byte. We need to work out here if, in the case that the first byte is null, whether or not special handling is required.
[perl #48130] [TODO] [dotnet] Why does sig_token have to be set to 0xFFFF in make_bytecde_pmc()?
# New Ticket Created by Paul Cochrane # Please include the string: [perl #48130] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48130 > In languages/dotnet/pmc/dotnetassembly.pmc:make_bytecode_pmc() there is the todo item (with surrounding code for context): /* Get code size and local signature location. */ bytecode->body_size = read_word_u(in); sig_token = read_word_u(in); if (ass->rows[Table_StandAloneSig] < 2 << 15) sig_token &= 0x; /* XXX Why do we have to do this? */ So, this still begs the question: why do we have to do this?
[perl #48132] [TODO] [cardinal] Need to throw an exception about invalid boolean type in get_bool()
# New Ticket Created by Paul Cochrane # Please include the string: [perl #48132] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48132 > In languages/cardinal/src/pmc/rubystring.pmc:get_bool() there is the todo item: /* XXX Throw exception about invalid boolean type. */ This needs to be implemented.
PGE & Multiple grammar associations
Is it possible to compile a single PGE grammar against multiple sets of actions to get multiple different parsers? This would be good for Lisp-like languages where you have one parser that spits out PIR code and a parser that is invoked for "(read)" calls and spits out s-expression objects. Both would work off the same grammar, but the different actions allow for different outputs from the parsers. - Istarex
Re: PGE & Multiple grammar associations
On Tue, Dec 04, 2007 at 12:54:43PM -0500, istarex wrote: > Is it possible to compile a single PGE grammar against multiple sets > of actions to get multiple different parsers? This would be good for > Lisp-like languages where you have one parser that spits out PIR code > and a parser that is invoked for "(read)" calls and spits out > s-expression objects. Both would work off the same grammar, but the > different actions allow for different outputs from the parsers. Yes. In fact, in PGE any actions to be performed are supplied as a runtime argument to the grammar, so one doesn't even have to recompile the grammar to get this behavior. For example, a few days ago it occurred to me that NQP and perl6 could potentially share the same parse grammar definition, but simply differ in the actions that each performs. NQP would simply ignore or stub out those constructs that it doesn't choose to implement. Pm
[perl #45479] [CAGE] config/gen/PodText.pm: Find better location
On Tue Dec 04 13:04:05 2007, coke wrote: > > If there are no references to it anywhere, +1; we have more than enough > desirable items in the repository, and no need to cling to relics. [parrot] 504 $ fns . | xargs grep -l PodText ./config/gen/PodText.pm ./MANIFEST
[perl #48134] [BUG][PATCH]interp->current_args overwritten in callmethodcc
# New Ticket Created by "Mehmet Yavuz Selim Soyturk"
# Please include the string: [perl #48134]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=48134 >
Next code segfaults because callmethodcc does another method call,
which causes that interp->current_args gets overwritten.
.sub main :main
$P0 = newclass 'Obj'
$P2 = new 'Obj'
$P2.'some_method'(42)
.end
.sub meth :method
.param pmc a
say a
.end
.namespace ['Obj']
.sub find_method :vtable :method
.param string meth_name
say meth_name
.const .Sub meth = 'meth'
.return (meth)
.end
I attached a patch which seems to solve the problem.
--
Mehmet
Index: src/ops/object.ops
===
--- src/ops/object.ops (revision 23456)
+++ src/ops/object.ops (working copy)
@@ -55,11 +55,17 @@
PMC *method_pmc, *object;
opcode_t *next;
STRING *meth;
+ opcode_t *current_args;
object = $1;
meth = $2;
next = expr NEXT();
+
+ /* find_method can overwrite interp->current_args! */
+ current_args = interp->current_args;
method_pmc = VTABLE_find_method(interp, object, meth);
+ interp->current_args = current_args;
+
if (PMC_IS_NULL(method_pmc)) {
real_exception(interp, next, METH_NOT_FOUND,
"Method '%Ss' not found", meth);
@@ -91,11 +97,17 @@
PMC *method_pmc, *object;
opcode_t *next;
STRING *meth;
+ opcode_t *current_args;
object = $1;
meth = $2;
next = expr NEXT();
+
+ /* find_method can overwrite interp->current_args! */
+ current_args = interp->current_args;
method_pmc = VTABLE_find_method(interp, object, meth);
+ interp->current_args = current_args;
+
if (PMC_IS_NULL(method_pmc)) {
real_exception(interp, next, METH_NOT_FOUND,
"Method '%Ss' not found", meth);
[perl #48138] [BUG] t/native_pbc/integer.t, t/native_pbc/number.t fail on Darwin
# New Ticket Created by James Keenan # Please include the string: [perl #48138] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48138 > In the course of preparing the patch submitted in r23472 to config/ auto/pmc.pm this evening, I had occasion to run 'make coretest' on both darwin-ppc and Linux. Two tests failed on Darwin but passed on Linux. Please see patch attached. Thank you very much. kid51 [autopmc] 554 $ prove -v t/native_pbc/integer.t t/native_pbc/number.t t/native_pbc/integer1..1 not ok 1 - i386 32 bit opcode_t, 32 bit intval # Failed test (t/native_pbc/integer.t at line 56) # Exited with error code: [SIGNAL 11] # Received: # # Expected: # 270544960 # Looks like you failed 1 test of 1. dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/1 tests, 0.00% okay t/native_pbc/number.1..1 not ok 1 - i386 double float 32 bit opcode_t # Failed test (t/native_pbc/number.t at line 86) # got: '012345678910111213141516171819202122232425' # expected: '1.00 # 4.00 # 16.00 # 64.00 # 256.00 # 1024.00 # 4096.00 # 16384.00 # 65536.00 # 262144.00 # 1048576.00 # 4194304.00 # 16777216.00 # 67108864.00 # 268435456.00 # 1073741824.00 # 4294967296.00 # 17179869184.00 # 68719476736.00 # 274877906944.00 # 1099511627776.00 # 4398046511104.00 # 17592186044416.00 # 70368744177664.00 # 281474976710656.00 # 1125899906842620.00 # ' # Looks like you failed 1 test of 1. dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/1 tests, 0.00% okay Failed TestStat Wstat Total Fail List of Failed --- t/native_pbc/integer.t1 256 11 1 t/native_pbc/number.t 1 256 11 1 Failed 2/2 test scripts. 2/2 subtests failed. Files=2, Tests=2, 3 wallclock secs ( 0.30 cusr + 0.18 csys = 0.48 CPU) Failed 2/2 test programs. 2/2 subtests failed. [autopmc] 555 $
[perl #48138] [BUG] t/native_pbc/integer.t, t/native_pbc/number.t fail on Darwin
I note that the same two tests are failing in this smoke report today from FreeBSD: http://tinyurl.com/2cb7c9
[perl #48142] [DEPRECATED] class_type vtable
# New Ticket Created by Will Coleda # Please include the string: [perl #48142] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48142 > From PDD17: =item class_type INTVAL class_type(INTERP, PMC* self) Return the integer type of the PMC. [NOTE: will be deprecated when type IDs are deprecated.] -- Will "Coke" Coleda [EMAIL PROTECTED]
[perl #48144] [DEPRECATED] pmc_namespace vtable
# New Ticket Created by Will Coleda # Please include the string: [perl #48144] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48144 > >From PDD17: =item pmc_namespace [deprecated] PMC* pmc_namespace(INTERP, PMC* self) Return the namespace object for this PMC. [NOTE: replaced by C.]
[svn:parrot-pdd] r23476 - in trunk: . docs/pdds
Author: coke Date: Tue Dec 4 21:02:17 2007 New Revision: 23476 Modified: trunk/docs/pdds/pdd17_pmc.pod Changes in other areas also in this revision: Modified: trunk/DEPRECATED.pod Log: [docs] open tickets for deprecated items in pdd17; note them in DEPRECATED also. Modified: trunk/docs/pdds/pdd17_pmc.pod == --- trunk/docs/pdds/pdd17_pmc.pod (original) +++ trunk/docs/pdds/pdd17_pmc.pod Tue Dec 4 21:02:17 2007 @@ -474,7 +474,7 @@ hash. This opcode is most often used with high-level classes, but low-level PMCs may instantiate an object of their own type. -=item new_from_string [deprecated] +=item new_from_string [deprecated: See RT# 47011] PMC* new_from_string(INTERP, PMC* self, STRING* rep, INTVAL flags) @@ -563,14 +563,13 @@ C object (or other high-level class object). For low-level PMCs, this returns a C object. -=item class_type +=item class_type [deprecated: See RT# 48142] INTVAL class_type(INTERP, PMC* self) -Return the integer type of the PMC. [NOTE: will be deprecated when type -IDs are deprecated.] +Return the integer type of the PMC. -=item pmc_namespace [deprecated] +=item pmc_namespace [deprecated: See RT# 48144] PMC* pmc_namespace(INTERP, PMC* self)
[perl #48150] [BUG] pdd23 doesn't document obtaining thrown exception object
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #48150] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48150 > PDD23 doesn't provide much information about how an exception handler gets access to the thrown exception object itself. For exception handlers that are subs, I suspect the exception is one of the arguments to the sub. If so, this should be made explicit. For exception handlers that are label targets within subs, I'm not sure what the "official" mechanism is. Many programs in the repository seem to use a ".get_results" PIR directive, which isn't documented in pdd23 or in the draft pdd19. Pm
[perl #48152] [TODO] document (pdd19) or deprecate .get_results directive
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #48152] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48152 > Many exception handlers in the repository use a ".get_results" directive to obtain the thrown exception object. This directive doesn't seem to be documented anywhere, except in the (highly outdated) "compiler_faq.pod" document. TODO: (1) adopt .get_results and document it, or (2) deprecate it and identify what is to be used in its place. Pm
