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

Using timezone: Central European Time
<CIA-2>03bonniot * 10Nice/Makefile: 00:20
Correctly handle cleaning when both dispatch.java and dispatch.java.bootstrap exist.
This can happen in particular if dispatch.java exists, and a new version of dispatch.java.bootstrap is obtained with cvs update.
* Atomixx leaves00:24
<CIA-2>03bonniot * 10Nice/Makefile: Fix for the previous patch, which failed when dispatch.java was not present00:26
03bonniot * 10Nice/ (6 files in 4 dirs): 01:23
Fix subtyping of wildcards. Should be safe, but overrestrictive, since
a wildcard is now not a subtype of itself.
* bonniot leaves01:45
* arjanb leaves03:38
* bonniot joins11:01
* arjanb joins12:04
<bonniot>how's you rsi?12:24
<arjanb>it's not away though manageable12:28
<bonniot>interesting, I thought this would work in java 5:12:34
void splash(java.util.List<?> l, int index1, int index2) {
l.set(index1, l.get(index2));
Java.java:7: set(int,capture of ?) in java.util.List<capture of ?> cannot be applied to (int,java.lang.Object)
l.set(index1, l.get(index2));
then I guess our current implementation is equivalent12:35
<arjanb>so an Unknown type or ? in java is different from an unbounded type variable?12:38
that's needed for safety if ? appears in the result type, i think12:41
<arjanb>it would safe to replace ? with a type variable when ? is in an argument type, right?12:44
<bonniot>i think so12:47
but you cannot do that simply for local variable's type
i wrote something about this on LtU
<arjanb>is ? the same as an anonymous existential type variable?12:56
<arjanb>ok i can make sense of it now12:59
<bonniot>i see you have the theoretical background ;-)13:00
<arjanb>yeah TAPL from Pierce is a good book
<bonniot>do you have java 5 installed?13:22
<bonniot>any reason not to?13:23
<arjanb>i have no use for it and i don't like fiddling with multiple jvm's installed13:25
<bonniot>it's just that I saw bootstrap is failing on it, so somebody should look into that13:27
i'M looking at artem's bug atm
<arjanb>afaik bootstrap has always failed on 1.513:28
<bonniot>yeah, but it should not be hard to fix. just some new methods that create ambiguities13:29
<arjanb>i think it was something with how java generates code for covariant returntypes13:30
* ArtemGr joins13:47
<bonniot>i'm looking at your latest bug now14:08
<bonniot>yes, so far, it looks like an optimization is not working like it should
so besides fixing this bug, we might save time in other cases14:09
but i need to investigate more
also, I think it just passes in the testsuite because of the larger memory14:10
<ArtemGr>when i've tried to increase memory in the original test case, i've got stacktraceowerflow14:11
my thought was that the presence of the full Nice (with libs) in the classpath might trigger the problem..14:12
<bonniot>well, importing the compiler package is not necessary for the program, right?14:16
it just increases the number of classes, and thus makes link tests longer
i got the same results with importing nice.swing14:17
ah, this looks related to Object14:20
<ArtemGr>too many methods with an Object argument?14:22
<bonniot>no, it's definitely a bug14:23
<CIA-2>03bonniot * 10Nice/src/mlsub/typing/Enumeration.java: Whitespace cleanup.14:26
<ArtemGr>strange problems with new version15:02
let Object comparator = cast(newInstance(Class.forName("ru.glim.db.KVBdbJe$Comparator")));15:03
Arguments (<T | java.lang.String <: java.lang.String, nice.lang.Class<?> <: nice.lang.Class<T>> T) do not fit:
<T, U> U cast(T)
<bonniot>that's surely related to the recent ? type changes15:12
could you make a testcase?
<bonniot>ah, i'm starting to see better15:54
<ArtemGr>good for your eyes : )
<bonniot>it's related to the fact that the method does not need to be implemented
<ArtemGr>well, should the following work?16:05
Object obj = Class.forName("java.lang.String").newInstance();
Object obj = Class.forName("java.lang.String").newInstance();16:06
Object obj = Class.forName("java.lang.String").newInstance();
i am going to put it into testsuite/lib/nice/lang/reflect/java.testsuite ...
<bonniot>it's not using nice.lang.reflect, is it?16:08
<ArtemGr>yes, but i'm afraid that newInstance declarations in the nice.lang.reflect are in the way of a usual newInstance. could that be?
<bonniot>normally not16:10
don't they have different signatures?16:11
do you import n.l.reflect at all?
<ArtemGr>i don't import it, but other methods work ok and newInstance not.16:12
<bonniot>if it's not imported, it cannot interfere
anyway, i think this is related to the typing of ?, since I changed that yesterday16:13
could you just paste the testcases, and I'll investigate
<ArtemGr>ok, you know the testcase:
Object obj = Class.forName("java.lang.String").newInstance();
your dispatch case is passing, btw ;-)
<ArtemGr>i was going to try it on the real library, but it fails on newInstance ; j16:16
<bonniot>my patch?16:17
you could apply it to a tree without the ? changes
<ArtemGr>would it be better for Nice than to test the whole new Nice version? 8 )16:19
<ArtemGr>you prefer me not to test the "?" changes?16:22
<bonniot>it's up to you16:23
<bonniot>it's just if you wanted to test the other ones before that is fixed
there might be a misunderstanding...
<ArtemGr>artem@dopler:~/Nice/$ patch < GnY4aP44.txt 16:58
Hmm... Looks like a unified diff to me...
The text leading up to this was:
|Index: src/mlsub/typing/Enumeration.java
|RCS file: /cvsroot/nice/Nice/src/mlsub/typing/Enumeration.java,v
|retrieving revision 1.19
|diff -u -r1.19 Enumeration.java
|--- src/mlsub/typing/Enumeration.java 26 May 2005 12:25:46 -0000 1.19
|+++ src/mlsub/typing/Enumeration.java 26 May 2005 14:31:10 -0000
Patching file src/mlsub/typing/Enumeration.java using Plan A...
Hunk #1 failed at 137.
Hunk #2 failed at 164.
Hunk #3 failed at 173.
Hunk #4 failed at 226.
4 out of 4 hunks failed--saving rejects to src/mlsub/typing/Enumeration.java.rej
<bonniot>$ patch -p0 <~/tmp/obj.diff [04:32 26/05/05]17:00
patching file src/mlsub/typing/Enumeration.java
Hunk #1 succeeded at 137 with fuzz 1.
Hunk #4 succeeded at 226 with fuzz 2.
<ArtemGr>obviously you are patching not against the current CVS17:01
<bonniot> cvs status src/mlsub/typing/Enumeration.java [05:00 26/05/05]17:02
File: Enumeration.java Status: Locally Modified
Working revision: 1.19
Repository revision: 1.19 /cvsroot/nice/Nice/src/mlsub/typing/Enumeration.java,v
as far as I can see, I am
but maybe you're not17:03
do you have 1.19 or 1.18?
it changed afew hours ago ;-)
now i guess that must be the source of the fuz, I did not update the remote machine where i applied the patch
it's just the whitespace cleanups17:04
maybe your patch is more strict than mine?
<ArtemGr>i have 1.1917:05
i've tried cygwin (essentially linux) and FreeBSD patches
found the problem - i had Windows CR/LF's after checkout
patched on FreeBSD but still can't on cygwin:17:10
patching file src/mlsub/typing/Enumeration.java
patch unexpectedly ends in middle of line
Hunk #4 succeeded at 226 with fuzz 1.
so this patching business is not as convenient as you might think
comparing to CVS update
still, i can build with your patch on FreeBSD, where i usually build anyway.17:11
i will commit when it's ready17:17
but you can also use cvs to apply patches selectively (once they are in the repository, of course)
<ArtemGr>tryed with the patched nicec. cast problem remains. (don't know if it should or not)17:18
<bonniot>it should, that's an unrelated problem
that's why I was advising to use an older version as the base
<CIA-2>03bonniot * 10Nice/src/bossa/syntax/dispatchTest.nice: Added debug info about used parameters.17:19
03bonniot * 10Nice/src/mlsub/typing/Enumeration.java: 17:22
Avoid looking setting kinds for Object when it's not used, as we already know
there is some solution.
03bonniot * 10Nice/src/mlsub/typing/Enumeration.java: Optimization: use a single SolutionFound instance17:26
<bonniot>to test your lib, you should be able to get from cvs the version of a few days ago, and then just update that one file to it's current version17:29
let me know if it fixes the problem17:30
<ArtemGr>i've reverted UnknownMonotype.java and Parser.jj17:38
well, reverting these didn't fixed the cast issue. perhaps it is related to other changes and not to the "?" changes.17:44
* bonniot leaves21:32
* CIA-2 leaves
* bonniot joins
* CIA-2 joins
* ArtemGr leaves21:35
* Atomixx joins21:45
* Atomixx leaves23:33
<bonniot>hum, these were not the relevant changes...00:21

Generated by Sualtam