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
La
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. Prab
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 debugge
> 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
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 bot
> 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.
___
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).
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
>>>
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 20
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 Mac
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 v
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 wi
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
13 matches
Mail list logo
