On Fri Aug 15 18:33:59 2008, [EMAIL PROTECTED] wrote:
And I, for one, find myself going to the Smolder site much more often
than our 'official' site these days -- precisely because I can spot new
test failures more quickly there and jump in with a quick fix.
As I did just now:
I
On Mon Aug 11 19:40:23 2008, [EMAIL PROTECTED] wrote:
Addressed, if not fully fixed, in r30178.
This is an old test. Its svn log notwithstanding, I think it predates
kid51's involvement in configuration tests.
It *is* an old test. Joshua Hoblitt wrote it back in the deep mists of
time.
1 test eliminated in RT 57826.
On Fri Aug 15 07:00:38 2008, coke wrote:
#not ok 1 - Line length ok
# Failed test 'Line length ok'
# at t/codingstd/linelength.t line 80.
# Lines longer than coding standard limit (100 columns) in 1 files:
# /home/smoke/parrot/compilers/pirc/new/pirsymbol.c:256: 104 cols
# Looks like you
Per discussion with Bob Rogers, I'll apply this Tuesday after the release.
Colleagues,
Since there have been no comments one way or another, I will apply this
patch in the next 24-36 hours unless some provides a good reason otherwise.
Thank you very much.
Thanks. Am close to submitting a patch. Anyone who wants to kibitz
should check out the 'opsrenum' branch from SVN.
I think this patch is worth considering and I encourage comments from
those Parrot developers who are knowledgeable about these file coda
issues, how they appear in vi and emacs, etc.
Since this patch is likely to affect a large number of files, I think we
should defer full consideration until
Okay, thanks for getting back to me. Could you read the inline comments
I have inserted into Parrot::OpsRenumber::renum_op_map_file()?
Do the comments accurately reflect what needs to happen re opcode
renumbering both now and at 1.0?
You can read them here:
On Mon Aug 11 07:26:33 2008, coke wrote:
With this patch, the probe now reports using the ccflags I passed in on
the command line, thanks.
Thanks. I'll do the merging this evening.
kid51
Merged into trunk in r41508. A Smolder report of tests done just before
the merge is viewable at
http://smolder.plusthree.com/app/public_projects/report_details/3830.
The coding standards test failures were addressed before the merge.
I'll allow a couple days for road testing, then resolve the
Addressed, if not fully fixed, in r30178.
This is an old test. Its svn log notwithstanding, I think it predates
kid51's involvement in configuration tests. When I'm more awake, I will
get an idea as to whether it is still needed at all.
Thank you very much.
kid51
On Wed Jul 02 09:17:44 2008, [EMAIL PROTECTED] wrote:
What purpose remains, then, for either tools/dev/ops_renum.mak or my
alternative, tools/dev/opsrenumber.pl? Is such a program only intended
to provide a number for newly added opcodes?
kid51
We haven't had any response to this
Last weekend tetragon and I had considerable discussion on #parrot about
this problem. My diagnosis was that we should not be handling
command-line options at all in 'hints' files; they should be handled in
inter::progs.
The patch attached removes options handling from
On Sat Aug 09 10:31:37 2008, [EMAIL PROTECTED] wrote:
On Saturday 09 August 2008 06:33:46 James Keenan via RT wrote:
What purpose remains, then, for either tools/dev/ops_renum.mak or
my
alternative, tools/dev/opsrenumber.pl? Is such a program only
intended
to provide a number
ask this:
On Sat Aug 09 09:37:49 2008, doughera wrote:
On Sat, 9 Aug 2008, James Keenan via RT wrote:
For example, how can you know
which
compiler flags to suggest if you don't even know which compiler you're
using yet?
Do you believe that the search for the C compiler (and, presumably
As expected, no harm done on 32-bit PPC OS X 10.4.
Since people are looking at patches for Darwin, let me remind you of
these open tickets:
http://rt.perl.org/rt3/Ticket/Display.html?id=49226
http://rt.perl.org/rt3/Ticket/Display.html?id=52212 (another Seneca patch)
For reference, here's what I got last night on Linux after a make
realclean, svn up and perl Configure.pl.
$ make headerizer make
/usr/local/bin/perl tools/build/headerizer.pl src/string.o
src/ops/core_ops.o src/ops/core_ops_switch.o src/atomic/gcc_x86.o
src/builtin.o src/byteorder.o
On Thu Aug 30 10:36:23 2007, particle wrote:
below is a brief requirements list for these use cases. at this early
point in the design process, the first two use cases are so similar
we'll consider them together.
12 develop/maintain cross-compilation configuration:
~ specify which
Applied to trunk in r29967. s1n++. Rakudo testers: Please put this
through its paces over the next few days so we can flush out any bugs.
Thank you very much.
kid51
On Sat Aug 02 20:08:36 2008, tetragon wrote:
The Configure test for MMX on Intel chips
Was this a test in t/configure/? t/steps/? or during Configure.pl itself?
I have tried this patch out in a sandbox from trunk and, at the very
least, it does no harm with anything up through Parrot's 'make test'.
I rarely go into the languages or, for example, run Rakudo's 'make
test', so I'm unclear as to how to use this. What would I do after I've
called:
cd
On Sat Aug 02 05:06:31 2008, rurban wrote:
On Sat Jun 14 17:17:03 2008, [EMAIL PROTECTED] wrote:
Can anyone on FreeBSD give us an update on this issue?
freebsd7, recent parrot svn (r29922)
passes the t/op/trans.t tests
Thanks for looking into this, Reini. Now, would these failures
Applied in r29959. tetragon++. Marking ticket resolved.
On Fri Aug 01 07:31:55 2008, doughera wrote:
Right. The problem is still exactly the same -- the hints file is still
unconditionally overwriting ccflags. Since that hasn't changed, the
problem is still there.
Okay. When I was writing tests for the config step classes, I never
went
Since we have achieved the single largest feasible speedup discussed in
this thread -- consolidation of the steps in t/steps/ -- I am going to
mark this ticket resolved.
I am opening a new RT, 57492, calling for exploration of the feasibility
of consolidating or otherwise speeding up the tests in
Since thanks to Michael Peters' work on Smolder we now have a Smolder
server, and since thanks in large part to Dan Magnuszewski we have lots
of Smolder reports daily, I think we have achieved the major objectives
of this RT.
I recommend that the ticket be marked resolved and that, if new
Andrew,
Do you know how this ticket stands?
Thank you very much.
kid51
I tried again today to apply this patch and I still cannot get it to
apply cleanly. I got this *.rej file:
$ cat config/gen/makefiles/root.in.rej
***
*** 379,384
\
$(OPS_DIR)/core_ops$(O) \
$(OPS_DIR)/core_ops_switch$(O) \
$(SRC_DIR)/builtin$(O) \
Coke: Given the points Leo made and the fact that there has been
nothing from the OP in 4 years, can we close this ticket?
Thanks.
kid51
c:
Should we still have this patch under consideration, and the related
issues under discussion?
Thank you very much.
kid51
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/
coke:
Are you still experiencing these problems?
Thank you very much.
kid51
On Mon Aug 06 05:29:23 2007, pcoch wrote:
In the file t/codingstd/linelength.t there is the todo item:
# XXX this should really be using src_dir instead of build_dir but it
# doesn't exist (yet)
This needs to be implemented
Alberto,
svn annotate and svn log suggest that you wrote the
On Thu Jul 31 16:38:12 2008, [EMAIL PROTECTED] wrote:
I believe you can safely modify the file and add the line after:
#CONDITIONED_LINE(i386_has_gcc_cmpxchg):
$(SRC_DIR)/atomic/gcc_x86$(O) \
(That's on line 372 for me).
Thanks. I tried that out. I applied (in sandbox) the
On Wed Nov 28 20:34:32 2007, coke wrote:
mk_native_pbc has, 2x:
make -s progclean
From config/gen/makefiles/[EMAIL PROTECTED]:
progclean :
$(RM_F) $(O_FILES) \
$(PARROT) $(IMCC_DIR)/main$(O) \
$(PDUMP) $(SRC_DIR)/pdump$(O) $(SRC_DIR)/packdump$(O) \
$(SRC_DIR)/pbc_info$(O)
Here's a list as of today -- and one that is not limited to perl scripts:
$ svn status -v tools/dev/* | tr -s ' ' | sort -t ' ' -k 7 -k 12 | cut
-d ' ' -f3,5
11501 tools/dev/mk_native_pbc
11501 tools/dev/testyamd
17087 tools/dev/parrot_8.supp
17087 tools/dev/src-t.sh
17087 tools/dev/vms-patch
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/alpha:
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
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
Tests contributed as part of r29867. Marking ticket resolved.
kid51
Andy: Are you still getting the error reported in this ticket? If so,
could you paste output of Configure.pl?
Thanks.
kid51
On Thu Jun 19 16:34:54 2008, [EMAIL PROTECTED] wrote:
Jeff (Todd, and anyone else getting the auto::readline error):
Can you try out this patch:
http://rt.perl.org/rt3/Ticket/Attachment/389086/176448/darwin-
editline-failer.txt
Jeff, Todd, et. al.:
Have you tried out this patch?
Would it be possible to get an update from Win32 users on these tests?
Specifically, output of 'prove -v' for these tests:
t/op/arithmetics.t
t/pmc/complex.t
t/pmc/float.t
(I'm going to assume that the sprintf test is still problematic.)
Thank you very much.
kid51
Interestingly enough, we are also getting failures on these 4 test files
on the OpenBSD Smolder tester:
http://smolder.plusthree.com/app/public_projects/report_details/3135
But, AFAICT, the Smolder server doesn't identify the particular tests
within the file which are failing.
kid51
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'
# expected:
On Wed Jul 30 16:26:13 2008, coke wrote:
Click Goto first failure. Click Failed. Click the box of the same
color as the failed box: You should see the tap output:
Thanks, Coke. That enabled me to verify that for these 3 test files:
t/op/arithmetics.t
t/pmc/complex.t
t/pmc/float.t
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.
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'
# expected:
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 parrot with gcc. Here
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 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 today
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
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 -
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
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
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 -- would speed it
up,
I agree
Patch applied in r29660 tonight.
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 understand it better and make our
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 concerned
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;
My wish was your command! Applied in r29617. Thank you very much.
kid51
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 revision is
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
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
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 error
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
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]
The control flow here is somewhat
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, I
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
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 both
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
-- 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 Release Note,
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.
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 21
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?
Yes. Look at the Config variables that are set
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 of this RT
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
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 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
functionality
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 an
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
201 - 300 of 1397 matches
Mail list logo
