Re: Speccing Test.pm?
On Tue, 2008-09-02 at 12:32 -0700, Darren Duncan wrote: Now a common factor to both of my proposals is that this Test.pm is intentionally kept as simple as possible and contains just the functionality needed to bootstrap the official Perl 6 test suite; if the official test suite doesn't use certain features, then they don't exist in this Test.pm, in general. This doesn't quite address one assumed detail -- should the official test suite be modified to use as few (and as simple) Test.pm features as possible, so that Test.pm can then be made even simpler? This would likely make the test suite slightly clumsier in places, while making it easier for a new implementation to get enough functionality in place so that Test.pm is fully supported. There would still be room for third party Test modules, as those would be richer and provide functionality that would be useful for testing language extensions / CPAN modules but that aren't needed by the tests for Perl 6 itself. If the test suite is modified as above, then there pretty much HAVE to be additional Test modules -- people programming third-party code would go insane using only the anemic Test.pm that would be sufficient for a simplified test suite. Of course, that doesn't mean that a more extensive Test module can't be standardized, or even an official version written that all perl6's can ship with. It doesn't have to be all-encompassing, but a core set of best practices test tools, perhaps just taken from Perl 5 experience of the TDD folks and modified for Perl 6 differences, would be nice to rely on everywhere. -'f
Re: [perl #58526] pick(*) is broken on nested arrays in Rakudo
Carl MXXsak (via RT) wrote: # New Ticket Created by Carl Mäsak # Please include the string: [perl #58526] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58526 r30698: $ ./perl6 -e 'say [1,2,3,4,5,6].pick(*)' # expected 645213 $ ./perl6 -e 'say [[1,2,3],[4,5,6]].pick(*)' # strange... 1234 $ ./perl6 -e 'say [[1,2,3],[4,5,6]].pick(*)' # ... 4561 The semantics seem to be that one array is randomly picked, flattened, and then a random element from the other array is picked. Not very intuitive behaviour, and probably not intended. Actually the array is just flattened before picking: ./perl6 -e 'say [[1,2,3],[4,5,6]].pick(*).perl' [4, 5, 6, 3] The same happens for other operations where a nested array is accessed: ./perl6 -e 'my %a = (a = [[1,2,3],[4,5,6]]); say %aa.perl' [1, 2, 3, 4, 5, 6] A saner behaviour would be for pick not to flatten elements which happen to be arrays. Indeed. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [perl #58524] prefix:= doesn't read from $*IN in Rakudo
Carl MXXsak (via RT) wrote: # New Ticket Created by Carl Mäsak # Please include the string: [perl #58524] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58524 r30698: ./perl6 -e 'say $*IN.readline' # works (i.e. repeats what I write) OH HAI! OH HAI! $ ./perl6 -e 'say =$*IN' # doesn't work 0 Shouldn't that be just =$*IN ? $ ./perl6 -e 'say =' # doesn't work -1 That is used as an example in S04, so it should work. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [svn:parrot] r30673 - in branches/pdd27mmd: include/parrot src src/pmc
On Sunday 31 August 2008 14:04:53 [EMAIL PROTECTED] wrote:
+PARROT_API
+void
+Parrot_pcc_invoke_sub_from_sig_object(PARROT_INTERP, ARGIN(PMC *sub_obj),
+ ARGIN(PMC *sig_obj))
+{
+#define PCC_ARG_MAX 1024
+ /* variables from PCCINVOKE impl in PCCMETHOD.pm */
+ /* args INSP, returns INSP */
+ INTVAL n_regs_used[] = { 0, 0, 0, 0, 0, 0, 0, 0 };
+
+ /* Each of these is 8K. Do we want 16K on the stack? */
+ opcode_t arg_indexes[PCC_ARG_MAX];
+ opcode_t result_indexes[PCC_ARG_MAX];
+
+ const char *signature = string_to_cstring(interp,
VTABLE_get_string(interp, sig_obj));
I skimmed this function in some detail and believe that signature leaks;
certainly it leaks at the first few exception calls.
+VTABLE void mark() {
+Parrot_CPointer * const data = PARROT_CPOINTER(SELF);
+
+if (data-sig)
+pobject_lives(interp, (PObj *)data-sig);
+
+if (string_equal(interp, data-sig, CONST_STRING(interp, P)) ==
0) { +PMC **pmc_pointer = (PMC **) data-pointer;
+pobject_lives(interp, (PObj *) *pmc_pointer);
+}
+else if (string_equal(interp, data-sig, CONST_STRING(interp,
S)) == 0) { +STRING **str_pointer = (STRING **)
data-pointer;
+pobject_lives(interp, (PObj *) *str_pointer);
+}
+}
I look at this and think You know, if we don't want to subclass this PMC for
the different types of pointers it can store and morph appropriately, we
could keep variant vtable entries for the different types and swap the vtable
depending on whether it stores a PMC or a STRING. Then I think That's
exactly the kind of evil we could use to fix the madness in the Key PMC.
Then I think Hey, is it midnight already?
That doesn't make my idea bad.
-- c
Re: [perl #58362] [BUG] can't set Env PMC values with non-keyed opcodes
On Monday 25 August 2008 08:41:39 Jeff Horwitz wrote: rakudo cannot write to %*ENV because the underlying Env PMC apparently does not update the environment when using a non-keyed opcode: The Env PMC is a thin wrapper around setenv(3) and getenv(3). We can change it to store STRING and PMC pointers for the appropriate vtable entries, but how do you distinguish between storing the value of a STRING with setenv(3) and storing the string pointer? How do you distinguish between storing a PMC pointer and fetching the string value of that PMC and storing it with setenv(3)? (The first person to tell me to read how Perl 5 does it gets a bonk on the head with my +2 Hammer of I've Read Enough Perl 5 Internals, Thank You, Radiant Damage.) -- c
Re: [perl #58524] prefix:= doesn't read from $*IN in Rakudo
Moritz (), Carl (): $ ./perl6 -e 'say =$*IN' # doesn't work 0 Shouldn't that be just =$*IN ? Yes, it should. I claim temporary insanity. // Carl
Re: [perl #56712] [BUG] --optimize causes perl6 to segfault during make
On Tuesday 08 July 2008 20:56:03 jason switzer wrote: When trying to use the --optimize flag, building perl6 causes parrot to segfault. Attached is the Configure.pl script output. Below is a backtrace by manually performing the make step from gdb. You'll notice the second run performs the same operation with the -G option to disable memory management. Seperate executions have generated slightly different backtraces (likely due to signal timings). This is not caused by the --inline Configure.pl option. Can you still reproduce this? I've seen a few weird 64-bit problems with GC in the past couple of months. Narrowing this down would be very handy. -- c
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
Klaas-Jan Stol wrote: On Tue, Sep 2, 2008 at 2:28 PM, Allison Randal [EMAIL PROTECTED] wrote: I'm not clear on why we need to reserve 'if', 'unless' and 'null' either, since they never appear in locations that could be confused with variables. there's not a strict reason, no. In fact, it would be possible to allow them, although the implementation of that will require a number of special cases in the grammar (but doable, as far as my experiments showed me). We're marking them as a special case now to treat them as reserved words. The only concern would be (as Andrew indicated as well), that you could write: if null null goto goto if you had declared null and goto as .locals. That's more of a stylistic custom than something to enforce in the parser. But, like I said, this definitely isn't an urgent modification, just a general matter of clarity and consistency in PIR. Allison
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
I checked in some major changes that allow all keywords (types and if, null, etc.) as identifiers. Cleanup and maybe a refactor will follow later. kjs On Wed, Sep 3, 2008 at 10:35 AM, Allison Randal [EMAIL PROTECTED] wrote: Klaas-Jan Stol wrote: On Tue, Sep 2, 2008 at 2:28 PM, Allison Randal [EMAIL PROTECTED] wrote: I'm not clear on why we need to reserve 'if', 'unless' and 'null' either, since they never appear in locations that could be confused with variables. there's not a strict reason, no. In fact, it would be possible to allow them, although the implementation of that will require a number of special cases in the grammar (but doable, as far as my experiments showed me). We're marking them as a special case now to treat them as reserved words. The only concern would be (as Andrew indicated as well), that you could write: if null null goto goto if you had declared null and goto as .locals. That's more of a stylistic custom than something to enforce in the parser. But, like I said, this definitely isn't an urgent modification, just a general matter of clarity and consistency in PIR. Allison
Re: [perl #58176] [PATCH] dotnet exceptions
On Wednesday 20 August 2008 12:48:27 Reini Urban wrote: make dotnet work with the new exceptions. I'm not sure how to return the jump_point correctly, but it looks fine. Thanks, applied as r30718. -- c
capitalization of classes
While S02 reserves some all caps names, I assume that all lower case class
names are okay (I don't see anything against them). Rakudo doesn't support
them. Is this a bug or is there something in the synopsis that I've missed.
Here is my example:
class Test { has $.x; }
class test { has $.x; }
Test.new(:x3);
test.new(:x3);
It produces:
sully:perl6 stephensimmons$ perl6 experiment/class_capitalization.p6
invoke() not implemented in class 'test'
current instr.: '_block11' pc 42 (EVAL_13:18)
called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806
(src/PCT/HLLCompiler.pir:481)
called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1078
(src/PCT/HLLCompiler.pir:610)
called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1257
(src/PCT/HLLCompiler.pir:699)
called from Sub 'parrot;Perl6::Compiler;main' pc 15522 (perl6.pir:172)
Stephen Simmons
Re: capitalization of classes
Hi, Stephen Simmons wrote: While S02 reserves some all caps names, I assume that all lower case class names are okay (I don't see anything against them). Rakudo doesn't support them. This is a not yet implemented feature. Basically Rakudo doesn't keep a symbol table yet while parsing, so it uses the case of the first letter to distinguish type names from sub names. This is an evil hack that will at some point be cleaned up. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Speccing Test.pm?
Two sorts of testing - a) compiler, b) modules. Each category has different environment and function. a) compiler. An official test suite is defined (and probably will be added to as corner cases / ambiguities are discovered and disambiguation decided, so presumably some standardisation of testing must exist, either implicitly or explicitly). Hence tests are canonical. Compiler is changed to conform to tests. Function of test suite - validate compiler implementation as perl6. b) modules. Valid compiler is assumed. Tests and module are changed to conform to compiler. Function of test suite - validate that a module works in an expected manner on a valid complier. Clearly, the functionality in Test.pm (for modules) could/should be a superset of the functionality in test_compiler.pm, and can assume a valid compiler. The interesting question - I think - is how practically and elegantly to ensure the tests in the compiler validation suite achieve their task. Two alternatives it seems are possible: a) Define the code for test_compiler.pm which is guaranteed to run all the test suite. This make test_compiler.pm a part of the language, viz., implementation as specification. Tests will be needed in the official test suite to ensure that test_compiler.pm running under the new compiler conforms to specification (eg., an error in the compiler reverses the meaning of the test functions). b) Define the core functions for testing the compiler as part of the language, allowing no others in the official test suite. Alternative implementations of test_compiler.pm are possible (though a prototype could be provided). Tests needed in the official suite to validate conformity of implementations of the test functions to specification. Whatever, it does seem to me that if perl6 is to be defined by its specification and its test suite, then the testing process has also to be defined within the language. If the testing process is not defined at the same level as the language itself, then at some point the validity of a compiler of the language will be dependent on the implementation of a part of the testing process. Patrick R. Michaud wrote: On Tue, Sep 02, 2008 at 12:32:49PM -0700, Darren Duncan wrote: Patrick R. Michaud wrote: I think it's good to have a prototype Test.pm that we can point to as a reference, but I don't think we need to try to designate it as being official. [...] 2. The Perl 6 language spec itself would specify a basic set of test routines built-in to the language, in a Test namespace, much as it defines collections of routines now for such as numbers and arrays and standard I/O. And so the basic test routines would be formally defined in a Synopsis document. I disagree. The testing we're likely want to do as part of the language test suite may be substantially different from what we want to provide to module writers for testing. In particular, I think that the test suite harness should require only a minimal Perl 6 implementation (note I said harness, not the tests themselves), whereas it's much more reasonable that a testing system used by module writers could/should assume a fully working Perl 6 implementation. It's a difference of bootstrapping versus running environment. I also don't see the possibility of our getting it wrong in the design to be such a big deal, since the odds are anything we think of now will work well for many years, as Test.pm/Test::More has been fairly stable already and meanwhile Perl 6 is versioned now, so we could make an incompatible change to the Test related language spec in the future, and as long as users say use Perl-6.0.0 their code relying on the older/current Test.pm like interface won't break. Perl 6 is versioned now is a misnomer. The *spec* calls for a versioned Perl 6, but I'm not aware that any of the implementations do much with that. At any rate, relying on handling multiple versions of Perl 6 to run Test.pm is exactly one of those things I'd like to avoid in the official test suite. Pm This mail was received via Mail-SeCure System.
[perl #58544] [BUG] IMPORTANT probaly.
# New Ticket Created by Pim
# Please include the string: [perl #58544]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58544
Hi,
playing with pugs and parrot compiled perl6 i found this bug:
1st script :
#!/usr/local/bin/pugs -w
loop (my $i=0;$i2;$i++) {
say $i;
}
---
works well.
2nd script :
#!/usr/local/bin/pugs -w
my $n=7;
if ($n 2) { say $n is bigger than 2;}
--
works well.
3rd script (is the concatenation of both 1st and 2nd):
#!/usr/local/bin/pugs -w
loop (my $i=0;$i2;$i++) {
say $i;
}
my $n=7;
if ($n 2) { say $n is bigger than 2;}
--
crashes with this error:
pugs t3.pl
***
Unexpected 2
expecting operator or ;
at ./t3.pl line 9, column 10
Here's my pugs version : Version: 6.2.13.11 according pugs -v.
-
and per6 parrot compiled (THIS VERSION):
This is Rakudo Perl 6, revision 30402 built on parrot 0.7.0-devel
11:57 pim for i486-linux-gnu-thread-multi.
complains like this:
Statement not terminated properly at line 9, near 2) { say \
current instr.: 'parrot;PGE::Util;die' pc 119
(runtime/parrot/library/PGE/Util.pir:82)
called from Sub 'parrot;Perl6::Grammar;eat_terminator' pc 23817
(src/gen_grammar.pir:2840) called from Sub
'parrot;Perl6::Grammar;statementlist' pc 22866
(src/gen_grammar.pir:2473) called from Sub 'parrot;Perl6::Grammar;circumfix'
pc 77039
(src/gen_grammar.pir:23163) called from Sub 'parrot;Perl6::Grammar;noun' pc
64913
(src/gen_grammar.pir:18584) called from Sub 'parrot;Perl6::Grammar;expect_term'
pc 60176
(src/gen_grammar.pir:16796) called from Sub 'parrot;PGE::OPTable;parse' pc 1959
(compilers/pge/PGE/OPTable.pir:554)called from Sub
'parrot;Perl6::Grammar;arglist' pc 92058
(src/gen_grammar.pir:29009) called from Sub 'parrot;Perl6::Grammar;term' pc
67012
(src/gen_grammar.pir:19356) called from Sub 'parrot;Perl6::Grammar;noun' pc
65511
(src/gen_grammar.pir:18786) called from Sub 'parrot;Perl6::Grammar;expect_term'
pc 60176
(src/gen_grammar.pir:16796) called from Sub 'parrot;PGE::OPTable;parse' pc 1959
(compilers/pge/PGE/OPTable.pir:554) called from Sub
'parrot;Perl6::Grammar;statement' pc 24619
(src/gen_grammar.pir:3146) called from Sub
'parrot;Perl6::Grammar;statementlist' pc 22764
(src/gen_grammar.pir:2437) called from Sub
'parrot;Perl6::Grammar;statement_block' pc 20803
(src/gen_grammar.pir:1665)called from Sub 'parrot;Perl6::Grammar;TOP' pc 17136
(src/gen_grammar.pir:225)
called from Sub 'parrot;PCT::HLLCompiler;parse' pc 585
(src/PCT/HLLCompiler.pir:371) called from Sub 'parrot;PCT::HLLCompiler;compile'
pc 438
(src/PCT/HLLCompiler.pir:303) called from Sub 'parrot;PCT::HLLCompiler;eval' pc
776
(src/PCT/HLLCompiler.pir:473) called from Sub
'parrot;PCT::HLLCompiler;evalfiles' pc 1078
(src/PCT/HLLCompiler.pir:610) called from Sub
'parrot;PCT::HLLCompiler;command_line' pc 1257
(src/PCT/HLLCompiler.pir:699) called from Sub 'parrot;Perl6::Compiler;main' pc
15352 (perl6.pir:172)
Hope this paste is not too long.
Notice : i talked about this error on irc #perl6 and they proposed me to post
the bug here.
Kind regards.
Jean-Yves.
[perl #58354] [PATCH] for the file parrot.spec
Reini's patch applied as r30719 and Gerd's patch suggestion applied as r30720. Thanks!
Re: [perl #58544] [BUG] IMPORTANT probaly.
On Wed, Sep 03, 2008 at 03:38:29AM -0700, Pim wrote:
#!/usr/local/bin/pugs -w
loop (my $i=0;$i2;$i++) {
say $i;
}
my $n=7;
if ($n 2) { say $n is bigger than 2;}
--
crashes with this error:
Unexpected 2
expecting operator or ;
at ./t3.pl line 9, column 10
[...]
and per6 parrot compiled (THIS VERSION):
Statement not terminated properly at line 9, near 2) { say \
If both pugs and rakudo agree on an error, I'd bet that the
problem is in the program and not the compiler(s). :-)
In this case, the problem is the lack of a space before the
angle bracket in the loop statement:
loop (my $i=0;$i2;$i++) {
...
if ($n 2) { say $n is bigger than 2;}
Perl 6 sees the angle bracket following the $i as being a
subscript using the ... notation, which ends at the angle
bracket in the if statement. It then complains about not
understanding the 2 that follows the closing angle bracket.
S03:2793 notes this explicitly:
Note: any operator beginning with C must have whitespace
in front of it, or it will be interpreted as a hash subscript instead.
So, add a whitespace character in front of the opening angle bracket,
and all works (at least in rakudo):
$ cat x
#!/usr/local/bin/pugs -w
loop (my $i = 0; $i 2; $i++) {
say $i;
}
my $n = 7;
if ($n 2) { say $n is bigger than 2;}
$ ./parrot perl6.pbc x
0
1
7 is bigger than 2
Thanks!
Pm
Re: [perl #58544] [BUG] IMPORTANT probaly.
Patrick ():
If both pugs and rakudo agree on an error, I'd bet that the
problem is in the program and not the compiler(s). :-)
In this case, the problem is the lack of a space before the
angle bracket in the loop statement:
loop (my $i=0;$i2;$i++) {
...
if ($n 2) { say $n is bigger than 2;}
Perl 6 sees the angle bracket following the $i as being a
subscript using the ... notation, which ends at the angle
bracket in the if statement. It then complains about not
understanding the 2 that follows the closing angle bracket.
S03:2793 notes this explicitly:
Note: any operator beginning with C must have whitespace
in front of it, or it will be interpreted as a hash subscript instead.
So, add a whitespace character in front of the opening angle bracket,
and all works (at least in rakudo):
$ cat x
#!/usr/local/bin/pugs -w
loop (my $i = 0; $i 2; $i++) {
say $i;
}
my $n = 7;
if ($n 2) { say $n is bigger than 2;}
$ ./parrot perl6.pbc x
0
1
7 is bigger than 2
There's a related problem when using empty parens after the 'loop'
keyword, however:
$ cat test.p6
loop () {
}
my $n
$ ./perl6 test.p6
Statement not terminated properly at line 1, near {\n}\nmy $n\n
[...]
That can't be related to the ... notation. Are empty parens allowed here?
// Carl
Re: [perl #58544] [BUG] IMPORTANT probaly.
On Wed, Sep 03, 2008 at 03:26:03PM +0200, Carl Mäsak wrote:
Patrick ():
If both pugs and rakudo agree on an error, I'd bet that the
problem is in the program and not the compiler(s). :-)
In this case, the problem is the lack of a space before the
angle bracket in the loop statement:
There's a related problem when using empty parens after the 'loop'
keyword, however:
$ cat test.p6
loop () {
}
my $n
$ ./perl6 test.p6
Statement not terminated properly at line 1, near {\n}\nmy $n\n
[...]
That can't be related to the ... notation. Are empty parens allowed here?
According to STD.pm, empty parens aren't allowed -- the semicolons
are required. One can write an infinite loop as either
loop { ... }
or
loop (;;) { ... }
At present Rakudo understands the first form but not the second
(patches welcome -- mainly the grammar just needs to treat the
expressions as optional instead of required).
Thanks!
Pm
[perl #58550] [TODO] Deprecate the cmodulus vtable functions
# New Ticket Created by Allison Randal # Please include the string: [perl #58550] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58550 Deprecate the following vtable functions: PMC* cmodulus(PMC* value, PMC* dest) PMC* cmodulus_int(INTVAL value, PMC* dest) PMC* cmodulus_float(FLOATVAL value, PMC* dest) void i_cmodulus(PMC* value) void i_cmodulus_int(INTVAL value) void i_cmodulus_float(FLOATVAL value) According to the documentation, the 'cmod' opcode is provided for those who need it (such as speed-sensitive applications with heavy use of mod, but using it only with positive arguments). There's no point in supporting a slow pmc/vtable/mmd-based implementation of an opcode that's only included as an optimization. Also deprecate the two-argument forms of the 'cmod' opcode (which only existed as an artifact of the old multiple dispatch system). Allison
Re: Name spaces of PIR identifiers
On Tue, Sep 2, 2008 at 8:08 AM, François Perrad [EMAIL PROTECTED]wrote:
It seems that PIR uses only one name space of identifiers.
$ cat const.pir
.const int cst = 42
.sub 'cst'
print cst
.end
$ parrot const.pir
error:imcc:undefined identifier 'cst'
in file 'const.pir' line 5
$ cat label.pir
.const int L1 = 42
.sub 'main'
print L1
goto L1
L1:
.end
$ parrot label.pir
error:imcc:syntax error, unexpected VAR, expecting IDENTIFIER or PARROT_OP
('L1')
in file 'label.pir' line 5
The expected behavior is not defined in ppd19.
François.
I agree, there should be more clarity on namespaces; do all identifiers
share the same namespace, or does each type of object (not Parrot type, but
whether it's a subroutine, .local, .const, etc.) have its own namespace?
Consider the following example:
.sub add
.local int add
add = 1
print add
add()
.end
Should the above be possible? That would imply that each type of object has
its own namespace, so that from the context the type of object can be
deduced (so:, invoking add means that add is expected to be a sub; however,
what if 'add' was declared as a pmc? it could hold a sub to be invoked, so
what sub should be called? ) It seems that .locals should take precedence
here: when invoking something that was declared as a .local, that .local
should be of type pmc and hold a subroutine (so the above example will then
emit an error message saying you can't invoke an integer). If add was not
declared a .local, a recursive call would be made.
Some clarity must be created around this.
kjs
Re: [perl #58392] Recursion and for loops interact badly in Rakudo
On Wednesday 27 August 2008 07:26:00 Moritz Lenz wrote:
Carl MXXsak (via RT) wrote:
r30589:
$ cat for-loop-recursion.bug
sub f($l) {
return() if $l = 0;
say entering $l;
for 1..3 {
f($l-1);
say looping in $l;
}
}
f(2);
I re-worked that as a test and added it to t/spec/S04-statements/for.t
If you or Carl can provide a PIR program which exhibits he problem, I'll fix
it.
-- c
[PATCH] cygwin070patches_9
for the cygwin070patches branch: * fix a perlcritic test for Compiler.pm * add DESTDIR to languages make install and test-installable * fix forth and tcl build/installed seperation and fixed pbc destination paths * make builds the default targets, all builds all. * fix wrong #ELSEIF to #ELSIF in language makefiles -- Reini Urban http://phpwiki.org/ http://murbreak.at/ cygwin070patches_9.patch.gz Description: GNU Zip compressed data
Re: [PATCH] cygwin070patches_9
Reini Urban wrote: for the cygwin070patches branch: * fix a perlcritic test for Compiler.pm * add DESTDIR to languages make install and test-installable * fix forth and tcl build/installed seperation and fixed pbc destination paths * make builds the default targets, all builds all. * fix wrong #ELSEIF to #ELSIF in language makefiles applied as r30732, thanks. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
[perl #58558] Implement stubby exception generators in Rakudo
# New Ticket Created by Carl Mäsak # Please include the string: [perl #58558] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58558 Implement the '...', '???' and '!!!' operators, as described in S03:1691.
Re: What happened to err operator?
Larry Wall larry-at-wall.org |Perl 6| wrote:
a() orelse b()
you might want to:
succeed on a()
trap mild failure of a() and try to succeed on b() instead
fail completely on drastic failure of a()
At the moment this three-way distinction depends on whether a() returns
defined/undefined or throws an exception. Maybe that's good enough.
I don't want to overcomplexify things, but I don't want to
undercomplexify them either. :)
I'm thinking that, rather than have a zillion options to pre-configure
the fail mode of that group of functions, it can be done by having a
CATCH handler that calls resume on the ones you want to pop back out.
{ # some block scope
use fail;
a() orelse b();
more-stuff-here;
CATCH {
when xxx { .resume() }
}
This is also handy in that you can set flags or something before getting
back to the main expression. This makes EH more like a footnote to
the code than anything I've used before.
--John
Conceptual question on exception in S04
I'm trying to work out some details of this area, but I don't understand what S04 is trying to say. Could someone please point me in the right direction? I'd be happy to then edit the S04 to contribute. In S04, the Exceptions section mentions that $! contains multiple exceptions. So what type is it? Why isn't it @! ? I says that they are thrown as a single new exception. So what type is that new exception? A multi-exception of some kind? How do you get multiple pending exceptions in the first place? If you mean that exceptions can be thrown (and handled) within the handling of another exception, then the list should be more of a stack. Should the handler then see the topmost one as its topic? If you really did make the whole list the topic then it would be difficult to match. How would you access the other exceptions in $!, presumably testing them for .defined etc.? Granted that the paragraph is muddled due to old edits from previous ideas, I'd be happy to rewrite it. But what =is= the current central concept that it is trying to explain? --John
Re: What happened to err operator?
On Wed, Sep 03, 2008 at 06:41:10PM -0500, John M. Dlugosz wrote:
Larry Wall larry-at-wall.org |Perl 6| wrote:
a() orelse b()
you might want to:
succeed on a()
trap mild failure of a() and try to succeed on b() instead
fail completely on drastic failure of a()
At the moment this three-way distinction depends on whether a() returns
defined/undefined or throws an exception. Maybe that's good enough.
I don't want to overcomplexify things, but I don't want to
undercomplexify them either. :)
I'm thinking that, rather than have a zillion options to pre-configure
the fail mode of that group of functions, it can be done by having a
CATCH handler that calls resume on the ones you want to pop back out.
{ # some block scope
use fail;
a() orelse b();
more-stuff-here;
CATCH {
when xxx { .resume() }
}
I think .resume is not quite right, since resume would tell the fail
to return back into the body of a() as if it were merely a warning.
(Which is how we do warnings, after all.) We need a name for what fail
does when fatal isn't turned on, which might simply be a .return(),
though that's going to be confusing to people who think it returns
from the outer routine rather than from a(). So maybe we should give
it an obscure name like .interesting() or some such to turn a thrown
exception into a mere interesting value of undef.
Presumably a failure that is returned rather than thrown is already
considered interesting. :)
I suppose some will be inclined to turn on use fatal and defatalize
everything with .interesting, though I'm pretty certain that would
not be nearly as efficient as if fail just returned directly.
Another potential issue is that CATCH doesn't distinguish exceptions
coming from the current block from those coming from the subcall to a().
So it could end up returning Failure from the current block when
you intended to force return of Failure from a(). Not sure what
to do about that...
This is also handy in that you can set flags or something before getting
back to the main expression. This makes EH more like a footnote to
the code than anything I've used before.
Indeed, nice metaphor.
Larry
