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

Using timezone: Greenwich Mean Time
* bonniot leaves02:27
* arjanb joins11:32
* bonniot joins12:12
hi
<arjanb>hi
* GummiEnte joins12:19
hello
I've again found something strange with closures...
<bonniot>hello12:20
yes?
<GummiEnte>Should I post some code?
<bonniot>well yes, either that or explain the case :-)12:21
<GummiEnte> getSheetName(z) {12:22
?String sheet = null;
executeStatement(_ch.conn, "SELECT SHEETNAME FROM "+_ch.table_prefix+"_translation_table WHERE CUBEID='"+id+"' AND SHEETID='"+z+"'", (?ResultSet rs) => {
// here we only take the first element! (there should be also one, but anyway)
if (rs != null && rs.next()) {
sheet = rs.getString(1);
}
}, sqlexceptionlogger);
if (sheet != null) return notNull(sheet);
else return Integer.toString(z);
}
Even right after the declaration an if (sheet != null) return sheet; won't work.12:23
<arjanb>that's because sheet is declared outside the closure12:24
<bonniot>yes, and the closure modifies its value
<GummiEnte>I want to avoid the notNull in "if (sheet != null) return notNull(sheet);"...
<bonniot>we understand that
<GummiEnte>But even before the closure it does not work without notNull.
<bonniot>it would be possible to handle that, but it's not trivial12:25
if you access the variable from one closure and modify it in another, it's impossible to know which one will be executed when12:26
<GummiEnte>Can you give me an example?
<bonniot>?String s = null;12:27
foo(() => { s = getSomeStringMaybeNull(); });
bar(() => { if (s != null) println(s.length); });12:28
foo might start a thread that calls its arguments once in a while
or it could store it somewhere, and it would be called indirectly by some code in the second closure12:29
so even when s != null succeeds, you cannot be sure s will not be null afterwards
<GummiEnte>Indeed... with concurrent threads. Also without?12:30
<bonniot>yes, in a slightly different example:
bar(() => { if (s != null) { poc(); println(s.length); }});
poc might get access to the first closure, if it was stored in a global variable, and call it12:31
<GummiEnte>So, these are tricky cases, and if you program like that, I would say, this is no good style, maybe even broken...12:32
Or?
.. not?12:33
<bonniot>i agree, but there could also be cleaner cases where this happens12:34
does this situation happen often for you? (when the compiler is too restrictive)
<GummiEnte>It seems only to hurd with ?types.12:35
<bonniot>yes, and with specialization by instanceof tests12:36
<GummiEnte>...for my sources at the moment. I use this as "return" value of the closure.
<bonniot>how many times does it happen?12:37
<GummiEnte>Actually not that often. I've reduced instanceof through the use of dispatch and the closures I now started to use as macros.12:38
<bonniot>it's possible to make improvements, but it needs reflexion, and could be a large work. so it's all a question of priorities12:39
<arjanb>and it's possible to change the semantics of closures12:40
<GummiEnte>No, you don't need to give it a high priority. I can get along with it. I use notNull and cast for that.
What would the change of the sematics mean?
...what would the new semantics be?
<arjanb>now all variables that are captured in a closure have a common storage12:42
<GummiEnte>Now the storage is outside, oright?12:43
<arjanb>every time you use a captured variable in a closure you are accessing a field of the closure class
that field could be accessable from multiple places at the same time12:44
if the semactics are changed to copying these fields to local variables at the start of executing a closure body and copied back at the end12:45
?String foo = null12:46
...
() => { if (foo != null) print(foo.substring(3, 5)); } 12:47
then type inference of captured variables is possible inside the closure body12:48
<GummiEnte>hmmm, I'm not sure, but I'm using no other meaning of closures today. Do you thing others do? 12:49
<arjanb>i don't know12:52
<GummiEnte>Well, is it possible to do the semantics change?12:55
...without huge programming effort?
<arjanb>yes but it's quite a lot of work
<GummiEnte>Ok, so it isn't.12:56
I again have to leave. Maybe I can rejoin in a couple of hours. So long...12:59
bye
* GummiEnte leaves
<bonniot>arjan, do you use Emacs on Windows?14:24
<arjanb>no14:25
<bonniot>notepad?
<arjanb>ultraedit
<Bluelive>jcreator :))14:27
<arjanb>why do you ask?14:33
<bonniot>i've been upgrading the Nice mode for Emacs14:37
it's always good to test in different environments/versions
<arjanb>i don't have emacs installed14:38
another thing for a volunteer: Nice highlighting for vim14:40
<bonniot>good idea, you should add it on the list14:41
arjab, did you test Swing recently?19:56
<arjanb>yes19:58
* GummiEnte joins20:01
Hello again.
I've found a severe error with java mixing...
<arjanb>hello20:02
<GummiEnte>I should give you some testclasses:
Hello arjan.
First the java classes:
package test8.B;
public interface IB extends test8.A.IA {
public void blubb();
}
next class (better interface):
package test8.A;
public interface IA extends Cloneable {
public void init(java.util.Map attr);
}
Ok, and now some nice classes:20:03
class A implements IA {
init(m) {}
}
class IAB extends A implements IB {
blubb() {}
}
Trying to compile this gives me:
~/Work/WorkingDirectory/e3m/src/test8/B/test.nice: line 16, column 5:
init is not declared
<arjanb>and if you remove extends Cloneable?20:04
<GummiEnte>That has worked a few weeks ago.
I'll try.
Still the same (anyway I would have had no chance to remove the cloneable extend).20:05
Could you reproduce it?20:06
<arjanb>in which package are class A and IAB?20:07
<GummiEnte>Sorry. Both in package test8.B;
So it is:20:08
package test8.B;
import test8.A;
class A implements IA {
init(m) {}
}
class IAB extends A implements IB {
blubb() {}
}
<arjanb>i think the init method is ignored because nice doesn't know which type params map has20:10
<bonniot>exact20:11
<arjanb>so you need to add a retyping for the init method20:12
<GummiEnte>No, if I remove the map arguemnt (so no arguemtn) still something wrong:
No.... another error.
Ok, that's it. But I think, that has worked a few weeks ago.20:13
How could I work around?
<arjanb>adding the retyping
<bonniot>i don't think it has worked before, because it cannot: what would be the type of init?20:15
<GummiEnte>Well, I can miss, but I've checked in the code and normally I don't check in, if is not compilable.20:16
Uuups...
Stack trace:
java.lang.NullPointerException
at bossa.syntax.MethodBodyDefinition.findSymbol(MethodBodyDefinition.java:167)
at bossa.syntax.MethodBodyDefinition.lateBuildScope(MethodBodyDefinition.java:298)
at bossa.syntax.AST.typedResolve(AST.java:118)
at bossa.modules.Package.typedResolve(Package.java:256)
at mlsub.compilation.fun.lambda23(~/Work/WorkingDirectory/Nice/src/mlsub/compilation:33)
at mlsub.compilation.fun.apply1(~/Work/WorkingDirectory/Nice/src/mlsub/compilation)
at gnu.expr.ModuleMethod.apply1(ModuleMethod.java:89)
at nice.lang.fun.foreach(~/Work/WorkingDirectory/Nice/stdlib/nice/lang:325)
at nice.lang.dispatch.foreach(~/Work/WorkingDirectory/Nice/classes/nice/lang)
Well, I did the following retyping, so that might be wrong:
void init(IA, Map) = native void IA.init(Map);
<arjanb>void init (IA, Map<SomeType, SomeType>) = native 20:18
<GummiEnte>I've checked this file in at 2003/11/02.
void init(IA, Map<int, int>) = native void IA.init(Map); ??
<arjanb>yes
<GummiEnte>Is it important in whcih pacakge I define the retyping?20:19
<bonniot>maybe when you checked in there was no code actually using init?
<GummiEnte>No, still the same... Was a test package... not used until now.
Still a NPE:20:20
java.lang.NullPointerException
at bossa.syntax.MethodBodyDefinition.findSymbol(MethodBodyDefinition.java:167)
at bossa.syntax.MethodBodyDefinition.lateBuildScope(MethodBodyDefinition.java:298)
at bossa.syntax.AST.typedResolve(AST.java:118)
at bossa.modules.Package.typedResolve(Package.java:256)
at mlsub.compilation.fun.lambda23(~/Work/WorkingDirectory/Nice/src/mlsub/compilation:33)
<bonniot>so what is your code?
<GummiEnte>I get the NPE now, if defined the retyping in package test8.B.
package test8.B;20:21
import test8.A;
class A implements IA {
init(m) {}
}
void init(IA, Map<int, int>) = native void IA.init(Map);
class IAB extends A implements IB {
blubb() {}
}
<bonniot>could you try putting the retyping before the use?20:24
<GummiEnte>Uups, one error I did: import test8.A; but missed import test8.A.*;20:25
That nw gives me:
Ignored retyping because no method named init with 1 arguments was found in class test8.A.IA
and still the NPE.
...with the retyping right at the beginning of the file.20:26
<bonniot>is test8.A a Nice package or a Java package?20:27
<arjanb>java
<GummiEnte>Both... But test8.A.IA is a java package.
But I can remove the nice nice8.A.20:28
<bonniot>IA is not an interface?
that should be ok to keep it, i'm just trying to make things clear
<GummiEnte>IA and IB are interfaces... IA in package A and IB in package B... (ok test8 prepended)20:29
<bonniot>ok, i was confused because you said IA is a package20:30
<GummiEnte>Ah, I'm sorry.
I think, I've found the error... Please forgive me...:
void init(IA, java.util.Map<int, int>) = native void IA.init(java.util.Map);20:31
not without java.util.
:/
<bonniot>it should be the same
does it remove the NPE?
<GummiEnte>Yes, it is.20:32
...it does.
<bonniot>that's strange, because I don't get one here
an exception in the compiler is always a bug, so it needs to be fixed20:33
<GummiEnte>I haven't imported java.util.*;
<arjanb>do you have another class named Map?
<bonniot>java.util is implicitely imported20:34
<GummiEnte>Ok. Yes, I've got another class Map, but that is not imported, so it should be out of scope, should'nt it?20:35
<bonniot>arjan, could you reproduce this behaviour?
<GummiEnte>I'm at the moment not using the latest compiler...20:36
<bonniot>i don't think it should make a difference, but you never know...20:37
do you have several compilers around?
<GummiEnte>If I have a Map<int,Object> than currently I need to do something like map.put(1, object(new Integer(1234));
With the latest compiler I don't need the object cast any longer, right?
<bonniot>it could help if you made a tar or zip with a minimal set of files that produce this NPE20:38
true
<GummiEnte>Nice.
<bonniot>btw, i cannot read email at the moment, but you can send files by IRC :-)20:41
<GummiEnte>Oh, that's a problem... I'm remotly logged over three host ...
<bonniot>what is the problem?20:42
<GummiEnte>Well, I have to copy step by step... Ok, I can do, ...
The mail is just out...
<bonniot>yes, but atm I cannot read email (the email server is kaput)20:43
though if you send to arjan, he can forward by irc :-)
<GummiEnte>:)
I've mangaged to get the file to the host where I'm logged in...
Do you now, how to send using bitch?20:44
sendfile
test8.jar
<bonniot>i don't know that client20:45
can you send it by email to arjan?
<GummiEnte>He also gets a copy.
<arjanb>received and send to daniel20:48
<GummiEnte>I also tried to send... Did you receive "request"?20:49
<bonniot>yes, and i accepted. it's in connect state20:50
(twice)
but i got it from arjan, so it's ok :-)
<GummiEnte>Ok, so its my firewall that does not allow to send.
<bonniot>did you compile A before B, or both together?20:51
<GummiEnte>Aeh... A and then B, but also together... I assume, that not make a difference (regarding the java classes)...20:52
<bonniot>nicec test8/B20:53
Locating nice.lang:
Source : none
Compiled: /usr/share/java/nice.jar
nice.lang: parsing
Loading compiled version of package nice.lang
Locating test8.B:
Source : ~/dcc/./test8/B
Compiled: none
test8.B: parsing
test8.B: typechecking
test8.B: generating code
test8.B: linking
no error
<GummiEnte>Did you remove the java.util?
<bonniot>i compiled what you sent me...20:54
<GummiEnte>Ok, so that is the working version. Sorry. Simply remove the java.util in the retyping(s).
<bonniot>that also works20:55
<GummiEnte>??20:56
Ok, so I hope that it will work with a newer compiler.
My compiler version:
<bonniot>there is only one retyping, right?
<GummiEnte>Nice compiler version 0.9.5 prerelease (build 2003.11.27, 15:05:00 UTC)
Compiled using JDK 1.3.0
<bonniot>what sequence of compilations do you use?20:57
<GummiEnte>java test8/A; java test8/B; nicec test8.B (javac of course)20:58
<bonniot>javac test8/A/IA.java ?21:00
<GummiEnte>Yes, you're again right...
:/
<bonniot>no problem21:01
arjan, any success?
<GummiEnte>I'm compiling a new compiler.
<bonniot>ok
what is the while output of the compiler?21:02
<GummiEnte>What you mean?21:03
<arjanb>D:\Nice\.\test8\b\test.nice: line 1, column 9:
Source files in: D:\Nice\.\test8\b declares it belongs to package test8.B, but it was found in packa
ge test8.b
<bonniot>before it crashes
that's a filesystem case insensitivity error21:04
chris: i meant the _whole_ output :-)21:07
the messsages
<GummiEnte>Oh, jsut wait a minute... I try to reprouce it myself...21:08
<bonniot>now you see, it was just an illusion :-)21:09
<GummiEnte>No, that cannot be... No, no, pleas not.21:10
Well, call me a fool... I also cannot reproduce... :( Maybe there have been some odl classes in the targets directory... damm, so Ive stolen all your time for nothing...21:16
<arjanb>it probably the older version of the compiler that's the problem21:17
<GummiEnte>No, also with the old compiler I connot reproduce... :(
<arjanb>so a Heisenbug :(21:19
<GummiEnte>Thnx again for all your support... I'll have to leave.... My girlfriend is waiting for me...
Heisenbug?
<arjanb>a bug that dissappears by looking at it
<GummiEnte>Ok... :/21:20
Well see us in a couple of days...
<arjanb>bye
<GummiEnte>have a nice week.
bye arjan
bye daniel
bye all the other still irc#s---21:21
* GummiEnte leaves
<bonniot>i could reproduce the bug21:35
<arjanb>how?21:41
<bonniot>just write a wrong type in native part of the retyping21:42
the method gets ignored, but it is still present in the global scope
i thought this had been done, but it seems not21:43
it would indeed have been helpful to see the compiler messages, but there must have been something like:21:49
Ignoring retyping because java class MapX is not known
before the NPE
i will commit the fix
and the testcase
<arjanb>that error case sensetive error was because i did nicec test8.b instead of nicec test8.B21:51
so this is more a user error than compiler bug21:54
<bonniot>yes22:07
on unix, the compiler would have said "cannot find package test8.b"
but because your filesystem is case insensitive, it returned test8/B when the compiler asked for directory test8/b22:08
<arjanb>right
is lowercase package name not the standard java style?22:09
<bonniot>yes, it is
<arjanb>are you making a release or is there something to be fixed first?23:29
<bonniot>i will make the release tomorrow (fells like I said that before :-)23:32
are there things you want to commit?
<arjanb>no
good night00:00
* arjanb leaves00:04
* bonniot leaves00:34
* ChanServ leaves
* Bluelive leaves
* ChanServ joins00:36
* bonniot joins
* Bluelive joins
* bonniot leaves01:05
* ChanServ leaves01:10
* Bluelive leaves
* ChanServ joins01:11
* Bluelive joins