rubycocoa-talk — talking about RubyCocoa

Re: [Rubycocoa-talk] Alternative to NSGraphicsContext graphicsContextWithGraphicsPort:flipped:

[Duncan M. <du...@on...>]

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

Re: [Rubycocoa-talk] Alternative to NSGraphicsContext graphicsContextWithGraphicsPort:flipped:

[Scott T. <ea...@ma...>]

 
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

[Rubycocoa-talk] Bus error CFRelease on CGImageSourceRef

[Duncan M. <du...@on...>]

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

[Rubycocoa-talk] Alternative to NSGraphicsContext graphicsContextWithGraphicsPort:flipped:

[Duncan M. <du...@on...>]

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

Re: [Rubycocoa-talk] actionForLayer:forKey not found

[Allison N. <dem...@ma...>]

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

[Rubycocoa-talk] actionForLayer:forKey not found

[Kei T. <ke...@pa...>]

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

Re: [Rubycocoa-talk] A potential bug to watch out for...

[Gregory C. <gr...@in...>]

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

Re: [Rubycocoa-talk] A potential bug to watch out for...

[Allison N. <dem...@ma...>]

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

Re: [Rubycocoa-talk] A potential bug to watch out for...

[Duncan M. <du...@on...>]

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
>

[Rubycocoa-talk] A potential bug to watch out for...

[Allison N. <dem...@me...>]

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

[Rubycocoa-talk] Odd NSArray behaviour

[Allison N. <dem...@ma...>]

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

Re: [Rubycocoa-talk] Address of structure

[Duncan M. <du...@on...>]

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?

Re: [Rubycocoa-talk] Address of structure

[Allison N. <dem...@ma...>]

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 &#45; New Free Runtime and 30 Day Trial
>Check out the new simplified licensign option that enables unlimited
>royalty&#45;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
>
>

[Rubycocoa-talk] Address of structure

[Duncan M. <du...@on...>]

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?

Re: [Rubycocoa-talk] Newbie Question: Threads

[Arcadio R. G. <arc...@gm...>]

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

Re: [Rubycocoa-talk] Newbie Question: Threads

[Gregory C. <gr...@in...>]

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

Re: [Rubycocoa-talk] Newbie Question: Threads

[Arcadio R. G. <arc...@gm...>]

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

Re: [Rubycocoa-talk] Newbie Question: Threads

[Allison N. <dem...@ma...>]

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] Newbie Question: Threads

[Arcadio R. G. <arc...@gm...>]

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

Re: [Rubycocoa-talk] ATSUI API

[Duncan M. <du...@on...>]

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

Re: [Rubycocoa-talk] ATSUI API

[Duncan M. <du...@on...>]

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

Re: [Rubycocoa-talk] ATSUI API

[Eloy D. <elo...@gm...>]

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

[Rubycocoa-talk] ATSUI API

[Duncan M. <du...@on...>]

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

Re: [Rubycocoa-talk] Ruby on the iPhone?

[Scott T. <ea...@ma...>]

> 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

Re: [Rubycocoa-talk] Ruby on the iPhone?

[Timothy P. <ti...@ge...>]

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
>