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

Using timezone: Central European Time
* magnus-- leaves00:36
<arjanb>any succes with the arrays?01:50
good night02:34
* arjanb leaves
* daniel__ joins11:11
* bonniot leaves11:19
* bonniot leaves11:54
* Bluelive leaves
* bonniot joins11:56
* Bluelive joins
* arjanb joins12:47
<bonniot>hello arjan13:31
how are line numbers doing? ;-)
<arjanb>i didn't look at it14:13
<bonniot>you could get source-lines in nice.lang working?14:18
<CIA-3>03bonniot * 10Nice/src/nice/tools/code/LiteralArrayProc.java: Simplified the bytecode generation of literal arrays (with the same output).14:25
<arjanb>it moved to nice.lang but i didn't look at how to put the try cath in main14:34
<bonniot>ok14:39
i think i got arrays working at last14:42
two know bugs fixed, and no regression14:43
this part is hard because we are working around the JVM limitations...14:44
<arjanb>does it fix the tuple variant of it too?
<bonniot>but I could get it work by using more info at compile time, without adding more checks at runtime, so performance will not suffer, and is actually maybe better in some cases14:45
it fixed two bugs in the testsuite
one of them has tuples too
i think it's not exactly the same as the reported one, i will check14:46
<arjanb>http://sourceforge.net/tracker/index.php?func=detail&aid=761629&group_id=12788&atid=112788
i have an additional testcase for it:14:50
(int[], int[]) t1 = ([1, 2], [3, 4]);
(List<int>, List<int>) t2 = t1;
(List<int> la, List<int> lb) = t2;
assert la[0] == 1;
assert la[1] == 2;
assert lb[0] == 3;
assert lb[1] == 4;
<bonniot>no, the original case still doesn't work14:54
your testcase now passes, though
<arjanb>that's odd14:56
<bonniot>the original case is more complex because it has three levels of lists/tuples, and yours has two15:01
<arjanb>i see15:03
but what to do with array literals in more than 2 levels of lists/tuples?15:04
i think it will be really ugly to fix15:05
<bonniot>why?15:08
<arjanb>List<List<int[]>> la = ...15:10
List<List<List<int>>> lb = la;
<bonniot>that's not well typed, that's unsafe15:11
you could add an ArrayList<int> deep inside lb, and that breaks la15:12
<arjanb>right replace the outer 2 list with tuples
<bonniot>then there should be no problem15:13
<arjanb>then it would require to unpack all the tulples and wrap the array in rawarray15:14
<bonniot>the difficulty is when you have a literal array to decide what bytecode component type to declare for the generated array
no, the array will be wrapped when it is needed only15:15
<arjanb>covariance doesn't play well with coercion
<bonniot>you can try, that should already be working
<arjanb>have you committed the fix?15:17
<bonniot>no. what i'm saying is that your above example should work in the current version
* bonniot is away: ~20 min15:18
<arjanb>this one doesn't work in current version:15:21
((int[], String) , String) t1 = (([1, 2], "abc"), "xyz");
((List<int>, String), String) t2 = t1;
((List<int>, String) t3, String s1) = t2;
(List<int> la, String s2) = t3;
assert la[0] == 1;
assert la[1] == 2;
<bonniot>I guess that's the literal part that is the pb15:45
* bonniot is back (gone 00:26:53)
<arjanb>i don't think so15:46
the problem is when should the wrapping of the array happen15:49
<bonniot>please commit the testcase15:52
<arjanb>both?15:53
<bonniot>ok15:54
<CIA-3>03arjanb * 10Nice/testsuite/compiler/expressions/arrays/compilation.testsuite: Added 2 testcases for coercion of arrays in nested arrays/tuples.16:03
* CIA-3 leaves18:25
* CIA-3 joins18:26
* CIA-3 leaves18:28
* CIA-3 joins
* CIA-3 leaves18:29
* CIA-3 joins18:37
<bonniot>you were right, your last testcase fails independently of the literal array18:53
so that will be a different fix
apart from that, the two reported bugs and all the other testcases now pass18:54
do you think exceptions can be ready soon? it would be nice to have them in 0.9.618:58
* bonniot is away: for the evening18:59
<CIA-3>03arjanb * 10Nice/stdlib/nice/lang/source-lines.nice: Make source lines fixup more robust.22:36
* bonniot is back (gone 04:13:20)23:12
<arjanb>try catch is inserted in fun.main but the testsuite doesn't handle runtime exception that are eaten23:16
<bonniot>that's why it should be in dispatch.fun as we discussed, no?23:24
(what do you do in the catch?)23:25
in dispatch.main, i meant
<arjanb>only print stacktrace
<bonniot>and then? continue execution?23:26
<arjanb>yes or i can exit
<bonniot>in dispatch.main ?23:28
<arjanb>in fun.main
<bonniot>yes, but that's not OK23:38
<arjanb>:(23:40
<bonniot>we discussed that before23:41
<arjanb>i know23:42
<bonniot>the other possibility is to investigate wrapping the exception23:43
it seems that the jvm understands that gnu.mapping.WrappedException is wrapping an exception, maybe because of the getCause() method23:46
even though it does no implement any JDK 1.4 only feature I think
<arjanb>getCause() is 1.423:48
<bonniot>ok, but any class can declare a method getClause an run on JDK 1.3 or earlier. which is good :-)23:53
but i would think the exception will not look perfect if it is wrapped, because it seems the jvm wants to print both the wrapper and the wrapped one23:54
<arjanb>right you want to complete stacktrace of the wrapped one23:57
<bonniot>ok, see you tomorrow00:09
* bonniot leaves