On Tue Jan 22 14:02:30 2008, ajr wrote:
>
> Any suggestions for further floundering would be welcome.
>
Well, here's one thought. You could try running Configure.pl with the
addition of the --configure_trace option. Read the POD for
Parrot::Configure::Trace to see how you would then be able t
On Tue Jan 22 14:02:30 2008, ajr wrote:
>
> Any suggestions for further floundering would be welcome.
>
Well, here's one thought. You could try running Configure.pl with the
addition of the --configure_trace option. Read the POD for
Parrot::Configure::Trace to see how you would then be able t
On Wed Feb 14 09:09:14 2007, coke wrote:
> Trying to build with GMP support on OSX intel. I have libgmp in
> /opt/local/bin/
>
> if I run:
>
> CC="ccache gcc-4.0"
> CX="ccache g++-4.0"
> perl Configure.pl --cc="$CC" --cxx="$CX" --link="$CX" --ld="$CX"
> --ccflags="-L/opt/local/lib -I/opt/local/i
On Thu Jan 24 12:52:34 2008, ajr wrote:
> Using the "Strawberry Perl" installed on Windows XP resulted in the
> following failure output from the Configure step:
>
> Determining if your platform supports GMP...Can't spawn ".\test.exe": Bad
> file descriptor at lib/Parrot/Configure/Utils.pm line 85
Some data questions:
1. Are you working from a checkout from the repository or from a Parrot
monthly release tarball?
2. If the former, which VCS did you use to make the checkout? (By
implication, which VCS do you expect to be exercised in _analyze_sandbox()?)
I ask because if you are working
On Thu Jan 24 17:43:06 2008, doughera wrote:
>
> This sounds like a problem in the hints file. I don't know what platform
> this is, but I'd look in the hints file to see if it unconditionally
> sets ccflags and ldflags without checking the command line options.
>
It's Darwin, whose hints file
On Thu Jan 24 17:38:33 2008, [EMAIL PROTECTED] wrote:
>
> Yeah, I get that on Strawberry Perl too. It surprised me, and it
> pauses the configure process until you click "Don't send report".
>
>
> > Might there be some obscure connection with
> > [perl #41508] [BUG] Configure losing flags... ?
On Thu Jan 24 10:31:46 2008, coke wrote:
>
> I think this helps verify my original claim, but how to address it?
>
What would happen if in config/auto/gmp.pm we had some code similar to
that found in config/auto/readline.pm?
sub _init {
my $self = shift;
my %data;
$data{descriptio
I committed a fix for this in r25229: a simple substitution of 'gmtime'
for 'localtime'. See attached.
It will not, however, be visible on the web page until the webmasters
install the revised version of smokeserv-server.pl.
kid51
Index: tools/util/smokeserv-server.pl
=
At this point in our work, it is expected that 'make' will generate
warnings. Consider them data for further research. So there's no cause
for panic here.
But I'm unclear: Did 'make' complete successfully? I.e., did you end
up with a './parrot' executable in your top-level sandbox?
kid51
I will try to look at this over the weekend.
Patch applied to trunk in r25298.
On Sun Jan 27 09:36:26 2008, [EMAIL PROTECTED] wrote:
> Hi.
>
> The test for the backtrace() function was failing
Could you post the failing test result?
In particular, the output of 'prove -v t/steps/auto_backtrace*.t' would
be helpful.
I haven't seen any failures in these tests lately, so I
I began by running configuration with tests. Specifically:
#!/bin/sh
CC="/usr/bin/gcc-3.3"
CX="/usr/bin/g++-3.3"
/usr/local/bin/perl Configure.pl --cc="$CC" --cxx="$CX" --link="$CX" \
--ld="$CX" --without-icu --without-gmp \
--test \
--configure_trace \
$@
... which is the way I
Thanks for taking the time to work on this patch.
Since the config/auto/backtrace.pm has not generated any configuration
or build failures for me on either Linux or Darwin, the most I would be
able to say is whether it does me any harm on either of those systems.
It did no harm on Linux, where it
On Sun Jan 27 17:14:11 2008, tiro wrote:
>
> Could you try setting MACOSX_DEPLOYMENT_TARGET to 10.4 to see if that
> fixes the problem?
>
How/where do I do that?
On Sun Jan 27 17:14:11 2008, tiro wrote:
>
> Could you try setting MACOSX_DEPLOYMENT_TARGET to 10.4 to see if that
> fixes the problem?
>
Okay, I figured out how to do that ... but no better results.
[parrot] 566 $ MACOSX_DEPLOYMENT_TARGET=10.4
[parrot] 567 $ echo $MACOSX_DEPLOYMENT_TARGET
10.4
On Mon Jan 28 00:30:51 2008, [EMAIL PROTECTED] wrote:
> James Keenan via RT wrote:
> >>
> > Okay, I figured out how to do that ... but no better results.
> >
> > [parrot] 566 $ MACOSX_DEPLOYMENT_TARGET=10.4
> [...]
> >
> > Setting the environmental
Patch applied to trunk in r25320.
Here's the verbose output on the failing configuration step, inter::progs.
First, with my usual settings:
Determining what C compiler and linker to use...
ccflags: -fno-common -no-cpp-precomp -pipe -I/usr/local/include -pipe
-fno-common -Wno-long-double
/usr/bin/gcc-3.3 -fno-common -no-cpp-pre
Nope.
[parrot] 521 $ ./myconfigure.sh
MACOSX_DEPLOYMENT TARGET is 10.3
Parrot Version 0.5.2 Configure 2.0
Copyright (C) 2001-2008, The Perl Foundation.
Hello, I'm Configure. My job is to poke and prod your system to figure out
how to build Parrot. The process is completely automated, unless you
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
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".
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_DEPRE
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 t
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 ha
On Tue Jan 29 19:42:15 2008, [EMAIL PROTECTED] wrote:
>
> Does C_LIBS have -lreadline included?
>
> Allison
>
Here's how 'libs' evolves over the course of configuration on my ibook.
Tracing evolution of libs ...
init::manifest =>
init::defaults => -lgdbm -ldbm -ldl -lm -lc
init::install =
On Tue Jan 29 19:42:15 2008, [EMAIL PROTECTED] wrote:
>
> Does C_LIBS have -lreadline included?
>
No, it does not.
C_LIBS = -lm -lgmp
Which is not surprising. If you recall, the result set by
auto::readline in the spewing case was 'no'. So with your patch
readline is not being found.
(B
On Wed Jan 30 07:26:13 2008, cognominal wrote:
> Doing a perl Configure.pl after a make realclean, I get :
>
> Recording configuration data for later retrieval...value for
> 'revision' in config/gen/config_pm/myconfig.in is undef at
> lib/Parrot/Configure/Compiler.pm line 392, <$in> line 1.
>
Ca
Or, better still:
make realclean
svk update
perl Configure.pl --verbose-step=61 --test
On Wed Jan 30 11:48:41 2008, doughera wrote:
>
> I haven't figured out what's creating the other things yet. One
> directory appears to contain a complete copy of MANIFEST.
> Other directories contain lib/Parrot/Config.pm, lib/Parrot/Revision.pm,
> and DEVELOPING. Still other directories are e
More C function documentation (src/runops_cores.c, src/embed.c)
contributed by Alan Rocker committed in r25372.
No one commented unfavorably on this patch, so I suspect that the only
way we're really going to find out if it's okay is to apply it to trunk
and see if it breaks any smokes. Applied in r25376.
I have identified a relatively few instances in the tests I have written
where I used tempfile() without UNLINK =>1 or tempdir() without CLEANUP
=> 1. I have fixed those situations. I have then done make realclean,
perl Configure.pl --test and checked to see whether any files were
created under /
Resolved. Patch applied in r23581.
On Wed Jan 30 18:36:27 2008, [EMAIL PROTECTED] wrote:
>
> Try manually adding -lreadline to the test compile in auto::readline and
> see what happens.
>
This is what I did:
Index: config/auto/readline.pm
===
--- config/auto/readl
Since this does not appear to be causing any problems for smoke tests,
I'm resolving this ticket.
Robert has implemented this change on the smokeserver, which is now
displaying smoke report times in UTC as the home page has always claimed
to do. Resolving ticket.
The patch attach provides the refactoring of t/harness proposed in the
OP. Please review. I'll apply in 3 days or so if no one objects.
Thank you very much.
kid51
(svn merge did not give me the intended results. Only the files that
were altered went into the patch; the newly added files did no
Patches applied to trunk in r25705.
Well, 9 hours later, I did make test and everything was passing. So I'm
closing the ticket.
No complaints received. No evidence of any problems showing up during
smoke testing. So I'm closing the ticket.
Binary searching. Fails in r25613, Feb 10, so problem started before then.
Failure began at or before r25454, Feb 03.
Failure began at or before r24867, Jan 15.
I got a pass at r24387 on Jan 01. So we're looking at something between
24388 and 24867.
I got a pass at r24673 on Jan 08. So we're looking at something between
24388 and 24867.
On Sat Feb 16 16:34:33 2008, [EMAIL PROTECTED] wrote:
> I got a pass at r24673 on Jan 08. So we're looking at something between
> 24388 and 24867.
Correction: We're looking between 24674 and 24867.
I got a pass at r24770 on Jan 12. So we're looking at something between
24771 and 24867.
After a whole day of binary searches, I've identified the problem as
occurring in a revision of src/list.c in revision 24840 (attached).
I am currently testing to see whether simply reverting this change is
sufficient to get t/src/intlist.t passing again on Darwin without
breaking it on Linux (the
On Sat Feb 16 20:23:16 2008, [EMAIL PROTECTED] wrote:
> After a whole day of binary searches, I've identified the problem as
> occurring in a revision of src/list.c in revision 24840 (attached).
>
> I am currently testing to see whether simply reverting this change is
> sufficient to get t/src/int
On Sat Feb 16 20:46:51 2008, [EMAIL PROTECTED] wrote:
>
> Does this patch fix it?
>
> -- c
>
Yes. c++, errr, chromatic++.
Patch applied to trunk in r25793. t/compilers/imcc/syn/macro.t now
passes on Darwin. 'make coretest' passes completely on Darwin. 'make
test' passes on Linux.
Thank y
On Thu Aug 09 20:20:09 2007, [EMAIL PROTECTED] wrote:
>
> I'm looking to close this ticket if we can... is anyone
> still seeing a failure in the shootout/regexdna.pir test
> in the latest svn HEAD ? If so, what OS and architecture?
>
> I'm particularly interested in hearing from people who hav
On Wed Feb 20 17:33:28 2008, coke wrote:
>
> Another thing to consider is we've upped our minimum perl version
> since this ticket was
> opened. Here's a quick summary of modules we should be able to rip
> right out (based a naive
> search of all .pm files in the lib/ dir:)
>
> Class::Struct was
On Wed Feb 20 18:17:12 2008, [EMAIL PROTECTED] wrote:
> >
> > Class::Struct was first released with perl 5.004
...
> > Text::Balanced was first released with perl 5.007003
> >
>
These two packages will be removed in the next few days, as both are
core with Perl 5.8 and their deletion from the
On Wed Feb 20 19:53:30 2008, [EMAIL PROTECTED] wrote:
> On Wed Feb 20 18:17:12 2008, [EMAIL PROTECTED] wrote:
>
> > >
> > > Class::Struct was first released with perl 5.004
> ...
> > > Text::Balanced was first released with perl 5.007003
> > >
> >
>
Both removed from distribution in r25974.
Coke:
Last weekend I applied a patch in r25788 which corrected persistent
problems in src/list.c and thereby enabled t/src/intlist.t to pass for
the first time in a month.
In this RT, you report that t/src/intlist.t is again failing -- this
time failing all its tests.
Was t/src/intlist.t passing
Alas! It is once again failing as of r25999.
t/compilers/imcc/syn/macro...21/33
# Failed test (t/compilers/imcc/syn/macro.t at line 298)
# ''
# doesn't match '/End of file reached/
# '
# './parrot -D40 --gc-debug
"/Users/jimk/work/parrot/t/compilers/imcc/sy
On Fri Feb 22 19:38:42 2008, [EMAIL PROTECTED] wrote:
> On Friday 22 February 2008 19:33:12 James Keenan via RT wrote:
>
> > Alas! It is once again failing as of r25999.
>
> Did it work at r25997? I think Andy keeps reverting the fix.
>
I should have spoken more precis
>
> The test passed at 25900.
>
and it passed at 25950. I'll have to pick up on this tomorrow.
> >
> > Test::Builder was first released with perl 5.006002
> > Test::More was first released with perl 5.006002
> > Test::Simple was first released with perl 5.006002
AFAICT, the versions of these three modules found in lib/Test/ are all
0.60. Presumably, that version was included because it h
On Fri Feb 22 20:18:03 2008, [EMAIL PROTECTED] wrote:
>
> >
> > The test passed at 25900.
> >
>
> and it passed at 25950. I'll have to pick up on this tomorrow.
And it passed at 25973.
The vampire has lain cold for a week. I'm resolving the ticket. Any
new instances of failure in t/examples/shootout.t should open a new
ticket (albeit one which should refer back to this one).
kid51
A patch has been posted to a related ticket that addresses the issues
raised in this ticket. See
http://rt.perl.org/rt3/Ticket/Attachment/362970/163286/diff.trunk.tcif.txt.
Thank you very much.
kid51
This is the second oldest unresolved ticket in the Parrot RT queue. Let
me ask a naïve question: We have a configuration step called auto::env
whose description reads, "Determining if the C library has C
and C." Assuming this step does what it says, in what ways
are the issues raised in this tic
On Sun Aug 15 13:02:08 2004, coke wrote:
>
Nothing has been done on this ticket in 3-1/2 years. chromatic's
question of two years back remains unanswered. I can't find the phrase
'Run different run cores' inside TODO, Parrot::Test or any other file in
the current distribution.
So is there any
Earlier this month I found one last instance where one of the tests I
had written failed to clean up a temporary file. I am no longer finding
any files in /tmp after configuration.
Andy, Joshua, ptc: Are you still seeing any tempfiles
post-configuration? If not I will close this ticket.
Thank
On Wed Dec 14 02:00:08 2005, [EMAIL PROTECTED] wrote:
> - It should be possible to specify the paths to all utilities via
> environment variables. Similar to how the new probes for lex and yacc
> work.
>
Joshua:
My guess is that you're referring to this code found in both
config/inter/lex.p
On Thu Jul 12 11:58:58 2007, coke wrote:
> This file seems to be obsoleted by t/codingstd/c_indent.t; It also relies
> on the non-standard module C::Scan.
Is there any reason why we can't close this ticket?
kid51
Somewhat apropos the discussion in this old ticket, tonight I noticed
the following code in config/inter/progs.pm:
sub cc_run {
...
my $run_error;
if ( defined( $_[0] ) && length( $_[0] ) ) {
local $" = ' ';
$run_error = _run_command( "$test_exe @_", './test.out', unde
>
> The original request was regarding all the tests, not just config, or
> so I thought; In either case, I'd feel safer if someone checked after
> a full test run before closing the ticket.
>
[li11-226:parrot] 508 $ find /tmp -type f
[li11-226:parrot] 509 $ screen
[deta
Resolving ticket.
On Sun Feb 24 19:44:02 2008, coke wrote:
>
> All tests successful.
> Files=261, Tests=3095, 84 wallclock secs ( 1.27 usr 1.69 sys + 25.98
> cusr 13.99 csys =
> 42.93 CPU)
> Result: PASS
>
> All tests successful.
> Files=42, Tests=1149, 31 wallclock secs ( 0.31 usr 0.22 sys + 21.59
> cusr 2.84
On Mon Feb 25 07:39:41 2008, doughera wrote:
(This is not trivial. The relevant code is mostly in perl.c and
> util.c, along with various Configure tests. There are additional
> vms-specific implementations in vms/vms.c. It's been a long time since I
> looked at any of it. I just remember i
On Mon Feb 25 13:09:04 2008, doughera wrote:
>
> This sounds to me as if it assumes all the tests will be running in
> order
> every time.
For the most part, this is true. However, once we work out the kinks,
this will not be cause for alarm.
We want our tests to simulate the development of
On Mon Feb 25 18:56:44 2008, doughera wrote:
>
> Yes. Exactly. I have been arguing that point for years. Every step
> can involve triggers, or callbacks, which can invoke arbitrary code
> and even change the results of preceeding steps. It is very much
> history-dependent. I think the best di
The patch looks good to me. I applied it on Debian Linux, called 'perl
configure.pl --test --configure_trace' -- the last option creates a
hidden file in the top-level directory which is cleaned up by 'make
realclean', hence providing a real-world test -- then 'make', 'make
test' and 'make realcl
Patch applied tonight in r26082.
On Tue Feb 26 19:02:04 2008, [EMAIL PROTECTED] wrote:
> Patch applied tonight in r26082.
There's a bit of mop-up work needed as pointed out by chromatic on #parrot.
1. Should 'lib/Test' be removed from the:
no_index:
directory:
element in META.yml. I felt it should, because that direct
I've spotted a flaw in the way I revised each of the t/steps/*.t files.
Trying to match an exact (true) return value in the 2nd test is too
strict; will generate a failure if, after successfully completing
configuration, you go back and call 'prove' or 'perl -d' on an
individual test.
Am working
On Wed Feb 27 05:59:58 2008, coke wrote:
>
> I would recommend marking whatever version came with 5.8; If we
> require a module that came with 5.10, we've effectively upped our base
> perl requirement, and I don't think we're quite ready to jump to 5.10
> yet.
>
> Is the version that came with 5
On Wed Feb 27 10:07:44 2008, pmichaud wrote:
>
> Since this is the first time in a while that META.yml
> has changed, I think we should attach this ticket or a new
> one to #51054 ("Parrot 0.6.0 release").
Dependency and comment added to that ticket.
On Wed Feb 27 09:57:55 2008, [EMAIL PROTECTED] wrote:
>
> Are you depending on having Test::Harness 3?
Not at this point for the tests covered by 'make test'.
On Fri Feb 29 15:31:39 2008, [EMAIL PROTECTED] wrote:
>
> This problem is fixed by the patch I've attached to ticket #51280.
Applied that patch to my sandbox. It fixed the problem with error.t but
not the one with macro.t:
[li11-226:parrot] 512 $ prove -v t/compilers/imcc/syn/macro.t
t/compil
Got similar output for continuing failure on macro.t on Darwin:
t/compilers/imcc/syn/macro.
# Failed test 'invalid label syntax (RT\#47978, RT\#51104)'
# at t/compilers/imcc/syn/macro.t line 438.
# 'compilers/imcc/imcc.l:994: failed assertion 'valp->s'
# '
No one objected. I re-tested on Darwin, with satisfactory results.
Applied to trunk in r26140.
Reviewing the RT queue, I see that t/compilers/imcc/syn/macro.t is the
subject of an earlier ticket, # 50920. So I am going to merge this
ticket into that one.
kid51
On Wed Feb 27 09:40:57 2008, [EMAIL PROTECTED] wrote:
>
> Two possible solutions: Either eliminate those 6 tests entirely, or
> rewrite the tests to make the regexes which need to be matched tolerant
> of the differences between Test::Builder 0.60 and 0.72 in this regard.
>
Like chromatic, I a
Patch applied to trunk in r26145.
On Fri Feb 29 23:20:07 2008, kraai wrote:
> Howdy,
>
> The failure tests in t/perl/Parrot_Test.t fail because the file name
> and line number format used by Test::Builder on my system differs from
> that expected. That is, the test suite expects
>
> # at $0 line $line.
>
> whereas
>
> #
Matt: I applied your patch in r26162. Can you make certain it works
with a pre-0.64 version of Test::Builder (such as we formerly had in the
Parrot distro)?
We'll also have to see if this resolves the problems reported by Barney
in http://rt.perl.org/rt3/Ticket/Display.html?id=51308
kid51
On Sat Mar 01 04:18:38 2008, bernhard wrote:
> Hi,
>
> with r26143 t/perl/Parrot_Test.t is failing for me.
> Somewhat related might be that t/compilers/imcc/syn/errors.t, RT#51280,
> is working for me.
> I'm stumped.
>
>
Can you svn up, re-Configure, and re-make, and then try these tests again
On Sat Mar 01 06:03:06 2008, [EMAIL PROTECTED] wrote:
> Patch applied to trunk in r26145.
I am reopening this ticket because there have been several reports of
continued failures in t/compilers/imcc/syn/errors.t. For example, at
r26173 on Debian Linux, using Perl 5.10 with Test::Builder 0.72, I g
This is the specific test which is failing:
pir_error_output_like( <<'END_PIR', <<'END_EXPECTED', 'SomethingFunny
isnt pmc' );
.sub main :main
.local SomethingFunny my_string
my_string = new String
my_string = 'hello'
say my_string
.end
END_PIR
/^error:imcc:Unknown PMC type 'SomethingFunny
Okay, Barney applied some fixes and, as of r26182,
t/compilers/imcc/syn/errors.t is once again passing all tests.
Since this test file has been up and down so much, I'll leave this
ticket open for a few days to see if any new dust gets kicked up.
kid51
On Mon Feb 25 18:56:44 2008, doughera wrote:
> At the
> moment, it has the same problem as the previous design -- it's failing
> to honor my command line arguments.
I believe I've spotted the problem. In
Parrot::Configure::Parallel::Trace::store_this_step(), the call to
process_options() is thr
On Sun Mar 02 17:00:59 2008, [EMAIL PROTECTED] wrote:
> I believe I've spotted the problem. In
> Parrot::Configure::Parallel::Trace::store_this_step(), the call to
> process_options() is throwing away the command-line options. I'll try
> to fix that.
>
This was fixed in r26183 in the 'tcif' br
On Sun Mar 02 11:46:00 2008, [EMAIL PROTECTED] wrote:
> Determining what C compiler and linker to use...Compilation failed
with 'cc'
I don't have access to an Ubuntu box at the moment, so I can't strictly
replicate your situation. However, I have this gcc on a Debian box:
[li11-226:work] 554 $ /
Over the last week this test is the only one that has been consistently
failing on both Linux and Darwin.
Here's some output from 'make test' on Linux at r26216:
t/compilers/imcc/syn/macro.
# Failed test 'invalid label syntax (RT\#47978, RT\#51104)'
# at t/compilers/imcc/s
rblasch has marked this test as TODO as of r26267. So the file as a
whole is passing (and, at least on Linux, make test is passing), but the
underlying problem is not solved.
901 - 1000 of 1414 matches
Mail list logo
