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

Using timezone: Central European Time
* zzorn_sleep leaves01:55
* arjanb leaves02:13
* CIA-3 leaves04:05
* CIA-1 joins04:06
* CIA-1 leaves04:33
* CIA-1 joins04:36
* zzorn joins08:25
* ArtemGr joins12:44
* glimming joins12:54
what are the best IRC channels for programming languages (theory, semantics) and category theory?
<ArtemGr>Don't know, using IRC only for Nice, personally.13:02
* arjanb joins13:13
* glimming leaves13:17
* arjanb leaves13:47
* arjanb joins13:48
* bonniot joins15:13
hi15:17
<ArtemGr>Salute.
<arjanb>hi15:18
<bonniot>arjanb: did you get my email?15:19
<arjanb>yes15:20
<bonniot>i can look at one issue now. is there a more urgent one?15:21
arjanb: could you add a testcase for the change you made in Assert?15:22
<ArtemGr>a vote: breaking out of synchronized blocks15:23
<arjanb>that is http://sourceforge.net/tracker/index.php?func=detail&aid=1090881&group_id=12788&atid=11278815:24
<bonniot>ok, i'll look at that
<arjanb>i can try to create to simpler testcase for assert15:25
<bonniot>i just saw none was commited15:27
is the submitted one too complex?
<arjanb>yes 2 package, 80 lines15:28
<ArtemGr>It was taken from a real program without understanding what's wrong, i think there could be 10 times smaller test case.
I'll try to write a small test case just now. See you in five minutes.15:33
<bonniot>thanks15:34
<ArtemGr>Submitted a shorter test case to http://sourceforge.net/tracker/index.php?func=detail&aid=1090881&group_id=12788&atid=11278815:54
Although the code currently throws "nice.lang.AssertionFailed", the expected behaviour is to fail at compile time, with a message that "fun" counld be used without being initialized.15:57
<bonniot>are you sure you put it in the right bug report? this seems to be about assert, not synchronization or break16:00
<arjanb>i think that testcase is for http://sourceforge.net/tracker/index.php?func=detail&aid=1113263&group_id=12788&atid=11278816:03
<CIA-1>03fbarber * 10Nice/src/nice/tools/doc/utilities.nice: Added method isSourceAvailable(String packageName)16:08
<ArtemGr>Thanks. reposted to http://sourceforge.net/tracker/index.php?func=detail&aid=1113263&group_id=12788&atid=11278816:09
<bonniot>do we know cm_'s email address?16:28
<arjanb>i don't, maybe you he's subsribed to nice-swing16:29
grrr, i'm still forgetting sentence parts16:32
<CIA-1>03arjanb * 10Nice/testsuite/compiler/designByContract/assert.testsuite: Testcase for compilation of bug #1113263.16:42
<bonniot>i seem to have the fix for break16:45
i'll run the whole testsuite to make sure it does not break anything16:46
<arjanb>there should be a testcase for that somewhere
statements\loops\break.testsuite16:52
<bonniot>yes, that one passes too :-)16:56
<ArtemGr>Last time we have been discussed Nice bootstrapping with Arjan (http://confer09.condor-edv.com/nice@freenode/2005-02-05.html).16:58
I appreciate him pointed me that http://nice.sourceforge.net/nice.jar is working again, but still I am curious about tinkering with Nice internals, and it's not very convenient for me to use the current UNIX bootstrapping, since I'm workiing in Eclipse and on Windows. Daniel, I wonder if you have an opinion of whether it is worth it to have alternative bootstrapping, and what it should be?
<arjanb>daniel: do you have a testcase for when there's a break/continue that doesn't leave the try finally block?
<bonniot>arjanb: yes, i'll add one of those17:43
ArtemGr: yes, it can only be good to have another bootstrap system, either for windows, or platform independent17:44
arjan is already doing it on windows17:45
<ArtemGr>Strange he doesn't mentioned it.I was going to do it myself, which would have been a needless strain then.17:47
<bonniot>i'm reading your previous discussion17:53
<ArtemGr>Or perhaps it is the Cygwin makefile patch what is meaned for Windows?
<bonniot>for what it's worth, on linux i'm also using GNU make 3.80, so I wonder why it doesn't work on BSD
<ArtemGr>{} might be a shell pattern
<bonniot>right17:57
bash?
<arjanb>i have a batchfile for windows but it behaves slightly different from the makefile, uses hardcoded directories and it needs preparations to work18:00
<ArtemGr>"gmake SHELL=/usr/local/bin/bash" fixes the shell problem (with {code/*.java,util/JDK.java}).18:06
<CIA-1>03bonniot * 10Nice/ (5 files in 3 dirs): Properly execute finally clauses when breaking out of a loop (fixes #1090881).18:07
<ArtemGr>The next thing is with "cp -a classes-inline/* classes": cp: illegal option -- a
<bonniot>hu, a cp without -a ??
-a, --archive18:08
same as -dpR
is this an old system?
<ArtemGr>FreeBSD uses it's own cp, while "-a" seems to be a GNU extension.
<bonniot>oh, i would have thought they used the GNU tools18:09
<ArtemGr>Linux "cp" has a section "POSIX OPTIONS" in the manual.
I think "cp -p" is sufficient, I doubt there are symbolink links involved.18:12
<bonniot>i agree18:14
<ArtemGr>Strange:
Encountered "=".
Was expecting one of:
" /usr/home/artem/tempNice/Nice/src/bossa/syntax/constant.nice: line 327, column 18:
" /usr/home/artem/tempNice/Nice/src/bossa/syntax/constant.nice: line 327, column 18:
Encountered "=".
Was expecting one of:
<arjanb>what's your current nicec version?18:16
<ArtemGr>build 2004.09.22
I'll try the latest now.
All right, I've just compiled Nice under FreeBSD 5.3.18:23
The only change to the Makefile is to replace "cp -a" with "cp -R -p" at line 169.18:24
When embedding Nice compiler into my project (used to compile NiceTee templates) there is a new error when some of the objects involved are obfuscated (compiler itself is not obfuscated, just copied into the jar)...18:30
Exception in thread "PoolThread-8" java.lang.InternalError: name is too long to represent
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)18:31
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at bossa.syntax.dispatch.resetAlternatives(dispatch.nice)
at bossa.modules.Package.startNewCompilation(Package.java:290)
at bossa.modules.fun.setMainPackage(Compilation.nice:78)
at bossa.modules.Compilation.setMainPackage(Compilation.nice)
at nice.tools.compiler.fun.compile(interface.nice:37)
at bossa.modules.Compilation.compile(Compilation.nice)
at ru.glim.nicetee.fun.compile(tee.nice:290)
at ru.glim.nicetee.Compiler.compile(tee.nice)
Any idea what might have been changed so that I can no longer compile in an obfuscated environment? Or maybe there are parts of the compiler I failed to include into the jar?
<bonniot>about the Makefile, didn't you also need to change the shell expression?18:32
oh ok, using bash solves it
<ArtemGr>"SHELL=" in the Makefile didn't work. But in the command line it did.18:33
<bonniot>ok
what is provoking an obfuscation?
<arjanb>is compiled nice code obfuscated?18:35
<ArtemGr>Oh, I just noticed the "SHELL = /bin/sh" line in your Makefile. I think that is what trigger the wrong shell! Becouse I automatically have "SHELL=/usr/local/bin/bash" in environment (set | grep SHELL).
No, compiled code is not obfuscated, furthermore, the obfuscation is currently turned off, I currently use the obfuscator just to shrink libraries and pack everything into a single jar.18:37
<CIA-1>03bonniot * 10Nice/Makefile: Avoid non-POSIX option of cp (-a).18:38
<bonniot>so doesn't it look like a bug in the obfuscator?
<ArtemGr>It worked all right with previous versions of Nice. So I've asked, what might have been changed to trigger this. Forgive me if that's a naive question. : )18:40
Changed in two last months.18:41
Nice should not be obfuscated at all, it is marked as library to the obfuscator, and inserted into my jar with <jar destfile="${shrinkedJar}" update="yes" duplicate="fail">18:42
<zipfileset src="${niceJar}"/>
So the problem is with Nice handling shrinked (not obfuscated!) classes.18:43
<bonniot>i'm not sure it's Nice handling the classes. in the stack trace, there is a call to java's class loader, which seems to fail because a class is malformed18:46
java.lang.InternalError: name is too long to represent
InternalError: Thrown to indicate some unexpected internal error has occurred in the Java Virtual Machine.18:47
this actually looks like a JVM internal bug18:48
so I plead not guilty on this one ;-)
<ArtemGr>All right. Excuse me for bothering. Anyway, I got your answer on this, thanks.18:50
<bonniot>no problem
in the recent changes, i don't see anything obvious that could trigger this bug18:51
<ArtemGr>That's what I mean saying "I've got your answer". ; )18:52
<bonniot>i could imagine there is a subttle bug in the obfuscator, which is triggered by random change in the bytecode generated by the new version of Nice
then there is a JVM bug that fails to nicely report a class format error
of course that's just a guess18:53
<ArtemGr>My code have a lot of dependencies: Nice uses Java, Java uses Nice, Nice uses Java, and so on. I'll try to rebuild everything, for starters.
<bonniot>you could try to run a bytecode verifier to help locating the problem
<ArtemGr>I haven't thought about verifier, thanks.18:54
So, since "a batchfile for windows ... needs preparations to work" is not a best automatic sollution, I still am willing to repeat my question. What is the preferred way to implement bootstrapper: ant script, custom Java program, custom Nice program, something else?19:01
Or should I say: "If I would to implement some Nice bootstrapper, would it be of any use?"19:10
<arjanb>i think it hasn't any added use now but it might later19:37
the development version won't be broken regularly anymore and makefile works in freebsd now19:38
<ArtemGr>Althought I don't personally like ant, it seems your makefile is simple enough to be laid into ant build and it won't worth the trouble to implement anything custom since nobody is interested in it. With any luck I should see to it for the ant bootstrapping to work.19:50
I managed to workaround the java.lang.InternalError mentioned earlier.20:05
It is the "-Xdebug" flag that triggers it.
When I run my program with "-Xdebug" - it fails. Whithout - works as expected.20:06
Daniel, could you run Nice test suite with "-Xdebug"?
<arjanb>here -Xdebug crashes the jvm20:08
<ArtemGr>Yes, but becouse of the Nice bytecode and during the Nice compilation, and it was working perfectly before.
So, even if it is a JVM bug, it is sound to workaround that bug to support debugging under JDK 1.4.2.20:11
I see the same error on JDK 1.4.2_06 under Windows XP and under Linux, and on 1.4.2-p7 on FreeBSD.20:12
p7 is a FreeBSD patchlevel.
<arjanb>sigh, why can the jvm only handle javac generated code :(20:16
<ArtemGr>The error is in /hotspot/src/share/vm/oops/symbolKlass.cpp ...20:24
if (len > symbolOopDesc::max_length()) { 20:25
THROW_MSG_0(vmSymbols::java_lang_InternalError(),
"name is too long to represent");
}
" Don't allow symbol oops to be created which cannot fit in a symbolOop.
" // Don't allow symbol oops to be created which cannot fit in a symbolOop.
(It's a comment there).
Method max_length() returns the max_symbol_length variable.20:27
Which is20:28
enum {
"// max_symbol_length is constrained by type of _length
max_symbol_length = (1 << 16) -1
};
What that symbolOopDesc means I don't know. : )20:29
"// A symbolOop is a canonicalized string.
"// All symbolOops reside in global symbolTable.
"// See oopFactory::new_symbol for how to allocate a symbolOop
<arjanb>i wonder where anything that size could come from20:31
<ArtemGr>max_symbol_length = (1 << 16) -1 - it seems to be 3276820:32
What symbol in bytecode can be of size more than 32768?
Perhaps another bug triggers this error message...
I can modify the sources (since FreeBSD builds Java from sources) to pring the name passed to that symbolOop symbolKlass::allocate_symbol(u1* name, int len, TRAPS) method...20:34
BTW, it seems to be a problem in the hotspot JIT.20:37
Funny, I've forgot if there is a safe way to concatenate strings in cpp.20:44
<arjanb>i won't be surprised if this bug has to do with handling null terminated strings21:02
<ArtemGr>I thing the problem happens when populating a "symbol table". One such population is during "dump_klass" of "ObjectDumper" in "jvmpi.cpp", where symbol used seems to be the name of the dumped class... There are a lot of other places where the "symbol table" is used though.
I can't safely throw the name itself, since it might be not null-terminated. I'll try to print it to the stdout.21:05
Well, sorry for bothering you all. Bye.21:08
* ArtemGr leaves21:09
* zzorn_sleep leaves23:32

Generated by Sualtam