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

Using timezone: Central European Time
* zzorn joins00:17
* zzorn_ leaves00:21
* zzorn_ joins02:29
* zzorn_ leaves02:33
<CIA-5>03bonniot * 10Nice/src/bossa/ (35 files in 2 dirs): 02:34
Made bossa.syntax.Module represent a visibility unit (typically a file).
Scopes are still global. This change will later allow to make each Module have
its own scope, to implement 'private'.
* zzorn leaves02:36
* bonniot leaves02:39
* arjanb leaves03:54
* zzorn joins10:58
* bonniot joins11:59
<Bluelive>success :) successfully wrote a parser for the example ;)12:36
* zzorn leaves13:34
<Bluelive>how do you ensure that notnull member variables are initialized before any methods are called on the instance13:41
?
<bonniot>in the constructor, or with a default value13:56
<CIA-5>03bonniot * 10Nice/src/ (8 files in 2 dirs):
Added the nice.tools.visibility package. Use it for global scoping of
(non-type) symbols. No functionality change yet.
<bonniot>is there a good term for "non-type symbols" ?13:57
i mean the group including methods, fields, global values, ...
<CIA-5>03bonniot * 10Nice/src/nice/tools/testsuite/NiceSourceFile.java: 14:08
Respect the order in which imports have been specified so that import order
can be specified by the testcase.
03bonniot * 10Nice/testsuite/compiler/visibility/expressions/public.testsuite: 14:13
Check that packages cannot see unqualified public expression symbols from
packages they have not imported.
* zzorn joins14:15
* arjanb joins14:19
<bonniot>hi14:24
<arjanb>hi
<bonniot>so where do we stand on generics syntax?14:27
<CIA-5>03bonniot * 10Nice/src/nice/tools/visibility/tests.nice: Added unit test for remove.14:28
<arjanb>how do you mean?14:30
<bonniot>are there still open questions?14:32
<arjanb>type variable introduction
<bonniot>have you seen:14:34
http://sourceforge.net/tracker/index.php?func=detail&aid=986587&group_id=12788&atid=362788
?
if we want to implement that, then we will need to lookup type idents in the global environment in any case14:35
so we could accept <String extends T> ...14:36
and <Foo extends T extends Bar>
<arjanb>the last one looks odd to me14:37
<bonniot>other ideas?
<T, Foo extends T, T extends Bar>14:38
but that's mixing veriable introduction and constraints
<arjanb><T extends Bar, Foo extends T>14:39
<bonniot>yes. the only issue is that this could be confused with <T extends Bar, Foo extends U> which introduces two variables14:40
if we can guarantee that there is one "slot" per variable, it's must simpler14:41
because of class Foo<T extends Bar, Foo extends T>
would that be a class with only one type param? confusing
class Foo<T extends Bar & super Foo> 14:42
"T extends Bar and is a supertype of Foo"
<arjanb>i think checking that all type variables are used would solve introducing too much variables
<bonniot>these cases would be pretty rare i guess ;-)
what would class Foo<T extends Bar, Foo extends T> be?14:43
<arjanb>classconstraint and method constraint are different now right?
<bonniot>the thing is there a general construct that always goes in front of the declaration14:44
then there is class Foo<T>
that's a different thing14:45
only in most cases you can write constraints there, for convenience.
<arjanb>so if class constraints are only allowed the front there's no problem
<bonniot>you mean not allow class Foo<T extends Bar> ?14:46
<arjanb>yes that would be <T extends Bar> class Foo<T>14:47
<bonniot>is the first one allowed in Java?
<arjanb>yes14:48
<bonniot>hum, then I don't think it's worth the incompatibility14:49
conceptually, if there is one variable introduction per slot, it's a good thing14:54
<arjanb>sometimes the number of typevariables don't match the number of typevariable in the class
<bonniot>because we don't need a symbol like |, nor doing fancy stuff to check if a variable is already defined or not
yes, in that case you will still have to use a constraint in the front14:55
<arjanb>the defined check is usefull anyway
<K, V, E | E <: MapEntry<K, V>> private class MapEntrySetWrapper<E> implements ReducableSet<E>{
private java.util.Set<java.util.Map.Entry<K, V>> mapentryset;
}
<bonniot>yes, but that could be:14:56
<K,V, E extends MapEntry<K,V> > class ...
i agree we need to keep constraint in front for such cases14:57
<arjanb>this is an old example but afaik it's still not possible
<bonniot>what we can get rid of is |
why is it not possible?
<CIA-5>03bonniot * 10Nice/src/bossa/ (syntax/VarScope.java util/HashMultiTable.java): Local var scopes can have at most one binding per name. Drop HashMultiTable.14:59
<arjanb>oh it's now15:00
<bonniot>:-)
| and <: really look cryptic15:02
they are fine in a research paper, but not great language syntax
<arjanb>you get used too it
<bonniot>_you_ do ;-)15:03
but that might set back people at first sight
<arjanb>and the word extends hasn't the same meaning as <:15:04
<bonniot>you're technically right. but most people don't care, and will like extends better15:06
hey, they will learn about generics in their uni course or in a Java 5 tutorial. so it will be all the easier for us to look the same
I don't think this is worth fighting on. there are more important things that badly need changing in Java, so let's focus on that15:07
<arjanb>yeah15:09
oh and what about AI constraints?
<bonniot>implements?15:10
<arjanb>that's confusing
<bonniot>why? a class can already implement an AI15:11
<arjanb>class X implements I --> <T extends I> class X implements AI --> <T implements AI>15:13
<bonniot>it's not really the second one that's confusing ;-)
<arjanb>maybe <T is Comparable>15:14
<bonniot>we can as well accept <T implements I>
it doesn't really matter semantically, it's just a syntactic question15:15
accepting both actually makes sense, since T might be as well an interface as a class15:16
<arjanb>then extends and implement are interchangable?15:22
<bonniot>yes, at least if the bound is an interface15:26
<arjanb>is <T <: I> and <T : I> different?15:39
<bonniot>i don't think <T <: I> was ever valid syntax15:42
<T | T <: I> is ;-)
<arjanb>i meant that
<bonniot>yes, it's different
first one is subtyping, other is AI implementation
<arjanb>so we need a word for :15:43
<bonniot>no, it can be implements15:45
the same way that currently <AI T> and <I T> share the same syntax15:46
<arjanb>would this short form disappear?15:50
<bonniot>yes15:51
<arjanb>what has happened with the wiki?16:28
<bonniot>what?16:29
<arjanb>the whole Main part has disappeared16:30
<bonniot>true
it's not really used though it is?
<arjanb>right16:32
* Bluelive leaves16:41
<CIA-5>03bonniot * 10Nice/src/nice/tools/visibility/ (tests.nice impl.nice): 16:52
Put 'general' symbols at the highest possible level so their are viewed
globally.
03bonniot * 10Nice/src/nice/tools/visibility/ (tests.nice impl.nice): Fix removal of 'general' symbols.16:57
* ArtemGr joins17:43
Salute, is anybody here.17:44
?
<arjanb>hi
<ArtemGr>Could you please verify that followin testsuite failures are OK with RFE 681385 implemented?17:45
http://bizlink.ru/Nice/
<arjanb>i find the first testcase very dubious17:47
i think it's ok for all except the last17:49
in one of the catch clause s is assigned null so s can be null in the finally block17:50
<ArtemGr>where should i look how catch clauses are implemented in respect to inference?17:53
it seems i found the place17:54
<arjanb>does your implementation branch merging of nullness?17:55
<ArtemGr>i push 'maybe' type to the stack: setVarType( variable, now: sureType, otherBranch: type ),17:58
but it seems to me at first glance that catch handling in typecheck doesn't uses the inference stack.
<arjanb>another testcase:18:01
?String s = "abc";
if(somecondition)
s = null;
else
s = "zyx";
s.substring(1);
<bonniot>hi Artem
<ArtemGr>salute
* arjanb is away for half an hour18:02
<bonniot>these testcases were already in the testsuite, or you just wrote them?18:03
<ArtemGr>they were
<bonniot>ok. one thing to be careful about is that even if the expectation should be changed, we should try to understand if they are meant to test a feature that will need its own test18:07
how come testcase602 is fixed, if you don't merge types at the end?18:08
<ArtemGr> ?String s = "abc";18:11
void->boolean somecondition = void => true;
if( somecondition() )
s = null;
else
s = "zyx";
s.substring(1);
- fails as expected
<bonniot>so?18:12
<ArtemGr>sorry, it doesn't fail as expected. it seems to leak sureType indeed18:14
<bonniot>so we are missing this testcase, right?18:15
that looks like the second testcase in dti.testsuite18:16
what do you get on that one?
i think it's not good in 612 to catch twice the same class of exception18:17
it should be changed to have Throwable in the second catch18:18
agreed?
<ArtemGr>yes, it seems misleading18:19
http://bizlink.ru/Nice2/18:21
The first is failing as expected, with "No possible call for substring", but the second compilation passes.18:22
That is becouse i use "setVarType( variable, now: sureType, otherBranch: type );" without the "out: type" parameter.18:23
<bonniot>yes, it's your bug ;-)
<CIA-5>03bonniot * 10Nice/testsuite/compiler/typing/dti.testsuite: Fix testcase to avoid catching twice the same class of exception.18:24
<bonniot>finding the "right" type for the exit of the block would require some additional work18:25
<ArtemGr>But it seems to me that i can't always use the "out: " parameter, since it will push both "ifLevel * 2" and "ifLevel * 2 + 1" records into the stack, thus preventing further stack unwinding to that point (since stack unwinding uses " while (levels.size() > 0 && levels.peek() == ifLevel * 2)" )...
<bonniot>what about you implement it and see if you can find such a testcase?18:26
<ArtemGr>implement what?
<bonniot>add the out: parameter18:27
<ArtemGr>out: parameter doesn't work, i can't compile compiler with it, and i've said why
<bonniot>where have you said why?
i know it failed
<ArtemGr>" it seems to me that i can't always use the "out: " parameter, since it will push both "ifLevel * 2" and "ifLevel * 2 + 1" records into the stack, thus preventing further stack unwinding to that point "18:28
<bonniot>ok, it sounded just like a supposition
does that testsuite pass with out: ?18:29
<ArtemGr>i can't run testsuite with 'out:', that's a problem with my build file perhaps, i get "package nice.lang not found" errors or such.18:30
<bonniot>that's with a compiler compiled by the stable version?18:31
<ArtemGr>no, by the latest one
<bonniot>define latest ;-)
http://nice.sf.net/nice.jar is fine
i mean, not one tainted by the changes you are making at that point18:32
<ArtemGr>you have "nice (0.9.10-1) unstable; urgency=low " record in the debian/changelog ; )
<bonniot>yeah, that has it's own meaning in the context of Debian ;-)
so?18:33
<ArtemGr>with the latest version, yes. compiler1 stage seems not to produce nice.lang.fun, even when i invoke stable nicec with package nice.lang and --exclude-runtime18:34
<bonniot>i think that's a problem of your build file
<ArtemGr>compiler2 stage works ok, though, so it is some weirdness with the testengine18:35
<bonniot>but compiler2 is already tainted18:36
don't you just miss the -R option? (recompileAll)18:39
<ArtemGr>no, i didn't, as i've mentioned earlier: "even when i invoke stable nicec with package nice.lang and --exclude-runtime"18:40
oh, sorry, i didn't mentioned : )
yes, i use -R
both when i'm trying by hands and it's the part of the "compiler1" stage..18:41
<bonniot>when testengine cannot find nice.lang, do you see where it is?18:43
<ArtemGr>i'll perform a clean "compiler1" stage and will post you what i see18:44
<bonniot>ok
<CIA-5>03bonniot * 10Nice/testsuite/compiler/typing/dti.testsuite: 18:45
Check that nullness inference is not too optimistic with if when only the
second branch guarantees non-nullness.
<bonniot>could you create a nice.conf file in your home?
with:
debug.modules = true
in it. that will make the compiler more verbose about where it finds packages
<ArtemGr>did it18:46
<bonniot>585 is really a corner case18:48
on the one hand, yes, we know x1 is not null because of the assignment
on the other hand, we know it's null, because of the test!18:49
obviously this is only possible because the code is dead
so i agree it's probably fine to let it pass
<ArtemGr>we know becouse of inference, but still in reality it may be null
<bonniot>in what sense?18:50
how can it be null?
<ArtemGr>?String x1; String abc = cast( null ); if( ( x1 = abc ) == null ) ...
<arjanb>the use of cast() is one's own responsibility18:53
<bonniot>right18:54
but if you don't believe the types, you cannot get far ;-)
i think the best solution for this testcase is simply to remove it18:55
opinions?18:56
<arjanb>agreed18:58
* bonniot leaves
* bonniot joins19:00
<ArtemGr>i think it's not a bad test case. TDD says test cases can be used as documentation, and that one is documenting this corner case. it might be remarked that this testcase behaviour is not strictly defined, whithout removing the testcase itself. IMHO the testcase should fail, becouse x1 == null..
<bonniot>if the behaviour is not strictly defined, i don't see how you can have a testcase for it19:02
<arjanb>myabe change it to ?String abc = null;
<bonniot>then it's not testing anything I think19:03
<ArtemGr>thinking of it, it _should_ be strictly defined. aren't nullness checks supported on sure types?
<bonniot>they are. so?
<arjanb>they will give a warning19:04
<bonniot>yep
<ArtemGr>then '(x1 = "abc") == null' is ok
<bonniot>yes, it's OK
<ArtemGr>what about the following:
<bonniot>the question is to know if it guarantess x1 not to be null19:05
<ArtemGr>String x1 = "abc"; if( x1 == null ) x1 = x1 + " "; // i think this shoulf fail. : )
it guarantess x1 to be null, since "==" works _after_ "x1 = abc"19:06
<bonniot>yes, that's the core of the question
<arjanb>in that case x1 shouldn't have a sure type19:07
<bonniot>what about we postpone this discussion until the more important questions are solved? this is a very minor point I think19:09
let's say that at the moment, all behaviours are fine ;-)
<arjanb>ok19:10
<ArtemGr>it's type inference "the other way". it's not very practical, but it would be fine of the compiler to forbid x1 being used when it was checked to be null... imho testcase might be left around with some explanation attached, since this question might occur again..19:11
<bonniot>ok, we don't delete it now. and move on ;-)19:12
i have 20 regressions to fix with my visibility changes...
but i'm available when you need help19:13
<ArtemGr>http://bizlink.ru/Nice3/
classes/nice.jar HAVE a nice.lang.fun class...19:14
<bonniot>the testsuite should not be looking in the jar file19:15
but in classes/nice/lang
<ArtemGr>Then the following comment is wrong?19:16
* Classpath entry that contains the Nice standard library.
private static String _runtime;
i've tried to unpack nice.jar into classes, same effect...
<bonniot>ls classes/nice/lang ??19:17
<ArtemGr>this nice.jar is just a derivative from console.jar19:19
console.jar seems to have nice.lang.fun and other classes, but testsuite still doesn't see it, nor from the classpath nor if i unpack console.jar into classes/19:21
<bonniot>does it have nice/lang/package.nicei?19:22
<ArtemGr>no
<bonniot>it needs it to see nice.lang as an imported package
what you should do is to the the "stable" compiler compile your modified compiler into classes/19:23
when developing, I do this _without_ creating a jar, so that I always use the same clean compiler19:24
once I get the testsuite to pass, I try to bootstrap
<ArtemGr>you have "${NICEC} -R -a src/nice/tools/compiler/console.jar nice.tools.compiler.console" at compiler1 in Makefile
<bonniot>yes, but that's for bootstrap19:26
actually, console.jar does not matter19:27
it's share/java/nice.jar that has the current compiler
(yeah, surely this scheme could be cleaner)19:28
<ArtemGr>"nicec --sourcepath src:stdlib -d classes -R nice.lang" do nothing,
"nicec --exclude-runtime --sourcepath src:stdlib -d classes -R nice.lang" too,
is it ok?
i figured that console.jar isn't used, but i don't have nice.lang anywere else...
<bonniot>what output do you get?19:29
for "nicec --sourcepath src:stdlib -d classes -R nice.lang"
<ArtemGr>oh, silly i,19:30
i get "warning: Path component src:stdlib does not exist",
"nicec --exclude-runtime --sourcepath src --sourcepath stdlib -d classes -R nice.lang" works.
thanks. : )19:31
<bonniot>np ;-)
this is another windows weirdness?
<ArtemGr>i can't use "src;stdlib", and "src:stdlib" seems not understood by the nicec19:32
<bonniot>works on unix afaik
see also:
http://sourceforge.net/tracker/index.php?func=detail&aid=908931&group_id=12788&atid=112788
this should really be fixed, it will bite other people19:33
<ArtemGr>it would be a big problem with nicec ant task, but it's ok now, since i don't use the nicec ant task anymore
so i can use two --sourcepath argumetns no prob.
<bonniot>it might work with ant
at least the bug i refer to is caused by batch file handling19:34
i think : cannot work on windows because it's a legal character in pathes
<ArtemGr>perhaps it was, but has been left unchanged when i've moved from using the ant task19:35
considering the bug, i think nice should use 'path.separator' property.19:36
<bonniot>doesn't it? arjan, isn't it using ; on win already?19:37
<ArtemGr>nicec --exclude-runtime --sourcepath src:stdlib -d classes -R nice.lang19:39
warning: Path component src:stdlib does not exist
nicec --exclude-runtime --sourcepath src;stdlib -d classes -R nice.lang
Supply only one package on the command line.
...
<bonniot>http://sourceforge.net/tracker/index.php?func=detail&aid=908931&group_id=12788&atid=112788
<ArtemGr>that is, neither do work
<arjanb>the problem with ; that it means something in batch files
<bonniot>"...;..." should work19:40
now
<arjanb>yeah
<bonniot>...;... should work (when somebody does something about it)
<ArtemGr>all right, probably my fault again,19:41
nicec --exclude-runtime --sourcepath "src;stdlib" -d classes -R nice.lang
do work (with quotes)
<bonniot>it's not your fault, there is something that could be improved (to work around this)19:43
<ArtemGr>in the ant build i just forgot to check that "stdlib" is on the path (it was for 'compiler2' but wasn't for 'compiler1'). thanks everyone for helping me to fix this. testengine now works with 'compiler1' classes.19:49
<bonniot>:-)
how is it going?21:09
<ArtemGr>i've fixed sureTC leaking, but had to patch the stack itself for that, running testsuite now (12 tests ok so far)21:10
<bonniot>is this a bug with the way I implemented the helper methods that prevents you from using them? or is it a situation that did not arise before?21:14
<ArtemGr>the situation is new, stack was populated on enbranchments, and it was clear whether "ifLevel * 2" or "ifLevel * 2 + 1" should be used, and now the stack is populated in the branch itself.21:16
<bonniot>i see21:18
well done for figuring this out. this is not the simplest part of the compiler ;-)
<ArtemGr>Here is my patch: http://bizlink.ru/Nice4/ ( i will beautify checkNotNull usage later on, when this works )21:24
<bonniot>still testing?21:25
<ArtemGr>This works as expected: http://bizlink.ru/Nice2/
testsuite\compiler\null\inference.testsuite still fails, see updated http://bizlink.ru/Nice/21:26
<bonniot>i don't think it's useful to catch NPE in your testcases21:27
<ArtemGr>it's very useful, becouse test cases should fail at compile time and not becouse of NPE21:28
<bonniot>yes, but the testsuite won't even run them if they are expected to fail
you don't need to worry about it ;-)
/// FAIL21:29
means: _compilation_ should fail
<ArtemGr>oh, all right, i didn't knew it. : )
what was the "known bug" in testcase602 ?21:36
testsuite finished. everything is ok except the aforementioned "inference".21:37
number of testcases: 1264
successes : 1234
regressions: 3
warnings : 0
known bugs : 26
FIXES :-)) : 1
<arjanb>which testcase?
<ArtemGr>http://bizlink.ru/Nice/21:38
testcase602
<arjanb>there a few testcase marked "known bug" while it means to be implemented
<bonniot>there is no 602 on that page21:39
<ArtemGr>wov, i've updated the page, but forgot to refresh it myself 8 )
it's ok then, becouse testcase602 shouldn't have been "fixed" from the look of it21:40
<bonniot>so you still have regressions to fix?21:42
<ArtemGr>testcase580 seems to be of the same kind as testcase59821:44
<bonniot>no, 580 is unsafe21:45
<ArtemGr>we have notNull inference now, but no maybeNull inference
<bonniot>i don't think that's the problem here21:46
agree it's unsafe to pass?
<ArtemGr>what's the problem then? we know that x is not null and this information is not leaked outside, i think implementation is correct regarfing RFE# 68138521:48
implementing maybeNull inference will fix the case though
<bonniot>but x IS null after the assignment21:50
so x++ will fail
<ArtemGr>that's what i call the "maybeNull inference". i'll try to implement it now.21:52
works the same way as "notNull inference" for assignments, but backwards. should probably fetch the originalType for that...21:53
<arjanb>isn't assignment to null handled at typecheck.nice:55?
<bonniot>you realize it is already implemented?21:54
yeah
somehow there is an interference with your patch, so that has to be worked out
<ArtemGr>oh, i see now22:15
it seems i've fixed that regression. testing now.23:13
i've updated my null/inference.testsuite status: http://bizlink.ru/Nice/23:20
that is, i have one regression left
<bonniot>yeah, and that's the same corner case. i'm OK with it
<ArtemGr>i will add some comment to it. should i mark it as a bug or switch it ti pass?23:21
<arjanb>the condition of that if can never be true
<ArtemGr>i will change "abc" to abc23:23
String abc
<bonniot>you could leave it as is and change to pass23:25
in that form, one cannot argue that it might fail ;-)
this form
<ArtemGr>in testsuite it looks like this:23:27
?String x1 = null;
if ( (x1 = "abc") != null)
x1 = x1 + "";
?String x1 = null;
if ( (x1 = "abc") == null)
x1 = x1 + "";
so it is natural for the second test to fail
<bonniot>"natural" is subjective23:28
<ArtemGr>for two reasons, becouse Arjan says it cannot be true and becouse x1 should be null..
so i'm tempted rather to mark it as bug
<bonniot>it's not very important23:30
but i don't feel that this is something that should be "fixed"
don't waste time on it in any case23:32
<ArtemGr>i'll just comment it out and leave there for reference.
<bonniot>perfect
how many fixes do you have?23:36
<ArtemGr>i have one fix and one regression in total. both are at dti.testsuite: http://bizlink.ru/Nice3/23:48
<bonniot>ah, so there is a pb with 614?23:49
<ArtemGr>what is pb?23:50
<bonniot>i see you haven't updated from cvs ;-)
problem
<ArtemGr>i've updated at the morning
at morning23:51
<bonniot>yeah. i just fixed the double catch, as you can have seen here. it should not influence the testcase result anyway23:52
<ArtemGr>have to go. should i commit my patches, or wait till tomorrow, when i can update from cvs to fix 614?23:53
and retest it..23:54
<bonniot>you should not commit until all regressions are fixed
<ArtemGr>is the "fix" in dti.testsuite expected?23:55
<bonniot>but will need some work, no?
<arjanb>yes
<bonniot>well, yes, that was your goal wasn't it?
ArtemGr: I did not _fix_ your regression on 61423:57
just made the testcase more logical
<ArtemGr>ah, so i still need to introduce 'inference stack' into catch typechecking?23:58
<bonniot>it should be there already
i see at least two cases in dti.testsuite that currently pass23:59
i should say "succeed": they fail, as expected ;-)00:00
<ArtemGr>ok, i'll see to it tomorrow. can't wait to submit my first patch. : )00:02
<bonniot>:-)
* ArtemGr leaves00:03
<arjanb>catch clauses are branches in analyse but not in typecheck00:05
<bonniot>there is an enterBlock/exitBlock00:22

Generated by Sualtam