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

Using timezone: Central European Time
* zzorn_afk leaves02:13
* bonniot leaves03:05
* arjanb leaves04:10
* Buggaboo joins04:36
* Buggaboo leaves05:14
* zzorn joins10:23
* CIA-2 leaves10:39
* ArtemGr joins11:29
* CIA-2 joins11:45
* bonniot joins11:53
* ChanServ leaves12:07
* ChanServ joins12:09
Thanks for the Xdebug fix!12:20
These two things (source line information and remote debugging) are really supplement each other.
* ArtemGr leaves13:10
<CIA-2>03bonniot * 10Nice/src/gnu/expr/LambdaExp.java: 14:20
Revert to revision 1.26 since the case of falsely reachable points because
of 'assert false' is handled in the more general case by
stdlib/nice/lang/inline/Assert.java revision 1.8.
* arjanb joins15:42
* ArtemGr joins15:51
<bonniot>arjanb: I'm thinking about dropping the SourceFile attribute completely. It cannot be accurate anyway, and the info is in SourceDebugExtension. Do you see any problem with that?15:52
ArtemGr: what tools are you using for debugging?15:53
<arjanb>the only thing SourceFile is used for is stacktraces i think
<bonniot>well, other tools can also try to use it. debuggers for instance15:55
<ArtemGr>bonniot: jdb when i need a stack trace to see what's going on and Eclipse when i need to debug something complicated (lately i try to use jdb for debugging too).
<bonniot>does Nice play well with the eclipse debugger at the moment?15:56
ie does eclipse implement jsr 045?
<ArtemGr>bonniot: No, Eclipse can only peek into Java code for now. That's why I'm trying to debug with jdb lately.15:57
<bonniot>i see15:58
i think eclipse is supposed to have some SourceDebugExtension support. that should be investigated
<ArtemGr>JSwat can set breakpoints in Nice sources (very nice). But it isn't stable currently, probably becouse it is in the middle of rewrite.
<bonniot>jswat does work well with nice, still. easier to use than jdb ;-)15:59
using 2.x or 3?
<ArtemGr>2x-dev I have
<bonniot>there is a minor problem with recent versions: you have to set the stratum to Default manually
i'm having the author fix that, he agrees ;-)16:00
jswat 3 is the rewrite. 2.x should be stable
i have to go, i'be be away for a couple of hours...16:01
<ArtemGr>I had crashes in 2.x..
<bonniot>you should try to report the bug...16:02
<ArtemGr>All right, I'll try next time. : )
<bonniot>oh, and don't you want to investigate why eclipse is not working with nice? ;-))16:03
<ArtemGr>... I'll think about it!.. 8-)16:05
<bonniot>in a first step, it should be as simple as researching, or asking on their mailing list, if it is supposed to work yet20:07
<ArtemGr>What is com.sun.jdi ?20:25
<bonniot>Java Debugger Interface or something like that20:27
it's an API for creating debuggers20:28
<ArtemGr>Eclipse apparently supports JSR-045, there is a complicated SourceDebugExtension parser and sparce references to JSR-045 in debugger comments. From the first page of googling it seems 045 is implemented primarily to allow JSP (j server pages) debugging..20:30
<bonniot>ok, that's good news20:32
it's funny that they are parsing SourceDebugExtension, because the JDI is supposed to do that for you...
<ArtemGr>It seems they have their own implementation. "this class implements the corresponding interfaces declared by the JDI specification. See the com.sun.jdi package for more information. "20:35
<bonniot>ok. weird20:36
can you start debugging Nice code at all? what happens?20:37
<ArtemGr>When exception is catched inside Nice compiler I see the following stack trace:20:40
Thread [main] (Suspended (exception AccessControlException))
AccessControlContext.checkPermission(Permission) line: 269
AccessController.checkPermission(Permission) line: 401
SecurityManager.checkPermission(Permission) line: 524
SecurityManager.checkRead(String) line: 863
FileInputStream.<init>(File) line: 100
Debug.<clinit>() line: 49
Typing.<clinit>() line: 667
Package.startNewCompilation() line: 287
fun.setMainPackage(Compilation, String) line: 21
Compilation.setMainPackage(String) line: not available
fun.compile(Compilation, String, String, String, boolean) line: 129
Compilation.compile(String, String, String, boolean) line: not available
fun.compile(Compiler) line: 290
Compiler.compile() line: not available
Template.compileNiceTee(Map) line: 319
Template.handle(Parameters) line: 118
fun.runTest(NiceTestNiceTee) line: 44
NiceTestNiceTee.runTest() line: not available
NiceTestNiceTee(TestCase).runBare() line: 127
TestResult$1.protect() line: 106
TestResult.runProtected(Test, Protectable) line: 12420:41
TestResult.run(TestCase) line: 109
NiceTestNiceTee(TestCase).run(TestResult) line: 118
TestSuite.runTest(Test, TestResult) line: 208
TestSuite.run(TestResult) line: 203
TestRunner.doRun(Test, boolean) line: 116
TestRunner.doRun(Test) line: 109
TestRunner.run(Test) line: 72
Suite.testMe() line: 18
Start.realMain(String[]) line: 164
Start.main(String[]) line: 51
It seems to me that source debug extension is ignored here.
<bonniot>that's in the debugger? or just running the generated program under eclipse?20:42
<ArtemGr>In the ebugger, with AccessControlException being intercepted.
<bonniot>at the moment, the JDK itself does not use SourceDebugExtension when printing stack traces
nicec generates code to catch exception in main and print stack traces20:44
<ArtemGr>I doubt Nicec will say "Thread [main] (Suspended (exception AccessControlException))".
<bonniot>correct, that's not it
i'm just saying that SDE is not ever known to work in stack traces20:45
You wrote the Start class?20:46
<bonniot>ok. but anyway the exception was not propagated there, right?20:47
<ArtemGr>BTW, Eclipse can find the Nice source when I hit "Open Declaration" (F3) from the Java source. That probably means, that Eclipse IS able to see source file location in the bytecode. It just can't see it in the stack trace which is used when the thread is suspended in the debugger.20:51
and can you set breakpoints in the Nice source file?20:53
which version of eclipse are you using?20:54
I can set breakpoints, but when I do, the breakpoint is automatically jumping to the end of the method and it doesn't work when debugging.20:55
and what about stepping into Nice code?20:56
<ArtemGr>I've said it doesn't work. What did you expect? : )
<bonniot>yeah. just trying to understand how much they've implemented20:57
<ArtemGr>Stepping works the same way - i can see current variables on the stack, but source line information is wrong.
Another stack trace:21:00
Thread [main] (Suspended (exception IllegalArgumentException))
fun.runTest(NiceTestCms) line: 84
NiceTestCms.runTest() line: not available
NiceTestCms(TestCase).runBare() line: 127
TestResult$1.protect() line: 106
TestResult.runProtected(Test, Protectable) line: 124
TestResult.run(TestCase) line: 109
NiceTestCms(TestCase).run(TestResult) line: 118
TestSuite.runTest(Test, TestResult) line: 208
TestSuite.run(TestResult) line: 203
TestRunner.doRun(Test, boolean) line: 116
TestRunner.doRun(Test) line: 109
TestRunner.run(Test) line: 72
Suite.testMe() line: 18
Start.realMain(String[]) line: 164
Start.main(String[]) line: 51
The actual exception is thrown by me from "testCms.nice", line 26.
<bonniot>the "line: not available" one corresponds to the dispatch method. it rightly does not have line info because it is "synthetic"21:01
i guess the wrong numbers are the untranslated ones (ie SDE is ignored)21:02
the good news is that this does not look like the standard JDK stack trace
so I guess this is custom eclipse code too
so they should be able to change it to use SDE
i guess the developers should really be asked about this21:03
i'm trying on #eclipse-dev at the moment
<ArtemGr>I think they just do this in their JSP plugin, and do not in standard Java plugin...21:04
<bonniot>but isn't it the same debugger?
with JSR 045, there is a standard, so you should be able to do generic support, not for a specific language21:05
<ArtemGr>But this debugger is invoked from larger GUI and I'm sure there is a lot of options and coupling points.21:07
Somewhat wild example: I can view Nice sources read-only (with Java syntax highlighting!), when referencing to them from the bytecode (Eclipse provide view of actual classes on the classpath), but I can't force Eclipce to edit the ".nice" file as a ".java" file. ".java" extension is just hardwired into the GUI. I even full-text searched Eclipse distribution: there is no way to say to Java GUI that21:11
".nice" file should be opened in Java editor. I'm sure there can be hardwired debugger options also..
<bonniot>so when you use "Open Declaration", where does the Nice file appear?21:49
<CIA-2>03bonniot * 10Nice/src/ (gnu/expr/LambdaExp.java bossa/modules/Package.java): 22:20
Don't include a SourceFile attribute in the generated classes.
It's only SourceDebugExtension that can give accurate source information.
<ArtemGr>bonniot: In the editor.22:22
File name displayed (in the tab) is not the original one though, but of the class opened. Source file is "testCms.nice". File name displayed: "NiceTestCms.class". But the source displayed is the one which is in the "testCms.nice"..22:24
Can send you a screenshot if you wish.22:25
<bonniot>is it the text editor or the java editor?22:26
<ArtemGr>It's a java editor, becouse there are javish things like breakpoint margin and folding margin (I can fold Nice methods) and syntax highlighting, neither of these is supported in the text editor (in which I have to edit Nice sources, BTW).22:29
<bonniot>weird mix22:33
eventually all this should be worked out by the eclipse plugin for nice
at the moment, it looks to me that the easiest thing to fix would be the line numbers in stack traces
would you care to submit a bug report/rfe?22:34
<ArtemGr>BTW, Java syntax highlighting works very well for Nice. I wonder if Nice plugin should extend Java plugin instead of reimplementing all these things.
<bonniot>yes, it's a possibility22:37
<ArtemGr>All right, I'll try to search mailing lists and perhaps submit a bug report tomorrow (monday).
<bonniot>i just wrote to Martin to know how he's doing22:38
<ArtemGr>Have to go. Good wishes.22:44
* ArtemGr leaves
<CIA-2>03bonniot * 10Nice/src/ (3 files in 3 dirs): 23:09
Give the end of the method as the location of implicit returns, so as to
make debuggers display sensible lines when jumping to the end of a
void method.
03bonniot * 10Nice/NEWS: 23:34
Give the end of the method as the location of implicit returns, so as to
make debuggers display sensible lines when jumping to the end of a
void method.

Generated by Sualtam