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

<bonniot>arjan, are you familiar with junit, or any other unit testing framework?00:39
<arjanb>no00:41
why?00:42
<bonniot>well, i think unit testing is a very important thing
i would like to start adding some unit tests to nice packages
for instance nice.getopt
(I had this idea because i found a bug in it)00:43
something i wonder is how much work there is behind junit
it is quite famous
but it seems to me that the basics of unit testing is very simple00:44
i just wrote one from sratch in nice in 5 minutes :-)
so i wonder:
either i am missing something
either most of the work is in the tools (for instance a GUI to report the results, ...) but that does not sound like much either00:45
either this is very trivial... :-)
maybe nice makes unit testing more straightforward00:46
in java you would typically create classes to hold the tests00:47
in nice you can just define package functions
also, we have assert, which helps
<arjanb>I don't know the details you're talking maybe seeing some code will help00:48
<bonniot>if you are interested, you should maybe start by reading some existing documentation00:49
http://junit.sourceforge.net for instance
here is a sample of what nice.unit can do so far:
package test;00:50
int customAdd(int x, int y) = x + y;
void test()
{
assert customAdd(2,3) == 5;
}
you compile that
then:
java -ea nice.unit.fun test
it will find the test method by reflection, and run it00:51
<arjanb>so instead of testing a whole program you test one class/package at a time
<bonniot>yes, this is unit testing00:52
the testsuite we have in Nice is basically an acceptance test
both methods are useful and complementary of each other
unit tests are good, because if they fail, you have a very precise idea of were the problem is00:53
acceptance tests are good, because they can test complex interraction between different parts, and they test the actual behaviour of the whole program00:54
but you can see its limits: if you write a testcase for nice to test that some expression is not well-typed, and you make a syntax error in the testcase, you can think it failed as expected. but in fact it fails for another reason, and you are not testing the right feature00:55
<arjanb>I will look further into unit testing some time but for now I have doubts if it's worth the effort to use in the nice compiler00:58
<bonniot>i'm still planning to use the testsuite for most of the testing
<arjanb>though it might be useful to test the parts that can't be covered by the testsuite00:59
<bonniot>but unit testing is useful too, to test libraries
yes
and the effort seems very small
for instance, i don't see you to test nice.getopt with the testsuite
you->how01:00
<arjanb>yes
i think i get enums working tomorrow01:21
goodnight
* bonniot joins01:49
* bonniot leaves
* alexgreif joins08:54
* bonniot joins08:58
* alexgreif joins09:10
<bonniot>hi09:11
<alexgreif>hi!
slept well?
<bonniot>well done with the plugin!
<alexgreif>have you tested it?
<bonniot>yeah thanks
not yet
did you spend the night on it? ;-)
<alexgreif>oly one hour :) it was the same mechansm as with the "main packege name"09:12
<bonniot>good
<alexgreif>first I wanted to make it in the pretty List form, but the I realized , that I would take too long.
<bonniot>do you think it would be difficult to get the output go in the console (or the task window)?09:13
yeah, that does not matter at this point
it's good to have a usable version first
the output would help, because now everything goes in the terminal
<alexgreif>where does it go now? I always start a new workbench to test it. On my system it lands in the console of the old workbench.
<bonniot>so you have to keep it open, but you also want the eclipse window to be fullscreen...09:14
<alexgreif>eclipse terminal?
<bonniot>what is a workbench?
no, x terminal
<alexgreif>:)
the workbench is the screen that you see when you start eclipse
<bonniot>are there eclipse terminals?
the main window?09:15
<alexgreif>there are eclipse console
yes
<bonniot>so if you start a new workbench, it seems eclipse connects its stdout to the console of the old one
<alexgreif>wait, I install the plugin on my eclipse an see where the output lands
yes09:16
I put the plugin folders in the "plugins" folder, an I start now eclipse...09:17
oops, you are right, nothing is outputted to the console :(09:21
then all aoutout goes to the starting console
I I start a workbench2 from wb1 then everything goes to console of wb1.09:22
<bonniot>it should go in the console of the current workbench
so to wb2, no?
<alexgreif>no
yes it should go in the console of the current workbench
I shoulf ix taht in the proto
fix09:23
<bonniot>that would be nice
then i think it would be truly usable :-)
<alexgreif>ok, but not before this evening. or maybe in the next days
<bonniot>ok
how did you leave the channel the first time this morning?09:24
it did not get logged...
<alexgreif>I think with /quit
I cann leave now with /leave to test all occasions.
* bonniot joins09:25
<alexgreif>I saw: *<* Signoff: bonniot ("Client exiting")
<bonniot>no log09:26
i'll look at that sometimes
<alexgreif>with /leave or with /quit?
<bonniot>i did /quit
<alexgreif>on irc it was logged.
<bonniot>yes, sure09:27
<alexgreif>I mean I saw your signoff
maybe there is a bug in the java api
<bonniot>the bot must just not be listening to some message
<alexgreif>yes
Why is it called "bot" or "robot"09:28
<bonniot>because it looks like a normal (human) user, but in fact it is a program
<alexgreif>ok
<bonniot>some do pseudo-conversation ... :-/
<alexgreif>and pseudo-intelligent conversation :)09:29
<bonniot>actually i did not experience that :-/
are you familiar with jUnit or XUnit?
<alexgreif>neither I , but I think with AI it would be possible.
JUnit... the first testsuite was written in that :)09:30
<bonniot>Abstract Interfaces? ;-)
<alexgreif>in nice?
<bonniot>i wrote a small unit testint package in nice09:31
you can read about it in the irc log
<alexgreif>good
<bonniot>i would like opinion from experienced users of unit testing
<alexgreif>with jUnit testsuites?
<bonniot>it does not depend on junit
<alexgreif>I will C6ook at it. are there any sources?
<bonniot>no, i wrote it in jvm bytecodes by hand :-))09:32
yes, there are
they are just on my disk at the moment (in the eclipse workspace :-)
<alexgreif>I dont want to read bytecode :))
<bonniot>why, it's not bad. much better than machine assembler. not bad at all...09:33
:-)
<alexgreif>btw Im not an experienced jUnit user :) Onece I used it.
<bonniot>you can still have an opinion
<alexgreif>ok :9
<bonniot>are you busy now?
<alexgreif>in 15 minutes, yes09:36
can we discuss it in 15 min? :)09:37
<bonniot>ok09:38
<alexgreif>about he bytecode?
<bonniot>?
<alexgreif>what should we discuss? the bytecode for jUnit?09:39
<bonniot>junit
<alexgreif>ok, go on :)
<bonniot>we can discuss bytecode if you feel like it. but i was just joking
<alexgreif>ah, ok :)
<bonniot>oh, you are free now, for 15 minutes?09:40
14 now?
:-)
<alexgreif>Im waiting for an admin, I have a strange sitution here
yes 13 min
<bonniot>i think the best would be that you read the log first. it is dated today i think, just at the start
<alexgreif>I see you are in a joking mood today?
ok. 09:41
<bonniot>http://pauillac.inria.fr/~bonniot/nice@freenode/2003-06-18.html
<alexgreif>why y is the testsuite not sufficient?09:43
ah, ok, I see the answer ...09:44
<bonniot>i explain in on the log i think
:-)
and nice.unit is not only for the compiler
it is for any nice program
<alexgreif>so you can test units in an existing program, thats good!
<bonniot>wdym existing?09:45
<alexgreif>the -ea option is new?
eg. flow4j
<bonniot>this is an option of java since 1.4
yes, if you add test methods to flow4j
<alexgreif>oh :)
<bonniot>it cannot guess the tests to do yet ;-)
-ea enables assertions, otherwise they are not checked by default in Sun's jvm09:46
<alexgreif>no problem, but the tests have only to be package methods?
<bonniot>do you mean that it is restrictive?
<alexgreif>no I mean what needs to be done to have a method that can be unit tested? only package scoped method?09:48
<bonniot>yes, declare a package method whose name starts with "test", with no arguments
simple, isn't it?09:49
so you don't even need to depend on anything to compile the tests
<alexgreif>ye :)
<bonniot>like for junit tests, you need to have junit installed to compile them
<alexgreif>its a good Idea!
<bonniot>which means that you might not want to put them together with the code09:50
i think the tests should be close to the code they test
<alexgreif>jUnit has a nice gui thats all, but we dont neet this
<bonniot>it makes it a good doc of the code, and you can keep them synchronized mroe easily
it can come later
<alexgreif>maybe it has its adwantages if the tests are in a separate package, then they dont clutter the code09:51
<bonniot>i have defined a TestListener interface, much like the CompilationListener :-)
it's not clutter
<alexgreif>but one can define a test.nice in the package, and then its fine !
<bonniot>yes, it can be in a different file
but it should definitely be in the same package
the idea is that tests are local09:52
<alexgreif>yes, I understand
yep
<bonniot>they are an important part of the development, together with doc comments and types
so if you keep them close, it's less likely that they get forgotten
<alexgreif>what we need is javadoc :)
<bonniot>nicedoc you mean? :-)
yes, that too
<alexgreif>yes, nicedoc :) ok, I have to go :((09:53
<bonniot>ok, cu
<alexgreif>cu
* alexgreif leaves
* bonniot is away: working...09:54
* arjanb joins10:49
* bonniot is back (gone 01:10:12)11:04
hi arjan
<arjanb>hello11:05
<bonniot>what's up?11:06
i mean what's new :-)
<arjanb>nothing yet
<bonniot>alex made a new version of the plugin11:07
did you ever try it? do you have eclipse installed?
<arjanb>I have tried the second version and yes11:08
<bonniot>it's almost usable now :-)11:09
do you have plans for today?
<arjanb>finishing the simple enums11:10
<bonniot>good
i have to work on my thesis now
later i will look at your diff11:11
<arjanb>ok
<bonniot>good luck!
* bonniot is away: working...11:12
* bonniot is back (gone 04:45:26)15:57
<arjanb>any news?17:03
i think i can implemented the visibility modifiers so i have started with that17:16
<bonniot>did you give up with the enums?18:08
<arjanb>no i only started to write ugly code18:09
<bonniot>?18:10
<arjanb>the code I need to write for enum becomes a bit ugly becauses subclasses inner classes is not really possible18:12
<bonniot>in java?18:13
<arjanb>yes
<bonniot>you mean
class A { class B extends A {} } 18:14
?
why do you need that, and why doesn't it work?
<arjanb>i want to subclass GlobalVarSymbol for enum elements18:15
but it's a non static inner class
<bonniot>inner to what?18:16
<arjanb>to GlobalVarDeclaration
<bonniot>why don't you create a new class for enums?
so they don't complicate existing code18:17
<arjanb>I have a new classes for enums now18:18
but then I have to change quite some thing in pattern.java because i can't reuse the dispatch on reference part
<bonniot>why not? the new class can be a subclass of an existing one, so that most behaviour is shared18:19
<arjanb>class EnumDefinition extends Definition { class EnumSymbol extends GlobalVarDeclaration.GlobalVarSymbol {} }18:21
this is not possible
<bonniot>why not?
oh because GlobalVarSymbol is not static?18:22
does one EnumDefinition correspond to a whole enum: enum Foo { A,B,C } ?18:23
<arjanb>yes18:24
<bonniot>and EnumSymbol? is it for Foo, or for A ?
<arjanb>for the elements18:25
<bonniot>so maybe what you need is:
class EnumDefinition extends Definition { class EnumElement extends GlobalVarDeclaration {18:26
class Symbol extends GlobalVarSymbol {} } }
would that be valid java ?
an EnumElement should be a special kind of GlobalVarDeclaration, right?18:27
<arjanb>yes but I only need a special symbol
<bonniot>so? what is the problem?18:28
<arjanb>that I'd rather avoid inner classes
<bonniot>why?18:29
the alternative would be to create several toplevel classes18:30
but i think it makes sense to regroup all these three in the same file18:31
and in Java you do that with inner classes
<arjanb>I don't like inner so I have never used them so i don't know to handle them right
<bonniot>maybe it's time to learn ;-)18:32
non-static inner classes are a bit tricky in some circusmstances
so a good rule is to declare inner classes static if they don't need a link to the outer class18:33
if they need it, but you experience problems, you can also declare them static, and provide the link explicitely in the constructor and store it in a field18:34
this is basically how inner classes are compiled by javac
static inner classes are really simple
<arjanb>yes
<bonniot>it is just a syntactic change, that their name is prefixed by the other class
no difficulty
ok?18:35
<arjanb>if they just had allowed multiple classes in a single file in Java then this complexity was not needed
<bonniot>it's not completely true, if you think of anonymous classes18:36
<arjanb>I can try making them static
<bonniot>ok
i applied your diff for the dispatch18:37
do you have a testcase that fails?
what is the problem?
(btw, it was really a great idea to sort testcases by date :-))18:38
<arjanb>you mean the diff for checking class constraint when resolving the method body def to method declaration18:39
<bonniot>yes18:40
<arjanb>don't you have a failed testcase then?18:41
<bonniot>well i just started the testsuite18:42
is there one in the testsuite?
<arjanb>yes
<bonniot>ok, do you know the file?
<arjanb>the one the the super methods
methods\super.testsuite 3rd last testcase18:43
<bonniot>thanks18:44
only it's methods/super.testsuite ;-))18:45
* arjanb is away for dinner18:53
<bonniot>the problem is not related to super, because replacing super with false gives the same results
<arjanb>I'm back did you find anything?19:21
<bonniot>yes, the case is working now. and all the cases in super19:26
i will check the whole suite
the motivating case is still fixed...19:30
<arjanb>great where was the problem?19:34
<bonniot>with setMarkedKind19:35
it is the first thing to be done
before doing any of the subtypings19:36
* arjanb joins19:39
<bonniot>Did you plan to work more on that feature?19:40
<arjanb>on what?19:41
<bonniot>the change in Pattern
<arjanb>it does work now right?19:42
I don't see any place where class constraints aren't enabled yet19:43
<bonniot>there is a related bug report. do you think this is closing it too?19:45
<arjanb>which bugreport?
<bonniot>looking...19:46
http://sourceforge.net/tracker/index.php?func=detail&aid=750422&group_id=12788&atid=11278819:49
no, it seems i was just wrong when I said the dispatch would do a false negative19:52
this is already fixed :-)
i just tried that case
it would readlly be nice to have Pattern cleaned up, using subclasses19:54
<arjanb>yes but that's not easy because the patterntype is only known after resolving19:55
there one issue that i won't touch related to class constraints:19:56
abstract interface AI {}
class X<T | T : AI> {}
T is not a class19:57
<bonniot>true about patternType19:59
i wonder if we should allow20:00
<AI T> class X<T> {}
because that would be the logical syntax
T is a type constructor variable in that case, not a type variable20:01
<arjanb>the syntax the same as with method's make sense20:02
<bonniot>yes, but isn't it nice for the common case to write20:04
class List<T> and not <T> class List<T> ??
<arjanb>yes but how often do you write new parametric class compared to methods20:06
<T> interface List<T> extends Collection<T> {} isn't that bad
<bonniot>so i commit the change to Pattern and MethodBodyDef, ok?20:11
<arjanb>yes
<String T> class StringList implements List<T> {} looks better as20:13
class StringList implements List<String T> {}
if it will be possible20:14
<bonniot>i think it should be
class StringList implements List<String>
but i don't see why such a class would be useful, by the way
<arjanb>no but there may be other classes where it can be useful20:16
<bonniot>yes20:19
i was wrong about the bug report and the coverage
it is still not done properly when there are constraints it seems:
package test;20:20
class B {}
class A<T | T <: B, B <: T> extends AbstractSet<T> { }
add(a@A, b@B) = super;
Method <E> nice.lang.boolean add(java.util.Collection<E>, E) is not completely covered:
no alternative matches (test.A, java.util.Hashtable)
i thought this was already implemented20:21
i'm sure constraints are used in coverage, i did it
<arjanb>but somehow they seems to be ignored in this case20:23
<bonniot>i'll add the testcase and look at it sometime20:24
how are enums doing?
<arjanb>working in single package case though I didn't make the inner classes static yet20:25
class B {}20:27
class A<T | T <: B, B <: T> extends AbstractSet<T> { }
add(a@A, b) {
B x = b;
return true;
}
this does compile
<bonniot>yes, because you don't dispatch @B20:29
so it covers everything
but it should be enough to cover B, not everything20:30
for enums: that's quite good already. is it more complex with several packages?
i thought that was already handled for reference dispatch
for the inner classes, you don't need to make them static if it works and if you need the parent this20:31
i'm gone...20:34
* bonniot is away: ...
* bonniot is back (gone 00:57:11)21:31
<arjanb>enums are finally working23:46
i have had a bad day23:48
i will check the source tomorrow when i hopefully have a clear mind again23:50
only if you use enums incorrectly you can get strange error messages23:54
<bonniot>how many classes are affected?00:00
well done, by the way!00:01
<arjanb>3
<bonniot>+ new ones?
<arjanb>inclusive
<bonniot>that's quite good
<arjanb>you haven't seen pattern.java yet00:02
<bonniot>for the error message, that's something we can work on
:-/
is your code cleaned up already?
<arjanb>no
<bonniot>after it is, tomorrow, you can either commit it, or send a diff to me if you prefer00:03
<arjanb>that bad error message is probably caused by the hack to make this work:
enum Color {red, blue, green}
void foo(Color);
foo(=red) = println("red");
foo(=blue) = println("blue");
foo(=green) = println("green");
<bonniot>what hack?00:04
<arjanb>to make the coverage test understand that foo is fully covered
<bonniot>yes, that's expected00:05
enums are special in this way, that the list of all cases is known and fixed
do you have many testcases?
<arjanb>no00:06
<bonniot>maybe not many are needed
just some for the coverage, so expected failures00:07
and multi package cases
<arjanb>yes i will do that tomorrow and the cleanup
<bonniot>good00:08
why was is a bad day?
<arjanb>because i hadn't a clear mind
<bonniot>in that case it's best to take a pause :-)00:09
enums can wait one more day ;-)
<arjanb>yes and i wouldn't mind if they didn't get in 0.9.0
<bonniot>we'll see how it goes00:10
<arjanb>is there anything else to be done for 0.9.0 ?
<bonniot>i would like the method specialization to be in there, but that's my part00:11
<arjanb>so there are still problems with that?
<bonniot>there is no must
well, i think it works well now00:12
but i would like a nicer implementation
and there are cases i want to test
<arjanb>i see
<bonniot>and because i spend much time on my dissertation, and the rest on bug fixing, it's not moving fast these days :-/00:13
but we made progress, now there are only 4 open bugs on SF00:14
<arjanb>well the dissertation should have priority isn't it
<bonniot>yep!
<arjanb>and i can try to keep to a bit of speed in the development00:15
<bonniot>that's great
it's good to see several people working at the same time
making progress on different fronts00:16
i just read a blog entry about Java One, where Per Bothner (Kawa's author) gave a speach
<arjanb>yes
link?00:17
<bonniot>He mentioned two languages using gnu.bytecode, one being Nice
http://www.webweavertech.com/ovidiu/weblog/archives/000271.html
one interesting point for me was the remark about the performance of code generation00:18
you don't know about rpm generation, do you?00:21
<arjanb>no
btw this channel isn't announced on nice-info yet00:25
<bonniot>true00:30
one less open bug :-)00:48
(rpm)
<arjanb>:-)00:49
the speed of the compiler hasn't changed significant since 0.7.901:03
flow4j in the automatic tests becomes useless becomes it isn't updated for some time01:10
2e becomes->because01:12
<bonniot>speed: that's good news, since we did not try any optimization. but we added new features that do not slow it down
ddi you check why it failed?01:13
it because the Ant plugin is not available (neede to drive the build)01:14
and Ant is not available because:
Building the Ant task definition...
src/nice/tools/ant/Nicec.java:287: cannot access bossa.modules.CompilationListener
file bossa/modules/CompilationListener.class not found
Compilation compilation = bossa.modules.fun.createCompilation(console);
^
<arjanb>no also when building by hand because of duplicate local vars 01:15
<bonniot>this looks like the visibility problem, that was already fixed (only more than 24 hours ago i think)
ah ok
well, this change is not even published, is it?01:16
no it's not surprising if flow4j fails for that
you should tell alex to update it, though :-)
if you meet him...
<arjanb>or he reads this01:17
<bonniot>:-)
then you should explain more in details what the problem is... :-)01:18
i'll leave now...
rest well, so you are in shape to finish the enums tomorrow :-)
<arjanb>goodnight01:19