With Parrot r43112 and Rakudo 8dc189 installed, after downloading and building code by the following steps:
$ git clone git://github.com/masak/gge.git $ cd gge $ export PERL6LIB=`pwd`/lib $ git co -b exhandler-failure origin/exhandler-failure $ perl6 Configure $ make The following blows up on my system: $ perl6 t/perl6regex/01-regex.t ok 1 - [quantifiers:1] star 2+ ok 2 - [quantifiers:2] star 1 ok 3 - [quantifiers:3] star 0 ok 4 - [quantifiers:4] star 2+ ok 5 - [quantifiers:5] star 1 ok 6 - [quantifiers:6] star 0 ** Exception caught while looking for a handler, trying next ** ** Exception caught while looking for a handler, trying next ** get_iter() not implemented in class 'Integer' current instr.: 'take' pc 16710 (src/builtins/control.pir:82) called from Sub '(null)' pc -1 ((unknown file):-1)Segmentation fault (Sometimes I get the error messages and then the segfault, sometimes I get just the segfault.) GGE has ~1k LOC. (Compare this to November's ~1.6k LOC.) It's at the upper range of the spectrum of Perl 6 application sizes, and it also creates a fair amount of objects as it runs. I keep getting failures such as the above about every 20 h of coding. Usually they go away pretty easily, just by my changing a character somewhere in the source. I've never tried to isolate a failure of this sort, because due to their instability, I don't really know how I'd go about it. They are, however, 'stable' in the sense that if I run things repeatedly without any changes, the failure occurs in the same place each time. I have a few questions: * How can I, as a motivated Rakudo application developer, help make Parrot more stable when something like this occurs in my app? In Rakudo, I can minimize the failure to a line or two, and the devs have a much easier time fixing the failures. Here, it seems that the cause of the failure is the complexity of the app, and thus not reducible to a minimal case. I know how relatively unhelpful instructions like "build my app and make it do this" are, compared to "this 10-line PIR file causes problems". * Are bug reports on these kinds of failures useful? They seem transient, and go away when conditions change slightly. Often people on other platforms cannot reproduce them. Somehow, the errors themselves are not the problem, but the underlying cause which makes them come and go on a regular basis. * Is there a plan to eradicate or greatly reduce failures like these by Parrot 2.0? If so, is there any way I can help? I fear the day might come when one of these errors prevents me from developing my app, and I'd like to pre-empt that. I'd love to see these random stability problems related to complexity bottlenecks go away completely -before- Parrot/Rakudo reach sufficient traction that other people try to develop applications with the size and memory usage that makes the current problems manifest themselves. // Carl _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
