[abc] Re: jastadd & abc (fwd)

From: Oege de Moor <Oege.de.Moor@comlab.ox.ac.uk>
Date: Fri Aug 19 2005 - 15:14:49 BST

answers from Tobbe to the questions we discussed at PLDI.
I'm concentrating on the ICSE paper right now, but if someone
else feels like looking into this...

---------- Forwarded message ----------
Date: Fri, 19 Aug 2005 15:44:39 +0200
From: "[ISO-8859-1] Torbjörn Ekman" <torbjorn.ekman@cs.lth.se>
To: Oege de Moor <Oege.de.Moor@comlab.ox.ac.uk>
Subject: Re: jastadd & abc

Hi again,

>>There are still a few questions lingering:
>>* what are the jacks failures you get with your frontend
>> (it's great that there are so few, we'd like to know where
>> any remaining problems are). You mentioned the huge number
>> of Polyglot jacks failures. Is it possible to share the output,
>> so we can also identify where the big problems are with Polyglot?
>>
>>
I have attached the output of a polyglot testrun. I have not really
analyzed the results myself. The errors for our frontend are included at
the end of this mail. The last 9 errors are shared with javac and
they actually depend on how you interpret the language specification.
The others should not be to hard to fix and I have no idea why I haven't
done it yet ;-)

>>* how far are you exactly with Java 5? If we could make the
>> AspectJ 1.2 -> 5 change at the same time as switching from
>> Polyglot, that would be a strong argument which might make
>> our users less unhappy.
>>
>>
Unfortunately I can not give a very good answer to this question. Which
parts do you consider most urgent? The support for Generics is almost
complete. Enhanced for statement is complete. Autoboxing is almost
complete. Enums and annotations only started. I have recently downloaded
the read-only license of JCK so I will hopefully have some numbers soon.
This would ofcourse be done by visual inspection of the test cases since
compilation is prohibited....

>>* we're a little worried about continued support. What are
>> your plans after completing your PhD? Is it likely you will
>> be able to continue JastAdd related work? [This may be
>> a chicken-and-egg question, as successful use in abc could
>> easily lead to more grants?]
>>
>>
>>
I will continue to work on JastAdd in one way or another. Hopefully I
can continue doing research in academia and even if I go to industry I
will make sure to continue supporting the tools at least part-time.

best regards
/Tobbe

==== 8.1.3-superclass-5 A superclass must be accessible FAILED
==== Contents of test case:

    compile [saveas p1/T813s5a.java {
package p1;
public class T813s5a {
    protected static class Inner {}
}
}] [saveas T813s5b.java {
class T813s5b extends p1.T813s5a.Inner {}
}]

---- Result was:
PASS
---- Result should have been:
FAIL
==== 8.1.3-superclass-5 FAILED

==== 15.9.5.1-superconstructor-7 An anonymous class may refer to
        an inaccessible type mentioned as a superconstructor parameter
FAILED
==== Contents of test case:

    compile [saveas p1/T15951s7_2.java {
package p1;
class T15951s7_1 {}
public class T15951s7_2 {
    public static T15951s7_1 get() { return new T15951s7_1(); }
    public static class Inner extends T15951s7_1 {}
    public T15951s7_2(T15951s7_1 s) {}
}
    }] [saveas T15951s7_3.java {
import p1.T15951s7_2;
class T15951s7_3 {
    {
        new T15951s7_2(null);
        new T15951s7_2(null) {};
        new T15951s7_2(T15951s7_2.get());
        new T15951s7_2(T15951s7_2.get()) {};
        new T15951s7_2(new T15951s7_2.Inner());
        new T15951s7_2(new T15951s7_2.Inner()) {};
        new T15951s7_2(new T15951s7_2.Inner() {});
        new T15951s7_2(new T15951s7_2.Inner() {}) {};
    }
}
    }]

---- Result was:
FAIL
---- Result should have been:
PASS
==== 15.9.5.1-superconstructor-7 FAILED

==== 15.12.2.2-ambiguous-24 The most specific method is chosen,
        regardless of return type or static considerations FAILED
==== Contents of test case:

    empty_class T151222a24 {
        static int m(long i) { return 0; }
        int m(int i) { return 0; }
        // int m(int) is chosen and fails, even though int m(long) would
work
        static int i = m(0);
    }

---- Result was:
PASS
---- Result should have been:
FAIL
==== 15.12.2.2-ambiguous-24 FAILED

==== 15.17.1-double-14 Floating-point * follows round-to-nearest,
        even with denorms, known bug in Sun's javac FAILED
==== Contents of test case:

    constant_expression T15171d14 {8.578459548793971E-162 *
2.512418001798401E-147
            == 2.155267619808936E-308} {6.946121092140867E-162 *
2.669444126910801E-147
            == 1.8542282154226677E-308}

---- Result was:
FAIL
---- Result should have been:
PASS
==== 15.17.1-double-14 FAILED

==== 15.18.1-float-6 conversion of float to String must use as few
        digits after decimal as produce the same float again by
rounding FAILED
==== Contents of test case:

    constant_expression T15181f6 {"" + 123456768f == "1.2345677E8"}
{"" + 123456776f == "1.23456776E8"} {"" + 123456784f == "1.2345678E8"}
{"" + 123456792f == "1.2345679E8"} {"" + 123456800f == "1.234568E8"}
{123456768f + "" == "1.2345677E8"} {123456776f + "" == "1.23456776E8"}
{123456784f + "" == "1.2345678E8"} {123456792f + "" == "1.2345679E8"}
{123456800f + "" == "1.234568E8"}

---- Result was:
FAIL
---- Result should have been:
PASS
==== 15.18.1-float-6 FAILED

==== 15.18.1-float-8 conversion of float to String switches from
        plain to exponent at 1e-3. Trailing 0's are not permitted. FAILED
==== Contents of test case:

    constant_expression T15181f8 {"" + .001f == "0.001"} {"" +
.000999998f == "9.99998E-4"} {.001f + "" == "0.001"} {.000999998f + ""
== "9.99998E-4"}

---- Result was:
FAIL
---- Result should have been:
PASS
==== 15.18.1-float-8 FAILED

==== 15.18.1-float-11 conversion of float to String prints the
        closest decimal string to the exact value, even on denorms FAILED
==== Contents of test case:

    constant_expression T15181f11 {"" + 1e-43f == "9.9E-44"} {1e-43f +
"" == "9.9E-44"}

---- Result was:
FAIL
---- Result should have been:
PASS
==== 15.18.1-float-11 FAILED

==== 15.18.1-float-12 conversion of float to String must use as few
        digits after decimal as produce the same float again by
rounding FAILED
==== Contents of test case:

    constant_expression T15181f12 {"" + 4294967808f == "4.294968E9"}
{4294967808f + "" == "4.294968E9"}

---- Result was:
FAIL
---- Result should have been:
PASS
==== 15.18.1-float-12 FAILED

==== 15.18.1-double-8 conversion of double to String must use as few
        digits after decimal as produce the same double again by
rounding FAILED
==== Contents of test case:

    constant_expression T15181d8 {"" + 40000000000000000. == "4.0E16"}
{"" + 40000000000000008. == "4.000000000000001E16"} {"" +
40000000000000016. == "4.000000000000002E16"} {"" + 40000000000000024.
== "4.0000000000000024E16"} {"" + 40000000000000032. ==
"4.000000000000003E16"} {"" + 40000000000000040. ==
"4.000000000000004E16"} {40000000000000000. + "" == "4.0E16"}
{40000000000000008. + "" == "4.000000000000001E16"} {40000000000000016.
+ "" == "4.000000000000002E16"} {40000000000000024. + "" ==
"4.0000000000000024E16"} {40000000000000032. + "" ==
"4.000000000000003E16"} {40000000000000040. + "" == "4.000000000000004E16"}

---- Result was:
FAIL
---- Result should have been:
PASS
==== 15.18.1-double-8 FAILED

==== 15.18.1-double-10 conversion of double to String switches from
        plain to exponent at 1e-3. Trailing 0's are not permitted. FAILED
==== Contents of test case:

    constant_expression T15181d10 {"" + .001 == "0.001"} {"" +
.0009999999999999998 == "9.999999999999998E-4"} {.001 + "" == "0.001"}
{.0009999999999999998 + "" == "9.999999999999998E-4"}

---- Result was:
FAIL
---- Result should have been:
PASS
==== 15.18.1-double-10 FAILED

==== 15.18.1-double-11 conversion of double to String produces the
        shortest string that parses back to the same double FAILED
==== Contents of test case:

    constant_expression T15181d11 {"" + 9.999999999999999e22 ==
"1.0E23"} {9.999999999999999e22 + "" == "1.0E23"}

---- Result was:
FAIL
---- Result should have been:
PASS
==== 15.18.1-double-11 FAILED

==== 15.18.1-double-13 conversion of double to String prints the
        closest decimal string to the exact value, even on denorms FAILED
==== Contents of test case:

    constant_expression T15181d13 {"" + 1e-323 == "9.9E-324"} {"" +
1e-322 == "9.9E-323"} {1e-323 + "" == "9.9E-324"} {1e-322 + "" ==
"9.9E-323"}

---- Result was:
FAIL
---- Result should have been:
PASS
==== 15.18.1-double-13 FAILED

Received on Fri Aug 19 15:14:53 2005

This archive was generated by hypermail 2.1.8 : Sat Aug 20 2005 - 02:50:14 BST