Log of the #nice channel on irc.freenode.net

* arjanb joins08:56
* bonniot joins09:58
hi
<arjanb>hi11:07
could you take a look at the parsing of the .. operator i have run out of ideas to fix it12:24
<bonniot>what is the problem12:42
is see there is already ".." in the parser
1 .. 2 seems to be parsed correctly12:44
also x..y
i think 1..2 does not work because of floating point literals12:45
if we want that, we could forbid float of the form 1. and require 1.0 (which is nicer anyway, i think)12:49
--- src/bossa/parser/Parser.jj 22 Aug 2003 13:36:40 -0000 1.204
+++ src/bossa/parser/Parser.jj 28 Aug 2003 10:48:47 -0000
@@ -240,7 +240,7 @@
TOKEN: /* Floating point literals */
{
< FLOATING_POINT_LITERAL:
- (["0"-"9"])+ "." (["0"-"9"])* (<EXPONENT>)? (["f","F","d","D"])?
+ (["0"-"9"])+ "." (["0"-"9"])+ (<EXPONENT>)? (["f","F","d","D"])?
| "." (["0"-"9"])+ (<EXPONENT>)? (["f","F","d","D"])?12:50
| (["0"-"9"])+ <EXPONENT> (["f","F","d","D"])?
| (["0"-"9"])+ (<EXPONENT>)? ["f","F","d","D"]
<arjanb>agreed 1. is ugly12:51
thanks for finding the problem
so for (x : 1..10) ... works now12:58
<bonniot>:-)13:10
<arjanb>is your dissertation finished? you seem to have time again to work on the compiler13:13
now i get a verifyerror13:29
class Bar<T> extends AbstractList {
isEmpty() = false;
}
void main(String[] args)
{
Collection<String> b = new Bar();
}
D:\Nice>java -jar test.jar
Exception in thread "main" java.lang.VerifyError: (class: testbug/Bar, method: isEmpty signature: (
Z) Illegal type in constant pool
at testbug.fun.main(D:\Nice\.\testbug:8)
and if i change the class to class Bar<T> extends AbstractCollection { then i get no error 13:31
strange
<bonniot>the bytecode calls List.isEmpty when it should call AbstractCollection.isEmpty13:53
<arjanb>i don't understand13:55
i see now looking at the generated code13:56
but that call is not reachable13:58
<bonniot>reachability does not matter when verifying bytecode14:01
<arjanb>so we need to optimize that branch away in nicec14:03
<bonniot>i think we should fix the bug first14:04
since it might also happen in cases that are not optimizable
<arjanb>true
<bonniot>it seems coverage test for java methods iwth multiple dispatch does not take into account existing methods:14:11
// PASS
Collection<String> b = new Bar();
/// Toplevel
class Bar<T> extends AbstractList<T>
{
removeAll(other@Bar) = false;
}
(that's an unrelated bug)
<arjanb>but java methods doesn't get coverage tested at all now?14:15
<bonniot>they are tested when there are nice implementations14:17
<arjanb>but i see nowhere that java method implementations are added to the alternatives14:25
<bonniot>i fixed the code generation bug14:28
the method was found from an interface, before looking in the superclass
there is Dispatch.register(JavaMethod)14:29
<arjanb>but that's only the method definition14:30
<bonniot>yes14:31
// For java methods, we are only concerned with cases14:32
// where the first argument is a Nice class.
this is why it is still incomplete
i'm not sure we need to enter java implementations in the alternatives14:34
we could probably handle them specially
especially since we know they have a very special form: dispatch on the first arg only14:35
<arjanb>it might be needed if one add methods like removeAll(@ArrayList, @MyList)14:36
<bonniot>that's not possible, since ArrayList is not a Nice class14:38
<arjanb>right14:42
but then we need to check for that14:44
<bonniot>for what?14:46
<arjanb>that you don't add methods for java classes that already have an implementation14:47
<bonniot>that's already checked14:53
<arjanb>do you have an development version? the fix doesn't seem to work here15:24
i have to go now i will see this evening if it works15:36
* arjanb leaves
* arjanb joins17:41
<bonniot>what doesn't work?17:47
<arjanb>i still get the verify error even with your fix17:48
<bonniot>on what souce?17:50
source
<arjanb>mine with the change you made today17:51
<bonniot>this works fine:17:52
class Bar<T> extends AbstractList
{
isEmpty() = false;
}
void main(String[] args)
{
Collection<String> b = new Bar();
}
are you sure you use the fix?
<arjanb>yes which files have you changed?17:53
<bonniot>gnu.bytecode.ClassType and bossa.link.Compilation17:54
<arjanb>bossa.link.Compilation isn't commited then i think
<bonniot>you're right17:56
done
<arjanb>ok it works now18:03
but we need to find another testcase
that one extends abstract list without implementing all abstract methods18:04
so if i implement methods for range that the coverage test will fail18:05
there are a few testcase more with the same problem18:08
<bonniot>Bar is already in this case, isn't it18:15
?
<arjanb>yes18:16
[nicec] defaultpackage21: generating code18:20
[nicec] defaultpackage21: linking
[nicec]
[nicec] F:\Nice\classes\nice\lang\package.nicei: line 196, column 35:
[nicec] Method <Any T> java.util.ListIterator<T> listIterator(java.util.List<T>, int) is not c
ompletely covered:
[nicec] no alternative matches (defaultpackage21.Bar, nice.lang.byte)
<bonniot>did you change something?18:22
<arjanb>i have a Range class in nice.lang that implement the listIterator method18:23
<bonniot>ah ok18:25
<arjanb>the listIterator methods isn't abstract in AbstractList18:26
what should i do with it now18:29
commit the range thing and just mark these cases as bug18:31
?
<bonniot>is listIt implemented?18:36
<arjanb>for both range and abstractlist18:38
<bonniot>how many failures are there?18:40
<arjanb>at least 418:41
<bonniot>just testcases?18:44
<arjanb>yes18:45
<bonniot>bossa.link.Dispatch line 247 is suppose to handle this case18:46
<arjanb>i made a little mistake in range so just 2 testcases that fail18:49
[file defaultpackage239.defaultpackage239_main.nice] class A {}18:50
[file defaultpackage239.defaultpackage239_main.nice] void do_something( List<A> x ) {}
[file defaultpackage239.defaultpackage239_main.nice] class B<A T | A <: T> extends LinkedLis
t<T> {}
[file defaultpackage239.defaultpackage239_main.nice] add(x@B, o) {
[file defaultpackage239.defaultpackage239_main.nice] do_something(x);
[file defaultpackage239.defaultpackage239_main.nice] return super;
[file defaultpackage239.defaultpackage239_main.nice] }
[nicec] F:\Nice\classes\nice\lang\package.nicei: line 195, column 35:18:51
[nicec] Method <Any T> java.util.ListIterator<T> listIterator(java.util.Collection<T>) is not
completely covered:
[nicec] no alternative matches (defaultpackage239.B)
[nicec]
[nicec] F:\Nice\classes\nice\lang\package.nicei: line 195, column 35:
[nicec] The implementation test failed for method listIterator
this one is not an incorrect testcase
<bonniot>i know why18:52
the reason is the java.util methods are taken from gj.jar to have the generic types18:53
but in gj.jar there is no code, so all methods are abstract
therefore the compiler thinks that there is no concrete implementation, for instance in AbstractList
one solution would be to recreate a gj.jar with the same signatures, but that respects which methods are abstract and which are not19:01
other ideas?19:06
<arjanb>is it possible not to use any gj.jar but do everthing with retypings?19:14
it has no use to support the old version of gj19:15
<bonniot>yes, we could have only retypings19:16
wdym the old version?
<arjanb>the signatures nicec can read are obsolete now19:17
<bonniot>the format has changed?
<arjanb>yes due to the variance things19:18
<bonniot>was variance officially included?
<arjanb>not officially19:19
<bonniot>so nothing is sure yet19:20
anyway
<arjanb>but i haven't seen any sign that they want to throw it out
and the beta comes in november
<bonniot>do you think it would be lots of work to retype java.util?
(they said variance was there only as a test, and that they hadn't decided yet)19:21
<arjanb>i think over half of the methods are retyped already
<bonniot>good. could you look into this?19:22
<arjanb>you mean that i add missing retypings now so that you can remove gj.jar?19:23
<bonniot>yep19:26
<arjanb>ok than i commit range first19:33
how to retype an inner class like map.entry?
<bonniot>you might be able to use Map$Entry19:37
* bonniot leaves19:44
* bonniot joins20:44
does the retyping goes ok?20:45
<arjanb>not started yet20:46
there are questions on the forum and something on the wiki about visibility20:49
<bonniot>i thought you had a problem with map.entry20:50
<arjanb>yes but i'm fast distracted20:53
so i was looking whether other languages with multiple dispatch that have visibility modifiers i didn't find any20:54
<bonniot>i think you mixed up the <...> in Map.Entry<String, Cell> when you modified the code example21:09
you have to use < for <
<arjanb>i see nothing wrong21:10
<bonniot>it's in the use of for ( : )21:13
<arjanb>what's the problem21:14
both ie and phoenix display it correct
<bonniot>it's not displayed correctly in the diff21:17
but it is ok in the main page, because it is inside verbatim
so that's OK
is the semantics of visibility for MM what has been blocking you to start the implementation of visibility?21:18
<arjanb>no21:19
<bonniot>ok. tell me how the retyping is going...21:21
<arjanb>it's a lot of typing21:26
this method has an ugly type:21:40
<T,U,V | T <: V, V <: ?U > ?U[] toArray(Collection<T>, V[]) = native Object[] Collection.toArray(Object[]);
the class Comparator could be a covariant class what do you think?22:10
i mean contravariant22:12
<bonniot>what dpes the return elements of toArray have to be possible null?22:48
for Comparator, yes it seems contravariant22:51
<arjanb>see this classpath implementation of toArray:22:54
public Object[] toArray(Object[] a)
{
int size = size();
if (a.length < size)
a = (Object[]) Array.newInstance(a.getClass().getComponentType(),
size);
else if (a.length > size)
a[size] = null;
Iterator itr = iterator();
for (int pos = 0; pos < size; pos++)
a[pos] = itr.next();
return a;
}
<bonniot>i see: if the array is too big, null is put at the end22:59
so what is wrong with the type?
<arjanb>this is just a ugly method thus the type makes it useless23:01
type is still wrong i think maybe this is better23:03
<T,U,V | !T <: ?V, ?V <: ?U > ?U[] toArray(Collection<!T>, ?V[]) = native Object[] Collection.toArray(Object[]);
<bonniot>it should work with Collection<?T>23:07
<arjanb>but with !T it makes more sense javadoc:23:08
If this collection fits in the specified array with room to spare (i.e., the array has more elements than this collection), the element in the array immediately following the end of the collection is set to null. This is useful in determining the length of this collection only if the caller knows that this collection does not contain any null elements.)
<bonniot>i know. but since you can always check the size of the original collection, this is not very important23:12
good luck... good night!23:23
<arjanb>good night23:24
* bonniot leaves23:25

Generated by Sualtam