Re: [svn:parrot] r30941 - branches/pdd27mmd/src
chromatic wrote: That C string leaks. We should have a diagnostic printf which supports the %Ss format we use in exception formatting strings. We have one, it's called PIO_fprintf. But, it's only used once in the repository, in an STM macro. Added to the I/O milestone tasklist. Allison
Re: [svn:parrot] r30941 - branches/pdd27mmd/src
On Wed, Sep 10, 2008 at 9:21 AM, Allison Randal [EMAIL PROTECTED] wrote: chromatic wrote: That C string leaks. We should have a diagnostic printf which supports the %Ss format we use in exception formatting strings. We have one, it's called PIO_fprintf. But, it's only used once in the repository, in an STM macro. We have more: PIO_printf, PIO_eprintf, Parrot_printf, Parrot_eprintf and Parrot_fprintf. The Parrot_ ones are a wrapper around the PIO_s, with added check for extern usage, and that does not need #include io files. The eprintf ones are adequate for diagnostic messages. But note that his usage with a NULL interpreter argument is flawed, only adequate for plain strings. But if you have a parrot string surely you have a parrot interpreter. -- Salu2
[perl #44457] [TODO] make sure files match test files for DYNPMCs and DYNOPs etc
On Mon Aug 06 06:08:54 2007, pcoch wrote: In the file t/distro/test_file_coverage.t there is the todo item: # TODO: DYNPMC, DYNOPS, etc This is in the context of making sure that the files match the test files. This needs to be implemented. Is this as simple as writing a test to make sure every src/dynpmc/*.pmc and src/dynoplibs/*.ops has a matching t/dynpmc/*.t and t/dynoplibs/*.t ? If so, this would be an ideal task for one of our recent volunteers, since the code would be pure Perl. Also, the test will fail without an exception for src/dynpmc/rotest.pmc. I don't know if a test should be written for this PMC or not.
Re: request for help (only a little :-): build pirc on linux
sorry, documentation and source should be reorganized at some point. For now, please check out compilers/pirc/README.pod. sorry for the confusion, kjs On Tue, Sep 9, 2008 at 5:31 PM, NotFound [EMAIL PROTECTED] wrote: I put the commands that I'm using in the README file (but that's for MSVC on windows), but I don't have any knowledge on how to do this on linux. There is no README file in compilers/pirc/new -- Salu2
Re: [perl #58236] [TODO][PDD19] make decision on open issue on .return directive in pdd19
On Sat, Aug 30, 2008 at 10:40 AM, Allison Randal [EMAIL PROTECTED] wrote:
Klaas-Jan Stol wrote:
On Sat, Aug 30, 2008 at 11:04 AM, Allison Randal [EMAIL PROTECTED]
wrote:
Yes, it will be deprecated, or at least renamed. The C.return
directive
without parentheses is an old convention for passing a single return
result,
and must always be sandwiched between C.begin_return and
C.end_return.
Do you mean this one? (see next)
.begin_return
.return hi
.return 42
.return 3.14
.end_return
(which is the same as: .return (hi, 42, 3.14) )
Is the purpose of renaming this to make a clear distinction between the
'.return' directive in this long style of returning and the short one
('.return ()' ) ?
Yes. That whole set of directives would benefit from clearer naming.
Perhaps:
.set_return hi # return value passed, between .begin_return
# and .end_return
.set_arg foo # argument passed, between .begin_call and .end_call
.get_result # result retrieved, between .call and .end_call
And, there's another C.return without parentheses that performs a
tail-call, invoking a sub or method reusing the same return continuation.
This should also be renamed.
Is the purpose to be more explicit on being a tailcall? (in that case, it
could be renamed as .tailcall or whatever -- but that's obvious)
Obvious is good.
The only directive that should be named C.return is the one that returns
a value or values (i.e. it's syntactic sugar for a whole collection of
low-level directives/opcodes).
and this would be: .return (hi, 42, 3.14)
right?
Yes.
Allison
Allison:
I made the following changes in pirc/new:
.arg - .set_arg
.result - .get_result
.return - .tailcall (in context of .return foo() , which thus is now:
.tailcall foo() )
.return - .set_return (in long-style returning : .begin/end_return
.yield - .set_yield ( in long-style yielding : .begin/end_yield)
From your answers in your previous reply I deduce you support such changes.
Can you reconfirm, then I'll make the appropriate changes in PDD19.
thanks,
kjs
Re: [svn:parrot] r30941 - branches/pdd27mmd/src
NotFound wrote: On Wed, Sep 10, 2008 at 9:21 AM, Allison Randal [EMAIL PROTECTED] wrote: chromatic wrote: That C string leaks. We should have a diagnostic printf which supports the %Ss format we use in exception formatting strings. We have one, it's called PIO_fprintf. But, it's only used once in the repository, in an STM macro. We have more: PIO_printf, PIO_eprintf, Parrot_printf, Parrot_eprintf and Parrot_fprintf. The Parrot_ ones are a wrapper around the PIO_s, with added check for extern usage, and that does not need #include io files. Yes, to be more accurate, we have a whole range of PIO functions. But, the fact that they're used so rarely makes me doubt whether they're particularly reliable. The eprintf ones are adequate for diagnostic messages. But note that his usage with a NULL interpreter argument is flawed, only adequate for plain strings. But if you have a parrot string surely you have a parrot interpreter. Aye, that part shouldn't be a problem. Allison
Re: [svn:parrot] r30941 - branches/pdd27mmd/src
We have more: PIO_printf, PIO_eprintf, Parrot_printf, Parrot_eprintf and Parrot_fprintf. The Parrot_ ones are a wrapper around the PIO_s, with added check for extern usage, and that does not need #include io files. Yes, to be more accurate, we have a whole range of PIO functions. But, the fact that they're used so rarely makes me doubt whether they're particularly reliable. From other perspective: if they are not used, we never be sure that they are reliable. If we access to string internals to avoid his usage, we are actively making strings less reliable. And no wonder that %Ss is rarely used, a lot of people doesn't even know that it exists. And if they never see it used in place of code where will be the correct solution, we can hardly blame them. By the way, as mentioned in other thread there is a problem with plain %s in parrot printf-alike functions. It does not handle well a NULL c string. This must be fixed. And before, given the current implementation, the behavior of string_make and his successor in the strings pdd, when receiving a NULL c string must be documented and implemented, or we risk to plague the code base with lots of more workarounds. -- Salu2
Re: [perl #51262] [BUG] Segfault in pdump
I've recently commited a fix on null string constants. I think it was the same problem described here. I compiled the pir file and pdumped without a problem, it shows the DATA = NULL my fix introduced. Can you verify the problem is gone? I assume you are referring to r30756 of src/packdump.c? Yes, that does avoid the segfault (though it reports the string value as NULL instead of ''). But isn't this really a bug in PIO_printf handling of %.*s? The NULL is my fault, I put it that way for easy searchability while testing. You are right, the value is an empty string and must be reported like that. The printf-alike parrot functions seem to have a problem with NULL c strings, yes, we will solve this quickly (I hope). But printf-alikes can't know the NULL is really a parrot empty string, because we dropped that information by the fact of passing a c string instead of the parrot string. So I think the correct solution will be to stop accessing string internals and using the parrot strings api. In the meantime, what we need to know now in this ticket is if the segfault is no longer present in all platforms reported. -- Salu2
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Tue, 9 Sep 2008, James Keenan via RT wrote:
On Tue Sep 09 15:14:36 2008, [EMAIL PROTECTED] wrote:
Generally agreed. In this case, hold this ticket for the I/O milestone,
which is next (sometime in the next few days). I've added it to the I/O
tasklist.
In the meantime, let's get Andy's patch applied (if it isn't already).
I extracted the attached patch from email text and applied it in r30946.
All
tests pass, but note that I still don't get correct detection of AIO
capabilities on Darwin/PPC (OS X 10.4). The message I get with
verbose-step=auto::aio is in the second attachment.
auto::aio - Does your platform support AIO...
/usr/bin/gcc [-options ... ] -I./include -c test_19186.c
c++ -undefined dynamic_lookup test_19186.o -o test_19186 -lm -lrt
/usr/bin/ld: can't locate file for: -lrt
That's another easy one. The test assumes that all platforms have -lrt
and that all platforms have to link with it for this test. Your system
clearly doesn't have -lrt, so the link fails. If you just delete the line
that adds in -lrt, I'll bet the test succeeds.
Generally, Configure shouldn't be unconditionally adding libraries. A
better idiom is probably to try without, and then try with only if
necessary. Something like this:
diff -r -u parrot-svn/config/auto/aio.pm parrot-cc/config/auto/aio.pm
--- parrot-svn/config/auto/aio.pm 2008-09-10 11:06:19.0 -0400
+++ parrot-cc/config/auto/aio.pm2008-09-10 11:53:31.0 -0400
@@ -45,9 +45,14 @@
my $verbose = $conf-options-get('verbose');
my $libs= $conf-data-get('libs');
-$conf-data-add( ' ', libs = '-lrt' );
-
my $errormsg = _first_probe_for_aio($conf, $verbose);
+if ($errormsg) {
+# Linux, at least, needs to add -lrt to $libs.
+print (Trying again with -lrt) if $verbose;
+$conf-data-add( ' ', libs = '-lrt' );
+$errormsg = _first_probe_for_aio($conf, $verbose);
+}
+
if ( ! $errormsg ) {
my $test = $conf-cc_run();
--
Andy Dougherty [EMAIL PROTECTED]
building parrot with clang + llvm
I tried to build parrot with the clang, an llvm frontend. It provides a
script called 'ccc', which accepts the same options as gcc.
Configure works fine (perl Configure.pl --verbose --cc=ccc --link=ccc).
The build starts fine, but fails while compiling the first pmc:
clang -emit-llvm-bc -x c -o src/io/io_passdown.o src/io/io_passdown.c
-I./include -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHASATTRIBUTE_CONST
-DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL
-DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED
-DHASATTRIBUTE_WARN_UNUSED_RESULT -DHAS_GETTEXT -DHAS_JIT -DI386
-DHAVE_COMPUTED_GOTO -Isrc/io
src/pmc/default.c
clang -emit-llvm-bc -x c -o src/pmc/default.o src/pmc/default.c
-I./include -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHASATTRIBUTE_CONST
-DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL
-DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED
-DHASATTRIBUTE_WARN_UNUSED_RESULT -DHAS_GETTEXT -DHAS_JIT -DI386
-DHAVE_COMPUTED_GOTO -Isrc/pmc
src/pmc/default.c:65:36: error: use of undeclared identifier
'_CONST_STRING_65'
VTABLE_name(interp, pmc) : CONST_STRING(interp, (null));
^
src/pmc/default.c:123:38: error: use of undeclared identifier
'_CONST_STRING_123'
if (!string_compare(interp, key, CONST_STRING(interp, _ro))) {
^
src/pmc/default.c:164:9: error: use of undeclared identifier
'_CONST_STRING_164'
VTABLE_set_pmc_keyed_str(interp, prop_hash, CONST_STRING(interp,
_ro), pmc_true);
^
src/pmc/default.c:202:40: error: use of undeclared identifier
'_CONST_STRING_202'
!string_compare(interp, key, CONST_STRING(interp, _ro))) {
^
src/pmc/default.c:947:28: error: use of undeclared identifier
'_CONST_STRING_947'
STRING * const undef = CONST_STRING(interp, Undef);
^
src/pmc/default.c:1161:9: error: use of undeclared identifier
'_CONST_STRING_1161'
if (VTABLE_isa(interp, p, CONST_STRING(interp, NCI))) {
^
src/pmc/default.c:1460:34: error: use of undeclared identifier
'_CONST_STRING_1460'
STRING * const flags_str = CONST_STRING(interp, flags);
^
src/pmc/default.c:1473:36: error: use of undeclared identifier
'_CONST_STRING_1473'
if (string_equal(interp, name, CONST_STRING(interp, flags)) == 0) {
^
8 diagnostics generated.
make: *** [src/pmc/default.o] Error 1
Does anybody have an idea what might be going on, or what I could do to
fix it?
(If not, that's no problem; it could be that clang+ccc just isn't mature
enough right now)
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: building parrot with clang + llvm
On Wednesday 10 September 2008 10:45:12 Moritz Lenz wrote: I tried to build parrot with the clang, an llvm frontend. It provides a script called 'ccc', which accepts the same options as gcc. Configure works fine (perl Configure.pl --verbose --cc=ccc --link=ccc). src/pmc/default.c:65:36: error: use of undeclared identifier '_CONST_STRING_65' VTABLE_name(interp, pmc) : CONST_STRING(interp, (null)); Does anybody have an idea what might be going on, or what I could do to fix it? src/pmc/default.str must exist (the Makefile should get this right), and clang should include it (there's an #include line in src/pmc/default.c to this effect). Perhaps clang forbids including files that do not end in .h? -- c
Re: building parrot with clang + llvm
chromatic wrote: On Wednesday 10 September 2008 10:45:12 Moritz Lenz wrote: I tried to build parrot with the clang, an llvm frontend. It provides a script called 'ccc', which accepts the same options as gcc. Configure works fine (perl Configure.pl --verbose --cc=ccc --link=ccc). src/pmc/default.c:65:36: error: use of undeclared identifier '_CONST_STRING_65' VTABLE_name(interp, pmc) : CONST_STRING(interp, (null)); Does anybody have an idea what might be going on, or what I could do to fix it? src/pmc/default.str must exist (the Makefile should get this right), It is there, yes. and clang should include it (there's an #include line in src/pmc/default.c to this effect). Perhaps clang forbids including files that do not end in .h? That doesn't the seem to be case here. I tried with a small sample script that include a .str file, and it works fine. A ack -a '_CONST_STRING_65\b' didn't find anything; so is this a broken macro expansion somewhere? Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: building parrot with clang + llvm
On Wednesday 10 September 2008 11:07:41 Moritz Lenz wrote: That doesn't the seem to be case here. I tried with a small sample script that include a .str file, and it works fine. A ack -a '_CONST_STRING_65\b' didn't find anything; so is this a broken macro expansion somewhere? The line numbers reported by clang seem sensible enough, but do they match values in src/pmc/default.str? Mine contains: #define _CONST_STRING_45 80 #define _CONST_STRING_103 534 #define _CONST_STRING_144 _CONST_STRING_103 #define _CONST_STRING_182 _CONST_STRING_144 #define _CONST_STRING_626 535 #define _CONST_STRING_1033 3 #define _CONST_STRING_973 536 #define _CONST_STRING_951 _CONST_STRING_973 -- c
Re: building parrot with clang + llvm
On Wed, Sep 10, 2008 at 8:12 PM, chromatic [EMAIL PROTECTED] wrote: The line numbers reported by clang seem sensible enough, but do they match values in src/pmc/default.str? Mine contains: #define _CONST_STRING_45 80 #define _CONST_STRING_103 534 #define _CONST_STRING_144 _CONST_STRING_103 #define _CONST_STRING_182 _CONST_STRING_144 #define _CONST_STRING_626 535 #define _CONST_STRING_1033 3 #define _CONST_STRING_973 536 #define _CONST_STRING_951 _CONST_STRING_973 These are .pmc file line numbers, it isn't? Looks like llvmc does not honor #line directives. -- Salu2
Re: [perl #57320] touch /tmp/t make test = fails t/perl/Parrot_IO.t ?
# from Will Coleda # on Monday 28 July 2008 07:31: I presume Eric noticed this as he was working on his patch to enable a parallel make test; Now that his patch is applied, fixing these tests should have a higher priority; If two tests that are trying to create/use the same directory run at the same time, one of them is likely to fail. Well, that is all true. But it really has little to do with parallel testing, it is simply a faulty assumption. Today I'm working on something else and still haven't shutdown my machine since then, so I still have a file /tmp/t, so the tests still fail. I *could* delete that file, but what if that just happens to be my favorite empty file of all time? But if I look at it deeper, the Parrot::IO code only exists for ./tools/docs/write_docs.pl? Oh, and a bunch of the codingstd tests? --Eric
[perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Wed Sep 10 09:30:37 2008, doughera wrote: That's another easy one. The test assumes that all platforms have -lrt and that all platforms have to link with it for this test. Your system clearly doesn't have -lrt, so the link fails. If you just delete the line that adds in -lrt, I'll bet the test succeeds. Generally, Configure shouldn't be unconditionally adding libraries. A better idiom is probably to try without, and then try with only if necessary. Something like this: The principle sounds good. I applied the patch and, as predicted, it DTRT on Linux, as this verbose output for auto::aio on Linux demonstrates. Unfortunately, it didn't cause AIO to be located on Darwin -- even though it changed the error message. The handles to the error files were opened, but the .out, .cco and .ldo files were all empty. $ ls -ltr test_* -rw-r--r-- 1 jimk jimk 3424 Sep 10 19:58 test_26632.o -rw-r--r-- 1 jimk jimk 0 Sep 10 19:58 test_26632.ldo -rw-r--r-- 1 jimk jimk 0 Sep 10 19:58 test_26632.cco -rw-r--r-- 1 jimk jimk 1330 Sep 10 19:58 test_26632.c -rw-r--r-- 1 jimk jimk 0 Sep 10 19:58 test_26632.out -rwxr-xr-x 1 jimk jimk 18148 Sep 10 19:58 test_26632 Thank you very much. kid51 auto::aio - Does your platform support AIO... /usr/bin/gcc -fno-common -no-cpp-precomp -pipe -I/opt/local/include -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -fvisibility=hidden -W -Wall -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch -Wmissing-braces -Wmissing-field-initializers -Wno-missing-format-attribute -Wmissing-include-dirs -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wvariadic-macros -Wwrite-strings -Wbad-function-cast -Wdeclaration-after-statement -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wnonnull -I./include -c test_26632.c /usr/bin/g++ -undefined dynamic_lookup test_26632.o -o test_26632 -lm ./test_26632 (no) Setting Configuration Data: ( verbose = undef, ); Does your platform support AIO...no. auto::aio - Does your platform support AIO... cc -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -fvisibility=hidden -maccumulate-outgoing-args -W -Wall -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch -Wmissing-braces -Wmissing-field-initializers -Wno-missing-format-attribute -Wmissing-include-dirs -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wvariadic-macros -Wwrite-strings -Wbad-function-cast -Wc++-compat -Wdeclaration-after-statement -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wnonnull -I./include -c test_15075.c cc -L/usr/local/lib -Wl,-E test_15075.o -o test_15075 -lnsl -ldl -lm -lcrypt -lutil -lpthread test_15075.o: In function `main': test_15075.c:(.text+0x172): undefined reference to `aio_read64' collect2: ld returned 1 exit status (Trying again with -lrt) cc -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -fvisibility=hidden -maccumulate-outgoing-args -W -Wall -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch -Wmissing-braces -Wmissing-field-initializers -Wno-missing-format-attribute -Wmissing-include-dirs -Wpacked -Wparentheses -Wpointer-arith
[perl #46783] [TODO] [Perl] Use temporary files in smartlinks tests
Generating a CC to the list: On Wed Sep 10 16:07:58 2008, szbalint wrote: This TODO doesn't really make sense because the tests which would need to create proper temporary files do not actually create any files, they just read some and parse. Therefor I think this ticket can be resolved simply by removing the text from smartlinks.t referring to this ticket. szbalint's patch simply proposed deleting the 4 comments citing this RT. This, of course, forced me to start actually looking at these tickets ... ... which forced me to look at the smartlink.t test ... ... which, to run it, required me to install Moose ... ... which, in turn, required me to install half of CPAN ;-) kid51
[perl #46783] [TODO] [Perl] Use temporary files in smartlinks tests
On Wed Sep 10 16:07:58 2008, szbalint wrote: This TODO doesn't really make sense because the tests which would need to create proper temporary files do not actually create any files, they just read some and parse. Therefor I think this ticket can be resolved simply by removing the text from smartlinks.t referring to this ticket. szbalint also wrote on #parrot: I was thinking about taking RT #46783 , but when I looked at smartlinks.t it turned out the TODO-ed tests do not actually create files temporary or otherwise. I'm just a little confused now, is there some policy to create special test files to _read_ from, instead of using docs/pdds/pdd03_calling_conventions.pod' for example, or the todo is a false alarm? You are correct. (1) The one remaining TODO-ed test does not create files. No need for tempfiles there. (2) The four tests which make reference to this ticket need POD to test. If docs/pdds/pdd03_calling_conventions.pod has enough variety of POD functionality for the purpose of the smartlinks test, then I don't see a compelling reason to, e.g., create a tempdir and copy the POD file into that tempdir for the purpose of testing. So I applied your patch in r30979. I'll leave the RT open for a couple of days in case anyone objects to your/my rationale. Thank you very much. kid51
[perl #57178] [BUG] Broken links on smolder site.
Michael, Coke: Has this problem been fixed? If so, Coke, can you close the ticket? thanks. kid51
[perl #56108] [BUG] make fails in languages/perl6
Ovid: Are you still experiencing these failures? Jonathan: Are you still tracking this ticket? thanks. kid51
[perl #56052] Storable issue
Can someone evaluate where we stand with respect to the issues in this ticket? Thank you very much. kid51
[perl #55504] [BUG] Failing test t/op/spawnw.t
Can someone evaluate where we stand with respect to the issues in this RT? Thank you very much. kid51
[perl #55298] [BUG] - Test failures in 0.6.2 on Fedora 5
Clark, We're now at Parrot 0.7. Are you still getting these test failures with that version (or with HEAD from svn)? Can anyone else reproduce these errors? Thank you very much. kid51
[perl #54372] [BUG] test failures on win32/msvc
Coke, particle: Where do we stand on this ticket? thank you very much. kid51
[perl #54000] [DEPRECATED] get_array, get_list, get_scalar methods
Patrick: Where do we stand in the deprecation cycle re these three methods? Thank you very much. kid51
[perl #53682] [CAGE] Visual Studio compiler for parrot
Coke, particle: Can we get an update on the issues raised in this RT? Thank you very much. kid51
[perl #53156] [BUG] Segmentation violation in parrot
Clark, Are you still getting these failures in the latest version/revision of Parrot? Thank you very much. kid51
[perl #53128] PDD13PBC branch work: M2 Bytecode format milestone
On Sun Apr 20 18:38:22 2008, [EMAIL PROTECTED] wrote: This ticket exists to track progress on the M2 Bytecode format milestone. Work on this milestone is occurring in the pdd13pmc branch. I am using RT to track progress on this milestone. I will break down the task into smaller pieces, so look for other (more specific) tickets which this ticket depends on. Infinoid, Can you give us any update on the work in this branch? Thank you very much. kid51
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Wed, 10 Sep 2008, James Keenan via RT wrote: On Wed Sep 10 09:30:37 2008, doughera wrote: That's another easy one. The test assumes that all platforms have -lrt and that all platforms have to link with it for this test. Your system clearly doesn't have -lrt, so the link fails. If you just delete the line that adds in -lrt, I'll bet the test succeeds. Generally, Configure shouldn't be unconditionally adding libraries. A better idiom is probably to try without, and then try with only if necessary. Something like this: The principle sounds good. I applied the patch and, as predicted, it DTRT on Linux, as this verbose output for auto::aio on Linux demonstrates. Unfortunately, it didn't cause AIO to be located on Darwin -- even though it changed the error message. The handles to the error files were opened, but the .out, .cco and .ldo files were all empty. It could be that aio just doesn't work on your system -- or at least aio as implemented by the author of this test. If you care to diagnose it further, you could try running the test_26632 executable directly from the command line and see what the output is. Or you could alter config/auto/aio.pm to output the errors in this case. However, I'm unsure if it's worth it. You'll might learn a little more about why it's failing, but you may not be able to do anything to fix it. $ ls -ltr test_* -rw-r--r-- 1 jimk jimk 3424 Sep 10 19:58 test_26632.o -rw-r--r-- 1 jimk jimk 0 Sep 10 19:58 test_26632.ldo -rw-r--r-- 1 jimk jimk 0 Sep 10 19:58 test_26632.cco -rw-r--r-- 1 jimk jimk 1330 Sep 10 19:58 test_26632.c -rw-r--r-- 1 jimk jimk 0 Sep 10 19:58 test_26632.out -rwxr-xr-x 1 jimk jimk 18148 Sep 10 19:58 test_26632 -- Andy Dougherty [EMAIL PROTECTED]
[perl #50212] [BUG] Configure step fails on Windows
Any update on the status of issues in this ticket? Thank you very much. kid51
[perl #48581] [DEPRECATED] vtable type_keyed_str
On Mon Apr 07 21:31:15 2008, coke wrote: This has been removed in the type_ids branch. Coke, Can you provide any update on this deprecation and/or the type_ids branch? Thank you very much. kid51
