You can subscribe to this list here.
2002 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(3) |
Nov
|
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(1) |
Feb
(11) |
Mar
(9) |
Apr
(1) |
May
(5) |
Jun
(5) |
Jul
(4) |
Aug
(3) |
Sep
(15) |
Oct
(8) |
Nov
(9) |
Dec
(11) |
2004 |
Jan
(5) |
Feb
(2) |
Mar
(1) |
Apr
(3) |
May
(6) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
|
Dec
(3) |
2005 |
Jan
(1) |
Feb
(7) |
Mar
(6) |
Apr
(36) |
May
(20) |
Jun
(42) |
Jul
(21) |
Aug
(12) |
Sep
(56) |
Oct
(5) |
Nov
(55) |
Dec
(53) |
2006 |
Jan
(43) |
Feb
(83) |
Mar
(98) |
Apr
(42) |
May
(68) |
Jun
(55) |
Jul
(50) |
Aug
(104) |
Sep
(13) |
Oct
(70) |
Nov
(37) |
Dec
(42) |
2007 |
Jan
(56) |
Feb
(18) |
Mar
(43) |
Apr
(80) |
May
(65) |
Jun
(149) |
Jul
(103) |
Aug
(71) |
Sep
(62) |
Oct
(67) |
Nov
(72) |
Dec
(63) |
2008 |
Jan
(64) |
Feb
(63) |
Mar
(31) |
Apr
(42) |
May
(71) |
Jun
(62) |
Jul
(37) |
Aug
(25) |
Sep
(5) |
Oct
(2) |
Nov
(7) |
Dec
(14) |
2009 |
Jan
(20) |
Feb
(15) |
Mar
(19) |
Apr
(8) |
May
(7) |
Jun
|
Jul
(37) |
Aug
(12) |
Sep
(19) |
Oct
(5) |
Nov
(1) |
Dec
(4) |
2010 |
Jan
(5) |
Feb
(24) |
Mar
(16) |
Apr
(9) |
May
(4) |
Jun
|
Jul
|
Aug
(6) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(5) |
Dec
|
2016 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Duncan M. <du...@on...> - 2009-07-02 07:37:41
|
On Wed, Jul 1, 2009 at 11:20 PM, Scott Thompson<ea...@ma...> wrote: > If I understand... you're going all the way to NSGraphicsContext just to flip the coordinate system? That's a long row to hoe :-). It would be, but I'm actually going to NSGraphicsContext so that I can draw NSImages and NSStrings on the PDF without having to bang my head against Quartz, especially in its font handling. Duncan |
From: Scott T. <ea...@ma...> - 2009-07-01 22:20:44
|
On Wednesday, July 01, 2009, at 02:51PM, "Duncan McGregor" <du...@on...> wrote: >Hi > >I'm writing PDF's with RubyCocoa, and want to set the current graphics >context to a PDF context from CGPDFContextCreateWithURL so that I can >draw on it. > >Essentially my code says (sorry, ObjC folks, Ruby follows) > >@pdf_context = CGPDFContextCreateWithURL(pdf_url, CGRectMake(0, 0, >100, 100), nil) >..... >NSGraphicsContext.saveGraphicsState >nscontext = >NSGraphicsContext >.graphicsContextWithGraphicsPort_flipped(@pdf_context, true) >NSGraphicsContext.setCurrentContext(nscontext) > >My problem is that graphicsContextWithGraphicsPort:flipped: crashes >RubyCocoa. It's a known issue, and has been fixed, but not shipped in >10.5.7 > >Can anyone suggest any workarounds that could get the pdf_context >current? If I understand... you're going all the way to NSGraphicsContext just to flip the coordinate system? That's a long row to hoe :-). Try something like (typed into mail) CGContextTranslateCTM(pdf_context, 0, 100); # where 100 is the height of the context... CGContextScaleCTM(pdf_context, 1.0, -1.0); use that instead of trying to set the flipped bit. Scott |
From: Duncan M. <du...@on...> - 2009-07-01 20:24:51
|
Hi I can't persuade RubyCocoa to CFRelease a CGImageSourceRef without a bus error - as a result my PDF writing code is leaking like a sieve. require 'test/unit' require 'osx/cocoa' include OSX class QuartzPDFWriterTest < Test::Unit::TestCase def setup @testdir = TestDir.new(self) end def test_dispose_CGImageSource 1.upto(10000) do |i| p i imageSource = CGImageSourceCreateWithURL(NSURL.fileURLWithPath('testdata/pot pourri/ blood.jpg'), nil) image = CGImageSourceCreateImageAtIndex(imageSource, 0, nil) CFRelease image CFRelease imageSource end end end CFRelease imageSource results in a segfault or bus error. For low iteration counts this happens after the test has finished, increasing the count makes it happen during the loop, suggesting a problem during garbage collection I think. If I don't CFRelease imageSource then I run out of memory to load any more images after about 4000 iterations with my test file. Does anyone have any ideas please? Duncan McGregor |
From: Duncan M. <du...@on...> - 2009-07-01 20:05:30
|
Hi I'm writing PDF's with RubyCocoa, and want to set the current graphics context to a PDF context from CGPDFContextCreateWithURL so that I can draw on it. Essentially my code says (sorry, ObjC folks, Ruby follows) @pdf_context = CGPDFContextCreateWithURL(pdf_url, CGRectMake(0, 0, 100, 100), nil) ..... NSGraphicsContext.saveGraphicsState nscontext = NSGraphicsContext .graphicsContextWithGraphicsPort_flipped(@pdf_context, true) NSGraphicsContext.setCurrentContext(nscontext) My problem is that graphicsContextWithGraphicsPort:flipped: crashes RubyCocoa. It's a known issue, and has been fixed, but not shipped in 10.5.7 Can anyone suggest any workarounds that could get the pdf_context current? Thanks in anticipation Duncan McGregor |
From: Allison N. <dem...@ma...> - 2009-05-28 09:15:58
|
The semi-colon in > def actionForLayer_forKey_(layer, key) > return nil; > end probably isn't helping... Le 28 mai 09 à 11:11, Kei Takashima a écrit : > Hi, > > I am using CoreAnimation from RubyCocoa. > > When I define actionForLayer_forKey_ method in my view class as a > delegate of CALayer class, the following exception is thrown. > > RuntimeError: Ruby object `#<TestView:0x227388 class='TestView' > id=0x53e140>' doesn't respond to the ObjC selector > `actionForLayer:forKey:', the method either doesn't exist or is > private > > It seems like RubyCocoa is actually finding the method because if I > omit the method, the program runs happily. Also when I call > instanceRespondToSelector from Ruby side, it returns true, although I > am not sure if this test is meaningful. The other clue is that > EXC_BAD_ACCESS is occasionally thrown, so the RuntimeError above might > be a just spurious of the EXC_BAD_ACCESS. > > I am using RubyCocoa version 0.13.2 on OSX 10.5.7. > > The following is the test code i am using: > > Thanks > Kei > > > require 'osx/cocoa' > OSX.require_framework '/System/Library/Frameworks/ > ApplicationServices.framework/Versions/Current/Frameworks/ > ImageIO.framework' > OSX.require_framework 'QuartzCore' > > class TestView < OSX::NSView > include OSX > > def initWithFrame(frame) > super_initWithFrame(frame) > return self > end > > def drawRect(rect) > end > > def actionForLayer_forKey_(layer, key) > return nil; > end > > def awakeFromNib > thelayer = CALayer.layer > setLayer thelayer > setWantsLayer true > thelayer.backgroundColor = black > puts "rubycocoa version #{OSX::RUBYCOCOA_VERSION}" > puts "instanceRespondTo: > #{TestView.instancesRespondToSelector :actionForLayer_forKey_}" > puts ("respond_to? #{self.respond_to? :actionForLayer_forKey_}") > thelayer.delegate = self > thelayer.opacity = 0.5 > end > > private > def black > values = [0.0, 0.0, 0.0, 1.0] > CGColorCreate(genericRGBSpace, values) > end > > def genericRGBSpace > CGColorSpaceCreateWithName KCGColorSpaceGenericRGB > end > end > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity > professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like > Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
From: Kei T. <ke...@pa...> - 2009-05-28 09:12:08
|
Hi, I am using CoreAnimation from RubyCocoa. When I define actionForLayer_forKey_ method in my view class as a delegate of CALayer class, the following exception is thrown. RuntimeError: Ruby object `#<TestView:0x227388 class='TestView' id=0x53e140>' doesn't respond to the ObjC selector `actionForLayer:forKey:', the method either doesn't exist or is private It seems like RubyCocoa is actually finding the method because if I omit the method, the program runs happily. Also when I call instanceRespondToSelector from Ruby side, it returns true, although I am not sure if this test is meaningful. The other clue is that EXC_BAD_ACCESS is occasionally thrown, so the RuntimeError above might be a just spurious of the EXC_BAD_ACCESS. I am using RubyCocoa version 0.13.2 on OSX 10.5.7. The following is the test code i am using: Thanks Kei require 'osx/cocoa' OSX.require_framework '/System/Library/Frameworks/ ApplicationServices.framework/Versions/Current/Frameworks/ ImageIO.framework' OSX.require_framework 'QuartzCore' class TestView < OSX::NSView include OSX def initWithFrame(frame) super_initWithFrame(frame) return self end def drawRect(rect) end def actionForLayer_forKey_(layer, key) return nil; end def awakeFromNib thelayer = CALayer.layer setLayer thelayer setWantsLayer true thelayer.backgroundColor = black puts "rubycocoa version #{OSX::RUBYCOCOA_VERSION}" puts "instanceRespondTo: #{TestView.instancesRespondToSelector :actionForLayer_forKey_}" puts ("respond_to? #{self.respond_to? :actionForLayer_forKey_}") thelayer.delegate = self thelayer.opacity = 0.5 end private def black values = [0.0, 0.0, 0.0, 1.0] CGColorCreate(genericRGBSpace, values) end def genericRGBSpace CGColorSpaceCreateWithName KCGColorSpaceGenericRGB end end |
From: Gregory C. <gr...@in...> - 2009-05-16 22:16:48
|
Hi Allison, I installed MacRuby 0.4 one weekend to play with it, but on Monday when I was back to work on my RubyCocoa app I found that it would no longer build and run! Uninstalled MacRuby and everything was fine. Greg > The bug doesn't occur in all apps - just in the biggest app that I > have written to date in RubyCocoa (naturally!), though as I said, in > that app, it happens in numerous places (changing a selection in a > group of objects, responding to a timer, serialising an object, etc > etc etc). I'm trying to find a nice small example that reproduces > the bug reliably, but without luck so far. I'll post it once I've > found a good, reliable way of making things blow up. > > Still, based on your experience, it's looking like MacRuby is the > culprit. This does make some sense... > > Alli > > > Le 16 mai 09 à 22:57, Duncan McGregor a écrit : > >> I've had that Xcode trace in my console (various addresses) for at >> least the past few days, before and after updating to 10.5.7, so >> maybe that isn't related to your [BUG]. >> >> My app still passes all its tests without your 'object allocation >> during garbage collection phase' issue, and, to pick one random >> example that we both could run, so does CGPDFViewer. So maybe its >> MacRuby? >> >> Cheers >> >> Duncan >> www.VelOCRaptor.com >> >> On 16 May 2009, at 21:40, Allison Newman wrote: >> >>> Hi everyone, >>> >>> I installed OS X 10.5.7 yesterday, as well as MacRuby 0.4. Since >>> then, whenever I run one of my RubyCocoa apps, I get the following >>> bug: >>> >>> [BUG] object allocation during garbage collection phase >>> ruby 1.8.6 (2008-08-11) [universal-darwin9.0] >>> >>> The application has been stable for over 6 months. Just to be >>> sure, I recovered a version from 3 months ago off TimeMachine, and >>> it still doesn't work, so the bug is definately coming from the >>> environment, not the app. Worse yet, the same bug appears in >>> multiple different places in the app, not just in one particular >>> part of the code, for example during a call to an NSEncoding >>> method, or whilst handling an NSTimer event. >>> >>> Checking the console logs, I now see this appearing all of the >>> time for RubyCocoa apps, when it has never before appeared in the >>> logs: >>> 16/05/09 22:33:20 [0x0-0xa60a6].com.apple.Xcode[2048] >>> Xcode(2048,0xb0103000) malloc: free_garbage: garbage ptr = >>> 0x45d8240, has non-zero refcount = 1 >>> >>> I'll typically see this trace about 50 times during the execution >>> of any RubyCocoa app. >>> >>> Apparently this is a bug in the Ruby interpretor. I don't know >>> which of these installs (10.5.7 or MacRuby) borked my machine, or >>> indeed if it was an interaction beween the two of them, but be >>> aware that you may have this problem before installing either. >>> >>> Alli >>> >> >> ------------------------------------------------------------------------------ >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables >> unlimited royalty-free distribution of the report engine >> for externally facing server and web deployment. >> http://p.sf.net/sfu/businessobjects_______________________________________________ >> Rubycocoa-talk mailing list >> Rub...@li... >> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects_______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
From: Allison N. <dem...@ma...> - 2009-05-16 21:17:28
|
The bug doesn't occur in all apps - just in the biggest app that I have written to date in RubyCocoa (naturally!), though as I said, in that app, it happens in numerous places (changing a selection in a group of objects, responding to a timer, serialising an object, etc etc etc). I'm trying to find a nice small example that reproduces the bug reliably, but without luck so far. I'll post it once I've found a good, reliable way of making things blow up. Still, based on your experience, it's looking like MacRuby is the culprit. This does make some sense... Alli Le 16 mai 09 à 22:57, Duncan McGregor a écrit : > I've had that Xcode trace in my console (various addresses) for at > least the past few days, before and after updating to 10.5.7, so > maybe that isn't related to your [BUG]. > > My app still passes all its tests without your 'object allocation > during garbage collection phase' issue, and, to pick one random > example that we both could run, so does CGPDFViewer. So maybe its > MacRuby? > > Cheers > > Duncan > www.VelOCRaptor.com > > On 16 May 2009, at 21:40, Allison Newman wrote: > >> Hi everyone, >> >> I installed OS X 10.5.7 yesterday, as well as MacRuby 0.4. Since >> then, whenever I run one of my RubyCocoa apps, I get the following >> bug: >> >> [BUG] object allocation during garbage collection phase >> ruby 1.8.6 (2008-08-11) [universal-darwin9.0] >> >> The application has been stable for over 6 months. Just to be >> sure, I recovered a version from 3 months ago off TimeMachine, and >> it still doesn't work, so the bug is definately coming from the >> environment, not the app. Worse yet, the same bug appears in >> multiple different places in the app, not just in one particular >> part of the code, for example during a call to an NSEncoding >> method, or whilst handling an NSTimer event. >> >> Checking the console logs, I now see this appearing all of the time >> for RubyCocoa apps, when it has never before appeared in the logs: >> 16/05/09 22:33:20 [0x0-0xa60a6].com.apple.Xcode[2048] >> Xcode(2048,0xb0103000) malloc: free_garbage: garbage ptr = >> 0x45d8240, has non-zero refcount = 1 >> >> I'll typically see this trace about 50 times during the execution >> of any RubyCocoa app. >> >> Apparently this is a bug in the Ruby interpretor. I don't know >> which of these installs (10.5.7 or MacRuby) borked my machine, or >> indeed if it was an interaction beween the two of them, but be >> aware that you may have this problem before installing either. >> >> Alli >> > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects_______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
From: Duncan M. <du...@on...> - 2009-05-16 20:57:49
|
I've had that Xcode trace in my console (various addresses) for at least the past few days, before and after updating to 10.5.7, so maybe that isn't related to your [BUG]. My app still passes all its tests without your 'object allocation during garbage collection phase' issue, and, to pick one random example that we both could run, so does CGPDFViewer. So maybe its MacRuby? Cheers Duncan www.VelOCRaptor.com On 16 May 2009, at 21:40, Allison Newman wrote: > Hi everyone, > > I installed OS X 10.5.7 yesterday, as well as MacRuby 0.4. Since > then, whenever I run one of my RubyCocoa apps, I get the following > bug: > > [BUG] object allocation during garbage collection phase > ruby 1.8.6 (2008-08-11) [universal-darwin9.0] > > The application has been stable for over 6 months. Just to be sure, > I recovered a version from 3 months ago off TimeMachine, and it > still doesn't work, so the bug is definately coming from the > environment, not the app. Worse yet, the same bug appears in > multiple different places in the app, not just in one particular > part of the code, for example during a call to an NSEncoding method, > or whilst handling an NSTimer event. > > Checking the console logs, I now see this appearing all of the time > for RubyCocoa apps, when it has never before appeared in the logs: > 16/05/09 22:33:20 [0x0-0xa60a6].com.apple.Xcode[2048] > Xcode(2048,0xb0103000) malloc: free_garbage: garbage ptr = > 0x45d8240, has non-zero refcount = 1 > > I'll typically see this trace about 50 times during the execution of > any RubyCocoa app. > > Apparently this is a bug in the Ruby interpretor. I don't know > which of these installs (10.5.7 or MacRuby) borked my machine, or > indeed if it was an interaction beween the two of them, but be aware > that you may have this problem before installing either. > > Alli > |
From: Allison N. <dem...@me...> - 2009-05-16 20:40:45
|
Hi everyone, I installed OS X 10.5.7 yesterday, as well as MacRuby 0.4. Since then, whenever I run one of my RubyCocoa apps, I get the following bug: [BUG] object allocation during garbage collection phase ruby 1.8.6 (2008-08-11) [universal-darwin9.0] The application has been stable for over 6 months. Just to be sure, I recovered a version from 3 months ago off TimeMachine, and it still doesn't work, so the bug is definately coming from the environment, not the app. Worse yet, the same bug appears in multiple different places in the app, not just in one particular part of the code, for example during a call to an NSEncoding method, or whilst handling an NSTimer event. Checking the console logs, I now see this appearing all of the time for RubyCocoa apps, when it has never before appeared in the logs: 16/05/09 22:33:20 [0x0-0xa60a6].com.apple.Xcode[2048] Xcode(2048,0xb0103000) malloc: free_garbage: garbage ptr = 0x45d8240, has non-zero refcount = 1 I'll typically see this trace about 50 times during the execution of any RubyCocoa app. Apparently this is a bug in the Ruby interpretor. I don't know which of these installs (10.5.7 or MacRuby) borked my machine, or indeed if it was an interaction beween the two of them, but be aware that you may have this problem before installing either. Alli |
From: Allison N. <dem...@ma...> - 2009-05-01 07:50:57
|
Hi everyone, I ran into a weird problem today, and I'm not sure if I'm doing something wrong, or if it's a bug in RubyCocoa. Here's the code: def test ary = NSMutableArray.alloc.init (0...100).each{|i| ary << NSObject.alloc.init} bad_array = [] (0...10).each{|i| bad_array << NSObject.alloc.init} ary -= bad_array end This always dies with the following 2009-05-01 09:39:04.138 PropertyInvestor[6113:10b] MainController#init: OSX::OCException: NSInvalidArgumentException - *** -[NSObject copyWithZone:]: unrecognized selector sent to instance 0x14beef00 /Library/Frameworks/RubyCocoa.framework/Resources/ruby/osx/objc/ oc_wrapper.rb:50:in `ocm_send' /Library/Frameworks/RubyCocoa.framework/Resources/ruby/osx/objc/ oc_wrapper.rb:50:in `method_missing' /Library/Frameworks/RubyCocoa.framework/Resources/ruby/osx/objc/ oc_attachments.rb:1328:in `-' /Library/Frameworks/RubyCocoa.framework/Resources/ruby/osx/objc/ oc_attachments.rb:1328:in `each' /Library/Frameworks/RubyCocoa.framework/Resources/ruby/osx/objc/ oc_attachments.rb:1328:in `-' /Users/demallien/Code/PropertyInvestor/PropertyInvestor/build/Debug/ PropertyInvestor.app/Contents/Resources/Database.rb:117:in `test' Now's where it gets weird. If I change ary to be a ruby array, making the code as follows: def test ary = NSMutableArray.alloc.init (0...100).each{ ary << NSObject.alloc.init} ary = [] + ary bad_array = [] (0...10).each{ bad_array << NSObject.alloc.init} ary -= bad_array end everything works just fine. Or if I fill the array with ruby objects rather than NSObjects, again, everything works fine, even if the enclosing array is an NSArray. Is this a bug in RubyCocoa? Or have I done something bad that you shouldn't do to NSArrays? Alli |
From: Duncan M. <du...@on...> - 2009-04-27 09:56:21
|
Thank you very much - timely and practical. Duncan On 27 Apr 2009, at 10:51, Allison Newman wrote: > Hi Duncan, > > I don't know about anyone else, but here's what I do when I want to > use NSData: > > rect = [0, 0, image_params.width_pt, > image_params.height_pt].pack('L_*') > data = NSData.alloc.initWithBytes_length(rect, 16) > > Of course there are probably a few zillion other ways of achieving > the same aim. Hope that helps. > > Alli > > On Monday, April 27, 2009, at 11:05AM, "Duncan McGregor" <du...@on... > > wrote: >> Sorry to have to ask this, but Sourceforge's mailing list search is >> so >> bad that I can't find an answer even if it exists. >> >> I'm trying to put a CGRect into an NSData >> >> rect_pt = CGRectMake(0, 0, image_params.width_pt, >> image_params.height_pt) >> data = NSData.alloc.initWithBytes_length(rect_pt, 16) >> >> ArgumentError: Expected either String/Array/ObjcPtr for argument #0 >> (but got OSX::CGRect). >> >> How do I create the ObjcPtr from a CGRect? >> >> Thanks in anticipation >> >> Duncan McGregor >> www.VelOCRaptor.com - Simple Mac OCR >> >> PS - Is there a better way of creating an NSData from a structure? |
From: Allison N. <dem...@ma...> - 2009-04-27 09:52:09
|
Hi Duncan, I don't know about anyone else, but here's what I do when I want to use NSData: rect = [0, 0, image_params.width_pt, image_params.height_pt].pack('L_*') data = NSData.alloc.initWithBytes_length(rect, 16) Of course there are probably a few zillion other ways of achieving the same aim. Hope that helps. Alli On Monday, April 27, 2009, at 11:05AM, "Duncan McGregor" <du...@on...> wrote: >Sorry to have to ask this, but Sourceforge's mailing list search is so >bad that I can't find an answer even if it exists. > >I'm trying to put a CGRect into an NSData > >rect_pt = CGRectMake(0, 0, image_params.width_pt, >image_params.height_pt) >data = NSData.alloc.initWithBytes_length(rect_pt, 16) > >ArgumentError: Expected either String/Array/ObjcPtr for argument #0 >(but got OSX::CGRect). > >How do I create the ObjcPtr from a CGRect? > >Thanks in anticipation > >Duncan McGregor >www.VelOCRaptor.com - Simple Mac OCR > >PS - Is there a better way of creating an NSData from a structure? > > >------------------------------------------------------------------------------ >Crystal Reports - New Free Runtime and 30 Day Trial >Check out the new simplified licensign option that enables unlimited >royalty-free distribution of the report engine for externally facing >server and web deployment. >http://p.sf.net/sfu/businessobjects >_______________________________________________ >Rubycocoa-talk mailing list >Rub...@li... >https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > |
From: Duncan M. <du...@on...> - 2009-04-27 09:18:31
|
Sorry to have to ask this, but Sourceforge's mailing list search is so bad that I can't find an answer even if it exists. I'm trying to put a CGRect into an NSData rect_pt = CGRectMake(0, 0, image_params.width_pt, image_params.height_pt) data = NSData.alloc.initWithBytes_length(rect_pt, 16) ArgumentError: Expected either String/Array/ObjcPtr for argument #0 (but got OSX::CGRect). How do I create the ObjcPtr from a CGRect? Thanks in anticipation Duncan McGregor www.VelOCRaptor.com - Simple Mac OCR PS - Is there a better way of creating an NSData from a structure? |
From: Arcadio R. G. <arc...@gm...> - 2009-04-05 18:20:56
|
Hi Greg, thanks, this looks great. I'll have a look and ask again if I still find any issue. > Hi Arcadio, > > If it's only a progress bar and log (and the GUI doesn't need to > receive user input while the process is running) then you have another > option. Create an ib_outlet for the view containing your progress > message and progress bar (I called mine @progressView), then when you > make changes to the progress bar, call displayIfNeeded on the view. > Example: > > @progressIndicator.incrementBy(1) > @progressView.displayIfNeeded > > If the contents of the view have changed, this forces it to "refresh" > allowing you to have a working progress bar without needing a thread. > (If you don't have a progress message that needs updating then you can > simply call @progressIndicator.displayIfNeeded to update just the > progress bar.) > > Greg > >> Hi Allison, >> >> thank you for the detailed explanation. >> >> From what I see you propose to run the GUI in a separate process, >> which makes a lot of sense in order to avoid the global interpreter >> lock. >> >> Answering your questions, my app is conceptually very simple. It's a >> batch process. I'd prefer to launch the GUI from the command line. >> The >> GUI will be basically a progress bar and a tree capturing the >> different details of the execution (sort of a log). >> >> Moreover, I'd prefer to use method calls for communicating with the >> GUI, that's why I was asking about how to instantiate a native thread >> from Ruby using RubyCocoa. Let's see if somebody knows how to do >> this. >> >> If not, I'll do what you propose. The interface between the program >> and the GUI is pretty simple. Probably a smart way of communicating >> with the GUI is to use DrB (Distributed Ruby). You get all the >> marshalling for free. It's roughly equivalent to RMI or RPC. >> >> -Arcadio >> >>> Hi Arcadio, >>> >>> OK, so you want a progress bar for your console-based app, is that >>> right? >>> >>> A couple of questions: >>> >>> 1) Do you want to launch the app from the command line, or by >>> clicking >>> on the app icon in the finder? >>> 2) is the console-based app interactive (does it take any input)? >>> 3) How are you planning on communicating between the GUI and the >>> app? >>> Method calls? Communicating using stdin/stdout? >>> >>> Based on what you've said so far, I would suggest launching your UI >>> app from the Finder, then in that app, fork, and launch your command >>> line app in the child process. Make your command line app set up a >>> server socket on a port that you have chosen. All input/output is >>> directed to the socket created during the accept on the server >>> socket. >>> Then, in the parent process, start trying to connect to the server >>> socket your command line app sets up. Once it succeeds, your UI >>> app, >>> and the command line app can communicate, whilst running in seperate >>> processes. If you're really bored, you can even move ruby objects >>> between the two, by marshalling them using YAML etc. >>> >>> It's a bit of a messy solution, but it has a couple of advantages: >>> 1) It actually works (I've done this before), which, when it comes >>> to >>> simultaneous execution and Ruby, is no mean feat. >>> 2) It leaves your original app as a standalone console app, so you >>> can >>> continue to use it as you have up until now. >>> >>> Anyhow, someone else may know of a cleaner way of achieving this, >>> but >>> I for one have never found another way that didn't fall foul of the >>> global interpreter lock. >>> >>> Hope that helps. >>> >>> Alli >>> >>> >>> Le 5 avr. 09 à 11:47, Arcadio Rubio García a écrit : >>> >>>> Hi all, >>>> >>>> I'm trying to build a very simple GUI for my Ruby application using >>>> Cocoa. I have no experience with Cocoa or ObjC, so that might be >>>> part >>>> of the problem. >>>> >>>> Anyway, I have a Ruby text application and I would like to add this >>>> GUI as an observer. So far I have other observers that for instance >>>> write a log to a file, but none of them are graphical. >>>> >>>> My problem is that I need to run the GUI in another thread since >>>> when >>>> I start it, the call to app.run (in the code below) never returns. >>>> As >>>> far as I know, I cannot use Ruby (green) threads. >>>> >>>> Note that due to the design my project, I cannot invert control and >>>> run my application within the thread created by Cocoa. Also, my >>>> code >>>> is not (yet) compatible with Ruby 1.9, so I have to stick to 1.8. >>>> >>>> Can anyone point how to execute app.run in another thread in the >>>> code >>>> shown below. I've tried using >>>> NSThread.detachNewThreadSelector_toTarget_withObject but haven't >>>> been >>>> successful. >>>> >>>> Thanks! >>>> >>>> >>>> require 'osx/cocoa' >>>> include OSX >>>> >>>> >>>> class AppDelegate < NSObject >>>> def init >>>> frame = [200.0, 300.0, 250.0, 100.0] >>>> @win = >>>> NSWindow.alloc.initWithContentRect_styleMask_backing_defer(frame, >>>> >>>> 15, 2, 0) >>>> @win.setTitle 'Test' >>>> @win.setLevel 0 >>>> @bar = NSProgressIndicator.alloc.initWithFrame [10.0, 10.0, 80.0, >>>> 80.0] >>>> @win.contentView.addSubview(@bar) >>>> @bar.setIndeterminate(false) >>>> @win.display >>>> @win.orderFrontRegardless >>>> end >>>> >>>> def step >>>> @bar.incrementBy(20) >>>> end >>>> end >>>> >>>> >>>> app = NSApplication.sharedApplication >>>> app.setDelegate(AppDelegate.alloc.init) >>>> app.run >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Rubycocoa-talk mailing list >>>> Rub...@li... >>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Rubycocoa-talk mailing list >>> Rub...@li... >>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Rubycocoa-talk mailing list >> Rub...@li... >> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > > ------------------------------------------------------------------------------ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
From: Gregory C. <gr...@in...> - 2009-04-05 18:12:18
|
Hi Arcadio, If it's only a progress bar and log (and the GUI doesn't need to receive user input while the process is running) then you have another option. Create an ib_outlet for the view containing your progress message and progress bar (I called mine @progressView), then when you make changes to the progress bar, call displayIfNeeded on the view. Example: @progressIndicator.incrementBy(1) @progressView.displayIfNeeded If the contents of the view have changed, this forces it to "refresh" allowing you to have a working progress bar without needing a thread. (If you don't have a progress message that needs updating then you can simply call @progressIndicator.displayIfNeeded to update just the progress bar.) Greg > Hi Allison, > > thank you for the detailed explanation. > > From what I see you propose to run the GUI in a separate process, > which makes a lot of sense in order to avoid the global interpreter > lock. > > Answering your questions, my app is conceptually very simple. It's a > batch process. I'd prefer to launch the GUI from the command line. The > GUI will be basically a progress bar and a tree capturing the > different details of the execution (sort of a log). > > Moreover, I'd prefer to use method calls for communicating with the > GUI, that's why I was asking about how to instantiate a native thread > from Ruby using RubyCocoa. Let's see if somebody knows how to do this. > > If not, I'll do what you propose. The interface between the program > and the GUI is pretty simple. Probably a smart way of communicating > with the GUI is to use DrB (Distributed Ruby). You get all the > marshalling for free. It's roughly equivalent to RMI or RPC. > > -Arcadio > >> Hi Arcadio, >> >> OK, so you want a progress bar for your console-based app, is that >> right? >> >> A couple of questions: >> >> 1) Do you want to launch the app from the command line, or by >> clicking >> on the app icon in the finder? >> 2) is the console-based app interactive (does it take any input)? >> 3) How are you planning on communicating between the GUI and the app? >> Method calls? Communicating using stdin/stdout? >> >> Based on what you've said so far, I would suggest launching your UI >> app from the Finder, then in that app, fork, and launch your command >> line app in the child process. Make your command line app set up a >> server socket on a port that you have chosen. All input/output is >> directed to the socket created during the accept on the server >> socket. >> Then, in the parent process, start trying to connect to the server >> socket your command line app sets up. Once it succeeds, your UI app, >> and the command line app can communicate, whilst running in seperate >> processes. If you're really bored, you can even move ruby objects >> between the two, by marshalling them using YAML etc. >> >> It's a bit of a messy solution, but it has a couple of advantages: >> 1) It actually works (I've done this before), which, when it comes to >> simultaneous execution and Ruby, is no mean feat. >> 2) It leaves your original app as a standalone console app, so you >> can >> continue to use it as you have up until now. >> >> Anyhow, someone else may know of a cleaner way of achieving this, but >> I for one have never found another way that didn't fall foul of the >> global interpreter lock. >> >> Hope that helps. >> >> Alli >> >> >> Le 5 avr. 09 à 11:47, Arcadio Rubio García a écrit : >> >>> Hi all, >>> >>> I'm trying to build a very simple GUI for my Ruby application using >>> Cocoa. I have no experience with Cocoa or ObjC, so that might be >>> part >>> of the problem. >>> >>> Anyway, I have a Ruby text application and I would like to add this >>> GUI as an observer. So far I have other observers that for instance >>> write a log to a file, but none of them are graphical. >>> >>> My problem is that I need to run the GUI in another thread since >>> when >>> I start it, the call to app.run (in the code below) never returns. >>> As >>> far as I know, I cannot use Ruby (green) threads. >>> >>> Note that due to the design my project, I cannot invert control and >>> run my application within the thread created by Cocoa. Also, my code >>> is not (yet) compatible with Ruby 1.9, so I have to stick to 1.8. >>> >>> Can anyone point how to execute app.run in another thread in the >>> code >>> shown below. I've tried using >>> NSThread.detachNewThreadSelector_toTarget_withObject but haven't >>> been >>> successful. >>> >>> Thanks! >>> >>> >>> require 'osx/cocoa' >>> include OSX >>> >>> >>> class AppDelegate < NSObject >>> def init >>> frame = [200.0, 300.0, 250.0, 100.0] >>> @win = >>> NSWindow.alloc.initWithContentRect_styleMask_backing_defer(frame, >>> >>> 15, 2, 0) >>> @win.setTitle 'Test' >>> @win.setLevel 0 >>> @bar = NSProgressIndicator.alloc.initWithFrame [10.0, 10.0, 80.0, >>> 80.0] >>> @win.contentView.addSubview(@bar) >>> @bar.setIndeterminate(false) >>> @win.display >>> @win.orderFrontRegardless >>> end >>> >>> def step >>> @bar.incrementBy(20) >>> end >>> end >>> >>> >>> app = NSApplication.sharedApplication >>> app.setDelegate(AppDelegate.alloc.init) >>> app.run >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Rubycocoa-talk mailing list >>> Rub...@li... >>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Rubycocoa-talk mailing list >> Rub...@li... >> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > > ------------------------------------------------------------------------------ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
From: Arcadio R. G. <arc...@gm...> - 2009-04-05 14:31:00
|
Hi Allison, thank you for the detailed explanation. From what I see you propose to run the GUI in a separate process, which makes a lot of sense in order to avoid the global interpreter lock. Answering your questions, my app is conceptually very simple. It's a batch process. I'd prefer to launch the GUI from the command line. The GUI will be basically a progress bar and a tree capturing the different details of the execution (sort of a log). Moreover, I'd prefer to use method calls for communicating with the GUI, that's why I was asking about how to instantiate a native thread from Ruby using RubyCocoa. Let's see if somebody knows how to do this. If not, I'll do what you propose. The interface between the program and the GUI is pretty simple. Probably a smart way of communicating with the GUI is to use DrB (Distributed Ruby). You get all the marshalling for free. It's roughly equivalent to RMI or RPC. -Arcadio > Hi Arcadio, > > OK, so you want a progress bar for your console-based app, is that > right? > > A couple of questions: > > 1) Do you want to launch the app from the command line, or by clicking > on the app icon in the finder? > 2) is the console-based app interactive (does it take any input)? > 3) How are you planning on communicating between the GUI and the app? > Method calls? Communicating using stdin/stdout? > > Based on what you've said so far, I would suggest launching your UI > app from the Finder, then in that app, fork, and launch your command > line app in the child process. Make your command line app set up a > server socket on a port that you have chosen. All input/output is > directed to the socket created during the accept on the server socket. > Then, in the parent process, start trying to connect to the server > socket your command line app sets up. Once it succeeds, your UI app, > and the command line app can communicate, whilst running in seperate > processes. If you're really bored, you can even move ruby objects > between the two, by marshalling them using YAML etc. > > It's a bit of a messy solution, but it has a couple of advantages: > 1) It actually works (I've done this before), which, when it comes to > simultaneous execution and Ruby, is no mean feat. > 2) It leaves your original app as a standalone console app, so you can > continue to use it as you have up until now. > > Anyhow, someone else may know of a cleaner way of achieving this, but > I for one have never found another way that didn't fall foul of the > global interpreter lock. > > Hope that helps. > > Alli > > > Le 5 avr. 09 à 11:47, Arcadio Rubio García a écrit : > >> Hi all, >> >> I'm trying to build a very simple GUI for my Ruby application using >> Cocoa. I have no experience with Cocoa or ObjC, so that might be part >> of the problem. >> >> Anyway, I have a Ruby text application and I would like to add this >> GUI as an observer. So far I have other observers that for instance >> write a log to a file, but none of them are graphical. >> >> My problem is that I need to run the GUI in another thread since when >> I start it, the call to app.run (in the code below) never returns. As >> far as I know, I cannot use Ruby (green) threads. >> >> Note that due to the design my project, I cannot invert control and >> run my application within the thread created by Cocoa. Also, my code >> is not (yet) compatible with Ruby 1.9, so I have to stick to 1.8. >> >> Can anyone point how to execute app.run in another thread in the code >> shown below. I've tried using >> NSThread.detachNewThreadSelector_toTarget_withObject but haven't been >> successful. >> >> Thanks! >> >> >> require 'osx/cocoa' >> include OSX >> >> >> class AppDelegate < NSObject >> def init >> frame = [200.0, 300.0, 250.0, 100.0] >> @win = >> NSWindow.alloc.initWithContentRect_styleMask_backing_defer(frame, >> >> 15, 2, 0) >> @win.setTitle 'Test' >> @win.setLevel 0 >> @bar = NSProgressIndicator.alloc.initWithFrame [10.0, 10.0, 80.0, >> 80.0] >> @win.contentView.addSubview(@bar) >> @bar.setIndeterminate(false) >> @win.display >> @win.orderFrontRegardless >> end >> >> def step >> @bar.incrementBy(20) >> end >> end >> >> >> app = NSApplication.sharedApplication >> app.setDelegate(AppDelegate.alloc.init) >> app.run >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Rubycocoa-talk mailing list >> Rub...@li... >> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > > ------------------------------------------------------------------------------ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
From: Allison N. <dem...@ma...> - 2009-04-05 14:06:49
|
Hi Arcadio, OK, so you want a progress bar for your console-based app, is that right? A couple of questions: 1) Do you want to launch the app from the command line, or by clicking on the app icon in the finder? 2) is the console-based app interactive (does it take any input)? 3) How are you planning on communicating between the GUI and the app? Method calls? Communicating using stdin/stdout? Based on what you've said so far, I would suggest launching your UI app from the Finder, then in that app, fork, and launch your command line app in the child process. Make your command line app set up a server socket on a port that you have chosen. All input/output is directed to the socket created during the accept on the server socket. Then, in the parent process, start trying to connect to the server socket your command line app sets up. Once it succeeds, your UI app, and the command line app can communicate, whilst running in seperate processes. If you're really bored, you can even move ruby objects between the two, by marshalling them using YAML etc. It's a bit of a messy solution, but it has a couple of advantages: 1) It actually works (I've done this before), which, when it comes to simultaneous execution and Ruby, is no mean feat. 2) It leaves your original app as a standalone console app, so you can continue to use it as you have up until now. Anyhow, someone else may know of a cleaner way of achieving this, but I for one have never found another way that didn't fall foul of the global interpreter lock. Hope that helps. Alli Le 5 avr. 09 à 11:47, Arcadio Rubio García a écrit : > Hi all, > > I'm trying to build a very simple GUI for my Ruby application using > Cocoa. I have no experience with Cocoa or ObjC, so that might be part > of the problem. > > Anyway, I have a Ruby text application and I would like to add this > GUI as an observer. So far I have other observers that for instance > write a log to a file, but none of them are graphical. > > My problem is that I need to run the GUI in another thread since when > I start it, the call to app.run (in the code below) never returns. As > far as I know, I cannot use Ruby (green) threads. > > Note that due to the design my project, I cannot invert control and > run my application within the thread created by Cocoa. Also, my code > is not (yet) compatible with Ruby 1.9, so I have to stick to 1.8. > > Can anyone point how to execute app.run in another thread in the code > shown below. I've tried using > NSThread.detachNewThreadSelector_toTarget_withObject but haven't been > successful. > > Thanks! > > > require 'osx/cocoa' > include OSX > > > class AppDelegate < NSObject > def init > frame = [200.0, 300.0, 250.0, 100.0] > @win = > NSWindow.alloc.initWithContentRect_styleMask_backing_defer(frame, > > 15, 2, 0) > @win.setTitle 'Test' > @win.setLevel 0 > @bar = NSProgressIndicator.alloc.initWithFrame [10.0, 10.0, 80.0, > 80.0] > @win.contentView.addSubview(@bar) > @bar.setIndeterminate(false) > @win.display > @win.orderFrontRegardless > end > > def step > @bar.incrementBy(20) > end > end > > > app = NSApplication.sharedApplication > app.setDelegate(AppDelegate.alloc.init) > app.run > > > ------------------------------------------------------------------------------ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
From: Arcadio R. G. <arc...@gm...> - 2009-04-05 09:47:36
|
Hi all, I'm trying to build a very simple GUI for my Ruby application using Cocoa. I have no experience with Cocoa or ObjC, so that might be part of the problem. Anyway, I have a Ruby text application and I would like to add this GUI as an observer. So far I have other observers that for instance write a log to a file, but none of them are graphical. My problem is that I need to run the GUI in another thread since when I start it, the call to app.run (in the code below) never returns. As far as I know, I cannot use Ruby (green) threads. Note that due to the design my project, I cannot invert control and run my application within the thread created by Cocoa. Also, my code is not (yet) compatible with Ruby 1.9, so I have to stick to 1.8. Can anyone point how to execute app.run in another thread in the code shown below. I've tried using NSThread.detachNewThreadSelector_toTarget_withObject but haven't been successful. Thanks! require 'osx/cocoa' include OSX class AppDelegate < NSObject def init frame = [200.0, 300.0, 250.0, 100.0] @win = NSWindow.alloc.initWithContentRect_styleMask_backing_defer(frame, 15, 2, 0) @win.setTitle 'Test' @win.setLevel 0 @bar = NSProgressIndicator.alloc.initWithFrame [10.0, 10.0, 80.0, 80.0] @win.contentView.addSubview(@bar) @bar.setIndeterminate(false) @win.display @win.orderFrontRegardless end def step @bar.incrementBy(20) end end app = NSApplication.sharedApplication app.setDelegate(AppDelegate.alloc.init) app.run |
From: Duncan M. <du...@on...> - 2009-03-19 07:48:46
|
Thanks It turns out it is already loaded, I just needed to access it properly. Cheers Duncan On 18 Mar 2009, at 18:29, Eloy Duran wrote: > Hi Duncan, > > Take a look at the gen_bridge_metadata tool. ($ man > gen_bridge_metadata) > > If I recall it correctly it would be something like: > $ gen_bridge_metadata -f /System/Library/Frameworks/ > ApplicationServices.framework/Versions/Current/Frameworks/QD.framework >> QD.bridgesupport > > You can then load that file with OSX.load_bridge_support_file > > Cheers, > Eloy > > On 18 mrt 2009, at 19:14, Duncan McGregor wrote: > >> Hi >> >> First thanks for RubyCocoa. As the author of Rococoa, which does a >> similar job for Java, I really appreciate what you've done. >> >> I'm trying to access Apple Type Services for Unicode Imaging (ATSUI) >> through RubyCocoa - in order to measure text before I lay it out. >> >> I need to call, for example - ATSUCreateStyle >> >> This is defined in ATSUnicodeObjects.h, which seems to be found in >> >> /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ >> QD.framework >> >> I'm having trouble working out how to gain access to this API. >> >> When I wanted to use CoreIO I used >> >> require_framework '/System/Library/Frameworks/ >> ApplicationServices.framework/Versions/Current/Frameworks/ >> ImageIO.framework' >> >> So I expected that >> >> require_framework '/System/Library/Frameworks/ >> ApplicationServices.framework/Versions/Current/Frameworks/ >> QD.framework' >> >> would work, but I get NoMethodError: undefined method >> `ATSUCreateStyle' when I try to call the function. >> >> Can anyone please point out what I'm doing wrong? >> >> Thanks in anticipation >> >> Duncan McGregor >> >> ------------------------------------------------------------------------------ >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) >> are >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly >> and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based >> development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Rubycocoa-talk mailing list >> Rub...@li... >> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) > are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly > and > easily build your RIAs with Flex Builder, the Eclipse(TM)based > development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
From: Duncan M. <du...@on...> - 2009-03-18 18:31:59
|
Always the way, just as soon as you post - you find the solution. So for those who may follow require_framework '/System/Library/Frameworks/ ApplicationServices.framework/Versions/Current/Frameworks/QD.framework' is correct, but I then need to use QD::ATSUCreateStyle Keep up the good work :-) Duncan On 18 Mar 2009, at 09:40, Duncan McGregor wrote: > Hi > > First thanks for RubyCocoa. As the author of Rococoa, which does a > similar job for Java, I really appreciate what you've done. > > I'm trying to access Apple Type Services for Unicode Imaging (ATSUI) > through RubyCocoa - in order to measure text before I lay it out. > > I need to call, for example - ATSUCreateStyle > > This is defined in ATSUnicodeObjects.h, which seems to be found in > > /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ > QD.framework > > I'm having trouble working out how to gain access to this API. > > When I wanted to use CoreIO I used > > require_framework '/System/Library/Frameworks/ > ApplicationServices.framework/Versions/Current/Frameworks/ > ImageIO.framework' > > So I expected that > > require_framework '/System/Library/Frameworks/ > ApplicationServices.framework/Versions/Current/Frameworks/ > QD.framework' > > would work, but I get NoMethodError: undefined method > `ATSUCreateStyle' when I try to call the function. > > Can anyone please point out what I'm doing wrong? > > Thanks in anticipation > > Duncan McGregor |
From: Eloy D. <elo...@gm...> - 2009-03-18 18:29:25
|
Hi Duncan, Take a look at the gen_bridge_metadata tool. ($ man gen_bridge_metadata) If I recall it correctly it would be something like: $ gen_bridge_metadata -f /System/Library/Frameworks/ ApplicationServices.framework/Versions/Current/Frameworks/QD.framework > QD.bridgesupport You can then load that file with OSX.load_bridge_support_file Cheers, Eloy On 18 mrt 2009, at 19:14, Duncan McGregor wrote: > Hi > > First thanks for RubyCocoa. As the author of Rococoa, which does a > similar job for Java, I really appreciate what you've done. > > I'm trying to access Apple Type Services for Unicode Imaging (ATSUI) > through RubyCocoa - in order to measure text before I lay it out. > > I need to call, for example - ATSUCreateStyle > > This is defined in ATSUnicodeObjects.h, which seems to be found in > > /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ > QD.framework > > I'm having trouble working out how to gain access to this API. > > When I wanted to use CoreIO I used > > require_framework '/System/Library/Frameworks/ > ApplicationServices.framework/Versions/Current/Frameworks/ > ImageIO.framework' > > So I expected that > > require_framework '/System/Library/Frameworks/ > ApplicationServices.framework/Versions/Current/Frameworks/ > QD.framework' > > would work, but I get NoMethodError: undefined method > `ATSUCreateStyle' when I try to call the function. > > Can anyone please point out what I'm doing wrong? > > Thanks in anticipation > > Duncan McGregor > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) > are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly > and > easily build your RIAs with Flex Builder, the Eclipse(TM)based > development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
From: Duncan M. <du...@on...> - 2009-03-18 18:15:14
|
Hi First thanks for RubyCocoa. As the author of Rococoa, which does a similar job for Java, I really appreciate what you've done. I'm trying to access Apple Type Services for Unicode Imaging (ATSUI) through RubyCocoa - in order to measure text before I lay it out. I need to call, for example - ATSUCreateStyle This is defined in ATSUnicodeObjects.h, which seems to be found in /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ QD.framework I'm having trouble working out how to gain access to this API. When I wanted to use CoreIO I used require_framework '/System/Library/Frameworks/ ApplicationServices.framework/Versions/Current/Frameworks/ ImageIO.framework' So I expected that require_framework '/System/Library/Frameworks/ ApplicationServices.framework/Versions/Current/Frameworks/QD.framework' would work, but I get NoMethodError: undefined method `ATSUCreateStyle' when I try to call the function. Can anyone please point out what I'm doing wrong? Thanks in anticipation Duncan McGregor |
From: Scott T. <ea...@ma...> - 2009-03-14 03:14:26
|
> PS: Based on Apple's strategy elsewhere with application > development, id say > its *very* unlikely that the iPhone runs any kind of VM. Not to > mention > performance / resource issues on a device that size. Not a general VM, but WebKit on the iPhone runs JavaScript. Although, I guess, In the current implementation that is, more than likely, the old syntax tree driven JavaScript interpreter and not the bytecode based Nitro engine... yet. give it until Tuesday of next week. That doesn't mean, of course, that you would have any direct access to the bytecode VM, but still... the phone could be running a VM then. :-D Scott |
From: Timothy P. <ti...@ge...> - 2009-03-11 09:51:03
|
Whilst I don't want to discourage you (as you seem quite dead set on this), I would certainly question the ROI in time and potential financial implications of what your looking at doing... Lets review: 1. You want to create a bespoke ruby compiler for a closed platform which you have no internal knowledge of or access to the internal OS. 2. You'd have to rebuild an entire ruby language parser - you point to Jruby. Bear in mind that Jruby has scores of very talented programmers contributing and its taken a good few years to get to this point where its reasonably usable. 3. Your looking at doing this on your own. 4. Its highly possible that you will loose a lot of what makes ruby flexible by having a code -> compile -> deploy workflow. 5. Id imagine there would be several difficulties (just as there are with the ruby-cocoa bridge) of mapping duck typed ruby to statically typed obj-c So, IMO, for the time you would have to sink into this (were talking years, not months) would it not just be easier to bite the bullet and write obj-c. Its not that difficult after all... Just some thoughts. Tim PS: Based on Apple's strategy elsewhere with application development, id say its *very* unlikely that the iPhone runs any kind of VM. Not to mention performance / resource issues on a device that size. On 11/03/2009 08:44, "Steven D. Arnold" <st...@ar...> wrote: > Yeah. I agree without Apple's permission, loading the Ruby runtime > into the iPhone would violate the EULA. I do think there is a chance > they could be talked into allowing this, but short of that, any > solution would have to generate and link .o files in the same way > Objective-C does. It would be a Ruby compiler down to the bare metal, > not a VM as the environment in which Ruby currently runs. > > For all I know, Apple already has a bytecode-driven VM in the iPhone. > If that is true, then the compiler could just compile to that bytecode > and the problem is no different than the problems of, say, the Jruby > project. It's very similar with ARM, too, you just have to think of > ARM's commands as the bytecode to use. :-) > > On Mar 11, 2009, at 3:20 AM, Axel M. Roest wrote: > >> At 23:21 -0400 10-03-2009, Steven Arnold wrote: >>> Disclaimer: IANAL, and for that reason this will be my last post on >>> the legal side of this issue. My reading of the iPhone SDK agreement >>> below is my opinion only. >> >> I think it is more this part that's bothering us: >> 3.3.2 <stuff deleted>. No interpreted code may be downloaded and used >> in an Application except for code that is interpreted and run by >> Apple's Published APIs and built-in interpreter(s). >> >> As ruby is neither built-in, nor supported in the API, you're on >> your own. >> >> just my 0.02... >> >> Axel >> -- >> _________________________ >> Axel Roest >> axelloroestello@{AIM/MSN} - Skype:axellofono - XOIP: 084-8749988 >> >> ----------------------------------------------------------------------------->> - >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) >> are >> powering Web 2.0 with engaging, cross-platform capabilities. Quickly >> and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based >> development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Rubycocoa-talk mailing list >> Rub...@li... >> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > |