Re: [MacRuby-devel] dylib hell
> 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 try to mach the version from the OS, but that's a lot easier to say than accomplish. > Did you try renaming the sqlite3 macports library name, or toggle the options > passed to the linker when creating the library? I haven't yet. It was something I thought about, but there are a couple of things about dylibs on OS X that I'm not sure about that might make that moot, In particular, anybody know what happens on OS X if you try to load two dylibs that define the same symbol? Even if I could get both libs to load, I'm not sure how it's going to differentiate the same functions from the two libs. Is it smart enough to remember which symbols came from which libs when the link occured? A variant on that is to statically link sqlite into the gem, but I'm still not sure about duplicate symbols ... ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] FYI - Update on NSView printing problem
Hi Laurent:
Thanks for your reply.
I created a scaled down version of my app using the same print mechanism and it
didn't reproduce the problem.
Rebuilding the app into a new project did not eliminate the problem.
The problem doesn't cause my app to crash, just error messages for the invalid
graphics context and the print operation fails.
I get the same error for all of my views including some very simple ones.
There may be something I'm doing wrong initializing my views but it seems to be
affecting only the small preview window in the PrintPanel - an option that I
can turn off.
My views define the knowsPageRange, rectForPage, and locationOfPrintRect
methods to adjust the position for overprinting pre-printed forms. Possibly
PrintPanel does like my drawing going beyond the printer's clip view bounds,
but I still get the errors commenting out these methods.
In any case, PrintPanel should be outputting a message and canceling the print
operation if it can't create a valid graphics context.
Thanks,
Bob Rice
On Sep 13, 2010, at 11:53 PM, Laurent Sansonetti wrote:
> Hi Robert,
>
> Interesting. Do you reproduce the crash when you use this code into a new
> Xcode project?
>
> If it only crashes in your app, maybe it's related to your view. How complex
> is the view?
>
> Laurent
>
> On Sep 10, 2010, at 9:30 AM, Robert Rice wrote:
>
>> I tracked down my NSView printing problem to the NSPrintPanel preview view.
>> My view printing now works again by overriding the default option to display
>> the small preview view:
>>
>> def print
>> po = NSPrintOperation.printOperationWithView( @printableView )
>> po.printPanel.setOptions( 0 )
>> po.setShowsPrintPanel( true )
>> po.runOperationModalForWindow( @printableView.window, delegate:self,
>> didRunSelector:"printOperationDidRun:success:contextInfo:",
>> contextInfo:nil )
>> end
>>
>> def printOperationDidRun( printOperation, success:success,
>> contextInfo:contextInfo )
>> puts "printOperationDidRun #{ success }"
>> end
>>
>> or I can bypass the printPanel entirely.
>>
>> It will take more experimenting to find out why NSPrintPanel is not creating
>> a graphics context for my NSView or why it would call my drawRect with an
>> invalid context; it works with my PDFView. But now
>> it's a low priority for me since I don't really need the NSPrintPanel
>> preview.
>>
>> Bob Rice
>>
>> ___
>> MacRuby-devel mailing list
>> [email protected]
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] 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. ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] backtrace in cocoa callbacks ...
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 > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] dylib hell
As a quick follow up, I realized that since the focus of my macruby stuff is cocoa apps which I compile into mach executables avoiding the macruby executable, I have the opportunity to (and, actually, must) add the custom sqlite there. Doesn't work for CLI apps that run against macruby, but those I can still do with 1.8/1.9 (so far, anyway). On Sep 13, 2010, at 8:56 PM, Laurent Sansonetti wrote: > Hi Steven, > > I see, that's a problem indeed. I'm not even sure loading the sqlite3 > macports version first is a good idea, since CFNetwork might not work with > 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 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 macruby doesn't link to any sqlite, >> CFNetwork does, and it links against the the system version. That link gets >> resolved before the gem extension is loaded, so the system version is used. >> >> I don't have much experience with dylibs on OS X, so I'm not sure if there's >> a good workaround for this. >> >> I can hack a workaround by actually calling out sqlite3 on the macruby link >> line and telling it to look at the maports version. That gets loaded before >> the framework stuff and everything seems happy. >> >> But, it's gross, of course. >> >> Ugh. >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] backtrace in cocoa callbacks ...
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 [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
