* 600+ BigDecimal tests @ 2002-12-22 14:58 Anthony Green 2003-01-03 1:35 ` Mark Wielaard 0 siblings, 1 reply; 12+ messages in thread From: Anthony Green @ 2002-12-22 14:58 UTC (permalink / raw) To: mauve-discuss I've just committed the following change... 2002-12-22 Anthony Green <green@redhat.com> * gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java: New file. It's over 100k, so I'm not going to post it as a patch. It contains a large number of BigDecimal test cases. I generated it by hacking on DiagBigDecimal.java from IBM's ICU project. The ICU project uses a very liberal license (which I copied into the test source), so it seems like fair game for Mauve. AG ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 600+ BigDecimal tests 2002-12-22 14:58 600+ BigDecimal tests Anthony Green @ 2003-01-03 1:35 ` Mark Wielaard 2003-01-17 19:26 ` Mark Wielaard 2003-01-20 0:06 ` Anthony Green 0 siblings, 2 replies; 12+ messages in thread From: Mark Wielaard @ 2003-01-03 1:35 UTC (permalink / raw) To: Anthony Green; +Cc: mauve-discuss [-- Attachment #1: Type: text/plain, Size: 1169 bytes --] Hi, On Sun, 2002-12-22 at 23:59, Anthony Green wrote: > I've just committed the following change... > > 2002-12-22 Anthony Green <green@redhat.com> > > * gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java: New file. > > It's over 100k, so I'm not going to post it as a patch. > > It contains a large number of BigDecimal test cases. I generated it > by hacking on DiagBigDecimal.java from IBM's ICU project. I have been removing inner classes from the test cases since libgcj uses Mauve in a way that cannot handle those. Normally that is easy (just use the test class itself instead of creating a new inner class). But in the case of DiagBigDecimal I had to make a bit more changes. The changes mostly just remove the old test framework that IBM was using. * gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java (diagrun): Return void. (DiagException): Remove and use RuntimeException if necessary. (summary): Removed. (Test): Removed. Would it be OK to commit this? If you have a way to track changes from the original test could you send me the script you are using then I can hack that. Cheers, Mark [-- Attachment #2: DiagBigDecimal.diff --] [-- Type: text/x-patch, Size: 13298 bytes --] Index: gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java =================================================================== RCS file: /cvs/mauve/mauve/gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java,v retrieving revision 1.1 diff -u -r1.1 DiagBigDecimal.java --- gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java 22 Dec 2002 22:56:32 -0000 1.1 +++ gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java 3 Jan 2003 01:34:04 -0000 @@ -200,23 +200,20 @@ * detected, or <0 if an unexpected Exception was signalled. */ - public int diagrun(TestHarness harness){ - int fails; + public void diagrun(TestHarness harness){ int num=0; - DiagException de=null; + RuntimeException de=null; java.lang.RuntimeException e=null; java.lang.String rest=null; - fails=0; // count of failures try{num=1;num:for(;num<=testcount;num++){ // [testcount is constant set above] try{ dotest(harness, num); } - catch (DiagException $1){de=$1; + catch (RuntimeException $1){de=$1; say(harness); harness.verbose("**** Failed:"+" "+de.getMessage()+" "+"****"); say(harness); - fails=fails+de.failcount; } } } @@ -224,10 +221,10 @@ say(harness); harness.verbose("**** Failed: unexpected exception ****"); e.printStackTrace(); - return -1; + return; }/*num*/ - return fails; + return; } /* Run test by number -- method for development/private switching */ @@ -1193,7 +1190,6 @@ }/*checknull*/ harness.check (flag, "cst301"); - summary("Constructors", harness); return; } @@ -1208,7 +1204,6 @@ harness.check ((one.toString()).equals("1"), "cuc002"); harness.check ((ten.toString()).equals("10"), "cuc003"); - summary("No mutation", harness); return;} @@ -1237,7 +1232,6 @@ harness.check (((new BigDecimal("0.01")).abs().toString()).equals("0.01"), "abs015"); harness.check (((new BigDecimal("-0.01")).abs().toString()).equals("0.01"), "abs016"); - summary("abs", harness); return;} /* ----------------------------------------------------------------- */ @@ -1367,7 +1361,6 @@ }/*checknull*/ harness.check (flag, "add200"); - summary("add", harness); return;} /* ----------------------------------------------------------------- */ @@ -1393,7 +1386,6 @@ }/*checknull*/ harness.check (flag, "cpt100"); - summary("compareTo", harness); return;} /* ----------------------------------------------------------------- */ @@ -1462,7 +1454,6 @@ }/*div0*/ harness.check (flag, "div204"); - summary("divide", harness); return;} /* ----------------------------------------------------------------- */ @@ -1488,7 +1479,6 @@ flag=true; }/*checknull*/ harness.check (flag, "max010"); - summary("max", harness); return;} /** Test the {@link BigDecimal#min} method. */ @@ -1515,7 +1505,6 @@ }/*checknull*/ harness.check (flag, "min010"); - summary("min", harness); return;} /* ----------------------------------------------------------------- */ @@ -1624,7 +1613,6 @@ }/*checknull*/ harness.check (flag, "mul200"); - summary("multiply", harness); return;} /* ----------------------------------------------------------------- */ @@ -1790,7 +1778,6 @@ }/*checknull*/ harness.check (flag, "sub200"); - summary("subtract", harness); return;} /* ----------------------------------------------------------------- */ @@ -1853,7 +1840,6 @@ // 244 // 245 - summary("byteValue+", harness); return;} /* ----------------------------------------------------------------- */ @@ -1891,7 +1877,6 @@ } harness.check (flag, "cto102"); - summary("compareTo(Obj)", harness); return;} /* ----------------------------------------------------------------- */ @@ -1914,7 +1899,6 @@ harness.check (((new BigDecimal(val)).doubleValue())==java.lang.Double.POSITIVE_INFINITY, "dov006"); val="-1e1000"; harness.check (((new BigDecimal(val)).doubleValue())==java.lang.Double.NEGATIVE_INFINITY, "dov007"); - summary("doubleValue", harness); return;} /* ----------------------------------------------------------------- */ @@ -1928,7 +1912,6 @@ harness.check ((!(d.equals((java.lang.Object)(new BigDecimal(66))))), "equ003"); harness.check (d.equals((java.lang.Object)d), "equ004"); harness.check (d.equals((java.lang.Object)((new BigDecimal(10)).add(new BigDecimal(7)))), "equ005"); - summary("equals", harness); return;} /* ----------------------------------------------------------------- */ @@ -1956,7 +1939,6 @@ harness.check (((new BigDecimal(val)).floatValue())==java.lang.Float.POSITIVE_INFINITY, "flv008"); val="-1e1000"; harness.check (((new BigDecimal(val)).floatValue())==java.lang.Float.NEGATIVE_INFINITY, "flv009"); - summary("floatValue", harness); return;} /* ----------------------------------------------------------------- */ @@ -1975,7 +1957,6 @@ hs="126.5E+200"; d=new BigDecimal(hs); harness.check ((d.hashCode())!=(hs.hashCode()), "has003"); - summary("hashCode", harness); return;} /* ----------------------------------------------------------------- */ @@ -2026,7 +2007,6 @@ harness.check (((5))==((new BigDecimal("5.0")).intValue()), "inv108"); harness.check (((-5))==((new BigDecimal("-5.0")).intValue()), "inv109"); - summary("intValue+", harness); return;} /* ----------------------------------------------------------------- */ @@ -2078,7 +2058,6 @@ harness.check ((((long)5))==((new BigDecimal("5.0")).longValue()), "lov108"); harness.check ((((long)-5))==((new BigDecimal("-5.0")).longValue()), "lov109"); - summary("longValue+", harness); return;} /* ----------------------------------------------------------------- */ @@ -2118,7 +2097,6 @@ harness.check (((new BigDecimal("0.5E+1")).movePointLeft(+5).toString()).equals("0.00005"), "mpl035"); harness.check (((new BigDecimal("0.5E+1")).movePointLeft(+10).toString()).equals("0.0000000005"), "mpl036"); - summary("movePointLeft", harness); return;} /* ----------------------------------------------------------------- */ @@ -2157,7 +2135,6 @@ harness.check (((new BigDecimal("0.5E+1")).movePointRight(-5).toString()).equals("0.00005"), "mpr035"); harness.check (((new BigDecimal("0.5E+1")).movePointRight(-10).toString()).equals("0.0000000005"), "mpr036"); - summary("movePointRight", harness); return;} /* ----------------------------------------------------------------- */ @@ -2181,7 +2158,6 @@ harness.check (((new BigDecimal("-0.1")).scale())==1, "sca015"); harness.check (((new BigDecimal("-0.12")).scale())==2, "sca016"); harness.check (((new BigDecimal("-0.123")).scale())==3, "sca017"); - summary("scale", harness); return;} /* ----------------------------------------------------------------- */ @@ -2226,7 +2202,6 @@ flag=(e.getMessage()).equals("Rounding necessary"); }/*checkrunn*/ harness.check (flag, "ssc102"); - summary("setScale", harness); return;} /* ----------------------------------------------------------------- */ @@ -2252,7 +2227,6 @@ harness.check (((smin))==((new BigDecimal(smax+1)).shortValue()), "shv011"); harness.check (((smax))==((new BigDecimal(smin-1)).shortValue()), "shv012"); - summary("shortValue+", harness); return;} /* ----------------------------------------------------------------- */ @@ -2278,7 +2252,6 @@ harness.check (1==((new BigDecimal("1")).signum()), "sig015"); harness.check (1==((new BigDecimal("1e+12")).signum()), "sig016"); harness.check (0==((new BigDecimal("00e+12")).signum()), "sig017"); - summary("signum", harness); return;} /* ----------------------------------------------------------------- */ @@ -2336,7 +2309,6 @@ harness.check (((new BigDecimal("1E-1000")).toBigInteger().toString()).equals("0"), "tbi044"); harness.check (((new BigDecimal("-1E-1000")).toBigInteger().toString()).equals("0"), "tbi045"); - summary("toBigInteger+", harness); return;} /* ----------------------------------------------------------------- */ @@ -2358,7 +2330,6 @@ harness.check (str.equals((java.lang.Object)cs), "tos004"); harness.check ((cs instanceof java.lang.String), "tos005"); harness.check ((d.toString() instanceof java.lang.String), "tos006"); - summary("toString", harness); return;} /* ----------------------------------------------------------------- */ @@ -2414,40 +2385,6 @@ }/*checkscale*/ harness.check (flag, "val100"); - summary("valueOf", harness); - return;} - - /* ------------------------------------------------------------------ */ - /* Support routines and minor classes follow */ - /* ------------------------------------------------------------------ */ - - /* ----------------------------------------------------------------- */ - /* Method called to summarise pending tests */ - /* ----------------------------------------------------------------- */ - /* Arg1 is section name */ - - private void summary(java.lang.String section, TestHarness harness){ - int bad; - int count; - int i=0; - Test item=null; - bad=0; - count=Tests.size(); - {int $144=count;i=0;i:for(;$144>0;$144--,i++){ - item=(Test)(Tests.elementAt(i)); - if ((!item.ok)) - { - bad++; - harness.verbose("Failed:"+" "+item.name); - } - } - }/*i*/ - totalcount=totalcount+count; - Tests=new java.util.Vector(100); // reinitialize - if (bad==0) - say("OK"+" "+left(section,14)+" "+right("["+count+" "+"tests]",12), harness); - else - throw new DiagException(section+" "+"[failed"+" "+bad+" "+"of"+" "+count+" "+"tests]",bad); return;} @@ -2505,91 +2442,4 @@ diagrun (harness); } -/* ------------------------------------------------------------------ */ -/* Test -- represents a test and its status */ -/* ------------------------------------------------------------------ */ -/* Copyright IBM Corporation 1998, 2000. All rights reserved. */ -/* Author: Mike Cowlishaw */ -/* ------------------------------------------------------------------ */ -/* 1998.07.15 Initial version */ -/* 2000.03.27 Change to javadoc comments */ - -/** - * The <code>Test</code> class is used to record a specific test. - * When constructed, it notes the name of the test and adds the test - * to the list of tests held by the parent. - * - * Its <code>ok</flag> is assigned directly to record whether the - * test succeeded (1) or failed (0). - * - * @see com.ibm.icu.math.DiagBigDecimal - * @version 1.00 2000.03.27 - * @author Mike Cowlishaw - */ - - public class Test{ - private final transient java.lang.String $0="DiagBigDecimal.nrx"; - /* properties shared transient */ - /** The name of the test. */ - transient java.lang.String name; - /** Success flag; will be set to 1 (true) if the test succeeded, or 0 - * (false) if the test failed. - */ - transient boolean ok; - - - /** - * Constructs a new <code>Test</code> with a specified name. - * - * @param testname The <code>String</code> naming the test. - */ - - public Test(java.lang.String testname){super(); - name=testname; // save the name - DiagBigDecimal.this.Tests.addElement((java.lang.Object)this); // and add to parent's list - return;} - } - - /* ------------------------------------------------------------------ */ - /* DiagException */ - /* ------------------------------------------------------------------ */ - /* Copyright IBM Corporation 1996, 2000. All rights reserved. */ - /* Author: Mike Cowlishaw */ - /* ------------------------------------------------------------------ */ - /* 1996.05.27 Initial version in NetRexx (as DiagX) */ - /* 1998.06.25 Copied from NetRexx test suite */ - /* 1999.07.03 Add fail count */ - /* 2000.03.27 Change to javadoc comments */ - - /** - * The <code>DiagException</code> class is used to signal the failure - * of a test group. It records the number of failures in the group. - * -v * @see com.ibm.icu.math.DiagBigDecimal - * @version 1.00 2000.03.27 - * @author Mike Cowlishaw - */ - - public static class DiagException extends java.lang.RuntimeException{ - private final transient java.lang.String $0="DiagBigDecimal.nrx"; - - /* properties shared transient */ - /** the count of failed tests in the group which signalled this - * exception. - */ - transient int failcount=0; - // number of tests which failed - - /** - * Constructs a new <code>DiagException</code> with a message and - * failure count. This is thrown when a group of tests fails. - * - * @param message The <code>String</code> message describing the group. - * @param fails The <code>int</code> number of failed tests in the group. - */ - - public DiagException(java.lang.String message,int fails){ - super(message); - failcount=fails; - return;} - }} + } ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 600+ BigDecimal tests 2003-01-03 1:35 ` Mark Wielaard @ 2003-01-17 19:26 ` Mark Wielaard 2003-01-18 15:27 ` Dalibor Topic 2003-01-20 0:06 ` Anthony Green 1 sibling, 1 reply; 12+ messages in thread From: Mark Wielaard @ 2003-01-17 19:26 UTC (permalink / raw) To: Anthony Green; +Cc: mauve-discuss Hi Anthony, On Fri, 2003-01-03 at 02:35, Mark Wielaard wrote: > On Sun, 2002-12-22 at 23:59, Anthony Green wrote: > > I've just committed the following change... > > > > 2002-12-22 Anthony Green <green@redhat.com> > > > > * gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java: New file. > > > > It's over 100k, so I'm not going to post it as a patch. > > > > It contains a large number of BigDecimal test cases. I generated it > > by hacking on DiagBigDecimal.java from IBM's ICU project. > > I have been removing inner classes from the test cases since libgcj uses > Mauve in a way that cannot handle those. Normally that is easy (just use > the test class itself instead of creating a new inner class). But in the > case of DiagBigDecimal I had to make a bit more changes. The changes > mostly just remove the old test framework that IBM was using. > > * gnu/testlet/java/math/BigDecimal/DiagBigDecimal.java (diagrun): > Return void. > (DiagException): Remove and use RuntimeException if necessary. > (summary): Removed. > (Test): Removed. > > Would it be OK to commit this? > > If you have a way to track changes from the original test could you send > me the script you are using then I can hack that. Could you take a look at the above and tell me if it would be OK to checkin this change? BTW. I currently get the following failures with gcj. Are those expected (bugs in Classpath/gcj?). I get the same failures with Kissme. : FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div377 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div203 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div204 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mul038 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: has001 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov007 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov107 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpl005 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpl006 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpl007 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpr005 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpr006 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpr007 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc005 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc006 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc100 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc101 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc102 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: val008 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: val013 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: val100 (number 1) Couldn't cross check against kaffe since that gives: FAIL: uncaught exception loading gnu.testlet.java.math.BigDecimal.DiagBigDecimaljava.lang.ExceptionInInitializerError: [exception was kaffe.util.NotImplemented] Thanks, Mark ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 600+ BigDecimal tests 2003-01-17 19:26 ` Mark Wielaard @ 2003-01-18 15:27 ` Dalibor Topic 2003-01-18 16:05 ` Mark Wielaard 0 siblings, 1 reply; 12+ messages in thread From: Dalibor Topic @ 2003-01-18 15:27 UTC (permalink / raw) To: Mark Wielaard, Anthony Green; +Cc: mauve-discuss Hi Mark, --- Mark Wielaard <mark@klomp.org> wrote: > Couldn't cross check against kaffe since that gives: > FAIL: uncaught exception loading > gnu.testlet.java.math.BigDecimal.DiagBigDecimaljava.lang.ExceptionInInitializerError: > [exception was kaffe.util.NotImplemented] Aah, that's a "known defect" ;) You need to install the gnu mp libs for arbitrary precision mathematics first ( http://www.swox.com/gmp/ ), and then recompile kaffe to pick it up. I've posted a patch on the kaffe mailing list last week that would allow to fall back on classpath's pure java implementation if gnu mp can not be found. It should enter the kaffe CVS next week. cheers, dalibor topic __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 600+ BigDecimal tests 2003-01-18 15:27 ` Dalibor Topic @ 2003-01-18 16:05 ` Mark Wielaard 2003-01-19 23:40 ` Stephen Crawley 0 siblings, 1 reply; 12+ messages in thread From: Mark Wielaard @ 2003-01-18 16:05 UTC (permalink / raw) To: Dalibor Topic; +Cc: Anthony Green, mauve-discuss Hi, On Sat, 2003-01-18 at 16:27, Dalibor Topic wrote: > Aah, that's a "known defect" ;) You need to install > the gnu mp libs for arbitrary precision mathematics > first ( http://www.swox.com/gmp/ ), and then recompile > kaffe to pick it up. Thanks. I just used the kaffe 1.0.7 Debian package which has the correct dependencies. Results: FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: has001 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov005 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov006 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov007 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov013 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov014 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov015 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov016 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov017 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov019 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov105 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov106 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov107 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov109 (number 1) 14 of 285 tests failed I have now also tried the Blackdown-1.4.1-beta which gives: FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div376 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div203 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div204 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mul038 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: has001 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: has002 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov007 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov107 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: sca007 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc100 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: val100 (number 1) 11 of 600 tests failed And here are the Classpath ones again just for comparison: FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div377 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div203 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: div204 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mul038 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: has001 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov007 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: lov107 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpl005 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpl006 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpl007 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpr005 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpr006 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: mpr007 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc005 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc006 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc100 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc101 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: ssc102 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: val008 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: val013 (number 1) FAIL: gnu.testlet.java.math.BigDecimal.DiagBigDecimal: val100 (number 1) 21 of 338 tests failed Hmmm. This will be fun figuring out what goes wrong where and wether it is the testcase or the implementation that is incorrect (has001, lov007 and lov107 at least look suspicious since all three implementations get those wrong). Note that you will need my patch to get these results, without it both the gcj and kaffe version give up almost immediatly with a NumberFormatException that is never caught. Cheers, Mark ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 600+ BigDecimal tests 2003-01-18 16:05 ` Mark Wielaard @ 2003-01-19 23:40 ` Stephen Crawley 2003-01-20 0:09 ` Anthony Green 0 siblings, 1 reply; 12+ messages in thread From: Stephen Crawley @ 2003-01-19 23:40 UTC (permalink / raw) To: Mark Wielaard; +Cc: Dalibor Topic, Anthony Green, mauve-discuss, crawley Folks, I've been looking at DiagBigDecimal and the "bugs" that it shows up. Some are genuine, but some are questionable. (The following is from memory ... YMMV) * There is a bug with the parse methods barffing with a "+" in the exponent in strings like "123.4E+5". I think this is the bug that Mark has patched. * There is a bug in the toString() method that doesn't add a leading zero in some cases; e.g. it produces ".1234" instead of "0.1234". I have a fix for this. [I'll submit it tonight.] * Some of the other tests check exception message strings, and are failing because the messages are different. I don't know whether this is a bug or not. Is Classpath aiming to give the same exception messages as the Sun JDK implementation ??? * The 'has001' failure is due to differences in the way that Classpath and the SUN JDK are calculating hashcodes. I don't know whether this is a bug or not. Is Classpath aiming to give the same hash code values as the Sun JDK implementation ??? -- Steve ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 600+ BigDecimal tests 2003-01-19 23:40 ` Stephen Crawley @ 2003-01-20 0:09 ` Anthony Green 2003-01-20 0:25 ` Stephen Crawley 2003-01-20 9:48 ` Dalibor Topic 0 siblings, 2 replies; 12+ messages in thread From: Anthony Green @ 2003-01-20 0:09 UTC (permalink / raw) To: Stephen Crawley; +Cc: Mark Wielaard, Dalibor Topic, mauve-discuss, crawley On Sun, 2003-01-19 at 15:39, Stephen Crawley wrote: > * Some of the other tests check exception message strings, and are > failing because the messages are different. > > I don't know whether this is a bug or not. Is Classpath aiming to > give the same exception messages as the Sun JDK implementation ??? I don't think so (could be wrong). I suppose we should remove these tests. > > * The 'has001' failure is due to differences in the way that > Classpath and the SUN JDK are calculating hashcodes. > > I don't know whether this is a bug or not. Is Classpath aiming to > give the same hash code values as the Sun JDK implementation ??? I know that some people have spent time figuring out how Sun hashes various objects, although I don't know if this is a policy. AG ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 600+ BigDecimal tests 2003-01-20 0:09 ` Anthony Green @ 2003-01-20 0:25 ` Stephen Crawley 2003-01-20 1:21 ` Artur Biesiadowski 2003-01-20 9:48 ` Dalibor Topic 1 sibling, 1 reply; 12+ messages in thread From: Stephen Crawley @ 2003-01-20 0:25 UTC (permalink / raw) To: Anthony Green Cc: Stephen Crawley, Mark Wielaard, Dalibor Topic, mauve-discuss, crawley, crawley > On Sun, 2003-01-19 at 15:39, Stephen Crawley wrote: > > * Some of the other tests check exception message strings, and are > > failing because the messages are different. > > > > I don't know whether this is a bug or not. Is Classpath aiming to > > give the same exception messages as the Sun JDK implementation ??? > > I don't think so (could be wrong). I suppose we should remove these > tests. Assuming that we are not aiming for identical exception messages, the correct approach is to change the tests to just check that the correct exceptions are raised. (Currently, at least some of them don't check this!) BTW. Has this question been debated / decided in the past? The reason I ask is that application code may rely on exception message strings to discriminate exception cases. IMO, this is a BAD THING (tm), but in some cases, the application programmer may have little choice. -- Steve ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 600+ BigDecimal tests 2003-01-20 0:25 ` Stephen Crawley @ 2003-01-20 1:21 ` Artur Biesiadowski 2003-01-20 2:11 ` Stephen Crawley 0 siblings, 1 reply; 12+ messages in thread From: Artur Biesiadowski @ 2003-01-20 1:21 UTC (permalink / raw) To: mauve-discuss Stephen Crawley wrote: > BTW. Has this question been debated / decided in the past? The reason > I ask is that application code may rely on exception message strings to > discriminate exception cases. IMO, this is a BAD THING (tm), but in some > cases, the application programmer may have little choice. This is doomed to failure from very start. Exception strings generated by system should be localized (so they can be shown to user in worst case). So there is no way to write language-portable program which looks at details of exception messages. Artur ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 600+ BigDecimal tests 2003-01-20 1:21 ` Artur Biesiadowski @ 2003-01-20 2:11 ` Stephen Crawley 0 siblings, 0 replies; 12+ messages in thread From: Stephen Crawley @ 2003-01-20 2:11 UTC (permalink / raw) To: abies; +Cc: mauve-discuss, crawley > Stephen Crawley wrote: > > > BTW. Has this question been debated / decided in the past? The reason > > I ask is that application code may rely on exception message strings to > > discriminate exception cases. IMO, this is a BAD THING (tm), but in some > > cases, the application programmer may have little choice. > > This is doomed to failure from very start. Exception strings generated > by system should be localized (so they can be shown to user in worst > case). So there is no way to write language-portable program which looks > at details of exception messages. True ... but this doesn't stop programmers doing this kind of thing out of ignorance or desperation. Still, I'm convinced that there is little value in busting a gut to get identical exception messages. -- Steve ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 600+ BigDecimal tests 2003-01-20 0:09 ` Anthony Green 2003-01-20 0:25 ` Stephen Crawley @ 2003-01-20 9:48 ` Dalibor Topic 1 sibling, 0 replies; 12+ messages in thread From: Dalibor Topic @ 2003-01-20 9:48 UTC (permalink / raw) To: Anthony Green, Stephen Crawley Cc: Mark Wielaard, Dalibor Topic, mauve-discuss, crawley --- Anthony Green <green@redhat.com> wrote: > On Sun, 2003-01-19 at 15:39, Stephen Crawley wrote: > > * Some of the other tests check exception > message strings, and are > > failing because the messages are different. > > > > I don't know whether this is a bug or not. Is > Classpath aiming to > > give the same exception messages as the Sun JDK > implementation ??? > > I don't think so (could be wrong). I suppose we > should remove these > tests. I'd vote for a change to catch the exception and ignore the message. After all, free implementations may (have) come up with more understandable, localized, superior messages to those provided by Sun's implementation. It would be counterproductive to force them to change them to Sun's version. > > > > * The 'has001' failure is due to differences in > the way that > > Classpath and the SUN JDK are calculating > hashcodes. > > > > I don't know whether this is a bug or not. Is > Classpath aiming to > > give the same hash code values as the Sun JDK > implementation ??? > > I know that some people have spent time figuring out > how Sun hashes > various objects, although I don't know if this is a > policy. I think the essential question here is: can having different hash methods bite you in some way? Beside obvious hashing performance considerations, I doubt it. best regards, dalibor topic __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 600+ BigDecimal tests 2003-01-03 1:35 ` Mark Wielaard 2003-01-17 19:26 ` Mark Wielaard @ 2003-01-20 0:06 ` Anthony Green 1 sibling, 0 replies; 12+ messages in thread From: Anthony Green @ 2003-01-20 0:06 UTC (permalink / raw) To: Mark Wielaard; +Cc: mauve-discuss On Thu, 2003-01-02 at 17:35, Mark Wielaard wrote: > Would it be OK to commit this? Yes, of course. Thanks, and sorry for the delay. > If you have a way to track changes from the original test could you send > me the script you are using then I can hack that. I don't have anything like that. Thanks again. AG ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2003-01-20 9:48 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-12-22 14:58 600+ BigDecimal tests Anthony Green 2003-01-03 1:35 ` Mark Wielaard 2003-01-17 19:26 ` Mark Wielaard 2003-01-18 15:27 ` Dalibor Topic 2003-01-18 16:05 ` Mark Wielaard 2003-01-19 23:40 ` Stephen Crawley 2003-01-20 0:09 ` Anthony Green 2003-01-20 0:25 ` Stephen Crawley 2003-01-20 1:21 ` Artur Biesiadowski 2003-01-20 2:11 ` Stephen Crawley 2003-01-20 9:48 ` Dalibor Topic 2003-01-20 0:06 ` Anthony Green
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).