Re: NEWS, PLATFORMS, and make fulltest Results Wanted
On Fri, 2008-05-16 at 22:05 -0700, chromatic wrote: > Parrot 0.6.2 is on schedule for the 20 May release. In preparation, please > gather up any NEWS you find important for your subsystem - Configuration + add step auto::opengl + add step gen::opengl + add step gen::call_list - Miscellaneous + new libraries: OpenGL/GLU/GLUT bindings (small subset working) + new pbc_dump.pl utility: PBC disassembly/source code weaver > and please run make fulltest on every architecture you can find. Running on Debian-testing/i386 (SVK) and Debian-testing/amd64 (git-svn) overnight (they're common I know, but what the heck). > I'd like to concentrate on applying patches and fixing bugs starting tomorrow > (or today, if you think it's Saturday already). I'd like to get 54238 committed, so I can deal with any last OpenGL issues that come up before the release. Plus it makes things a lot less hackish for anyone who might look at my code in this release. :-) -'f
Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
Me Here (>), Carl (>>), Me Here (>>>): >> > What is the point of marking things readonly if you can turn it off? >> >> There are many possible reasons, I think. >> >> * The code that declares the variable readonly might not be available >> to you (compiled to bytecode, fetched by RCP etc), >> * or it might be available but used by other clients which expect the >> variable to be read-only. >> * You might be writing a one-time hack, which can be done the easy way >> by turning off read-only checking. >> * You might be writing test code, which is greatly simplified by your >> just reaching in an changing the damn thing. >> >> In short, I have no problem with _turning off_ read-only checking. >> That, I think, can be done on a suit-yourself basis. >> >> I'm arguing for having read-only checking at compile level (which >> everyone seemingly agrees on), and spec-requiring of a compiler to >> check this (and here opinions divide). > > And that pretty much sums up about half of the traffic on this list. > Speculative considerations of theoretically possible scenarios without > any consideration of whether they would ever actually arise. Or be > useful if they did. The result is a spec so complex that there is > almost no chance of verification against it, even if enough people > understand the intersection between all the speculative what-ifs and > the few more concrete 'will's and 'must be's, to actually come close to > implementing it. I'm sorry you feel that way. On my part, I've always been amazed that the spec documents have been kept current and open in the way the have the last few years. That's a brave way to develop a new language. Naturally, there's always the risk that the spec grows too complex due to a "many chefs" phenomenon, but by and large Larry et al seem to have the opposite effect, distilling the best from the obstreperous opinions of perl6-language into precise spec-lingo. Some on the list want theoretical rigour, some want practicality. The spec often ends up disquieting very few. Maybe you're confusing the discussion here on perl6-language with the spec itself? (If not, do you have any specific places in the spec which you find unclear, overly complex, or unverifiable? I'm sure people would be grateful to hear about them.) > Perl made it's name by adopting the useful, pragmatic parts of other > languages, and leaving out all the abstract, purely theoretical and > only useful to one-legged, six-fingered theologians on wet Wednesdays > in October. > > Sometimes it's a good idea to return to the beginning and ask yourself > why do we want this feature in the first place. Sure! The RO-ness of variables seems a point of agreement between us. It's whether one should be able to switch it off with a pragma that's up for discussion. I made a quick grep through the Perl 5 @INC directories on my computer and found 263 occurrences of "no strict 'refs'" in various CPAN modules, core and non-core alike. Everyone knows that strict 'refs' is a good thing, but some things are possible or just plain simpler without it. I suspect the same will be true of RO variables. >What does adding the ability to mark variables or parameters RO by the > programmer using the language? > > In Perl 5, people are beginning to jump through hoops in order to > achieve encapsulation that cannot be subverted. Giving > module/subroutine users the ability to ignore the authors mutability > annotations makes them worthless. I see where you're coming from: it's the idea that the one who wrote the module you're using knows best how to use that module. It's also the idea that programmers should not be given tools that might be used for bad things. Now tell me this: given that Perl 6 will be a multi-language/changeable environment, wherein people will be able to switch to a language/dialect without the RO restriction if they so choose, and given that at some point, someone _will_ want to change a RO variable (for the reasons I listed above), which one do you prefer, the circumnavigational hackish way through a language with different rules, or a pragma? >What does adding the default assumption that subroutine or method > parameters are RO buy the language implementor? > > This provision could be used my the language implementor to achieve > some extra level of efficiency by allowing them to hoist RO values into > registers; avoid locking of RO values in threaded environments; perform > compile-time constant folding and expression substitutions > (term-rewriting); and similar. The moment you allow the RO annotations > to be overridden at either compile-time or runtime, those optimisations > go out the window. > > In other words, if you allow RO annotations to be overridden, all the > benefits that could accrue from having them go out the window, so you > might as well simplify everyones life and discard them all together. > Now maybe that's the way to go. Historically, the few places where the > readonly attribut
[perl #54312] [PATCH] Implementation of 'infix:=>' for Rakudo
# New Ticket Created by Vasily Chekalkin
# Please include the string: [perl #54312]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=54312 >
Hello.
There is implementation of 'infix:=>' for Rakudo
Index: src/parser/grammar-oper.pg
===
--- src/parser/grammar-oper.pg (revision 27566)
+++ src/parser/grammar-oper.pg (working copy)
@@ -128,6 +128,7 @@
proto infix:<:=> is equiv(infix:<=>) is pasttype('bind') { ... }
proto infix:<::=> is equiv(infix:<=>) { ... }
proto infix:<.=> is equiv(infix:<=>) { ... }
+proto infix:«=>» is equiv(infix:<=>) { ... }
proto infix:<~=> is equiv(infix:<=>) { ... }
proto infix:<+=> is equiv(infix:<=>) { ... }
proto infix:<-=> is equiv(infix:<=>) { ... }
Index: src/classes/Pair.pir
===
--- src/classes/Pair.pir (revision 27566)
+++ src/classes/Pair.pir (working copy)
@@ -137,7 +137,43 @@
.return($S2)
.end
+=item get_string()(vtable method)
+Return the pair in stringified form
+
+=cut
+
+.sub 'get_string' :vtable :method
+$P0 = self.'perl'()
+.return ($P0)
+.end
+
+=head1 Functions
+
+=cut
+
+.namespace
+
+=item infix:=>
+
+Create Pair
+
+=cut
+
+.sub 'infix:=>'
+.param pmc key
+.param pmc value
+.local pmc pair
+
+pair = new 'Perl6Pair'
+setattribute pair, '$!key', key
+setattribute pair, '$!value', value
+
+.return (pair)
+
+#.return (pair)
+.end
+
=back
=cut
Re: Create a sub of a particular type
Jonathan Worthington wrote: Bob Rogers wrote: Jonathan Worthington wrote: Is the idea sane, and is the name of the adverb OK? If so, I'll go ahead and implement it (with changes as needed). The idea is generally sane. It is a good idea. I think I would call it ":class", though. I did ponder that, and then worried that people would confuse it with putting a method into a certain class, which isn't what this is for... :class is better than :type (which carries far too much baggage from type theory, and is used heavily in parrot for other things). Longer, but clearer would be :instanceof. Allison
Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
On 2008 May 17, at 4:10, Carl Mäsak wrote: Whether we're risking the loss of important compiler optimizations by allowing overriding of variable RO-ness is not for me to say, that's up to the compiler writers around here. It seems to me you make it sound worse than it really is, that optimizations can still be made in many cases, and that a programmer who turns off RO stricture simply takes a calculated risk. The compiler should in fact assume that "is ro" is a hard fact; if the programmer chooses to override, on her own head be it. Examples using other existing languages: GHC doesn't compromise its optimization rules just because someone might be using unsafePerformIO (this is in fact quite similar as unsafePerformIO means a presumed read-only expression can vary at runtime) or unsafeCoerce#. gcc doesn't compromise its just because someone might use an asm() to do something naughty where the C / C++ layer can't see it. Etc. I also came to think about this relevant quote from Jamie Zawinski: Java is a remarkable example of how to do it wrong, for many values of "it". -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: NEWS, PLATFORMS, and make fulltest Results Wanted
Hi: I have to put/modify some entries in PLATFORMS, but in the meantime : SunOS netra 5.10 Generic_127127-11 sun4u sparc SUNW,UltraSPARC-IIi-cEngine cc: Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12 parrot: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped make test: All tests successful. Files=583, Tests=11030 Result: PASS make fulltest: # Error: PARROT_JIT_FLAG is set, but interpreter is not JIT_CAPABLE! - :) make perl6: ./perl6 -e"say 'Hello, world.'" Hello, world. gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) parrot: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped make test: t/op/trans.t (Wstat: 256 Tests: 22 Failed: 1) Failed test: 14 Non-zero exit status: 1 Files=581, Tests=11005 Result: FAIL Failed 1/581 test programs. 1/11005 subtests failed. # Failed test 'atan, part 2' # at t/op/trans.t line 380. # got: 'not 0.00ok 1 # ' # expected: 'ok 1 # ' --- This is documented in config/init/hints/solaris.pm make fulltest: # Skipped make perl6: ./perl6 -e"say 'Hello, world.'" Hello, world. # AIX rs6000 3 5 004078CC4C00 (AIX 5.3) C for AIX Compiler, Version 6 --- Not tried (for now) gcc version 4.2.0 (powerpc-ibm-aix5.3.0.0) parrot: 64-bit XCOFF executable or object module not stripped --- compiles but needs manual intervention --- I cant reach make tests, I have some issues with the compiler/linker .. --- needs more work .. Paco On Sat, May 17, 2008 at 7:05 AM, chromatic <[EMAIL PROTECTED]> wrote: > Parrot 0.6.2 is on schedule for the 20 May release. In preparation, please > gather up any NEWS you find important for your subsystem, please report any > PLATFORMS updates, and please run make fulltest on every architecture you > can > find. > > I'd like to concentrate on applying patches and fixing bugs starting > tomorrow > (or today, if you think it's Saturday already). > > -- c >
Re: NEWS, PLATFORMS, and make fulltest Results Wanted
On Sat, 2008-05-17 at 00:17 -0700, Geoffrey Broadwell wrote: > On Fri, 2008-05-16 at 22:05 -0700, chromatic wrote: > > and please run make fulltest on every architecture you can find. > > Running on Debian-testing/i386 (SVK) and Debian-testing/amd64 (git-svn) > overnight (they're common I know, but what the heck). This is the first time that I've done this, and found the results a bit disappointing -- there's no summary results. Just pages and pages of terminal scrollback, which makes it much less useful to do this in "start and forget" mode as I did. Is there already a plan afoot to improve this, or should I create a TODO RT? On a more positive note, the 'make' and 'make perl6' that I ran first worked perfectly. And the triangle spins on both platforms. Of course. :-) -'f
Re: Create a sub of a particular type
From: Allison Randal <[EMAIL PROTECTED]> Date: Sat, 17 May 2008 15:17:27 +0200 Longer, but clearer would be :instanceof. Allison I like this much better, despite the length. There may be other classes and types involved (especially when defining a :multi sub), but the only relevant instance is that of the Sub itself. -- Bob
Re: NEWS, PLATFORMS, and make fulltest Results Wanted
On Saturday 17 May 2008 08:42:13 Geoffrey Broadwell wrote: > > Running on Debian-testing/i386 (SVK) and Debian-testing/amd64 (git-svn) > > overnight (they're common I know, but what the heck). > > This is the first time that I've done this, and found the results a bit > disappointing -- there's no summary results. Just pages and pages of > terminal scrollback, which makes it much less useful to do this in > "start and forget" mode as I did. > > Is there already a plan afoot to improve this, or should I create a TODO > RT? A summary would be nice (though I'm not sure how to do it) -- but remember that it's a big list of make targets, so if one exits with an error, make will exit with that error message. > On a more positive note, the 'make' and 'make perl6' that I ran first > worked perfectly. And the triangle spins on both platforms. Of > course. :-) Of course. -- c
Re: NEWS, PLATFORMS, and make fulltest Results Wanted
mac osx 10.4.11 (macbook 2.16 GHz Intel Core 2 Duo, 1GB RAM) perl -version = v5.10.0 built for darwin-2level -- perl Configure.pl - ok in plain vanilla mode make - ok make test - failed a single test t/examples/library.t (Wstat: 256 Tests: 4 Failed: 1) Failed test: 3 make perl6 - ok hth, Jim Fuller
Re: NEWS, PLATFORMS, and make fulltest Results Wanted
On Saturday 17 May 2008 09:40:08 James Fuller wrote: > mac osx 10.4.11 (macbook 2.16 GHz Intel Core 2 Duo, 1GB RAM) > perl -version = v5.10.0 built for darwin-2level > -- > > perl Configure.pl - ok in plain vanilla mode > > make - ok > > make test - failed a single test > >t/examples/library.t (Wstat: 256 Tests: 4 Failed: > 1) Failed test: 3 Can you run prove -v t/examples/library.t and paste the whole output into a message? The diagnostics in particular will be interesting. -- c
Re: NEWS, PLATFORMS, and make fulltest Results Wanted
sudo prove -v t/examples/library.t t/examples/library.. 1..4 ok 1 - examples/library/getopt_demo.pir ok 2 - examples/library/md5sum.pir 7.4 Failed to load libpcre current instr.: 'parrot;PCRE;init' pc 99 (library/pcre.pir:106) called from Sub 'parrot;PCRE;main' pc 244 (examples/library/pcre.pir:39) not ok 3 - examples/library/pcre.pir # Failed test 'examples/library/pcre.pir' # at t/examples/library.t line 67. # got: '' # expected: 'asdf =~ /as/ # 1 match(es): # as # ' not ok 4 - ncurses_life.pir # TODO ncurses_life.pir not testable yet # Failed (TODO) test 'ncurses_life.pir' # at t/examples/library.t line 77. # Looks like you failed 1 test of 4. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/4 subtests Test Summary Report --- t/examples/library.t (Wstat: 256 Tests: 4 Failed: 1) Failed test: 3 Non-zero exit status: 1 Files=1, Tests=4, 1 wallclock secs ( 0.01 usr 0.00 sys + 0.19 cusr 0.11 csys = 0.31 CPU) Result: FAIL cheers, J On Sat, May 17, 2008 at 6:52 PM, chromatic <[EMAIL PROTECTED]> wrote: > On Saturday 17 May 2008 09:40:08 James Fuller wrote: > >> mac osx 10.4.11 (macbook 2.16 GHz Intel Core 2 Duo, 1GB RAM) >> perl -version = v5.10.0 built for darwin-2level >> -- >> >> perl Configure.pl - ok in plain vanilla mode >> >> make - ok >> >> make test - failed a single test >> >>t/examples/library.t (Wstat: 256 Tests: 4 Failed: >> 1) Failed test: 3 > > Can you run prove -v t/examples/library.t and paste the whole output into a > message? The diagnostics in particular will be interesting. > > -- c >
[perl #54374] [BUG]: Warning being emitted when harness runs t/steps/inter_libparrot-*.t
# New Ticket Created by James Keenan
# Please include the string: [perl #54374]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=54374 >
While running 'perl Configure.pl --test', I get the following warning
on each of the tests in t/steps/inter_libparrot-*.t:
t/steps/inter_libparrot-01.8/11 Use of
uninitialized value $_[0] in join or string at /usr/local/lib/
perl5/5.10.0/File/Spec/Unix.pm line 81.t/steps/
inter_libparrot-01.ok
There are 9 such test files all together. I do not get the warning
when I run them individually or collectively via 'prove -v t/steps/
inter_libparrot*.t'.
A recent change to config/inter/libparrot.pm may be the cause; see
attached.
Index: config/inter/libparrot.pm
===
--- config/inter/libparrot.pm (revision 25763)
+++ config/inter/libparrot.pm (revision 27445)
@@ -41,6 +41,18 @@
$parrot_is_shared = 0 unless $conf->data->get('has_dynamic_linking');
+# Parrot can't necessarily handle a pre-existing installed shared
+# libparrot.so. At this point, we don't know the actual name
+# of the shared parrot library. However, 'libparrot.so' will catch
+# at least some of the problems.
+# RT#52288: the check for old_versions should be improved
+my $old_version
+= File::Spec->catfile($conf->data->get('libdir'), 'libparrot.so');
+if (-e $old_version) {
+warn("\nWarning: Building a shared parrot library may conflict " .
+ "with your previously-installed $old_version\n");
+}
+
if (
$conf->options->get('ask')
&&
I will try to look into this.
kid51
[perl #54374] [BUG]: Warning being emitted when harness runs t/steps/inter_libparrot-*.t
The tests needed a bit more information to adapt to the change described
above in config/inter/libparrot.pm.
The patch attached fixes the tests. If there is no objection I'll apply
it within 24 hours.
Index: t/steps/inter_libparrot-02.t
===
--- t/steps/inter_libparrot-02.t(revision 27599)
+++ t/steps/inter_libparrot-02.t(working copy)
@@ -5,10 +5,11 @@
use strict;
use warnings;
-use Test::More tests => 10;
+use Test::More tests => 15;
use Carp;
use lib qw( lib t/configure/testlib );
use_ok('config::init::defaults');
+use_ok('config::init::install');
use_ok('config::inter::libparrot');
use Parrot::Configure;
use Parrot::Configure::Options qw( process_options );
@@ -24,6 +25,7 @@
my $conf = Parrot::Configure->new;
test_step_thru_runstep( $conf, q{init::defaults}, $args );
+test_step_thru_runstep( $conf, q{init::install}, $args );
my $pkg = q{inter::libparrot};
@@ -31,7 +33,7 @@
$conf->options->set( %{$args} );
my ( $task, $step_name, $step);
-$task= $conf->steps->[1];
+$task= $conf->steps->[-1];
$step_name = $task->step;
$step = $step_name->new();
Index: t/steps/inter_libparrot-06.t
===
--- t/steps/inter_libparrot-06.t(revision 27599)
+++ t/steps/inter_libparrot-06.t(working copy)
@@ -5,10 +5,11 @@
use strict;
use warnings;
-use Test::More tests => 11;
+use Test::More tests => 16;
use Carp;
use lib qw( lib t/configure/testlib );
use_ok('config::init::defaults');
+use_ok('config::init::install');
use_ok('config::inter::libparrot');
use Parrot::Configure;
use Parrot::Configure::Options qw( process_options );
@@ -24,6 +25,7 @@
my $conf = Parrot::Configure->new;
test_step_thru_runstep( $conf, q{init::defaults}, $args );
+test_step_thru_runstep( $conf, q{init::install}, $args );
my $pkg = q{inter::libparrot};
@@ -31,7 +33,7 @@
$conf->options->set( %{$args} );
my ( $task, $step_name, $step);
-$task= $conf->steps->[1];
+$task= $conf->steps->[-1];
$step_name = $task->step;
$step = $step_name->new();
Index: t/steps/inter_libparrot-03.t
===
--- t/steps/inter_libparrot-03.t(revision 27599)
+++ t/steps/inter_libparrot-03.t(working copy)
@@ -5,10 +5,11 @@
use strict;
use warnings;
-use Test::More tests => 11;
+use Test::More tests => 16;
use Carp;
use lib qw( lib t/configure/testlib );
use_ok('config::init::defaults');
+use_ok('config::init::install');
use_ok('config::inter::libparrot');
use Parrot::Configure;
use Parrot::Configure::Options qw( process_options );
@@ -24,6 +25,7 @@
my $conf = Parrot::Configure->new;
test_step_thru_runstep( $conf, q{init::defaults}, $args );
+test_step_thru_runstep( $conf, q{init::install}, $args );
my $pkg = q{inter::libparrot};
@@ -31,7 +33,7 @@
$conf->options->set( %{$args} );
my ( $task, $step_name, $step);
-$task= $conf->steps->[1];
+$task= $conf->steps->[-1];
$step_name = $task->step;
$step = $step_name->new();
Index: t/steps/inter_libparrot-07.t
===
--- t/steps/inter_libparrot-07.t(revision 27599)
+++ t/steps/inter_libparrot-07.t(working copy)
@@ -5,10 +5,11 @@
use strict;
use warnings;
-use Test::More tests => 13;
+use Test::More tests => 18;
use Carp;
use lib qw( lib t/configure/testlib );
use_ok('config::init::defaults');
+use_ok('config::init::install');
use_ok('config::inter::libparrot');
use Parrot::Configure;
use Parrot::Configure::Options qw( process_options );
@@ -25,6 +26,7 @@
my $conf = Parrot::Configure->new;
test_step_thru_runstep( $conf, q{init::defaults}, $args );
+test_step_thru_runstep( $conf, q{init::install}, $args );
my $pkg = q{inter::libparrot};
@@ -32,7 +34,7 @@
$conf->options->set( %{$args} );
my ( $task, $step_name, $step);
-$task= $conf->steps->[1];
+$task= $conf->steps->[-1];
$step_name = $task->step;
$step = $step_name->new();
Index: t/steps/inter_libparrot-04.t
===
--- t/steps/inter_libparrot-04.t(revision 27599)
+++ t/steps/inter_libparrot-04.t(working copy)
@@ -5,10 +5,11 @@
use strict;
use warnings;
-use Test::More tests => 11;
+use Test::More tests => 16;
use Carp;
use lib qw( lib t/configure/testlib );
use_ok('config::init::defaults');
+use_ok('config::init::install');
use_ok('config::inter::libparrot');
use Parrot::Configure;
use Parrot::Configure::Options qw( process_options );
@@ -24,6 +25,7 @@
my $conf = Parrot::Configure->new;
test_step_thru_runstep( $conf, q{init::defaults}, $args );
+test_step_thru_runstep( $conf, q{init::install}, $args );
my $pkg = q{inter::libparrot};
@@ -31,7 +33,7 @@
$conf->options->set( %{$args} );
my ( $task, $
[perl #36019] [TODO] readline support
On Sat May 28 03:12:45 2005, leo wrote: > We already have some interactive parrot programs and applications. > Adding readline support for these would vastly improve their usability. This ticket strikes me as being too nebulous to ever be resolvable on its own merits. I vote to close it. Pm
[svn:perl6-synopsis] r14542 - doc/trunk/design/syn
Author: larry Date: Sat May 17 14:37:37 2008 New Revision: 14542 Modified: doc/trunk/design/syn/S05.pod Log: Clarifications to how tied longest tokens are handled under LTM Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podSat May 17 14:37:37 2008 @@ -14,9 +14,9 @@ Maintainer: Patrick Michaud <[EMAIL PROTECTED]> and Larry Wall <[EMAIL PROTECTED]> Date: 24 Jun 2002 - Last Modified: 7 May 2008 + Last Modified: 18 May 2008 Number: 5 - Version: 78 + Version: 79 This document summarizes Apocalypse 5, which is about the new regex syntax. We now try to call them I rather than "regular @@ -2094,8 +2094,14 @@ expressions). A logical alternation using C<|> then takes two or more of these lists and dispatches to the alternative that matches the longest token prefix. This may or may not be the alternative -that comes first lexically. (However, in the case of a tie between -alternatives, the textually earlier alternative does take precedence.) +that comes first lexically. + +However, if two alternatives match at the same length, the tie is +broken by one of two methods. If the alternatives are in different +grammars, standard MRO (method resolution order) determines which +one to try first. If the alternatives are in the same grammar, the +textually earlier alternative takes precedence. (If a grammar's rules +are defined in more than one file, the results are undefined.) This longest token prefix corresponds roughly to the notion of "token" in other parsing systems that use a lexer, but in the case of Perl @@ -2150,6 +2156,11 @@ Greedy quantifiers and character classes do not terminate a token pattern. Zero-width assertions such as word boundaries are also okay. +Because such assertions can be part of the token, the lexer engine must +be able to recover from the failure of such an assertion and backtrack +to the next best token candidate, which might be the same length or shorter, +but can never be longer than the current candidate. + For a pattern that starts with a positive lookahead assertion, the assertion is assumed to be more specific than the subsequent pattern, so the lookahead's pattern is treated as the longest token;
[perl #37324] [TODO] build - root.in makefile split-up
On Sat Jan 12 01:22:42 2008, bernhard wrote: > James Keenan via RT schrieb: > > On Sun Oct 02 05:22:08 2005, [EMAIL PROTECTED] wrote: > > > >> config/gen/makefiles/root.in already weighs in at 1581 lines. It needs > >> to be divided up into smaller files that are combined when Configure is > >> run. > >> > > Apart from the fact that it's a PITA to edit a file which, since Oct > > 2005, has swelled to 2258 lines, is there a strong reason to split > > root.in up into smaller components? > > root.in can probably be improved, but I see no need to split it up, just > because > it is large. I agree with earlier posters -- I don't see a burning need to split root.in unless/until we have a different Makefile setup for parrot. So, I vote that we give a few days for responses and then either close or suspend the ticket. Pm
[perl #38191] [TODO] build - generate META.yml
On Fri Jan 11 13:16:00 2008, [EMAIL PROTECTED] wrote: > On Sun Jan 08 21:12:48 2006, [EMAIL PROTECTED] wrote: > > But wait until we've figured out exactly wait we want to list for CPAN > > to index. Perhaps we can use/steal Module::Build's logic. > > Joshua: I see that we've had a META.yml file in the distro since you > implemented it in Jan 2006. Is there anything more we should do? > > Otherwise, can we close this ticket? I vote to close the ticket -- yes, we have META.yml, and at present it doesn't seem to be difficult for the release managers and others to maintain it manually. Pm
[perl #38191] [TODO] build - generate META.yml
Resolved per pmichaud's comment.
[perl #37927] [TODO] build - progs from env vars
On Sat May 17 14:41:38 2008, pmichaud wrote: > On Sun Feb 24 16:59:34 2008, [EMAIL PROTECTED] wrote: > > > > What are the other 'utilities' that you were referring to? Which of > > them would normally -- for some definition of 'normally' -- be set in > > ENV variables? > > There hasn't been much response on this ticket since 2005, I vote that > we close it. > Agreed. There was no response to the question I posed in February. Will close. kid51
[perl #39313] [TODO] or [BUG] improve PMC compiler
No action has occurred on this ticket since 2006, and I suspect it's obsoleted by improvements to PCCMETHOD and pmc2c anyway. I vote to close the ticket. Pm
[perl #36019] [TODO] readline support
On Sat May 17 14:36:08 2008, pmichaud wrote: > On Sat May 28 03:12:45 2005, leo wrote: > > We already have some interactive parrot programs and applications. > > Adding readline support for these would vastly improve their usability. > > This ticket strikes me as being too nebulous to ever be resolvable on > its own merits. I vote to close it. > Agreed. Given that we've put quite a bit of effort into config/auto/readline.pm in recent months, I think we can say that any readline-related issues should be handled in new, more focused tickets. Will close. kid51
[perl #39430] Method cache not always invalidated
On Mon Jun 12 16:30:13 2006, jonathan wrote: > Both Parrot_store_global and store_sub call Parrot_invalidate_method_cache, > however the versions of these that take keys (Parrot_store_global_p and > store_sub_p) fail to do so. Is this ticket still relevant after the pdd15oo changes incorporated in late 2007? If the ticket is not relevant, let's close it. Pm
[perl #39855] [CAGE] configuration: define MIN/MAX macros for all integral typedefs
On Mon Jul 17 11:59:47 2006, chip wrote: > It's great to have INTVAL and UINTVAL, but without MAX_INTVAL it's kind of > hard to work with them in some respects. All integral typedefs should have > min/max macros. Syntax not a big deal, it can be fixed later, just don't > break anything when introducing them. Nothing has happened on this ticket since it was introduced in 2006. Do we need MIN/MAX macros? If so, why, or where do we expect them to be used? Pm
[perl #39990] External API and C Strings
On Thu Jul 27 12:05:41 2006, leo wrote: > Am Donnerstag, 27. Juli 2006 20:27 schrieb chromatic: > > When embedding or extending Parrot through the external API, most of > the > > strings go into and come out of Parrot as the type Parrot_STRING. > This is > > painful and somewhat tedious from C (where these are usually -- but > not > > always -- C strings already), and it has implications for memory > management > > (do you use const_string()? Create a new Parrot_STRING through a > > function?). > > > > Where possible, the external API should take and receive C strings. > > [...] > > I was proposing the following already: > > * STRING arguments use a String PMC > - gets rid of one extra indirection in the String PMC > - removes a lot of duplicate code with STRING vs. (String) PMC args > - all our dynamic HLLs except Perl6 don't have a notion of 'str' > anyway > and are using a *String PMC > > * the current S register type becomes a C-string > - this is matching Perl6 'str' type (a buffer of 'short' ints) - > hopefully > - it's nicely covered and optimizable by libc's string functions Some problems/questions on this ticket (which admittedly is very old by now)... * A number of Parrot's string-related opcodes currently only work on string registers. The 'downcase' opcode comes to mind, but there are quite a few others. So, we either have to allow string registers to contain unicode, or we have provide pmc-capable versions of all string operations. * C-strings are null terminated, whereas Perl6 'str' type is not. * I don't know how this ticket plays with the recent "strings pdd" (PDD28). Let's abandon this ticket or incorporate its items into the strings pdd dicussions/documentation. Or both. Pm
[perl #41132] [BUG] Segfault in Parrot_call_sub_ret_int
Is this ticket still relevant? There hasn't been any activity on it since Dec 2006, and if there was a problem we probably would've uncovered it by now. Pm
[perl #41619] [PATCH] add add_attr, rem_attr, and rem_attr_str vtable methods
On Sun Mar 16 09:20:55 2008, [EMAIL PROTECTED] wrote: > On Mon Mar 12 05:40:14 2007, [EMAIL PROTECTED] wrote: > > I'm still working on my use case, but it appears the new MetaClass PMC > > (src/pmc/metaclass.pmc) could use this vtable method as well; currently it > > only has an add_attribute PMETHOD. > > > > Alek, Are you still planning work on this patch? (No activity in thread > for > 1 year.) Could you give us an update on the issues at hand? No activity on this ticket since Mar 2007. Beyond that, I suspect it's been made obsolete by the pdd15oo changes from November 2007. I vote to close it. Pm
[perl #41620] [PATCH] change opcode syntax for label arguments
On Sun Mar 16 09:24:16 2008, [EMAIL PROTECTED] wrote: > On Sun Feb 25 20:12:58 2007, [EMAIL PROTECTED] wrote: > > This patch changes the , , and > INT> syntax in opcodes to , , and > LABEL>, respectively. > > There's been no activity in this thread for > 1 year. While the patch > did apply successfully, that was in a branch which has long since been > removed. I doubt it was ever applied to trunk. > > Can someone who is knowledgeable about the ops re-evaluate this patch? Since there's still no activity, I think this ticket can be closed. But I think chromatic should be the one to make the call here. Thanks, Pm
[perl #42393] [TODO] regex - FIXME items in languages/regex/lib/Regex/Grammar.y
On Sat Sep 01 08:32:08 2007, bernhard wrote: > On Mo. 09. Apr. 2007, 08:16:36, ptc wrote: > > There are two FIXME items in languages/regex/lib/Regex/Grammar.y. > > Your task, should you choose to accept it, is to work out why the > > lines of code need to be fixed, and then to fix them. > > In r18166 Grammar.y was renamed to Grammar.yp. > The relevant lines are marked with '# RT#42393!' > I have no idea what should be fixed there. Nothing has happened on this ticket in over a year; plus I don't know that languages/regex is being used or maintained. I vote to remove languages/regex, either for the May 2008 release or soon thereafter. Pm
[perl #42692] install error
There's been no activity on this ticket since Apr 2007, I vote we close it as being abandoned. Pm
[perl #42938] [BUG] allocation failures in res_lea.c
Is this ticket still relevant/important in light of the pdd28 strings PDD? If not, I think we can close it. Pm
[perl #54380] PGE <.rule> still generates captures
# New Ticket Created by Kevin Tew
# Please include the string: [perl #54380]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=54380 >
token identifier {
<.identifier_nondigit> [ <.identifier_nondigit> | <.digit> ]*
{*}
}
token identifier_nondigit {
<.alpha> | [_] | <.universal_character_name>
}
=> PMC 'C99::CPP::Grammar' => "SPI_H" @ 415 {
<> =>
ResizablePMCArray (size:5) [
PMC
'C99::CPP::Grammar' => "S" @ 415 {
<> =>
PMC 'C99::CPP::Grammar' => "S" @ 415
},
PMC
'C99::CPP::Grammar' => "P" @ 416 {
<> =>
PMC 'C99::CPP::Grammar' => "P" @ 416
},
PMC
'C99::CPP::Grammar' => "I" @ 417 {
<> =>
PMC 'C99::CPP::Grammar' => "I" @ 417
},
PMC
'C99::CPP::Grammar' => "_" @ 418,
PMC
'C99::CPP::Grammar' => "H" @ 419 {
<> =>
PMC 'C99::CPP::Grammar' => "H" @ 419
}
]
}
[perl #42987] parrot coredump during make smoke on HPUX 11.23 (Itanium)
This ticket is over a year old -- and I don't know that we have a way to test it. Shall we close it and let someone reopen/resubmit if it's observed again? Pm
Re: NEWS, PLATFORMS, and make fulltest Results Wanted
chromatic wrote: Parrot 0.6.2 is on schedule for the 20 May release. In preparation, please gather up any NEWS you find important for your subsystem, please report any PLATFORMS updates, and please run make fulltest on every architecture you can find. Here's the one non-codingstd failure I got when running 'make fulltest' on Linux/386 at r27599 today. IIRC, this was the very first time I ever ran make fulltest, so judge results accordingly. make testj make[1]: Entering directory `/home/jimk/work/parrot' Compiling with: xx.c cc -I./include -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -fvisibility=hidden -maccumulate-outgoing-args -W -Wall -Waggregate-return -Wbad-function-cast -Wc++-compat -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdeclaration-after-statement -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wimport -Winit-self -Winline -Winvalid-pch -Wmain -Wmissing-braces -Wmissing-declarations -Wmissing-field-initializers -Wno-missing-format-attribute -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs -Wnonnull -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wvariadic-macros -Wwrite-strings -DHAS_GETTEXT -g -DHAS_JIT -DI386 -DHAVE_COMPUTED_GOTO -fPIC -I. -o xx.o -c xx.c [snip] /usr/local/bin/perl t/harness --gc-debug --running-make-test -j --runcore-tests [snip] t/compilers/imcc/syn/regressions. # Failed test 'cannot constant fold div by 0' # at t/compilers/imcc/syn/regressions.t line 19. # Exited with error code: [SIGNAL 8] # Received: # # Expected: # ok 1 - caught div_i_ic_ic exception # ok 2 - caught div_n_nc_nc exception # # Looks like you failed 1 test of 3. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/3 subtests
Re: [perl #42393] [TODO] regex - FIXME items in languages/regex/lib/Regex/Grammar.y
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 68.237.16.164 Patrick R. Michaud via RT wrote: > plus I don't know > that languages/regex is being used or maintained. I vote to remove > languages/regex, either for the May 2008 release or soon thereafter. > > FWIW, svn status -v languages/regex/ suggests that François, Barney and chromatic have worked in this tree in the last year. So it's getting some degree of attention. kid51
Re: NEWS, PLATFORMS, and make fulltest Results Wanted
chromatic wrote: Parrot 0.6.2 is on schedule for the 20 May release. In preparation, please gather up any NEWS you find important for your subsystem, please report any PLATFORMS updates, and please run make fulltest on every architecture you can find. Running 'make fulltest' on Darwin/ppc (Mac OS X 10.4), during the 'make testj' part, I got an indefinite hang on t/compilers/pge/pge_examples.t I then called: /usr/local/bin/perl t/harness --gc-debug --running-make-test -j --runcore-test ... and got the same indefinite hang -- even thought the test passes 'prove' when run by itself: t/compilers/pge/pge_examples.1/2 ^C [parrot] 519 $ prove -v t/compilers/pge/pge_examples.tt/compilers/pge/pge_examples..1..2 ok 1 - This made Parrot m4 fail ok 2 - parse FASTA ok All tests successful. Files=1, Tests=2, 3 wallclock secs ( 0.03 usr 0.01 sys + 1.82 cusr 0.43 csys = 2.29 CPU) Result: PASS kid51
Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
"Carl Mäsak" wrote: > ] Oh, but it gets even better: it turns out they didn't really have to > ] sneak in through native code anyway, at least as far as the JVM is > ] concerned, since the JVM treats final variables as always writable > to ] the class they're defined in! There's no special case for > ] constructors: they're just always writable. The javac compiler, on > ] the other hand, pretends that they're only assignable once, either > in ] static init code for static finals or once per constructor for > ] instance variables. It also will optimize access to finals, despite > ] the fact that it's actually unsafe to do so. I'm pleased to note that you made my point for me. Sure, you can sneak in under the covers of the JVM and compromise the immutability of its final data. But you do have to sneak in. And when you do, and things go belly up in interesting ways, or worse continue to run but produce mysteriously wrong output, don't go running to blame either the Java spec or the JVM. Their writers made their optimisations, and the proofs of correctness of those optimisations, and proof of correctness of the entire system, based upon the specification of final. You hack it. Your problem. But, if you add *is ro* to the P6 spec and then specify a way for users to ignore or turn it off, and you render it entirely worthless. Indeed it's worse than worthless because it is extra complication for no benefit. If it doesn't allow the compiler writeres to make any extra assumptions, it's just tying up space in symbol tables, consuming cycles in the parser, and most damningly, mindspace in the spec and users. If you add it to the spec. Mean it. If you don't mean it, don't add it. If you mean it, but it doesn't initially get implemented that's fine. Someday it might and someday we might benefit from it. Add it to the spec whilst offering a way to ignore it and you've wasted everyones time. b. --
[perl #54376] Make runs after make clean
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #54376] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=54376 > --- osname= linux osvers= 2.6.24-arch arch= i686-linux cc= cc --- Flags: category=core severity=critical ack=no --- After a make realclean, make runs and builds a lot of files, failing more or less in the middle of the compiling step. Probably the makefile should be removed after make realclean, so this does not happens. Or, in other hand, create a dummy makefile asking the user to run configure. CHeers Alberto --- Summary of my parrot 0.6.1 (r27552) configuration: configdate='Sat May 17 20:24:36 2008 GMT' Platform: osname=linux, archname=i686-linux jitcapable=1, jitarchname=i386-linux, jitosname=LINUX, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl Compiler: cc='cc', ccflags=' -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -fvisibility=hidden -maccumulate-outgoing-args -W -Wall -Waggregate-return -Wbad-function-cast -Wc++-compat -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdeclaration-after-statement -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wimport -Winit-self -Winline -Winvalid-pch -Wlogical-op -Wmain -Wmissing-braces -Wmissing-declarations -Wmissing-field-initializers -Wno-missing-format-attribute -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs -Wnonnull -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-s hadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wvariadic-macros -Wwrite-strings -DHAS_GETTEXT', Linker and Libraries: ld='cc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp -lreadline -lpcre -lglut -lGLU -lGL -lcrypto ' Dynamic Linking: share_ext='.so', ld_share_flags='-shared -O2 -L/usr/local/lib -fPIC', load_ext='.so', ld_load_flags='-shared -O2 -L/usr/local/lib -fPIC' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=1234, nv=double, numvalsize=8, doublesize=8 --- Environment: HOME =/home/ambs LANG =en_US.utf8 LANGUAGE (unset) LC_ALL =en_GB.ISO-8859-1 LC_COLLATE =C LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH =/home/ambs/kwiki/bin/:/usr/ccache:/usr/local/Adobe/Acrobat7.0/bin/:/bin:/usr/bin:/sbin:/usr/sbin:/usr/X11R6/bin:/opt/bin:/opt/mozilla/bin:/opt/texlive/bin:/home/ambs/bin:/usr/local/j2re1.4.1/bin:/opt/mozilla/bin/:/usr/local/bin:/home/ambs/TnT/tnt/ SHELL =/bin/bash
[svn:parrot-pdd] r27608 - trunk/docs/pdds/draft
Author: rgrjr Date: Sat May 17 20:04:52 2008 New Revision: 27608 Modified: trunk/docs/pdds/draft/pdd19_pir.pod Log: [DOCS] * docs/pdds/draft/pdd19_pir.pod: + Expand the documentation of :immediate by hijacking the revcomp.pir example, which illustrates a hidden feature. Expand :postcomp slightly to match. + Also refine the descriptions of :main, :init, and :load. Modified: trunk/docs/pdds/draft/pdd19_pir.pod == --- trunk/docs/pdds/draft/pdd19_pir.pod (original) +++ trunk/docs/pdds/draft/pdd19_pir.pod Sat May 17 20:04:52 2008 @@ -387,20 +387,23 @@ =item :main -Define "main" entry point to start execution. If multiple subroutines -are marked as B<:main>, the B marked subroutine is entered. +Define "main" entry point to start execution. If multiple subroutines are +marked as B<:main>, the B marked subroutine is used. Only the first +file loaded or compiled counts; subs marked as B<:main> are ignored by the +B op. =item :load -Run this subroutine during the B opcode. -If multiple subs have the B<:load> pragma, the subs are -run in source code order. +Run this subroutine when loaded by the B op (i.e. neither in +the initial program file nor compiled from memory). This is complementary to +what B<:init> does (below); to get both behaviours, use B<:init :load>. If +multiple subs have the B<:load> pragma, the subs are run in source code order. =item :init Run the subroutine when the program is run directly (that is, not loaded as a -module). This is different from B<:load>, which runs a subroutine when a -library is being loaded. To get both behaviours, use B<:init :load>. +module), including when it is compiled from memory. This is complementary to +what B<:load> does (above); to get both behaviours, use B<:init :load>. =item :anon @@ -415,33 +418,60 @@ =item :immediate -This subroutine is executed immediately after being compiled. (Analagous to -C in perl5.) +Execute this subroutine immediately after being compiled, which is analogous +to C in Perl 5. -=item :postcomp - -Same as C<:immediate>, except that the subroutine is B executed when -the compilation of the file that contains the subroutine is triggered by -a C instruction in another file. +In addition, if the sub returns a PMC value, that value replaces the sub in +the constant table of the bytecode file. This makes it possible to build +constants at compile time, provided that (a) the generated constant can be +computed at compile time (i.e. doesn't depend on the runtime environment), and +(b) the constant value is of a PMC class that supports saving in a bytecode +file [need a freeze/thaw reference]. + +For example, C contains the following (slightly +abbreviated) definition: + +.sub tr_00_init :immediate + .local pmc tr_array + tr_array = new 'FixedIntegerArray' + tr_array = 256 + ## [code to initialize tr_array omitted.] + .return (tr_array) +.end -An example. File C contains: - - .sub main - load_bytecode "foo.pir" - .end +This code is run at compile time, and the returned C is stored +in the bytecode file in place of the sub. Other subs may then do: -The file C contains: + .const .Sub tr_00 = 'tr_00_init' - .sub foo :immediate - print "42" - .end +in order to fetch the constant. - .sub bar :postcomp - print "43" - .end +=item :postcomp -When executing file C, it will execute both C and C. -However, when executing the file C, only C will be executed. +Execute immediately after being compiled, but only if the subroutine is in the +initial file (i.e. not in PIR compiled as result of a C +instruction from another file). + +As an example, suppose file C contains: + +.sub main +load_bytecode "foo.pir" +.end + +and the file C contains: + +.sub foo :immediate +print "42" +.end + +.sub bar :postcomp +print "43" +.end + +Executing C will run both C and C. On the other hand, +executing C will run only C. If C is compiled to +bytecode, only C will be run, and loading C will not run either +C or C. =item :method
Licensing issues of translated sample code
I am considering adding PIR translations (and possibly other language
translations) of the OpenGL Programming Guide ("Red Book") sample code
to examples/opengl/ in the Parrot repository. The original C version of
this code is under the seemingly free license at the bottom of this
message. What do I need to do to handle this properly?
My working assumption is that I can copy the SGI license into a file in
the directory named something obvious like "ORIGINAL_LICENSE", and head
each one of my files with a notice that says:
=head1 COPYRIGHT
This file is a translation of sample code Copyright (c) 1993-2003,
Silicon Graphics, Inc. For details of the original code's license,
please see the file ORIGINAL_LICENSE in this directory. This
translation is Copyright (C) 2008 The Perl Foundation.
=cut
Would this be acceptable?
-'f
### ORIGINAL LICENSE FOLLOWS
/*
* Copyright (c) 1993-2003, Silicon Graphics, Inc.
* All Rights Reserved
*
* Permission to use, copy, modify, and distribute this software for any
* purpose and without fee is hereby granted, provided that the above
* copyright notice appear in all copies and that both the copyright
* notice and this permission notice appear in supporting documentation,
* and that the name of Silicon Graphics, Inc. not be used in
* advertising or publicity pertaining to distribution of the software
* without specific, written prior permission.
*
* THE MATERIAL EMBODIED ON THIS SOFTWARE IS PROVIDED TO YOU "AS-IS" AND
* WITHOUT WARRANTY OF ANY KIND, EXPRESS, IMPLIED OR OTHERWISE,
* INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR
* FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL SILICON
* GRAPHICS, INC. BE LIABLE TO YOU OR ANYONE ELSE FOR ANY DIRECT,
* SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND,
* OR ANY DAMAGES WHATSOEVER, INCLUDING WITHOUT LIMITATION, LOSS OF
* PROFIT, LOSS OF USE, SAVINGS OR REVENUE, OR THE CLAIMS OF THIRD
* PARTIES, WHETHER OR NOT SILICON GRAPHICS, INC. HAS BEEN ADVISED OF
* THE POSSIBILITY OF SUCH LOSS, HOWEVER CAUSED AND ON ANY THEORY OF
* LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE POSSESSION, USE
* OR PERFORMANCE OF THIS SOFTWARE.
*
* US Government Users Restricted Rights
* Use, duplication, or disclosure by the Government is subject to
* restrictions set forth in FAR 52.227.19(c)(2) or subparagraph
* (c)(1)(ii) of the Rights in Technical Data and Computer Software
* clause at DFARS 252.227-7013 and/or in similar or successor clauses
* in the FAR or the DOD or NASA FAR Supplement. Unpublished - rights
* reserved under the copyright laws of the United States.
*
* Contractor/manufacturer is:
* Silicon Graphics, Inc.
* 1500 Crittenden Lane
* Mountain View, CA 94043
* United State of America
*
* OpenGL(R) is a registered trademark of Silicon Graphics, Inc.
*/
[perl #54384] [BUG] split opcode gives "failed assertion" when source string is null
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #54384] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=54384 > The split opcode gives "failed assertion 's'" when given a null string argument. Perhaps it should pretend it got the null string, or at least throw a more "normal" exception. Test case exposing bug: $ cat y.pir .sub main :main $S0 = 'hello world' $P0 = split ' ', $S0 $I0 = elements $P0 say $I0 # 2 null $S0 $P0 = split ' ', $S0 # KABOOM $I0 = elements $P0 say $I0 .end $ ./parrot y.pir 2 src/string.c:802: failed assertion 's' Backtrace - Obtained 16 stack frames (max trace depth is 32). (unknown) Parrot_confess string_length string_split Parrot_split_p_sc_s [...lines deleted for brevity...] Aborted $ Pm
