Re: [perl #36597] [PATCH]Dominance Frontiers
Thanks for pointing this out. I tracked the bug down, and it looks like the dominator algorithm does not handle unreachable blocks correctly, and the dominance frontier algorithm suffers for it. Why the unreachable blocks are generated in the first place might be an interesting question for someone working on PGE. I'll work on the dominator bug before applying the DF patch. -Curtis On 7/28/05, Will Coleda [EMAIL PROTECTED] wrote: The eval tests are failing with a pristine checkout so we can ignore those. Applying your patch to a pristine build yields only the backtrack.t failure: #2 eats 100% of the CPU until I kill it: it doesn't behave that way in svn-head. Looks like PerlString and String were red herrings. Should track down why p6rules is misbehaving with your patch, though. Regards. On Jul 28, 2005, at 1:55 PM, Will Coleda wrote: FYI, on OS X 10.4.2, I get: Failed Test Stat Wstat Total Fail Failed List of Failed -- - t/p6rules/backtrack.t1 256151 6.67% 2 t/pmc/eval.t 3 768143 21.43% 12-14 t/pmc/perlstring.t 1 256681 1.47% 61 t/pmc/string.t 1 256351 2.86% 28 I have some slight differences from svn-latest which of course shouldn't affect these tests. =-) On Jul 19, 2005, at 10:39 PM, Curtis Rawls (via RT) wrote: # New Ticket Created by Curtis Rawls # Please include the string: [perl #36597] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36597 This patch adds support for dominance frontiers in imcc, including: -Array of Sets for dominance frontiers -An efficient algorithm described in A Simple, Fast Dominance Algorithm, Cooper et al. (2001) -Free and dump functions -Curtis df.patch
Accessing Hash with strings/keys
Hi, I'm trying to extend the standard Hash PMC, if it returns None, because there was no value at the specified key, then I want to override this behaviour by returning something else. In order to do that, I should know what methods are called. That's where I'm running into trouble. I can just do a fprintf(stderr, signature); to check if the method is called. Now, when I do: P0 = new .Hash P1 = P0[42] and I0 = 42 P1 = P0[I0] the method PMC *get_pmc_keyed_int(INTVAL) gets called (as I would expect). So, I can just override this method, and if the return value of SUPER() is None, then I return my own stuff (nil to be exact). So, when I try to index the hash with a string like: P1 = P0[hi] or S0 = hi P1 = P0[S0] I would expect the method PMC *get_pmc_keyed_str(STRING *) gets called. It seems to me this is not the case. The same is true for indexing with a PMC: P2 = new .Key P2 = hello P1 = P0[P2] This should call (I think) PMC *get_pmc_keyed(PMC *) Well, that would be logical, right? (I can't find any other suitable methods in hash.pmc that could be called, because the return value should be a PMC) Anybody an idea what I'm doing wrong here? Thanks, klaas-jan
Re: [perl #36677] Parrot cannot startup if STDERR or STDOUT is closed
On Thu, Jul 28, 2005 at 12:31:33PM -0700, jerry gay via RT wrote: i've added a new test t/run/exit.t that checks parrot exit codes under different scenarios. the 8 subtests all pass on win32. These tests pass, and yet: $ perl -wle 'close STDOUT; system parrot --version; print STDERR $? 8' Parrot IO: Failed init layer(unix). 66 It appears to be your redirect which is doing it. $ perl -wle 'close STDOUT; system parrot --version /dev/null 21 ; print STDERR $? 8' 0 It must be reopening STDERR and STDOUT. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Re: Accessing Hash with strings/keys
On Jul 29, 2005, at 10:38, Klaas-Jan Stol wrote: Anybody an idea what I'm doing wrong here? By far the simplest thing is either look at the opcode in ops/core_ops.c or use a debugger and set a breakpoint at the appropriate opcode, e.g. Parrot_set_p_p_kc (or _kic) and step on from there (The keyed_str variants are only used internally to avoid constructing key PMCs at runtime. For opcodes this isn't a problem because these key pmcs are created just once at PBC load tine) Thanks, klaas-jan leo
Re: [perl #36597] [PATCH]Dominance Frontiers
On Thu, Jul 28, 2005 at 03:39:33PM -0400, Andy Dougherty wrote: On Thu, 28 Jul 2005, Will Coleda wrote: Applying your patch to a pristine build yields only the backtrack.t failure: #2 eats 100% of the CPU until I kill it: it doesn't behave that way in svn-head. I can confirm the backtrack #2 failure under SPARC/Solaris. I can't say what other tests may have changed; the script I had running the comparison got stuck at backtrack.t and never finished. Just to add to the picture -- I also tried applying df.patch to a fresh checkout of parrot/trunk (r8727), and also observed the same problem of getting stuck on test #2 in t/p6rules/backtrack.t . (FWIW, I'm running Fedora Core 4.) Some additional investigation reveals that with df.patch applied it's the PIR compiler that is getting stuck. I'm able to reproduce this with the code below, which doesn't do anything useful other than demonstrate that the compiler gets stuck when one tries to compile: $ cat x4.pir .sub foo print started\n bsr R1 goto end R1: goto R2 if $I0 goto R2 bsr R2 R2: ret end: .end $ parrot -t -v -o x4.pbc x4.pir debug = 0x0 Reading x4.pir using optimization '0' (0) Starting parse... at which point the process is stuck until interrupted somehow. The problem seems to be with the exact goto/if/bsr sequence given in R1 -- remove any of them or reorder them and the code successfully compiles. I completely grant that the specific sequence of statements that trigger this problem is bizarre -- it only occurred in PGE because of a missing optimization in PGE's code generator. The cut operator (for backtracking control) generated a goto R2 statement to handle the cut, but then also generated the code that would've performed the backtracking had the cut not been present. Note that having the extra code after the goto doesn't change the syntactic or semantic correctness at all -- it just causes the compiler to choke somehow (when df.patch is applied). I'll definitely fix PGE to not generate the unnecessary code following the goto, but it seems to me that the compiler should not hang on something like this in any case. I'll be very happy to add the above PIR segment to the imcc test suite if someone can tell me which imcc/t/*/*.t file it should go in. Then I'll fix PGE to not generate the code it should not have been generating in the first place. :-) Hope this helps! Pm
Re: [perl #36597] [PATCH]Dominance Frontiers
Patrick R. Michaud wrote: ... I'm able to reproduce this with the code below Good catch. I'll be very happy to add the above PIR segment to the imcc test suite if someone can tell me which imcc/t/*/*.t file it should go in. Probably time to start a new subdir: imcc/t/cfg/df.t or some such. Pm leo
[perl #36683] Test failures on OS X 10.3.9
# New Ticket Created by Michael G Schwern
# Please include the string: [perl #36683]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36683
The latest parrot build is failing as follows on OS X 10.3.9.
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/dynclass/gdbmhash.t 13 332813 13 100.00% 1-13
t/library/pcre.t 1 256 11 100.00% 1
t/pmc/eval.t 3 768143 21.43% 12-14
The full test output is attached. This Parrot was built using fink's
perl 5.8.6 and fink's pcre (4.2) and gdbm (1.8.0) libraries.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
You know what the chain of command is? It's the chain I go get and beat you
with 'til you understand who's in ruttin' command here.
-- Jayne Cobb, Firefly
Compiling with:
xx.c
cc -I/sw/include -fno-common -no-cpp-precomp -pipe -I/usr/local/include -pipe
-fno-common -Wno-long-double -g -Wall -Wstrict-prototypes -Wmissing-prototypes
-Winline -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings
-Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral
-Wformat-security -Wpacked -Wdisabled-optimization -falign-functions=16
-Wno-shadow -I./include -DHAS_JIT -DPPC -DHAVE_COMPUTED_GOTO -I. -o xx.o -c xx.c
bleadperl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? 8;' docs
bleadperl -e '-d or mkdir $_,0777 or die foreach @ARGV' ops
bleadperl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? 8;'
dynclasses
bleadperl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? 8;'
compilers/pge
make[1]: Nothing to be done for `all'.
bleadperl t/harness --gc-debug --running-make-test t/library/*.t t/op/*.t
t/pmc/*.t t/run/*.t t/native_pbc/*.t imcc/t/*/*.t t/dynclass/*.t t/p6rules/*.t
t/src/*.t t/perl/*.t
t/library/dumper...ok
t/library/getopt_long..ok
t/library/md5..ok
t/library/parrotlibok
t/library/pcre.
# Failed test (t/library/pcre.t at line 33)
# got: 'ok 1
# no extension: file 'libpcre'
# '
# expected: 'ok 1
# ok 2
# ok 3
# ok 4
# ok 5
# '
# './parrot --gc-debug /usr/local/src/parrot/t/library/pcre_1.pir' failed
with exit code 42
# Looks like you failed 1 test of 1.
dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
t/library/pge..ok
t/library/sort.ok
t/library/streams..ok
t/library/yaml_parser_syck.ok
t/op/00ff-dos..ok
t/op/00ff-unix.ok
t/op/64bit.skipped
all skipped: 64bit INTVAL platforms only
t/op/arithmetics...ok
t/op/basic.ok
t/op/bitwise...ok
t/op/calling...ok
t/op/comp..ok
t/op/conv..ok
t/op/debuginfo.ok
3/8 skipped: getline/setline changes not finished
t/op/gcok
t/op/globals...ok
t/op/hacks.ok
2/2 skipped: no universal SIGFPE handling
t/op/ifunless..ok
t/op/info..ok
t/op/integer...ok
t/op/interpok
t/op/jit...ok
t/op/jitn..ok
t/op/lexicals..ok
t/op/literal...ok
t/op/macro.ok
1/18 skipped: Await exceptions
t/op/numberok
t/op/randomok
t/op/rxok
1/23 skipped: Pending some sort of lowercasing op
t/op/spawnwok
t/op/stacksok
3/56 skipped: no stack limit currently
t/op/stringok
7/156 skipped: various reasons
t/op/string_cclass.ok
t/op/string_cs.ok
t/op/stringu...ok
t/op/time..ok
t/op/trans.ok
t/op/types.ok
t/pmc/arrayok
t/pmc/bigint...ok
t/pmc/boolean..ok
t/pmc/builtin..ok
t/pmc/complex..ok
t/pmc/config...ok
t/pmc/coroutineok
2/13 skipped: various reasons
t/pmc/delegate.ok
t/pmc/env..ok
t/pmc/eval.
# Failed test (t/pmc/eval.t at line 358)
# got: 'directory_pack segment 'BYTECODE_EVAL_1' used size 14 but
reported 12
#
# '
# expected: 'hello from foo_1
# hello from foo_2
# '
# './parrot --gc-debug /usr/local/src/parrot/t/pmc/eval_12.pir' failed with
exit code 1
# Failed test (t/pmc/eval.t at line 402)
# got: 'directory_pack segment 'BYTECODE_EVAL_1' used size 14 but
reported 12
#
# '
#
[perl #36682] Configure.pl warning
# New Ticket Created by Michael G Schwern # Please include the string: [perl #36682] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36682 rsync'ing the latest parrot from cvs.perl.org and running configure on OS X 10.3.9 using fink's perl 5.8.6 I get the following warning: Generating build files..value for 'parrot_exe_def' in config/gen/makefiles/root.in is undef at lib/Parrot/Configure/Step.pm line 232, IN line 667. value for 'ld_parrot_exe_def' in config/gen/makefiles/root.in is undef at lib/Parrot/Configure/Step.pm line 232, IN line 668. value for 'cc_building_dynclass_flag' in config/gen/makefiles/dynclasses_pl.in is undef at lib/Parrot/Configure/Step.pm line 232, IN line 34. ..done. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
Re: GMC for dummies
On Mon, Jul 25, 2005 at 10:33:37PM -0400, Bob Rogers wrote: [snip] This is sounding more and more like the CMUCL gencgc algorithm, which uses what I understand is a classic approach. Instead of an IGP list, it write-protects all oldspace pages (hence my earlier question), unprotecting them transparently when one is stored into, so that it only needs to scan writable pages to look for newspace pointers. It is my intuition that this would be less overhead than an IGP list, but I suspect this is data-dependent, and would take benchmarking to prove. On a POSIX-ish OS, this approach involves a system call to change the protection on each page, plus a signal handler that gets invoked whenever such a page is stored into, and then another system call to unprotect the page. [snip] That's OK; if Leo believes it will work, then I'm sure it will. My quibbles were about speed and complexity, and I don't want to distract you with unproven assertions about things that might not matter. System calls aren't cheap, and page table manipulations are not necessarilly cheap either. Whether this performance tradeoff is worth it is going to be both OS- and processor-specific. It also lurches into the realm of signal handlers, where POSIX guarantees very little behavior that is portable behavior, but operating systems may allow much more, but the allowed behaviors form an ever-changing and largely disjoint set. In summary, just about any algorithm that avoids page table manipulations and signal handlers is likely to be more portable, and will quite likely be faster. -- Ed M
Re: [perl #36677] Parrot cannot startup if STDERR or STDOUT is closed
Michael G Schwern (via RT) wrote: Parrot cannot start up if either STDOUT or STDERR are closed. Fixed in trunk - r8730 Now a Undef PMC is stored as the PIO STDxx PMC. This will give nice effects if you print something. leo
Re: [svn ci] (r8717) Win32 Dynclasses
Woot! None of the tests are currently failing on OS X, though there are several TODOs hey. Many (All??) of the failing tests are TODOs: perhaps the test harness isn't happy about TODOs on win32, for some reason. Do TODO tests report as passed in the core suite? If so, it's probably something with lib/Parrot/Test/Tcl.pm ... Thanks for your work on this, Jonathan! On Jul 28, 2005, at 4:11 PM, Jonathan Worthington wrote: Hi, Dynclasses now work on Win32 when building Parrot with the MS Visual Studio compiler. That means that all t\dynclass\*.t passes. :-) I've also (after ci'ing a fix to config/gen/makefiles/tcl.in) managed to build Partcl on Win32 and run the tests. Here's what I'm seeing. Failed Test Status Wstat Total Fail Failed List of Failed -- t\cmd_expr.t 433 6.98% 41-43 t\cmd_linsert.t51 20.00% 2 t\cmd_proc.t 41 25.00% 4 t\cmd_source.t 21 50.00% 1 t\cmd_string.t374 10.81% 16, 33-35 t\cmd_time.t 11 100.00% 1 t\tcl_backslash.t 162 12.50% 12, 14 t\tcl_command_subst.t 101 10.00% 10 t\tcl_misc.t 121 8.33% 12 t\tcl_pir_compiler.t 31 33.33% 3 Failed 10/39 test scripts, 74.36% okay. 16/266 subtests failed, 93.98% okay. Any problems, let me know. Take care, Jonathan
Re: [perl #36567] t/perl/Parrot_Docs.t doesn't clean up properly.
On Fri, 15 Jul 2005, Chromatic wrote: On Fri, 2005-07-15 at 08:27 -0700, Andy Dougherty wrote: After running 'make test', Parrot leaves the following files lying around in /tmp. I think there's from t/perl/Parrot_Docs.t. There are two problems: 1. Parrot should clean up after itself. 2. Parrot should probably pick directory names less likely to collide with other legitimate uses of /tmp. Agreed. This patch appears to fix #1. If there are no objections in a day or two, I'll apply it. Thanks. Applied as revision 8731. -- Andy Dougherty [EMAIL PROTECTED]
Does it cost anything to use a big pmc everywhere?
[Accidentally posted to Google Groups first] I'm finally doing some work on Leo's PIR Z-machine interpreter. (I've added about 15 opcodes to the 10 or so he started with. Luckily, he did a lot of the infrastructure stuff that scared me as a PIR newbie. The tester I wrote while developing Plotz passes 85 tests. Mostly.) The compiler translates Z-code into PIR, then compiles and runs it. The image of the Z-file (where the Z-machine stores its global variables and other useful things) is stored in a global called Image. So if you need to access one of the Z-machine's global variables, you emit code like: .local pmc image image = global 'Image' .GET_WORD($I181 , image, 692) where the last line is a macro that pulls the global variable out of the Z-machine memory. But Leo was smart and, while translating, says to only load image (i.e. to only output the first two lines) once per Z-code subroutine. Now here's the problem. My Z-code emitted code like this: if $I17 == 3 goto L1234 .local pmc image image = global 'Image' .GET_WORD($I181 , image, 692) L1234: print yes, blah .GET_WORD($I182 , image, 692) If $I17==3, then when we get to the second GET_WORD we exit with an error because we don't know what image is. So I think to avoid these problems I need to declare image at the top of every Z-code sub. My question is, is there any cost associated with always declaring this array holding 50-500K ints, other than having one P register always full? Since everything else in the translated code is integers strings I'm not really worried about filling my P registers. The only other option I can think of is keeping track of how my scopes are nesting while translating, which sounds like a disaster. This is what I get for trying to develop in PIR after ignoring the mailing list for 6 months and not reading the basic docs. Thanks, -Amir Karger It's better to write me at [EMAIL PROTECTED] Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
