backtrace in cocoa callbacks ...
I guess the question is, do they (backtrace in cocoa/framework callbacks) ever work? Since everything in a cocoa is basically a callback, if they don't ... it makes things tough (for me, at least). I get the exceptions and I can catch/rescue them, but the backtraces seem always to be empty when I'm running in a Cocoa callback like -applicationDidFinishLaunching.
Hi Steven: I've noticed that my backtraces (when I get them) are often incomplete. Some method calls will be missing from the backtrace. But I'm more concerned that some errors, e.g., undefined method names, will often cause a loop that I can't catch. And if I don't kill it quickly enough it will use up memory until the Finder crashes requiring a hard reset. This can make debugging difficult. I assume that the looping occurs somewhere searching the Cocoa object inheritances. My experience thus far indicates that MacRuby will be fast enough for many large applications, but I don't think it will be widely accepted until it is robust enough to catch most errors so that they can be dealt with. After viewing the introduction to Xcode 4 and LLVM, I am curious if MacRuby compiler could be integrated into and directly compiled by LLVM. LLVM claims to have much improved diagnostics and an enviable analysis phase. Is this idea on the MacRuby roadmap? Bob Rice On Sep 14, 2010, at 5:36 PM, Steven Parkes wrote:
I guess the question is, do they (backtrace in cocoa/framework callbacks) ever work? Since everything in a cocoa is basically a callback, if they don't ... it makes things tough (for me, at least). I get the exceptions and I can catch/rescue them, but the backtraces seem always to be empty when I'm running in a Cocoa callback like -applicationDidFinishLaunching. _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On 15 Sep 2010, at 00:00, Robert Rice wrote:
After viewing the introduction to Xcode 4 and LLVM, I am curious if MacRuby compiler could be integrated into and directly compiled by LLVM. LLVM claims to have much improved diagnostics and an enviable analysis phase. Is this idea on the MacRuby roadmap?
MacRuby is already using LLVM, from the homepage: "MacRuby is an implementation of Ruby 1.9 directly on top of Mac OS X core technologies such as the Objective-C runtime and garbage collector, the LLVM compiler infrastructure and the Foundation and ICU frameworks." C --- Caius Durling caius@caius.name +44 (0) 7960 268 100 http://caius.name/
Hi Caius: I was aware that MacRuby uses LLVM runtime but I believe it is still using the GCC 4.2 compiler infrastructure. LLVM claims to support Objective-C, C and C++ compilation with much better diagnostics than GCC. Bob Rice On Sep 17, 2010, at 6:45 AM, Caius Durling wrote:
On 15 Sep 2010, at 00:00, Robert Rice wrote:
After viewing the introduction to Xcode 4 and LLVM, I am curious if MacRuby compiler could be integrated into and directly compiled by LLVM. LLVM claims to have much improved diagnostics and an enviable analysis phase. Is this idea on the MacRuby roadmap?
MacRuby is already using LLVM, from the homepage: "MacRuby is an implementation of Ruby 1.9 directly on top of Mac OS X core technologies such as the Objective-C runtime and garbage collector, the LLVM compiler infrastructure and the Foundation and ICU frameworks."
C --- Caius Durling caius@caius.name +44 (0) 7960 268 100 http://caius.name/
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi Bob, On Sep 17, 2010, at 12:56 PM, Robert Rice wrote:
After viewing the introduction to Xcode 4 and LLVM, I am curious if MacRuby compiler could be integrated into and directly compiled by LLVM. LLVM claims to have much improved diagnostics and an enviable analysis phase. Is this idea on the MacRuby roadmap?
I was aware that MacRuby uses LLVM runtime but I believe it is still using the GCC 4.2 compiler infrastructure. LLVM claims to support Objective-C, C and C++ compilation with much better diagnostics than GCC.
I think you may be referring to the "clang" compiler front-end, not LLVM per se: http://clang.llvm.org/ I believe it is possible to build MacRuby with clang, though we don't take advantage of any clang-specific features since Ruby by default builds with -c99 strict mode. Clang is only about compile-time diagnostics and static analysis for C code, which is useful for people debugging the underlying implementation but not of general interest. In terms of performance, the important aspect is the LLVM back-end, which I believe we have always used. -- Ernie P.
Bob Rice
On Sep 17, 2010, at 6:45 AM, Caius Durling wrote:
On 15 Sep 2010, at 00:00, Robert Rice wrote:
After viewing the introduction to Xcode 4 and LLVM, I am curious if MacRuby compiler could be integrated into and directly compiled by LLVM. LLVM claims to have much improved diagnostics and an enviable analysis phase. Is this idea on the MacRuby roadmap?
MacRuby is already using LLVM, from the homepage: "MacRuby is an implementation of Ruby 1.9 directly on top of Mac OS X core technologies such as the Objective-C runtime and garbage collector, the LLVM compiler infrastructure and the Foundation and ICU frameworks."
C --- Caius Durling caius@caius.name +44 (0) 7960 268 100 http://caius.name/
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi Ernest: Yes. The LLVM introduction wasn't clear that the "clang" compiler front-end is a separate product. My target build info list GCC 4.2 for the C/C++ Compiler Version. Is GCC still the best option to use for the C compiler? Thanks, Bob Rice On Sep 17, 2010, at 4:00 PM, Ernest N. Prabhakar, Ph.D. wrote:
Hi Bob,
On Sep 17, 2010, at 12:56 PM, Robert Rice wrote:
After viewing the introduction to Xcode 4 and LLVM, I am curious if MacRuby compiler could be integrated into and directly compiled by LLVM. LLVM claims to have much improved diagnostics and an enviable analysis phase. Is this idea on the MacRuby roadmap?
I was aware that MacRuby uses LLVM runtime but I believe it is still using the GCC 4.2 compiler infrastructure. LLVM claims to support Objective-C, C and C++ compilation with much better diagnostics than GCC.
I think you may be referring to the "clang" compiler front-end, not LLVM per se:
I believe it is possible to build MacRuby with clang, though we don't take advantage of any clang-specific features since Ruby by default builds with -c99 strict mode. Clang is only about compile-time diagnostics and static analysis for C code, which is useful for people debugging the underlying implementation but not of general interest.
In terms of performance, the important aspect is the LLVM back-end, which I believe we have always used.
-- Ernie P.
Bob Rice
On Sep 17, 2010, at 6:45 AM, Caius Durling wrote:
On 15 Sep 2010, at 00:00, Robert Rice wrote:
After viewing the introduction to Xcode 4 and LLVM, I am curious if MacRuby compiler could be integrated into and directly compiled by LLVM. LLVM claims to have much improved diagnostics and an enviable analysis phase. Is this idea on the MacRuby roadmap?
MacRuby is already using LLVM, from the homepage: "MacRuby is an implementation of Ruby 1.9 directly on top of Mac OS X core technologies such as the Objective-C runtime and garbage collector, the LLVM compiler infrastructure and the Foundation and ICU frameworks."
C --- Caius Durling caius@caius.name +44 (0) 7960 268 100 http://caius.name/
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
FWIW, I have a lots of stuff built that does work, that makes it easy (for my needs, anyway) to link to existing ObjC and C++ libraries and quickly prototype a cocoa UI. I have a bunch of rake tasks that can build cocoa app bundles with only dylibs, bundles, and the main mach binary, including vendored gems, etc. It all can be made to work pretty nicely. But the lack of exception traces in cocoa apps, that might be a killer for me. I get an exception and I have no idea where it is. Thinking about it now, dynamic languages are pretty tough to debug without exception traces. Actually, file names/line numbers might be enough, but those don't seem to come through either when called from a cocoa event loop. I'm happy to try to contribute if it's something that's feasible. Given that this is thread/event loop stuff, I'm not sure how difficult this might be ...
Hi Steven, Sorry I haven't seen this thread for a reason. Normally you should get file names / line numbers from backtraces, and if an exception happens in a callback you should see something in your console (the Ruby-side backtrace is the NSException message, so it should be displayed there). This is of course on MacRuby trunk (0.7). If you have a reduction where an exception happens without a backtrace, please attach it to a new ticket and we will look. Laurent On Sep 14, 2010, at 5:56 PM, Steven Parkes wrote:
FWIW, I have a lots of stuff built that does work, that makes it easy (for my needs, anyway) to link to existing ObjC and C++ libraries and quickly prototype a cocoa UI. I have a bunch of rake tasks that can build cocoa app bundles with only dylibs, bundles, and the main mach binary, including vendored gems, etc.
It all can be made to work pretty nicely.
But the lack of exception traces in cocoa apps, that might be a killer for me. I get an exception and I have no idea where it is. Thinking about it now, dynamic languages are pretty tough to debug without exception traces.
Actually, file names/line numbers might be enough, but those don't seem to come through either when called from a cocoa event loop.
I'm happy to try to contribute if it's something that's feasible. Given that this is thread/event loop stuff, I'm not sure how difficult this might be ... _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On Sep 17, 2010, at 6:34 PM, Steven Parkes wrote:
Sorry I haven't seen this thread for a reason.
No worries; I wouldn't think of complaining.
I figured out what's quashing things: I don't get backtraces when I run from a mach executable with dylibs/bundles. I'm not sure which or both of those is causing the issue.
Oh I see the problem then. It is true that the backtracing metadata is forgotten during AOT compilation. It's actually on purpose (to avoid sensitive information to be in the binary), but we should maybe make macrubyc accept -g (like gcc) which would support it. In theory AOT compilation isn't used for development, but I agree that sometimes you might want to do it. Laurent
Oh I see the problem then. It is true that the backtracing metadata is forgotten during AOT compilation. It's actually on purpose (to avoid sensitive information to be in the binary)
Yeah, I actually think that's great.
but we should maybe make macrubyc accept -g (like gcc) which would support it. In theory AOT compilation isn't used for development, but I agree that sometimes you might want to do it.
Yeah, definitely a nice-to-have, but less critical. If I'd realized what was causing the traces to be elided, I probably wouldn't have even posted. I had spent a bunch of time putting together rake tasks to create a compile app bundle and once I had them working, I just kept using them. Guess it's time to expand the tasks to create both Debug and Release bundles a la xcode. Thanks for the help and all the effort!
I like the idea of a -g flag. I actually think AOT will be used increasingly in development scenarios for "code you're not changing" (but may, at some point, want to see in a backtrace) since the temptation for internal libraries and such is to AOT them for speed, once they're basically debugged and working. The code that calls them may not be, however. :) - Jordan On Sep 17, 2010, at 7:02 PM, Laurent Sansonetti wrote:
On Sep 17, 2010, at 6:34 PM, Steven Parkes wrote:
Sorry I haven't seen this thread for a reason.
No worries; I wouldn't think of complaining.
I figured out what's quashing things: I don't get backtraces when I run from a mach executable with dylibs/bundles. I'm not sure which or both of those is causing the issue.
Oh I see the problem then. It is true that the backtracing metadata is forgotten during AOT compilation. It's actually on purpose (to avoid sensitive information to be in the binary), but we should maybe make macrubyc accept -g (like gcc) which would support it. In theory AOT compilation isn't used for development, but I agree that sometimes you might want to do it.
Laurent _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Agreed. I looked at the problem this afternoon but an efficient solution would involve a major change (to interpret the dwarf metadata at runtime), and eventually some LLVM hacking, so let's do that post 0.7. I filed the following ticket to not forget: http://www.macruby.org/trac/ticket/911 Laurent On Sep 17, 2010, at 11:31 PM, Jordan K. Hubbard wrote:
I like the idea of a -g flag. I actually think AOT will be used increasingly in development scenarios for "code you're not changing" (but may, at some point, want to see in a backtrace) since the temptation for internal libraries and such is to AOT them for speed, once they're basically debugged and working. The code that calls them may not be, however. :)
- Jordan
On Sep 17, 2010, at 7:02 PM, Laurent Sansonetti wrote:
On Sep 17, 2010, at 6:34 PM, Steven Parkes wrote:
Sorry I haven't seen this thread for a reason.
No worries; I wouldn't think of complaining.
I figured out what's quashing things: I don't get backtraces when I run from a mach executable with dylibs/bundles. I'm not sure which or both of those is causing the issue.
Oh I see the problem then. It is true that the backtracing metadata is forgotten during AOT compilation. It's actually on purpose (to avoid sensitive information to be in the binary), but we should maybe make macrubyc accept -g (like gcc) which would support it. In theory AOT compilation isn't used for development, but I agree that sometimes you might want to do it.
Laurent _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
participants (6)
-
Caius Durling
-
Ernest N. Prabhakar, Ph.D.
-
Jordan K. Hubbard
-
Laurent Sansonetti
-
Robert Rice
-
Steven Parkes