On Nov 11, 2006, at 5:56 AM, Joshua Hoblitt via RT wrote:
I believe that the attachment containing your make output was
truncated.
Can you try again or just inline the make error(s)?
See below. It should be noted that I upgraded to GMP 4.2.1. before
trying to build Parrot (or, more prec
Joshua Hoblitt wrote:
> I believe that the attachment containing your make output was
truncated.
> Can you try again or just inline the make error(s)?
>
> Thanks,
>
> -J
>
At Jerry Gay's suggestion, I did a 'make clean' and started anew.
Compiling with:
xx.c
cc -I./include -fno-common -no-cpp
On Dec 30, 2006, at 1:06 AM, Kevin Tew via RT wrote:
I modified the root.in changes to follow the conventions already
present
in the file.
The following composite patch builds and passes parrot tests.
However the pmc2cutil tests are not passing. Could you post a new
diff
that includes pa
On Dec 30, 2006, at 2:56 PM, chromatic via RT wrote:
Here's what I get on an x86 Linux machine:
/usr/bin/perl t/harness t/tools/pmc2cutils/00-qualify.t
[snip]
t/tools/pmc2cutils/01-pmc2cutils.
# Failed test (t/tools/pmc2cutils/01-pmc2cutils.t at line 48)
# Parrot::Pmc2c::Utils->c
On Dec 30, 2006, at 12:31 PM, Will Coleda via RT wrote:
Perhaps a helpful failure message when run at the wrong time would
help.
In a patch to t/tools/pmc2cutils/00-qualify.t which I just submitted,
I have included such an explanatory message which will print out if
you run it with 'p
README
Description: Binary data
MANIFEST.patch
Description: Binary data
Following a suggestion made earlier today by Coke, I am submitting
this file for t/tools/pmc2utils/.
kid51
On Dec 30, 2006, at 1:06 AM, Kevin Tew via RT wrote:
I modified the root.in changes to follow the conventions already
present
in the file.
Kevin, I had hoped that creating a 'make' target in config/gen/
makefiles/root.in would provide a convenient way to run my tests of
Parrot::Pmc2c::
On Dec 30, 2006, at 12:31 PM, Will Coleda via RT wrote:
Perhaps a helpful failure message when run at the wrong time would
help.
And, inspired by your t/perl/README, I have submitted one for t/tools/
pmc2cutils/.
kid51
On Jan 7, 2007, at 8:44 AM, Steve Peters via RT wrote:
What is your c++ symlink pointing at?
[parrot] 512 $ ls -l /usr/bin/c++
lrwxr-xr-x 1 root wheel 7 Aug 9 2004 /usr/bin/c++ -> g++-3.3
[parrot] 513 $ ls -l /usr/bin/g++-3.3
-r-xr-xr-x 1 root wheel 135816 May 14 2006 /usr/bin/g
On Jan 11, 2007, at 9:21 AM, Steve Peters via RT wrote:
On Sun Jan 07 08:27:28 2007, [EMAIL PROTECTED] wrote:
On Jan 7, 2007, at 8:44 AM, Steve Peters via RT wrote:
What is your c++ symlink pointing at?
[parrot] 512 $ ls -l /usr/bin/c++
lrwxr-xr-x 1 root wheel 7 Aug 9 2004 /usr/b
Following my refactoring of tools/build/pmc2c.pl, particle asked me
to look at phalanxing a couple of the other build tools: ops2pm.pl
and ops2c.pl. Since ops2pm.pl is invoked at the very beginning of
the 'make' process, I decided to focus there. As was the case with
pmc2c.pl, my strate
For the first time in the two months I've been working on Parrot,
'make test' completely succeeded -- and with some TODO tests passing,
to boot!
All tests successful (18 subtests UNEXPECTEDLY SUCCEEDED), 11 tests
and 605 subtests skipped.
Passed TODOStat Wstat TODOs Pas
On Jan 31, 2007, at 4:48 PM, Allison Randal wrote:
People with general experience in dynamic languages are also good:
they pick up PIR quickly.
Which leads to my next questions:
Given a knowledge of a dynamic language (I believe there's one called
Perl 5), what is the trajectory for l
On Feb 6, 2007, at 2:27 PM, Leopold Toetsch via RT wrote:
Am Dienstag, 6. Februar 2007 17:54 schrieb Allison Randal:
This is a failing test Leo added in r16783. It looks to me like
calling:
o = new 'MyClass', $P0
actually should call init_pmc, rather than init, even when $P0 is
null.
On Feb 6, 2007, at 12:07 PM, Allison Randal wrote:
Failing that, a PIR tutorial is a good project for someone to take
on. You interested in working on it?
E ... I'm the one who *needs* the tutorial, not the one to write it.
See attached output of prove -v. I have not encountered these
failures before tonight.
Updated to revision 17318.
[parrot] 526 $ prove -v t/pmc/smop_*.t
t/pmc/smop_attribute1..5
# Failed test (t/pmc/smop_attribute.t at line 26)
# got: 'sh: line 1: ./parrot: No such file or dir
On Mar 4, 2007, at 5:15 PM, Sam Vilain wrote:
James Keenan wrote:
The patch attached is really two patches in one:
1. A resubmission in patch form of my refactoring of tools/build/
ops2c.pl into lib/Parrot/Ops2c/Utils.pm and lib/Parrot/Ops2c/
Auxiliary.pm, along with a test suite in t/tools
Here are some notes which I have made which may prove useful in the
refactoring of Parrot::Distribution. I hope that I have grepped and
acked accurately, but I'm not guaranteeing 100% accuracy.
kid51
NAME
Parrot::Distribution refactoring notes
ANALYSIS OF PACKAGE
* used by:
On Mar 9, 2007, at 10:42 AM, Will Coleda via RT wrote:
On Mon Mar 05 16:57:47 2007, [EMAIL PROTECTED] wrote:
Two months ago, I filed this bug report (excerpt):
I'm still not seeing the effects of the bug you describe, btw. (on
OS X
intel or ppc). It does remind me of issues I had when atte
On Mar 9, 2007, at 10:42 AM, Will Coleda via RT wrote:
Do you still get the bug when you revert the change to Configure.pl?
This morning, I checked out a fresh version from trunk: r17419. I
ran myconfigure.sh, which internally called the HEAD version of
Configure.pl.
#!/bin/sh
I got errors in 5 different tests running 'make test' this morning on
a tree freshly updated from trunk. An excerpt from 'make test'
output is attached.
Set aside the failure in t/perl/Parrot_Distribution.t; that's well
known. Here's the output of 'prove -v' on the other 4 files:
[parro
On Mar 24, 2007, at 11:38 AM, chromatic wrote:
We're probably just working around something weird on your system;
it would be
nice if we could figure out what it is and fix it for you.
Is it possible to get a diff between the two configurations
generated with and
without this patch?
On Mar 24, 2007, at 11:53 PM, chromatic wrote:
On Saturday 24 March 2007 09:06, James Keenan wrote:
< ld='c++', ldflags=' -L/usr/local/lib
-L/Users/jimk/work/fresh/blib/lib -flat_namespace ', ---
ld='/usr/bin/g++-3.3', ldflags=' -L/usr/local
On Mar 25, 2007, at 1:41 PM, Klaas-Jan Stol via RT wrote:
hi, I'm maintaining compilers/pirc. The pirc.in file (from which the
Makefile is generated) does contain:
realclean: clean
$(RM_RF) Makefile
$(RM_RF) pirc$(EXE)
When I type 'make realclean' (in compilers/pirc dir.) it does
de
Toronto Perlmongers are pleased to announce Hackathon Toronto, a one-
day, almost-spur-of-the-moment hackathon, to be held Saturday, April
28, 2007.
A hackathon is a gathering of free and open source software
developers reflecting the joy of collective hacking. Building on the
tradition o
I am trying to determine the purpose of a certain block of code in
Configure.pl. In the most recent version in trunk, we find:
if ( exists $args{step} ) {
$conf->data()->slurp();
$conf->runstep( $args{step} );
print "\n";
exit(0);
} else {
# Run
On Apr 14, 2007, at 7:18 PM, Patrick R. Michaud wrote:
On Sat, Apr 14, 2007 at 06:41:19PM -0400, James Keenan wrote:
I am trying to determine the purpose of a certain block of code in
Configure.pl. In the most recent version in trunk, we find:
...
My questions are:
1. If you've al
In lib/Parrot/Configure.pm there is the following code (trunk:
starting at line 254):
# XXX cc_build uses this verbose setting, why?
$self->data->set( verbose => $verbose ) if $n > 2;
$n is the index in the array of configuration steps of the step
currently being processed. $verbos
In January 2006, the paragraphs marked XXX below were added to docs/
configuration.pod concerning methods to be defined in the package for
each configuration step (e.g., config/init/manifest.pm for step
init::manifest)
=item C # starting at trunk, line 138
Returns a list of the names of an
On May 2, 2007, at 11:37 PM, chromatic via RT wrote:
Everything worked fine for me with Svk, barring some fuzz when
updating
MANIFEST.SKIP and the lack of Svn properties set in the diff. Nice
work.
This was the first time that I used tools/dev/mk_manifest_and_skip.pl
to (re-)genera
Andy Dougherty wrote:
> The following oddity turned up today:
>
> t/postconfigure/02-revision_no_DEVELOPING
> # Failed test (t/postconfigure/02-revision_no_DEVELOPING.t at
line 51)
> # '0'
> # ne
> # '0'
> # Looks like you failed 1 test of 16.
> dubious
>Test ret
Allison Randal wrote:
> This test seems to expect that the current revision and the revision
> where I last ran Configure.pl are always the same. Why?
>
> --
> [EMAIL PROTECTED]:~/projects/svn/parrot$ prove t/postconfigure/03-
revision.t
> t/postconfigure/03-revisionok 4/7# Failed te
On May 8, 2007, at 9:02 PM, Will Coleda wrote:
I had similar failures here where I got '0' vs. some other number.
$ prove -v t/postconfigure/03-revision.t
t/postconfigure/03-revision1..7
ok 1 - use Cwd;
ok 2 - use File::Copy;
ok 3 - use File::Temp;
ok 4 - current revision is all numeric
ok
On May 8, 2007, at 9:02 PM, Will Coleda wrote:
I had similar failures here where I got '0' vs. some other number.
$ prove -v t/postconfigure/03-revision.t
t/postconfigure/03-revision1..7
ok 1 - use Cwd;
ok 2 - use File::Copy;
ok 3 - use File::Temp;
ok 4 - current revision is all numeric
ok
On May 8, 2007, at 9:21 PM, Will Coleda wrote:
That was after 'make'
Here's two more data points for you:
# realclean
$ prove t/postconfigure/03-revision.t
t/postconfigure/03-revisionok
3/7 skipped: various reasons
All tests successful, 3 subtests skipped.
Files=1, Tests=7, 0 wa
On May 8, 2007, at 9:23 PM, James Keenan wrote:
In r18473, I have just commented-out the offending test in each of
t/postconfigure/02- and 03-, pending further diagnosis.
kid51
Further coverage analysis indicated that the tests were contributing
nothing to higher test coverage. So I
On Jun 2, 2007, at 10:32 AM, Bob Rogers via RT wrote:
This seems like a lot of trouble just to keep dead code in the
codebase.
Is there some reason not to yank the useless methods?
-- Bob
Not that *I* know of. But my knowledge base only ext
Forwarded to list pending return to life of rt.perl.org:
Parrot::Configure::runstep() is the only subroutine in
Parrot::Configure() that is still not covered via the tests in t/
configure/ or t/postconfigure/. No test has yet been written in
part because this is a subroutine which is not
Forwarded to list pending return to life of rt.perl.org:
According to its documentation, the purpose of
Parrot::Configure::Step is to hold "... utility functions for
[configuration] steps to use."
This package, in relation to others in the Parrot::Configure::*
tree, has a relatively lar
On Jun 29, 2007, at 12:28 PM, Bernhard Schmalhofer via RT wrote:
James Keenan via RT schrieb:
There was code in several of the test files in the reconfigure/
branch which was repeated. At
the hackathon, David Adler refactored it into a subroutine which I
then placed in new file
With refactoring committed to trunk in r29144 (2008-07-07), test
coverage for this file is about as high as it can go
(http://thenceforward.net/parrot/coverage/configure-build/config-auto-sizes-pm.html).
Resolving ticket.
kid51
On Mon Jul 07 17:55:34 2008, [EMAIL PROTECTED] wrote:
>
>
> Trying to 'make', though, I've started emitting hundreds of 'warning:
> control reaches end of non-void function' messages. I'm pretty
> confident those are new, but possibly I just never noticed them.
> The few I sampled are where G
Committed to trunk in r29181:
http://www.parrotvm.org/svn/parrot/revision?rev=29181
kid51
Since I closed this ticket in January, more code has been added.
Tonight, while writing unit tests for internal subroutine
_handle_ncurses_need(), I noticed the following lines:
if ( $osname =~ /mswin32/i ) {
if ( $cc =~ /^gcc/i ) {
$conf->data->add( ' ', libs => '-lncuses
With additional unit tests added in r29216-29217, test coverage is now
100% in all major categories. Resolving ticket.
kid51
On Tue Jul 08 20:01:11 2008, [EMAIL PROTECTED] wrote:
> Committed to trunk in r29181:
> http://www.parrotvm.org/svn/parrot/revision?rev=29181
>
> kid51
Revisions appear to be passing smoke tests. Marking ticket resolved.
kid51
On Wed Jul 02 09:17:44 2008, [EMAIL PROTECTED] wrote:
> On Wed Jul 02 06:25:14 2008, particle wrote:
> >
> > therefore, in an attempt to keep bytecode compatible across versions
> > of parrot, opcodes can never be deleted. instead, if opcodes are
> > deprecated, their function bodies should throw
Added some tests to t/steps/auto_opengl-03.t for internal subs
_evaluate_cc_run() and _handle_glut(). No need to do any refactoring of
step class itself. Test coverage is very high, so this ticket is
quickly being resolved.
BTW, japhb++ for instructions as to how to install Debian packages
neede
On Wed Jul 09 18:57:43 2008, [EMAIL PROTECTED] wrote:
> Since I closed this ticket in January, more code has been added.
> Tonight, while writing unit tests for internal subroutine
> _handle_ncurses_need(), I noticed the following lines:
>
> if ( $osname =~ /mswin32/i ) {
> if ( $cc =
On Sat Jul 12 09:33:35 2008, coke wrote:
>
> Another solution here would be to not run them by default. The purpose
> of 'make test'
> should be to verify that the parrot functionality works on the target
> system.
If speed is your concern, you can call 'make coretest'. We've had that
functional
Two of the three directories were left over from earlier development of
testing of configuration steps, so I was familiar with them. The third
had apparently last been used > 20K revisions ago, in the long distant
past of 2005.
3 directories removed. Ticket marked resolved.
kid51
On Mon Jul 14 10:55:35 2008, doughera wrote:
> Some of the new tests for auto::pack fail for me:
>
> $ perl t/harness -v t/steps/auto_pack-01.t > out 2>&1
> t/steps/auto_pack-01# Failed test (t/steps/auto_pack-01.t at
> line 101)
> # Failed test (t/steps/auto_pack-01.t at line 102)
>
On Mon Jul 14 17:14:09 2008, doughera wrote:
> On Mon, 14 Jul 2008, James Keenan via RT wrote:
>
> > 2. Apart from deleting the step, then running 'make' and 'make test',
> > is there any other way to demonstrate that these types are not used?
>
>
On Mon Jul 14 18:44:51 2008, [EMAIL PROTECTED] wrote:
> On Mon Jul 14 17:14:09 2008, doughera wrote:
> > Yes. Look at the Config variables that are set, and then grep for
> them in
> > the source tree. You'll find they are never used.
> >
>
>
> So it would appear. I'll change the Subject
Tested in the 'noautopack' branch. Passed all pre- and
post-configuration tests; built correctly; passed all tests in 'make test'.
If no one objects, I'll apply this patch after tomorrow's release.
Thank you very much.
kid51
Index: lib/Parrot/Configure/Step/List.pm
=
>
> -- Forwarded message --
> From: Reini Urban <[EMAIL PROTECTED]>
> Date: Tue, Jul 15, 2008 at 9:52 AM
> Subject: .parrot_current_rev
> To: [EMAIL PROTECTED]
>
>
> The file .parrot_current_rev is missing in the Release, and also the
> revision is nowhere
> mentioned in any Rel
Applied in r29499. Marking ticket resolved.
Applied in r29499. Marking ticket resolved.
Since I have not heard back from the OP, have not been able to reproduce
the test failure and have not seen it failing on smoke test reports, I
am going to close this ticket.
I think this new subroutine could use some refactoring:
30 sub update {
31 my $prev = _get_revision();
32 my $revision = _analyze_sandbox();
33 if (defined ($prev) && ($revision ne $prev)) {
34 $revision = 'unknown' unless defined $revision;
35
On Wed Jul 16 16:56:20 2008, coke wrote:
> > I suspect that the merger/committer failed either to run 'perl
> > Configure.pl --test' or 'make buildtools_tests' prior to 'make'.
>
> I can't remember the last time I ran these particular test targets, so
> that's easy (for me) to forgive.
>
(Well,
On Wed Jul 16 18:53:05 2008, [EMAIL PROTECTED] wrote:
>
> So if you really think lib/Parrot/Ops2c/Utils.pm could be better
> designed while achieving the same functionality, have a go at it!
But in the short run I would recommend simply reverting to the last
prior version of the module. I sus
On Wed Jul 16 19:25:46 2008, coke wrote:
>
> Attached is a patch which passes all tests by removing the tests for
> the explicit true value of these methods.
>
Coke: I don't think we should accept this patch, for the simple reason
that I think the changes made to lib/Parrot/Ops2c/Utils.pm were b
This module is written in Perl 5 and is called in a program written in
Perl 5. In the work I've done in this project, I've taken the approach
to return values which I think is more Perlish, namely, if a subroutine
completes and does what you wanted it to, it should return a true value.
A bare ret
The breakage was in lib/Parrot/Ops2pm/Utils.pm, not
lib/Parrot/Ops2c/Utils.pm. So I have corrected the Subject of the RT.
kid51
I can see Barney's point that the documentation was not in accordance
with the return statements of several of the subroutines. So I have
changed that accordingly.
It seems from the discussion that most of us can live with an explicit
statement of a true return value (as distinct from an explicit
On Thu Jul 17 03:40:13 2008, [EMAIL PROTECTED] wrote:
>
> For future reference, please note that the POD for
> lib/Parrot/Ops2c/Utils.pm has all along included a NOTE ON TESTING
> section that describes the accompanying test suite and how to use it in
> refactoring the module.
>
Aagh! Same err
Michael:
I install TAP::Harness::Archive from CPAN, then applied the patches to a
fresh checkout from trunk. I configured, built and ran 'make
smolder_test'. The Smolder test completed and stated that it uploaded
-- though I have a tough time matching my particular report to those at
http://smol
On Wed Jul 16 06:27:16 2008, julianalbo wrote:
> On Wed, Jul 16, 2008 at 1:12 PM, James Keenan via RT
[snip]
>
> > If no one gets to this today I will try to work on this this evening.
>
> Go for it.
>
On Wed Jul 16 04:12:35 2008, [EMAIL PROTECTED] wrote:
> [snip]
&g
Here's the attachment.
Index: lib/Parrot/Revision.pm
===
--- lib/Parrot/Revision.pm (.../trunk) (revision 29567)
+++ lib/Parrot/Revision.pm (.../branches/revisionpm) (revision 29574)
@@ -30,36 +30,50 @@
sub update
On Fri Jul 18 09:17:19 2008, [EMAIL PROTECTED] wrote:
>
> I would find this clearer if you reversed the top level conditions. In
> English, this reads:
>
> if the revision isn't defined, then do this
> otherwise do that
>
> Flipping the order changes it to:
>
> if the revisi
And I applied one little grammatical correction.
Since we've applied and refined the patches that Michael Peters
originally submitted, is there any particular reason to keep this RT open?
kid51
Have tested the build tools on two different OSes and they're all
passing. Having heard no further complaints, I'm going to resolve this
ticket.
kid51
r29352 | jkeenan | 2008-07-12 13:00:43 -0400 (Sat, 12 Jul 2008) | 4 lines
Applied 5 days ago. No complaints heard. Closing ticket.
On Fri Jul 18 08:22:48 2008, doughera wrote:
>
> Oh yes -- I did remember one other. Configure.pl currently offers you
the
> opportunity to specify different sizes for opcode_t and INTVAL. However,
> parrot itself assumes they are the same size. (See [perl #56810] for a
> little more backgr
My wish was your command! Applied in r29617. Thank you very much.
kid51
On Sun Jul 13 19:25:11 2008, pmichaud wrote:
> On Sat, Jul 12, 2008 at 11:00:29AM -0700, James Keenan via RT wrote:
>
> Here's a question I have -- what are the various use cases for running
> the various test targets? Perhaps if we enumerate the use cases we
> could unde
On Sat Jul 12 11:00:27 2008, [EMAIL PROTECTED] wrote:
>
> particle's original post was one I requested he make as follow-up to a
> discussion that he, chromatic and I had concerning configuration at
> YAPC::NA::2008 in Chicago (with additional input from Steve Lembark).
> That discussion concerne
On Thu Jun 26 12:46:10 2008, coke wrote:
>
> In that case, Memoize will not help, you're absolutely right. (Might
> be worth seeing if the code is amenable to a refactor that -would- be
> amenable to this, but that's probably more work.)
>
If no one currently has any more ideas on the subject of
1 test still not passing as of r29636:
not ok 36 - invalid label syntax # TODO RT#47978, RT#51104
# Failed (TODO) test 'invalid label syntax'
# at t/compilers/imcc/syn/macro.t line 469.
# 'compilers/imcc/imcc.l:1010: failed assertion 'valp->s'
# Backtrace - Obtained 10 stack
This is the situation on both Linux and Darwin (r29636) today.
$ prove -v t/stm/runtime.t
t/stm/runtime
1..5
ok 1 - choice (one thread)
ok 2 # SKIP Intermittently failing everywhere
ok 3 # SKIP Intermittently failing everywhere
ok 4 - queue adapted for the library
ok 5 - queue (non-blocking; n
Patch applied in r29660 tonight.
As part of my work on this ticket in the 'parallel' branch, I have
finally begun writing some basic tests for the 'gen' configuration
steps: config/gen/*.pm. These steps -- which are the final
configuration steps -- primarily look data up in source files, files
generated earlier in the configurati
I've added references to 7 tickets opened last year focusing on tests
for the 'gen' step classes.
In the course of working on tests for this and other configuration step
classes in the 'parallel' branch in SVN, I had occasion to note that
this is the only one of 60+ config steps which displays certain verbose
output only when '--verbose=2' is called on the command line:
53-print " ($genera
On Sun Jul 20 17:52:49 2008, [EMAIL PROTECTED] wrote:
> On Sunday 20 July 2008 17:37:28 James Keenan via RT wrote:
>
> > If no one currently has any more ideas on the subject of this
> ticket, I
> > will close it.
>
> Running it less frequently -- over all PMCs at once
In the course of working on unit tests in the 'parallel' branch, I came
across this inline comment in config/gen/makefiles.pm:
# Why is this here? I'd think this information belongs
# in the CFLAGS.in file. -- A.D. March 12, 2004
if ( $conf->data->get('cpuarch') =~ /sun4|sparc64/ ) {
I tried this test on an older Mac: OS X 10.4 on Darwin. I did not get
any outright failures because one test is SKIPped and another is
expected to fail and hence is TODOed out.
$ prove -v t/examples/library.t
t/examples/library
1..4
ok 1 - examples/library/getopt_demo.pir
ok 2 - examples/li
Per request from Reini Urban, I have merged RT 57296 into this ticket.
The version of the patch which should be evaluated is that submitted by
Reini on 26 July: make-install-lang.patch.
kid51
On Sat Jul 26 22:27:39 2008, [EMAIL PROTECTED] wrote:
> It appears that this test assumes (multiple times perhaps?) that it may
> make named files in /tmp/.
>
>
Are you saying that making named files in /tmp (or any other temporary
directory) is bad or something to be avoided? If so, what alte
On Mon Jul 28 10:48:21 2008, particle wrote:
> On Mon, Jul 28, 2008 at 10:27 AM, Eric Wilhelm
> <[EMAIL PROTECTED]> wrote:
> >
> > Tests need to be written defensively for arbitrary parallelization to be
> > possible.
The configuration step tests have been evolving for 13 months now, but
until
I have prepared a patch which represents an 'svn diff' between trunk and
the 'parallel' branch at the point of the branch's inception. Rather
than swamp your inboxes, I'm posting it here:
http://thenceforward.net/parrot/diff.trunk.parallel.txt
This patch is more for review than application. Bec
On Tue Jul 29 11:01:12 2008, particle wrote:
>
> the failing test:
> t/steps/auto_ctags-01ok 1/31
> # Failed test 'Got expected result'
> # at t/steps/auto_ctags-01.t line 65.
> t/steps/auto_ctags-01NOK 17/31# got:
> 'yes'
> # expect
On Tue Jul 29 11:04:59 2008, doughera wrote:
> On Tue, 29 Jul 2008, James Keenan via RT wrote:
> The parallel branch does seem to run in about half the time. This is
> with
> perl-5.8.8 on Solaris/SPARC, where perl was built with Sun's cc, but
> I'm
> trying to build p
On Tue Jul 29 11:01:12 2008, particle wrote:
>
> overall, i'm impressed at the 50% speedup. given that these are
> relatively fast tests, it makes sense that since there are half as
> many files (and therefore half as many invocations of perl), the tests
> take half the time to run. other than my
On Tue Jul 29 11:08:30 2008, doughera wrote:
> After running the Configure.pl test suite, I'm seeing some
> annoying-to-remove directories staying behind in /tmp.
>
> $ ls -lR /tmp/qdEG6yqmCn/
> qdEG6yqmCn/:
> total 16
> drwxr-xr-x 3 doughera faculty 181 Jul 29 13:48 alpha/
>
> qdEG6yqmCn
On Wed Jul 30 12:24:35 2008, [EMAIL PROTECTED] wrote:
>
> Thanks, applied as r29881.
>
> -- c
>
Wow, first time in a year that anyone besides me has worked on these
tests :-)
Thanks, guys. Marking ticket resolved.
kid51
Tests contributed as part of r29867. Marking ticket resolved.
kid51
Tests contributed as part of r29867. Marking ticket resolved.
kid51
Tests contributed as part of r29867. Marking ticket resolved.
kid51
1 - 100 of 1454 matches
Mail list logo
