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

Using timezone: Greenwich Mean Time
* arjanb joins10:13
* bonniot joins10:39
<bonniot>did you try the new version of the CCs?10:42
<arjanb>no i'm compiling it now10:44
do you have an idea how CC and OC (overloaded) can be distinguished? it seems to me they would overload10:47
new Point(String s) { ... }
this could be either a CC, or a OC implementation
<arjanb>i think no 'new' at an OC implementation and OC declaration i don't know yet 10:48
<bonniot>?Point new Point(String);10:50
yes, ommiting new for implementations is an option. but isn't it going to be confusing?
nestinglevel variable is parser.jj shouldn't be static anymore
and Loader could be simplified10:55
<bonniot>the confusion could be that people declare an OC, then try to implement it with 'new', which will be recognized as a CC11:03
can you update nestingLevel? (it should not really matter at the moment, because the "string parser" never contains comments. But it will be cleaner not to have the nestingLevel static)11:05
what change to Loader?
<arjanb>just creating a new Parser everytime11:08
<bonniot>ok, if that does not impact performance11:13
<arjanb>btw i replied to Christian's mail11:15
<bonniot>me 2, whata did u say?11:16
<arjanb>that he should build a new nice-bootstrap.jar from cvs of a few days ago11:18
*away for an hour*11:20
<bonniot>yes i think so too. the strange thing is that he says he used a recent one. sf.net/nice.jar should be pretty recent11:22
why do you think that the stacktrace Christian gave is a jvm bug?13:23
<bonniot> at mlsub.typing.MonotypeConstructor.setId(MonotypeConstructor.java:119)13:26
at nice.tools.code.Types.setMarkedKind(Types.java:656)
setMarkedKind calls setKind, not setId
do you see the strangeness of it?14:11
i looked whether some things were missing in the stacktrace because of inlining but that doesn't seems possible either14:13
i can remove half of the retypings in java-io.nice by a few small changes to default typing of java methods14:34
array argument always non null and constructor arguments non null14:38
<bonniot>the problem with changing the default typing is that it could force people to write retypings or cast(null) just to _use_ simple Java libraries that do not conform14:42
why are there retypings like:
void write(Writer, char[]) = native void Writer.write(char[]);
isn't that the same as the default?14:43
<arjanb>the default is now void write(Writer char[?])
is the problem with class directive that there would still need to be many of them?14:47
<arjanb>sorry was busy with other things15:20
<bonniot>no pb
<arjanb>well i think you would need quite a few class directives
<bonniot>so what about directives at the package level15:21
<arjanb>that's at least better than class directives15:22
<bonniot>that's a compromise :-)15:26
<arjanb>*away again*15:36
simplification of the bug Isaac found:16:42
class Test {
Test->boolean a = f;
boolean f() = true;
<bonniot>i'm not aware of that, where is it?16:46
<arjanb>bug report on sf
this one is for you i think16:55
<bonniot>did you get an email notification?17:09
<bonniot>quite simplidifed :-)18:39
ok, i will look at it
i think i have a simple fix19:02
<arjanb>in gnu.lists are some java.in files and script that converts them to .java files19:13
but you can't run that script in windows so what about storing the java files in cvs instead of the java.in ones19:14
or storing both in cvs19:19
<bonniot>Could you check how is the current upstream Kawa? Do you still have the java.in files?
Do they ...
<arjanb>no *.java.in files in kawa anymore19:20
<bonniot>didthey keep only the version with collections, or what?19:21
<bonniot>so, it's surely better to do the same :-)19:26
<arjanb>whithout collections is only to make that compilable with javac < 1.2
<bonniot>but they dropped that
so we can get rid of the .java.in files and the script
can you do it?19:31
<arjanb>i can't test the makefile so i won't do it19:32
<bonniot>just need to delete the line19:35
cd src/gnu/lists && ./withCollections
<arjanb>the .cvsignore is odd in that dir19:38
it's a mistake
it can be removed too when java.in files are removed
<arjanb>could you check if i did everything right?20:12
<bonniot>did you commit?20:16
<bonniot>ok, i can see it on gmane20:26
<arjanb>mail still broken20:27
<bonniot>my mail is working
but there might be a delay
<arjanb>not at sf then
<bonniot>.cvsignore could have been removed
<arjanb>seen the last post on the forum?20:29
<bonniot>now yes :-)20:31
<arjanb>so you should change the wording of the readme a bit20:35
<arjanb>because it's confusing
<bonniot>i don't see why. what do you propose?20:40
<arjanb>not using the word recommanded20:42
<bonniot>It is mandatory, then? :-)20:43
<arjanb>someone can think so20:44
<bonniot>the problem is not that this guy tried the plugin, it's that he did not succeed20:46
apparently, he also tried the command-line version
i think the good thing about the IDEs is that they will take care of calling the compiler, while people can be surprised at having to supply a package name, not a file name20:47
it would be good to include a link to the EclipsePlugin page, for sure
it seems the changes to gnu.lists are good :-)20:49
<arjanb> teste(o@Object) = "Object";20:51
see other new forum post20:52
<bonniot>yes, i saw it
<arjanb>i think @Object should not be allowed
or just be replaced with at any20:53
<bonniot>it is useful, in cases like
void foo(Object);
to implement foo
it looks like a bug in the pattern comparison20:54
@Object is more specific than at any so is tested earlier in the dispatch
<bonniot>yes, that's fine20:55
but Integer should be been printed
<bonniot>with 0.9.5 you cannot write @Object20:57
not new Object()20:58
but that should be allowed again later
<arjanb>@Object is never needed20:59
<bonniot>for disambiguation
<arjanb>for what odd code should that be?21:00
<bonniot>void foo(String);21:01
void foo(Object);21:02
foo(o@Object) {...}
nothing odd :-)
<arjanb>foo(x(String)) {...} foo(x(Object)) {...}21:03
<bonniot>Ok, but it's better not to need that feature, because it's one less concept21:04
to learn
there is nothing wrong with @Object, so it should work. it's not a priority, granted21:05
<arjanb>i know why the order of the methods matters before 0.9.521:06
Object and Integer were incomparable so the compiler didn't care about the order in the generated code21:07
<bonniot>you're right21:13
<arjanb>the tutorial is not correct since 0.9.5 "A consequence of this rule is that there is no class (like Object in Java) that is an ancestor of all classes. There could not be, since all classes do not have the same number of type parameters. 21:15
However, it is possible to express that a method takes arguments of any type. For instance the equals method is declared in Nice:
<bonniot>Yes, this should be reworded21:16
there is a rush of new users suddenly :-)
i suppose it's the release
ok, i'll be going21:43
<arjanb>good night
* bonniot leaves21:44

Generated by Sualtam