Re: [perl #56558] [PATCH] pdb rename to parrot_pdb
NotFound a écrit : After some discussion in #parrotsketch, the name parrot_debugger wins. Done in r29496, waiting for comments and fixes before closing the ticket. pdb was renamed parrot_debugger, but not installable_pdb. François.
language testing on pdd25cx, preparing to merge
After temporarily disabling the graph coloring register allocator, the pdd25cx branch passes all Parrot tests. Please run the tests for your language and report/debug any test failures that are different than the test failures in trunk. The plan is to merge the branch back into trunk on Friday or Saturday. Allison
Re: language testing on pdd25cx, preparing to merge (rakudo)
Allison Randal wrote: After temporarily disabling the graph coloring register allocator, the pdd25cx branch passes all Parrot tests. Please run the tests for your language and report/debug any test failures that are different than the test failures in trunk. I ran the tests for rakudo. make test is clean, make spectest_regression reveals some bugs (make spectest_regression is clean in trunk). Most of them are quite similar to this one: t/spec/S02-builtin_data_types/type..1/25 too few arguments passed (0 ) - 1 params expected current instr.: 'paramtype' pc 742 (EVAL_15:276) called from Sub '_block165' pc 688 (EVAL_15:260) called from Sub '_block11' pc 280 (EVAL_15:98) called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806 (src/PCT/HLLCompiler.pir:4 81) called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1088 (src/PCT/HLLCompiler .pir:610) called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1267 (src/PCT/HLLCompi ler.pir:699) called from Sub 'parrot;Perl6::Compiler;main' pc 12211 (perl6.pir:174) There's also a HLL scoping failure which I'd attribute to the PGE problems: t/spec/S12-class/attributes.Scope not found for PAST::Var ' $a' current instr.: 'parrot;PCT::HLLCompiler;panic' pc 156 (src/PCT/HLLCompiler.pir: 103) [longish stack trace snipped] Other errors are: * get_integer() not implemented in class 'Range' (in t/spec/S29-array/delete) * Method 'min' not found for invocant of class 'Int' (in t/spec/S29-list/minmax) * No result object (in t/spec/S29-num/abs) plus a few parse errors. I also get errors in parrot's PGE tests (I guess they are known already; if not I can happily send the details) The plan is to merge the branch back into trunk on Friday or Saturday. Allison -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [perl #57026] [BUG]: Changes to Parrot::Ops2c::Utils in remove_getfd branch cause failures in buildtools_tests
Will Coleda schrieb: On Wed, Jul 16, 2008 at 10:54 PM, James Keenan via RT [EMAIL PROTECTED] wrote: This module is written in Perl 5 and is called in a program written in Perl 5. In the work I've done in this project, I've taken the approach to return values which I think is more Perlish, namely, if a subroutine completes and does what you wanted it to, it should return a true value. A bare return returns an undef, which in Perl is false. False values (whether empty string, empty list, 0 or undef) should indicate some unsatisfactory completion of the subroutine. Having these subs end in a bare return to me connotes an unsatisfactory outcome of some sort. That's why I did not have them end in bare returns, and it's why I object to the changes that were made yesterday. Not every function has a true/false return value. These methods that were refactored from the original script are only invoked once, and are just there to encapsulate code. They are not expected to return a true -or- false value. The one place they are invoked outside of the test suite treats them as a void return value and doesn't save the return value, let alone have a conditional based on it. Since there's no 'void' return in perl, undef is about as close as you can get. I'm done, and I didn't die. That said, we can agree to disagree on that point for now, and leave the tests unchanged for the moment... ... because we can change the bare 'return;'s to 'return 1;' for now. That avoids the implicit return value that we were unintentionally getting, and will get us one step closer to passing the perlcritic policy [Subroutines::RequireFinalReturn]. Hi, sorry for not running 'make buildtool-tests'. The only reason for adding the empty returns, was that the implementation was not in accord with function documentation. In the POD for the changed functions there was: Return Value: None. I think the interface of a function should reflect it's intent. If only internal state is modified, I'm happy with returning undef or the empty list. On the other hand, I wouldn't expect that a function returns 1, only because the code ran successfully. So I would be in favour of changing the tests. But as I have no strong feelings about that, a return 1; would be fine as well. Regards, Bernhard
[perl #57026] [BUG]: Changes to Parrot::Ops2pm::Utils in remove_getfd branch cause failures in buildtools_tests
The breakage was in lib/Parrot/Ops2pm/Utils.pm, not lib/Parrot/Ops2c/Utils.pm. So I have corrected the Subject of the RT. kid51
[perl #57026] [BUG]: Changes to Parrot::Ops2pm::Utils in remove_getfd branch cause failures in buildtools_tests
I can see Barney's point that the documentation was not in accordance
with the return statements of several of the subroutines. So I have
changed that accordingly.
It seems from the discussion that most of us can live with an explicit
statement of a true return value (as distinct from an explicit bare
return or an implicit true value), so I have made that change. No
changes in the test suite are then needed.
These are the return statements:
$ grep -n return lib/Parrot/Ops2pm/Utils.pm
131:return bless $argsref, $class;
275:return 1;
359:return 1;
414:return 1;
465:return 1;
552:return 1;
637:return 1;
Attached is the diff for what I have committed in r29553.
For future reference, please note that the POD for
lib/Parrot/Ops2c/Utils.pm has all along included a NOTE ON TESTING
section that describes the accompanying test suite and how to use it in
refactoring the module.
Thank you very much.
kid51
Index: lib/Parrot/Ops2pm/Utils.pm
===
--- lib/Parrot/Ops2pm/Utils.pm (revision 29552)
+++ lib/Parrot/Ops2pm/Utils.pm (working copy)
@@ -375,8 +375,8 @@
=item * Return Value
-None. Internally, sets the Cops key of the object's data
-structure.
+Returns true value upon successful completion. Internally, sets the Cops
+key of the object's data structure.
=item * Comment
@@ -411,7 +411,7 @@
@{ $self-{ops}-{OPS} } =
sort { $a-{CODE} = $b-{CODE} } ( @{ $self-{ops}-{OPS} } );
-return;
+return 1;
}
=head2 Cprepare_real_ops()
@@ -429,8 +429,8 @@
=item * Return Value
-None. Internally, sets the Creal_ops key of the object's
-data structure.
+Returns true value upon successful completion. Internally, sets the
+Creal_ops key of the object's data structure.
=item * Comment
@@ -462,7 +462,7 @@
}
$self-{real_ops} = $real_ops;
-return;
+return 1;
}
=head2 Cprint_module()
@@ -476,12 +476,12 @@
=item * Arguments
-None. (Implicitly requires that the constructor have the
-following keys defined: Cargv, Cscript, Cmoddir and Cmodule.)
+None. (Implicitly requires that the constructor have the following keys
+defined: Cargv, Cscript, Cmoddir and Cmodule.)
=item * Return Value
-Returns true value upon success.
+Returns true value upon successful completion.
=item * Comment
[perl #57026] [BUG]: Changes to Parrot::Ops2pm::Utils in remove_getfd branch cause failures in buildtools_tests
On Thu Jul 17 03:40:13 2008, [EMAIL PROTECTED] wrote: For future reference, please note that the POD for lib/Parrot/Ops2c/Utils.pm has all along included a NOTE ON TESTING section that describes the accompanying test suite and how to use it in refactoring the module. Aagh! Same error twice. It's the POD for lib/Parrot/Ops2pm/Utils.pm that has that section.
[CORE] gcc: objects after libs, linker switches after libs.
I see that on 0.6.4 within cygwin my linker does not work anymore. Latest svn smokes from before the release built fine. Checking the Makefiles I see that some objects had been added to the end of the linker lines which is invalid on newer gcc versions and windows. First the objects, then the linker switches, then the libs. If noone changed that in tghe recent past it could be that my switch to link against an windows importlibrary and not directly to the dll anymore caused that bug to emerge. I had to fix tools/dev/pbc_to_exe_gen.pl (config at last is wrong) and config/gen/makefiles/root.in In the exe targets in root.in the switches were even completely reversed. -$(ALL_PARROT_LIBS) $(LINKFLAGS) +$(LINKFLAGS) $(ALL_PARROT_LIBS) @@ -801,15 +801,15 @@ # TODO build the real miniparrot $(MINIPARROT) : $(SRC_DIR)/main$(O) $(GEN_HEADERS) $(LIBPARROT) \ lib/Parrot/OpLib/core.pm $(SRC_DIR)/null_config$(O) - $(LINK) @[EMAIL PROTECTED]@ $(SRC_DIR)/main$(O) \ -@rpath_blib@ $(ALL_PARROT_LIBS) $(LINKFLAGS) $(SRC_DIR)/null_config$(O) + $(LINK) @[EMAIL PROTECTED]@ $(SRC_DIR)/main$(O) $(SRC_DIR)/null_config$(O) \ +@rpath_blib@ $(LINKFLAGS) $(ALL_PARROT_LIBS) Note the null_config at the end. Similar through the whole files. Should I open a ticket and submit my patch or am I wrong? -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #51944] [DOCS] Cygwin Readme
2008/7/16 Will Coleda [EMAIL PROTECTED]: On Wed, Jul 16, 2008 at 2:31 AM, Reini Urban via RT [EMAIL PROTECTED] wrote: 2008/7/15 Reini Urban [EMAIL PROTECTED]: Will Coleda via RT schrieb: On Tue May 13 05:21:32 2008, rurban wrote: 2008/5/13 Andrew Whitworth via RT bugs-parrot- [EMAIL PROTECTED]: is this ticket (#51944) resolved? I don't see any outstanding todo items here that need to be considered further, and the submitted patch has already been applied. Can we close this, or is this a placeholder for us to further improve cygwin documentation? The list os build preq's is required. Well, the tip for smoke to do cpan Test::TAP::HTMLMatrix could be added. But this should be added in the general README for all platforms. Then platform specific is only that pg.t fails due to missing loadlib exceptions and that cygwin perl-5.10.0 fails to send the smoke report. perl-5.8.8 works ok. I'll send that as extra README_cygwin.pod patch. ENOPATCH. =-) Can someone with cygwin access go through the README once more so we can get this ticket closed? Thanks. Ok, since there's now almost an official parrot package, the updates are easy. Patch attached. The parrot-0.6.4-1 packages are in the works. I found a better link for the SDL link. Yesterday the http://cygwinports.dotsrc.org/ site was down, but now it is up again. Please use the attached revised patch instead. This looks good; I'd ask you double check which deps are required vs. optional: I'm pretty sure we don't -require- any of those packages. Ditto for their correspond build deps. (e.g. libgdbm-devel) Note, there are more cygwin-side updates to come to this README, which I will commit after my parrot-0.6.4 release (in 1-2 days). In which pod should we document the non-windows package requirements? Most of those packages have similar names anyway for every unix/posix platform. parrot is recursively listed as a build requirement oops. For the optional items, perl's Moose should be on the list (for smartlink), and Test::Perl::Critic/Perl::Critic for the critic tests. (Honestly we should have this documented somewhere else and just refer to it from here.) Good. Where? Here are some notes about the build/tests.. ** I get this warning on configure: Determining CPU architecture and OS...done. Determining JIT capability... 10 [main] test 1944 _cygtls::handle_exceptions : Error while dumping state (probably corrupted stack) 10 [main] test 4596 _cygtls::handle_exceptions: Error while dumping state ( probably corrupted stack) ..yes. There's a cygwin jit patch outstanding. [perl #56824] [PATCH] Configure - fix SEGV in JIT has_exec_protect test on Cygwin Generating CPU specific stuff.done. Verifying that the compiler supports function pointer castsyes. ** Get a similar error running t/src/extend.t ** Bug in t/doc/pod.t - few warnings of the type: Error: /cygdrive/d/sandbox/parrot/pbc_to_exe is unreadable: No such file or dire ctory Yes, this needs to be fixed, but it's not so urgent. Just the test is wrong. ... But all tests pass. More urgent for me is fixing the .include search path. [perl #56996] [TODO] remove non FHS-compliant searchpaths -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #51944] [DOCS] Cygwin Readme
On Thu, Jul 17, 2008 at 8:33 AM, Reini Urban [EMAIL PROTECTED] wrote: 2008/7/16 Will Coleda [EMAIL PROTECTED]: This looks good; I'd ask you double check which deps are required vs. optional: I'm pretty sure we don't -require- any of those packages. Ditto for their correspond build deps. (e.g. libgdbm-devel) Note, there are more cygwin-side updates to come to this README, which I will commit after my parrot-0.6.4 release (in 1-2 days). In which pod should we document the non-windows package requirements? Most of those packages have similar names anyway for every unix/posix platform. parrot is recursively listed as a build requirement oops. For the optional items, perl's Moose should be on the list (for smartlink), and Test::Perl::Critic/Perl::Critic for the critic tests. (Honestly we should have this documented somewhere else and just refer to it from here.) Good. Where? How about docs/dependencies.pod (new file)? This can house the optional systems we probe for, and a list of the non-core perl modules we're using (and what they're used for.) Thanks for the work on cygwin! -- Will Coke Coleda
[perl #46679] [TODO] [C] Check if we need to deallocate strerror strings
On Tue Feb 19 16:19:14 2008, Whiteknight wrote: On Mon Oct 22 09:49:02 2007, ptc wrote: In src/pmc/file.pmc there is the todo item: /* XXX Check if we need to deallocate strerror strings */ Do this. According to: http://www.cplusplus.com/reference/clibrary/cstring/strerror.html The strings returned by strerror() are statically allocated, and should not be modified or freed. I have not been able to find explicit confirmation of this fact anywhere else, however. I'll keep looking, but I think that we do not need to free them. --Andrew whitworth All the documentation and examples I've found agree that strerr returns a pointer to a static buffer that shouldn't be free'd. I'm calling this resolved.
[perl #57028] Re: pdd25cx and PGE optable bugs -- detailed analysis
# New Ticket Created by Allison Randal # Please include the string: [perl #57028] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57028 In a joint deugging session, chromatic and I confirmed that this is indeed a bug in the register allocator, specifically in the graph coloring register allocator, and not in the vanilla allocator (which is why it works when run outside the test harness, because Parrot is defaulting to the vanilla allocator). There's code in the allocator that turns off certain optimizations when it encounters the branching ops, and we need to treat 'local_branch' and 'local_return' similarly. For now, we've turned off the graph coloring allocator, so the pdd25cx branch passes all its tests, and language testing on the branch can proceed. This ticket is to remind us to look back into the graph coloring allocator. Also marked the following tests as TODO, because they expect the graph coloring allocator to be selected during the test run. t/compilers/imcc/imcpasm/optc.t #9 t/compilers/imcc/imcpasm/opt0.t #1 and 3 Allison Patrick R. Michaud wrote: The attached trace.out file contains a trace that demonstrates why PGE is failing its tests in the pdd25cx branch. I suspect the problem is with the register allocator -- perhaps being unable to correctly map registers when local_branch and local_return instructions are present. The line where the problem first manifests is PGE/OPTable.pir:331 : if has_stop == 0 goto key_search This line occurs in a loop that starts at the 'token_next' label on 309. Inside of that loop, the value of has_stop is never modified (in fact, it's not modified at all after the 'with_stop' label on line 280). The first time the if statement above is executed, has_stop correctly has a value of 1, as shown by line 97 in the trace output: # 1303 eq I5, 0, 40 I5=1 The next time through the loop, however, the value of has_stop (I5) has somehow been changed to zero (line 742 in the trace output), even though the original PIR doesn't modify has_stop at any point in the loop. # 1303 eq I5, 0, 40 I5=0 Line 128 of the trace seems to show where the I5 register is first modified after having had the correct value at line 97: # 1856 set I5, P7[wb] I5=1 P7=Hash=PMC(0x8454a98) This corresponds to line 539 of PGE/OPTable.pir: $I1 = token['wb'] The trace also shows the I5 register being modified at line 654 of the trace, which corresponds to line 492 of PGE/OPTable.pir: # 1710 set I5, P9[arity] I5=0 P9=Hash=PMC(0x8455454) arity = top['arity'] So, somehow imcc is re-using the same I5 register for each of has_stop, arity, and $I1 registers in the 'parse' method. At the bottom of this message are the instructions for reproducing this trace, as well as some other oddities I've noticed. I did try adding :unique_reg to all of the named registers in the 'parse' method where this problem occurs, but immc still ended up reusing the Chas_stop register for use in the C$I1 = token['wb'] instruction on PGE/OPTable.pir line 539. So, for a complete workaround I suppose we could try eliminating all temporary registers from the parse method as well, so that only named registers are used and they are always flagged with :unique_reg. But, before I do that I wanted to see if there were other options to explore first. (If we take the :unique_reg approach, we will probably have to do the same for generated code coming from PGE/Exp.pir and other places that make use of local_branch/local_return.) Hope this helps, Pm steps to produce the trace output on my system * Place the attached 03-optable.t file in the parrot root directory. This file is a version of t/compilers/pge/03-optable.t that has been modified to only run one failing test and to enable tracing of the 'parse' method invocation. * Run prove 03-optable.t trace.out 21 to produce a trace.out file. Two very interesting observations: 1. On my system, the test is sensitive to the name of the test file. For example, if I rename '03-optable.t' to 'opbug.t' and run prove on it as above then I get a different trace and the bug no longer manifests. 2. Running parrot directly on the 03-optable_1.pir file that is generated by the 'prove' step above produces the correct output, and the output trace indicates that different registers are being used as compared to when the program was run using 'prove' (even though the same 03-optable_1.pir file is used in both instances).
[perl #56798] [pdd25cx] test failure with NQP
On Thu Jul 10 11:00:14 2008, coke wrote: Since the NQP tests aren't run by default, ran them by hand in pdd25cx: Test Summary Report --- t/28-return.t(Wstat: 256 Tests: 1 Failed: 0) Non-zero exit status: 1 Parse errors: Bad plan. You planned 3 tests but ran 1. Files=28, Tests=182, 6 wallclock secs ( 0.04 usr 0.05 sys + 4.56 cusr 0.56 csys = 5.21 CPU) Result: FAIL $ perl t/harness t/28-return.t t/28-return..1/3 No exception handler and no message current instr.: 'bar' pc 227 (EVAL_6:78) called from Sub '_block11' pc 52 (EVAL_6:11) called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806 (src/PCT/HLLCompiler.pir:481) called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1088 (src/PCT/HLLCompiler.pir:610) called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1267 (src/PCT/HLLCompiler.pir:699) t/28-return.. Dubious, test returned 1 (wstat 256, 0x100) Failed 2/3 subtests This failure still occurs at revision 29555. -- Will Coke Coleda
[perl #46681] [TODO] [C] Use strerror_r instead of strerror
On Wed Apr 23 18:18:00 2008, [EMAIL PROTECTED] wrote: This thread trailed off about 4 months ago. Could we get an update on its status, i.e., whether it should be applied, what OSes it's passing on, etc. Thank you very much. kid51 The tests passed because the strerror/strerror_r code doesn't have any coverage. I added some tests that make sure the error message consists only of alphanumerics and whitespace in r29551. The tests pass with the current src/pmc/file.pmc, but fail with the attached patch. I don't have the tuits to fix the patch, but at least now it's obvious that it was broken.
[perl #56786] [pdd25cx] Segfault with tcl
On Thu Jul 10 06:40:28 2008, coke wrote:
Using tcl, I can make parrot segfault in this branch.
$ ../../parrot tcl.pbc -e error eek
Segmentation fault
Real tclsh, if you put that in a file and ran it, would say:
eek
while executing
error eek
(file foo.tcl line 1)
The backtrace is:
#0 0xb7b75357 in string_append (interp=0x804f040, a=0x2, b=0x81fa8e4)
at src/string.c:516
#1 0xb7b9a69b in Parrot_concat_s_sc (cur_opcode=0xb7a887f4,
interp=0x804f040)
at src/ops/string.ops:112
#2 0xb7c1c3e4 in runops_slow_core (interp=0x804f040, pc=0xb7a887f4)
at src/runops_cores.c:221
#3 0xb7bee9d6 in runops_int (interp=0x804f040, offset=3)
at src/interpreter.c:929
#4 0xb7bef2b3 in runops (interp=0x804f040, offs=3) at
src/inter_run.c:101
#5 0xb7bef550 in runops_args (interp=0x804f040, sub=0x82233a8,
obj=0x809dac0,
meth_unused=0x0, sig=0xb7e4e20f vP,
ap=0xbff5ce7c
è1\\b¸Îõ¿Pìï·\220Q\034\bè1\\b¨3\[EMAIL PROTECTED]) at
src/inter_run.c:223
#6 0xb7bef68c in Parrot_runops_fromc_args (interp=0x804f040,
sub=0x82233a8,
sig=0xb7e4e20f vP) at src/inter_run.c:295
#7 0xb7bd8b37 in Parrot_runcode (interp=0x804f040, argc=3,
argv=0xbff5cfe8)
at src/embed.c:944
#8 0xb7e2a812 in imcc_run_pbc (interp=0x804f040, obj_file=0,
output_file=0x0,
argc=3, argv=0xbff5cfe8) at compilers/imcc/main.c:783
#9 0xb7e2b202 in imcc_run (interp=0x804f040, sourcefile=0xbff5d9b0
tcl.pbc,
argc=3, argv=0xbff5cfe8) at compilers/imcc/main.c:1071
#10 0x08048988 in main (argc=3, argv=0xbff5cfe8) at src/main.c:61
This may be related to the intermediate test file I began with:
catch after result
if {$result != {wrong # args: should be after option ?arg arg ...?}}
{
puts -nonewline not
}
puts ok
The first line eval's the command after, and stores the error
message in result ([after] requires arguments). In tclsh, this
prints ok. Partcl in this branch prints not ok, and the result is
the empty string. This exception handler is in
runtime/builtin/catch.pir, beginning at line 81. If I comment out the
push_eh/pop_eh pair there, I get another segfault from the same bit of
C code, although the path to get there is different.
#0 0xb7b7a357 in string_append (interp=0x804f040, a=0x2, b=0x81fa8e4)
at src/string.c:516
#1 0xb7b9f69b in Parrot_concat_s_sc (cur_opcode=0xb7a8d7f4,
interp=0x804f040)
at src/ops/string.ops:112
#2 0xb7c213e4 in runops_slow_core (interp=0x804f040, pc=0xb7a8d7f4)
at src/runops_cores.c:221
#3 0xb7bf39d6 in runops_int (interp=0x804f040, offset=3253)
at src/interpreter.c:929
#4 0xb7bf42b3 in runops (interp=0x804f040, offs=3253) at
src/inter_run.c:101
#5 0xb7bf4550 in runops_args (interp=0x804f040, sub=0x843fde8,
obj=0x809dac0,
meth_unused=0x0, sig=0xb7e53530 vPS,
ap=0xbfd2010c \füC\bÐÃG¶°G\bH\001Ò¿Hÿ½·èýC\bÐÃG¶) at
src/inter_run.c:223
#6 0xb7bf468c in Parrot_runops_fromc_args (interp=0x804f040,
sub=0x843fde8,
sig=0xb7e53530 vPS) at src/inter_run.c:295
#7 0xb7be052a in Parrot_ex_throw_from_c (interp=0x804f040,
exception=0x843fc0c) at src/exceptions.c:302
#8 0xb7be05fe in Parrot_ex_throw_from_c_args (interp=0x804f040,
ret_addr=0x0,
exitcode=20, format=0xb7e5689c Class %Ss already registered!\n)
at src/exceptions.c:349
#9 0xb7c14ac1 in fail_if_type_exists (interp=0x804f040,
name=0x843fd5c)
at src/oo.c:632
#10 0xb7c14b34 in Parrot_oo_register_type (interp=0x804f040,
name=0x843fd5c)
at src/oo.c:662
SNIP
This is still occurring at revision 29555.
--
Will Coke Coleda
[perl #56800] [META] merge pdd25cx branch back into trunk
In r29552 of https://svn.perl.org/parrot/branches/pdd25cx I ran make test for: pipp, eclectus, hq9plus, lazy-k, m4, unlambda. All tests were passing. -- /* [EMAIL PROTECTED] */
[perl #57032] test failure in t/tools/dump_pbc.t (only in make smoke)
# New Ticket Created by Moritz Lenz # Please include the string: [perl #57032] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57032 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In parrot as of r29547 I get a failure while running make smoke: - - t/tools/dump_pbc.t perl: symbol lookup error: /usr/local/lib/perl5/5.10.0/i486-linux-gnu-thread-multi/auto/Cwd/Cwd.so: undefined symbol: Perl_Istack_sp_ptr # Failed test '01_temp_var.pir' # at t/tools/dump_pbc.t line 40. # '' # doesn't match '(?-xism:\=head1\ Simple\ Variables)' # Looks like you failed 1 test of 1. - - t/tools/parrot_debugger.t However when I run make test, all is fine. I ran both 'make test' and 'make smoke' multiple times, always with the same results. This is Debian Etch on i386 32bit with a vanilla perl-5.10.0 in /usr/local/ (which I use to build parrot) Cheers, Moritz - -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIfwlQAAkekJBI0yIRAju3AKCFf0p7Ji0qDVqmy/pmlBX/BV6RXQCZAcPh WEG0oXyHVnjw7VTK/ryqJ9g= =2476 -END PGP SIGNATURE-
Re: encoding vs charset
On Thu, Jul 17, 2008 at 5:20 AM, Allison Randal [EMAIL PROTECTED] wrote: The thing is, there's a tendency for data for a particular program or application to all be from the same character set (if, for example, you're parsing a series of files, munging the data in some way, and writing out a series of files as a result). We never want to force all data to be transformed into one canonical character set, because it significantly But that it's not my proposal. The proposal is to consider that all texts are already unicode, just encoded in his particular way. And there is no need to transform it unless asked, the same way that utf8 does not need to be converted to utf16 or utf32 if not asked. But better I'll leave this discussion, and not reopen it without first preparing a detailed proposal. -- Salu2
[perl #56804] [pdd25cx] Test failures
On Thu Jul 10 11:14:26 2008, coke wrote: The following tests fail during 'make test' on feather in the pd25cx branch. Test Summary Report --- t/op/gc.t (Wstat: 256 Tests: 20 Failed: 1) Failed test: 12 Non-zero exit status: 1 t/compilers/pge/03-optable.t (Wstat: 512 Tests: 35 Failed: 2) Failed tests: 34-35 Non-zero exit status: 2 t/compilers/pge/perl6regex/01-regex.t (Wstat: 6 Tests: 98 Failed: 0) Parse errors: No plan found in TAP output Files=585, Tests=10658, 367 wallclock secs ( 0.80 usr 1.68 sys + 136.67 cusr 42.41 csys = 181.56 CPU) Result: FAIL Failed 3/585 test programs. 3/10658 subtests failed. make: *** [test] Error 255 The only test result oddity in 'make test' for me now is a passing test (pop_eh out of context (2) # TODO handler dynamic scope) in t/op/exceptions.t All tests successful. Test Summary Report --- t/op/exceptions.t (Wstat: 0 Tests: 29 Failed: 0) TODO passed: 20 Files=1, Tests=29, 1 wallclock secs ( 0.01 usr 0.00 sys + 0.20 cusr 0.29 csys = 0.50 CPU) Result: PASS -- Will Coke Coleda
[perl #54930] [BUG] PGE build fails in pdd25cx branch
On Tue Jun 03 00:15:06 2008, [EMAIL PROTECTED] wrote: On Monday 02 June 2008 19:42:58 Will Coleda via RT wrote: Error earlier in the build process now, with PGE: /home/coke/bin/perl -e PGE/builtins_gen.pir ../../parrot -o PGE.pbc --output-pbc PGE.pir ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir -- output=PGE/builtins_gen.pir PGE/builtins.pg make: *** [PGE.pbc] Segmentation fault Running this last parrot invocation with -G avoids the segfault. I can't reproduce this with 32-bit x86 GNU/Linux, but I do see some segfaults in the PGE tests. -- c I am no longer seeing the build errors or any failures in the tests for PGE in branch. Resolving ticket. -- Will Coke Coleda
Re: [perl #56558] [PATCH] pdb rename to parrot_pdb
On Thu, Jul 17, 2008 at 9:46 AM, François Perrad [EMAIL PROTECTED] wrote: pdb was renamed parrot_debugger, but not installable_pdb. Done in r29556, thanks. -- Salu2
make: *** [perl6] Segmentation fault
Hi, I am using: Linux 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 i686 i386 GNU/Linux Fedora release 8 (Werewolf) gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33) The make target perl6 fails: $ make perl6 ... ... ... gmake[1]: Leaving directory `/home/saleem/work/compiler/parrot/languages/perl6' /usr/bin/perl -MExtUtils::Command -e cp languages/perl6/perl6 ./perl6 /usr/bin/perl -MExtUtils::Command -e ExtUtils::Command::chmod 0755 ./perl6 ./perl6 -esay 'Hello, world.' make: *** [perl6] Segmentation fault make: *** Deleting file `perl6' This also segfaults: $ languages/perl6/perl6 -esay 'Hello, world.' Segmentation fault When using ltrace: $ ltrace languages/perl6/perl6 -esay 'Hello, world.' __libc_start_main(0x8048920, 2, 0xbf987754, 0x8048ae0, 0x8048ad0 unfinished ... Parrot_set_config_hash_internal(0x81d0a60, 20376, 0x5af7fc8, 1, 0xb3fd65) = 20376 Parrot_new(0, 0x81d6bb4, 0xbf987698, 0x8048731, 0xb7f56000) = 0x846c008 string_from_cstring(0x846c008, 0xbf988738, 0, 0x8048731, 0xb7f56000) = 0x863d234 Parrot_set_executable_name(0x846c008, 0x863d234, 0, 0x8048731, 0xb7f56000) = 10 Parrot_set_flag(0x846c008, 512, 0, 0x8048731, 0xb7f56000) = 512 PackFile_new(0x846c008, 0, 0, 0x8048731, 0xb7f56000) = 0x8644f68 PackFile_unpack(0x846c008, 0x8644f68, 0x8048bc0, 0x187e90, 0xb7f56000) = 401316 do_sub_pragmas(0x846c008, 0x86450f0, 4, 0, 0xb7f56000) = 1052 Parrot_loadbc(0x846c008, 0x8644f68, 4, 0, 0xb7f56000) = 0x846c008 PackFile_fixup_subs(0x846c008, 1, 0, 0, 0xb7f56000) = 1052 Parrot_runcode(0x846c008, 2, 0xbf987754, 0, 0xb7f56000 unfinished ... --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ However the interactive mode is working fine: $ languages/perl6/perl6 say 'Hello, world.' Hello, world. [ctr-d] What may be wrong?
Re: [perl #56786] [pdd25cx] Segfault with tcl
On Thu, Jul 17, 2008 at 9:47 AM, Will Coleda via RT
[EMAIL PROTECTED] wrote:
On Thu Jul 10 06:40:28 2008, coke wrote:
Using tcl, I can make parrot segfault in this branch.
$ ../../parrot tcl.pbc -e error eek
Segmentation fault
Real tclsh, if you put that in a file and ran it, would say:
eek
while executing
error eek
(file foo.tcl line 1)
The backtrace is:
#0 0xb7b75357 in string_append (interp=0x804f040, a=0x2, b=0x81fa8e4)
at src/string.c:516
#1 0xb7b9a69b in Parrot_concat_s_sc (cur_opcode=0xb7a887f4,
interp=0x804f040)
at src/ops/string.ops:112
#2 0xb7c1c3e4 in runops_slow_core (interp=0x804f040, pc=0xb7a887f4)
at src/runops_cores.c:221
#3 0xb7bee9d6 in runops_int (interp=0x804f040, offset=3)
at src/interpreter.c:929
#4 0xb7bef2b3 in runops (interp=0x804f040, offs=3) at
src/inter_run.c:101
#5 0xb7bef550 in runops_args (interp=0x804f040, sub=0x82233a8,
obj=0x809dac0,
meth_unused=0x0, sig=0xb7e4e20f vP,
ap=0xbff5ce7c
è1\\b¸Îõ¿Pìï·\220Q\034\bè1\\b¨3\[EMAIL PROTECTED]) at
src/inter_run.c:223
#6 0xb7bef68c in Parrot_runops_fromc_args (interp=0x804f040,
sub=0x82233a8,
sig=0xb7e4e20f vP) at src/inter_run.c:295
#7 0xb7bd8b37 in Parrot_runcode (interp=0x804f040, argc=3,
argv=0xbff5cfe8)
at src/embed.c:944
#8 0xb7e2a812 in imcc_run_pbc (interp=0x804f040, obj_file=0,
output_file=0x0,
argc=3, argv=0xbff5cfe8) at compilers/imcc/main.c:783
#9 0xb7e2b202 in imcc_run (interp=0x804f040, sourcefile=0xbff5d9b0
tcl.pbc,
argc=3, argv=0xbff5cfe8) at compilers/imcc/main.c:1071
#10 0x08048988 in main (argc=3, argv=0xbff5cfe8) at src/main.c:61
This may be related to the intermediate test file I began with:
catch after result
if {$result != {wrong # args: should be after option ?arg arg ...?}}
{
puts -nonewline not
}
puts ok
The first line eval's the command after, and stores the error
message in result ([after] requires arguments). In tclsh, this
prints ok. Partcl in this branch prints not ok, and the result is
the empty string. This exception handler is in
runtime/builtin/catch.pir, beginning at line 81. If I comment out the
push_eh/pop_eh pair there, I get another segfault from the same bit of
C code, although the path to get there is different.
#0 0xb7b7a357 in string_append (interp=0x804f040, a=0x2, b=0x81fa8e4)
at src/string.c:516
#1 0xb7b9f69b in Parrot_concat_s_sc (cur_opcode=0xb7a8d7f4,
interp=0x804f040)
at src/ops/string.ops:112
#2 0xb7c213e4 in runops_slow_core (interp=0x804f040, pc=0xb7a8d7f4)
at src/runops_cores.c:221
#3 0xb7bf39d6 in runops_int (interp=0x804f040, offset=3253)
at src/interpreter.c:929
#4 0xb7bf42b3 in runops (interp=0x804f040, offs=3253) at
src/inter_run.c:101
#5 0xb7bf4550 in runops_args (interp=0x804f040, sub=0x843fde8,
obj=0x809dac0,
meth_unused=0x0, sig=0xb7e53530 vPS,
ap=0xbfd2010c \füC\bÐÃG¶°G\bH\001Ò¿Hÿ½·èýC\bÐÃG¶) at
src/inter_run.c:223
#6 0xb7bf468c in Parrot_runops_fromc_args (interp=0x804f040,
sub=0x843fde8,
sig=0xb7e53530 vPS) at src/inter_run.c:295
#7 0xb7be052a in Parrot_ex_throw_from_c (interp=0x804f040,
exception=0x843fc0c) at src/exceptions.c:302
#8 0xb7be05fe in Parrot_ex_throw_from_c_args (interp=0x804f040,
ret_addr=0x0,
exitcode=20, format=0xb7e5689c Class %Ss already registered!\n)
at src/exceptions.c:349
#9 0xb7c14ac1 in fail_if_type_exists (interp=0x804f040,
name=0x843fd5c)
at src/oo.c:632
#10 0xb7c14b34 in Parrot_oo_register_type (interp=0x804f040,
name=0x843fd5c)
at src/oo.c:662
SNIP
This is still occurring at revision 29555.
--
Will Coke Coleda
This is very likely due to the fact that tcl has its own set of
opcodes for throwing exceptions that need to be updated to match,
e.g., the die opcode in the new branch.
--
Will Coke Coleda
Re: [perl #56786] [pdd25cx] Segfault with tcl
On Thu, Jul 17, 2008 at 11:26 AM, Will Coleda [EMAIL PROTECTED] wrote:
On Thu, Jul 17, 2008 at 9:47 AM, Will Coleda via RT
[EMAIL PROTECTED] wrote:
On Thu Jul 10 06:40:28 2008, coke wrote:
Using tcl, I can make parrot segfault in this branch.
$ ../../parrot tcl.pbc -e error eek
Segmentation fault
Real tclsh, if you put that in a file and ran it, would say:
eek
while executing
error eek
(file foo.tcl line 1)
The backtrace is:
#0 0xb7b75357 in string_append (interp=0x804f040, a=0x2, b=0x81fa8e4)
at src/string.c:516
#1 0xb7b9a69b in Parrot_concat_s_sc (cur_opcode=0xb7a887f4,
interp=0x804f040)
at src/ops/string.ops:112
#2 0xb7c1c3e4 in runops_slow_core (interp=0x804f040, pc=0xb7a887f4)
at src/runops_cores.c:221
#3 0xb7bee9d6 in runops_int (interp=0x804f040, offset=3)
at src/interpreter.c:929
#4 0xb7bef2b3 in runops (interp=0x804f040, offs=3) at
src/inter_run.c:101
#5 0xb7bef550 in runops_args (interp=0x804f040, sub=0x82233a8,
obj=0x809dac0,
meth_unused=0x0, sig=0xb7e4e20f vP,
ap=0xbff5ce7c
è1\\b¸Îõ¿Pìï·\220Q\034\bè1\\b¨3\[EMAIL PROTECTED]) at
src/inter_run.c:223
#6 0xb7bef68c in Parrot_runops_fromc_args (interp=0x804f040,
sub=0x82233a8,
sig=0xb7e4e20f vP) at src/inter_run.c:295
#7 0xb7bd8b37 in Parrot_runcode (interp=0x804f040, argc=3,
argv=0xbff5cfe8)
at src/embed.c:944
#8 0xb7e2a812 in imcc_run_pbc (interp=0x804f040, obj_file=0,
output_file=0x0,
argc=3, argv=0xbff5cfe8) at compilers/imcc/main.c:783
#9 0xb7e2b202 in imcc_run (interp=0x804f040, sourcefile=0xbff5d9b0
tcl.pbc,
argc=3, argv=0xbff5cfe8) at compilers/imcc/main.c:1071
#10 0x08048988 in main (argc=3, argv=0xbff5cfe8) at src/main.c:61
This may be related to the intermediate test file I began with:
catch after result
if {$result != {wrong # args: should be after option ?arg arg ...?}}
{
puts -nonewline not
}
puts ok
The first line eval's the command after, and stores the error
message in result ([after] requires arguments). In tclsh, this
prints ok. Partcl in this branch prints not ok, and the result is
the empty string. This exception handler is in
runtime/builtin/catch.pir, beginning at line 81. If I comment out the
push_eh/pop_eh pair there, I get another segfault from the same bit of
C code, although the path to get there is different.
#0 0xb7b7a357 in string_append (interp=0x804f040, a=0x2, b=0x81fa8e4)
at src/string.c:516
#1 0xb7b9f69b in Parrot_concat_s_sc (cur_opcode=0xb7a8d7f4,
interp=0x804f040)
at src/ops/string.ops:112
#2 0xb7c213e4 in runops_slow_core (interp=0x804f040, pc=0xb7a8d7f4)
at src/runops_cores.c:221
#3 0xb7bf39d6 in runops_int (interp=0x804f040, offset=3253)
at src/interpreter.c:929
#4 0xb7bf42b3 in runops (interp=0x804f040, offs=3253) at
src/inter_run.c:101
#5 0xb7bf4550 in runops_args (interp=0x804f040, sub=0x843fde8,
obj=0x809dac0,
meth_unused=0x0, sig=0xb7e53530 vPS,
ap=0xbfd2010c \füC\bÐÃG¶°G\bH\001Ò¿Hÿ½·èýC\bÐÃG¶) at
src/inter_run.c:223
#6 0xb7bf468c in Parrot_runops_fromc_args (interp=0x804f040,
sub=0x843fde8,
sig=0xb7e53530 vPS) at src/inter_run.c:295
#7 0xb7be052a in Parrot_ex_throw_from_c (interp=0x804f040,
exception=0x843fc0c) at src/exceptions.c:302
#8 0xb7be05fe in Parrot_ex_throw_from_c_args (interp=0x804f040,
ret_addr=0x0,
exitcode=20, format=0xb7e5689c Class %Ss already registered!\n)
at src/exceptions.c:349
#9 0xb7c14ac1 in fail_if_type_exists (interp=0x804f040,
name=0x843fd5c)
at src/oo.c:632
#10 0xb7c14b34 in Parrot_oo_register_type (interp=0x804f040,
name=0x843fd5c)
at src/oo.c:662
SNIP
This is still occurring at revision 29555.
--
Will Coke Coleda
This is very likely due to the fact that tcl has its own set of
opcodes for throwing exceptions that need to be updated to match,
e.g., the die opcode in the new branch.
--
Will Coke Coleda
I committed a patch (r29559) that updates all the tcl.ops to be more
like the 'die' opcode in how the exception object is constructed and
created. Still segfaulting. As long as I'm in here, I'm going to
eliminate the forms of tcl_error that are now identical to 'die'.
--
Will Coke Coleda
Re: [perl #56786] [pdd25cx] Segfault with tcl
On Thursday 17 July 2008 08:49:05 Will Coleda wrote: I committed a patch (r29559) that updates all the tcl.ops to be more like the 'die' opcode in how the exception object is constructed and created. Still segfaulting. As long as I'm in here, I'm going to eliminate the forms of tcl_error that are now identical to 'die'. Throw a backtrace this way (better if you can figure out what's null) and it might tickle out some solutions. -- c
Re: [perl #56800] [META] merge pdd25cx branch back into trunk
Bernhard Schmalhofer via RT a écrit :
In r29552 of https://svn.perl.org/parrot/branches/pdd25cx I ran make test
for: pipp, eclectus, hq9plus, lazy-k, m4, unlambda.
All tests were passing.
in branch_pdd25cx, 221/1109 Lua subtests failed.
Mostly for same reason : exception handling.
$ cat nil.lua
print(- nil)
[trunk] $ parrot luc.pbc nil.lua
lua.pbc: EVAL_1:33: attempt to perform arithmetic on a nil value
stack traceback:
EVAL_1:33 in function 'main_10'
languages/lua/src/lib/luaaux.pir:788 in function 'docall'
lua.pir:303 in function 'handle_script'
lua.pir:123 in function 'main'
[branch_pdd25cx] $ parrot lua.pbc nil.lua
lua.pbc: attempt to perform arithmetic on a nil value
in this example, the exception is raised by the following code in
languages/lua/src/pmc/luaany.pmc (line #216)
PMC* neg(PMC *dest) {
PMC *meth = find_meth(INTERP, SELF, __unm);
if (!meth)
Parrot_ex_throw_from_c_args(INTERP, NULL,
EXCEPTION_ILL_INHERIT,
attempt to perform arithmetic on a %Ss value,
SELF.name());
...
The global exception handler for Lua is in
languages/lua/src/lib/luaaux.pir (lines 775-823),
with the function 'docall' and the closure 'traceback'.
Missing data are retrieved with the methods 'where' 'traceback'
implemented in languages/lua/src/pmc/lua.pmc.
How rewrites it in branch_pdd25cx ?
François.
Re: [perl #56786] [pdd25cx] Segfault with tcl
On Thu, Jul 17, 2008 at 12:31 PM, chromatic via RT
[EMAIL PROTECTED] wrote:
On Thursday 17 July 2008 08:49:05 Will Coleda wrote:
I committed a patch (r29559) that updates all the tcl.ops to be more
like the 'die' opcode in how the exception object is constructed and
created. Still segfaulting. As long as I'm in here, I'm going to
eliminate the forms of tcl_error that are now identical to 'die'.
Throw a backtrace this way (better if you can figure out what's null) and it
might tickle out some solutions.
-- c
Found the segfault occurred shortly after trying to get the
stacktrace attribute from an exception; Allison noted that
src/pmc/exception.pmc's get_pmc_keyed and set_pmc_keyed are using
getprop/setprop. This naive patch makes them use the new ATTR
implementation.
Index: src/pmc/exception.pmc
===
--- src/pmc/exception.pmc (revision 29555)
+++ src/pmc/exception.pmc (working copy)
@@ -260,7 +260,7 @@
VTABLE PMC *get_pmc_keyed(PMC *key) {
STRING *s = key_string(INTERP, key);
-return SELF.getprop(s);
+return SELF.get_attr_str(s);
}
@@ -389,7 +389,7 @@
VTABLE void set_pmc_keyed(PMC *key, PMC *value) {
STRING *s = key_string(INTERP, key);
-SELF.setprop(s, value);
+SELF.set_attr_str(s, value);
}
- This dramatically improves tcl's pass rate (still not 100%, though)
- Make test now reports failures:
t/examples/shootout.t (Wstat: 2816 Tests: 20 Failed: 11)
Failed tests: 3, 6-11, 14, 17-19
Non-zero exit status: 11
- Probably need a test for these vtables.
- No change in the number of lua subtest failures with this patch.
--
Will Coke Coleda
[perl #56786] [pdd25cx] Segfault with tcl
On Thu Jul 17 09:31:27 2008, [EMAIL PROTECTED] wrote:
On Thursday 17 July 2008 08:49:05 Will Coleda wrote:
I committed a patch (r29559) that updates all the tcl.ops to be more
like the 'die' opcode in how the exception object is constructed and
created. Still segfaulting. As long as I'm in here, I'm going to
eliminate the forms of tcl_error that are now identical to 'die'.
Throw a backtrace this way (better if you can figure out what's null)
and it
might tickle out some solutions.
-- c
It was in the original ticket, but here's an update with some more details.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6c828d0 (LWP 21358)]
0xb7c10627 in string_append (interp=0x804f040, a=0x2, b=0x820e4e4)
at src/string.c:518
518 if (a == NULL || PObj_bufstart(a) == NULL)
(gdb) bt
#0 0xb7c10627 in string_append (interp=0x804f040, a=0x2, b=0x820e4e4)
at src/string.c:518
#1 0xb7c35d2b in Parrot_concat_s_sc (cur_opcode=0xb7b237f4,
interp=0x804f040)
at src/ops/string.ops:112
#2 0xb7cb8934 in runops_slow_core (interp=0x804f040, pc=0xb7b237f4)
at src/runops_cores.c:221
SNIP
(gdb) l
513 const UINTVAL b_len = b ? string_length(interp, b) : 0;
514 if (!b_len)
515 return a;
516
517 /* Is A real? */
518 if (a == NULL || PObj_bufstart(a) == NULL)
519 return string_copy(interp, b);
520
521 saneify_string(a);
522 saneify_string(b);
(gdb) p *b
$4 = {cache = {_b = {_bufstart = 0xb6c62890, _buflen = 4}, _ptrs = {
_struct_val = 0xb6c62890, _pmc_val = 0x4}, _i = {_int_val =
-1228527472,
_int_val2 = 4}, _num_val = 1.0003005735938968e-313,
_string_val = 0xb6c62890}, flags = 397568, strstart = 0xb6c62890 \n,
bufused = 1, strlen = 1, hashval = 0, encoding = 0x806fd88,
charset = 0x8071328}
(gdb) p *a
Cannot access memory at address 0x2
--
Will Coke Coleda
Re: [perl #34549] atan2() isn't IEEE compliant on OpenBSD/*BSD/Cygwin/Solaris
On Wed, 16 Jul 2008, Andrew Whitworth via RT wrote: Is this still not resolved? This ticket has not seen any discussion since 2006. To double-check, I think we need people to check t/op/trans.t on: *Solaris *OpenBSD *NetBSD *Cygwin If it passes all these platforms, I think the ticket is resolved. If not, maybe we need to break this into more-specific sub-tickets for each failing platform. It still fails in the identical way on Solaris 8/SPARC with gcc. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #57006] [PATCH] add cygwin opengl config quirks
Donald Hunter via RT schrieb:
Sorry rurban, this patch will break on my cygwin installation. I think
the problem is caused by more than an assumption that mingw eq cygwin.
The real problem is that Cygwin hosts three flavours of library for
OpenGL: mingw, cygwin/w32api, cygwin/X11.
All your patch does is switch from Cygwin/w32api to Cygwin/X11.
Please see rt#56628 for more details.
Ah thanks. I missed your recent common on this.
http://rt.perl.org/rt3/Public/Bug/Display.html?id=56628
The problem I had with the w32api libs was -lglut32. with linking
directly to the dll /usr/bin/glut32.dll everything works fine, and I'll
get rid of freeglut as default.
Now I only have to find out whatÄs wrong with that importlib, then I
send the revised patch. for now it is:
--- origsrc/parrot-0.6.4/config/auto/opengl.pm 2008-06-02
17:35:05.0 +
+++ src/parrot-0.6.4/config/auto/opengl.pm 2008-07-17 19:14:11.0
+
@@ -89,7 +89,6 @@
On Windows, Parrot supports three different compiler environments, each of
which has different requirements for OpenGL support:
-
=head3 MSVC
=over 4
@@ -104,16 +103,21 @@
=back
-
=head3 MinGW
: No details yet
+=head3 Cygwin/w32api
-=head3 cygwin
+The Cygwin/w32api for native opengl support
- : No details yet
+F-lglut32 -lglu32 -lopengl32
+
+=head3 Cygwin/X
+
+Requires a X server.
+Ffreeglut, Flibglut-devel
=cut
@@ -159,15 +163,23 @@
my $osname = $conf-data-get_p5('OSNAME');
-$self-_add_to_libs( {
-conf= $conf,
-osname = $osname,
-cc = $cc,
-win32_gcc = '-lglut32 -lglu32 -lopengl32',
-win32_nongcc= 'opengl32.lib glu32.lib glut32.lib',
-darwin = '-framework OpenGL -framework GLUT',
-default = '-lglut -lGLU -lGL',
-} );
+# Prefer Cygwin/w32api over Cygwin/X, but use X when DISPLAY is set
+if ($^O eq 'cygwin' and $ENV{DISPLAY}) {
+ $self-_add_to_libs( {
+ conf= $conf,
+ osname = $osname,
+ cc = $cc,
+ cygwin = '-lglut -L/usr/X11R6/lib -lGLU -lGL'
+} ) } else {
+ $self-_add_to_libs( {
+ conf= $conf,
+osname = $osname,
+cc = $cc,
+win32_gcc = '-lglut32 -lglu32 -lopengl32',
+win32_nongcc= 'opengl32.lib glu32.lib glut32.lib',
+darwin = '-framework OpenGL -framework GLUT',
+default = '-lglut -lGLU -lGL',
+} ) };
# On OS X check the presence of the OpenGL headers in the standard
# Fink/macports locations.
[perl #46681] [TODO] [C] Use strerror_r instead of strerror
On Thu Jul 17 01:17:51 2008, cotto wrote:
On Wed Apr 23 18:18:00 2008, [EMAIL PROTECTED] wrote:
This thread trailed off about 4 months ago. Could we get an update on
its status, i.e., whether it should be applied, what OSes it's passing
on, etc.
Thank you very much.
kid51
The tests passed because the strerror/strerror_r code doesn't have any
coverage. I added some tests that make sure the error message consists
only of alphanumerics and whitespace in r29551. The tests pass with the
current src/pmc/file.pmc, but fail with the attached patch. I don't
have the tuits to fix the patch, but at least now it's obvious that it
was broken.
With this patch, the new tests still pass on Linux/x86. The patch uses
STRING-strstart to avoid leaking a malloc'd buffer when throwing an
exception, which may or may not be considered kosher in this situation.
If this is judged appropriate, I'd appreciate test confirmation from at
least OSX/x86 and Windows since strerror_r seems to be a special function.
Index: src/pmc/file.pmc
===
--- src/pmc/file.pmc (revision 29551)
+++ src/pmc/file.pmc (working copy)
@@ -26,6 +26,21 @@
/* RT#46681 apparently, strerror_r is thread-safe and should be used instead.*/
+/* strerror_r should truncate the message if its too long for the supplied buffer
+ * it's probably best to just specify a sane default buffer size than to worry
+ * about retrying calls
+ */
+#define ERRBUF_SIZE 128
+
+#define STRERROR_R_EXCEPTION() \
+{ \
+char errmsg[ERRBUF_SIZE]; \
+char *errstr = strerror_r(errno, errmsg, ERRBUF_SIZE); \
+STRING *errmsg_pstring = string_make(interp, errstr, strlen(errstr), NULL, 0); \
+real_exception(interp, NULL, E_SystemError, errmsg_pstring-strstart); \
+}
+
+
static PMC *File_PMC;
pmclass File singleton {
@@ -89,6 +104,7 @@
*/
+
METHOD is_dir(STRING *path) {
struct stat info;
char *cpath = string_to_cstring(interp, path);
@@ -100,8 +116,7 @@
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
if (S_ISDIR(info.st_mode))
@@ -131,8 +146,7 @@
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
if (S_ISREG(info.st_mode))
@@ -164,8 +178,7 @@
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
if (S_ISLNK(info.st_mode))
@@ -199,6 +212,8 @@
string_cstring_free(cfrom);
+char errmsg[ERRBUF_SIZE];
+
if (source) {
char *cto= string_to_cstring(interp, to);
FILE *target = fopen(cto, w+b);
@@ -223,14 +238,12 @@
fclose(target);
}
else {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
fclose(source);
}
else {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
#undef CHUNK_SIZE
}
@@ -254,8 +267,7 @@
string_cstring_free(cto);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION();
}
}
}
Index: config/gen/platform/win32/string.h
===
--- config/gen/platform/win32/string.h (revision 29551)
+++ config/gen/platform/win32/string.h (working copy)
@@ -14,6 +14,8 @@
# endif
#endif
+#define strerror_r(errnum, buf, buflen) strerror_s(buf, buflen, errnum)
+
#endif /* PARROT_PLATFORM_WIN32_STRING_H_GUARD */
/*
Re: [perl #57006] [PATCH] add cygwin opengl config quirks
On Thu, 2008-07-17 at 22:50 +0200, Reini Urban wrote:
The problem I had with the w32api libs was -lglut32. with linking
directly to the dll /usr/bin/glut32.dll everything works fine, and I'll
get rid of freeglut as default.
I'm not sure I understand what you meant here.
Now I only have to find out whatÄs wrong with that importlib, then I
send the revised patch. for now it is:
I'm fine with the patch conceptually, but some details:
--- origsrc/parrot-0.6.4/config/auto/opengl.pm2008-06-02
-
=head3 MSVC
-
=head3 MinGW
I find it easier to read raw POD with two lines of blank above headers;
please don't remove these. :-)
+=head3 Cygwin/w32api
-=head3 cygwin
+The Cygwin/w32api for native opengl support
- : No details yet
+F-lglut32 -lglu32 -lopengl32
These should be replaced with the actual package names you need to
install (w32api, opengl, ...?)
+Requires a X server.
In this case, use 'an' instead of 'a'.
Also note that Coke had discussed moving this kind of optional library
requirements documentation to a separate file in docs/ -- if that is
done, then most of the POD from this file can be moved there, leaving
just a stub with a link to make the file in docs/ easy to find.
+# Prefer Cygwin/w32api over Cygwin/X, but use X when DISPLAY is set
How about:
# Prefer Cygwin/w32api over Cygwin/X unless DISPLAY is set
+ cygwin = '-lglut -L/usr/X11R6/lib -lGLU -lGL'
Why not just use 'win32_gcc' here? Otherwise, it's not clear below how
this relates to win32_gcc in the non-X case.
+} ) } else {
Please uncuddle that else. :-)
Thanks for your work on this, rurban!
-'f
Re: make: *** [perl6] Segmentation fault
Seeing the same thing Linux 2.6.18-53.1.21.el5xen #1 SMP gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-14) perl, v5.10.0 built for i686-linux however: ./parrot languages/perl6/perl6.pbc -e 'say hello world ' hello world $ languages/perl6/perl6 say hello hello [EMAIL PROTECTED] parrot]$ languages/perl6/perl6 -e 'say hello' Segmentation fault Hmm: [EMAIL PROTECTED] parrot]$ languages/perl6/perl6 -e ' say hello' hello [EMAIL PROTECTED] parrot]$ languages/perl6/perl6 -e 'say hello' Segmentation fault a --- Andy Bach Systems Mangler Internet: [EMAIL PROTECTED] Voice: (608) 261-5738 Fax: 264-5932 Accordion, n.:A bagpipe with pleats.
Re: [perl #46681] [TODO] [C] Use strerror_r instead of strerror
On Thu, Jul 17, 2008 at 9:59 PM, Christoph Otto via RT [EMAIL PROTECTED] wrote: With this patch, the new tests still pass on Linux/x86. The patch uses STRING-strstart to avoid leaking a malloc'd buffer when throwing an exception, which may or may not be considered kosher in this situation. Can't you use real_exception(interp, NULL, E_SystemError, %Ss, errmsg_pstring); ? Using internal details of parrot strings must be avoided. -- Salu2
[perl #55954] [PATCH]: Add 'make smolder_test' target
Michael: I install TAP::Harness::Archive from CPAN, then applied the patches to a fresh checkout from trunk. I configured, built and ran 'make smolder_test'. The Smolder test completed and stated that it uploaded -- though I have a tough time matching my particular report to those at http://smolder.plusthree.com/app/public_projects/smoke_reports/8. More importantly, running the Smolder test revealed that lib/Parrot/Harness/Smoke.pm was itself in violation of some t/codingstd/perlcritic.t standards. 08:37 dalek : Committing Michael Peters' most recent patches for Smolder testing 08:37 dalek : (http://rt.perl.org/rt3/Ticket/Display.html?id=55954). NOTE: 08:37 dalek : lib/Parrot/Harness/Smoke.pm is failing perlcritic.t policy re comments with 08:37 dalek : 'TODO' -- a failure I found out by running make smolder_test itself! 08:37 dalek diff: http://www.parrotvm.org/svn/parrot/revision?rev=29572 not ok 166 - Test::Perl::Critic for /home/jimk/work/forsmolder/lib/Parrot/Harness/Smoke.pm # Failed test 'Test::Perl::Critic for /home/jimk/work/forsmolder/lib/Parrot/Harness/Smoke.pm' # at t/codingstd/perlcritic.t line 69. # # Perl::Critic found these violations in /home/jimk/work/forsmolder/lib/Parrot/Harness/Smoke.pm: # Flag comment 'TODO' found at /home/jimk/work/forsmolder/lib/Parrot/Harness/Smoke.pm line 100 # Flag comment 'TODO' found at /home/jimk/work/forsmolder/lib/Parrot/Harness/Smoke.pm line 108 I was told on #parrot that you have to replace # TODO comments by creating RT tickets and referencing the RT instead of the TODO. Perhaps it would be simpler to just delete these comments. Please advise. Thank you very much. kid51
[perl #56948] [BUG] .parrot_current_rev broken
On Wed Jul 16 06:27:16 2008, julianalbo wrote:
On Wed, Jul 16, 2008 at 1:12 PM, James Keenan via RT
[snip]
If no one gets to this today I will try to work on this this evening.
Go for it.
On Wed Jul 16 04:12:35 2008, [EMAIL PROTECTED] wrote:
[snip]
The control flow here is somewhat awkward and creates additional
branches which will need coverage in testing (cf t/configure/017 and 018):
33 if (defined ($prev) ($revision ne $prev)) {
34 $revision = 'unknown' unless defined $revision;
This is a case where things can be improved by (a) making the control
flow a bit more explicit and (b) using Devel::Cover for coverage
analysis during testing.
Suppose we rewrite line 34 as:
if (! defined $revision) {
$revision = 'unknown';
} else {
# do something else
}
If we were to try to write tests for both the defined and undefined
cases for $revision, we'd soon see that in the undefined case we would
get an uninitialized value warning on line 33 in the second part of the
outer 'if' branch:
($revision ne $prev)
Line 33 strongly assumes that $revision is defined, so to question its
definedness on Line 34 is dubious.
So I re-ordered this part of the module, then wrote tests which cover
each branch and placed them at the end of
t/configure/017-revision_from_cache.t and in new test file
t/configure/061-revision_from_cache.t. The code is more verbose, less
idiomatic -- those things we can fix later. But in the meantime we can
see the flow better and write tests which exercise more of its nooks and
crannies.
Reini et al: Please evaluate the attached patch. Alternatively, you
can do: svn co https://svn.perl.org/parrot/branches/revisionpm.
As usual, I'll apply in a couple of days if there is no objection.
Thank you very much.
kid51
language testing on pdd25cx, preparing to merge
From: Allison Randal [EMAIL PROTECTED] Date: Thu, 17 Jul 2008 01:27:14 -0700 After temporarily disabling the graph coloring register allocator, the pdd25cx branch passes all Parrot tests. Please run the tests for your language and report/debug any test failures that are different than the test failures in trunk. The plan is to merge the branch back into trunk on Friday or Saturday. Allison The same Kea-CL tests are failing in pdd25cx revision 29565 as I mentioned in this message: From: Bob Rogers [EMAIL PROTECTED] Date: Tue, 8 Jul 2008 22:21:06 -0400 . . . I am seeing three test failures when it should execute a pushaction sub, but does not. Two are when transferring control to an error handler, and another when calling a continuation . . . I will try to write a test case for this, but not before Saturday at the earliest. -- Bob
