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
[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. # URL: 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. # URL: 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
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. # URL: 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 Cgetstdin op is not allowed to be an rvalue and lookup Cgetstdin in the list of C.locals as a fallback. ~jerry
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. # URL: 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. # URL: 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
[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
