HTTP/1.1 -1 Read error in cache disk data: SuccessContent-Type: text/csv; charset="utf-8" Last-Modified: Sat, 22 Jan 2022 02:45:13 GMT Content-length: 7372 Connection: Close Proxy-Connection: Close X-Cache: HIT from web1.osuosl.org Server: ProxyTrack 0.5 (HTTrack 3.49.2) ticket,summary,component,priority,version,milestone,type,__color__,owner,status,created,_changetime,_description,_reporter 457,t/dynpmc/os.t has invalid stat() and lstat() tests.,testing,normal,,,bug,4,,new,2009-03-16T13:38:44Z,2010-09-23T22:50:48Z,"TT #325 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): {{{ 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. }}} 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. This problem is not necessarily specific to Solaris, though that's the platform where a mix of models is most likely to be encountered. 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. '''UPDATE''': Updated description 2010-09-20 to reflect movement of file from ''t/pmc/'' to ''t/dynpmc''.",doughera 205,r35872 test fails on solaris,core,normal,trunk,,bug,4,,new,2009-01-21T20:39:05Z,2010-08-13T14:10:55Z,"Test Summary Report ------------------- t/op/trans (Wstat: 256 Tests: 22 Failed: 1) Failed test: 14 Non-zero exit status: 1 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 I'm not sure what else you need, so here are some random things. uname -a SunOS web01-dev 5.10 Generic_127112-11 i86pc i386 i86pc Solaris ./parrot -V This is parrot version 0.9.0-devel built for nojit. Copyright (C) 2001-2008, The Perl Foundation. 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. ",jsut 435,languages moved to examples need tests.,none,normal,,,cage,5,,new,2009-03-11T12:31:37Z,2010-10-13T02:58:35Z,"The tests for {{{examples/languages}}} should: 1. be run as part of {{{make examples_tests}}} 1. Once covered, they should be skipped from {{{t/examples/catchall.t}}} (see line 34 of this file for another skip) 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 {{{.include}}}s are failing.",coke 357,Enable meaningful testing of t/native_pbc/*.t,testing,normal,,,cage,5,,new,2009-02-18T22:28:58Z,2011-02-26T12:56:32Z,"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. 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. 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. 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. 3. There was no meaningful code freeze prior to the release, making it essentially impossible to do the coordination necessary for item 2. What to do? 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. Second, I think the ideas of having a code freeze and issuing release candidates merit serious consideration prior to 1.0.",doughera 955,need ability to create tempfile from PIR,testing,normal,,,todo,6,whiteknight,assigned,2009-08-28T18:05:43Z,2011-07-07T19:29:50Z,"to fully convert tests from Perl to PIR, we need a PIR-level analog to: {{{ use Parrot::Test::Util 'create_tempfile'; }}} ... I'm not sure if we can automatically delete; that would be nice, but a manual deletion at program exit is sufficient.",coke 313,ignore print -0 test errors on win32,testing,normal,trunk,,todo,6,,new,2009-02-11T09:07:06Z,2010-08-03T21:58:46Z,"The win32 msvcrt has a special limitation not to print -0 as -0, instead it prints 0. openbsd seems to have the same problem. cygwin is not affected, since it uses newlib, which is similar to the glibc in this regard. For now I fixed the failing tests, but there should be a workaround. {{{ 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 # ' }}} The internal numeric representation seems not to be affected. In detail, this patch does not help. It's just the printer. {{{ 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 { }}} ",rurban