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

Using timezone: Central European Time
* ChanServ leaves03:30
* ChanServ joins03:31
* arjanb joins10:01
* ArtemGr joins11:00
* ArtemGr leaves11:11
* ArtemGr joins11:14
<arjanb>hi
<ArtemGr>salute11:15
* ArtemGr leaves11:18
* ArtemGr joins11:19
<CIA-3>03artemgr * 10Nice/build.xml: New testengine has been separated into the "check_advanced" target.12:37
* arjanb leaves13:01
* someone joins14:29
* someone leaves14:30
* arjanb joins14:59
* bonniot joins16:29
<arjanb>hi16:35
<ArtemGr>??????
salute
<bonniot>hi17:45
<arjanb>ArtemGr: can you commit that testcase of yesterday?18:03
<ArtemGr>i've not prepared it yet
i have a preliminary one, but i want to beautify it18:04
in what folder should i place it, btw?
<arjanb>packages maybe?18:05
<ArtemGr>okay
<bonniot>ArtemGr: I agree in general that it's better to generate interfaces with methods inside them18:34
there is a recent RFE about this, as you might know
i'm going to look at your email in detail know, and we can discuss it
<ArtemGr>Arjan pointed me to that RFE, yes.
fine18:35
btw, should RFE autopost to nice-devel?18:42
<bonniot>good question18:48
used to. then i directed them to nice-info, but they still need approval there
<ArtemGr>okay. gmane.comp.lang.nice.general is nice-info?18:54
<arjanb>yes18:55
<bonniot>ArtemGr: if I understand the code correctly, you leave everything that was generated intact...19:03
in addition, you add an abstract method in the interface
and copy the full dispatch method in all implementing classes
is that correct?19:04
<ArtemGr>yes
<bonniot>ok, that should work, but it's wasteful
I think it could be made more similar to the way "Java multi-methods" are implemented19:05
each member method would only dispatch to those implementations that cover their member class as the first arg19:06
does that make sense?19:07
<ArtemGr>Main dispatch method location seems to be chosen in niceMethod.nice:getDispatchMethod - for methods implementing an interface the "receiver" tends to be an interface. Which isn't possible since interface methods does not have real code.19:14
<bonniot>right, that case needs to be supported19:15
but the receiver can be a class too
what i'm saying is that each of the dispatch methods that you generate could only consider a subset of all cases19:17
but this is only an optimization, so if you prefer, we can focus on getting this version ready for commit, and work on that afterwards19:18
<ArtemGr>i think the version is ready for commit, in fact. i've beutified it today, and i see no regressions.19:19
<bonniot>pk, could you let me see the current patch then?19:20
s/pk/ok19:22
<ArtemGr>sorry, it's a combined patch, with another thing i'm going to commit.19:23
http://rafb.net/paste/results/0IqVeL89.html
what do you mean by "could only consider a subset of all cases", i don't really understand. : )19:24
?
<bonniot>it would be better to isolate such patches19:25
for non-trivial changes, it's a good idea to work in a separate tree, which makes that easy
also, please don't mix unrelated changes (like the addition of maybeNull calls)19:26
it makes it easier to review the patch, and it's also better to commit them separately
now about the optimization:19:27
suppose you have interface I, class A extends I, B extends I
void foo(I); foo(A) {} foo(B) {}19:28
if I read correctly, in A.foo you will have tests for B, and in B.foo tests for A
<ArtemGr>i don't separate them now becouse i create the patch with few clicks from Eclipse. i'm not going to commit them together.
<bonniot>these tests can never succeed, and so can be optimized away19:29
<ArtemGr>about branches, the changes i am going to commit i consider trivial (not speaking about interfaces patch)
<bonniot>ok, but in the future thing about working in separate trees
what change are you going to commit?19:30
<ArtemGr>that one http://rafb.net/paste/results/lQd3Cn61.html19:40
ok, but in the future thing about working in separate trees - and spend a lot of time managing these trees just to show you a clean patch?19:42
<bonniot>lot of time managing? cvs update, that's all19:43
it's not just easier to show a clean patch, it's also easier to commit19:44
for instance, now, how are you going to separate the maybeNull changes separately?
<ArtemGr>don't i need to create a separate Eclipse project for that?
for the branch, i mean
<bonniot>i'm not very familiar with eclipse yet19:45
<ArtemGr>maybeNull patches doesn't change anything, they just remove the warning, isn't it so principial to separate them?
<bonniot>i think that a separate project might be the clean way to do it. is it really that complex?
it's not a big problem if you commit then together this time, but it's not the best practice19:46
suppose somebody want to review your patch to understand what it does (like I just did)
half of the time is spent reading some code, and then realizing, ah, that looks unrelated, I can ignore it19:47
also, it sometimes can happen that a patch needs to be reverted, and that's made more difficult if there are unrelated things in it (even trivial, but that you will want to keep)19:48
<ArtemGr>i thought you've spoken about CVS branches, not about difference directory to made a CVS update to, btw.
<bonniot>oh no, not CVS branches19:49
i agree that's not worth the trouble
CVS branches would only be good for a change that needs to live for a very long time before merging it, and I rather avoid them19:50
<ArtemGr>about management difficulty, yes, it will be difficult, to work on separate directories, becouse when i hack on Nice i don't really sure what i am going to do, i have no that knowledge yet. i'm not planning: this day i will add maybeNull's, and this day i will implement interfaces.
<bonniot>agreed
<ArtemGr>"and I rather avoid them" - that's why i overreacted.
<bonniot>ok
i know the problem you mention just above19:51
what I usually do is to have a tree i do day-to-day work
if I start a big change, then I can create a new tree
also, if you are in the middle of a big change, and you discover a small change that you would like to do, you can go to a clean tree, try the small change, commit it, then update the other one19:52
as long as unrelated changes are in different directories/files, you can even keep them in the same tree19:53
it's easy to generate the patch, or do the commit, only for the files/dirs that you select manually19:54
<ArtemGr>that is okay, not always things goes in a planned way though, but alright19:55
<bonniot>i know, sometimes it's a bit difficult. just try reasonably to do it, if it's not perfect once in a while it's not dramatic ;-)19:57
it needs a bit of discipline, but usually it's a good thing for you too, because it's easier to focus on one task at a time
so if you start to have one tree with many changes, it can be worth to spend a little time to separate them, so that later you can more easily focus on one at a time19:58
<ArtemGr>yeah, the problem is that i already trying to do it,19:59
i use CVS even for my standalone projects and i'm still trying to do that,
and now you begin to teach me how to use CVS.
in fact i should appreciate your concern. thanks.
<bonniot>sorry if i'm telling you things you already know. all the better then ;-)20:00
<CIA-3>03bonniot * 10Nice/src/nice/tools/unit/console/main.nice: Report number of failures/tests at the end of a run.20:03
<ArtemGr>"these tests can never succeed, and so can be optimized away" - you have something particular in mind?
remember, i spend two days, becouse i've needed a fix for this thing, not becouse i had spare time, so i'm probably will not be able to continue with something complicated, sorry.20:05
<bonniot>well yes: if A.foo is executed, then we know the code is not foo(B)
yes, i already said that we can consider this after it's commited
<ArtemGr>executed? or tested in typechecking?
<bonniot>executed, i'm speaking about the runtime behaviour20:06
<ArtemGr>hmm. we are talking about dispatch methods generated for interface implementations, right? when i've worked on the subject, there were times when i've generated duplicate methods, for example i had duplicate method entries in the interface, like foo$1. Therefore i think that if i do some work twice, it will be obvious - there will be duplicated dispatch methods in classes.20:10
About runtime part i don't understand, we generate dispatch methods, not tests.
<bonniot>the body of dispatch methods is made of instanceof tests20:11
<ArtemGr>ah, so we speaking of the subject i've not dvelved into. : )
<bonniot>yeah. but don't need to now <
;-)
i've made your inner class test a bit simpler and self-contained, by not depending on external classes like Comparable. should I commit it?20:14
testcase
<ArtemGr>all right, thanks20:15
should i commit the workaround?20:16
<bonniot>afterwards ;-)
this way, you can "link" the code to the testcase in CVS history (since you'll commit the removal of the 'bug' marker)20:19
<ArtemGr>you mean rcs2log or something else?20:21
<CIA-3>03bonniot * 10Nice/testsuite/compiler/packages/inner-classes.testsuite: 20:23
Imported classes with a $ in their name are mishandled and end up being
duplicated in the typechecker.
<bonniot>when I want to understand in what context a certain file has been change, I usually use a cvs diff -D command with dates around the revision date, to find which files it was changed together with20:24
I also believe cvs2svn will be able to merge simultaneous file changes into a single subversion changeset20:25
<ArtemGr>rcs2log generate ChangeLog, where it merges together consecutive changes made with the same description.20:26
<bonniot>ok, so that would be a good tool for that task, then. thanks for the info20:27
<ArtemGr>checked your testcase and my testcase with both the Nice compiler with my TypeScope patch just commented out and with a completely clean Nice compiler (from anonymous CVS). my testcase fails, your cleaned version doesn't.20:40
<bonniot>hum, I don't see how to tell rcslog what revision to document (I could get the whole history of one file)
strange20:41
isn't it a known bug?
java -cp classes nice.tools.testsuite.TestNice testsuite/compiler/packages/inner-classes.testsuite
run test engine
testsuite: testsuite/compiler/packages/inner-classes.testsuite
test engine finished
number of testcases: 1
successes : 0
regressions: 0
warnings : 0
known bugs : 1
it's not a success, just an expected bug20:42
do you get something else
?
<ArtemGr>ahh, i see. : )
<bonniot>since I don't commit the fix, i set the bug marker20:43
when you commit the fix, you can commit the removal of that marker
<ArtemGr>i just get used to my testcase failing right away. i just use "ant check" and see if the first testcase fails.20:44
<bonniot>ok, so that fix should go in ;-)20:45
for the other one, i'll annoy you once more: to beautify/minimize the patch, it's a good idea to avoid whitespace line changes20:46
now I run away before you beat on me (away for dinner) ;-)20:47
<ArtemGr>yeah, unfortunately we have different formatting styles and Eclipse ignore whitespaces when showing difference, so what you see is not displayed in Eclipse - i've removed all empty-line differences i saw there.20:51
bon appetite
<CIA-3>03artemgr * 10Nice/ (2 files in 2 dirs): A workaround for the situation when a class with a '$' in its name is searched for with '.' instead of '$'.21:05
<ArtemGr>throwed away the maybeNull things.21:13
here is the final result of two hours of beautification ; )
http://rafb.net/paste/results/LuOiNe27.html
<bonniot>french dinners...?22:12
<ArtemGr>not here22:13
<bonniot>no?
quick dinners?22:14
ok, the patch looks good
is it possible to write a testcase to check the functionality? probably using reflexion...
<ArtemGr>would be possible with javac in the new testing engine22:15
<bonniot>yes, but also with reflexion in the old one, I guess22:16
<ArtemGr>declare interface in Nice, then implement and invoke from Java.
declare interface in Nice, implement, then invoke from Java.
haven't thought about reflection...
too late for dinners22:20
* ArtemGr yawns and goes off to get some sleep22:24
* ArtemGr leaves
* bonniot leaves23:51
* ChanServ leaves00:30
* ChanServ joins
* arjanb leaves01:13