Parrot: {24} Testing Ticketshttp://trac.parrot.org/parrot/report/24
Trac Report - This report lists tickets that have fixes/patches posted, but need testing to verify that the problem is fixed.
It shows any non-closed tickets that have "testing" in the Keyword field.
Since some tickets have the "testing" keyword for other reasons, this report may list false positives.
The tickets are color-coded by Type, and ordered by Type and Id.
Original discussion: http://irclog.perlgeek.de/parrotsketch/2010-08-03#i_2660866
en-usParrothttp://trac.parrot.org/parrot/chrome/site/parrot_logo.pnghttp://trac.parrot.org/parrot/report/24
Trac v0.11.7#205: r35872 test fails on solarisWed, 21 Jan 2009 20:39:05 GMTFri, 13 Aug 2010 14:10:55 GMT<p>
Test Summary Report
</p>
<hr />
<p>
t/op/trans (Wstat: 256 Tests: 22 Failed: 1)
</p>
<blockquote>
<p>
Failed test: 14
Non-zero exit status: 1
</p>
</blockquote>
<p>
Files=395, Tests=11826, 574 wallclock secs ( 3.10 usr 1.83 sys + 89.02 cusr 30.35 csys = 124.30 CPU)
Result: FAIL
make: *** [test] Error 1
</p>
<p>
I'm not sure what else you need, so here are some random things.
</p>
<p>
uname -a
SunOS web01-dev 5.10 Generic_127112-11 i86pc i386 i86pc Solaris
</p>
<p>
./parrot -V
This is parrot version 0.9.0-devel built for nojit.
Copyright (C) 2001-2008, The Perl Foundation.
</p>
<p>
This code is distributed under the terms of the Artistic License 2.0.
For more details, see the full text of the license in the LICENSE file
included in the Parrot source tree.
</p>
http://trac.parrot.org/parrot/ticket/205
http://trac.parrot.org/parrot/ticket/205Report#313: ignore print -0 test errors on win32Wed, 11 Feb 2009 09:07:06 GMTTue, 03 Aug 2010 21:58:46 GMT<p>
The win32 msvcrt has a special limitation not to print -0 as -0, instead it prints 0.
</p>
<p>
openbsd seems to have the same problem. cygwin is not affected, since it uses newlib, which is similar to the glibc in this regard.
</p>
<p>
For now I fixed the failing tests, but there should be a workaround.
</p>
<pre class="wiki">t\pmc\complex.t:
not ok 380 - sinh of 0-2i
# Have: 0.000000-0.909297i
# Want: -0.000000-0.909297i
not ok 381 - sinh of 0+2i
# Have: 0.000000+0.909297i
# Want: -0.000000+0.909297i
t\pmc\float.t:
not ok 23 - neg 0
# Failed test 'neg 0'
# at t\pmc\float.t line 509
# '0'
# doesn't match '/^-0/
# '
t\op\arithmetics.t:
not ok 7 - turn a native number into its negative
# Failed test 'turn a native number into its negative'
# at t\op\arithmetics.t line 175.
# got: '0
# 0
# -123.456789
# 123.456789
# 0
# 0
# -123.456789
# 123.456789
# '
# expected: '-0
# 0
# -123.456789
# 123.456789
# -0
# 0
# -123.456789
# 123.456789
# '
</pre><p>
The internal numeric representation seems not to be affected.
In detail, this patch does not help. It's just the printer.
</p>
<pre class="wiki">Index: parrot-svn/src/ops/math.ops
===================================================================
--- parrot-svn.orig/src/ops/math.ops
+++ parrot-svn/src/ops/math.ops
@@ -774,7 +774,17 @@ inline op neg(inout INT) :base_core {
}
inline op neg(inout NUM) :base_core {
+#ifdef WIN32
+ /* The msvcrt is broken for neg -0.0 */
+ if ($1 == -0.0) {
+ $1 = -0.0;
+ }
+ else {
+ $1 = - $1;
+ }
+#else
$1 = - $1;
+#endif
}
inline op neg(invar PMC) :base_core {
@@ -786,7 +796,17 @@ inline op neg(out INT, in INT) :base_cor
}
inline op neg(out NUM, in NUM) :base_core {
+#ifdef WIN32
+ /* The msvcrt is broken for neg -0.0 */
+ if ($2 == -0.0) {
+ $1 = -0.0;
+ }
+ else {
+ $1 = - $1;
+ }
+#else
$1 = - $2;
+#endif
}
inline op neg(out PMC, invar PMC) :base_core {
</pre>http://trac.parrot.org/parrot/ticket/313
http://trac.parrot.org/parrot/ticket/313Report#357: Enable meaningful testing of t/native_pbc/*.tWed, 18 Feb 2009 22:28:58 GMTSat, 26 Feb 2011 12:56:32 GMT<p>
Version 0.9.1 was released with failing t/native_pbc/*.t tests. If the tests are to be included in 1.0, it would be nice to have confidence that they will pass in the released version.
</p>
<p>
Offhand, I can think of three big problems that contributed to the failure. I hasten to add that *all* of these were out of the control of the release manager -- they are inherent in the design of the tests.
</p>
<p>
1. The tests act differently in "DEVELOPING" versus released directories, meaning all the tests done in an svn-checkout -- even those done just prior to release -- weren't necessarily relevant.
</p>
<p>
2. The release procedure is difficult in practice. It is not easy, on short notice, to get developers with all the requisite different platforms to run the appropriate scripts, commit the appropriate files, and re-run all the appropriate tests. Also, because of item 1, even running all the appropriate tests does not ensure that the tests will actually pass in the released version.
</p>
<p>
3. There was no meaningful code freeze prior to the release, making it essentially impossible to do the coordination necessary for item 2.
</p>
<p>
What to do?
</p>
<p>
First, if the tests are to be kept, they must be designed so that they can be meaningfully run well in advance of the release. That way, new raw pbc files can be generated ahead of time, committed, and tested, and failures can be addressed. If they cannot be redesigned this way, then I think they are too fragile to waste time on, and they should simply be deleted.
</p>
<p>
Second, I think the ideas of having a code freeze and issuing release candidates merit serious consideration prior to 1.0.
</p>
http://trac.parrot.org/parrot/ticket/357
http://trac.parrot.org/parrot/ticket/357Report#435: languages moved to examples need tests.Wed, 11 Mar 2009 12:31:37 GMTWed, 13 Oct 2010 02:58:35 GMT<p>
The tests for <tt>examples/languages</tt> should:
</p>
<ol><li> be run as part of <tt>make examples_tests</tt>
</li><li>Once covered, they should be skipped from <tt>t/examples/catchall.t</tt> (see line 34 of this file for another skip)
</li></ol><p>
As it stands, the files in that directory are generating even more failures in examples_tests, because they aren't meant to be run from the top level directory, and <tt>.include</tt>s are failing.
</p>
http://trac.parrot.org/parrot/ticket/435
http://trac.parrot.org/parrot/ticket/435Report#457: t/dynpmc/os.t has invalid stat() and lstat() tests.Mon, 16 Mar 2009 13:38:44 GMTThu, 23 Sep 2010 22:50:48 GMT<p>
TT <a class="closed ticket" href="http://trac.parrot.org/parrot/ticket/325" title="bug: case-sensitivity test issues on win32 (closed: fixed)">#325</a> incorrectly put a "TODO" on the stat() and lstat() tests for Solaris in t/pmc/os.t. stat() and lstat() work fine on Solaris. The problem is that the test is wrong. It erroneously assumes that the st_dev value reported by one program (parrot, in this case) is necessarily the same as the st_dev value reported by another program (perl, in this case) that might have been compiled in a different mode. Specifically, on Solaris, the default system perl is compiled in 32-bit mode. If parrot is compiled in 64-bit mode, it will get a different 'st_dev' value. That's not a problem because, according to the Solaris man page for stat(2):
</p>
<p>
<tt> Its value may be used as input to the ustat() function to determine more information about this file system. No other meaning is associated with this value. </tt>
</p>
<p>
The fix is "simple": t/dynpmc/os.t should only compare the last 12 entries returned by stat, not all 13. Alas, I don't know how to do that in PIR.
</p>
<p>
This problem is not necessarily specific to Solaris, though that's the platform where a mix of models is most likely to be encountered.
</p>
<p>
If no one has the time to fix the tests, they should probably be skipped. Currently, it can result in spurious passing TODOs if perl and parrot happen to have been compiled in the same mode.
</p>
<p>
<strong>UPDATE</strong>: Updated description 2010-09-20 to reflect movement of file from <i>t/pmc/</i> to <i>t/dynpmc</i>.
</p>
http://trac.parrot.org/parrot/ticket/457
http://trac.parrot.org/parrot/ticket/457Report#955: need ability to create tempfile from PIRFri, 28 Aug 2009 18:05:43 GMTThu, 07 Jul 2011 19:29:50 GMT<p>
to fully convert tests from Perl to PIR, we need a PIR-level analog to:
</p>
<pre class="wiki"> use Parrot::Test::Util 'create_tempfile';
</pre><p>
... I'm not sure if we can automatically delete; that would be nice, but a manual deletion at program exit is sufficient.
</p>
http://trac.parrot.org/parrot/ticket/955
http://trac.parrot.org/parrot/ticket/955Report