> 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
> 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.
___
> I believe there is a problem in the way CFNetwork uses sqlite3 here.
C.f. http://arstechnica.com/civis/viewtopic.php?f=19&t=115763&start=280: i.e.,
CFNetwork/CFURL/NSURL use sqlite to cache responses.
> It seems to prevent any user of Cocoa to use a different version of sqlite3.
Well, it does
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
> that version.
>
> Did you try renaming the sqlite3 macports library name, or toggle the options
> passed to the linker when creating the library?
>
> Laurent
>
> On Sep 12, 2010, at 3:49 PM, Steven Parkes wrote:
>
>> Ugh. The sqlite that ships with OS X does
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 not even sure loading the sqlite3 macports version first is a good idea,
> since CFNetwork might not work with that version.
Yeah, I thought about that. One would hope that sqlite3 is pretty
consistent/upgradable within minor versions at this point, but there's no
guarantee. One could tr
Ugh. The sqlite that ships with OS X doesn't have the full text search module
enabled. This isn't usually a problem: just install a custom version, e.g., via
macports, and then (re)install the sqlite3 gem. Works great for 1.8/1.9.
Fails miserably for macruby.
I think the problem is that while m
> ptr
> = Pointer.new("{ProcessSerialNumber=II}"
> )
Thanks. I had tried Pointer.new_with_type (trying to go from examples I found).
I don't understand the difference between the two (yet).
> However, please note that this will get the current **application** PSN,
> which, in case you run the
> Hope this helps :-)
Yup. I'm getting the hang of bridgesupport (coming from an MRI FFI world ...)
Any obvious reason why this doesn't seem to work?
load_bridge_support_file(...)
psn = ProcessSerialNumber.new
GetCurrentProcess(psn)
p psn
I don't see the member values getting set
> Can you add a little more information to the issue maybe?
The callback is getting most of its parameters typed correctly, but one of them
seems to be not. Not only does #inspect show this, but trying to pass it to a
framework function fails with
2010-08-23 11:09:11.789 macruby[77790:9207] ***
I've got a callback for QTCaptureVideoPreviewOutput
-captureOutput:didOutputVideoFrame:withSampleBuffer:fromConnection getting
called in 0.6, but the result type for didOutputVideoFrame is coming is
__NSCFType rather than CVImageBufferRef.
Looks like the CV types are supposed to work?
_
12 matches
Mail list logo
