On Sat Nov 11 03:56:22 2006, [EMAIL PROTECTED] wrote:
I believe that the attachment containing your make output was truncated.
Can you try again or just inline the make error(s)?
Thanks,
It should be noted that I upgraded to GMP 4.2.1. before trying to build Parrot
(or, more
precisely,
Next attempt: At Jerry's and Chip's suggestions, we tried a different
configuration:
perl Configure.pl --without-gmp --cc=gcc --ccflags=-DAN
where 'AN' was intended to be a harmless option for --ccflags.
This time, 'make' got a few lines farther; see attachment.
Compiling with:
xx.c
gcc
On Thu Nov 30 18:34:48 2006, [EMAIL PROTECTED] wrote:
Problem confirmed. I am working on it. I think I have misunderstood
how to use
Getopt::Long::GetOptions().
I fixed the problem with GetOptions() -- but there are additional problems that
will take time to
diagnose. So my patches
On Thu Nov 30 19:25:49 2006, [EMAIL PROTECTED] wrote:
On Thu Nov 30 18:34:48 2006, [EMAIL PROTECTED] wrote:
I fixed the problem with GetOptions() -- but there are additional
problems that will take time to
diagnose. So my patches are not yet ready for prime time.
I'm attaching a file,
On Sat Dec 02 20:22:14 2006, [EMAIL PROTECTED] wrote:
Tests of Parrot's build tools are not tests of Parrot itself. Once
Parrot's make call has
succeeded, testing the components of the build tools is irrelevant.
Hence, including tests of
the build tools in the suite of tests called by
On Mon Dec 25 22:14:18 2006, [EMAIL PROTECTED] wrote:
A few style comments here.
[snip]
sub dump_vtable {
my $self = shift;
my $file = shift;
Why two shifts here, when @_ goes unused through the rest of the method?
Fixed in attached patch: Utils.pm.
sub print_tree
Further refinement of new file lib/Parrot/Pmc2c/Utils.pm. Coverage analysis
suggested that
the following line in gen_parent_list() (approx. line 547):
next if exists $class-{has_parent}{$parent};
... was never reached by my tests in the 'true' case (if exists
On Tue Jan 23 14:20:21 2007, particle wrote:
when compiling src/pmc/pmethod.c, cl has a few warnings:
src\pmc\pmethod_test.c
D:/usr\local\parrot\bug\tools\build\../../lib\Parrot\Pmc2c\Utils.pm(1096)
: warn
ing C4102: 'test_method0_returns' : unreferenced label
[snip]
it seems the pmc2c
In each of the 7 affected test files, the initial mention of $topdir in the
BEGIN block was replaced
by 'our $topdir'. These tests now pass when run via 'make buildtools_tests' or
'prove t/tools/
pmc2cutils/*.t' after running 'Configure.pl' but before running 'make'. I also
ran 'make'
Tests have been corrected and now pass again. People are aware of problem.
Closing ticket.
This test continues to fail on Darwin. Here's a result from tonight:
[parrot] 535 $ perl t/harness t/examples/shootout.t
t/examples/shootoutok 8/20
# Failed test (t/examples/shootout.t at line 99)
# got: 'agggtaaa|tttaccct 0
#
Should have included 'myconfig' with the original report. It is now attached.
kid51
myconfig
Description: Binary data
Following discussion with particle on Feb 19 2007, these patches and new files
were committed
to trunk in r17061. Ticket may be closed.
Please substitute the two files attached for the identically named files in my
previous posting in
this thread. These two test files extend the test coverage
(http://thenceforward.net/parrot/
coverage/).
t/tools/ops2cutils/04-print_c_source_top.t
t/tools/ops2cutils/05-print_c_source_bottom.t
This may have been self-induced. Once I did 'make realclean; svn
update;' and re-ran make and make test, the tests in question passed.
Closing ticket.
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:
*
I am pulling this patch from submission for the time being. When I
originally submitted the refactored tools/build/ops2c.pl and
lib/Parrot/Ops2c/Utils.pm over a week ago, they were passing their own
tests as well as those in 'make test'.
However, something outside these patches must have changed
[Same note as in RT 41688]
I am pulling this patch from submission for the time being. When I
originally submitted the refactored tools/build/ops2c.pl and
lib/Parrot/Ops2c/Utils.pm over a week ago, they were passing their own
tests as well as those in 'make test'.
However, something outside
On Wed Aug 16 23:06:53 2006, coke wrote:
Anything referring to TEST_PROG should probably be renamed to
parrot or executable based on context.
For reference ...
I 'acked' and got the instances of TEST_PROG found in the attachment
TEST_PROG.instances.txt.
kid51
On Fri Mar 16 19:42:17 2007, [EMAIL PROTECTED] wrote:
On Wed Aug 16 23:06:53 2006, coke wrote:
Anything referring to TEST_PROG should probably be renamed to
parrot or executable based on context.
For reference ...
I 'acked' and got the instances of TEST_PROG found in the attachment
On Fri Mar 16 19:09:33 2007, [EMAIL PROTECTED] wrote:
Twice in the past two days I have encountered this failure while
running 'make test':
[fresh] 539 $ prove -v t/pmc/metaclass.t
t/pmc/metaclass1..9
On #parrot, Jonathan indicated this test is expected to fail. If there is no
spec
particle discovered an extraneous patch in my submission of last night. I hope
this corrects it.
Index: lib/Parrot/Test/PIR_PGE.pm
===
--- lib/Parrot/Test/PIR_PGE.pm (revision 17522)
+++ lib/Parrot/Test/PIR_PGE.pm (working copy)
On Sun Mar 25 23:00:09 2007, [EMAIL PROTECTED] wrote:
On Mar 25, 2007, at 9:34 PM, James Keenan (via RT) wrote:
1. Configure.pl has a lexical @valid_opts (starting at line 284 for
me). One of the elements of this array is: 'verbose-step=N'.
Shouldn't this really be: 'verbose-step
On Mon Mar 26 00:53:31 2007, kjs wrote:
Klaas-Jan Stol wrote:
James Keenan wrote:
[snip]
Please try the patch attached.
It more closely follows the pattern in config/gen/makefiles/root.in
-- specifically it categorizes your Makefile as a STICKY_FILE.
It does remove the Makefile
Error in the previous report: t/src/io.t failed during 'make test' (both times
I ran it), but
appears to have passed when run with 'prove'. Here's what I saw during 'make
test'.
t/src/io.Failed to delete temp.file at
t/src/io.t line 46.
# Looks like you
I've applied my patch successfully on both Darwin and Linux; kjs indicated on
IRC that he got it
working on Windows. Assuming there is no objection, I will apply it to trunk
on Wed Mar 28.
On Mon Mar 26 21:40:39 2007, guest wrote:
On Mon Mar 26 18:38:00 2007, [EMAIL PROTECTED] wrote:
Error in the previous report: t/src/io.t failed during 'make test'
(both times I ran it), but
Can you clarify: did or did not the iterator test fail? If so, I am
probably the one to look at
Patch applied in r17821.
Applied in r17899.
Closing ticket.
This is weird. I renamed the sandbox directory in which I was experiencing
failures from
'options/' to 'latest/'. All the t/compilers/* tests passed.
And the failing test in t/pmc/sub.t has bee TODO-ed.
Can anyone suggest why the name of one's sandbox directory should affect the
test
No one has spoken up in favor of retaining the 'no-body' option. tewk,
who is doing as much work as anyone in this area, has recommended
getting rid of it.
I will take the ticket. Perl Seminar NY's Phalanx Phoenix project is
recruiting additional hackers to work on this type of code. We'll
I'm closing this ticket because the causes of the failing test files
have been identified in ongoing work by other project members and the
tests are no longer failing (or, at least, consistently failing).
Patch applied in r17983 and 17984.
Patch committed to trunk in r18027.
Applied to trunk in r18033. Thanks, Shawn!
Closing ticket.
On Sun Apr 08 00:07:13 2007, [EMAIL PROTECTED] wrote:
When Parrot processes its command-line arguments, it detects valid and
invalid
flags and reports invalid flags, then exits with an exit code of 1.
I could find no tests for this feature. They would be lovely to have.
A week ago I
t/tools/ops2pmutils/testlib/Capture.pm was deleted in r18040. All tests using
it were modified
to use Parrot::IO::Capture::Mini. 'make buildtools_tests' run; all test
passed. Closing ticket.
On Mon Mar 19 15:43:27 2007, particle wrote:
there's a number of scripts and utilities in the tools/ subtree which
i suspect have gone unused for some time now. this ticket is a
placeholder to track efforts on surveying and fixing the files under
tools/.
~jerry
Here is some
Applied to trunk in r18157
Also, in r18158 applied some small changes in docs/configuration.pod to point
to
Parrot::Configure::Step::List as new location for list of configuration steps
used in Configure.pl.
Patches applied; closing ticket.
Fixed in revision 18292. I carried over to these tests code I used in
t/tools/pmc2cutils/*.t,
where it was more needed.
The patch I applied has been overridden by further patches (r18291-18292)
applied in response
to RT 42618.
The patch I submitted for this ticket has been superseded by the patch
submitted to RT 42777
(http://rt.perl.org/rt3/Ticket/Display.html?id=42777).
This problem was cleared up when lib/Parrot/Ops2pm/Utils.pm was committed to
trunk in
February.
On Tue Apr 10 18:50:18 2007, [EMAIL PROTECTED] wrote:
There are two points in docs/submission.pod where the word 'test' is
used is a way which, IMHO, is confusing.
It probably would have been more productive if I had correctly identified the
file I was
complaining about. The file in
Feedback requested on patch attached.
Index: docs/configuration.pod
===
--- docs/configuration.pod (revision 18348)
+++ docs/configuration.pod (working copy)
@@ -21,11 +21,12 @@
Ffoo.pm uses Fbar_c.in, Fbar_c.in should be
On Mon Apr 16 16:36:56 2007, [EMAIL PROTECTED] wrote:
I ran Makefile.PL on a random windows box which hasn't had its
compiler
installed correctly yet. Rather than emitting an error message about
how it couldn't find my compiler, it apparently passed the test, and
then crashed multiple times
On Mon Apr 09 17:04:49 2007, [EMAIL PROTECTED] wrote:
I haven't yet looked at scripts in other directories such as
tools/dev/.
Here's a bit of information about tools/dev/*.pl: last revision for each script
[parrot] 520 $ svn status -v tools/dev/*.pl | tr -s ' ' | sort -t ' ' +7 -12 |
On Sun Mar 18 09:01:52 2007, ptc wrote:
t/codingstd/perlcritic.t uses a non-standard argument parsing
mechanism. This should be replaced with Getopt::Long.
To demonstrate that this replacement has been done successfully, the patch
submitter should
provide 'before' and 'after' results for
On Fri Apr 27 19:44:35 2007, ptc wrote:
On 28/04/07, James Keenan via RT [EMAIL PROTECTED] wrote:
On Mon Apr 16 16:36:56 2007, [EMAIL PROTECTED] wrote:
I ran Makefile.PL on a random windows box which hasn't had its
compiler
installed correctly yet. Rather than emitting an error
Patch prepared by Alan Rocker at Hackathon Toronto (Apr 28 2007).
Index: tools/build/pmc2c.pl
===
--- tools/build/pmc2c.pl(revision 18351)
+++ tools/build/pmc2c.pl(working copy)
@@ -20,7 +20,6 @@
dump =
Committed to trunk in r18352.
A participant in this weekend's hackathon in Toronto posed this question:
Invoking the compiler on a simple source file, then checking that the
generated code exists seems such an obvious test that there must be a
fatal flaw in it. What am I missing?
In the course of writing tests for Parrot::Revision (see the 'reconfigure'
branch), I noticed that
much of the code depends on the definedness and value of $svn_entries.
However, since
$svn_entries is explicitly undefined at the top of lib/Parrot/Revision.pm, and
since it's never
assigned
On Tue Apr 10 01:45:31 2007, [EMAIL PROTECTED] wrote:
Configure should act as though writing --foo=no is false instead of
true. Tonight I tried using --execcapable=no to get around a compile
failure, but then realized that it would probably treat no as a true
value.
I discussed this
More research.
1. Here is the output of a recent run in trunk of coverage analysis on the
code underlying
tools/build/pmc2c.pl:
[parrot] 517 $ PERL5OPT=-MDevel::Cover=-db,coverage/pmc2c prove
t/tools/pmc2cutils/*.t
$@
t/tools/pmc2cutils/00-qualifyDevel::Cover: Can't open -e for MD5
On Tue May 01 15:58:34 2007, particle wrote:
#
[parrot] 502 $ ack --nohtml --nophp svn_entries
config/gen/revision.pm
31:my $entries = $Parrot::Revision::svn_entries;
your interpretation is correct. '.svn_entries' is an svn metadata file
that's not even available in newer
On Tue May 01 19:40:49 2007, [EMAIL PROTECTED] wrote:
Here is the output of 'ack' for SVN_ENTRIES in trunk (post-
Configure.pl, in this instance):
[parrot] 521 $ ack --nohtml --nophp SVN_ENTRIES
...
config_lib.pasm
274:set P0[SVN_ENTRIES], P1
But do we have to do anything with
Patch applied in r18405.
Hack described in Configure.pl and found in Parrot::Configure::Step is fixed
by making Parrot::Configure object into a singleton. This entailed changes in
those two packages as well as config/init/defaults.pm.
Also: Parrot::Configure::Data::slurp() now checks
See attached patch revision.patch.txt. Per discussion on list with particle,
lib/Parrot/
Revision.pm is revised to eliminate unassignable variable $svn_entries and one
stanza of
code associated therewith. Also eliminates unused variable $ent. I also add 4
test files: two
in t/configure/
On Fri Apr 27 19:03:28 2007, jkeen !-- x -- at verizon.net wrote:
Feedback requested on patch attached.
Having heard no objections, patch was applied tonight in r18417.
kid51
Closing ticket.
On Thu May 03 21:02:21 2007, allison !-- x -- at perl.org wrote:
Andy Dougherty wrote:
On Tue, 1 May 2007, James Keenan via RT wrote:
On Tue Apr 10 01:45:31 2007, jrisom !-- x -- at gmail.com wrote:
Configure should act as though writing --foo=no is false instead of
true. Tonight I
Patch applied in r18427 May 05 2007.
On Sat May 05 10:04:24 2007, jkeen !-- x -- at verizon.net wrote:
Patch applied in r18427 May 05 2007.
I'm leaving the ticket open in the hope that some project member who uses SVK
for version
control can add tests for that VCS under t/configure/ and t/postconfigure/.
Patch applied in r18428.
Closing ticket.
I have taken this ticket because I have begun working on it in the
'reconfigure' branch.
Please review patch.
Index: Configure.pl
===
--- Configure.pl(revision 18438)
+++ Configure.pl(working copy)
@@ -60,8 +60,35 @@
This turns on the user prompts.
+=item C--test
+
+Run certain tests along with
Applied to trunk in r18447.
Applied with slight correction in r..
Correction was to place 2 tests in t/configure/25-options_test.t into SKIP
blocks when $ENV
{PERL5OPT}=-MDevel::Cover. This was necessary because Devel::Cover was gagging
on running
tests within tests.
Tested in both trunk and reconfigure branch;
On Sat May 12 07:17:36 2007, jkeen !-- x -- at verizon.net wrote:
Applied with slight correction in r..
That would be: r18516.
kid51
On Wed May 02 19:33:17 2007, jkeen !-- x -- at verizon.net wrote:
See attached patch revision.patch.txt. Per discussion on list with
particle, lib/Parrot/
Revision.pm is revised to eliminate unassignable variable $svn_entries
and one stanza of
code associated therewith. Also eliminates
On Thu May 17 01:49:39 2007, bernhard wrote:
For the code coverage I suggest that you add an op like
'non_existent_op_used_for_testing' hardcoded in your test script. In
this way you wouldn't depend on src/ops/*.ops.
bernhard++! I was able to implement your suggestion in less than an
On Sun May 20 08:08:13 2007, jkeen !-- x -- at verizon.net wrote:
Since I created the postconfigure/ subdirectory, I'll start by
writing a patch describing what the tests in that directory are for.
If you worked on one of the other 4 undocumented subdirectories,
please submit a patch as
On Mon May 21 18:58:45 2007, allison !-- x -- at perl.org wrote:
Bernhard Schmalhofer via RT wrote:
When hearing 'executables' I primarily think of compiled programs, e.g.
compiled C-programs. Personally I'd call the *.pl files simple scripts.
Agreed, *.pl isn't an executable. Script
Applied in r18617.
No complaints in last 2-1/2 weeks. Resolving ticket.
On Fri Jun 01 19:46:40 2007, rgrjr wrote:
This is from the Small tweak to Pmc2c.pm I posted on 19-May and
committed as r18646 on 26-May. Note that lib/Parrot/Pmc2c.pm is not
actually doing anything different now, it's just telling you that none
of the code for these methods is being used in
Test now passes on Darwin and Linux. Resolving ticket.
I was patching along the patch and hadn't tried it out myself. When I did so
tonight in the
'reconfigure' branch, I did not get good results:
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 \
On Fri Jun 01 09:29:18 2007, chromatic !-- x -- at wgz.org wrote:
This patch is very close. Instead of handling compilation manually, I
recommend instead using cc_gen() and cc_build() from
Parrot::Configure::Step.
See config/auto/sizes.pm for an example.
-- c
Can you explain why using
On Wed Jun 06 00:45:25 2007, ptc wrote:
On Mon Feb 20 14:35:58 2006, jhoblitt wrote:
[jhoblitt !-- x -- at hawaii.edu - Wed Dec 14 01:56:56 2005]:
- The framework itself needs tests!!!
Parrot::Configure::Data should be low hanging fruit
This has been mustly done since
Applied in r18965.
kid51
Well, no one else contributed anything to this file, so there's no point in
considering it for
trunk. I'll leave it in 'reconfigure' and update it from time to time.
kid51
On Wed May 30 19:30:39 2007, jkeen !-- x -- at verizon.net wrote:
[snip]
In other words, no src/ops/.ops file currently sets VERSION in any
way other than by assignment from PARROT_VERSION.
I therefore ask: Why should we not stipulate that 'VERSION =
PARROT_VERSION' is the *sole*
Okay, then I won't need to supply a patch. Closing ticket.
On Tue Jun 19 09:19:38 2007, bernhard wrote:
Perhaps somebody who knows about creating Parrot distributions can comment
whether 'tools/dev/mk_manifests.pl' and 'tools/dev/installfiles.pl' are
needed at all.
Well, pending an answer to that question, I decided to take bull by horns and
Name change applied. Closing ticket.
On Fri Jun 22 12:48:39 2007, chromatic !-- x -- at wgz.org wrote:
On Tuesday 19 June 2007 05:45:42 James Keenan wrote:
According to its documentation, mk_manifests.pl ...generates a set
of FMANIFEST.* files that give the final
locations in the file system for all the installable files
On Tue Feb 13 08:01:12 2007, ptc wrote:
The profiling options specified in config/init/defaults.pm should be
moved into their own 'step' of the configure process.
Paul: Can you explain your rationale for this?
kid51
On Tue Feb 13 08:06:53 2007, ptc wrote:
The profiling options used in config/init/defaults.pm are specific to
gcc. This should probably be specified in the relevant hints file.
The profiling options code in config/init/defaults.pm reads:
if ( $conf-options-get('profile') ) {
On Fri Jun 22 18:17:49 2007, jkeen !-- x -- at verizon.net wrote:
Write unit tests for config/init/manifest.pm,
the module whose functionality executes Parrot
configuration step init::manifest.
Some tests have already been written for this module in the
'reconfigure' branch of the Parrot
On Mon Jun 25 11:46:07 2007, ptc wrote:
On 25/06/07, Bernhard Schmalhofer via RT
parrotbug-followup !-- x -- at parrotcode.org wrote:
On So. 06. Mai 2007, 12:09:58, bernhard wrote:
TODO: Check whether Parrot::Distribution::gen_manifest_skip() can
be used
in mk_manifest_and_skip.pl or
The POD for config/init/miniparrot.pm states:
Modifies settings to match miniparrot (ANSI C Parrot)'s needs. This step
primarily overwrites a lot of settings in the Configure database to disable
JIT and *match ANSI characteristics* (emphasis added).
How this package disables JIT is fairly
On Tue Jun 26 07:50:06 2007, jkeen !-- x -- at verizon.net wrote:
But it's not clear how one can validate that the result will match
ANSI characteristics. Is
there any link we could place in the POD that would show which ANSI C
characteristics we
need to have miniparrot match?
I've got
On Fri Jun 22 18:19:26 2007, jkeen !-- x -- at verizon.net wrote:
config/init/headers.pm would benefit from an
explanation of what 'nongenerated headers' are.
This module has already achieved 100% coverage of all statements and branches
during testing,
so we only need to respond to the
On Tue Jun 26 20:15:04 2007, jkeen !-- x -- at verizon.net wrote:
On Fri Jun 22 18:19:26 2007, jkeen !-- x -- at verizon.net wrote:
config/init/headers.pm would benefit from an
explanation of what 'nongenerated headers' are.
This module has already achieved 100% coverage of all
1 - 100 of 1353 matches
Mail list logo
