Re: [PCT] PAST nodes for goto and friends, labels.
On Jan 24, 2008 5:45 PM, Patrick R. Michaud [EMAIL PROTECTED] wrote:
On Sat, Jan 19, 2008 at 12:24:37PM +0100, Klaas-Jan Stol wrote:
as far as I could tell there's no support for goto statements in PCT
(that
is, special nodes or something).
I don't know whether there are any plans to add special support for it,
but
here's an idea I was thinking about. It would be rather helpful, instead
of
having this handle by each language implementer, by manually generating
(:inline) statements that result in a label and the relating
goto/jump
statements; it's a pretty common feature.
Statements like break, next, last, continue typically take a
label
as an argument (or it's implicit like for continue).
You're correct that PCT doesn't have support for 'goto' yet, and
yes, it will. However, the typical model for this is likely to
be based on control exceptions instead of using branches and labels.
To borrow from your example:
while ($x 10) {
$x++;
next if $x 5;
print $x;
}
In Perl, the { ... } represents a new lexical scope, and in the
general case that means it's a separate Parrot sub with an
:outer flag. Thus when we determine that we need to invoke 'next',
we can't do it with a simple branch, we need to throw an exception
that gets caught by the while loop in the outer Parrot sub and
handled there.
The same is true for labels on the control exceptions, such as
next LABEL -- in this case the control exception propagates
outward until it reaches the construct having the corresponding
label.
A similar situation exists for 'return': because it's possible
to invoke a return inside of a nested lexical block, it needs to be
treated as a control exception that can propagate outward through
outer lexical Parrot subs until it reaches the outer block of
the higher-level sub and gets returned from there.
I haven't completely figured out how we'll handle 'goto' statements,
but I'm suspecting it will also need to be based on control
exceptions as opposed to simple PIR branches.
It's possible that some HLLs or situations may warrant optimizing
control statements to use branches instead of control exceptions --
e.g., when the body of a loop isn't a nested lexical block.
But I think we're better off saving that as a later optimization
than trying to resolve it now.
So, the next step on this issue will likely be for PCT to define a
relatively standard interface for its control exceptions, and then
adjust its node types to be able to throw and catch the control
exceptions as appropriate.
Thanks!
Pm
One more common construct is the switch statement, especially if the
language has fall-through semantics for the cases (so no implicit
break). I think Perl 6 (given statement) has implicit breaks, so that only
the selected case is executed. Many other languages that will be dealt with,
let control fall through the cases, which is a pain to implement by hand. It
cannot be done simply by creating :pasttype('if') nodes, as that will only
execute the then block (first child). It would be nice to have some kind
of 'switch' node (IIRC, the JVM even has a special instruction for that),
that takes a list of 'case' conditions, and the blocks (or maybe better
would be a 'case' node, taking a 'condition' child and a 'block' child, that
is executed. The 'switch' node could be a specialized version of 'Stmts',
that takes these 'case' nodes as children, and has an attribute
'fallthrough' or whatever).
Maybe I'm thinking on a wrong level here, but I think it would certainly
help to have some PAST support here.
Just another thought :-)
kjs
[perl #50212] Configure step fails on Windows
On Fri Jan 25 15:10:50 2008, ajr wrote: Hi, Alan! What kind of CPU do you have? If you have an AMD Athlon XP (or something of similar lineage), I think I know what the problem is. I think you've nailed it: Athlon XP-M. Hi, I have built and sent an updated libgmp.a to the Strawberry Perl maintainer (Adam Kennedy). GMP lets you specify (via the --enable-fat ./configure option) that it should build for all possible processor types, and choose the right set of functions at runtime. But it sounds like this didn't actually work in versions older than 4.2.2, or maybe they just didn't build it this way last time. You should see the updated library in the next release of Strawberry Perl. If that doesn't happen in a timely fashion, ask me for a copy of the updated library, and I'll forward you what I sent Adam. Whatever happened, GMP is now detected successfully and parrot configures for me without incident. (And it wasn't Parrot's fault to begin with.) So I am marking this ticket as resolved.
[perl #50380] [TODO]: override Test::Harness summary method to provide better-looking test result summary
# New Ticket Created by Jerry Gay # Please include the string: [perl #50380] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=50380 test::harness 3 is wonderful, except where it's rough around the edges. in particular, the test summary report is much noisier than that of it's predecessor. it'd be great if the test names were visually separated from the summary info, so they could be easily selected from the console in order to fix the tests. you may be on a platform that supports color in consoles, where this isn't so much of an issue, but i'm not. where we now have a report like: Test Summary Report --- t\spec\S02-literals\radix.rakudo(Wstat: 256 Tests: 86 Failed: 6) Failed tests: 47-48, 76-79 Non-zero exit status: 1 t\spec\S03-operators\autoincrement.t (Wstat: 0 Tests: 42 Failed: 12) Failed tests: 31-42 t\spec\S04-statements\while.rakudo (Wstat: 256 Tests: 10 Failed: 0) Non-zero exit status: 1 t\spec\S29-array\kv.rakudo (Wstat: 256 Tests: 9 Failed: 0) Non-zero exit status: 1 t\spec\S29-array\pairs.rakudo (Wstat: 256 Tests: 10 Failed: 0) Non-zero exit status: 1 t\spec\S29-array\pop.rakudo (Wstat: 256 Tests: 1 Failed: 0) Non-zero exit status: 1 Parse errors: Bad plan. You planned 27 tests but ran 1. t\spec\S29-array\push.rakudo(Wstat: 256 Tests: 1 Failed: 0) Non-zero exit status: 1 Parse errors: Bad plan. You planned 42 tests but ran 1. i want to see something more like: Test Summary Report --- t\spec\S02-literals\radix.rakudo(Wstat: 256 Tests: 86 Failed: 6) Failed tests: 47-48, 76-79 Non-zero exit status: 1 t\spec\S03-operators\autoincrement.t (Wstat: 0 Tests: 42 Failed: 12) Failed tests: 31-42 t\spec\S04-statements\while.rakudo (Wstat: 256 Tests: 10 Failed: 0) Non-zero exit status: 1 t\spec\S29-array\kv.rakudo (Wstat: 256 Tests: 9 Failed: 0) Non-zero exit status: 1 t\spec\S29-array\pairs.rakudo (Wstat: 256 Tests: 10 Failed: 0) Non-zero exit status: 1 t\spec\S29-array\pop.rakudo (Wstat: 256 Tests: 1 Failed: 0) Non-zero exit status: 1 Parse errors: Bad plan. You planned 27 tests but ran 1. t\spec\S29-array\push.rakudo(Wstat: 256 Tests: 1 Failed: 0) Non-zero exit status: 1 Parse errors: Bad plan. You planned 42 tests but ran 1. chromatic has even given us a hint on how to do it. see http://www.oreillynet.com/onlamp/blog/2007/03/cpan_module_review_tapparser.html ~jerry
Re: [perl #50056] [BUG] Undefined symbols on OS X
James Keenan via RT wrote: Note the spewing during auto::readline; never had that before. Note further that this failed to detect that I have readline installed via Fink. Whazzup with that? The spewing in auto::readline is caused by it failing to detect readline from Fink. In the generated Makefile, both LINKFLAGS and LDFLAGS should include the entry -L/sw/lib and CFLAGS should include the entry -I/sw/include. Do they? Allison
[perl #50380] [TODO]: override Test::Harness summary method to provide better-looking test result summary
particle: I was wondering why my reports started looking different lately! It's interesting that what you typed below was represented one way in my webmail and news readers (Failed tests indented many spaces to vertically align with (Wstat) and a different way on RT (everything flush left on the margin). I guess this is more of the roughness around the edges. i want to see something more like: Test Summary Report --- t\spec\S02-literals\radix.rakudo(Wstat: 256 Tests: 86 Failed: 6) Failed tests: 47-48, 76-79 Non-zero exit status: 1 I had been meaning to initiate a discussion as to when we would begin to incorporate TAP::Parser into our testing. chromatic's tutorial is nearly a year old, so I wonder whether it represents the 3.0+ release version. I've been wary about moving too quickly, because I see that they're continuing to add new features even after the 3.0 release. It may be stable in a logical sense, but I sense that the perl-qa community 's views on how it should be evolving are anything but stable. In any event, one particular area of concern is the code that t/harness uses to build the .html smoke report. It's built on Test::TAP::*, which is build on Test::Harness::Straps -- which I know to be superseded by TAP::Parser. I have been meaning to find out how Test::TAP::* is evolving ... but I dread posting on perl-qa, opening up a big discussion and not having my original concerns addressed (... which was my last experience on that list). kid51
[perl #50056] [BUG] Undefined symbols on OS X
On Tue Jan 29 16:40:22 2008, [EMAIL PROTECTED] wrote:
The spewing in auto::readline is caused by it failing to detect readline
from Fink.
In the generated Makefile, both LINKFLAGS and LDFLAGS should include the
entry -L/sw/lib and CFLAGS should include the entry -I/sw/include.
Do they?
Allison
A good diagnostic question. They do not:
LINKFLAGS = -undefined dynamic_lookup -L/sw/lib -L/sw/lib
LD = /usr/bin/g++-3.3
LDFLAGS= -L/usr/local/lib -L/Users/jimk/work/parrot/blib/lib
-L/sw/lib -L/sw/lib
-L/sw/lib is duplicated on those lines with -I/sw/include is missing
from each.
This may be a problem with the code I wrote/adapted concerning Fink.
Here's some data from Parrot::Configure::Trace. First, here is how
'linkflags' is evolving around the crucial configuration steps:
{
'auto::aio' = '-undefined dynamic_lookup'
},
{
'auto::gmp' = '-undefined dynamic_lookup -L/sw/lib'
},
{
'auto::readline' = '-undefined dynamic_lookup -L/sw/lib'
},
{
'auto::gdbm' = '-undefined dynamic_lookup -L/sw/lib -L/sw/lib'
},
And here's how 'ldflags' is evolving around the same steps:
{
'auto::aio' = ' -L/usr/local/lib -L/Users/jimk/work/parrot/blib/lib'
},
{
'auto::gmp' = ' -L/usr/local/lib -L/Users/jimk/work/parrot/blib/lib
-L/sw/lib'
},
{
'auto::readline' = ' -L/usr/local/lib
-L/Users/jimk/work/parrot/blib/lib -L/sw/lib'
},
{
'auto::gdbm' = ' -L/usr/local/lib
-L/Users/jimk/work/parrot/blib/lib -L/sw/lib -L/sw/lib'
},
[perl #50056] [BUG] Undefined symbols on OS X
I see that I misread your post; 'ldflags' should have included
-L/sw/lib, and it does. Here's the evolution of 'ccflags' in the same
region:
{
'auto::aio' = '-fno-common -no-cpp-precomp -pipe
-I/usr/local/include -pipe -fno-common -Wno-long-double
-DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT
-DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN
-DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -falign-functions=16 -W
-Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual
-Wchar-subscripts -Wcomment -Wdisabled-optimization -Wformat-nonliteral
-Wformat-security -Wformat-y2k -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Wimport -Winline
-Winvalid-pch -Wmain -Wmissing-braces -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wno-endif-labels -Wno-shadow
-Wno-unused -Wnonnull -Wpacked -Wparentheses -Wpointer-arith
-Wreturn-type -Wsequence-point -Wsign-compare -Wstrict-aliasing -Wswitch
-Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wwrite-strings'
},
{
'auto::gmp' = '-fno-common -no-cpp-precomp -pipe
-I/usr/local/include -pipe -fno-common -Wno-long-double
-DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT
-DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN
-DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -falign-functions=16 -W
-Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual
-Wchar-subscripts -Wcomment -Wdisabled-optimization -Wformat-nonliteral
-Wformat-security -Wformat-y2k -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Wimport -Winline
-Winvalid-pch -Wmain -Wmissing-braces -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wno-endif-labels -Wno-shadow
-Wno-unused -Wnonnull -Wpacked -Wparentheses -Wpointer-arith
-Wreturn-type -Wsequence-point -Wsign-compare -Wstrict-aliasing -Wswitch
-Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wwrite-strings
-I/sw/include'
},
{
'auto::readline' = '-fno-common -no-cpp-precomp -pipe
-I/usr/local/include -pipe -fno-common -Wno-long-double
-DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT
-DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN
-DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -falign-functions=16 -W
-Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual
-Wchar-subscripts -Wcomment -Wdisabled-optimization -Wformat-nonliteral
-Wformat-security -Wformat-y2k -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Wimport -Winline
-Winvalid-pch -Wmain -Wmissing-braces -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wno-endif-labels -Wno-shadow
-Wno-unused -Wnonnull -Wpacked -Wparentheses -Wpointer-arith
-Wreturn-type -Wsequence-point -Wsign-compare -Wstrict-aliasing -Wswitch
-Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wwrite-strings
-I/sw/include'
},
{
'auto::gdbm' = '-fno-common -no-cpp-precomp -pipe
-I/usr/local/include -pipe -fno-common -Wno-long-double
-DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT
-DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN
-DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -falign-functions=16 -W
-Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual
-Wchar-subscripts -Wcomment -Wdisabled-optimization -Wformat-nonliteral
-Wformat-security -Wformat-y2k -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Wimport -Winline
-Winvalid-pch -Wmain -Wmissing-braces -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wno-endif-labels -Wno-shadow
-Wno-unused -Wnonnull -Wpacked -Wparentheses -Wpointer-arith
-Wreturn-type -Wsequence-point -Wsign-compare -Wstrict-aliasing -Wswitch
-Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wwrite-strings
-I/sw/include -I/sw/include'
},
Now, an obvious error is the doubling of the attribute at auto::gdbm for
each of the 3 flags. I have an idea of how that happened.
from lib/Parrot/Configure/Step/Methods.pm:
sub _handle_darwin_for_fink {
my ($self, $conf, $osname, $file) = @_;
if ( $osname =~ /darwin/ ) {
my $fink_lib_dir= $conf-data-get('fink_lib_dir');
my $fink_include_dir= $conf-data-get('fink_include_dir');
if ( (defined $fink_lib_dir) (defined $fink_include_dir) ) {
if ( -f $fink_include_dir/$file ) {
$conf-data-add( ' ', linkflags = -L$fink_lib_dir );
$conf-data-add( ' ', ldflags = -L$fink_lib_dir );
$conf-data-add( ' ', ccflags = -I$fink_include_dir );
}
}
}
return 1;
}
However, the spewing problem occured at auto::readline -- one step
*before* the first superfluous addition of a flag.
[perl #50056] [BUG] Undefined symbols on OS X
I just sent off a patch for the duplicate flags problem; it will appear in a separate RT and I'll commit it to trunk in a day if there is no objection. However, it did *not* fix the spewing problem with auto::readline. Here's my latest configuration log. This was run with both Allison's patch to config/init/hints/darwin.pm and my anti-duplication patch to lib/Parrot/Configure/Step/Methods.pm. 'make' completed successfully but slowed my iBook *drastically* at src/ops/core_ops_cg.c src/ops/debug.ops: In function `cg_core': src/ops/debug.ops:103: warning: null argument where non-null required (arg 2) src/ops/debug.ops:113: warning: null argument where non-null required (arg 2) src/ops/core_ops_cgp.c src/ops/debug.ops: In function `cgp_core': src/ops/debug.ops:103: warning: null argument where non-null required (arg 2) src/ops/debug.ops:113: warning: null argument where non-null required (arg 2) kid51 As you requested, we'll start with some tests of the configuration tools. t/configure/001-optionsok t/configure/002-messages...ok t/configure/003-steplist...ok t/configure/004-configure..ok t/configure/005-run_one_step...ok t/configure/006-bad_step...ok t/configure/007-verbose_twook t/configure/008-verbose_step_numberok t/configure/009-verbose_step_regex.ok t/configure/010-verbose_step_num_uncalled..ok t/configure/011-no_description.ok t/configure/012-verboseok t/configure/013-dieok t/configure/015-no_return..ok t/configure/016-no_return_but_result...ok t/configure/017-revision_from_cacheok t/configure/018-revision_to_cache..ok t/configure/019-versionok t/configure/020-versionok t/configure/021-versionok t/configure/022-versionok t/configure/023-versionok t/configure/024-versionok t/configure/025-options_test...ok t/configure/026-options_test...ok t/configure/027-option_or_data.ok t/configure/028-option_or_data.ok t/configure/029-option_or_data.ok t/configure/030-option_or_data.ok t/configure/031-base...ok t/configure/032-data...ok t/configure/033-step...ok t/configure/034-step...ok t/configure/035-step...ok t/configure/036-config_steps...ok t/configure/037-run_single_stepok t/configure/038-run_single_stepok t/configure/039-run_single_stepok t/configure/040-return_undef...ok t/configure/041-return_undef...ok t/configure/042-list_of_steps..ok t/configure/043-verbose_step_name..ok t/configure/044-slurp_file.ok t/configure/045-generated_file_header..ok t/configure/046-inter..ok t/configure/047-inter..ok t/configure/048-return_result_undefok t/configure/050-fatal..ok t/configure/051-fatal_step.ok t/configure/052-fatal_step.ok t/configure/053-fatal_step.ok t/configure/054-fatal_step.ok t/configure/055-fatal_step.ok t/configure/056-fatal_step.ok t/configure/057-fatal_step.ok t/configure/058-fatal_step.ok t/configure/059-silent.ok t/configure/060-silent.ok t/steps/init_manifest-01...ok t/steps/init_manifest-02...ok t/steps/init_defaults-01...ok t/steps/init_defaults-02...ok t/steps/init_defaults-03...ok t/steps/init_defaults-04...ok t/steps/init_install-01ok t/steps/init_install-02ok t/steps/init_miniparrot-01.ok t/steps/init_hints-01..ok t/steps/init_hints-02..ok t/steps/init_hints-03..ok t/steps/init_hints-04..ok t/steps/init_headers-01ok t/steps/inter_progs-01.ok t/steps/inter_progs-02.ok t/steps/inter_progs-03.ok t/steps/inter_progs-04.ok t/steps/inter_make-01..ok t/steps/inter_make-02..ok t/steps/inter_lex-01...ok t/steps/inter_lex-02...ok
[perl #50390] [BUG]: Parrot::Configure::Step::Methods::_handle_darwin_for_fink adding superfluous flags
# New Ticket Created by James Keenan
# Please include the string: [perl #50390]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=50390
In the course of research on http://rt.perl.org/rt3/Ticket/
Display.html?id=50056 tonight, use of Parrot::Configure::Trace
indicated that auxiliary method _handle_darwin_for_fink was adding
flag '-L/sw/lib' an unnecessary second time to 'linkflags' and
'ldflags' at config step auto::gdbm (on my box, at least) and was
adding '-I/sw/include' an unnecessary second time to 'ccflags'.
The attached patch for lib/Parrot/Configure/Step/Methods.pm corrects
the problem by checking to see whether these flags are already in the
attribute before adding them.
Index: lib/Parrot/Configure/Step/Methods.pm
===
--- lib/Parrot/Configure/Step/Methods.pm(revision 25337)
+++ lib/Parrot/Configure/Step/Methods.pm(working copy)
@@ -65,9 +65,21 @@
my $fink_include_dir= $conf-data-get('fink_include_dir');
if ( (defined $fink_lib_dir) (defined $fink_include_dir) ) {
if ( -f $fink_include_dir/$file ) {
-$conf-data-add( ' ', linkflags = -L$fink_lib_dir );
-$conf-data-add( ' ', ldflags = -L$fink_lib_dir );
-$conf-data-add( ' ', ccflags = -I$fink_include_dir );
+#$conf-data-add( ' ', linkflags = -L$fink_lib_dir );
+#$conf-data-add( ' ', ldflags = -L$fink_lib_dir );
+#$conf-data-add( ' ', ccflags = -I$fink_include_dir );
+my %intended = (
+linkflags = -L$fink_lib_dir,
+ldflags = -L$fink_lib_dir,
+ccflags = -I$fink_include_dir,
+);
+foreach my $flag (keys %intended) {
+my $flagstr = $conf-data-get($flag);
+my @elements = split /\s+/, $flagstr;
+my %seen = map {$_, 1} @elements;
+$conf-data-add( ' ', $flag = $intended{$flag} )
+unless $seen{$intended{$flag}};
+}
}
}
}
Re: [perl #50390] [BUG]: Parrot::Configure::Step::Methods::_handle_darwin_for_fink adding superfluous flags
On Jan 29, 2008 9:08 PM, via RT James Keenan
[EMAIL PROTECTED] wrote:
# New Ticket Created by James Keenan
# Please include the string: [perl #50390]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=50390
In the course of research on http://rt.perl.org/rt3/Ticket/
Display.html?id=50056 tonight, use of Parrot::Configure::Trace
indicated that auxiliary method _handle_darwin_for_fink was adding
flag '-L/sw/lib' an unnecessary second time to 'linkflags' and
'ldflags' at config step auto::gdbm (on my box, at least) and was
adding '-I/sw/include' an unnecessary second time to 'ccflags'.
The attached patch for lib/Parrot/Configure/Step/Methods.pm corrects
the problem by checking to see whether these flags are already in the
attribute before adding them.
Index: lib/Parrot/Configure/Step/Methods.pm
===
--- lib/Parrot/Configure/Step/Methods.pm(revision 25337)
+++ lib/Parrot/Configure/Step/Methods.pm(working copy)
@@ -65,9 +65,21 @@
my $fink_include_dir= $conf-data-get('fink_include_dir');
if ( (defined $fink_lib_dir) (defined $fink_include_dir) ) {
if ( -f $fink_include_dir/$file ) {
-$conf-data-add( ' ', linkflags = -L$fink_lib_dir );
-$conf-data-add( ' ', ldflags = -L$fink_lib_dir );
-$conf-data-add( ' ', ccflags = -I$fink_include_dir );
+#$conf-data-add( ' ', linkflags = -L$fink_lib_dir );
+#$conf-data-add( ' ', ldflags = -L$fink_lib_dir );
+#$conf-data-add( ' ', ccflags = -I$fink_include_dir );
+my %intended = (
+linkflags = -L$fink_lib_dir,
+ldflags = -L$fink_lib_dir,
+ccflags = -I$fink_include_dir,
+);
+foreach my $flag (keys %intended) {
+my $flagstr = $conf-data-get($flag);
+my @elements = split /\s+/, $flagstr;
+my %seen = map {$_, 1} @elements;
+$conf-data-add( ' ', $flag = $intended{$flag} )
+unless $seen{$intended{$flag}};
+}
}
}
}
Would it make sense to make this the default behavior to
$conf-data-add, or perhaps add another add* variant?
--
Will Coke Coleda
[perl #50390] [BUG]: Parrot::Configure::Step::Methods::_handle_darwin_for_fink adding superfluous flags
On Tue Jan 29 18:14:48 2008, coke wrote: Would it make sense to make this the default behavior to $conf-data-add, or perhaps add another add* variant? The same thought occurred to me while I was eating my broccoli! Great minds ... However ... (a) To do it right, someone would have to survey all current uses of $conf-data-add to assess the impact of a change; and (b) That someone is not going to be me, as (i) I already have enough Parrot projects on my plate, and (ii) I am being mandated to take vacation days over the next two weeks. Implication: We need more cage-cleaners.
Re: [perl #50056] [BUG] Undefined symbols on OS X
James Keenan via RT wrote: [...] However, the spewing problem occured at auto::readline -- one step *before* the first superfluous addition of a flag. Okay, so (summarizing) at the point of running auto::readline, -L/sw/lib and -I/sw/include are all set appropriately. Does C_LIBS have -lreadline included? Allison
