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

Using timezone: Central European Time
<bonniot>good night00:20
<arjanb>g'night
* bonniot leaves
* arjanb leaves00:29
* bonniot joins09:39
* arjanb joins09:42
<CIA-3>03bonniot * 10Nice/stdlib/nice/io/file.nice: 10:53
Avoid using a class retyping for importing the class, since that create
problems with the class fully qualified name. Using Java package import
for now.
* arjanb leaves11:33
* arjanb joins13:59
* ArtemGr joins14:05
<bonniot>hi14:09
<ArtemGr>??????14:12
salute
btw, what about class-loading order when package "a" have methods extending "b" classes and package "b" have methods extending "a" classes?14:13
<bonniot>then the packages must import each other, right?
<ArtemGr>they should14:18
<bonniot>not must?14:19
i think they must14:21
in that case, there is no problem, since they have the same view of all methods
<ArtemGr>they can use absolute class name (b.Foo)14:23
what i mean, is that if a is separately compiled to a.jar and b to b.jar
then either a or b classes will be loaded first, and other's overloaded methods will be "not found".
<bonniot>not if a and b import each other14:24
<ArtemGr>why not?
<bonniot>because then they are always compiled together14:25
<ArtemGr>ah, i see
<bonniot>it will help to have formal testcases ;-)14:26
<ArtemGr>and if they not, the "package 'b' must be recompiled but no sources available" will rise?
<bonniot>if the sources are not available, yes
<ArtemGr>we should probably auto-import packages whose classes referenced by absolute class name (import b if b.Foo is used)?14:27
<bonniot>an alternative is to require the import relations to be declared14:28
that is, fail on b.Foo is b is not imported
i think that's good, because the import relations are the basic architectural decisions in a project
my test framework is ready for commit, i'm just not sure yet of the directory layout for the new cases14:31
what kind of tests do you have in mind?
<ArtemGr>classloader tests should be a good test for the testing framework: i should have access to the compiled jar, so that i can load it from URLClassLoader. should be able to compile two packages together statically and have an access to that static jar.14:33
am going to write some tests when Java classes are compiled and then extended by Nice14:34
<bonniot>hum, but then how do you call a java compiler?
<ArtemGr>thru the framework ; )14:35
<bonniot>how does the framework call a java compiler in a portable way?
<arjanb>hi14:36
<ArtemGr>testing framework should be configured externally about which compiler to use, then it can be used agains different JVMs14:37
<arjanb>calling javac can be done just like ant does
<bonniot>arjanb: i'm not sure that's portable
<ArtemGr>ant allows to specify the compiler to use, but i think framework should be configured outside the test14:38
<bonniot>yes, there is a runner program to start all the tests found, which could handle the task of setting up a java compiler14:39
i think i'm going to commit the runner and the helper methods
then we can discuss how to extend it, and how to layout the new tests
<ArtemGr>good
<CIA-3>03bonniot * 10Nice/ (3 files in 3 dirs): Embedded DSL to write testcases as nice programs calling the compiler.14:46
<bonniot>http://rafb.net/paste/results/WyMwXU61.html14:47
as an example
you might need to generalize the helper methods...14:48
make nicetestengine compiles the runner14:49
java -cp classes nice.tools.testsuite looks for .nice testcases inside testsuite/14:50
java -cp classes nice.tools.testsuite.dispatch
<ArtemGr>ok. i'll try to do something tomorrow evening.14:57
<bonniot>ok. did you have a closer look at gjdoc?15:01
<ArtemGr>no, but we can debug on Sun's Standard Doclet as well. i thought yesterday that i will switch to thinking about nicedoc only when Java integration bug are fixed enough.15:05
s/bug/bugs/
<bonniot>ok, that makes sense
btw, did you see the failures? seem to be related to your assert changes:15:06
~/automated/tester/builds/Nice/stdlib/nice/lang/assertions.nice: line 26, column 3:
No possible call for this.
Arguments: (java.lang.String, ?nice.lang.Throwable)
Possibilities:
nice.lang.AssertionFailed (Object message)
nice.lang.AssertionFailed ()
nice.lang.AssertionFailed (?java.lang.String)
for some reason this happens only on jdk 1.3
actually i saw it on doppler before, but it's not there anymore
<ArtemGr>Shouldn't be on dopler.15:10
The problem is probably that there is no Throwable(String,Throwable) constructor JDK1.3.
Even Throwable(Throwable) isn't available.15:12
<raboof>hm. is `value' a reserved word of some sort?15:15
<bonniot>no, why?15:16
<raboof>i get a different error when using the undefined variable name `value' than when i use `valuee'
<bonniot>what errors do you get?
wait, value can be a global method or something15:17
so you will get a different error
<raboof>http://rafb.net/paste/results/BCtwwZ40.html15:19
ah, `T nice.lang.Ref.value' is a global method called `value'?15:20
<bonniot>yeah
yes, it's a field of class Ref
the error message is indeed confusing15:21
<raboof>i guess it'd help if it was more verbose, like `usage of method "value" didn't match any of the following declarations:'15:22
err
and then correct :)
<bonniot>there is something like that already15:23
only here it's the compiler trying to see if this is not a implicit access (without this) to a field of the current class
it should not print this error
on the other hand, it should not always discard it, for instance if the field exists but has the wrong type15:24
good error messages is hard ;-)
<raboof>very true15:25
<bonniot>ArtemGr: we already have a few workarounds for missing methods in JDK 1.3, in nice.tools.util.JDK15:28
<raboof>btw, it might be nice to consider giving error messages in gcc-style form (`filename:linenumber: message')
so maybe certain IDE's might immediately support it (like vim, http://www.vim.org/htmldoc/usr_30.html)15:29
<bonniot>nicec --editor
<raboof>sweet :)15:30
though it doesn't work for vim it seems - due to not expanding the `~' it seems15:42
but i'm not sure if that's a `bug' in vim or in nicec :)
<bonniot>feature request for vim? ;-)
yeah
works in emacs ;-)15:43
<CIA-3>03artemgr * 10Nice/ (3 files in 3 dirs): Made assertions Object message to be JDK1.3 compatible.15:56
<bonniot>excellent!15:59
<ArtemGr>thanks. : )
<bonniot>i've found the problem with dispatch and compiled packages in jars16:02
<ArtemGr>which problem? jar-related?16:06
<bonniot>the one in the testcase i posted today16:07
using the wrong dispatch methods
<raboof>hmm. it'd be rather nice if "if (s != null) { .. }" used a local (guaranteed to be non-null) copy of `s' inside the block.16:41
should i put that under FeatureProposals?
<bonniot>yes16:42
<ArtemGr>btw, writing to the local "s" should write both to the local and to the global "s" instances...16:43
<raboof>oh drat, you're right of course. things are never as simple as they sound :016:44
<bonniot>but that does not make it impossible16:45
<arjanb>there's a rfe for nullness inference on fields already
<bonniot>ah, thanks
comments could be place there then
with a link from/to the wiki if you want16:46
i think a nice first step should be to support tests on final fields
<raboof>what's an RFE?
<bonniot>that case does not require copying, so it's simpler
and it would put in place part of the machinery needed for the general case
request for enhancement16:47
<arjanb>this one: http://sourceforge.net/tracker/index.php?func=detail&aid=671444&group_id=12788&atid=362788
<bonniot>aka feature request
<raboof>ah! :)
seems like the constrained-generic classes bug is indeed gone btw, for which thanks :)16:52
gotta go for a while, see you later
<bonniot>see you
cool
that part of the compiler was not used much yet, it seems, but it's getting better ;-)16:53
<raboof>http://nice.sourceforge.net/cgi-bin/twiki/view/Doc/BinarySearchTreeExample - any comments?18:40
<bonniot>you got it working?18:41
<raboof>think so. `it compiles' :)
<bonniot>:-)
where are the unit tests? ;-)18:42
what version of the compiler are you using?18:52
<raboof>0.9.11 prerelease (build 2005.04.11, 12:54:51 UTC)18:55
<bonniot>oh good18:59
i was just using the wrong branch, which does not have my latest fix ;-)
<raboof>;)
<bonniot>the !Ts are not necessary19:01
i also think your trees are all empty... (a small bug)19:03
<raboof>oh drat. the copying :)19:04
i'll test a bit :)
<bonniot>you can use 'let mycontent = content;' saves typing, and will show the bug ;-)19:07
<raboof>what does `let' to?19:08
oh i'll just look it up
hm the compiler can't infer parameterized types yet can it?19:11
<arjanb>it can most of the time but the implementation of that is buggy19:12
<bonniot>if the value has a monomorphic parameterized type, there is no problem19:17
for example here, content has type ?IntTreeNode<T,U>, which is OK19:18
the only problem is for values with their own type parameters, like new ArrayList()
shoudl work too, but there are bugs19:19
let declares a constant binding19:20
(final is Java terminology)
and it "lets" you omit the type ;-)19:21
var is similar for variables
you could use many lets, which would make the code clearer I think19:23
possibly declare a getValue method that accepts a null first argument19:24
that would make the logic clearer by eliminating that special case19:25
that's all for my comments!
<raboof>hmm. so something that looks like a member of IntTreeNode, but doesn't mind if it's called on something that is null?19:28
<bonniot>yes
just declare the method at toplevel, with a ? type
<raboof>that's weird in a cool way.
hm, i sometimes find myself having to delete `package.nicei' files to fix compilation errors, is that known?19:31
<bonniot>no, could you try to find a reproduceable situation?19:33
<raboof>i'll as soon as i bump into it again
<bonniot>ok thanks19:34
<raboof>w00t, i got the compiler to crash again :) - with code that's indeed incorrect, though19:44
<arjanb>what's the begin of the stacktrace?19:45
<bonniot>it's still a bug!
<raboof>Exception in thread "main" java.lang.ClassCastException
at nice.tools.typing.Types.rawType(Types.java:104)
at nice.tools.typing.Types.equivalent(Types.java:84)
at nice.tools.typing.Types.isVoid(Types.java:32)
<bonniot>please report it19:46
<raboof>report coming right up
<bonniot>thanks
<raboof>so, for the getValue-that-handles-null, would i make it override the class getValue, check for nullness, and call the overridden method or return null? or is there a neater way?19:51
<arjanb>that bug is caused by unknown type showing up at an unexpected place19:54
that's just a matter of style to use a null check or pattern matching20:03
<raboof>(hm. utwente. which reminds me. i should squeeze in some more training in the coming 2 weeks :))20:06
<arjanb>oh you will run the batavieren race?20:08
<raboof>jep :)
i'm from Nijmegen, so :)
<bonniot>one possibility is:20:09
public <Comparable T,U> ?U getValue(?IntTreeNode<T,U> node, T key);
getValue(null, key) = null;
use 'override' instead of public in the existing getValue
and get rid of the tests ;-)
* ArtemGr leaves20:17
<raboof>still, even though crashes are prevented with the `what' construction now, you can still have race conditions20:18
so it's code that solves a problem that would only exist in case of threading, but actually using threading will still break stuff :)
<arjanb>what's the threading problem here?20:23
<raboof>for example, 2 threads simultaneously trying to add something. one thread might overwrite the other one's addition
interleaving 2 instances of `let theleft = left ; theleft.add(foo) ; left = theleft'20:25
<bonniot>yes, you should use synchronization for that ;-)20:26
<raboof>well, yeah, of course20:29
<arjanb>that bug reminds me of wanting another syntax for unknowntype20:34
* Bluelive joins21:15
* Bluelive leaves21:17
<bonniot>wow, weird bug you found21:19
i wonder why it even parses
<arjanb>it's an anonymous formalparam of unknowntype...21:25
<bonniot>ah, yes21:36

Generated by Sualtam