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

Using timezone: Central European Time
* bonniot leaves02:09
* bonniot joins10:23
* rubber joins11:16
hello
<bonniot>hi11:28
sorry for yesterday, i was afk
how are you doing?
<rubber>No Problem. Quite busy at the moment (not at work, but with private things)...11:29
How about you?
The last two weeks I have only be online about 6 hours... That's quite few for me...11:30
But I've tried to follow all the upcoming discussions on the ML.
<bonniot>then you must have used most of your 6 hours on that ;-)11:31
i'm well, thanks
<rubber>Yes, mostly reading mail.
<bonniot>how is Nice usage at your company?11:32
<rubber>As already mentioned, it becomes the most important language.
<bonniot>:-)
<rubber>Some parts are still native, but ok.11:33
<bonniot>you should really write that document about your experience sometime...
<rubber>The latest changes make me headache more and more.
I really should.
<bonniot>native = Java or C?
<rubber>You will get a medal in my document. :)
<bonniot>which changes?
:-)11:34
<rubber>It was something, that needs a change with the runtime nice classes...
C code.
<bonniot>called with JNI?11:35
<rubber>yes
<bonniot>that change was because of gcj compilation?
<rubber>gcj compilation cause more and more troubles,...
But we need it, cause most clients don't want a JVM.11:36
Btw. do you know if it would be legal to deliver a JVM (free of charge of course).
<bonniot>i don't know about Sun's JVM, but it _might_ be possible, i vaguely recall11:37
<rubber>printStackTraceWithSourceInfo <-- this is now used in all generated classes, right?11:38
<bonniot>in the class that has the main method
is that a problem?
<rubber>Well, not directly, but many things that lead to the same... gcj cross to mingw32 is mostly available for java-1.3... nice is no longer compilable with jdk-1.3 (at least with sun's jvm)... so at the moment I cannot produce new nice runtimes...11:40
<bonniot>it has not been compilable sometimes recently with 1.3, but it is now:11:41
http://nice.sourceforge.net/tests.html
<rubber>And the "abstract classes are not serilizable" bug in gcj is even present in gcc-3.5!
Yes, that was the blackdown jvm... I have to try... I just forgotten it.11:42
<bonniot>that should not matter
i know compilation on 1.3 was broken until yesterday
<rubber>?
<bonniot>you should first try to upgrade
blackdown vm or sun vm should behave the same11:43
when did you last try compilation on 1.3?
<rubber>make complete gives me the error with that was impossible (at least to the code lines, the compiler complains about).
Sunday...
No, monday.11:44
<bonniot>it was fixed yesterday
at 13:13 CET :-)
<rubber>So, it was an error?
<bonniot>no, it was just code in nicedoc that used a method introduced in JDK 1.4
<rubber>Ah, the replaceAll funtion... 11:45
<bonniot>yep
<rubber>I also used that and had to write a helper.
<bonniot>there is one in Nice's CVS now :-)
nice.tools.util.JDK
<rubber>I've updated.
GPL?
LPGL?11:46
Guille?
<bonniot>must be GPL like the rest of the compiler, I did not think about it
I could add the exception if you like
it's not needed for running nice programs
<rubber>I just mention it, cause I saw also some discussion about nice and its license...11:48
<bonniot>yes, but the issue is about the runtime
btw, the author of the gnu.* classes told me he would give a license to use the modified versions used in Nice :-)
<rubber>Great!11:49
<bonniot>and NiceSwing will be changed as soon as Martin is back
so there should be no problem left
<rubber>What about NiceSWT. How far is Jason?
Stack trace:
Exception in thread "main" java.lang.Error
java.lang.Error
at mlsub.typing.MonotypeConstructor.setId(MonotypeConstructor.java:119)11:50
at nice.tools.code.Types.setMarkedKind(Types.java:656)
at bossa.syntax.Pattern.inDomain(Pattern.java:319)
...
<bonniot>Jason said he was starting on Sunday I think
<rubber>Warning: the above stack trace has wrong line numbers for Nice methods.
Use a JVM version 1.4 or later to get the correct line numbers.
<bonniot>we saw that before
<rubber>But with jvm-1.4 I don't get the error. 11:51
<bonniot>i think we said it was a vm bug
<rubber>This was the error I meant.
Yes, that was because I said, I have to try the blackdown version.
<bonniot>what vm is that? is this during bootstrap? which phase?
ok, i understand
forgot about that
for JNI, you need to write a stub in Java?11:54
<rubber>native is still in JAVA classes... Not moved to nice up to now.
Hey :-) :11:56
rubber@tower:~/Work/WorkingDirectory/Nice > java -jar share/java/nice.jar --version
Nice compiler version 0.9.6 prerelease (build 2004.02.18, 11:01:00 UTC)
Compiled using JDK 1.3.1
<bonniot>you mean that part of the program is in Java anyway?
:-)
<rubber>blackdown.
<bonniot>ok, so there's a bug in Sun's VM
shame
<rubber>Yes, that are parts, that are still in java. But as already said, we're going to move it all.
<bonniot>ok :-)11:57
<rubber>I still have to get more familar with the package level...
But you're right, there is no nicech
<bonniot>i suppose at the moment you would still need a java class for doing JNI
sounds like a funny name :-)11:59
<rubber>What about the task about independent compilation...
<bonniot>?
<rubber>...we had that a few months ago...
<bonniot>please recall me briefly12:00
oh, about -R ?
<rubber>...it was about compile a class in a package and ... what was the point, wait a moment, I recall.
Ah, it was not only independent compilation is was mostly about dynamic loading/resolving.12:01
It was also on the ML at under Subject: [Nice-info] Question about generated code12:02
<bonniot>checking the ML12:03
<rubber>http://sourceforge.net/mailarchive/forum.php?thread_id=2745162&forum_id=492212:04
Ahhh, I don't like the sf ml archive... 12:05
<bonniot>http://news.gmane.org/gmane.comp.lang.nice.general/cutoff=84912:06
(t's not that message, but the point is that gmane is much nicer)
<rubber>Ah, much better!
<bonniot>:-)
in your initial example, you could not do it in java, because the dispatch is on an integer, right?12:07
<rubber>I just wanted to find a example...12:08
<bonniot>i think i see what you mean, though12:09
<rubber>Syntax/semantic might not be correct...
;)
<bonniot>if you add a new class, how can the old code know about it and load it? by using reflexion?12:10
how does it know the name of the class?
<rubber>yes, reflexion is widly used to find "plugins" isn't it?
<bonniot>how does it know the name of the class?12:11
<rubber>I don't know exactly, but I think, search for some metadata in the jar to find the start class... I thing that is the way, JEdit also does it...12:12
<bonniot>and you can add plugins while the app is running?12:13
<rubber>JEdit can manage this.
but that is plain java and I want to find a way to do it with nice.
<bonniot>ok12:14
<rubber>What do you propose?
<bonniot>i read about the plans for Eclipse 3.0, and they were saying that at the moment you need to restart Eclipse, but they were planning to use a library that reloads code dynamically when it has changed12:15
one option would be to do that
you use the compiler normally to produce your new version, and that library (probably a fancy classloader) can reload the classes that have changed, and execution continues12:16
how does that sound?
<rubber>well, that would solve the problem of newer versions (if it would work ;-)12:18
but what about the plugins?
saying to extend dispatching...
...when plugin B is loaded?12:19
<bonniot>you can still use the first solution, no?12:20
<rubber>first solution, so I would need to "auto"-reload fun/dispatch in package p; ok, but then I would need ('count of plugins')! many fun|dispatch classes (don't know, if faculty is right)12:22
<bonniot>no, you have only one p.dispatch that takes all the plugins into account12:23
<rubber>so, p.dispatch has to be changed whenever a new plugin gets created... How to handle this, if many different vendors create plugins?12:24
<bonniot>no pb12:25
you don't need the source of the plugins
you discover the plugins, regenerate the dispatch classes, and reload them12:26
<rubber>"discover the plugins, regenerate the dispatch classes"
?
<bonniot>i mean that this can be done automatically by the runtime12:27
<rubber>How?
<bonniot>it would need a library to do that, of course12:28
nice.plugin :-)
<rubber>:)
<bonniot>how much do you need atm?12:29
<rubber>;-)
<bonniot>?
<rubber>Now, that I have a working 1.3.1 nice version, I'll get a new nice.dll and so I can manage to produce again win32 nice-compiled native code. So, the plugins will be the next part...12:30
<bonniot>why do you need plugins, exactly?12:31
<rubber>Several fields; protocol specific things, connections, data handling at all12:33
<bonniot>is it that you are running a server that you cannot stop?12:34
<rubber>Yes.
Ahh, it's a pity. I just thought, I can create a native nice compiler:12:35
rubber@tower:~/Work/WorkingDirectory/Nice > gcj -c share/java/nice.jar --classpath=/site.opt/Java/Ant/lib/ant.jar
bossa/util/Internal.java: In class `bossa.util.Internal':
bossa/util/Internal.java: In method `bossa.util.Internal.printStackTrace()':
bossa/util/Internal.java:32: error: class 'bossa.syntax.dispatch' has no method named 'printStackTraceWithSourceInfo' matching signature '(Ljava/lang/Throwable;)V'
Do you know, where this comes from?
<bonniot>you must be using a wrong nice.jar
how dod you create it?
how do you ...
<rubber>Nice compiler version 0.9.6 prerelease (build 2004.02.18, 11:01:00 UTC)12:36
Compiled using JDK 1.3.1
<bonniot>yes, but how? are you using make? with what target?
<rubber>make complete
<bonniot>i'll try12:37
<rubber>gcc-Version 3.4.0 20040206 (prerelease)
<bonniot>did you try java -jar share/java/nice.jar --version12:39
(just checking it's the same version you are running and using)
ok, i get the same. I'll look
<rubber>I'm just using make fixpoint... Please wait...
Ok.
The blackdown jdk is faster.12:40
<bonniot>how much faster?12:43
<rubber>Well, not measured up to now. But noticeable.12:44
<bonniot>:-)
<rubber>dispatch.java.bootstrap does contain the printStackTraceWithSourceInfo method
<bonniot>i know what's going on :-)12:45
<rubber>Yes, a bug found?12:46
The method gets not written within the nicec compilation part, right?12:47
and the method is lost from the bootstrap dispatch version, right?
...lost, cause overriden during the nicec compilation part...12:48
<bonniot>yes12:49
<CIA-3>03bonniot * 10Nice/src/bossa/ (3 files in 2 dirs):
Uses consistent names for the printStackTraceWithSourceInfo during the two
phases of bootstrap.
<bonniot>fixed :-)12:50
<rubber>why this has caused no troubles up to now?12:51
<bonniot>this is a very recent change12:57
<rubber>Great, seems so, as if we now have got a native nice compiler.---
<bonniot>but also, gcj finds such errors earlier than running in a jvm12:58
:-)
what is it useful for? is it faster?
<rubber>rubber@tower:~/Work/WorkingDirectory/Nice/dd > gcj -c nice.jar
rubber@tower:~/Work/WorkingDirectory/Nice/dd > gcj --main=nice.tools.compiler.console.fun -o nicec nice.o
-rw-rw-r-- 1 rubber users 1263343 2004-02-18 13:03 nice.jar12:59
-rw-rw-r-- 1 rubber users 9644172 2004-02-18 13:04 nice.o
-rwxrwxr-x 1 rubber users 8408656 2004-02-18 13:04 nicec*
rubber@tower:~/Work/WorkingDirectory/Nice/dd > ./nicec
Usage: nicec [OPTIONS] PACKAGE
Type "nicec --help" to list the options
Yes, it definitly will be faster.
<bonniot>you need to make tests13:00
sometimes gcj is faster, sometimes a jvm is faster
<rubber>Ok, give me a testprogram
<bonniot>startup should be faster with gcj, for sure
don't you have one? :-)
<rubber>I've encountered a few programs now, and with hard io, gcj is faster.
Yes, but give me something, that you choose...13:01
I think, I would be not fair :)
<bonniot>you could try compiling nice-swing
<rubber>Ok, I'll do.
<bonniot>BTW, did you report to gcj (or classpath?) about:13:03
class 'java.lang.Thread' has no method named '<init>' matching signature '(Ljava/lang/ThreadGroup;Ljava/lang/Runnable;Ljava/lang/String;J)V'
it would make your life easier :-)
<rubber>Well, it is a gcc-3.3 version.13:04
<bonniot>gcc 3.4 has it?13:05
<rubber>Yes.
<bonniot>so do you still need to work with JDK 1.3?13:06
<rubber>rubber@tower:/site.data/ZippedFiles/WinLinux/Java/nice/swing > ./nicec --sourcepath src --destination targets nice.ui.common
Classpath component null does not exist
Exception in thread "main" java.lang.NullPointerException
:(
<bonniot>you need to add --runtime .../nice.jar I think13:08
otherwise it does not find nice.lang...13:09
<rubber>I'll give it a try.
:)13:10
Ok, that works, but now we get errors like: 13:11
nice/ui/common/types/beans/java.nice: line 61, column 45:
BeanContext has 1 type parameter
<bonniot>hum, that would need more serious debugging13:13
<rubber>nice/ui/common/types/beans/java.nice: line 216, column 52:
Ignored retyping because The types of the arguments don't match the declaration:java.beans.BeanInfo java.beans.Introspector.getBeanInfo(java.lang.Class,java.lang.Class)
<bonniot>it might be gcj's fault, or it might be nicec's
* arjanb joins
<rubber>Ignored retyping because no method named instantiate with 3 arguments was found in class java.beans.Beans
nice/ui/common/types/beans/java.nice: line 189, column 89:
Ignored retyping because no method named instantiate with 4 arguments was found in class java.beans.Beans
<bonniot>hu, that looks like gcj does not have the same API as the JDK here...13:14
<rubber>Yes.
Hi arjan
<arjanb>hello
<bonniot>hello ar:
jan
i know they have a tool to automatically compare their API to the JDK's
so it seems the native version of nice works ok, but the APIs have small problems13:16
<rubber>"java.beans
Believed to be functional and complete, should be compatible with JDK 1.4."
<bonniot>you could check the specific methods nicec complained about13:17
<rubber>Yes, as always. That is my "normal" problem...
<bonniot>do you use Swing?
<rubber>No, SWT.13:18
<bonniot>so you won't have problem with that :-)13:19
<rubber>No,... The libjava Beans class is not jdk-1.4 conform :(13:20
So, it is clear, that the native nicec complains about.13:21
Ok, let us try something else with less dependencies.
<bonniot>http://japi.sab39.org/htmlout/h-libgcj-jdk14.html13:25
according to that, libgcj is 100% correct on java.beans
<rubber>;(
<bonniot>could it be that the CVS version is correct?13:26
then it's :-)
<rubber>That is possible...13:27
Ahh, it is a pity, but a nicec.exe I'm not able to produce with my maybe outdated cross mingw compiler...13:28
<bonniot>how did you produce it before? oh, a linux binary?
http://japi.sab39.org/htmlout/h-jdk14-libgcj.html
according to that java.beans is only 75% OK against 1.413:29
i guess it means that all the methods in libgcj are correct, but that some are missing13:30
<rubber>Yes, that is correct
Correctly
<bonniot>(it's testing in both directions)
<rubber>That is what I saw in the sources.
<arjanb>wow a busy day on the mailinglist
<bonniot>yes :-)
<rubber>Ok, I'll have to build a new cross compiler. Is someone interested in a nicec.exe?13:35
<bonniot>not me :-)13:36
<rubber>;)
Maybe arjan
<arjanb>not useful for me13:37
<rubber>Ok, sualtam is compilable through nicec*13:38
Ok, I did the following:13:41
date +%s > time && nicec -R --sourcepath src --destination destination --runtime ../Nice/dd/nice.jar --classpath lib/martyr.jar sualtam && date +%s >> time
...--> native 6 seconds and java 7 seconds.
ok, it is a small project.13:42
<bonniot>jsut use:
time nicec ...
it will be easier and more precise :-)
and you get the processor time in addition to the wall clock time
<rubber>Ok: native:13:43
real0m6.104s
user0m5.880s
sys0m0.090s
java:
real0m7.255s
user0m4.700s
sys0m0.100s
<bonniot>did you run several times in turn each?13:44
(that was 20% faster, not bad. would be interesting how it goes for larger programs)13:45
although, java is actually using _less_ CPU. interesting13:46
<rubber>ok, avaerage of several times: native13:47
real0m6.038s
user0m5.870s
sys0m0.040s
java13:48
real0m7.130s
user0m4.610s
sys0m0.130s
<bonniot>ok. no big change13:50
thx
<arjanb>no surprising numbers
<bonniot>what is your goal? faster compilation?13:51
<rubber>No, this was just for "fun"
The library dependencies that will are not fullfilled, are also without a native compiler enough.13:52
<bonniot>don't understand13:54
<rubber>I mean, that I doesn't want to use another thing, that has even more dependencies.13:55
With the java version of nicec I'm pleased.
<bonniot>ok :-)
<rubber>but to come back to nice.plugin.... what to you suggest?14:09
<bonniot>you are the only vendor writing the plugins, right? and you deploy locally? or the server runs at a client?14:14
<rubber>Well, the client also need the plugin mechanism.14:17
Currenlt ywe are the only vendor, but to write a plugin mechanism, it should be more general.
http://nice.sourceforge.net/cgi-bin/twiki/view/Doc/UnitTesting <--- :)14:19
<bonniot>sure. i just want to make the distinction between what you need in the short term, and what can be a generic system14:20
how would the client use the plugin system?
<rubber>First for the same things, the server uses to receive, so the clients need appropiate plugins to send.14:22
Second for "lets say" different views of data...
<bonniot>(when I said clients I meant customers)14:31
(customer is said "client" in french ;-)
(sorry, i was writing UnitTesting at the same time)14:32
so you have a client-server architecture?
that spans across several machines?
<rubber>yes.
<bonniot>ok14:37
i suppose that this does not matter
you can write you new version of the server, new version of the client that you send there, and both are reloaded dynamically (if the client also needs to run permanently)14:38
(UnitTesting is written)14:40
to make things clear: in how much time would you need these plugin system to be available?14:41
<rubber>I assume, that I need until tomorrow to produce again some native windows binaries. After that I will have the time for the plugins.14:46
But friday is "Karneval"...14:47
<bonniot>is there a deadline regarding your customers?
;-)
<rubber>And my parents relocate, so I have to help them on saturday.
After that I have to catch up all the Karneval time... 14:48
Deadline is ago. :(
<bonniot>and plugins are necessary for that deadline?14:49
<rubber>No, but the function that is in the plugins...
This is currently only roughly implemented... very hardcoded and very unflexible.14:50
For the latest requirements I want to change that, so that the desig again becomes cleaner.
<bonniot>ok. i have in mind a design for a generic system of plugins14:51
it would need some investigation
<rubber>So to speak, we have to deliver a version with the latest changes up to end of the month. Before that the plugin mechanism has to work and the plugins have to be written.
So, it is not more than one week.14:52
<bonniot>i see
<rubber>... one week in workdays...
Without the nights... ;)
<bonniot>:-)
<rubber>and without more windows worms...14:53
...btw. what do you think about windows going open source?
<bonniot>one issue is that the plugin system for Nice would need a part of the compiler, and so that would bring the GPL...
<rubber>Hmmm....14:54
<bonniot>i suppose that would be an issue for you?
<rubber>definitly14:55
<bonniot>hum
could your company consider hiring an external contractor? :-)
<rubber>wdym?14:56
<bonniot>give a contract to somebody outside to company to work on this issue14:57
<rubber>"why"dym?
would that resolve the compiler part requirement?14:58
<bonniot>that could, if that contractor happens to hold the copyright on that compiler ;-)14:59
<rubber>;-)
<arjanb>daniel why does a plugin system need the compiler?15:03
<bonniot>to generate dispatch classes dynamically15:04
<rubber>I'll have to leave for lunch... see you soon
<arjanb>it could use reflection15:08
<bonniot>not only, because the dispatch class cannot know about the new packages15:23
<arjanb>what if all dispatch code is inside classes like java methods?15:29
<bonniot>it's not always possible (value dispatch for instance, or dispatching on JDK classes)15:31
<arjanb>true but you could only a restricted set of dispatch things for plugin methods15:33
<bonniot>yes. only I don't like too much having something that "half works"
there would still be hard work changing the dispatch code generation and to make sure it is correct15:34
<rubber>back15:59
what does 'niceunit --classpath hello.jar hello' do?16:15
<bonniot>run the unit tests in package hello16:17
<rubber>ok, but what are the unit tests?16:18
all void functions, that start with _?
<bonniot>every method that starts with _test
<rubber>Ah, every function that starts with _test... Ok... Did you mention that on the wiki=16:19
<arjanb>i don't see niceunit code in cvs?
<bonniot>no, as I said there, i's like some feedback before i commit
will check the wiki
<arjanb>i see16:20
<rubber>I only see some niceunit changes to nicec.bat nicec...
I've also aliased 'ln -s nicec niceunit'...16:21
But it does not work ;)
rubber@tower:~ > niceunit16:22
Exception in thread "main" java.lang.NoClassDefFoundError: nice/tools/unit/console/fun
<bonniot>clarified in wiki
yes, the code is not commited yet :-)
give me some feedback, and I will commit :-)
<rubber>"... unit tests if the compilation succeded. Should this by default be turned on or off?)" Turn off as default.16:23
<bonniot>otherwise ppl might complain that compilation is longer that it is :-)16:24
<rubber>What is a JUnit style?
ppl <-- ?16:25
<bonniot>for every class Foo that you want to test, you create a separate class FooTest
ppl = people
<rubber>:)
And so with this FooTest you can only test the Class from outside...?16:26
<bonniot>right, no calls to private methods
<rubber>Ok, I prefer the niceunit way. If it is needed, is something else, but I like the freedom.
<bonniot>some ppl argue that's a feature, but it's also a FAQ: how do I test my private methods?
:-)
<rubber>all JUnit tests could be run by niceunit?16:27
If that would be the case, we could write niceunit tests, but if someone prefers Junit tests, we could test them also.16:28
<bonniot>yes, that would be possible.
<rubber>but for the moment it would be no requirement to mho.16:29
<bonniot>agreed
we should start gathering some experience with this, then decide about the next step
<CIA-3>03bonniot * 10Nice/ (2 files in 2 dirs): Allow expression-local variables without keywords but with a type specifier.16:30
03bonniot * 10Nice/ (5 files in 4 dirs): Added NiceUnit.17:32
<rubber>Ok, lets see, what niceunit can do... :)17:37
<bonniot>:_)17:39
<rubber>What about:17:42
Building the Ant task definition...
JAVA="/site.opt/Java/j2sdk1.3.1/bin/java" /home/rubber/Work/WorkingDirectory/Nice/bin/nicec --exclude-runtime -d "/home/rubber/Work/WorkingDirectory/Nice/classes" --sourcepath="/home/rubber/Work/WorkingDirectory/Nice/stdlib:/home/rubber/Work/WorkingDirectory/Nice/src" --classpath "/site.opt/Java/Ant/lib/ant.jar" nice.tools.ant
nice.lang: parsing
Command line:
Package nice.tools.ant is not available.
The source path is: /home/rubber/Work/WorkingDirectory/Nice/stdlib:/home/rubber/Work/WorkingDirectory/Nice/src
The package path is: /site.opt/Java/Ant/lib/ant.jar
make: *** [ant] Error 2
<bonniot>did you checkout nice.ant?17:43
or maybe i forgot it...
<rubber>aeh, what?
<bonniot>yep, my mistake
<rubber>ok
* bonniot is away: ~20 minutes17:45
<CIA-3>03bonniot * 10Nice/src/nice/tools/ant/ (TestListener.nice NiceUnit.java): Ant support for NiceUnit.17:46
* bonniot is back (gone 00:30:28)18:16
<rubber>Ive a problem with niceunit:18:18
package testunit;
class TU {
void _test_me() {
}
void _test_me_also() {
}
}
void _test_f_me() {
assert 1!=0;
}
void _test_f_me_also() {
assert 1==0;
}
void main(String[] args) {
_test_f_me();
_test_f_me_also();
}
java -ea -classpath targets testunit.fun
Exception in thread "main" nice.lang.AssertionFailed
niceunit --classpath targets testunitException in thread "main" Argument #0 to 'start' has wrong type
at gnu.mapping.WrongType.make(WrongType.java:56)18:19
at nice.tools.unit.dispatch.start(dispatch.nice)
at nice.tools.unit.fun.runTestMethod(fun.nice:53)
...
what do you think about that?18:20
still online?18:22
Up since: Wed Apr 16 13:10:08 200318:23
Load Average: 101.80 104.53 104.95 (1199 processes)
Ram: 5950784KB
Free: 4440KB
Current bandwidth utilization 255.31 Mbit/s
:-)
<arjanb>your server?18:24
<rubber>No, that would be nice... kernel.org
<arjanb>looks like a new release
<rubber>yep, another local security hole. 18:25
<arjanb>*away for meal*18:29
<bonniot>rubber: you don't need to call the tests from main18:30
does the exception appear before the call to niceunit like you wrote?18:31
<rubber>No, the test to call from main, was just to verify, that the assertions work.18:33
<bonniot>ok
<rubber>the tests in the class tu, doesn't seem to get recognized at all...
<bonniot>they are not supposed to18:34
tests should have no parameters
those have the 'this' parameter18:35
<rubber>Ah, ok.
package testunit;
void _test_f_me_also() {
assert 1==0;
}
but this still throws:
rubber@tower:~/Work/WorkingDirectory/e3m > niceunit --classpath targets testunitException in thread "main" Argument #0 to 'start' has wrong type
at gnu.mapping.WrongType.make(WrongType.java:56)
at nice.tools.unit.dispatch.start(dispatch.nice)18:36
at nice.tools.unit.fun.runTestMethod(fun.nice:53)
...
<bonniot>i get it too18:37
<rubber>ok, good
<bonniot>i know18:39
<rubber>:)18:42
btw. will the testunit stop after the first encountered assertion, or proceed?18:43
<CIA-3>03bonniot * 10Nice/src/nice/tools/ant/TestListener.nice: Make sure that the console listener does not get ignored.18:44
<bonniot>that should work18:47
the previous version only worked in ant/maven mode18:48
<arjanb>*back*
<rubber>package testunit;18:50
void _test_f_me_also() {
assert 1==1;
}
void _test_f_me_also() {
assert 1!=1;
}
that is compilable without warning or something like that???18:51
<arjanb>possibly
<rubber>Yes, it is.
Strange, that this is possible... For what purpose?18:52
<arjanb>some checks are missing in the compiler18:53
<rubber>Ok.18:54
<bonniot>what warning would you want?18:59
oh, double declaration
<rubber>:)19:00
<bonniot>actually, there is no problem here, both tests are run I expect, right?
if you try to call that method, you'll get an ambiguity
<rubber>Something like: "You fool, there are two functions with name foo; I'm going to format C: " would be better...
<bonniot>i agree it would be better to signal an error on that one
:-))19:01
<rubber>that would'nt be nice for arjan I assume.
So, sorry for that.19:02
;)
<bonniot>the format part? yeah...
rm -rf $HOME wouldn't be great either
<rubber>Uhh, das would be bad....
<bonniot>although at least you keep your system, and $HOME should be on backups...19:03
<rubber>I would need to verify, that my tapes work, but I haven't done that for a long time.
<bonniot>the interesting case is:
TEMP_DIR=...
...
# clean up
rm -rf $TEMPDIR/19:04
#oops, $TEMPDIR is the empty string, i'm deleting the system
<rubber>:)
<bonniot>so, better not run scripts as root
<rubber>rm -rf does'nt delete anything?19:05
<bonniot>only if it's allowed to19:08
a user can't erase system directories and files
or other users'
how do you like niceunit?19:11
<rubber>It's good to have. 19:12
now I must have the strength to write the testcases.
<bonniot>:-)19:25
one way to do is to write the testcases first, then make sure you write code that passes them
<rubber>Correct
Good point :)19:26
<bonniot>arjanb: can you login on SF?19:56
<arjanb>cvs or website?20:02
( 2004-02-18 10:35:25 - Project Database Service, Project Web Service ) On 2004-02-18, project database and project web services will be offline for up to six hours starting at 8:00 to permit a hardware upgrade for the project database servers. 20:04
<bonniot>shell20:05
<arjanb>i don't use shell but cvs works for me
<bonniot>for me too20:07
it's shell login that doesn't
* bonniot is away: for dinner21:00
* bonniot is back (gone 00:49:06)21:49
<rubber>whooh... Java-1.5 has that many new features...22:37
<bonniot>yes: multi-methods, anonymous functions, tuples, static typing of null, abstract interfaces, optional arguments, name arguments, ...22:40
oops, those were features it does _not_ have
;-)
<rubber>Yes, but it now has type parameters, Enhanced For Loop, import static;... 22:41
great things... don't you think, we should prefer plain java before nice.22:42
?
http://www.heise.de/ix/artikel/2004/03/066/03.shtml http://www.heise.de/ix/artikel/2004/03/066/02.shtml http://www.heise.de/ix/artikel/2004/03/066/01.shtml22:43
just great improvement about 1.4...
we need to download it immediatly
<bonniot>yes, it's definitely improvements
but it took them more than 5 years to add type parameters. improvements are coming very slowly22:44
<rubber>please daniel, download it and then to a 'mv jdk-1.5.bin > /dev/null'
<bonniot>:-)22:45
<rubber>I would be of of no good if you would spend your time with it.
...expect looking for arguments to switch to nice.22:46
<bonniot>see above for a few...
<rubber>year
yaeh
yeah... *lol*
<bonniot>and given their speed, it will be a few years before the next version, while we are adding great features *weekly* :-)22:47
<rubber>yes, and their most important argument for the slow speed is, that they won't change the VM.22:48
and this is mostly the blocker for new features...
<bonniot>but we don't change the VM, and we do lots of fancy stuff...22:50
<rubber>Well, that are only a few things, now one could use. They are even not stable for production systems.
<bonniot>jdk 1.5 is not stable?22:51
<arjanb>not yet22:52
<rubber>will it ever be?22:56
<bonniot>;-)22:58
<rubber>where was the site to see the stats of http://nice.sf.net/ ?23:12
<bonniot>http://nice.sourceforge.net/cgi-bin/twiki/view/Doc/StatisticsLinks ?23:14
<rubber>thnx23:18
ok, I'll go to bed now... see you tomorrow...23:36
<arjanb>cu
<rubber>bye
* rubber leaves23:37
<bonniot>good night00:19
<arjanb>good night00:20
* bonniot leaves00:27

Generated by Sualtam