Re: [perl #44353] [BUG] Configure.pl: verbose-step option not working with named step
Joshua Hoblitt wrote: The issue is here is that there is nothing in Configure.pl's output to correlate the package name of the step with the output seen from a typical run. For example, say the test that outputs Determining architecture, OS and JIT capability... is failing for some reason so you want to run it verbosely? Unless you are one of the PI number of people in the world that has fiddled with the configure steps your not going to know that steps package name is 'auto::jit'. I suspect, however, that the number of people in the world who at any moment *do* fiddle with the configure steps is a low multiple of PI -- and that they know where to look up the names of the steps (Parrot::Configure::Step::List). The current system lets you run that step verbosely with just `perl Configure.pl --verbose-step=jit` and it just works. But what if you say: 'perl Configure.pl --verbose-step=Determining' ? Then you get more than you want. There's no requirement that the author/maintainer of a config/*/*.pm package provide a $description that unambiguously distinguishes that step from all others. Possible ways forward: 1) Do nothing and document the behavior 2) add an additional test for a step with a package name matching the string passed to --verbose-step This is what particle was expecting to happen. It's what I thought should have been happening -- even though upon re-reading the output of --help I can see that your interpretation is not unreasonable. 3) remove the description matching functionality 4) 2 3 5) remove --verbose-step altogether 6) remove the --verbose* options and just write a 'config.log' on every run that can be searched with your text editor for choice. This: - removes code - removes complexity - is helpful for user support, please send me your config.log file This, of course, is not so much a fix for the current problem as a request for a new feature, which should go into a separate RT. It sounds both desirable and feasible. (My recent addition of Parrot::Configure::Trace works somewhat the same way, logging the internal development of the P::C object over the course of the steps.) 7) have ever[y] configure step print its package name as part of its output I'm thinking that this is a happy compromise between the 'provide the step::name only' and 'provide something that appears in the description' position. What the user would type to request verbosity would be fairly self-evident. kid51
[perl #44363] [PATCH] -D80 + bad luck = segfault
# New Ticket Created by Bram Geron
# Please include the string: [perl #44363]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44363
At Parrot exit, we force-destroy all PObjs. It can happen that a context
is destroyed after its sub is destroyed. Usually that's not a problem,
but if you run with -D80 (show when contexts are destroyed, and print
out the name of the sub) we may segfault, because the Parrot_sub
structure is already freed.
This patch fixes the segfault by turning off -D80 just before
force-freeing all PObjs.
inter_create.c |8
1 file changed, 8 insertions(+)
This patch is unified after applying the patch from bug #44351. You
probably want to apply that first, or you will get warnings from patch(1).
--
Bram Geron | GPG 0xE7B9E65E
diff --git a/src/inter_create.c b/src/inter_create.c
index 307fa71..6a6c4aa 100644
--- a/src/inter_create.c
+++ b/src/inter_create.c
@@ -315,6 +315,14 @@ Parrot_really_destroy(PARROT_INTERP, SHIM(int exit_code), SHIM(void *arg))
interp-arena_base-DOD_block_level =
interp-arena_base-GC_block_level = 0;
+if (Interp_debug_TEST(interp, PARROT_CTX_DESTROY_DEBUG_FLAG)) {
+PIO_eprintf(interp, We are about to exit and force-free subs, so turning off -D%x. It might\n
+generate segfaults when we destroy a context of which the sub is already\n
+dead.\n,
+PARROT_CTX_DESTROY_DEBUG_FLAG);
+Interp_debug_CLEAR(interp, PARROT_CTX_DESTROY_DEBUG_FLAG);
+}
+
if (Interp_trace_TEST(interp, ~0)) {
PIO_eprintf(interp, ParrotIO objects (like stdout and stderr) are about to be closed, so clearing trace flags.\n);
Interp_trace_CLEAR(interp, ~0);
[svn ci] increased warnings levels for msvc
if you windows developers suddenly notice that your build output is full of warnings, it's because we've increased the warnings level from -W3 to -W4. since some level four warnings are so noisy, we've disabled a few of them, until we get the others under control. if you have msvc and an eye for fixing warnings in c code, please dive in and help. output of a recent make session can be found here: http://nopaste.snit.ch:8001/10794 ~jerry
Re: [svn:parrot] r20446 - trunk/config/auto
On Aug 3, 2007, at 8:19 AM, [EMAIL PROTECTED] wrote: Modified: trunk/config/auto/gcc.pm Log: [config] Started doing some cleaning of the warnings setting code for gcc I'm going to be gutting all this gcc code in a day or two anyway, making it autosniff capabilities like the autosniffing I've done on the HASATTRIBUTE flags. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
[perl #44351] [PATCH] GC_VERBOSE=1 + tracing = segfault
# New Ticket Created by Bram Geron
# Please include the string: [perl #44351]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44351
When GC_VERBOSE=1 and tracing is on, Parrot spits out messages about
PObjs getting destroyed. These messages are getting spit out with
PIO_eprintf, which accesses the ParrotIO object for stderr. The problem
is that at Parrot_exit, all PObjs are destroyed (including ParrotIO
objects), and trying to spit out such messages will fail with a SIGSEGV.
This patch turns off such tracing with a notice just before
force-destroying all PObjs (no matter the setting of GC_VERBOSE).
Without tracing enabled, it does nothing.
include/parrot/dod.h |3 ++-
src/inter_create.c |8
2 files changed, 10 insertions(+), 1 deletion(-)
--
Bram Geron | GPG 0xE7B9E65E
diff --git a/include/parrot/dod.h b/include/parrot/dod.h
index 79c1831..15df0e0 100644
--- a/include/parrot/dod.h
+++ b/include/parrot/dod.h
@@ -44,7 +44,8 @@
#define DOD_trace_stack_FLAG(UINTVAL)(1 0) /* trace system areads and stack */
#define DOD_trace_normal(UINTVAL)(1 0) /* the same */
#define DOD_lazy_FLAG (UINTVAL)(1 1) /* timely destruction run */
-#define DOD_finish_FLAG (UINTVAL)(1 2) /* run async past sweep */
+#define DOD_finish_FLAG (UINTVAL)(1 2) /* on Parrot exit: mark (almost) all PMCs dead and */
+/* garbage collect. */
#define DOD_no_trace_volatile_roots (UINTVAL)(1 3)
/* trace all but volatile root set, i.e. registers */
diff --git a/src/inter_create.c b/src/inter_create.c
index 51c355d..307fa71 100644
--- a/src/inter_create.c
+++ b/src/inter_create.c
@@ -314,6 +314,14 @@ Parrot_really_destroy(PARROT_INTERP, SHIM(int exit_code), SHIM(void *arg))
*/
interp-arena_base-DOD_block_level =
interp-arena_base-GC_block_level = 0;
+
+if (Interp_trace_TEST(interp, ~0)) {
+PIO_eprintf(interp, ParrotIO objects (like stdout and stderr) are about to be closed, so clearing trace flags.\n);
+Interp_trace_CLEAR(interp, ~0);
+}
+
+/* Destroys all PMCs, even constants and the ParrotIO objects for
+ * std{in,out,err}. So we better not try to be verbose about DOD'ing. */
Parrot_do_dod_run(interp, DOD_finish_FLAG);
#if STM_PROFILE
Re: [perl #44345] [PATCH] Add NQP to docs/glossary.pod
The attached patch adds NQP to the glossary in the docs directory. The attached, corrected patch gives the correct definition for NQP. Colin Index: docs/glossary.pod === --- docs/glossary.pod (revision 20449) +++ docs/glossary.pod (working copy) @@ -221,6 +221,12 @@ Acronym for Native Call Interface. +=head2 NQP + +Acronym for Not Quite Perl (6). NQP is designed to be a very small compiler for +quickly generating PIR routines to create transformers for Parrot (especially +HLL compilers). + =head2 Packfile Another name for a PBC file, due to the names used for data structures in one
[perl #44213] docs/faq.pod - fix Lfoo|http://... pod abuse
Seems like a pretty straightforward patch, but isn't the L syntax used currently proper? Is there a particular pod reader we're trying to make happy?
[perl #44393] something funny in dod/gc blocking macros
# New Ticket Created by Jerry Gay
# Please include the string: [perl #44393]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44393
i'm having trouble on x86_64. when running a 32bit parrot, i get
occasional deadlock at the OS level, after Parrot_exit. when running a
64bit parrot, it segfaults within Parrot_exit, while running the exit
handlers. if i run with -G, no segfault.
a comment in the source notes that disabling dod/gc may be a good
thing to do, since gc during interpreter teardown could lead to Bad
Things. sounds like that's a valid note, and addressing it will fix my
problems.
so, i try a patch:
===
Index: src/exit.c
===
--- src/exit.c (revision 20461)
+++ src/exit.c (working copy)
@@ -70,6 +70,9 @@
* and: interp-exit_handler_list is gone, after the last exit handler
* (Parrot_really_destroy) has run
*/
+Parrot_block_DOD(interp);
+Parrot_block_GC(interp);
+
handler_node_t *node = interp-exit_handler_list;
while (node) {
handler_node_t * const next = node-next;
===
but that gives me compile errors:
===
src\exit.c
src\exit.c(76) : error C2275: 'handler_node_t' : illegal use of this type as an
expression
c:\usr\local\parrot\trunk\include\parrot/exit.h(25) : see declaration of
'handler_node_t'
src\exit.c(76) : error C2065: 'node' : undeclared identifier
src\exit.c(78) : error C2223: left of '-next' must point to struct/union
src\exit.c(80) : error C2223: left of '-function' must point to struct/union
src\exit.c(80) : error C2223: left of '-arg' must point to struct/union
src\exit.c(81) : warning C4022: 'mem_sys_free' : pointer mismatch for actual par
ameter 1
src\exit.c(82) : warning C4047: '=' : 'int' differs in levels of indirection fro
m 'handler_node_t *const '
===
huh? something must be funny in these macros. a naive workaround:
===
Index: src/exit.c
===
--- src/exit.c (revision 20461)
+++ src/exit.c (working copy)
@@ -70,6 +70,10 @@
* and: interp-exit_handler_list is gone, after the last exit handler
* (Parrot_really_destroy) has run
*/
+Parrot_block_DOD(interp);
+Parrot_block_GC(interp);
+
+{
handler_node_t *node = interp-exit_handler_list;
while (node) {
handler_node_t * const next = node-next;
@@ -78,7 +82,7 @@
mem_sys_free(node);
node = next;
}
-
+}
exit(status);
}
===
compiles without error.
what's going on here? i have i feeling i'm close to fixing this
annoying bug, but now i've got to dive into two or three levels of
hate, and i really want to start my weekend.
so, that's what i'm going to do. feel free to beat me to fixing this
before i pick up on it again next week, please!
~jerry
[perl #44393] something funny in dod/gc blocking macros
hi, i'm a blockhead. ron reminded me that i'm not following C89, since node was not defined at the top of a block. duh. anyway, this doesn't seem to fix the problem. rats. i must misunderstand the comment, because i find it hard to believe that adding these few lines of code is enough to address a whole paragraph of comments. your input is most welcome. ~jerry
Re: [perl #44393] something funny in dod/gc blocking macros
On Friday 03 August 2007 13:29:53 Jerry Gay wrote: i'm having trouble on x86_64. when running a 32bit parrot, i get occasional deadlock at the OS level, after Parrot_exit. when running a 64bit parrot, it segfaults within Parrot_exit, while running the exit handlers. if i run with -G, no segfault. Bram Geron's patches in RT #44363 and RT #44351 look reasonable to me. I think they might work for you. -- c
Re: [perl #44213] docs/faq.pod - fix Lfoo|http://... pod abuse
Will Coleda via RT wrote: Seems like a pretty straightforward patch, but isn't the L syntax used currently proper? Is there a particular pod reader we're trying to make happy? I tripped over this recently too. From perlpod: * Lscheme:... Links to an absolute URL. For example, Lhttp://www.perl.org/. But note that there is no corresponding Ltext|scheme:... syntax, for various reasons.
Re: [perl #44213] docs/faq.pod - fix Lfoo|http://... pod abuse
# from Will Coleda via RT # on Friday 03 August 2007 01:40 pm: Seems like a pretty straightforward patch, but isn't the L syntax used currently proper? The L doesn't support named http:// links. from perlpod: ' Lscheme:... Links to an absolute URL. For example, Lhttp://www.perl.org/. But note that there is no corresponding Ltext|scheme:... syntax, for various reasons. ' Is there a particular pod reader we're trying to make happy? I'm assuming the website uses combust, so mostly whatever combust uses. The 68K emulator and April Fool's Joke links here are broken because of it: http://www.parrotcode.org/faq/ Also, pod2html (Pod::HTML) and Pod::Simple::HTML. Thanks, Eric -- It is impossible to make anything foolproof because fools are so ingenious. --Murphy's Second Corollary --- http://scratchcomputing.com ---
Re: [perl #44379] config/auto/attributes.pm ought to use its own test_c.in
On 8/3/07, via RT Andy Dougherty [EMAIL PROTECTED] wrote:
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #44379]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44379
The new attributes scanning ought to use its own test_c.in file, instead
of trying to piggy-back off existing test_c.in files. The scheme in place
has several problems:
1. It has no fallback. From attributes.pm, the following snippet:
if ( $cc =~ /gcc/ ) {
cc_gen('config/auto/gcc/test_c.in');
}
elsif ( $cc eq 'cl' ) {
cc_gen('config/auto/msvc/test_c.in');
}
does nothing for other compilers. Obviously, all the compiles fail,
since no test.c file is generated. I don't know, for example, if 'icc'
handles attributes, or if it might in the future.
2. The name of the compiler is not the best test of whether you are
using gcc. On Linux, for example, if you use Configure.pl --cc=cc, then
this test,
if ( $cc =~ /gcc/ ) {
fails, even though you are using gcc. A better test is to check
gccversion.
3. The attributes testing is now duplicated in two test files,
gcc/test_c.in and msvc/test_c.in.
4. It's now potentially more difficult to use gcc/test_c.in for its
intended use. For example, the Solaris hints file needs to know if
we're using gcc, and it used to try to compile the gcc/test_c.in
program. Now, it has to add in -Iinclude/ to pick up
parrot/compilers.h which does the #ifdef dance around all the
attributes. All this compilication just to see if we're using gcc.
A much better plan, in my humble opinion, is to revert most of these
changes and simply make a *new* test_c.in file,
config/auto/attributes/test_c.in. Each test file can then concentrate
on doing one test.
Thanks for listening,
you're right, on all points. i hacked that code in to get msvc
working, and figured i'd clean up the damage later. sorry, i didn't
think of testing icc before i committed--of course it'll break.
i don't expect to have the tuits until monday, though. hopefully
somebody will step in before then and clean up the mess andy and i
made. otherwise, i'll get to it first when i'm available.
~jerry
[perl #44379] config/auto/attributes.pm ought to use its own test_c.in
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #44379]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44379
The new attributes scanning ought to use its own test_c.in file, instead
of trying to piggy-back off existing test_c.in files. The scheme in place
has several problems:
1. It has no fallback. From attributes.pm, the following snippet:
if ( $cc =~ /gcc/ ) {
cc_gen('config/auto/gcc/test_c.in');
}
elsif ( $cc eq 'cl' ) {
cc_gen('config/auto/msvc/test_c.in');
}
does nothing for other compilers. Obviously, all the compiles fail,
since no test.c file is generated. I don't know, for example, if 'icc'
handles attributes, or if it might in the future.
2. The name of the compiler is not the best test of whether you are
using gcc. On Linux, for example, if you use Configure.pl --cc=cc, then
this test,
if ( $cc =~ /gcc/ ) {
fails, even though you are using gcc. A better test is to check
gccversion.
3. The attributes testing is now duplicated in two test files,
gcc/test_c.in and msvc/test_c.in.
4. It's now potentially more difficult to use gcc/test_c.in for its
intended use. For example, the Solaris hints file needs to know if
we're using gcc, and it used to try to compile the gcc/test_c.in
program. Now, it has to add in -Iinclude/ to pick up
parrot/compilers.h which does the #ifdef dance around all the
attributes. All this compilication just to see if we're using gcc.
A much better plan, in my humble opinion, is to revert most of these
changes and simply make a *new* test_c.in file,
config/auto/attributes/test_c.in. Each test file can then concentrate
on doing one test.
Thanks for listening,
--
Andy Dougherty [EMAIL PROTECTED]
[perl #44381] Should Configure.pl scan for __attribute__ at all?
# New Ticket Created by Andy Dougherty # Please include the string: [perl #44381] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44381 Thinking *way* ahead, I wonder if Configure.pl should even bother scanning for __attribute__ at all. Perhaps it should just be hardcoded somewhere in parrot/*.h. In perl5, we're moving in that direction. Here's the relevant excerpt from perl.h: /* In case Configure was not used (we are using a canned config * such as Win32, or a cross-compilation setup, for example) try going * by the gcc major and minor versions. One useful URL is * http://www.ohse.de/uwe/articles/gcc-attributes.html, * but contrary to this information warn_unused_result seems * not to be in gcc 3.3.5, at least. --jhi * Also, when building extensions with an installed perl, this allows * the user to upgrade gcc and get the right attributes, rather than * relying on the list generated at Configure time. --AD * Set these up now otherwise we get confused when some of the *thread.h * includes below indirectly pull in perlio.h (which needs to know if we * have HASATTRIBUTE_FORMAT). */ #if defined __GNUC__ !defined(__INTEL_COMPILER) # if __GNUC__ = 3 /* 3.0 - */ /* XXX Verify this version */ #define HASATTRIBUTE_FORMAT #if defined __MINGW32__ # define PRINTF_FORMAT_NULL_OK #endif # endif # if __GNUC__ = 3 /* 3.0 - */ #define HASATTRIBUTE_MALLOC # endif # if __GNUC__ == 3 __GNUC_MINOR__ = 3 || __GNUC__ 3 /* 3.3 - */ #define HASATTRIBUTE_NONNULL # endif # if __GNUC__ == 2 __GNUC_MINOR__ = 5 || __GNUC__ 2 /* 2.5 - */ #define HASATTRIBUTE_NORETURN # endif # if __GNUC__ = 3 /* gcc 3.0 - */ #define HASATTRIBUTE_PURE # endif # if __GNUC__ == 3 __GNUC_MINOR__ = 4 || __GNUC__ 3 /* 3.4 - */ #define HASATTRIBUTE_UNUSED # endif # if __GNUC__ == 3 __GNUC_MINOR__ == 3 !defined(__cplusplus) #define HASATTRIBUTE_UNUSED /* gcc-3.3, but not g++-3.3. */ # endif # if __GNUC__ == 3 __GNUC_MINOR__ = 4 || __GNUC__ 3 /* 3.4 - */ #define HASATTRIBUTE_WARN_UNUSED_RESULT # endif #endif -- Andy Dougherty [EMAIL PROTECTED]
[perl #44395] Lexical scopes are too coarse-grained for loops.
# New Ticket Created by Bob Rogers
# Please include the string: [perl #44395]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44395
The problem arises when blocks with closed-over lexical bindings are
executed more than once, as can happen inside loops. Here is an example
in Perl 5:
sub make_closures_loop {
# Return $n closures, each with lexical references to $i and $n.
my $n = shift;
my @result;
for (1..$n) {
my $i = $_;
push(@result, sub { print Called sub $i out of $n.\n; });
}
return @result;
}
Here there is only one $n binding, but a new and independent $i binding
is created every time through the loop, as running the first attachment
clearly shows. It makes no difference if you say for my $i ... or
replace the loop with map instead.
A naive PIR implementation of this loop is included as the second
attachment. It fails miserably, because PIR can't distinguish between
the different scopes for $i and $n.
Currently, the only way to get a distinct binding for each $i in
PIR is to factor the loop body out into a separate lexical sub. This is
far from ideal, not least because it is not transparent to the HLL user.
It is also painful for compilers to optimize away: In order to decide
whether the extra sub is really needed, the compiler must find all the
closed-over variables first, which (for me at least) requires breaking
lexical analysis into two passes.
Parrot should do better, IMHO. The easiest way, it seems, would be
to resurrect the push_pad and pop_pad instructions in some form. After
the lexical analysis, the compiler can simply use the same is this
closed-over binding inside a loop? analysis to decide whether or not it
needs to emit push_pad/pop_pad at the appropriate places. It then
becomes purely a question of merging lexical scopes during optimization,
and doesn't affect semantic correctness.
FWIW, I do remember waaay back when Leo got rid of the explicit pad
manipulation instructions (r10240 on 2005-11-29 and thereabouts). At
the time, it went right over my head that I might ever need these (my
compiler didn't even support closures until three weeks later), for
which I am now very sorry. I am hoping that others will have a similar
reaction, and that push_pad etc. weren't flushed due to some fundamental
problem.
For the record, continuations are also broken in this respect; not
surprisingly, they'll take you back to the right context, but with
whatever value of $i was stored last. So whatever solution is
adopted, we need to make sure that continuations capture the detailed
lexical state.
Any objection if I start working on this?
TIA,
-- Bob Rogers
http://rgrjr.dyndns.org/
#! /usr/bin/perl -w
use strict;
use warnings;
sub make_closures_loop {
# Return n closures, each with lexical references to $i and $n.
my $n = shift;
my @result;
for (1..$n) {
my $i = $_;
push(@result, sub { print Called sub $i out of $n.\n; });
}
return @result;
}
# Make three closures and call them in turn.
for my $c (make_closures_loop(3)) {
$c-();
}
## Return n closures, each with lexical references to I and N'.
.sub make_closures_loop
.param pmc n
.lex $n, n
.lex $i, $P42
.local pmc result
result = new .FixedPMCArray
$I1 = n
result = $I1
.const .Sub $P53 = 'internal_make_closures_loop_0'
$I0 = 0
next:
if $I0 = $I1 goto done
$P42 = new .Integer
$P42 = $I0
inc $P42
newclosure $P52, $P53
result[$I0] = $P52
inc $I0
goto next
done:
.return (result)
.end
.sub internal_make_closures_loop_0 :outer('make_closures_loop')
find_lex $P42, $i
find_lex $P43, $n
print Called sub
print $P42
print out of
print $P43
print .\n
.end
## Make three closures and call them in turn.
.sub test_closures :main
.local pmc closures
$I1 = 3
closures = make_closures_loop($I1)
$I0 = 0
next:
if $I0 = $I1 goto done
$P52 = closures[$I0]
$P52()
inc $I0
goto next
done:
.end
[perl #44391] r19820 breaks other JITs
# New Ticket Created by Joshua Isom # Please include the string: [perl #44391] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44391 After a fair amount of headaches, I finally discovered some of my trouble with my jit. It seems as though r19820 changed the API for preserving and restoring parrot's registers to cpu registers. The cause was to convert internal_exceptions(fatal) to real_exceptions(maybe fatal), and since internal_exceptions need interp, interp gets passed around. Only i386 was fixed to handle the API change, and PPC's broken. In this case, real_exception could be appropriate to prevent executing bad/incomplete machine code that would crash parrot. If you look at the exceptions used, in i386's jit_emit.h, it's more a bad jit_emit.h than anything caused by a user.
[svn:perl6-synopsis] r14432 - doc/trunk/design/syn
Author: larry Date: Fri Aug 3 18:27:52 2007 New Revision: 14432 Modified: doc/trunk/design/syn/S05.pod doc/trunk/design/syn/S06.pod Log: Clarification of meaning of foo: string form as non-interpolating Restriction of placeholder names to lowercase to help us catch $^O et al. Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podFri Aug 3 18:27:52 2007 @@ -14,9 +14,9 @@ Maintainer: Patrick Michaud [EMAIL PROTECTED] and Larry Wall [EMAIL PROTECTED] Date: 24 Jun 2002 - Last Modified: 10 Jul 2007 + Last Modified: 3 Jul 2007 Number: 5 - Version: 61 + Version: 62 This document summarizes Apocalypse 5, which is about the new regex syntax. We now try to call them Iregex rather than regular @@ -1000,7 +1000,8 @@ foo: bar -To pass a string with leading whitespace you must use the parenthesized form. +To pass a string with leading whitespace, or to interpolate any values +into the string, you must use the parenthesized form. If the first character is a plus or minus, the initial identifier is taken as a character class, so the first character after the Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podFri Aug 3 18:27:52 2007 @@ -13,9 +13,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 21 Mar 2003 - Last Modified: 2 Jun 2007 + Last Modified: 3 Aug 2007 Number: 6 - Version: 88 + Version: 89 This document summarizes Apocalypse 6, which covers subroutines and the @@ -1397,6 +1397,8 @@ Note that placeholder variables syntactically cannot have type constraints. Also, it is illegal to use placeholder variables in a block that already has a signature, because the autogenerated signature would conflict with that. +Placeholder names may only be lowercase, not because we're mean, but +because it helps us catch references to obsolete Perl 5 variables such as $^O. =head1 Properties and traits
[svn:perl6-synopsis] r14433 - doc/trunk/design/syn
Author: larry Date: Fri Aug 3 18:40:13 2007 New Revision: 14433 Modified: doc/trunk/design/syn/S05.pod Log: date typo Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podFri Aug 3 18:40:13 2007 @@ -14,7 +14,7 @@ Maintainer: Patrick Michaud [EMAIL PROTECTED] and Larry Wall [EMAIL PROTECTED] Date: 24 Jun 2002 - Last Modified: 3 Jul 2007 + Last Modified: 3 Aug 2007 Number: 5 Version: 62
[perl #44389] Excessive warnings on Apple's gcc 3.3 wrt attributes
# New Ticket Created by Joshua Isom # Please include the string: [perl #44389] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44389 The new attribute configure code seems to get a false positive with warn_unused_result on Apple's gcc 3.3. Here's the configure output from the attribute checking code. Detecting compiler attributes (-DHASATTRIBUTE_xxx)... trying attribute 'HASATTRIBUTE_CONST' cc: cc cc -o test -Iinclude -fno-common -no-cpp-precomp -pipe -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_CONST test.c exit code: 1 trying attribute 'HASATTRIBUTE_DEPRECATED' cc: cc cc -o test -Iinclude -fno-common -no-cpp-precomp -pipe -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_DEPRECATED test.c exit code: 1 trying attribute 'HASATTRIBUTE_FORMAT' cc: cc cc -o test -Iinclude -fno-common -no-cpp-precomp -pipe -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_FORMAT test.c exit code: 1 trying attribute 'HASATTRIBUTE_MALLOC' cc: cc cc -o test -Iinclude -fno-common -no-cpp-precomp -pipe -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_MALLOC test.c exit code: 1 trying attribute 'HASATTRIBUTE_NONNULL' cc: cc cc -o test -Iinclude -fno-common -no-cpp-precomp -pipe -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_NONNULL test.c exit code: 1 trying attribute 'HASATTRIBUTE_NORETURN' cc: cc cc -o test -Iinclude -fno-common -no-cpp-precomp -pipe -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_NORETURN test.c exit code: 1 trying attribute 'HASATTRIBUTE_PURE' cc: cc cc -o test -Iinclude -fno-common -no-cpp-precomp -pipe -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_PURE test.c exit code: 1 trying attribute 'HASATTRIBUTE_UNUSED' cc: cc cc -o test -Iinclude -fno-common -no-cpp-precomp -pipe -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_UNUSED test.c exit code: 1 trying attribute 'HASATTRIBUTE_WARN_UNUSED_RESULT' cc: cc cc -o test -Iinclude -fno-common -no-cpp-precomp -pipe -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_WARN_UNUSED_RESULT test.c exit code: 1 trying attribute 'HASATTRIBUTE_NEVER_WORKS' cc: cc cc -o test -Iinclude -fno-common -no-cpp-precomp -pipe -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_NEVER_WORKS test.c exit code: 1 My CC: ccache gcc -I./include -fno-common -no-cpp-precomp -pipe -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -I/sw/include -I/sw/include -I /sw/include -g -W -Wall -Wundef -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Winline -Wpointer-arith -Wcast-qual -Wwrite-strings -Waggregate-return -Winline -Wno-unused -Wnested-externs -Wsign-compare -falign-functions=16 -Wformat-nonliteral -Wformat-security -Wpacked -Wdisabled-optimization -Wno-shadow -DHAS_JIT -DPPC -DHAVE_COMPUTED_GOTO -I. -o xx.o -c xx.c And some of gcc's output. include/parrot/stacks.h:56: warning: `warn_unused_result' attribute directive ignored include/parrot/stacks.h:56: warning: `warn_unused_result' attribute directive ignored include/parrot/stacks.h:68: warning: `warn_unused_result' attribute directive ignored include/parrot/stacks.h:80: warning: `warn_unused_result' attribute directive ignored
Re: [perl #44389] Excessive warnings on Apple's gcc 3.3 wrt attributes
Joshua Isom wrote: # New Ticket Created by Joshua Isom # Please include the string: [perl #44389] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44389 The new attribute configure code seems to get a false positive with warn_unused_result on Apple's gcc 3.3. Confirmed. Over the last few weeks, my log of my 'make' output on Darwin has tended to run in the range of 70-73K. Tonight it ran to over 7.1M. -rw-r--r-- 1 jimk jimk70806 Jul 14 17:43 14.07.2007.make.04.txt -rw-r--r-- 1 jimk jimk71898 Jul 15 10:30 15.07.2007.make.txt -rw-r--r-- 1 jimk jimk73181 Jul 22 21:17 21.07.2007.make.txt -rw-r--r-- 1 jimk jimk 7167507 Aug 3 21:43 03.08.2007.make.txt I certainly hope someone can patch this; it's not an area in which I have any expertise. Thank you very much. Summary of my parrot 0.4.14 (r20463) configuration: configdate='Sat Aug 4 01:28:41 2007 GMT' Platform: osname=darwin, archname=darwin-2level jitcapable=1, jitarchname=ppc-darwin, jitosname=DARWIN, jitcpuarch=ppc execcapable=1 perl=/usr/local/bin/perl Compiler: cc='/usr/bin/gcc-3.3', ccflags='-fno-common -no-cpp-precomp -pipe -I/usr/local/include -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT', Linker and Libraries: ld='/usr/bin/g++-3.3', ldflags=' -L/usr/local/lib -L/Users/jimk/work/parrot/blib/lib -flat_namespace ', cc_ldflags='', libs='-lm' Dynamic Linking: share_ext='.dylib', ld_share_flags='-dynamiclib -undefined suppress', load_ext='.bundle', ld_load_flags='-bundle -undefined suppress' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=4321, nv=double, numvalsize=8, doublesize=8
Re: [perl #44395] Lexical scopes are too coarse-grained for loops.
On Fri, Aug 03, 2007 at 03:37:39PM -0700, Bob Rogers wrote:
A naive PIR implementation of this loop is included as the second
attachment. It fails miserably, because PIR can't distinguish between
the different scopes for $i and $n.
sub make_closures_loop {
# Return n closures, each with lexical references to $i and $n.
my $n = shift;
my @result;
for (1..$n) {
my $i = $_;
push(@result, sub { print Called sub $i out of $n.\n; });
}
return @result;
}
[...]
## Return n closures, each with lexical references to I and N'.
.sub make_closures_loop
.param pmc n
.lex $n, n
.lex $i, $P42
[...]
.sub internal_make_closures_loop_0 :outer('make_closures_loop')
find_lex $P42, $i
find_lex $P43, $n
[...]
This seems wrong to me -- shouldn't $i be scoped to the internal
loop instead of the outer one? In other words, I think the PIR
code should read:
.sub make_closures_loop
.param pmc n
.lex $n, n
...
and then
.sub internal_make_closures_loop_0 :outer('make_closures_loop')
.lex $i, $P42
find_lex $P43, $n
...
Otherwise, the reason that PIR isn't able to distinguish the
scopes is because in PIR you're actually defining them to be
in the same scope.
However, I must confess that I still haven't grokked all of the
ramifications of lexicals and closures in PIR yet -- and I may
even be interpreting the p5 translation incorrectly. It just
looks to me as though the naive translation isn't being faithful
to the original p5 source, and so perhaps that's causing the
problem you're seeing.
Hope this helps,
Pm
Re: [perl #44395] Lexical scopes are too coarse-grained for loops
Perhaps ignore my earlier message -- this one is more coherent.
On Fri, Aug 03, 2007 at 03:37:39PM -0700, Bob Rogers wrote:
sub make_closures_loop {
# Return $n closures, each with lexical references to $i and $n.
my $n = shift;
my @result;
for (1..$n) {
my $i = $_;
push(@result, sub { print Called sub $i out of $n.\n; });
}
return @result;
}
Currently, the only way to get a distinct binding for each $i in
PIR is to factor the loop body out into a separate lexical sub. This is
far from ideal, not least because it is not transparent to the HLL user.
Factoring the loop body out into a separate lexical sub is _exactly_
how Chip described to me that the above needed to be done.
Or, phrased differently, every lexical scope ends up requiring
its own parrot sub (with appropriate :outer pragmas), and the
compiler can optimize out such subs when it determines that there
aren't any new lexicals being declared within the loop body
(which somewhat comes down to keeping track of whether the loop
body contains any my declarations).
I'm not sure why this separate lexical sub has to be visible
to the HLL user -- the compiler ought to be able to make it appear
as though the sub isn't present. (But I also bet that we can
come up with an example that makes it really hard to do that.)
Parrot should do better, IMHO. The easiest way, it seems, would be
to resurrect the push_pad and pop_pad instructions in some form. [...]
I'd like for Parrot to be able to do better, yes, but I'm not
yet enough of an expert on closure handling to be able to
refute Chip's reasons for designing things this way. I also
found the push_pad and pop_pad model somewhat easier to grasp
conceptually, but I recall Chip was fairly certain that they
wouldn't handle things in the generic case.
FWIW, the perl6 compiler currently treats _every_ block as a new
lexical scope, and generates a separate Parrot sub for each.
At some point we will add an optimization so that blocks can
be inlined when the compiler determines that it's safe to do
so (based in part on the absence of any lexical declarations
within the block).
Hope this helps somewhat more than my previous message... :-)
Pm
Re: [perl #44395] Lexical scopes are too coarse-grained for loops
On Fri, Aug 03, 2007 at 09:51:53PM -0500, Patrick R. Michaud wrote:
Currently, the only way to get a distinct binding for each $i in
PIR is to factor the loop body out into a separate lexical sub. This is
far from ideal, not least because it is not transparent to the HLL user.
Factoring the loop body out into a separate lexical sub is _exactly_
how Chip described to me that the above needed to be done.
Just for completeness, attached is a PIR version that I think
is slightly more faithful to the original test-closures.pl
program. It appears to work:
$ ./parrot test-closures-3.pir
Called sub 1 out of 3.
Called sub 2 out of 3.
Called sub 3 out of 3.
$
Pm
## Return n closures, each with lexical references to I and N'.
.sub make_closures_loop
.param pmc n
.lex $n, n
.lex @result, $P0
$P0 = new 'ResizablePMCArray'
$I0 = 1
$I1 = n
next:
if $I0 $I1 goto done
'internal_loop_body'($I0)
inc $I0
goto next
done:
.return ($P0)
.end
.sub 'internal_loop_body' :outer('make_closures_loop')
.param pmc topic
.lex '$_', topic
$P0 = clone topic
.lex '$i', $P0
.const .Sub $P1 = 'internal_sub'
newclosure $P2, $P1
find_lex $P3, '@result'
push $P3, $P2
.return ($P3)
.end
.sub 'internal_sub' :outer('internal_loop_body')
find_lex $P0, '$i'
find_lex $P1, '$n'
print Called sub
print $P0
print out of
print $P1
print .\n
.end
## Make three closures and call them in turn.
.sub test_closures :main
.local pmc closures
$I1 = 3
closures = make_closures_loop($I1)
$I0 = 0
next:
if $I0 = $I1 goto done
$P52 = closures[$I0]
$P52()
inc $I0
goto next
done:
.end
Re: [perl #44395] Lexical scopes are too coarse-grained for loops
From: Patrick R. Michaud [EMAIL PROTECTED]
Date: Fri, 3 Aug 2007 21:51:53 -0500
Perhaps ignore my earlier message -- this one is more coherent.
I haven't gotten that one yet. (Must have been via RT. Now if I could
only remember to send all my incoherent posts via RT. ;-)
On Fri, Aug 03, 2007 at 03:37:39PM -0700, Bob Rogers wrote:
sub make_closures_loop {
# Return $n closures, each with lexical references to $i and $n.
my $n = shift;
my @result;
for (1..$n) {
my $i = $_;
push(@result, sub { print Called sub $i out of $n.\n; });
}
return @result;
}
Currently, the only way to get a distinct binding for each $i in
PIR is to factor the loop body out into a separate lexical sub. This is
far from ideal, not least because it is not transparent to the HLL user.
Factoring the loop body out into a separate lexical sub is _exactly_
how Chip described to me that the above needed to be done.
Or, phrased differently, every lexical scope ends up requiring
its own parrot sub . . .
Bummer.
I'm not sure why this separate lexical sub has to be visible
to the HLL user -- the compiler ought to be able to make it appear
as though the sub isn't present. (But I also bet that we can
come up with an example that makes it really hard to do that.)
It will show up in backtraces, if nothing else. This may complicate the
user's debugging session slightly, because what the user assumed would
be one call frame is actually two, and inner functions may not have the
expected compiler-assigned names, but that's hardly a show-stopper.
Parrot should do better, IMHO. The easiest way, it seems, would be
to resurrect the push_pad and pop_pad instructions in some form. [...]
I'd like for Parrot to be able to do better, yes, but I'm not
yet enough of an expert on closure handling to be able to
refute Chip's reasons for designing things this way.
The current model has the advantage of being more declarative, which is
good; things that can be nailed down at compile time should be. But the
same thing could be done for multiple loop scopes as well. Consider the
following alternative:
## Return n closures, each with lexical references to I and N'.
.sub make_closures_loop
.param pmc n
.lex $n, n
.local pmc result
result = new .FixedPMCArray
$I1 = n
result = $I1
.const .Sub $P53 = 'internal_make_closures_loop_0'
$I0 = 0
next:
if $I0 = $I1 goto done
.push_scope
.lex $i, $P42
$P42 = new .Integer
$P42 = $I0
inc $P42
newclosure $P52, $P53
result[$I0] = $P52
inc $I0
.pop_scope
goto next
done:
.return (result)
.end
Every .lex belongs to the immediately enclosing .push_scope/.pop_scope
group (or the sub top-level scope). .push_scope needs to expand into
push_pad, and .pop_scope needs to do a pop_pad, but the pseudo-ops serve
to delimit scopes so that the PIR compiler can build a LexInfo object
for each scope. (But the inner .lex ops may require an explicit
store_lex, since they are not being stored in the Parrot_Context.
(Which is a good thing.))
I also found the push_pad and pop_pad model somewhat easier to grasp
conceptually, but I recall Chip was fairly certain that they wouldn't
handle things in the generic case.
They would certainly permit more to be handled than is handled now. And
re-adding them should be monotonic in terms of Parrot functionality.
Which means that Chip's statement (IYRC) seems to make no sense. ???
FWIW, the perl6 compiler currently treats _every_ block as a new
lexical scope, and generates a separate Parrot sub for each . . .
Hmm. The lexical scope == Parrot sub worldview seems backwards to me.
But probably I'm just grumbling because I've realized I'm going to have
to rewrite a fair-sized chunk of my compiler to cope with this. Oh,
well; so be it.
From: Patrick R. Michaud [EMAIL PROTECTED]
Date: Fri, 3 Aug 2007 22:13:25 -0500
Just for completeness, attached is a PIR version that I think
is slightly more faithful to the original test-closures.pl
program. It appears to work:
$ ./parrot test-closures-3.pir
Called sub 1 out of 3.
Called sub 2 out of 3.
Called sub 3 out of 3.
$
Pm
Makes sense; looks like what map would compile into, if the block were
not inlined.
Thanks for explaining the situation.
-- Bob
Re: [perl #37287] [TODO] pdb - don't die on exceptions
This patch makes parrot stop execution of the vm when running as a debugger. This makes the pdb stop executing and shows the exception message instead of silently exiting. Hi, pancake! I have tried to update your patch to svn r20469, see attached patch. Unfortunately, it doesn't work any longer. I wrote a simple test file (see attached test.pir) that just generates an exception. Then I tried to run it under parrot, and it generated an exception, as expected. [EMAIL PROTECTED] ~/parrot $ ./parrot test.pir Null PMC access in get_string() current instr.: 'main' pc 0 (test.pir:3) Problem is, when I then ran it under pdb, it died pretty horribly. [EMAIL PROTECTED] ~/parrot $ ./pdb test.pir Parrot Debugger 0.4.x Please note: the debugger is currently under reconstruction (pdb) r Restarting Hijacked exception: Null PMC access in get_string() Restarting *** glibc detected *** ./pdb: free(): invalid pointer: 0xb6f191b8 *** === Backtrace: = /lib/libc.so.6[0xb6e4efaf] /lib/libc.so.6(__libc_free+0x89)[0xb6e4fce9] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(mem_sys_free+0x23)[0xb7c3b9b3] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(PDB_free_file+0x98)[0xb7c2eb38] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(PDB_disassemble+0x62)[0xb7c2e712] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(Parrot_debug+0x65)[0xb7c31c85] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(runops_slow_core+0x60)[0xb7c76130] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(runops_int+0x190)[0xb7c46b80] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(runops+0xfd)[0xb7c474cd] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14[0xb7c476e6] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(Parrot_runops_fromc_args+0x36)[0xb7c477f6] /home/paranoid/parrot/blib/lib/libparrot.so.0.4.14(Parrot_runcode+0x22f)[0xb7c31c0f] ./pdb(main+0x2d2)[0x8048f22] /lib/libc.so.6(__libc_start_main+0xe2)[0xb6dfe9d2] ./pdb[0x8048bb1] === Memory map: 08048000-0804a000 r-xp fe:03 636705 /home/paranoid/parrot/pdb 0804a000-0804b000 rw-p 1000 fe:03 636705 /home/paranoid/parrot/pdb 0804b000-0841 rw-p 0804b000 00:00 0 [heap] b5b0-b5b21000 rw-p b5b0 00:00 0 b5b21000-b5c0 ---p b5b21000 00:00 0 b5cca000-b5d0c000 rw-p b5cca000 00:00 0 b5d0c000-b5d0d000 ---p b5d0c000 00:00 0 b5d0d000-b650d000 rw-p b5d0d000 00:00 0 b650d000-b650e000 ---p b650d000 00:00 0 b650e000-b6d1 rw-p b650e000 00:00 0 b6d1-b6d18000 r-xp fe:00 292092 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.6/libgcc_s.so.1 b6d18000-b6d19000 rw-p 7000 fe:00 292092 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.6/libgcc_s.so.1 b6d19000-b6ddf000 r-xp fe:00 292103 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3 b6ddf000-b6de4000 rw-p 000c6000 fe:00 292103 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3 b6de4000-b6de9000 rw-p b6de4000 00:00 0 b6de9000-b6f16000 r-xp 03:01 40041 /lib/libc-2.6.so b6f16000-b6f17000 r--p 0012d000 03:01 40041 /lib/libc-2.6.so b6f17000-b6f19000 rw-p 0012e000 03:01 40041 /lib/libc-2.6.so b6f19000-b6f1c000 rw-p b6f19000 00:00 0 b6f1c000-b6f57000 r-xp 03:01 6397 /lib/libncurses.so.5.6 b6f57000-b6f6 rw-p 0003a000 03:01 6397 /lib/libncurses.so.5.6 b6f6-b6f8c000 r-xp 03:01 20277 /lib/libreadline.so.5.2 b6f8c000-b6f9 rw-p 0002b000 03:01 20277 /lib/libreadline.so.5.2 b6f9-b6f92000 rw-p b6f9 00:00 0 b6f92000-b6fc3000 r-xp fe:00 7746 /usr/lib/libgmp.so.3.4.1 b6fc3000-b6fc4000 rw-p 00031000 fe:00 7746 /usr/lib/libgmp.so.3.4.1 b6fc4000-b6fcb000 r-xp 03:01 35535 /lib/librt-2.6.so b6fcb000-b6fcd000 rw-p 6000 03:01 35535 /lib/librt-2.6.so b6fcd000-b6fcf000 r-xp 03:01 40037 /lib/libutil-2.6.so b6fcf000-b6fd1000 rw-p 1000 03:01 40037 /lib/libutil-2.6.so b6fd1000-b6fd6000 r-xp 03:01 40035 /lib/libcrypt-2.6.so b6fd6000-b6fd8000 rw-p 4000 03:01 40035 /lib/libcrypt-2.6.so b6fd8000-b6fff000 rw-p b6fd8000 00:00 0 b6fff000-b7001000 r-xp 03:01 40028 /lib/libdl-2.6.so b7001000-b7003000 rw-p 1000 03:01 40028 /lib/libdl-2.6.so b7003000-b7016000 r-xp 03:01 6394 /lib/libnsl-2.6.so b7016000-b7018000 rw-p 00012000 03:01 6394 /lib/libnsl-2.6.so b7018000-b701b000 rw-p b7018000 00:00 0 b701b000-b79ca000 r--p fe:00 384232 /usr/lib/libicudata.so.36.0 b79ca000-b79cb000 rw-p 009ae000 fe:00 384232 /usr/lib/libicudata.so.36.0 b79cb000-b7adc000 r-xp fe:00 403052 /usr/lib/libicuuc.so.36.0 b7adc000-b7ae3000 rw-p 00111000 fe:00 403052 /usr/lib/libicuuc.so.36.0 b7ae3000-b7ae5000 rw-p b7ae3000 00:00 0 b7ae5000-b7b08000 r-xp 03:01 40040 /lib/liAborted [EMAIL PROTECTED] ~/parrot $ It's a useful patch, and I think it *almost* works. Maybe pdb itself is broken. Also note I've created a test program[1] for pdb, at
Re: [perl #44389] Excessive warnings on Apple's gcc 3.3 wrt attributes
On Friday 03 August 2007 18:45:37 James E Keenan wrote: Confirmed. Over the last few weeks, my log of my 'make' output on Darwin has tended to run in the range of 70-73K. Tonight it ran to over 7.1M. r20454 doesn't help. Of course, it looks like that's papering over the fact that the noreturn attribute expands (for me on x86 Linux, that is) to: #define PARROT_DOES_NOT_RETURN /[EMAIL PROTECTED]@*/ __attribute__noreturn__ ... when it looks like it should be: #define PARROT_DOES_NOT_RETURN /[EMAIL PROTECTED]@*/ __attribute__((noreturn)) So I'm not sure what went weird. -- c
