[perl #59112] Failing test in t/examples/library.t
On Tue Sep 30 16:48:32 2008, masak wrote: James (): Let's start with an elementary question: What does Configure.pl say for you at this step: auto::pcre - Does your platform support pcre auto::pcre - Does your platform support pcreyes, 7.7. // Carl Heretofore I did not have PCRE installed on either Darwin or Linux. I just installed it on Debian Stable, which provided version 6.7, not 7.7: auto::pcre - Does your platform support pcreyes, 6.7. With this version installed, I could not reproduce the error you reported. See: http://smolder.plusthree.com/app/public_projects/tap_stream/5784/392 So could this be a problem with PCRE 7.7, or how it installs on your OS? Thank you very much. kid51
Re: [perl #59112] Failing test in t/examples/library.t
auto::pcre - Does your platform support pcreyes, 6.7. With this version installed, I could not reproduce the error you reported. See: http://smolder.plusthree.com/app/public_projects/tap_stream/5784/392 So could this be a problem with PCRE 7.7, or how it installs on your OS? The config test for pcre try to compile a test program. The pcre.pir dynamically loads the pcre library. So if, for example, you have only a static pcre lib, it will detect it but fails to use. -- Salu2
Re: [perl #59112] Failing test in t/examples/library.t
On Wednesday 01 October 2008 13:43:37 NotFound wrote: auto::pcre - Does your platform support pcreyes, 6.7. With this version installed, I could not reproduce the error you reported. See: http://smolder.plusthree.com/app/public_projects/tap_stream/5784/392 So could this be a problem with PCRE 7.7, or how it installs on your OS? The config test for pcre try to compile a test program. The pcre.pir dynamically loads the pcre library. So if, for example, you have only a static pcre lib, it will detect it but fails to use. That makes sense. Can we change the config test to link against a dynamic pcre? -- c
[perl #59112] Failing test in t/examples/library.t
On Wed Oct 01 13:58:32 2008, [EMAIL PROTECTED] wrote: On Wednesday 01 October 2008 13:43:37 NotFound wrote: The config test for pcre try to compile a test program. The pcre.pir dynamically loads the pcre library. So if, for example, you have only a static pcre lib, it will detect it but fails to use. That makes sense. Can we change the config test to link against a dynamic pcre? Patches welcome. I'm cc-ing ambs, who was the original contributor of this config step and the associated C probe, to see if he can help out. Thank you very much. kid51
Re: [perl #59112] Failing test in t/examples/library.t
The config test for pcre try to compile a test program. The pcre.pir dynamically loads the pcre library. So if, for example, you have only a static pcre lib, it will detect it but fails to use. That makes sense. Can we change the config test to link against a dynamic pcre? Patches welcome. I'm cc-ing ambs, who was the original contributor of this config step and the associated C probe, to see if he can help out. I see a more generic problem. Several modules add lib links to the parrot executable. Makes sense to link static libraries if that is the intention, but is not convenient to link dynamics that can be, and are, dynamically linked at runtime. This way adds unneeded dependences to the binary packages. Also, if the libraries are linked to the parrot executable or the parrot library makes no sense to fail if they can not be located at runtime. We need some way to know that the library is already linked and his symbols available, without forcing all modules that use a library to check for both cases. -- Salu2
[perl #59410] [PATCH] CONTROL_LOOP_NEXT support for pct. Rakudo won't build, though.
Patch applied in r31547 (by avoiding a push_eh/pop_eh mismatch). The problems with imcc hanging will be entered in a separate ticket. Thanks! Pm
[perl #59538] [BUG] imcc freezes (compute_dominance_frontiers)
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #59538] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59538 The attached hang.pir file causes imcc to freeze while compiling it. The code itself is derived from code generated by PCT from RT #59410. There is a runtime logic error in the code -- at runtime it would be possible for a pop_eh to be executed without a previous push_eh. Of course, that shouldn't be enough to cause imcc to hang. Commenting out any of the lines marked xxx allows the code to compile. It's also interesting that the myfoo *= $I0 statement is one of these (and is required to evoke the bug), even though it's in an entirely different sub. Pm .sub 'foo' .local num myfoo myfoo = 1.0 $I0 = 5 myfoo *= $I0 ## xxx ?!? .end .namespace [Perl6;Grammar;Actions] .sub _block1806 :anon :lexid(139) get_global $P1808, $/ set $P1809, $P1808[post] unless_null $P1809, vivify_548 ## xxx new $P1809, Undef ## xxx vivify_548: defined $I1811, $P1809 unless $I1811, for_1807_end ## xxx new $P1812, 'ExceptionHandler' set_addr $P1812, for_1807_next ## xxx $P1812.'handle_types'(63)## xxx push_eh $P1812 iter $P1810, $P1809 for_1807: unless $P1810, for_1807_end ## xxx shift $P1813, $P1810 $P1855 = find_name _block1814 $P1855($P1813) ## xxx goto for_1807## xxx for_1807_next: goto for_1807## xxx for_1807_end: pop_eh .return ($P1810) .end
