metamethod contradictions in S12
Around line 477, it explains that
our $count;
method ^count { return $count }
Such a I is always delegated to the C
object just as methods like C<.does> are, so it's possible to call
this as C or C<$dog.count>.
However, around line 1983 it illustrates
But C gives you shortcuts to those:
$obj.can("bark")
$obj.does(Dog)
$obj.isa(Mammal)
...In general, C will delegate only those metamethods
that read well when reasoning about an individual object.
Infrastructural methods like C<.^methods> and C<.^attributes>
are not delegated, so C<$obj.methods> fails.
That is, metamethods are not automatically delegated by the dispatcher, but
rather ordinary methods forward to the metamethod to enable that form of calling.
---
Over and over the document warns that you really shouldn't use the shortcut
form. So I'd suggest that the second way is right. If you want a shortcut to
be available (if the method reads well when reasoning about an individual
object) then write one, too.
Or, why define the ^foo form in the first place? As it explains earlier, any
method can be called on the protoobject as long as it doesn't try and access the
undefined parts of the instance. So if you want to call $obj.count, then write
method count, not method ^count.
You can also have a trait that generates the shortcut method as well, as
syntactic sugar. That does not require any new language features.
--John
Re: Allowing '-' in identifiers: what's the motivation?
On Mon, Aug 11, 2008 at 11:34:03AM -0600, Tom Christiansen wrote:
: >I'm still somewhat ambivalent about this, myself. My previous
: >experience with hyphens in identifiers is chiefly in languages that
: >don't generally have algebraic expressions, e.g. LISP, XML, so it will
: >take some getting used to in Perl. But at least in Perl's case the
: >subtraction conflict is mitigated by the fact that many subtraction
: >expressions will involve sigils; $x-$y can't possibly be a single
: >identifier.
:
: People use nonadic functions (nonary operators? where non = 0, not 9)
: without parens, and get themselves into trouble for it.
:
: % perl -E 'say time-time'
: 0
:
: % perl -E 'say time-do{sleep 3; time}'
: -3
:
: % perl -E 'say time +5'
: 1218475824
:
: % perl -E 'say time -5'
: 1218475817
:
: % perl -E 'say time(-5)'
: syntax error at -e line 1, near "(-"
: Execution of -e aborted due to compilation errors.
: Exit 19
The thing that convinced me this was a good idea is that it corresponds
pretty closely to what English orthography uses.
The thing that convinced me it's not a bad idea is that it is almost
certain that the compiler will catch any mistakes because it's strict.
In that context, the question of how often people will make such
mistakes is a secondary consideration. I was reassured on the
apostrophe score that the entire test suite only made the new
"mistake" twice. I'll have a better idea about the frequency of
hyphen mistakes once STD implements symbol tables and complains
about undefined subs, which will catch flubs like "time-time" or
"time-do".
On the subject of 0-ary functions, there's no entire solution, but one
of the things we are doing is getting rid of all the 0-or-1-ary
functions which only add to the confusion. For instance, rand
is now 0-ary only, and to get something other than a number in
the range 0..^1 you must use something like:
rand*100
100.rand
(1..100).pick
And, in fact, if you say "rand 100" the current STD grammar complains:
Obsolete use of rand(N); in Perl 6 please use N.rand or (1..N).pick instead
Larry
Re: [perl #57636] [TODO][PDD19] Document the reason for :unique_reg flag
On Fri, Aug 8, 2008 at 12:57 PM, Patrick R. Michaud <[EMAIL PROTECTED]>wrote: > On Thu, Aug 07, 2008 at 10:15:24AM -0400, Will Coleda wrote: > > Now, if the problem is that the register allocator is broken, then > > let's fix the register allocator. If :unique_reg is just a workaround > > because fixing it is hard, let's document it as deprecated with the > > expectation that it will be removed when the allocator is no longer > > broken. > > Here's my slightly different interpretation: > > Before we had variable register frames, the register allocator > was something of a necessary evil, because we needed something > that could fit a large number of symbolic registers into a > fixed number of absolute registers. > > However, now that we have variable register frames, the register > allocator is really more of an optimizer than anything else -- i.e., > it allows our code to run using fewer registers. And as with > any other optimization, we ought to provide the compiler writers > with an option to turn the optimization off. This is effectively > what :unique_reg does on a per-symbol basis. > > Of course, ":unique_reg" on individual symbols might not be > the best way to achieve this, but it does at least have > historical precedent. If we eliminate ":unique_reg", I'd > still like to have a way to generate PIR code where I know > that the register allocator isn't re-using registers or > doing other fancy allocation. > > Pm Well, at least I've seen some good reasons to keep :unique_reg around; viewing the pir compiler as an assembler (which it is, in the end, albeit a fancy one), :unique_reg is just a directive. Once the whole register allocation stuff is revisited (and I'm sure imcc's should be tested for bugs), this can be reconsidered. For now, this thread provided enough information to update pdd19. I will do this sometime soon. Thanks for all the feedback. kjs
Re: [perl #41508] [BUG] Configure losing flags...
On Sat, 9 Aug 2008, James Keenan via RT wrote: > I think that many of the things you say are interesting, but they are > part of a much broader discussion. > In a conversation I had with particle and chromatic at YAPC, particle > indicated that we would be revisiting the design of our configuration at > a point before 1.0. So what I'm doing now is largely focused on > responding to particular needs expressed by our developers which do not > require a complete re-thinking of our configuration system right now. > So, for example, here I'm trying to respond to a particular issue raised > by Coke that I think can be remedied relatively simply. That's a reasonable idea, but I was trying to point out that your proposed remedy, if implemented as you described, won't work. This makes it a "keep it working" issue. > But let me ask this: > > On Sat Aug 09 09:37:49 2008, doughera wrote: > > On Sat, 9 Aug 2008, James Keenan via RT wrote: > > > > For example, how can you know > > which > > compiler flags to suggest if you don't even know which compiler you're > > using yet? > > Do you believe that the search for the C compiler (and, presumably, > related things like the linker) should be moved earlier in the > configuration process? It's probably ok where it is. It's the dependency flow that's tricky. The hints files need to come very early -- before the compiler searching. (For example, you can't know whether to consider xlc_r unless you already know you're on the appropriate version of AIX.) After the hints file, you can get the compiler. However, now that you know the compiler, you can *apply* information from the hints file. That's what triggers do. So the information flow is: read hints file. Note information for later use. inter::progs -- Choose compiler. Apply information stored at hint-file time. So the current order could be made to work ok, provided the hint file information was applied after the compiler was chosen. Up till at least recently, the hidden unspecified assumption was that users only made non-default choices for the compiler on the Configure.pl command line, so that the "Choose compiler" step actually happened at the very beginning, long before the inter::progs step. The working assumption was that no one ever changed the compiler during the interactive steps. Thus the real, effective flow of information was: Choose compiler (by Configure.pl command-line option) read hints file apply information right away at hint-file time inter::progs -- don't change anything. By removing the command line options from the hints files without adding triggers to the hints files, you're effectively proposing changing the information flow to: read hints file apply information right away at hint-file time inter::progs -- Choose compiler (by Configure.pl command-line option) -- accept hints file settings, whether they apply to this compiler or not. See the discussion in [perl #41195] for some more background and examples. -- Andy Dougherty [EMAIL PROTECTED]
RE: Allowing '-' in identifiers: what's the motivation?
On Tue, 12 Aug 2008 10:03:03 +0200, Michael Mangelsdorf wrote: > I also tried to say that as special characters (not 7-bit ASCII) > like for hyper ops have already been admitted, the question of just how > far ($foo&bar) this admission should (be allowed to) is just around > the corner. Completely my 2¢ following. Even if programmers want to be able to put funny characters in variable names, I'm against allowing them to embed characters that already have other meaning in the language (grandfathered exception: underscore). I expect +, *, / to be operators with some kind of additive, multiplicative, and divisive semantics, and I am going to have a very hard time reading programs that contain variables like $foo*bar without a mental derailing at that asterisk. I won't mind $ricks_café, or $coke® or $¢ = $dollars*100 because those symbols have no other meaning in the language, but if we allow operator symbols in identifiers then the world will divide into those people who look at Perl 6 programs only through syntax-highlighting editors and don't know what all the fuss is about naming a variable $e*trade since it is all purple, and those people who give up on reading the other people's programs. I'm all for giving people enough rope to either hang themselves or make a hammock, but do we really want to open this can of worms? -- Peter Scott http://www.perlmedic.com/ http://www.perldebugged.com/
[perl #57876] An if statement isn't parsed correctly if it follows on a sub
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #57876]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57876 >
r30183:
$ ./perl6 -e '
sub x {
}
if 1 {
}'
Statement not terminated properly at line 4, near "{\n}"
[...]
>From S04:
=head1 Statement-ending blocks
A line ending with a closing brace "C<}>", followed by nothing but
whitespace or comments, will terminate a statement if an end of statement
can occur there. That is, these two statements are equivalent:
my $x = sub { 3 }
my $x = sub { 3 };
[perl #57884] [PATCH] file_type option for Parrot::Configure::Compiler->genfile
# New Ticket Created by Vyacheslav Matjukhin
# Please include the string: [perl #57884]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57884 >
genfile() method at the Parrot::Configure::Compiler module generates wrong
vim syntax modelines, i.e., it prints ft=c always.
This patch fixes it by implementing new file_type option.
If file_type isn't specified, genfile() tries to automatically recognize
file type by looking at a target file name.
Also, understanding file_type allows method users to forget about a
comment_type option in most cases.
This obviously generalizes old makefile option, so i removed it.
Patch contents description follows.
(as required by "How To Submit A Patch" from submissions.pod; should i
really do this? It all seems pretty obvious...)
config/gen/config_h.pm, config/gen/crypto.pm, config/gen/makefiles.pm:
using new file_type option where needed, sometimes instead of makefile
option.
lib/Parrot/Configure/Compiler.pm:
file_type option implementation and pod; hash with description of possible
file_type's and corresponding comment_type's and vim_ft's.
t/configure/034-step.t:
trivial test updates.
PS. I should've refactored 034-step.t too, but this can be done next time.
There are no tests checking genfile() output, they all just check return
value...
Index: lib/Parrot/Configure/Compiler.pm
===
--- lib/Parrot/Configure/Compiler.pm (revision 30189)
+++ lib/Parrot/Configure/Compiler.pm (working copy)
@@ -34,6 +34,25 @@
move_if_diff
);
+our %file_types_info = (
+makefile => {
+comment_type=> '#',
+vim_ft => 'make',
+},
+c => {
+comment_type=> '/*',
+vim_ft => 'c',
+},
+pmc => {
+comment_type=> '/*',
+vim_ft => 'pmc',
+},
+perl => {
+comment_type=> '#',
+vim_ft => 'perl',
+},
+);
+
=item C
$conf->cc_gen($source)
@@ -46,7 +65,7 @@
my $conf = shift;
my $source = shift;
-$conf->genfile( $source, "test_$$.c" );
+$conf->genfile( $source, "test_$$.c", file_type => 'none' );
}
=item C
@@ -179,13 +198,15 @@
=over 4
-=item makefile
+=item file_type
-If set to a true value, this flag sets (unless overridden) C
-to '#', C to enabled, and C to enabled.
+If set to a C, C or C value, C will be set
+to corresponding value.
+Moreover, when set to a C value, it will set C to
+enabled, and C to enabled.
-If the name of the file being generated ends in C, this option
-defaults to true.
+Its value will be detected automatically by target file name unless you set
+it to a special value C.
=item conditioned_lines
@@ -272,21 +293,52 @@
open my $in, '<', $source or die "Can't open $source: $!";
open my $out, '>', "$target.tmp" or die "Can't open $target.tmp: $!";
-if ( !exists $options{makefile} && $target =~ m/makefile$/i ) {
-$options{makefile} = 1;
+if ( !exists $options{file_type}) {
+if ( $target =~ m/makefile$/i ) {
+$options{file_type} = 'makefile';
+}
+elsif ($target =~ m/\.pl$/i ) {
+$options{file_type} = 'perl';
+}
+elsif ($target =~ m/\.[hc]$/ ) {
+$options{file_type} = 'c';
+}
+elsif ($target =~ m/\.pmc$/ ) {
+$options{file_type} = 'pmc';
+}
+} elsif ( $options{file_type} eq 'none' ) {
+delete $options{file_type};
}
-if ( $options{makefile} ) {
-exists $options{comment_type} or $options{comment_type} = '#';
-exists $options{replace_slashes} or $options{replace_slashes} = 1;
-exists $options{conditioned_lines} or $options{conditioned_lines} = 1;
+if ( !exists $options{file_type} && $target =~ m/makefile$/i ) {
+$options{file_type} = 'makefile';
}
+if ( $options{file_type} ) {
+unless ( exists $file_types_info{$options{file_type}} ) {
+die "Unknown file_type '$options{file_type}'";
+}
+unless ( exists $options{comment_type} ) {
+$options{comment_type} = $file_types_info{$options{file_type}}{comment_type};
+}
+if ( $options{file_type} eq 'makefile' ) {
+exists $options{replace_slashes} or $options{replace_slashes} = 1;
+exists $options{conditioned_lines} or $options{conditioned_lines} = 1;
+}
+}
+
if ( $options{comment_type} ) {
-my @comment = ( 'ex: set ro ft=c:',
+my @comment = ( 'ex: set ro',
'DO NOT EDIT THIS FILE',
'Generated by ' . __PACKAGE__ . " from $source" );
+if ($options{file_type}) {
+$comment[0] .= ' ft=' . $file_types_info{$options{file_type}}{vim_ft} . ':';
+}
+else {
+$comment[0] .= ':';
+}
+
if ( $options{c
[perl #57870] List word quoting construct not implemented
# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #57870] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=57870 > >From S05: =item * If the first character is whitespace, the angles are treated as an ordinary "quote words" array literal. < adam & eve > # equivalent to [ 'adam' | '&' | 'eve' ] --- r30183: $ ./perl6 -e '"!" ~~ / < ! !! !!! > /' Syntax error at line 1, near "!! !!! > /" [...] This is more of a PGE feature request than a rakudo bug. Please re-classify as needed.
Re: r14574 - doc/trunk/design/syn
Thanks, guys. I was about to point out the difficulties for editors to get their syntax highlighting and auto-indenting right, but then I remembered that programming languages are (or should be) designed for the convenience of people and not to make the tasks easier for tools working on them. Regards, Ron
[perl #57900] solaris hints no longer work
# New Ticket Created by Andy Dougherty # Please include the string: [perl #57900] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=57900 > There's been a change somewhere in the Configure system such that the solaris.pm hints no longer work. While running perl Configure.pl --cc=gcc --verbose I got the following message: Parrot Version 0.6.4 Configure 2.0 Copyright (C) 2001-2008, The Perl Foundation. Hello, I'm Configure. My job is to poke and prod your system to figure out how to build Parrot. The process is completely automated, unless you passed in the `--ask' flag on the command line, in which case I'll prompt you for a few pieces of info. Since you're running this program, you obviously have Perl 5--I'll be pulling some defaults from its configuration. sh: svn: not found Checking MANIFEST.done. Setting up Configure's default values.done. Setting up installation paths.done. Tweaking settings for miniparrot...skipped. Loading platform and local hints files... [ init::hints::solaris init::hints::local ].done. Finding header files distributed with Parrot..done. Determining what C compiler and linker to use... ./test_3877 Can't exec "./test_3877": No such file or directory at lib/Parrot/Configure/Utils.pm line 85. step inter::progs died during execution: Can't run the test program: No such file or directory at config/init/hints/solaris.pm line 40. at Configure.pl line 71 [ . . . more failures omitted . . . ] Configure.pl actually continues to run, but ends with: During configuration the following steps failed: 07: inter::progs 11: auto::gcc 16: auto::msvc 27: auto::alignptrs 29: auto::sizes 30: auto::byteorder 31: auto::va_ptr 53: auto::snprintf You should diagnose and fix these errors before calling 'make' The problem appears to be in config/init/hints/solaris.pm in the solaris_link_cb function. That function tries to compile and run a simple test.c program. I don't know where the _3877 part of the filename is coming from, but it's confusing the hint file. If the cc_gen function is going to munge the file name, it ought to tell the caller what file name it actually ended up using, so the caller can use it. -- Andy Dougherty [EMAIL PROTECTED]
[perl #57902] [PATCH] PLATFORMS update -- Solaris is broken
# New Ticket Created by Andy Dougherty # Please include the string: [perl #57902] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=57902 > In preparation for the next release, I tried to update the Solaris 8/SPARC status. Unfortunately, it doesn't get past the hints stage. See [perl #57900]. Since I won't have an opportunity to fix it myself before next week, this patch is the best status report I can offer. (Note that the hints failure is harmless in many configurations since the default fall-back guesses often work. Not for me, however.) --- parrot-current/PLATFORMSTue Aug 12 12:43:30 2008 +++ parrot-andy/PLATFORMS Wed Aug 13 10:20:43 2008 @@ -35,8 +35,8 @@ linux-x86_64-gcc4.1.0 4 Y-- Y Y YY/2 ? 20060807 linux-x86_64-gcc4.1.2 8 Y-- Y Y YY ? 20080220 openbsd-zaurus-gcc3.3.5 Y-- Y Y Y? ? 20070309 -sol8-sparc-ccB--- - - -Y/1 ? 20080401 -sol8-sparc-gcc_4.1.0 B--- - - -Y/77 ? 20080401 +sol8-sparc-ccB--- - - - - ? 20080813 +sol8-sparc-gcc_4.1.0 B--- - - - - ? 20080813 sol10-sparc-cc_5.8 BY-- Y Y YY/9 ? 20060807 sol10-sparc-cc_5.9 B4*4 Y-- Y Y YY ? 20080510 sol10-sparc-cc_5.9 B8 Y-- Y Y YY/2 ? 20080518 -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #57900] solaris hints no longer work
On Wednesday 13 August 2008 07:36:45 Andy Dougherty wrote:
> The problem appears to be in config/init/hints/solaris.pm in
> the solaris_link_cb function. That function tries to compile and run a
> simple test.c program. I don't know where the _3877 part of the
> filename is coming from, but it's confusing the hint file.
It's the PID of the program used to compile and run the test.c program. I
added the PID to all of the generated files so that parallel testing will
work without spurious failures.
Does this patch help?
-- c
=== config/init/hints/solaris.pm
==
--- config/init/hints/solaris.pm (revision 30240)
+++ config/init/hints/solaris.pm (local)
@@ -34,9 +34,9 @@
# Can't call cc_build since we haven't set all the flags yet.
# This should suffice for this test.
my $cc_inc = $conf->data->get('cc_inc');
-Parrot::Configure::Utils::_run_command( "$cc -o test test.c",
-'test.cco', 'test.cco' )
-and confess "C compiler failed (see test.cco)";
+Parrot::Configure::Utils::_run_command( "$cc -o test test_$$.c",
+"test_$$.cco", "test_$$.cco" )
+and confess "C compiler failed (see test_$$.cco)";
%gnuc = eval $conf->cc_run() or die "Can't run the test program: $!";
if ( defined $gnuc{__GNUC__} ) {
$link = 'g++';
[perl #57690] [BUG] make headerizer breaks build
On Thu Aug 07 06:20:51 2008, coke wrote: > On Thu, Aug 7, 2008 at 8:21 AM, NotFound <[EMAIL PROTECTED]> wrote: > > On Thu, Aug 7, 2008 at 2:06 PM, Will Coleda <[EMAIL PROTECTED]> wrote: > > > >> make headerizer is trying to operate on files generated by make. Given > >> that it's supposed to be updating the header files based on the C > >> sources, this seems vaguely reasonable, so I would suggest that the > >> problem is actually that you're not supposed to do things in that > >> order. > > > > But make can fail if headerizer has not done his job before, because > > an include'd file may be not updated and thus the file that include it > > fails to compile. This is not theory, is failing now that way. > > headerizer doesn't need the full build. It just needs to have the > generated C files created that it's trying to modify. Those files > don't need to have been compiled. I think we're talking about two different errors now, and maybe we should split this ticket up (how do we do that, if it's even possible?). The original problem that I was trying to talk about, which still exists although it has been masked, is that running "make headerizer" creates problems in the IMCC-related header files. Function prototypes are being included before the necessary data type definitions that are required by them. So, for instance, the prototype for compilers/imcc/symreg.c:add_namespace is included before the definition of IMC_Unit. This probably isn't headerizer's fault, it's more likely the fault of IMCC for being so damn complicated. We could change all the function definitions in the IMCC related files to use "struct _IMC_Unit" instead of "IMC_Unit" which would resolve the problem. Alternatively, we could rearrange the way the header files are ordered/created, and ensure all function prototypes are included after all data type definitions. Neither fix should be too difficult, but I don't know which we would prefer to pursue. --Andrew Whitworth
[perl #57874] Tokens inconsistently require semicolons after them
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #57874]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57874 >
r30183:
$ ./perl6 -e 'class A { # actual newlines
method a { }
method b { }
}' # parses
$ ./perl6 -e 'grammar A {
token a { A }
token b { B }
}' # fails
Statement not terminated properly at line 3, near "token b { "
[...]
It feels odd that what works for methods doesn't for
tokens/rules/regexen, even though it could.
[perl #57858] $/ is de-defined in if blocks in rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #57858]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57858 >
r30183:
$ ./perl6 -e '"yo" ~~ /yo/; say $/' # works
yo
$ ./perl6 -e 'if "yo" ~~ /yo/ { say $/ }' # worksn't
Null PMC access in get_string()
[...]
$ ./perl6 -e '"foo" ~~ /foo/; if 42 { say $/ }'
Null PMC access in get_string()
[...]
[perl #57862] Calling undefined things in a grammar causes a Null PMC access in rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #57862]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57862 >
r30183:
$ ./perl6 -e 'grammar A { token b { c } }; "c" ~~ A::b' # works
$ ./perl6 -e 'grammar A { token b { } }; "c" ~~ A::b' # fails
Unable to find regex 'c'
Null PMC access in invoke()
[...]
To be clear, the bug is not about the failure itself (which is
expected), but about the Null PMC access that follows it.
[perl #57866] Quoting characters in character class ranges makes the character classes not match
# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #57866] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=57866 > r30183: $ ./perl6 -e 'say "b" ~~ /<[a..c]>/' # matches b $ ./perl6 -e 'say "b" ~~ /<["a".."c"]>/' # should match, doesn't Maybe this is a PGE bug -- please reclassify as needed.
Re: [perl #57690] [BUG] make headerizer breaks build
On Tuesday 12 August 2008 15:05:58 Andrew Whitworth via RT wrote: > We could change all the function > definitions in the IMCC related files to use "struct _IMC_Unit" instead > of "IMC_Unit" which would resolve the problem. Alternatively, we could > rearrange the way the header files are ordered/created, and ensure all > function prototypes are included after all data type definitions. > Neither fix should be too difficult, but I don't know which we would > prefer to pursue. The second. If I never see "struct" in a function signature, good. -- c
[perl #46109] [TODO] Where does string get freed in PDB_get_command()?
Solved in r30203, debugger command line buffers are now created and destroyed during creation and destruction of the debugger instance.
[perl #57882] Trying to assign to a class attribute within a class declaration in rakudo makes Parrot segfault
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #57882]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57882 >
r30188:
$ ./perl6 -e 'class A { my $.x = 7; say $.x }' # segfaults
Lexical 'self' not found
[...]
Segmentation fault
Not sure if the error message from Pugs is right either. Should it be
looking for 'self' at this stage? What should the program really do,
print out the variable or disallow statements within a class
declaration but outside methods?
[perl #57868] Quotes are not recognized in literal array alternative matches in rakudo
# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #57868] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=57868 > r30183: $ ./perl6 -e '"\"" ~~ /\"/' # works $ ./perl6 -e '"\"" ~~ / < \" > /' # fails Unable to find regex '' Null PMC access in invoke() [...] This goes for single as well as double quotes. And backslashes: $ ./perl6 -e '"\\" ~~ / < \\ > /' # fails too Unable to find regex '' Null PMC access in invoke() [...]
[perl #57860] $_ is null in if blocks in rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #57860]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57860 >
r30183:
$ ./perl6 -e '.say' # works
$ ./perl6 -e 'if 1 { .say }' # fails
Null PMC access in find_method()
[perl #57864] Calling a token "text" in rakudo makes matching fail
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #57864]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57864 >
r30183:
$ ./perl6 -e 'grammar A { token TOP { }; token foo { d } }; "d"
~~ A::TOP' # works
$ ./perl6 -e 'grammar A { token TOP { }; token text { d } };
"d" ~~ A::TOP' # fails!
Null PMC access in type()
[...]
Same goes for 'rule text' or 'regex test'. My uneducated guess is that
something inside PGE is called 'text' and clashes.
Re: [perl #57882] Trying to assign to a class attribute within a class declaration in rakudo makes Parrot segfault
On Tuesday 12 August 2008 14:17:22 Carl Mäsak wrote:
> # New Ticket Created by "Carl Mäsak"
> # Please include the string: [perl #57882]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=57882 >
>
>
> r30188:
> $ ./perl6 -e 'class A { my $.x = 7; say $.x }' # segfaults
> Lexical 'self' not found
> [...]
> Segmentation fault
This is another double-free abort like the one in RT #57710. The fix is
likely similar to r30149.
-- c
[perl #57884] [PATCH] file_type option for Parrot::Configure::Compiler->genfile
I think this patch is worth considering and I encourage comments from those Parrot developers who are knowledgeable about these "file coda" issues, how they appear in vi and emacs, etc. Since this patch is likely to affect a large number of files, I think we should defer full consideration until after next week's release. But comments are welcome in the meantime. Thank you very much. kid51
Re: [perl #57884] [PATCH] file_type option for Parrot::Configure::Compiler->genfile
On Wednesday 13 August 2008 17:30:39 James Keenan via RT wrote: > I think this patch is worth considering and I encourage comments from > those Parrot developers who are knowledgeable about these "file coda" > issues, how they appear in vi and emacs, etc. > > Since this patch is likely to affect a large number of files, I think we > should defer full consideration until after next week's release. But > comments are welcome in the meantime. +1 to the patch and +1 to waiting a week, though if it went in tonight and we had several days of successful Smolders, I wouldn't object either. -- c
Re: [perl #57900] solaris hints no longer work
On Wed, 13 Aug 2008, Andrew Johnson via RT wrote: > On Wed Aug 13 10:41:22 2008, [EMAIL PROTECTED] wrote: > > > > Does this patch help? > > Almost, you just missed the executable itself (-o arg). This patch > works for me. [patch using test_$$ everywhere] That looks like it should work, but it feels like we're cheating a little bit too. We're relying on special knowledge of how cc_gen works internally. I'd think that a better solution might be to have cc_gen() return what name it actually generated, and then explicitly use that name as an argument to the build and run commands. But for now, this at least should work, which is better than it was! Thanks, -- Andy Dougherty [EMAIL PROTECTED]
[perl #53976] [PATCH] Remove tools/dev/ops_renum.mak
Okay, thanks for getting back to me. Could you read the inline comments I have inserted into Parrot::OpsRenumber::renum_op_map_file()? Do the comments accurately reflect what needs to happen re opcode renumbering both now and at 1.0? You can read them here: http://svn.perl.org/parrot/branches/opsrenum/lib/Parrot/OpsRenumber.pm Thank you very much. kid51
Re: [perl #53976] [PATCH] Remove tools/dev/ops_renum.mak
On Wednesday 13 August 2008 19:39:16 James Keenan via RT wrote: > Okay, thanks for getting back to me. Could you read the inline comments > I have inserted into Parrot::OpsRenumber::renum_op_map_file()? > > Do the comments accurately reflect what needs to happen re opcode > renumbering both now and at 1.0? Yes, they're accurate. -- c
Re: [perl #57868] Quotes are not recognized in literal array alternative matches in rakudo
On Tue, Aug 12, 2008 at 12:02:41PM -0700, Carl Mäsak wrote: > r30183: > $ ./perl6 -e '"\"" ~~ /\"/' # works > $ ./perl6 -e '"\"" ~~ / < \" > /' # fails > Unable to find regex '' > Null PMC access in invoke() > [...] > > This goes for single as well as double quotes. And backslashes: > > $ ./perl6 -e '"\\" ~~ / < \\ > /' # fails too > Unable to find regex '' > Null PMC access in invoke() > [...] PGE doesn't yet support the angle quotes inside of regexes. Shouldn't be too hard to add -- just haven't done it yet (and may decide to wait for some other PGE refactors before implementing it). Pm
Re: [perl #57866] Quoting characters in character class ranges makes the character classes not match
On Tue, Aug 12, 2008 at 12:00:54PM -0700, Carl Mäsak wrote: > # New Ticket Created by "Carl Mäsak" > # Please include the string: [perl #57866] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=57866 > > > > r30183: > $ ./perl6 -e 'say "b" ~~ /<[a..c]>/' # matches > b > $ ./perl6 -e 'say "b" ~~ /<["a".."c"]>/' # should match, doesn't > > Maybe this is a PGE bug -- please reclassify as needed. I can't find anything in S05 that indicates that we should be able to use double quotes as character delimiters inside of the character enumeration. Thus the case of C<< <["a".."c"]> >> is really equivalent to C<< <["ac]> >>, as the C< ".." > range simply collapses to match the double quote (in the same way that C<< <[a..a]> >> would simply match an 'a'). So, I think PGE is following the spec, and the example is incorrect. Pm
