Re: [MacRuby-devel] NSBitmapImageRep representationUsingType
Hey
I have prepared a simple project that contains nothing else but the image
downloading/scaling code, but I have kept it so that it works exactly like in
our actual project. I have also put two crash logs in the zip, but the date in
them isn't todays date so i'm not sure whats going on there to be honest, as it
did crash for me just a little while ago.
Here's a link to the file: http://dl.dropbox.com/u/436484/NSBitmapRepTest.zip
I am on another computer at the moment as I'm at work, and it have only crashed
once for me on this computer. I still have to test this project on my home
computer to see how it acts, but I figured I'll post it here right away anyway.
The code for the download and scaling is exactly the same, except that it
downloads the same image over and over instead of different ones, and I updated
the code with the ruby syntax that Thibault mentioned. It is a bit
unpredictable when it will crash, sometimes it works all the way through,
others it crashes after 3 images, and then sometimes after 50 and so on. On my
imac it does crash 98% of the times though, but on this MBP it has only crashed
once so far.
I read somewhere else online that some people had problems using
NSBitmapImageRep TIFFRepresentation on any other than the main thread, and that
someone suspected it was connected to what type of graphics card was in the
computer. I have no idea if this also goes for the method I'm using, ,but I
figured it was worth mentioning. I can't find anything in the Apple docs saying
it can't be used in background threads, but then again, there's a lot of
documentation to search through. ;)
The computer that gives me constant problems is my iMac 24" which I don't
remember exactly what gfx card it is on top of my head, but I'm 99% sure it is
an ATI card in those. :) The computer I'm running on right now is a Macbook Pro
with a NVIDIA GeForce 9400M.
Thanks a lot for the help guys, I really appreciate it, and I love MacRuby. :)
Kenny
12 aug 2010 kl. 01.36 skrev Laurent Sansonetti:
> Hi Kenny,
>
> Could you try to extract the image scaling code (which seems to cause the
> crash if I read well) into a smaller program and see if you still have the
> problem?
>
> A backtrace would be nice, otherwise. If your app crashes you might have a
> crash log in ~/Library/Logs/CrashReporter for it.
>
> Laurent
>
> On Aug 11, 2010, at 1:43 PM, Kenny Lovrin wrote:
>
>> Sure, here's the parts that I think is of value:
>>
>> Heres how my queue is defined:
>>
>> class MetadataDownloader
>>
>> @@queue = Dispatch::Queue.new("se.kennylovrin.test")
>>
>> class << self
>>
>> def fetch(id)
>> downloader = new(id)
>> @@queue.async do
>> downloader.start
>> end
>> end
>>
>> end
>>
>>
>> end
>>
>> I use this by looping an array of integers, calling
>> MetadataDownloader.fetch(var), hoping it will instantiate a new downloader
>> and start it in the queue. :)
>>
>> Then, it does some work, connecting to some API's and downloading som data
>> which contains a url to an image, that url is later passed into this
>> instance method:
>>
>> def save_poster(url)
>> stamp = Time.now.to_i
>> save_path = File.join CoreDataManager.instance.app_support_dir,
>> "posters", "#{stamp}.jpg"
>> save_path_small = File.join
>> CoreDataManager.instance.app_support_dir, "posters", "#{stamp}_small.jpg"
>>
>> fm = NSFileManager.defaultManager
>> unless fm.fileExistsAtPath save_path
>> error = Pointer.new_with_type "@"
>> unless fm.createDirectoryAtPath
>> save_path.stringByDeletingLastPathComponent,
>> withIntermediateDirectories:true, attributes:nil, error:error
>> NSLog "Failed to create dir for poster"
>> return nil
>> end
>>
>> img_data = NSData.dataWithContentsOfURL
>> NSURL.URLWithString(url)
>>
>> if img_data && fm.createFileAtPath(save_path,
>> contents:img_data, attributes:nil)
>> NSLog "Fullsize poster saved"
>> jpeg_data = rescaled_image img_data
>> unless jpeg_data &&
>> jpeg_data.writeToFile(save_path_small, atomically:true)
>> NSLog "Failed to scale down poster at
>> #{save_path_small}"
>> return nil
>> end
>> NSLog "Small poster saved"
>> else
>> NSLog "Failed to save poster at #{save_path}"
>> return nil
>> end
>>
>>
[MacRuby-devel] PDF_View - Quartz Framework
I recently added the Quartz framework and a PDF_View to my app. The PDF_View works great except for these warnings when I start my app: 2010-08-12 10:49:45.297 MacDriverLog[265:a0f] [QL] image sp_zoomp_handle not found 2010-08-12 10:49:45.300 MacDriverLog[265:a0f] [QL] image sp_zoomp_track_left not found 2010-08-12 10:49:45.301 MacDriverLog[265:a0f] [QL] image sp_zoomp_track_center not found 2010-08-12 10:49:45.304 MacDriverLog[265:a0f] [QL] image sp_zoomp_track_right not found 2010-08-12 10:49:46.331 MacDriverLog[265:a0f] __CFServiceControllerBeginPBSLoadForLocalizations timed out while talking to pbs Do I need to be concerned with these messages? Although my PDF_View works both for display and printing, My other views now create an invalid graphics context when printing although they still display OK. After the call to beginDocument, NSPrintOperation.currentOperation.context is nil and NSGraphicsContext.currentContext.graphicsPort is invalid. Calling NSPrintOperation.currentOperation.createContext changes the context to NSPrintSpoolingGraphicsContext but then my app just hangs. Has anyone experienced this problem? I am using MacRuby 0.6 stable release. Thanks for your help, Bob Rice ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] MacRuby hanging
Hi MacRuby developers: Using MacRuby 0.6 stable, the most time consuming problem debugging is the tendency of MacRuby to hang without generating an error when calling an undefined method name. I usually can breakpoint until I find my error but occasionally the undefined method is called from a UI element and it is hard to find the error. Have the error diagnostics been improved since the 0.6 stable release? Thanks, Bob Rice ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] PDF_View - Quartz Framework
You can safely ignore these warnings, they're left-overs in the QuickLook framework. Afaik Laurent already filed a radar ticket for this. I can't help you with your printing problem, but filing a ticket with a reproducible reduction never hurts :) Eloy Sent from my iPad On 12 aug. 2010, at 17:22, Robert Rice wrote: > I recently added the Quartz framework and a PDF_View to my app. The PDF_View > works great except for these warnings when I start my app: > > 2010-08-12 10:49:45.297 MacDriverLog[265:a0f] [QL] image sp_zoomp_handle not > found > 2010-08-12 10:49:45.300 MacDriverLog[265:a0f] [QL] image sp_zoomp_track_left > not found > 2010-08-12 10:49:45.301 MacDriverLog[265:a0f] [QL] image > sp_zoomp_track_center not found > 2010-08-12 10:49:45.304 MacDriverLog[265:a0f] [QL] image sp_zoomp_track_right > not found > 2010-08-12 10:49:46.331 MacDriverLog[265:a0f] > __CFServiceControllerBeginPBSLoadForLocalizations timed out while talking to > pbs > > Do I need to be concerned with these messages? > > Although my PDF_View works both for display and printing, My other views now > create an invalid graphics context when printing although they still display > OK. After the call to beginDocument, > NSPrintOperation.currentOperation.context is nil and > NSGraphicsContext.currentContext.graphicsPort is invalid. Calling > NSPrintOperation.currentOperation.createContext changes the context to > NSPrintSpoolingGraphicsContext but then my app just hangs. > > Has anyone experienced this problem? > > I am using MacRuby 0.6 stable release. > > Thanks for your help, > 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
Re: [MacRuby-devel] MacRuby hanging
There has been some improvement around exceptions. For instance, no backtrace would printed to the console for Ruby exceptions. But there are probably still cases where the exceptions aren't as helpful as you'd like. Eloy Sent from my iPad On 12 aug. 2010, at 17:31, Robert Rice wrote: > Hi MacRuby developers: > > Using MacRuby 0.6 stable, the most time consuming problem debugging is the > tendency of MacRuby to hang without generating an error when calling an > undefined method name. I usually can breakpoint until I find my error but > occasionally the undefined method is called from a UI element and it is hard > to find the error. > > Have the error diagnostics been improved since the 0.6 stable release? > > Thanks, > 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
Re: [MacRuby-devel] Fibers and Enumerators
I agree (I don't see a performance issue, rather, a compatibility issue) While I am certain everyone would agree that 100% compatibility should be the goal, I am not convinced how "critical" this addition is: in particular, how difficult is it to do a quick code change? Unlike basic data types, there are quite a few reasons I don't see Fibers being a large percentage of any code. Does anyone have any truly compelling examples where Fibers are truly the only/right way to go, vs. an alternate design? I don't see them scaling well (see ruby-doc.org) - meaning, their advantage is restricted in scope. e.g. (MSDN) "In general, fibers do not provide advantages over a well-designed multithreaded application." The term "lightweight" seems to correlate near 1.0 with "fiber" on web pages... one (not all) of GCD's primary goals in life is: lightweight ... which makes me think/agree this really boils down to measuring the pain/cost of having this one feature MIA (e.g. source translation/compatibility) vs. not... -Daniel On Wed, 11 Aug 2010 17:15:54 -0700 "Jordan K. Hubbard" wrote: On Aug 11, 2010, at 3:23 PM, easco wrote: My concern for the feature is focused not so much on the performance impact of using it, as it focuses on the fact that Fibers have been added to the 1.9.x language. They appear to be an important part of the External Enumerators feature and that feature seems to have a lot of people very excited. Any external libraries that make use of Fibers or External Enumerators stand a good chance of not working in MacRuby. In that case MacRuby becomes "Mac-MostOfRuby" which makes it harder to adopt... etc. I'd rather that didn't happen. Perhaps the big take-away from this discussion then is that we need someone to pick up the gauntlet of Fiber support in MacRuby and figure out how to make it perform "acceptably" given the caveats Laurent has already outlined. Any volunteers? - Jordan ___ 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] Fibers and Enumerators
+1 for implementing Fibers in MacRuby. Rob http://robgleeson.github.comWebsite http://github.com/robgleeson GitHub [email protected] On 12 Aug 2010, at 21:33, [email protected] wrote: > > I agree (I don't see a performance issue, rather, a compatibility issue) > > While I am certain everyone would agree that 100% compatibility should be the > goal, I am not convinced how "critical" this addition is: > in particular, how difficult is it to do a quick code change? > Unlike basic data types, there are quite a few reasons I don't see Fibers > being a large percentage of any code. > > Does anyone have any truly compelling examples where Fibers are truly the > only/right way to go, vs. an alternate design? > > I don't see them scaling well (see ruby-doc.org) - meaning, their advantage > is restricted in scope. > > e.g. (MSDN) > "In general, fibers do not provide advantages over a well-designed > multithreaded application." > > The term "lightweight" seems to correlate near 1.0 with "fiber" on web > pages... one (not all) of GCD's primary goals in life is: lightweight ... > which makes me think/agree this really boils down to measuring the pain/cost > of having this one feature MIA (e.g. source translation/compatibility) vs. > not... > > -Daniel > > > On Wed, 11 Aug 2010 17:15:54 -0700 > "Jordan K. Hubbard" wrote: >> On Aug 11, 2010, at 3:23 PM, easco wrote: >>> My concern for the feature is focused not so much on the performance impact >>> of using it, as it focuses on the fact that Fibers have been added to the >>> 1.9.x language. They appear to be an important part of the External >>> Enumerators feature and that feature seems to have a lot of people very >>> excited. >>> Any external libraries that make use of Fibers or External Enumerators >>> stand a good chance of not working in MacRuby. In that case MacRuby becomes >>> "Mac-MostOfRuby" which makes it harder to adopt... etc. I'd rather that >>> didn't happen. >> Perhaps the big take-away from this discussion then is that we need someone >> to pick up the gauntlet of Fiber support in MacRuby and figure out how to >> make it perform "acceptably" given the caveats Laurent has already outlined. >> Any volunteers? >> - Jordan >> ___ >> 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] Break Points. Was Re: MacRuby hanging
On 13/08/2010, at 3:31 AM, Robert Rice wrote: > Hi MacRuby developers: > > Using MacRuby 0.6 stable, the most time consuming problem debugging is the > tendency of MacRuby to hang without generating an error when calling an > undefined method name. I usually can breakpoint until I find my error but > occasionally the undefined method is called from a UI element and it is hard > to find the error. Are you putting breakpoints in your Ruby? How do you do this? I'm having a hell of a time debugging MacRuby. Henry ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
