[perl #59938] [patch] test_more.pir does not export "nok"
# New Ticket Created by Mark Grimes # Please include the string: [perl #59938] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=59938 > Hi, I was doing some test clean up (converting perl test to pir), and I noticed that test_more.pir doesn't export "nok". It is a simple fix, and I have included a patch. Thanks, Mark test_more.patch Description: Binary data
[perl #59472] [TODO] Randomize hash seed
On Tue Sep 30 04:34:58 2008, bernhard wrote: > In src/hash.c:816 there is a TODO comment: > > /* TODO randomize */ > hash->seed = 3793; > > This needs to be investigated and probably implemented. I assume it would be easy to take Parrot_intval_time() as the seed here, or some function of it. Are there any specific boundaries on how large/small this number has to be, whether it has to be prime or pseudoprime, etc? I'll throw it together if somebody will tell me what the requirements are (if any). -- Andrew Whitworth a.k.a Whiteknight
[perl #59940] [patch] convert perl tests to parrot
On Thu Oct 16 17:43:28 2008, mgrimes wrote: > Hi, > > The attached patch converts two perl based tests into parrot tests: > > t/pmc/string.t > t/pmc/objects.t > > Each of these included "pir_error_is" type tests. I am not aware of > any way to test those within parrot right now, so I kept them in perl > tests and move them to t/pmc/string-errors.t and > t/pmc/objects-errors.t. > > Converting these test to pir dropped their run time from 19 secs to 3 > secs, and more than 2 of those seconds are spent in the *-errors.t > tests. > > Unfortunately, I ran into a small issue applying the patch. Since I am > changing lines near the "# $Id:$" line, "svn diff" creates a patch > that doesn't apply cleanly. The following one liner will clean up the > $Id: line, so the patch applies cleanly. > > $ perl -i.bak -pe's/# \$Id: .*$/# \$Id\$/' t/pmc/string.t t/pmc/objects.t > > If there is a better way to make the patch, please let me know. > > Thanks, > Mark You can fix the foo_error_bar tests by using an exception handler to catch the (appropriate type of) exception. The simplest way is to use push_eh with a label. If the exception is raised, control will jump to that label. t/pmc/resizablestringarray.t uses this style. The more fine-grained approach is to use an ExceptionHandler PMC. t/pmc/ro.t uses this style. This lets you set the types and min/max severity that the eh will handle and resume execution. t/pmc/exceptionhandler.t has some nice examples. Thanks for rewriting those two tests. I thought about tackling them when I was on my PIRifying binge, but I didn't have nearly enough patience at the time.
[perl #59686] [CAGE] Review t/pmc/ro.t - improve error testing
On Tue Oct 07 06:53:58 2008, [EMAIL PROTECTED] wrote: > In fixing the Complex PMC in r31749, I revealed a problem in our > read-only PMC tests. In t/pmc/ro.t, test 5 gets an error as expected, > but the error it gets complains that add_p_ic_p doesn't exist (it hasn't > existed for years, if ever). So, test 5 isn't actually testing anything > useful. > > I'm a bit suspicious about the whole test file now, because it's not > testing for the actual text of the error message, it's just testing that > it got *some* error. The cage task is to review the test file and > improve the error testing, so that if the read-only error is masked by > some other error, the tests will fail. > > One possible direction is to use exception handlers to trap the > read-only exceptions inside the tests, instead of just relying on the > exit code. > > Allison Most of the tests are rewritten in r31997 so that only the appropriate exception types are caught. I also split the ROTest tests into a separate file in src/dynpmc/rotest.t so t/distro/test_file_coverage.t would be happy (r32001,2). Rewriting the tests uncovered a couple errors in the tests themselves. All these have been resolved to both correctly test ro functionality and pass (unless I'm missing a subtlety). The last test in t/pmc/ro.t needs a look, but it has a separate ticket. I'm marking this one resolved.
Re: [svn:perl6-synopsis] r14597 - doc/trunk/design/syn
Larry Wall <[EMAIL PROTECTED]> writes: > On Thu, Oct 16, 2008 at 10:37:41PM +0200, Eirik Berg Hanssen wrote: > : [EMAIL PROTECTED] writes: > : > : > -C<< infix: >>, sequential junctional and operator > : > +C<< infix: >>, sequential junctional and operator > : > > : > -EXPR where EXPR where EXPR ... > : > +EXPR also EXPR also EXPR ... > : > > : > Can be used to construct ANDed patterns with the same semantics as > : > C<< infix:<&> >>, but with left-to-right evaluation guaranteed, for use > : > in guarded patterns: > : > > : > -$target ~~ MyType where .mytest1 where .mytest2 > : > +$target ~~ MyType also .mytest1 also .mytest2 > : > > : > This is useful when later tests might throw exceptions if earlier > : > tests don't pass. This cannot be guaranteed by: > : > : All this, just to get the exceptions in the right order? > > It's to get exceptions not to happen at all. Normal junctions don't > trap exceptions either, but also can't guarantee order of evaluation. > This variant does. That's all. Okay, I may be particularly slow this week, but shouldn't that be specced as "short-curcuit" rather than merely "sequential" and "with left-to-right evaluation guaranteed"? (I don't see how you can get exceptions not to happen at all, unless it's short-circuiting.) Eirik -- "Minimal collateral damage" and "entire star system" do *not* belong in the same sentence. -- Howard Tayler, http://www.schlockmercenary.com/d/20050326.html
[svn:perl6-synopsis] r14598 - doc/trunk/design/syn
Author: larry Date: Fri Oct 17 08:24:48 2008 New Revision: 14598 Modified: doc/trunk/design/syn/S03.pod Log: explicit use of term "short-circuit" suggested by Eirik-Berg.Hanssen++ Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podFri Oct 17 08:24:48 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 8 Mar 2004 - Last Modified: 16 Oct 2008 + Last Modified: 17 Oct 2008 Number: 3 - Version: 144 + Version: 145 =head1 Overview @@ -949,7 +949,7 @@ =item * -C<< infix: >>, sequential junctional and operator +C<< infix: >>, short-circuit junctional and operator EXPR also EXPR also EXPR ...
[perl #59914] Re: building parrot
[reforwarding this so it gets in the bug-tracking system] On Wed, 15 Oct 2008, Michael P. Soulier wrote: > I'm trying to build parrot on a CentOS 4.6 box and it's failing at link time. > > gcc -o miniparrot src/main.o src/null_config.o \ > -Wl,-rpath=/home/msoulier/downloads/parrot-0.7.1/blib/lib > -L/home/msoulier/downloads/parrot-0.7.1/blib/lib -lparrot -lresolv -lnsl -ldl > -lm -lcrypt -lutil -lpthread -lrt -lgmp -lreadline -lncurses -lcrypto > -L/usr/local/lib -Wl,-E > src/main.o(.text+0x5c): In function `main': > src/main.c:52: undefined reference to `Parrot_new' > src/main.o(.text+0x6a):src/main.c:53: undefined reference to `imcc_initialize' > src/main.o(.text+0x86):src/main.c:58: undefined reference to > `string_from_cstring' [ . . . ] > On Wed, Oct 15, 2008 at 9:52 AM, Will Coleda <[EMAIL PROTECTED]> wrote: > > Do you have a previously installed parrot? It's possible that we're > > inadvertently linking against the installed libparrot instead of the > > one in your build dir. > > No file by that name on the box anywhere. Are you *sure*? I don't know exactly what name you searched for, nor how you searched for it, but this is just the sort of error message I'd expect to see if you did have an old libparrot.so somewhere else on your system. To be specific: The first 'undefined reference' is to Parrot_new. It should be in src/embed.o and also in blib/lib/libparrot.so. What do you get for the following commands: nm src/embed.o | grep 'Parrot_new$' nm blib/lib/libparrot.so | grep 'Parrot_new$' -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #59472] [TODO] Randomize hash seed
On Thursday 16 October 2008 11:22:20 Andrew Whitworth via RT wrote: > On Tue Sep 30 04:34:58 2008, bernhard wrote: > > In src/hash.c:816 there is a TODO comment: > > > > /* TODO randomize */ > > hash->seed = 3793; > > > > This needs to be investigated and probably implemented. > > I assume it would be easy to take Parrot_intval_time() as the seed here, > or some function of it. Are there any specific boundaries on how > large/small this number has to be, whether it has to be prime or > pseudoprime, etc? With our current hash implementation, I'm not sure it matters. (A bucket size that's always a power of two makes the resizing algorithm somewhat easy, but I have my doubts about its distributive powers) -- c
Re: [svn:perl6-synopsis] r14598 - doc/trunk/design/syn
"also" seems to be the junctive equivalent of "andthen". Should there be a junctive equivalent of "orelse"? -- Jonathan "Dataweaver" Lang
[perl #59938] [patch] test_more.pir does not export "nok"
On Thu Oct 16 17:20:00 2008, mgrimes wrote: > Hi, > > I was doing some test clean up (converting perl test to pir), and I > noticed that test_more.pir doesn't export "nok". It is a simple fix, > and I have included a patch. > > Thanks, > Mark Thanks, applied in r32004 -- Will "Coke" Coleda
