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

Using timezone: Central European Time
* CIA-3 leaves10:29
* CIA-6 joins
* CIA-6 leaves
* CIA-3 joins10:32
* ArtemGr joins12:33
i don't know these parts of the compiler well enough to review your patch but the idea seems good12:47
at least it works
i have an interface used by the Java application, and now i ported the interface and one of the implementing classes to Nice12:48
had to change Java implementations a bit becouse of the lack of compatibility "throws" clause.12:50
<arjanb>i think javac should be fixed to work with other languages that don't have checked exceptions12:53
<ArtemGr>enforcing exceptions checking was surely a bad decision. they should have made a warning instead.12:56
<ArtemGr>i'm having a strange problem with a Comparator class (not related to interface changes). When i write "public class KVBdbJe_Comparator<-T> implements Comparator<T>, java.io.Serializable" everything works fine. But historically i've used KVBdbJe$Comparator (which is now embered in databases), but when i use KVBdbJe$Comparator in Nice, strange errors begin to occur, like "no implementation found for12:58
method compare". Going to look into it now.
<arjanb>Comparator is the only contravariant class so that might have some bugs13:02
<ArtemGr>i've seen this variance thing in the sources, but not familiar with these terms. is it related to tensor analysis? and to category theory? : )13:06
<arjanb>afaik it's a type theory term13:07
a good explanation of variance is needed in the manual13:15
<ArtemGr>how about this http://citeseer.ist.psu.edu/cardelli97type.html ? : )13:16
<arjanb>that's probably not readable without knowing some type theory
in Nice type parameter are nonvariant by default so you cant do List<Object> x = someList; // of type List<String>13:19
in Java arrays are covariant so you can have Object[] x = someArray; // of type String[]
and contravariant is the opposite of covariant13:20
<ArtemGr>is the nonvariance of Nice a temporary thing? it isn't always convenient.13:21
<arjanb>nonvariance is needed for arrays to have static type safetye13:22
String[] x = ["abc"];13:25
(?String)[] y = x; //would be possible with covariant arrays
y[0] = null;
String s = x[0].substring();
<ArtemGr>let's say that type is composite, that is, !T is {nullness,basetype},13:33
type !String is {sureType,String}, and type ?String is {maybeType,String}
isn't it possible to have covariance for basetype, and nonvariance for nullness?
<arjanb>i don't know but covariance for basetypes only is unsafe in a similar way13:35
<ArtemGr>i see
<arjanb>are these new rfe's from you?16:32
<ArtemGr>probably not. which one?
<arjanb>the ones added last week16:33
<ArtemGr>no. i've missed them, don't they autoposted to nice-devel?16:38
<arjanb>that doesn't seem to happen16:39
java 1.5 support will be tricky because enums and annotations depend on a few runtime classes16:54
<ArtemGr>i haven't tried java 1.5, my goal is GCJ instead.16:58
don't even know what are enums in java 1.5.16:59
at least, from the point of view of writing libraries and frameworks, the 1.4 code we write will be always usable from 1.517:03
funny, i was very enthusiastic about using 1.4, becouse i really need socket open timeouts and non-blocking IO, but of 1.5 i'm on the reactionary side.17:07
<arjanb>yes but to make enums and annotation useable from java 1.5 we need to use these runtime classes
<ArtemGr>you use java 1.5?17:15
<arjanb>not yet17:16
<ArtemGr>somehow mlsub.typing.Typing.introduce is called twice when i use class with $ instead of )19:21
sorry, instead of _
that is, for ru.glim.db.KVBdbJe$Comparator createJavaType is called once, but mlsub.typing.Typing.introduce - twice19:23
first "mlsub.typing.Typing.introduce" happends with "ru.glim.db: parsing" and second with "Registering java class ru.glim.db.KVBdbJe$Comparator".19:26
<arjanb>aren't classnames with a $ inner classes?19:29
<ArtemGr>yes, it was historically an inner class. now i can't change the name becouse it is remembered in databases.19:30
* jackah joins
* jackah leaves
<arjanb>i think nicec depends on the $ to detect innerclasses19:34
<ArtemGr>it was a static class, which is in fact practically not the intter class19:38
Nice probably thinks that $ class can'be a Nice class19:39
when it expecting bytecode19:40
<arjanb>do you have a workaround for this problem?19:47
i can revert back to Java classes, but it is not what i'm trying to do19:48
<arjanb>i guess it's tricky to change that in nicec without breaking things19:51
<ArtemGr>why? it's just a matter of finding an existing type (it was already registered with the typing system when it was imported from Nice package; i thing it just isn't found). or of filtering out already registered types in mlsub.typing.Typing.introduce.19:53
<arjanb>hmm that might work19:54
<ArtemGr>what is tricky, is to track this down. spend on it the entire day already. : )19:55
<arjanb>it's a very obscure bug19:57
in general it's better not to depend on the details of nicec compiled code yet
<ArtemGr>i don't think it's obscure: i've tracked to the place in the mlsub.typing where comparison of constrains fails becouse the same type is present twice.19:58
having the same type twice in the typing subsystem is certaintly a bug here19:59
<arjanb>it's obscure because it depends on slightly different representations of class names somewhere20:00
any luck in finding where the decission of loading it as a java class is taken?20:04
<arjanb>maybe print the stacktrace on the second introduce?20:06
<ArtemGr>thanks, it will do good at the moment. shall try.20:07
second time it is loaded from Package.readAlternatives and readImportedAlternative(alternative.nice:414)20:23
i will be away for some time20:24
<arjanb>readAlternative shouldn't trigger loading of classes i think20:37
<ArtemGr>not loading, but registering. there is a registerJavaMethod(fullName, module.scope); invokation in readImportedAlternative. i have a feeling that decision whether to load the class as a Java class has been made somewhere before, when this method was placed into the list of alternatives...20:41
<arjanb>what is the stacktrace part between readAlternative and introduce?20:47
does it include readPattern?20:49
<ArtemGr>yes, readPattern hre21:12
there is the let sym = Node.getGlobalTypeScope().lookup(name);21:14
<arjanb>then it might be the replace on pattern.nice:775 causing the problem
does removing that replace help?21:16
it doesn't seem to break anything...21:27
<ArtemGr>nope, as it seems, it produce mlsub.typing.lowlevel.LowlevelUnsatisfiable warnings when debug is on, but the main problem remains.
i would expect the nice class to be already in the globalTypeScope21:31
<ArtemGr>i'm now going to see what's there.
indeed, Nice is trying to lookup the "ru.glim.db.KVBdbJe.Comparator", and the TypeScope.map have ru.glim.db.KVBdbJe$Comparator21:41
i'm not sure the replacement is made in the pattern.nice, though21:43
anyway, i think the replacement should be left as it is, one option is to modify the lookup method instead..21:44
<arjanb>i guess the replacement should be replaced by a function that knows how to stringify inner classes21:47
<ArtemGr>hurra!, adding21:51
if( name.equals( "ru.glim.db.KVBdbJe.Comparator" ) ) return (TypeSymbol) map.get( "ru.glim.db.KVBdbJe$Comparator" );
to TypeScope.get fixes my problem. it's a progress! thank you. : )
s/thank you/thanks to you/21:52
could this Comparator thing be turned into a testcase?22:05
<ArtemGr>perhaps instead of removing the replacement, we can add one? if Nice class have $, it is probably safe to replace it with a '.' in the TypeScope.addMapping (replacement will affect only TypeScope.map keys)...22:07
the problem with the testcase seems to trigger reading of the $Comparator from the bytecode.22:08
<arjanb>a testcase with 2 package could do that
<ArtemGr>yess! made a testsuite for that.22:15
i was trying with the new testing framework before, but got strange results from it.22:16
but it works with conventional testsuite.
will commit the TypeScope lookup workarond and testsuite tests tomorrow.22:18
<arjanb>the testcase is enough, i will look for a fix then22:19
<ArtemGr>the workaround will be to try replacing the last dot in the name if the usual lookup failed.22:20
why not commit it?
<arjanb>it doesn't matter22:22
<ArtemGr>still a solution, even if not the best one, better have it around than not.22:23
<ArtemGr>what the bytecodeRepresentation method does? it encodes the name *into* the bytecode form, or *from* it?22:32
<arjanb>encoding into, it's used for finding back implementation alternatives22:34
<ArtemGr>strange, i see dollars ($) for innter classes in the bytecode, so if this method is converting *into* bytecode form, than is is probably not directly related to bytecode.22:41
<arjanb>it's only for a bytecode attribute of implementation alternatives22:42
<ArtemGr>moved the workaround to scope.nice ...22:55
hmm, just replacing '$' with '.' in scope.nice:addMapping doesn't work:23:09
got "nice.lang.Map$Entry is not declared" error.
<arjanb>i see23:15
<ArtemGr>i will go. good night.23:35
* ArtemGr leaves23:36
* arjanb leaves
* bonniot joins23:52
* ChanServ leaves00:41
* ChanServ joins
* bonniot leaves00:51
* CIA-3 leaves01:13
* CIA-3 joins01:14