Re: [perl #57668] [BUG][PATCH] Iterate through the current namespace causes a segfault
Bob Rogers wrote: From: chromatic <[EMAIL PROTECTED]> Fixed in r30286. -- c Terrific; thanks. (Especially since it looks like something I may have seen in other circumstances, but could not reproduce.) -- Bob It looks like this is resolved. I'll mark it as such in rt in a couple days unless there are any objections. Christoph
new 'failthrow' branch for Failure/exception testing
Tonight I've updated Rakudo to have Failure objects that more closely match the description in S04 (i.e., with unthrown exception objects). However, because this causes a number of spectest_regression failures, I've committed the code into a 'failthrow' branch until we can get the test regression failures sorted out. I've only checked a few tests, but there seem to be a number of places where uninitialized or undef values are used. For example, there are a number of places that check for undef using: is($var, undef, '$var is undef'); If I understand S04 correctly, C should return a Failure object with an unthrown and unhandled exception, and attempting to use the value of the Failure object immediately throws the exception. So, the above call to C needs to be changed, or we need to make C smart enough to properly handle and compare Failure objects in the manner given above. Anyway, this is just a note to invite others to start looking at this branch and help clean up or re-evaluate the test suite in light of failure handling. This branch also introduces a private '!FAIL' function that builtin methods can use to return better Failure objects without having to directly call "new 'Failure'". The Perl 6 builtin C function will be coming soon to this branch as well. Thanks! Pm
[perl #58590] [PATCH] dotnet make
# New Ticket Created by Reini Urban # Please include the string: [perl #58590] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=58590 > --- osname= cygwin osvers= 1.5.25(0.15642) arch= cygwin-thread-multi-64int cc= gcc --- Flags: category=languages severity=medium ack=no --- Attached patch overhauls the dotnet make + Configure system a bit, so that the conditional make syntax is supported and the perl stuff is gone. It requires the 57548-CONDITIONED_LINE_enh.patch (best wait for the cygwin070patches merge) Status: Failed 22/43 test programs. 141/263 subtests failed with cygwin + mono-1.2.1 --- Summary of my parrot 0.7.0 (r30732) configuration: configdate='Wed Sep 3 19:18:37 2008 GMT' Platform: osname=cygwin, archname=cygwin-thread-multi-64int jitcapable=1, jitarchname=i386-cygwin, jitosname=CYGWIN, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl.exe Compiler: cc='gcc', ccflags='-U__STRICT_ANSI__ -pipe -I/usr/local/include -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -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 -Wno-missing-format-attribute -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 -Wwrite-strings -Wbad-function-cast -Wdeclaration-after-statement -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wnonnull -DDISABLE_GC_DEBUG=1 -DNDEBUG -O3 -DHAS_GETTEXT', Linker and Libraries: ld='gcc', ldflags=' -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--stack,8388608 -Wl,--enable-auto-image-base ', cc_ldflags='', libs='-L/usr/local/lib -lcrypt -lgmp -lreadline -lpcre -lglut32 -lglu32 -lopengl32 -lcrypto -lintl' Dynamic Linking: share_ext='.dll', ld_share_flags='-shared', load_ext='.dll', ld_load_flags='-shared' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=1234, nv=double, numvalsize=8, doublesize=8 -- Reini Urban http://phpwiki.org/ http://murbreak.at/ dotnet-make.patch Description: Binary data
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
On Tue, Sep 2, 2008 at 12:43 PM, Allison Randal <[EMAIL PROTECTED]> wrote: > Klaas-Jan Stol wrote: > >> >> This must make the following syntax rule illegal: >> >> target = null >> >> because if "null" is declared as a .local, you can't know whether you want >> to nullify target, or want to set target's value to that of the .local >> variable "null". >> >> I take it this is no problem; just stick to >> >> null target >> >> if you actually want to set target to 0/null. >> > > Yes, that's reasonable. The syntactic sugar was confusing in that case > anyway. (Seemed like you were assigning a null value to the destination > register, rather than nullifying the PMC in the destination register.) > > This belongs in a general category of opcodes where the standard > transformation of "call the opcode with the first argument stuck before an > '=' sign" doesn't really make sense. > > Allison > the problem seems to be a bit bigger than I had foreseen. The issue is that ops with the first operand marked as 'OUT' may be rewritten as: target = op [operand [, operand]*]? However, consider the following: .local pmc getstdin $P0 = getstdin How should this be resolved? is the opcode 'getstdin' meant here, or is it the value of the .local getstdin. This problem occurrs with all ops, not only with single-operand ops. kjs
[PATCH] added links to dotnet/doc/contents.pod
Attached patch adds links to external dotnet ressources Jonathan mentioned (his paper, the specs), and the implementations. Jonathan should approve it because it links to a bad poem on VM's in his paper on page 1. No ticket because it's so simple. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ dotnet-links.patch Description: Binary data
[perl #58586] s/FedoraCore/Fedora/ on http://www.parrot.org/download
# New Ticket Created by Stuart Jansen # Please include the string: [perl #58586] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=58586 > The Fedora Core/Extras split no longer exists. Fedora is now simply called Fedora, not Fedora Core. (Oh, and it was never FedoraCore.) http://www.parrot.org/download
[perl #32087] [PATCH] .include with an absolute path
On Fri Aug 01 06:44:05 2008, coke wrote: > On Thu, Jul 31, 2008 at 7:35 PM, James Keenan via RT > <[EMAIL PROTECTED]> wrote: > > Coke: Given the points Leo made and the fact that there has been > > nothing from the OP in 4 years, can we close this ticket? > > > > Thanks. > > > > kid51 > > > > Just because there's no activity or followups on a ticket doesn't mean > the bug isn't still there. In this case, though, I can't reproduce the > poster's original complaint about an absolute include path not > working, ignoring the quality or state of his patch. > > We can close this ticket by adding a test that > - creates a temporary PIR file with a simple one line :main that > outputs something. > - gets the absolute path of that file > - uses another file to .include that temporary file via the absolute path. > - verifies the output > - removes the temporary file. > This patch adds test of this functionality to t/compilers/imcc/syn/file.t . It passes on Linux/x86. I'll try it on a windows machine tomorrow and apply it over the weekend unless there any objections. Christoph Index: t/compilers/imcc/syn/file.t === --- t/compilers/imcc/syn/file.t (revision 30772) +++ t/compilers/imcc/syn/file.t (working copy) @@ -7,6 +7,7 @@ use lib qw( . lib ../lib ../../lib ); use File::Spec; use Test::More; +use Cwd qw(cwd); use Parrot::Config; use Parrot::Test tests => 13; @@ -52,6 +53,29 @@ unlink 'temp.pasm'; ## +open $FOO, '>', "temp.pasm" or die "Can't write temp.pasm\n"; +print $FOO <<'ENDF'; + .macro_const BAR 42 +ENDF +close $FOO; +my $temp_abs_path = cwd()."/temp.pasm"; + +pir_output_is( <<"CODE", <<'OUT', 'include pasm (absolute path)' ); +.sub test :main +say "before" +.include '$temp_abs_path' +say .BAR +say "after" +end +.end +CODE +before +42 +after +OUT +unlink 'temp.pasm'; + +## open $FOO, '>', 'temp.pir' or die "Can't write temp.pir: $!\n"; print $FOO <<'ENDF'; .const int BAR = 42
[perl #56304] smokej consumes all memory Revision: 28672 on linux
On Mon Jul 14 13:47:29 2008, [EMAIL PROTECTED] wrote: > Seems to be fixed as of 29440: Sounds like a happy ending. resolved
[perl #58592] --target=PAST and -e don't mix in Rakudo
# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #58592] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=58592 > $ ../../parrot perl6.pbc -e 'say "OH HAI"' # works OH HAI $ ../../parrot perl6.pbc --target=PAST -e 'say "OH HAI"' # outputs nothing ...whereas both these approaches work when the -e program is replaced by a file with corresponding contents.
Re: [perl #58586] s/FedoraCore/Fedora/ on http://www.parrot.org/download
Stuart Jansen (via RT) wrote: > # New Ticket Created by Stuart Jansen > # Please include the string: [perl #58586] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=58586 > > > > The Fedora Core/Extras split no longer exists. Fedora is now simply > called Fedora, not Fedora Core. (Oh, and it was never FedoraCore.) > > http://www.parrot.org/download Thanks, fixed. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
[perl #39313] [TODO] or [BUG] improve PMC compiler
On Fri Jun 27 13:14:53 2008, coke wrote:
>
> While I think this particular example is now valid with the new calling
> conventions, you can get a similar effect with:
>
> METHOD BORK BORK parent() {
> /* nothing to see here*/
> }
This ticket doesn't seem to be closeable as is. Would it be good enough
if pmc2c.pl spit out an error on the above definition, or is this even
something that pmc2c.pl should be concerned about?
[perl #57116] [BUG] make: *** [perl6] Segmentation fault
On Tue Jul 29 00:38:29 2008, tuxdna wrote: > I found that it is now working correctly in the latest revision 29838. resolved
Re: [perl #39313] [TODO] or [BUG] improve PMC compiler
On Fri, Sep 5, 2008 at 3:45 AM, Christoph Otto via RT
<[EMAIL PROTECTED]> wrote:
> On Fri Jun 27 13:14:53 2008, coke wrote:
>>
>> While I think this particular example is now valid with the new calling
>> conventions, you can get a similar effect with:
>>
>> METHOD BORK BORK parent() {
>> /* nothing to see here*/
>> }
>
> This ticket doesn't seem to be closeable as is.Would it be good enough
> if pmc2c.pl spit out an error on the above definition, or is this even
> something that pmc2c.pl should be concerned about?
>
The goal of the ticket should be for pmc2c.pl to entirely parse the
input PMC files. Either passing through uncooked C, or doing
transformations. Silently dropping code on the floor is not
acceptable.
The script should either pass this through to the .c file (in which
case the build will fail when a c compiler looks at it), or the
transformation should error out.
In either case, the build stops, and the developer knows they need to
fix the METHOD declaration. I slightly prefer having the
transformation step fail because then we can emit a more helpful error
message about the METHOD signature, but if it's easier to just let it
passthrough, we can do that and close the ticket.
--
Will "Coke" Coleda
Re: [perl #39313] [TODO] or [BUG] improve PMC compiler
On Fri, Sep 5, 2008 at 1:28 PM, Will Coleda <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 5, 2008 at 3:45 AM, Christoph Otto via RT
> <[EMAIL PROTECTED]> wrote:
> > On Fri Jun 27 13:14:53 2008, coke wrote:
> >>
> >> While I think this particular example is now valid with the new calling
> >> conventions, you can get a similar effect with:
> >>
> >> METHOD BORK BORK parent() {
> >> /* nothing to see here*/
> >> }
> >
> > This ticket doesn't seem to be closeable as is.Would it be good enough
> > if pmc2c.pl spit out an error on the above definition, or is this even
> > something that pmc2c.pl should be concerned about?
> >
>
> The goal of the ticket should be for pmc2c.pl to entirely parse the
> input PMC files. Either passing through uncooked C, or doing
> transformations. Silently dropping code on the floor is not
> acceptable.
wouldn't a PGE-based compiler be helpful?
just a thought.
kjs
Re: [perl #39313] [TODO] or [BUG] improve PMC compiler
On Fri, Sep 5, 2008 at 9:07 AM, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, Sep 5, 2008 at 1:28 PM, Will Coleda <[EMAIL PROTECTED]> wrote:
>>
>> On Fri, Sep 5, 2008 at 3:45 AM, Christoph Otto via RT
>> <[EMAIL PROTECTED]> wrote:
>> > On Fri Jun 27 13:14:53 2008, coke wrote:
>> >>
>> >> While I think this particular example is now valid with the new calling
>> >> conventions, you can get a similar effect with:
>> >>
>> >> METHOD BORK BORK parent() {
>> >> /* nothing to see here*/
>> >> }
>> >
>> > This ticket doesn't seem to be closeable as is.Would it be good enough
>> > if pmc2c.pl spit out an error on the above definition, or is this even
>> > something that pmc2c.pl should be concerned about?
>> >
>>
>> The goal of the ticket should be for pmc2c.pl to entirely parse the
>> input PMC files. Either passing through uncooked C, or doing
>> transformations. Silently dropping code on the floor is not
>> acceptable.
>
> wouldn't a PGE-based compiler be helpful?
> just a thought.
> kjs
>
On Fri, Sep 5, 2008 at 9:07 AM, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, Sep 5, 2008 at 1:28 PM, Will Coleda <[EMAIL PROTECTED]> wrote:
>>
>> On Fri, Sep 5, 2008 at 3:45 AM, Christoph Otto via RT
>> <[EMAIL PROTECTED]> wrote:
>> > On Fri Jun 27 13:14:53 2008, coke wrote:
>> >>
>> >> While I think this particular example is now valid with the new calling
>> >> conventions, you can get a similar effect with:
>> >>
>> >> METHOD BORK BORK parent() {
>> >> /* nothing to see here*/
>> >> }
>> >
>> > This ticket doesn't seem to be closeable as is.Would it be good enough
>> > if pmc2c.pl spit out an error on the above definition, or is this even
>> > something that pmc2c.pl should be concerned about?
>> >
>>
>> The goal of the ticket should be for pmc2c.pl to entirely parse the
>> input PMC files. Either passing through uncooked C, or doing
>> transformations. Silently dropping code on the floor is not
>> acceptable.
>
> wouldn't a PGE-based compiler be helpful?
> just a thought.
> kjs
>
Only if you can get me a PGE compiler before parrot is built.
--
Will "Coke" Coleda
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
On Fri, Sep 5, 2008 at 2:36 AM, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote: > On Tue, Sep 2, 2008 at 12:43 PM, Allison Randal <[EMAIL PROTECTED]> wrote: > >> Klaas-Jan Stol wrote: >> >>> >>> This must make the following syntax rule illegal: >>> >>> target = null >>> >>> because if "null" is declared as a .local, you can't know whether you want >>> to nullify target, or want to set target's value to that of the .local >>> variable "null". >>> >>> I take it this is no problem; just stick to >>> >>> null target >>> >>> if you actually want to set target to 0/null. >>> >> >> Yes, that's reasonable. The syntactic sugar was confusing in that case >> anyway. (Seemed like you were assigning a null value to the destination >> register, rather than nullifying the PMC in the destination register.) >> >> This belongs in a general category of opcodes where the standard >> transformation of "call the opcode with the first argument stuck before an >> '=' sign" doesn't really make sense. >> >> Allison >> > > the problem seems to be a bit bigger than I had foreseen. The issue is that > ops with the first operand marked as 'OUT' may be rewritten as: > target = op [operand [, operand]*]? > > However, consider the following: > > .local pmc getstdin > > $P0 = getstdin > > How should this be resolved? is the opcode 'getstdin' meant here, or is it > the value of the .local getstdin. This problem occurrs with all ops, not > only with single-operand ops. > > kjs > the sugar for what can be on the left side of an equals sign needs to be changed. simply having a first parameter with OUT isn't enough. the same thing happens for $P0 = push $S1 which is legal pir syntax, but obscure at best. ops must have some means of specifying (perhaps an attribute like C<:returns> or C<:rvalue>?) that allows them to be on the right side of the equals. only this class of ops allows the syntax described above. in the case of .local pmc getstdin ... $P0 = getstdin this can be resolved because the (now) compiler knows (either during parsing or semantic analysis) that the C op is not allowed to be an rvalue and lookup C in the list of C<.local>s as a fallback. ~jerry
[perl #58602] subset types and multi dispatch don't mix
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #58602]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=58602 >
Rakudo r30787 dies on multi dispatch when subset types are involved:
test file:
subset Even of Int where { $_ % 2 == 0 };
subset Odd of Int where { $_ % 2 == 1 };
multi sub test_subtypes(Even $y){ 'Even' }
multi sub test_subtypes(Odd $y){ 'Odd' }
say test_subtypes(3)
dies with
No applicable methods.
Adding debugging statements to both where blocks reveals that neither of
them is ever called.
I added a few tests for that to t/spec/S12-subset/multi-dispatch.t
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
> > This is a patch in the sense of "bandaid". What is it about the letter > 'K' that means that this probe gives sloppy results on Kubuntu when on > Ubuntu it has built cleanly for me every day Something to do with Gnome, since that's the major difference between the two? -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
> This is a patch in the sense of "bandaid". What is it about the letter > 'K' that means that this probe gives sloppy results on Kubuntu when on > Ubuntu it has built cleanly for me every day since I started Something to do with KDE vs Gnome, since that's the major difference? Perhaps KDE's screen-saver mechanism's sabotaging you? -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Thu, 4 Sep 2008, Patrick R. Michaud wrote:
> On Thu, Sep 04, 2008 at 04:52:34PM -0700, James Keenan via RT wrote:
> > I applied the patch attached, aio.in.revised.patch.txt, in r30771. I
> > set the 'sleep' to 4 seconds. All the tests have been reactivated.
>
> Thanks.
>
> > This is a patch in the sense of "bandaid". What is it about the letter
> > 'K' that means that this probe gives sloppy results on Kubuntu when on
> > Ubuntu it has built cleanly for me every day since I started building
> > Parrot?
>
> The problem only appeared for me in Kubuntu a few weeks ago, and
> then only intermittently until a week or so ago. Prior to the
> beginning of August Parrot had been building cleanly for me on
> Kubuntu without any difficulty.
>
> As one of the earlier messages suggested, I think it may just be a
> race condition in the signal handling.
It's a wacky test in many respects. For one thing, it tests using
signal number '35' without any regard for what that signal might
acutally mean. On Solaris, for example, 35 is 'SIGFREEZE', which is
almost certainly not what was intended.
I suspect that on someone's Linux system, SIGRTMIN got reported as 34,
and so the test just hard-coded '35'. It's quite possible that signal
35 means something different on recent versions of Kubuntu.
This patch takes the following small steps:
First, I replaced the
retval = *(int*)i->si_ptr;
line by
retval = *(int*)i->si_value.sival_ptr;
I've never fiddled with this stuff before, but it looks like the si_ptr
#define is not necessarily very portable. I replaced it by the si_value
and sival_ptr fields, which I hope are slightly more portable.
Second, it moves the small step of moving the logic of finding
SIGRTMIN + 1 into the C program, where it's trivial.
Next, it adds in an else branch for the case where the program builds
but does not run successfully.
Finally, made sure the 'aio' and 'HAS_AIO' entries are always set to
some value.
I haven't looked for race conditions at all, but with this patch, I'll at
least be more confident that it's trying to do what we think it's trying
to do.
diff -r -u parrot-current/config/auto/aio/aio.in
parrot-andy/config/auto/aio/aio.in
--- parrot-current/config/auto/aio/aio.in 2008-09-05 08:13:19.0
-0400
+++ parrot-andy/config/auto/aio/aio.in 2008-09-05 13:04:03.0 -0400
@@ -23,7 +23,7 @@
{
if (s == my_sig) {
flag = s;
- retval = *(int*)i->si_ptr;
+ retval = *(int*)i->si_value.sival_ptr;
}
}
@@ -36,7 +36,13 @@
int i = 42;
int cnt = 4;
-my_sig = atoi(argv[1]);
+/* For internal use, we usually use
+ SIGRTMIN + argv[1].
+ Usually, that's set to
+ SIGRTMIN + 1
+ by the calling program.
+*/
+my_sig = SIGRTMIN + atoi(argv[1]);
printf("SIGRTMIN=%d SIGRTMAX=%d\n", SIGRTMIN, SIGRTMAX);
fd = open("MANIFEST", O_RDONLY);
diff -r -u parrot-current/config/auto/aio.pm parrot-andy/config/auto/aio.pm
--- parrot-current/config/auto/aio.pm 2008-08-31 12:15:34.0 -0400
+++ parrot-andy/config/auto/aio.pm 2008-09-05 12:08:23.0 -0400
@@ -49,10 +49,11 @@
my $errormsg = _first_probe_for_aio($conf);
if ( ! $errormsg ) {
-my $test = $conf->cc_run(35);
+my $test = $conf->cc_run(1); # Use signal RTMIN + 1
# if the test is failing with sigaction err
# we should repeat it with a different signal number
+# This is currently not implemented.
if (
$test =~ /SIGRTMIN=(\d+)\sSIGRTMAX=(\d+)\n
INFO=42\n
@@ -69,6 +70,9 @@
D_SIGRTMAX => $2,
);
}
+else {
+$self->_handle_error_case($conf, $libs, $verbose);
+}
}
else {
$self->_handle_error_case($conf, $libs, $verbose);
@@ -88,7 +92,11 @@
sub _handle_error_case {
my ($self, $conf, $libs, $verbose) = @_;
-$conf->data->set( libs => $libs );
+$conf->data->set(
+aio=> undef,
+HAS_AIO=> 0,
+);
+$conf->data->set( libs => $libs ); # Restore old values
print " (no) " if $verbose;
$self->set_result('no');
}
--
Andy Dougherty [EMAIL PROTECTED]
[perl #58610] [ PATCH ] Broken link on parrotcode.org dev page - list item "Parrot Testing Status"
# New Ticket Created by Ronald Schmidt # Please include the string: [perl #58610] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=58610 > I applied for an account and built what seems to me to be an appropriate Parrot Testing Status page. My proposed link target is http://www.parrot.org/wiki/some-testing-status-tools . If someone wants to set me up as a site editor I will fix the link myself otherwise the page is available for someone else to fix the link. Ron
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
I'll try this out on Darwin and (Debian) Linux this weekend and see what happens. Thanks.
Re: [perl #58610] [ PATCH ] Broken link on parrotcode.org dev page - list item "Parrot Testing Status"
On Fri, Sep 5, 2008 at 9:59 AM, via RT Ronald Schmidt <[EMAIL PROTECTED]> wrote: > # New Ticket Created by Ronald Schmidt > # Please include the string: [perl #58610] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=58610 > > > > I applied for an account and built what seems to me to be an appropriate > Parrot Testing Status page. My proposed link target is > http://www.parrot.org/wiki/some-testing-status-tools . If someone wants > to set me up as a site editor I will fix the link myself otherwise the > page is available for someone else to fix the link. > you're now an editor. have at it! ~jerry
Re: [perl #58438] [PATCH] nci can't pass NULL string arguments
Hearing no objections, and because I needed it to be able to do tests with mysqlclient, applied in r30790 -- Salu2
[ PATCH ] Broken link on parrotcode.org dev page - list item "Parrot Testing Status"
I applied for an account and built what seems to me to be an appropriate Parrot Testing Status page. My proposed link target is http://www.parrot.org/wiki/some-testing-status-tools . If someone wants to set me up as a site editor I will fix the link myself otherwise the page is available for someone else to fix the link. Ron
Re: new 'failthrow' branch for Failure/exception testing
Patrick R. Michaud wrote: If I understand S04 correctly, C should return a Failure object with an unthrown and unhandled exception, and attempting to use the value of the Failure object immediately throws the exception. So, the above call to C needs to be changed, or we need to make C smart enough to properly handle and compare Failure objects in the manner given above. Not all undefined values are unhandled Failures. It can be an undefined protoobject, possibly even auto-vivifying. My understanding is that undef by itself will return a generic undef object, whose exact type and other properties are not completely specified in S04 yet. But, it is not "toxic" like an unhandled Failure, which overrides all the methods of the type its but-ed into to 'fail' if called. I'm working on a complete and comprehensive examination of this area now. It's going slow now that I'm back at $work, but still an active interest. --John
[perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Fri Sep 05 10:17:30 2008, doughera wrote: > > This patch takes the following small steps: > > First, I replaced the > retval = *(int*)i->si_ptr; > line by > retval = *(int*)i->si_value.sival_ptr; > I've never fiddled with this stuff before, but it looks like the > si_ptr > #define is not necessarily very portable. I replaced it by the > si_value > and sival_ptr fields, which I hope are slightly more portable. > > Second, it moves the small step of moving the logic of finding > SIGRTMIN + 1 into the C program, where it's trivial. > > Next, it adds in an else branch for the case where the program builds > but does not run successfully. > > Finally, made sure the 'aio' and 'HAS_AIO' entries are always set to > some value. > > I haven't looked for race conditions at all, but with this patch, I'll > at > least be more confident that it's trying to do what we think it's > trying > to do. > Thanks, Andy. Applied in r30800 after testing on Linux and Darwin.
[perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Thu Sep 04 19:22:56 2008, [EMAIL PROTECTED] wrote: > FWIW, here is a data point: What happens on my Darwin/PPC (10.4) Mac at > auto::aio: > > On Darwin, Configure.pl reports that AIO is unsupported. Follow-up question: If I 'locate aio' on my Mac and come up with this (excerpted) list of files: /usr/include/aio.h /usr/include/sys/aio.h /usr/share/man/man2/aio_cancel.2 /usr/share/man/man2/aio_error.2 /usr/share/man/man2/aio_read.2 /usr/share/man/man2/aio_return.2 /usr/share/man/man2/aio_suspend.2 /usr/share/man/man2/aio_write.2 ... what *else* would I need to have AIO available on Darwin? Thank you very much. kid51
Re: Regex repetition controlled by characters
On Sun, Aug 31, 2008 at 08:33:48AM -0600, Stephen Simmons wrote:
> In S05, I found this regarding the generalized repetition specifier:
>
> ** '|'# repetition controlled by presence of character
>
> I tried it out with
>
> rule thislist { ** '|' };
>
> and got (with Rakudo):
>
> perl6regex parse error: Error in closure quantifier at offset 28, found '''
>
> Is this feature unsupported at the moment or am I misunderstanding it?
It's unsupported at the moment -- currently this is RT #53100.
Pm
Re: [perl #52054] [CAGE]: Make all PDDs conform to coding standards
James Keenan via RT wrote: The PDDs in docs/pdds/ are now in substantial compliance with the coding standard, those in docs/pdds/draft/ much less so. I'll leave this ticket open, but it's the sort of thing that only needs some cage cleaning attention every month or so. The non-draft PDDs are all passing t/codingstd/pdd_format.t as of r30810, but two of the draft PDDs aren't. Since they're still drafts and as such are very likely to change, it doesn't seem worthwhile to bring them into compliance or to have a test depend on them. I propose that pdd_format.t be split into 2 otherwise identical tests; one for draft PDDs and one for final PDDs. The draft test could be permanently TODO'd, which would indicate if any of the drafts were broken without messing up the test results. The final PDD test could become part of make test and this ticket could be marked resolved. I'll submit a patch if this seems to be a reasonable solution.
