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

Using timezone: Central European Time
<arjanb>daniel: have you thought about overriding and constracts?00:45
<bonniot>an override must not add any precondition, yes, that should be forbidden01:14
it is valid to add post-conditions, though
atm contracts are lost for the overrides
but not for implementations :-)01:18
one option would be to compile the precondition independently from the dispatch method01:19
the dispatch method would call it, and overrides too01:20
another is to regenerate the contract checking in overrides
<arjanb>the first would be usefull for the old function01:21
<arjanb>i see no way to turn calculating and storing of the old value on/off in a single method without duplicating the dispatch part01:29
<bonniot>why couldn't the computation of the old value be inside the if before dispatch, and then checked after dispatch?01:32
<arjanb>var x;01:36
if (assertOn)
x = ...;
... dispatch things
if (assertOn)
checksomething(x);//x not initialized
<bonniot>just put null or 0 in x
<arjanb>right i'm getting sleepy01:38
<bonniot>it would be useful to add some testcases about overrides and contracts01:48
<arjanb>i'll look at contract things tomorrow01:51
it seems i have polymorphic inference working now...
btw where did you get the idea for option types from?02:14
<bonniot>from thinking about how null can be handled safely02:16
there is also the option type in ML, only that one does not support !T <: ?T
<arjanb>it seems that the non-null type paper has reinvented the wheel but for C#02:21
<bonniot>yes. it's mostly complicated because of the constructor semantics, as you said02:24
good night02:54
<arjanb>good night02:55
* bonniot leaves03:00
* magnus-- leaves03:03
* arjanb leaves03:05
* rubber joins09:18
hi all
* arjanb joins12:08
hello rubber12:10
<arjanb>solved that not declared error or?12:24
<rubber>No :(12:26
Here's my last stand:
package testa;
import java.util.*;
public class Arraz
public Object getA()
return new ArrayList();
package testb;
import testa.*;
import java.util.*;
Object getA() = native Object Arraz.getA();
void main(String[] args) {
Arraz a = new Arraz();
//Collection<Object> al = getA(a);
Object o = getA(a);
Native method getA has not the same number of parameters in Java (1) and in Nice (0)12:27
What's wrong here?
Same for more special retypings...
I've tried:
Object getA() = native Object Arraz.getA(Arraz);12:28
<arjanb>the compiler can't guess the type params
<rubber>That gave me something like:
Ignored retyping because no method named getA with 1 arguments was found in class testa.Arraz
No type params... I'm now not returning a ArrayList, but an object.12:29
... well, the object is an ArrayList...
<arjanb>class Arraz<T> = native testa.Arraz;12:30
<T> ArrayList<T> getA(Arraz<T>) = native ArrayList Arraz.getA();12:31
<rubber>Class testb.Arraz has no constructor with 1 type parameters.12:32
<arjanb>what's the constructor in java code?12:33
<rubber>No, default constr.12:34
so, it should be public Arraz() {}
<arjanb><T> Arraz<T> Arraz() = native new Arraz();12:35
<rubber>Ok, that seems to work... Why do I need that much retypings?
And why do I need: class Arraz<T> = native testa.Arraz;12:36
Up to now, I've used cast instead of the retypings...12:38
...but in the latest compiler there is a DEADLOCK with my code. Something really hard. I've not tracked it down up to now, but I'm working on it.12:39
<arjanb>the problem is that methods which have a class with type params as argument or return type are ignored by the compiler
<rubber>boring. But now, that I know it, Ok. The error messages are not good. It simply says: No method like that.12:40
<arjanb>i think that warning should be made non silent12:41
<rubber>Would be good.12:45
<arjanb>a potential cause of the deadlock is the change that reorders the initialization of global vars/constants12:46
* bonniot joins12:48
<arjanb>that change has been made on 5 march you could try to make a compiler from the cvs just before that12:49
Ok, I'll do so.... Now I'll leave for lunch...
<bonniot>(just read the logs)12:52
is any retyping needed for that code?
Object getA() = native Object Arraz.getA();12:53
that's wrong because there is one argument
should be:
Object getA(Arraz) = native Object Arraz.getA();
but i don't think it'sneeded at all, is it?12:54
arjan, did you try?
<arjanb>but it should return an ArrayList i think
<bonniot>it it returns an ArrayList then yes12:55
currrently the javacode returns Object
arjanb: when a method is ignored and then you try to use it, you get a warning, it is not silent anymore13:02
<arjanb>that seems not the case with methods ignored because of unknown type params13:03
<bonniot>right, that's when the bytecode method does not exist13:08
now that we have Object, couldn't we import List as List<Object> by default?13:09
<arjanb>mostly the type param is related to some other type param13:11
<bonniot>yes, but we cannot guess that13:12
using Object would give a good default, and then if the user can see that the method exists, only its precise type is not known
<arjanb>i think defaulting to Object is ok when it's treated as an ignored retyping13:13
so that you get a warning at usage
<CIA-1>03bonniot * 10Nice/src/bossa/syntax/RetypedJavaMethod.java: Typos.13:14
<bonniot>yes, there could be a warning at usage13:15
i'm finishing the poly lets atm, so i won't look at that now13:18
<arjanb>and for the deadlock what do you think that can be the cause?13:19
the version from 5.3. also halts.
<bonniot>what is the deadlock?
<rubber>Well, dunno. The compiler starts compiling and then halts. No error no ntohiung...13:21
<bonniot>can you get a stacktrace?
<arjanb>tried pressing ctlr-C or something?13:22
<bonniot>C-c would stop it, no?
to get the stacktrace it's C-A-\ if i remember correctly13:23
<rubber>ah, yes, what was the ... yes, ...I'll try
<bonniot>on unix
<rubber>Ok, quite a lot:13:24
Full thread dump Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode):
"Signal Dispatcher" daemon prio=1 tid=0x0808fb28 nid=0x13b8 waiting on condition [0..0]
"Finalizer" daemon prio=1 tid=0x0808a698 nid=0x13b6 in Object.wait() [bf3ff000..bf3ff918]
"Reference Handler" daemon prio=1 tid=0x08089a28 nid=0x13b5 in Object.wait() [bf5ff000..bf5ff918]
Ok, too much... I'll upload a small file...13:25
<bonniot>i can be useful to get a few of them one after the other, to see if something is happening, or if there is a real deadlock
but no stack overflow?13:28
<rubber>No. Only that.
It holds... Have tried to let it run, but runs to 5 minutes... nothing. normally I expect 30 seconds for all.13:29
...after 5 minutes I stop...
<bonniot>it might be an issue with finding specialized methods
<rubber>Ok, now also out2 out3 out4 out513:30
<arjanb>out2 is strange13:31
<rubber>away for 15 minutes...13:33
<arjanb>maybe multiple compilation in one vm or the vm is doing something strange with finalization13:37
<bonniot>are there multiple compilations in this case?13:39
<arjanb>which vm do you use rubber?13:41
at java.lang.Object.wait(Native Method)13:42
- waiting on <0x44bd7d40> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
- locked <0x44bd7d40> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
this looks like a bug in the ReferenceQueue implementation to me
<bonniot>rubber: please try compiling using http://nice.sf.net/nice-dbg.jar13:47
it will give useful debug info about this case13:48
<rubber>java version "1.4.2"13:50
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)
<bonniot>yes, i think those two add methods are confusing the override finder...13:53
<rubber>Why now? It has worked up to: 13:54
Nice compiler version 0.9.7 (build 2004.02.28, 08:35:56 UTC)
<bonniot>that might be before overrides were introduced, no?
<rubber>I've also encountered some real bad benchmarks. Going to ask, how to improve...13:55
But I assume yes.
package dispatchtest;
public class TTT {
?Object o = null;
void dosomething(TTT t) {
package dispatchtest;
public class Test {
public static void main(String[] args) {
if (args.length == 1) {
long start = System.currentTimeMillis();
int i = Integer.parseInt(args[0]);13:56
TTT tt = new TTT();
while (i-- > 0) {
* rubber leaves
* rubber joins
too much :(
long length = System.currentTimeMillis() - start;
System.out.println("Execution needed "+length+" millis");
start = System.currentTimeMillis();
i = Integer.parseInt(args[0]);
java.util.Hashtable t = new java.util.Hashtable();
while (i-- > 0) {
btw. second second package is again JAVA....
<bonniot>(why did you write it in Java?)
<rubber> length = System.currentTimeMillis() - start;
System.out.println("Execution needed "+length+" millis");
Now take the following result:13:58
java -classpath ../targets:../nice-compile/nice.jar dispatchtest.Test 1
Execution needed 7 millis
Execution needed 0 millis
java -classpath ../targets:../nice-compile/nice.jar dispatchtest.Test 10
Execution needed 7 millis
Execution needed 0 millis
java -classpath ../targets:../nice-compile/nice.jar dispatchtest.Test 100000
Execution needed 12 millis
Execution needed 3 millis
That is really really bad, or not? Up to 1000 simple calls, I get a duration that is quite heavy for one dispatch...13:59
It becomes even worse, if the count of methods to dispatch on, becomes higher.14:00
<bonniot>could you try putting the java calls before the nice calls?14:01
<rubber>what do you think?
ok, I'll try.
java -classpath ../targets:../nice-compile/nice.jar dispatchtest.Test 114:02
Execution needed 0 millis
Execution needed 7 millis
java -classpath ../targets:../nice-compile/nice.jar dispatchtest.Test 10
Execution needed 0 millis
Execution needed 7 millis
java -classpath ../targets:../nice-compile/nice.jar dispatchtest.Test 10000
Execution needed 1 millis
Execution needed 13 millis
what do you think?14:03
<bonniot>i suspect the overhead comes from loading dispatch for the first time
<rubber>Yes, but 7 millis?!
<bonniot>it's a constant cost, no?14:04
<arjanb>rubber try running that with java -Xprof and see where the time goes14:05
<bonniot>you could try calling a first time before the benchmark, to force class loading
Hashtable is in the core classes, so it's cheating ;=)14:06
it might already be loaded before the benchmark
<rubber>java -Xprof -classpath ../targets:../nice-compile/nice.jar dispatchtest.Test 1000000014:09
Execution needed 163 millis
Execution needed 118 millis
Flat profile of 0.33 secs (14 total ticks): main
Interpreted + native Method
7.1% 0 + 1 java.io.UnixFileSystem.getBooleanAttributes0
7.1% 0 + 1 java.io.UnixFileSystem.getLength
14.3% 0 + 2 Total interpreted
Compiled + native Method
35.7% 5 + 0 dispatchtest.dispatch.dosomething
28.6% 4 + 0 java.util.Hashtable.size
21.4% 3 + 0 dispatchtest.Test.main
85.7% 12 + 0 Total compiled
Flat profile of 0.01 secs (1 total ticks): DestroyJavaVM
Thread-local ticks:
100.0% 1 Blocked (of total)
Global summary of 0.42 seconds:
100.0% 19 Received ticks
it starts jit if i > 100000...
<bonniot>in this the difference is much smaller, no?14:10
35 vs 28
<rubber>yes, if compiled, than it becomes nearly equal...14:11
but I felt, that java is faster....
<bonniot>did you try a first call before starting the clock?
<rubber>...so I did some benchmarking...
<bonniot>i think that's the classloading14:12
(microbenchmarking is tricky, especially with JIT)
<rubber>java -Djava.compiler=NONE -Xprof -classpath ../targets:../nice-compile/nice.jar dispatchtest.Test 1000000014:14
Execution needed 1366 millis
Execution needed 1623 millis
Ok, so now it's quite fair again.
java -Djava.compiler=NONE -Xprof -classpath ../targets:../nice-compile/nice.jar dispatchtest.Test 10
Execution needed 0 millis
Execution needed 0 millis
<bonniot>it could be useful to put such benchmark on the wiki, since other peoplemight run into this...14:21
<arjanb>nice compiles with quite a few static methods and these are easily inlined by the jit but that isn't triggered before 1000s of executions14:24
<bonniot>which does not really matter, because 1000s of executions are unoticablea ;-)14:26
* daniel__ joins
* bonniot leaves14:28
rubber: do Queue and MyList have a common parent?14:30
<rubber>interface Queue<T>14:31
void add(T element);
void add(MyList<T> list);
<T> add(list) = list.foreach(T e => this.add(e));
T get();
int size();
boolean isEmpty();
void clear();
interface MyList<T> {
T getElementOf(int index);
T getFirst();
T getLast();
int getIndexOf(T element);
int getSize();
void add(T element);
void clear();
void foreach(T->void);
void forbreak(T->void);
void insert(int index, T element);
void removeAt(int index);
void remove(T element);
boolean isEmpty();
boolean contains(T element);
that seems to reproduce it ;-)14:33
<rubber>Yes? :) Good!
<bonniot>quite simple, once we know what to look for :-)
<rubber>And you already know what causes the hold?14:34
<bonniot>might be because the second argument is once T and once Foo<T>14:35
simple workaround: rename add into addAll (like in Collection)
or use an earlier compiler ;-
What about the error with the T.... 14:38
<bonniot>which one?
<rubber>...ok, that was a good description of the error :) :l:
...the error that forces me to use -R all the time...14:39
it was something like:
class SortedLiListImpl<T> extends LiListImpl implements SortedLiList {
(T, T) -> int comparator = (T t1, T t2) => 0;
setComparator(f) = this.comparator = f;
that does not work without -R 14:40
You found a even smaller testcase for it.
<bonniot>good :-)
i had forgotten. you should open a bug report if you don't work on it immediately ;-)14:41
I mean, I should work on it... You're kidding...
<bonniot>sorry, i meant: if we don't ;-)14:42
<rubber>Do you remind the testcase?
<bonniot>not by heart, no! that's why a bug report is good14:43
i remember about it, yes, but not the precise code
and now you have found a simpler one?
<rubber>No, you have found the simple one... :)14:44
Or was it me... I don't remind either.
<bonniot>i'm confusing you/me, you/we today ;-)14:45
<bonniot>That should be a testcase for the second (still not working):14:57
package com.condor_edv.e3m.util.list;
class StackImpl<T> {
private T -> boolean filter = (T e) => true;
so it was you :-)
Cool, that you found it.
<bonniot>i think i have the right fix for this one...16:07
<rubber>Whcih one? Last one here in the log?16:09
<bonniot>yes, the "T" bug
<rubber>Great. 16:15
<bonniot>it should save you some recompile time, right? ;-)16:17
<rubber>Yes... But only iff the other bug is also solved.16:18
<bonniot>you could also backport the fix to an earlier version. depends how important it is for you16:24
(only two classes are modified)
<arjanb>so the deadlock thing is harder to fix?16:26
<rubber>it would be nice to have.16:27
<bonniot>i haven't investigated that one yet
but the workaround is not too hard, is it?16:28
<rubber>the workaround was addAll... I'll try if that was the only occurance...
<rubber>Ok, workaround seems to work... Now I need the two-class-patch... :)16:32
<bonniot>i'm commiting in a few seconds... ;-)
<rubber>seconds... 1 2 316:35
<CIA-1>03bonniot * 10Nice/ (3 files in 2 dirs): 16:36
Put type parameters in the type scope of methods, in case the default values
of formals parameters need it (anonymous functions for instance).
<bonniot>ok, that was rather a few minutes ;-)
<rubber>updated, now compiling.16:41
patch seems to work :)16:46
it is great, not to recompile every package one each compile...
<arjanb>rubber do you have other bugs/ideas?16:53
<rubber>I haven't followed all the new things with override but I have used the custom constructors a bit.
<arjanb>no warnings for overrides during compilation?16:55
<rubber>I have dropped in the last weeks some parts of my nice code, since it has become obsolete from javacc and jjtree.
Quite a few...16:56
...haven't looked at them closely...
<rubber>list.nice: line 8, column 10:
This method overrides <T> nice.lang.void display(com.condor_edv.e3m.util.list.MyList<T> list)
You should make this explicit, either by omitting the return type
or by using the 'override' keyword
something like that...
what to do now?16:58
<T> void display(MyList<T> list) {
<T> void display(LiList<T> list) {
interface MyList<T> {
interface LiList<T> extends MyList<T> {
<arjanb>the display methods do the same thing?17:00
they Outstream.println(...) in an other manner.17:01
<arjanb>then shouldn't they have the same name17:02
<rubber>...well, logically they do the same.
<arjanb>ok then either write:
<T> display(LiList list) { ...17:03
override <T> void display(LiList<T> list) { ...17:04
what do you expect this code to do? :17:06
MyList<Something> list = new LiList();
<rubber>why does'nt it work ... ok, waiting for your explanation.
<rubber>Aehm, let me see, what it does at the moment... :)17:07
list.display should use the "more" special implementation, don't?
So, it does...17:09
with and even without the change.17:10
it that correct?
<arjanb>with change yes
but without it's strange
<rubber>Ah, moment... I've used LiList<something> l = ...17:11
...then it has no choice, right?
<rubber>the argument is explicit of type lilist, so it should use the special version... if argument would be ... now, that does not work.17:14
so the override change is catching dubious things in your code17:15
<rubber>:/ So, I have to take a look at it.,17:17
But now I'm afraid to remove any of my target classes, since I dunno if I've again build a java-nice-java or nice-java-nice loop....17:21
* ChanServ leaves17:25
<bonniot>can't you get rid of the java sources?17:27
<rubber>jjtree/javacc is now my parser generator.17:28
* ChanServ joins
<rubber>and native is also a problem...17:30
...with nice.
<rubber>yes... we have had this already...17:31
<bonniot>yeah, it should be possible to skip the step though Java by adding tool support17:33
<rubber>The 'Any' keyword is deprecated, leave it away.17:36
<bonniot>yes, it was decided on nice-info that it's just confusing17:37
yu can write <T> instead of <Any T>17:38
ok, only two any deprecations and another override ...17:45
...the other override was my old foreach for HashMap's.
<arjanb>that one is the stdlib now17:46
<rubber>so, now I'm again on the latest compiler... .)
<bonniot>congrats! ;-)17:47
<rubber>ok, I'll have to leave irc... We'll see us next days...17:54
* rubber leaves
* CIA-1 leaves18:29
* CIA-1 joins
<arjanb>i don't think it's useful to keep flow4j in the automatic test18:52
<bonniot>did you check what was wrong with it?18:54
<arjanb>an override with an contravariant return type18:55
<arjanb>but flow4j ins't maintained anymore18:57
*away for meal*
<bonniot>isn't there a simple fix?18:59
maybe there is a simple fix now19:58
* CIA-1 leaves20:26
* CIA-1 joins
<bonniot>how are exams going for the dutch guys? ;-)22:05
just wrote to Alex about flow4j22:11
<Bluelive>think i passed discrete mathematics today22:15
also almost got stacktraces working in alpha

Generated by Sualtam