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

Using timezone: Central European Time
* zzorn_sleep leaves01:32
<bonniot>gppd night01:45
* bonniot leaves01:48
* arjanb leaves03:56
* ArtemGr joins07:41
* zzorn joins08:32
* bonniot joins09:05
<CIA-5>03artemgr * 10Nice/build.xml: 09:13
Execution of testsuite is now possible after "compiler1"
(stdlib sourcepath absence is fixed).
<bonniot>any objection to allowing this:09:15
void foo()09:16
if (...)
return println("...");
that is, returning a "void value"
<CIA-5>03artemgr * 10Nice/ (3 files in 3 dirs): Nullness analisys on assignments is partially implemented (RFE 681385).09:17
<ArtemGr>no, it's a fine thing, imho
i remember it being discussed for C++09:18
<bonniot>so you fixed that last regression?09:20
<ArtemGr>as i've said, there was no 'inference stack' for catches. yes, i've fixed it.09:21
<bonniot>well done!09:22
<ArtemGr>thanks : )09:23
the RFE is only partially implemented though
<bonniot>yes, because non-nullness is never propagated down, right?09:24
you can leave a comment in the RFE to let know what has been done09:26
<ArtemGr>i thought about pushing statements into additional stack ( enterBlock will push the Statement, exitIf will pop it ), then it is possible to check from the branch if the current statement is "if" without "else" and with the current "variable" being the only argument of conditional expression... but i'm not inclined to do this now.09:27
<CIA-5>03bonniot * 10Nice/NEWS: Opened 0.9.1109:28
<bonniot>btw, please also include an entry in the NEWS file, anytime you implement something users should know about
<ArtemGr>approve of http://bizlink.ru/Nice/maybeNull/ ?09:32
<bonniot>for consistency of style: it's if (null == value), not if( null == value )09:35
also ?T maybeNull(!T value)09:36
?T maybeNull (!T value) is fine too with me, it's just not used much atm
that won't compile
should be
<T> ?T maybeNull (!T value)
oh, it's the page eating the tags ;-)09:38
<ArtemGr>yes, sorry. should put a textarea
<bonniot>i agree with maybeNull
I'm not sure notNull should be changed (unlike what the comment says)09:39
notNull is a kind of assertion
it makes sense for it to fail fast only if assertions are enabled
<ArtemGr>see again: http://bizlink.ru/Nice/maybeNull/09:42
ups, forgot to return assertion cheeck09:43
now it should be ok09:44
<bonniot>Yeah. the comments could be improved09:46
what about:
Assert that a value it not null.
Throws java.lang.AssertionError if assertions are enabled and the argument is <code>null</code>.
there should be something for maybeNull too
explaining when it is useful09:47
<ArtemGr>why not the usual09:49
*/ comments?
like in Java?
' /**09:50
<bonniot>i find it heavy09:53
when your editor colors comments, the * is really redundant09:54
<ArtemGr>mine doesn't : )
<bonniot>what is that?09:55
<ArtemGr>Eclipse _text_ editor.
<ArtemGr>i can't stand colors buildin into the current Nice plugin
<bonniot>no config?
<ArtemGr>absolutly none. they could have read system properties at least, but the colors are just hardwired09:57
<bonniot>feel free to change the defaults
<ArtemGr>i don't want to recompile Eclipse plugins yet09:58
<bonniot>do you think returning non-void should be allowed in a void method? (value ignored)09:59
<ArtemGr>the text editor is fine, btw. it respect existing indents, and my brain is 'toned up' by the lack of highlighting. like in old c++ days when i've used joe or DOS MultiEdit...10:00
"do you think ..." - absolutely
i've checked, it's supported in gcc10:01
in c++ probably too
and it's convenient
<bonniot>a relevant thread: http://thread.gmane.org/gmane.comp.lang.nice.general/36810:03
<ArtemGr>are /() => ""/ and /() => return ""/ - different things?10:07
(well the later form should be () => { return ""; }
<ArtemGr>having 'ignore' function is fine. or keyword could be even better, becouse no brackets would be required then: l.foreach( (String s) => ignore buffer.append( s ); );10:13
if there is no problems with 'void subtyping', then fine10:15
"Of course we can do some magic, so that 'return e' inside a void method is not allowed, except if it was produced from this syntactic sugar." - better not. the usual use case is: if( condition ) return buf.append(..); that is, instead of writing: if( condition ){ buf.append(..); return; }10:18
<bonniot>at the moment, we have void subtyping + return value disallowed in non-void methods10:20
the no brainer would be to allow return void value10:21
but yeah, that woulnd't allow return buf.append(...);
<ArtemGr>wouldn't it be less effective, performance vice, to treat void as a supertype?
i mean, the generated bytecode, would it always return something?10:22
the value is simply ignored
inside the method, not at the caller site
so it's not a performance issue
i'll be gone for a couple of hours10:25
please don't forget the NEWS entry
* arjanb joins10:26
<bonniot>hello arjanb 10:30
<bonniot>back in a couple of hours...
<CIA-5>03artemgr * 10Nice/stdlib/nice/lang/prelude.nice: maybeNull10:49
03artemgr * 10Nice/build.xml: Changed the version string to "0.9.11 prerelease".10:55
03artemgr * 10Nice/NEWS: maybeNull, and RFE 68138511:32
03bonniot * 10Nice/stdlib/nice/lang/prelude.nice: Typo.12:35
<arjanb>daniel: bootstrap problem with current cvs12:43
Exception in thread "main" java.lang.NoClassDefFoundError: nice/tools/visibility/fun
at bossa.syntax.fun.addSymbol(Unknown Source)
at bossa.syntax.GlobalVarScope.addSymbol(scope.nice)
<bonniot>i'll look at it12:46
do you get this locally too?
(I saw the automated builder does that)
<bonniot>it's a build file issue13:06
but with the official dev compiler you should be able to bootstrap13:11
the autobuilder does not let a new one become official otherwise
<CIA-5>03bonniot * 10Nice/Makefile: Bootstrap nice.tools.visibility13:15
<bonniot>i wonder how build.xml fares on this one ;-)13:19
arjanb: any idea how this can happen?:13:39
Method <Enum T> nice.lang.List<T> family(T element) is declared but never implemented:
no alternative matches (nice.tools.visibility.Visibility)
<arjanb>maybe something is wrong the check when to generate that method13:45
<ArtemGr>i had no problems compiling CVS today13:46
<bonniot>maybe it's only with my local changes, checking now13:47
ArtemGr: the bootstrap problems might occur when you use the new compiler as a base compiler (depending on what your build script does)13:48
<ArtemGr>bonniot: that's exactly what i did13:49
<bonniot>the enum problem is only in my local tree13:50
by new i mean: generated from cvs, not the dev version
if that works then all is well13:51
<ArtemGr>i've used the one with RFE 681385 patches as the base compiler, to check that the compiler still can compile itself from scratch. i'll check again, though, with my latest (commited) version.13:56
<bonniot>the problem is not related to your changes but to mine ;-)13:58
<arjanb>:(( http://wiki.ffii.org/Cons050307En
<ArtemGr>but there was no changes from you since i've commited RFE patches...14:00
confirm: successfully bootstrapped from the previously bootstrapped CVS (with ant)
<bonniot>ok, great14:01
<arjanb>including running the testsuite?
<ArtemGr>arjanb: nay. will give another roundtrip with a testsuite now.14:04
wow, on the second round-trip i got it too: java.lang.NoClassDefFoundError: nice/tools/visibility/fun14:09
on "compiler2" stage
<arjanb>porting the change from the makefile should be trivial14:12
<ArtemGr>arjanb: thanks; will test it now.14:16
<bonniot>arjanb: sounds bad. the directive needs to go backk to the EP though14:25
<arjanb>the whole procedure around the adoptation was very strange14:29
it's sad to see that large institutions can't be democratic14:30
<CIA-5>03artemgr * 10Nice/build.xml: Bootstrap nice.tools.visibility14:40
03bonniot * 10Nice/stdlib/nice/lang/array.nice: Added fill method for bidimensional arrays.15:21
* namxam joins16:01
* namxam leaves
<ArtemGr>how do i check that two Expression variables point to the same symbol?17:24
<arjanb>you mean SymbolExp's?17:26
<arjanb>their 'symbol' field is identical then17:28
<bonniot>what are you up to now?
<ArtemGr>Wondering about RFE 681385 still.17:31
<bonniot>yeah, that's what I mean I think
the idea should be that when you exit a statement with several branches, you merge the infered type17:33
that is, if all branches finish with a non-null type, then you keep that type
this is very similar to what is done in analyse.nice to check initialization of variables17:34
<ArtemGr>that's one possibility, another is for / if( foo == null ) foo = something; /, but both cases can share information
<bonniot>what would you want to do in that case?17:35
<ArtemGr>propagate out one level that foo is not null
<bonniot>ok, but that's only a special case17:36
(quite common, but still...)
<arjanb>this is merging with an empty else branch right?
<ArtemGr>that's the nice case i've taken RFE 681385 for.17:37
it's not just the empty branch, have to check if arguments first
<bonniot>arjanb: right
ArtemGr: yeah, but this is already done
if (x == null) {} else { x++; }
the else branch already knows that x is not null
<ArtemGr>method "nullnessInfo" can be used to see what is 'null', but not what is 'not null'...17:38
err, i mean the other way around
<bonniot>why do you care if something is exactly null?17:39
<ArtemGr>let's say / if( foo == null ) foo = new Foo() /17:43
i can't propagate "foo = new Foo()" becouse if will not always succeed
so i think i need to check for the special case in order to handle it
<bonniot>what will not succeed?
<ArtemGr>ok, the general case / if( maybeTrue() ) foo = new Foo() /17:45
i don't know if maybeTrue() condition will succeed (is true) so i can't propagate / foo = new Foo() /
<bonniot>let's say foo has type ?T before. with annotations:
if (foo == null) 17:46
foo = new Foo();
/* foo: !Foo */
{ /* foo: !T */ }
here we can merge:
<ArtemGr>i see. thanks
(provided Foo extends T)17:47
<bonniot>(i didn't get your last comment(
arjanb: do we handle loops properly at the moment?17:48
but that's a harder problem17:49
* arjanb looking up testcase17:50
<bonniot>oh, it's that you need to feed back the info at the end to the begining17:51
it happens to be simpler for initialization checking, because the values are always increasing17:52
<arjanb>yes plus merging of the continue points and that needs to be repeated while the type change at merging
?String s = "xyz";
String t = "abc";
int x = 0;
if ( s != null)
do {
t = s;17:53
s = null;
} while(x++ < 10);
<bonniot>you cannot become unititialized again, but you can become maybe-null again
<arjanb>yes so multiple passes may be needed
I would *very much* be in favor of extracting the analysis framework out17:54
i guess it can be made pretty generic
<arjanb>that would be usefull because we need nullness inference for final fields too and that requires tracking what variables refer to17:55
<bonniot>aliasing analysis?17:56
it would be correct without it, wouldn't it? just a bit less precise17:57
<arjanb>if a variable is changed, the nullness info of a field should be removed17:58
combined with merging it's almost alias analysis18:00
<ArtemGr>how do i compare one MonoSymbol with another to see if they point to the same symbol?18:02
compare one type to another to see if they can be merged: is mlsub.typing.Typing.leq sufficient for this?
<bonniot>arjanb: you're right. but if we just discard the info, it's much simpler when the var is assigned, that's much simpler than alias analysis18:04
<arjanb>just reference equality on MonoSymbol
Typing.leq should not be used because it's about asserting, not testing
(it makes a difference at least for inferred variables)18:06
ArtemGr: do you think the merging can be done easily in the current infrastructure?18:10
<ArtemGr>it requires additional stack
<CIA-5>03bonniot * 10Nice/ (6 files in 4 dirs): 18:11
Allow value returns in void methods. We don't need to distinguish between
real and "fake" (sugared) returns.
<ArtemGr>to remember what each branch decisions were..18:12
<bonniot>then maybe it would make sense to only do it while switching to the new framework, what do you think?
<ArtemGr>i've implemented such a stack at least for IfExp already. so i can try to go a bit further.18:14
framework would be very nice. and i can scrap my work if you think it doesn't worth it (i almost did already)18:16
<bonniot>it's surely good to have it now
<arjanb>trying is useful to know what the framework needs be able to do18:17
<bonniot>oh, are you taking about something you haven't commited yet?
<bonniot>ah ok
if you can get 'if( foo == null ) foo = something;' working, that would be very useful in practice18:19
<ArtemGr>i think i always did it (in the wrong way, without merging)18:20
<bonniot>but if it's hard, then it might be better to focus on the clean framework
you mean it's passing now?
<ArtemGr>no, just written
<bonniot>s/always/already/ then?18:21
<ArtemGr>it's clear i will have no time nor have the experience with Nice compiler to write the framework, so i can't "focus" on it :-j18:24
<bonniot>it should actually be easier than what you are doing now, because it can be done completely outside the compiler, no need for internal knowledge18:26
(like what I'm doing with visibility)
<ArtemGr>visibility is in the nice.tools.visibility? will try to look at it next weekends.18:29
<bonniot>it's very preliminary at the moment18:36
nice.tools.visibility is a library that can be used to manage symbols in nested scopes, with marked visibilities18:37
it's completely independent of the compiler
<ArtemGr>is it used from the compiler, or is it a plugin?18:38
<bonniot>so i won't have the details about visibility in nice. it's about extracting a generic tool to keep the compiler simpler18:39
what's the difference?
<ArtemGr>i think it may be designed very differently depending on whether it is a library used outside or a plugin that uses something from inside. or maybe there is a library and the plugin for integration. it might be required to understand this integration to grasp how the things actually "work".18:43
<bonniot>it's a library, then18:44
i whish we generated a dependency graph. it would help understand the design, and help improve it ;-)18:46
<ArtemGr>i thought some hints might be present in http://nice.sourceforge.net/research.html18:51
didn't had time to check
<bonniot>hints about what?
<ArtemGr>abould compiler design18:52
<bonniot>not really. it's mostly about the advanced aspects of the type system
my goal is to modularize the compiler much more18:54
using multimethods helps ;-)
<ArtemGr>i'll try to focus on / if( foo == null ) foo = something; / then : )18:55
<ArtemGr>i have the / if( foo == null ) foo = new Foo(); / fix working! : )19:57
you can see the patch here: http://bizlink.ru/Nice/preliminaryFix1/
running testsuite now..
the stack i use there can easily be used for merging20:00
<bonniot>in ifPropagation:20:02
why don't you test condition.isCallTo("==") earlier?
then you wouldn't need instanceof
<arjanb>why can't nullnessinfo be used there?20:03
<bonniot>right, if it can it should simplify even more20:04
<ArtemGr>for starters, currently it's just a proof of concept.20:07
Daniel explained how nullnessInfo might be used for merging,
but i don't see how it can be used without merging in this case.
<bonniot>nullnessInfo is just a convenient way to ask if an expression guarantees an expression to be non-null20:08
aren't your tests at the beginning duplicating that?
(nullnessInfo is more general because it handles &&, ...)
<ArtemGr>i test if the value 'is null', nullnessInfo tests if the value 'is not null'.20:09
moreover, i test if that particular argument is compared with null, and not if the whole expression lead to some nullness in then/else branches20:10
testsuite finished. two fixes: http://bizlink.ru/Nice/fixes1/ no regressions20:13
<bonniot>that's cool20:14
<ArtemGr>now, is there a way to check if two mlsub.typing.Monotype are equal enough to be merged?20:16
<bonniot>i could write one20:18
ideally, what should be the api?
merge(Monotype m1, Monotype m2) ?20:19
<ArtemGr>boolean canMerge(Monotype m1, Monotype m2)
should i try to implement merging in 'ifPropagation' then?20:20
it should be much simpler then the current logic, if i understood it correctly20:21
<arjanb>canMerge isn't enough because the monotypes can be different
<ArtemGr>then ?Monotype merge(Monotype m1, Monotype m2), returnin null if can't be merged?20:24
or i can stick to this scary but working implementation, refactor it a bit and left around till the framework20:25
<bonniot>2 secs
<ArtemGr>i'll be away for a few minutes20:28
i'm here. decided anything?20:50
that's why I thought, merge should return a type20:58
it would be simpler than the current CVS code, or than your patch?21:00
away for dinner21:01
<ArtemGr>should be simpler than my patch. just check if the variable is present in both branches and a have mergeable type.21:03
<arjanb>i think a variable is always mergable21:05
<ArtemGr>even if it had null in one branch (typecheck.nice:79) and notNull in the other one (typecheck.nice:65)?21:07
<arjanb>merge would find the common supertype and that's maybe null21:08
<ArtemGr>i see
are these fixes sufficient to close the RFE 681385?21:29
<arjanb>if it all works yes21:32
<CIA-5>03artemgr * 10Nice/build.xml: Enable assertions when bootstrapping (-ea argument in jvmArgs).21:44
03artemgr * 10Nice/ (3 files in 3 dirs): RFE 681385 implemented.21:53
<arjanb>enable assertions is usefull for the testsuite too21:54
<bonniot>ArtemGr: are you missing the merge method?21:57
aren't you?
<ArtemGr>arjanb: it's ok, testsuite uses the same jvmArgs parameter. in fact the parameter was first introduced to speed up the testsuite with -Xms64M (this speedup was mentioned first in Makefile CVS history).21:58
<arjanb>i see21:59
<ArtemGr>bonniot: merge isn't required to implement RFE 681385. i think you shouldn't distract now implementing it. and i'm running out of my free time. ; )22:00
i just wrote a simple version, completely untested:
<ArtemGr>and it is ok to have a working implementation in the CVS before trying to implement the new merge one, anyway.22:03
<bonniot>indeed. history is your friend ;-)
this is intended for nice.tools.typing.Types
public static Monotype merge(Monotype m1, Monotype m2)
if (m1 == m2)
return m1;
Monotype raw1 = equivalent(m1);
Monotype raw2 = equivalent(m2);
TypeConstructor head;
if (Typing.testRigidLeq(raw1.head(), raw2.head()))
head = raw2.head();
else if (Typing.testRigidLeq(raw2.head(), raw1.head()))
head = raw1.head();
return null;
Monotype[] args1 = ((MonotypeConstructor) m1).getTP();
Monotype[] args2 = ((MonotypeConstructor) m2).getTP();22:04
Monotype[] args = new Monotype[args1.length];
for (int i = 0; i < args.length; i++)
args[i] = merge(args1[i], args2[i]);
if (args[i] == null)
return null;
TypeConstructor marker;
if (isSure(m1) && isSure(m2))
marker = PrimitiveType.sureTC;
marker = PrimitiveType.maybeTC;
return new MonotypeConstructor
(marker, new MonotypeConstructor[]{new MonotypeConstructor(head, args)});
let me know if you can make something with it, or if you have problems
<ArtemGr>thanks. i will have a few hours tomorrow morning, maybe i will look into it.22:07
<bonniot>this merge is not optimal since it does not search of a common supertype, only if one is smaller than the other22:10
but it should be useful already, and enough to test an algo that needs it
<arjanb>yeah it would handle 95% of the cases
<ArtemGr>have to go. salute. : )22:11
* ArtemGr leaves
<bonniot>arjan, this might be interesting: http://jdfa.sourceforge.net/22:14
also, i did not really review artem's patches yet. did you? are the testcases covering enough cases?22:29
<arjanb>i will look for more testcases22:32

Generated by Sualtam