rubycocoa-talk — talking about RubyCocoa

[Rubycocoa-talk] Using the Identity Services frameworks

[Carl P. <c.p...@ac...>]

Dear all,
   I'm new to using the Objective-C frameworks and am having an issue  
with manipulating the Core Services Identity framework objects  
(specifically CSIdentity) with the RubyCocoa bridge.

   I'm able to use the Collaboration framework to generate  
authentication authorities and to locate users (ie. get CBIdentity  
instances).

   Now, from what I understand from the documentation, if I want to  
(for example) alter a users password then I need to create a  
CSIdentity instance. With that CSIdentity instance I should then be  
able to alter the password and then commit my changes (modulo some  
auth-related restrictions). I'm generating this instance by calling  
the Objective-C method CSIdentity on the CBIdentity instance I've  
created.
   Doing this gives me an ObjcPtr object that wraps up that instance.  
Whenever I now attempt to manipulate or query that instance (eg. by  
calling API related methods), I get errors messages indicating that  
the method doesn't exist - this is presumably due to the fact that  
RubyCocoa knows nothing about the methods in CSIdentity?

   Any help at pointing me in the correct direction is very much  
appreciated.

All the best,

   Carl.

[Rubycocoa-talk] ANNOUNCE: Rucola 0.5 released

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

Hi,

I've just released Rucola 0.5

Rucola is a light weight framework that helps you write RubyCocoa apps.
It allows you to build, test, and deploy applications using rake  
commands,
eliminating the need to use XCode for the most common tasks.

Rucola provides a set of generators to help you generate controllers,  
window controllers,
and document-based applications.  It also provides APIs for  
simplifying some of Objective-C's
ways of doing things.

New in this release:
Dependency resolver:
* You can now specify your dependencies in environment.rb and they  
will resolved and vendored in release mode.
   This applies to gems and any other ruby lib. Because of this  
agnostic system there might still be some edge cases, for this purpose
   there's the possibility to specify exceptions.
* In release mode RubyGems will NOT be loaded even if it's required at  
some point. This results in application startup time going from ~3  
bounces in the dock to ~1.

Deploying:
* Added rake task for packaging a release build in a dmg
* Added rake task for uploading via scp, adding others is easy.
* Added rake task for creating a Sparkle appcast file.
* Added rake task that looks for textile files in ReleaseNotes/ 
AppName_Version and creates HTML for Sparkle.

Others:
* Added Rucola::FSEvents which is a rubyesque wrapper around FSEvents.
* Added Rucola::Reloader, which uses Rucola::FSEvents to watch the app/ 
controllers path for modifications and reloads the class.
   In debug mode this will be enabled by default, you can override  
this setting on the `config` of Initializer.
* Added the Rucola::Log class and an extension to Kernel to access it  
easily. (Manfred Stienstra)
* Added Rucola::TestCase which is a test case mixin, like the one in  
Rails, which sets up a test case for a controller, defines helper  
methods and creates stubs for all ib_outlets that are defined in the  
controller.
* Added support for ruby-debug. If a call is made to Kernel.debugger  
and the RUBYCOCOA_ENV is 'debug', then the ruby-debug library will be  
required and ran.
* NSImage.imageNamed will also look in app/assets for a given image  
name.
* Added a script/console script which will run a irb console with the  
application loaded. (Jelle Helsen)
* Added a simple model generator, which is simply a subclass of  
NSObject.

http://rucola.rubyforge.org/

Cheers,
Eloy

Re: [Rubycocoa-talk] Subdirectories in app/Contents/Resources

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

Rucola does use xcode, just not Xcode.app.
It uses the xcodebuild command line tool.

On 10 jul 2008, at 04:35, Brian Marick wrote:

> I'm writing a RubyCocoa book, and I want to support both people using
> Xcode and people using their own editor + rake. So I needed a single
> setup that would work well in both cases. (I myself use Aquamacs to
> edit, but oddly use Xcode to run the app - which is an F4-F4 keystroke
> for me.)
>
> <http://www.pragprog.com/titles/bmrc/rubycocoa>
>
>
> On Jul 9, 2008, at 5:36 PM, Tim Perrett wrote:
>
>> There's your problem - dont use XCode. Those of us using Rucola are
>> usually using the following:
>>
>> 1x Textmate
>> 1x Terminal window
>>
>> Cheers, Tim
>>
>> On 9 Jul 2008, at 21:43, Brian Marick wrote:
>>
>>> The Rucola approach doesn't work if Xcode doesn't save the file when
>>> you do a Build-n-Run. The code to run isn't on disk yet. (Do others
>>> not have this problem?)
>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic  
>> lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> Rubycocoa-talk mailing list
>> Rub...@li...
>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>
>
>
> -----
> Brian Marick, independent consultant
> Mostly on agile methods with a testing slant
> www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

Re: [Rubycocoa-talk] Subdirectories in app/Contents/Resources

[Brian M. <ma...@ex...>]

I'm writing a RubyCocoa book, and I want to support both people using  
Xcode and people using their own editor + rake. So I needed a single  
setup that would work well in both cases. (I myself use Aquamacs to  
edit, but oddly use Xcode to run the app - which is an F4-F4 keystroke  
for me.)

<http://www.pragprog.com/titles/bmrc/rubycocoa>


On Jul 9, 2008, at 5:36 PM, Tim Perrett wrote:

> There's your problem - dont use XCode. Those of us using Rucola are
> usually using the following:
>
> 1x Textmate
> 1x Terminal window
>
> Cheers, Tim
>
> On 9 Jul 2008, at 21:43, Brian Marick wrote:
>
>> The Rucola approach doesn't work if Xcode doesn't save the file when
>> you do a Build-n-Run. The code to run isn't on disk yet. (Do others
>> not have this problem?)
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk



-----
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.exampler.com/blog, www.twitter.com/marick

Re: [Rubycocoa-talk] Subdirectories in app/Contents/Resources

[Tim P. <he...@ti...>]

There's your problem - dont use XCode. Those of us using Rucola are  
usually using the following:

1x Textmate
1x Terminal window

Cheers, Tim

On 9 Jul 2008, at 21:43, Brian Marick wrote:

> The Rucola approach doesn't work if Xcode doesn't save the file when
> you do a Build-n-Run. The code to run isn't on disk yet. (Do others
> not have this problem?)

Re: [Rubycocoa-talk] Subdirectories in app/Contents/Resources

[Brian M. <ma...@ex...>]

The Rucola approach doesn't work if Xcode doesn't save the file when  
you do a Build-n-Run. The code to run isn't on disk yet. (Do others  
not have this problem?)

On Jul 9, 2008, at 1:39 PM, Eloy Duran wrote:

> The Rucola approach works, because we run all the files from the
> source root in debug environment rather than from inside the bundle.
> before a release you always first do a clean.... right?! ;)
>
> Eloy
>
> On 9 jul 2008, at 19:30, Brian Marick wrote:
>
>> The Rucola approach doesn't quite work with Xcode, I think. Xcode has
>> a bug where "Save changed files on build" doesn't consistently save
>> changed files that live in folders (rather than Xcode groups). It's
>> annoying when you make a change, have it not work, then discover it's
>> because Xcode didn't save the changed file. I finally wrote an
>> Applescript to really, really save before building. With that, I have
>> a structure that works for both Xcode and your favorite editor, using
>> Xcode's clever "don't use the Ruby files in the built directory when
>> making a Debug build" trick.
>>
>> On Jul 3, 2008, at 12:38 PM, Tim Perrett wrote:
>>
>>> Have you tried Rucola?
>>>
>>> http://rucola.rubyforge.org/
>>>
>>> On 3 Jul 2008, at 18:25, Brian Marick wrote:
>>>
>>>> Summary: Xcode seems to strongly prefer that all your Ruby files be
>>>> at
>>>> the top level of the resources directory. Can my preference for a
>>>> source directory structure override its?
>>>
>>>
>>> -------------------------------------------------------------------------
>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>> Studies have shown that voting for your favorite open source  
>>> project,
>>> along with a healthy diet, reduces your potential for chronic
>>> lameness
>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>> _______________________________________________
>>> Rubycocoa-talk mailing list
>>> Rub...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>>
>> -----
>> Brian Marick, independent consultant
>> Mostly on agile methods with a testing slant
>> www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic  
>> lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> Rubycocoa-talk mailing list
>> Rub...@li...
>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

-----
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.exampler.com/blog, www.twitter.com/marick

Re: [Rubycocoa-talk] Subdirectories in app/Contents/Resources

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

The Rucola approach works, because we run all the files from the
source root in debug environment rather than from inside the bundle.
before a release you always first do a clean.... right?! ;)

Eloy

On 9 jul 2008, at 19:30, Brian Marick wrote:

> The Rucola approach doesn't quite work with Xcode, I think. Xcode has
> a bug where "Save changed files on build" doesn't consistently save
> changed files that live in folders (rather than Xcode groups). It's
> annoying when you make a change, have it not work, then discover it's
> because Xcode didn't save the changed file. I finally wrote an
> Applescript to really, really save before building. With that, I have
> a structure that works for both Xcode and your favorite editor, using
> Xcode's clever "don't use the Ruby files in the built directory when
> making a Debug build" trick.
>
> On Jul 3, 2008, at 12:38 PM, Tim Perrett wrote:
>
>> Have you tried Rucola?
>>
>> http://rucola.rubyforge.org/
>>
>> On 3 Jul 2008, at 18:25, Brian Marick wrote:
>>
>>> Summary: Xcode seems to strongly prefer that all your Ruby files be
>>> at
>>> the top level of the resources directory. Can my preference for a
>>> source directory structure override its?
>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic  
>> lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> Rubycocoa-talk mailing list
>> Rub...@li...
>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>
> -----
> Brian Marick, independent consultant
> Mostly on agile methods with a testing slant
> www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

Re: [Rubycocoa-talk] Subdirectories in app/Contents/Resources

[Brian M. <ma...@ex...>]

The Rucola approach doesn't quite work with Xcode, I think. Xcode has  
a bug where "Save changed files on build" doesn't consistently save  
changed files that live in folders (rather than Xcode groups). It's  
annoying when you make a change, have it not work, then discover it's  
because Xcode didn't save the changed file. I finally wrote an  
Applescript to really, really save before building. With that, I have  
a structure that works for both Xcode and your favorite editor, using  
Xcode's clever "don't use the Ruby files in the built directory when  
making a Debug build" trick.

On Jul 3, 2008, at 12:38 PM, Tim Perrett wrote:

> Have you tried Rucola?
>
> http://rucola.rubyforge.org/
>
> On 3 Jul 2008, at 18:25, Brian Marick wrote:
>
>> Summary: Xcode seems to strongly prefer that all your Ruby files be  
>> at
>> the top level of the resources directory. Can my preference for a
>> source directory structure override its?
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

-----
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.exampler.com/blog, www.twitter.com/marick

Re: [Rubycocoa-talk] Subdirectories in app/Contents/Resources

[Dave B. <dav...@3d...>]

On 3 Jul 2008, at 18:25, Brian Marick wrote:

> Summary: Xcode seems to strongly prefer that all your Ruby files be at
> the top level of the resources directory. Can my preference for a
> source directory structure override its?
>
> Suppose I think of my app in this structure:
> root/
>     TranslatorEnlister.rb
>     translators/
>         ToString.rb
>     controllers/
>     util/
>
> I can mimic that structure in Xcode groups, but as far as I can tell,
> the structure is always flattened to look like this:
>
> Contents/Resources/
>     TranslatorEnlister.rb
>     ToString.rb
>
> This is a problem if I'm doing unit testing outside the build
> directory, in which case (say) TranslatorEnlister.rb would have a
> "require 'translators/ToString'".

You can always add to the search path used to find files to require:

$:.unshift '../translators'

would do it.

Doesn't answer your main problem with xcode, though.

Dave.

>
>
> I can create the directories on disk, add them, and tell Xcode to
> create folder references instead of groups. However, Xcode's
> dependency checking seems to stop at the top-level folder. So if I
> change a file within .../translators/, Xcode doesn't copy it into the
> build unless I touch .../translators/ or something.
>
> Am I confused?
>
> I remember the thrill, back around 1980, of first working on an
> operating system that allowed a directory hierarchy. I could have two
> files with *the same name*. I would like to recapture that thrill with
> Xcode.
>
> -----
> Brian Marick, independent consultant
> Mostly on agile methods with a testing slant
> www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

Re: [Rubycocoa-talk] Subdirectories in app/Contents/Resources

[Tim P. <he...@ti...>]

Have you tried Rucola?

http://rucola.rubyforge.org/

On 3 Jul 2008, at 18:25, Brian Marick wrote:

> Summary: Xcode seems to strongly prefer that all your Ruby files be at
> the top level of the resources directory. Can my preference for a
> source directory structure override its?

[Rubycocoa-talk] Subdirectories in app/Contents/Resources

[Brian M. <ma...@ex...>]

Summary: Xcode seems to strongly prefer that all your Ruby files be at  
the top level of the resources directory. Can my preference for a  
source directory structure override its?

Suppose I think of my app in this structure:
root/
     TranslatorEnlister.rb
     translators/
         ToString.rb
     controllers/
     util/

I can mimic that structure in Xcode groups, but as far as I can tell,  
the structure is always flattened to look like this:

Contents/Resources/
     TranslatorEnlister.rb
     ToString.rb

This is a problem if I'm doing unit testing outside the build  
directory, in which case (say) TranslatorEnlister.rb would have a  
"require 'translators/ToString'".

I can create the directories on disk, add them, and tell Xcode to  
create folder references instead of groups. However, Xcode's  
dependency checking seems to stop at the top-level folder. So if I  
change a file within .../translators/, Xcode doesn't copy it into the  
build unless I touch .../translators/ or something.

Am I confused?

I remember the thrill, back around 1980, of first working on an  
operating system that allowed a directory hierarchy. I could have two  
files with *the same name*. I would like to recapture that thrill with  
Xcode.

-----
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.exampler.com/blog, www.twitter.com/marick

Re: [Rubycocoa-talk] RubyCocoa Garbage Collection: lambdas versus Procs

[Benjamin J. <bhj...@gm...>]

An update for anyone following along:

The dropped notifications have re-appeared, though with less
frequency. I'm not sure if this lambda thing was a real or imagined
problem. Perhaps something else is causing it independently.

On Wed, Jul 2, 2008 at 8:35 PM, Benjamin Jackson <bhj...@gm...> wrote:
> Hi all,
>
> I wanted to share my experience and see if anyone else has had the
> same issues as we have had with Blogo and memory management.
>
> In short: we make liberal use of Cocoa's asynchronous classes for IO,
> almost all of it using NSURLConnection. In all cases we hook our
> controllers into methods which accept a proc as a callback and call it
> when their delegate methods or notification listeners get called.
>
> Anyone who has followed Blogo's launch knows we've had more than our
> share of crashing bugs. Most of these incidents amounted to us
> receiving crash reports with segfaults and cryptic libruby- and
> AppKit-related stack traces. Some of them pointed us in the direction
> of the asynchronous callbacks, which led us to examine why GC was
> ripping up our objects before they were called.
>
> This in turn led us to the realization that Ruby GC really doesn't
> give a damn about Objective C's reference counter, which led to the
> realization that we couldn't just throw an object into a local
> variable and expect it to hang around waiting for the delegate methods
> to fire. Changing to use NSNotifications solved the crashes but was
> the equivalent of putting a band-aid on a broken leg: now we had to
> run timers to check for dropped notifications when GC acts up. Clearly
> not ideal.
>
> So there we thought we had it worked out. Until the crashes started
> reappearing in other areas of the app which used no local variables.
>
> While researching ruby GC today I had an idea. What if the objects are
> still there, but the procs being used for callbacks were getting
> swallowed by GC?
>
> Normally we call our helper classes as such:
>
> @helper = MyAwesomeAsyncHelper.alloc.init
> @helper.getSomething do |result|
>  # do something interesting with the result...
> end
>
> MyAwesomeAsyncHelper then stores the lambda in an instance var to be
> called later:
>
> class MyAwesomeAsyncHelper < OSX::NSObject
>  def getSomething &callback
>    @myCallback = callback
>    # do something asynchronous...
>  end
>
>  def connectionDidFinishLoading
>    @myCallback.call(@resultData)
>  end
> end
>
> By our logic, this should be sound. The reference is there. It's
> assigned to an instance var.
>
> For kicks I tried changing the helper classes to use Procs instead of lambdas:
>
> @helper = MyAwesomeAsyncHelper.alloc.init
> @helperCallback = Proc.new { |result| # do something interesting with
> the result... }
> @helper.getSomething(@helperCallback)
>
> And the helper (removed the & from the args list):
>
> class MyAwesomeAsyncHelper < OSX::NSObject
>  def getSomething callback
>    @myCallback = callback
>    # do something asynchronous...
>  end
>
>  def connectionDidFinishLoading
>    @myCallback.call(@resultData)
>  end
> end
>
> Voila. No more dropped notifications.
>
> So here's what I think is happening:
>
> 1. Client sends lambda to helper.
> 2. Helper calls to_proc on lambda
> 3. Helper stores reference to the new Proc
> 4. Lambda has no references to it and is swept at the first opportunity
>
> Can anyone confirm or deny that this is the case?
>

[Rubycocoa-talk] RubyCocoa Garbage Collection: lambdas versus Procs

[Benjamin J. <bhj...@gm...>]

Hi all,

I wanted to share my experience and see if anyone else has had the
same issues as we have had with Blogo and memory management.

In short: we make liberal use of Cocoa's asynchronous classes for IO,
almost all of it using NSURLConnection. In all cases we hook our
controllers into methods which accept a proc as a callback and call it
when their delegate methods or notification listeners get called.

Anyone who has followed Blogo's launch knows we've had more than our
share of crashing bugs. Most of these incidents amounted to us
receiving crash reports with segfaults and cryptic libruby- and
AppKit-related stack traces. Some of them pointed us in the direction
of the asynchronous callbacks, which led us to examine why GC was
ripping up our objects before they were called.

This in turn led us to the realization that Ruby GC really doesn't
give a damn about Objective C's reference counter, which led to the
realization that we couldn't just throw an object into a local
variable and expect it to hang around waiting for the delegate methods
to fire. Changing to use NSNotifications solved the crashes but was
the equivalent of putting a band-aid on a broken leg: now we had to
run timers to check for dropped notifications when GC acts up. Clearly
not ideal.

So there we thought we had it worked out. Until the crashes started
reappearing in other areas of the app which used no local variables.

While researching ruby GC today I had an idea. What if the objects are
still there, but the procs being used for callbacks were getting
swallowed by GC?

Normally we call our helper classes as such:

@helper = MyAwesomeAsyncHelper.alloc.init
@helper.getSomething do |result|
  # do something interesting with the result...
end

MyAwesomeAsyncHelper then stores the lambda in an instance var to be
called later:

class MyAwesomeAsyncHelper < OSX::NSObject
  def getSomething &callback
    @myCallback = callback
    # do something asynchronous...
  end

  def connectionDidFinishLoading
    @myCallback.call(@resultData)
  end
end

By our logic, this should be sound. The reference is there. It's
assigned to an instance var.

For kicks I tried changing the helper classes to use Procs instead of lambdas:

@helper = MyAwesomeAsyncHelper.alloc.init
@helperCallback = Proc.new { |result| # do something interesting with
the result... }
@helper.getSomething(@helperCallback)

And the helper (removed the & from the args list):

class MyAwesomeAsyncHelper < OSX::NSObject
  def getSomething callback
    @myCallback = callback
    # do something asynchronous...
  end

  def connectionDidFinishLoading
    @myCallback.call(@resultData)
  end
end

Voila. No more dropped notifications.

So here's what I think is happening:

1. Client sends lambda to helper.
2. Helper calls to_proc on lambda
3. Helper stores reference to the new Proc
4. Lambda has no references to it and is swept at the first opportunity

Can anyone confirm or deny that this is the case?

Re: [Rubycocoa-talk] RC for iPhone Dev

[Dave B. <dav...@3d...>]

I am hoping the MacRuby effort makes it to the iPhone as I think this  
could be a much better fit.

Dave.

On 26 Jun 2008, at 15:04, Tim Perrett wrote:

> I have no intention of building an RC app for iPhone right now, I was
> just looking at the SDK online and had a thought about it thats  
> all :-)
>
> For now i'll sit back and see what evolves...
>
> On 26 Jun 2008, at 14:57, Marcelo Alves wrote:
>
>> Yep, it is interpreted, but if you bundle it with your app, there's  
>> no
>> download and the "no interpreted code may be downloaded AND used"
>> doesn't apply. =)
>>
>> And I agree, it is a grey area and Apple can reject your app.
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk

Re: [Rubycocoa-talk] RC for iPhone Dev

[Tim P. <he...@ti...>]

I have no intention of building an RC app for iPhone right now, I was  
just looking at the SDK online and had a thought about it thats all :-)

For now i'll sit back and see what evolves...

On 26 Jun 2008, at 14:57, Marcelo Alves wrote:

> Yep, it is interpreted, but if you bundle it with your app, there's no
> download and the "no interpreted code may be downloaded AND used"
> doesn't apply. =)
>
> And I agree, it is a grey area and Apple can reject your app.

Re: [Rubycocoa-talk] RC for iPhone Dev

[Marcelo A. <mar...@xf...>]

2008/6/26 Tim Perrett <he...@ti...>:
> Im no lawyer, but this line:
>
> "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)"
>
> Ruby is an interpreted language, so one would imagine that puts pay to
> the idea of RC for iPhone... Although having said that its a bridge to
> Apples interpreter, so, perhaps its a grey area ;-)

Yep, it is interpreted, but if you bundle it with your app, there's no
download and the "no interpreted code may be downloaded AND used"
doesn't apply. =)

And I agree, it is a grey area and Apple can reject your app.

>
> On 26 Jun 2008, at 14:41, Marcelo Alves wrote:
>
>> I don't think the statement #3.3.2 forbids the use of another
>> languages. If your app bundles the ruby interpreter inside, there's no
>> download, and you're not launching another executable.
>>
>> Problems: your apps will be HUGE (>10Mb each, no download over 3G),
>> because you can't share the interpreter with another apps.
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>

Re: [Rubycocoa-talk] RC for iPhone Dev

[Tim P. <he...@ti...>]

Im no lawyer, but this line:

"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)"

Ruby is an interpreted language, so one would imagine that puts pay to  
the idea of RC for iPhone... Although having said that its a bridge to  
Apples interpreter, so, perhaps its a grey area ;-)

On 26 Jun 2008, at 14:41, Marcelo Alves wrote:

> I don't think the statement #3.3.2 forbids the use of another
> languages. If your app bundles the ruby interpreter inside, there's no
> download, and you're not launching another executable.
>
> Problems: your apps will be HUGE (>10Mb each, no download over 3G),
> because you can't share the interpreter with another apps.

Re: [Rubycocoa-talk] RC for iPhone Dev

[Jason F. <ja...@th...>]

On Jun 26, 2008, at 8:41 AM, Marcelo Alves wrote:

> I don't think the statement #3.3.2 forbids the use of another
> languages. If your app bundles the ruby interpreter inside, there's no
> download, and you're not launching another executable.

Not sure I agree with you; I think it does prohibit it, albeit in some  
very vague and possibly ambiguous language.  But IANAL, so who knows.   
Also keep in mind that they have the power to just reject your app for  
inclusion in the App Store anyway, so I'm not sure it is worth the  
effort to build an iPhone app using RubyCocoa at this time.

I spoke to some Apple engineers at WWDC, and none of them seemed  
opposed to having RubyCocoa (or PyObjC) on the iPhone.  Best way to  
make it happen is to file bugs.  They'll probably be closed as dupes,  
but the more they get, the higher chance there is of it happening.


Jason

Re: [Rubycocoa-talk] RC for iPhone Dev

[Marcelo A. <mar...@xf...>]

I don't think the statement #3.3.2 forbids the use of another
languages. If your app bundles the ruby interpreter inside, there's no
download, and you're not launching another executable.

Problems: your apps will be HUGE (>10Mb each, no download over 3G),
because you can't share the interpreter with another apps.


2008/6/26 Tim Perrett <he...@ti...>:
> oooo interesting - thats a real shame. Anyone know if there are plans
> afoot for that to change?
>
> Tim
>
> On 26 Jun 2008, at 14:28, victor jalencas wrote:
>
>> Actually, the SDK EULA forbids that:
>>
>> 3.3.2 An Application may not itself install or launch other
>> executable code by any means, including without limitation through
>> the use of a plug-in architecture, calling other frameworks, other
>> APIs or otherwise. 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).
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>

Re: [Rubycocoa-talk] RC for iPhone Dev

[Tim P. <he...@ti...>]

oooo interesting - thats a real shame. Anyone know if there are plans  
afoot for that to change?

Tim

On 26 Jun 2008, at 14:28, victor jalencas wrote:

> Actually, the SDK EULA forbids that:
>
> 3.3.2 An Application may not itself install or launch other  
> executable code by any means, including without limitation through  
> the use of a plug-in architecture, calling other frameworks, other  
> APIs or otherwise. 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).

Re: [Rubycocoa-talk] RC for iPhone Dev

[victor j. <vic...@ca...>]

Actually, the SDK EULA forbids that:

3.3.2 An Application may not itself install or launch other executable code
by any means, including without limitation through the use of a plug-in
architecture, calling other frameworks, other APIs or otherwise. 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).

On Thu, Jun 26, 2008 at 3:19 PM, Brian Ketelsen <bke...@gm...> wrote:

> No RubyCocoa for iPhone yet.  I wish.
>
> On Thu, Jun 26, 2008 at 9:18 AM, Tim Perrett <he...@ti...> wrote:
> > Chaps,
> >
> > Has anyone tried RC with the iPhone SDK? That would be so awesome if
> > you could use RC on the iPhone... although im not sure that iPhone
> > would have the the MRI installed - if not, perhaps packaging it would
> > work...?
> >
> > Cheers
> >
> > Tim
> >
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > _______________________________________________
> > Rubycocoa-talk mailing list
> > Rub...@li...
> > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
> >
>
>
>
> --
>
> ----
> Brian Ketelsen
> bketelsen <at> gmail <dot> com
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>



-- 
--
Victor Jalencas <vi...@ca...>

Re: [Rubycocoa-talk] RC for iPhone Dev

[Brian K. <bke...@gm...>]

No RubyCocoa for iPhone yet.  I wish.

On Thu, Jun 26, 2008 at 9:18 AM, Tim Perrett <he...@ti...> wrote:
> Chaps,
>
> Has anyone tried RC with the iPhone SDK? That would be so awesome if
> you could use RC on the iPhone... although im not sure that iPhone
> would have the the MRI installed - if not, perhaps packaging it would
> work...?
>
> Cheers
>
> Tim
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>



-- 

----
Brian Ketelsen
bketelsen <at> gmail <dot> com

[Rubycocoa-talk] RC for iPhone Dev

[Tim P. <he...@ti...>]

Chaps,

Has anyone tried RC with the iPhone SDK? That would be so awesome if  
you could use RC on the iPhone... although im not sure that iPhone  
would have the the MRI installed - if not, perhaps packaging it would  
work...?

Cheers

Tim

[Rubycocoa-talk] standalonification and AddressBook framework

[Yvon T. <yvo...@gm...>]

i've added manually the AddressBook framework in
/path/to/My.app/Contents/Frameworks AFTER standalonification giving this
rb_main.rb :
################################################################################
# standaloneify.rb patch
################################################################################
# Remove all entries that aren't in the application bundle

COCOA_APP_RESOURCES_DIR = File.dirname(__FILE__)

$LOAD_PATH.reject! { |d| d.index(File.dirname(COCOA_APP_RESOURCES_DIR))!=0 }
$LOAD_PATH << File.join(COCOA_APP_RESOURCES_DIR,"ThirdParty")
$LOAD_PATH << File.join(File.dirname(COCOA_APP_RESOURCES_DIR),"lib")

$LOADED_FEATURES << "rubycocoa.bundle"

ENV['GEM_HOME'] = ENV['GEM_PATH'] =
File.join(COCOA_APP_RESOURCES_DIR,"RubyGems")

################################################################################
#
#  rb_main.rb
#  AB2Html
#
#  Created by Yvon Thoraval on 29/01/08.
#  Copyright (c) 2008 yTho. All rights reserved.
#

require 'osx/cocoa'

OSX.require_framework 'AddressBook'

def rb_main_init
  path = OSX::NSBundle.mainBundle.resourcePath.fileSystemRepresentation
  rbfiles = Dir.entries(path).select {|x| /\.rb\z/ =~ x}
  rbfiles -= [ File.basename(__FILE__) ]
  rbfiles.each do |path|
    require( File.basename(path) )
  end
end

if $0 == __FILE__ then
  rb_main_init
  OSX.NSApplicationMain(0, nil)
end


and i've an error reported by a user showing the AB framework isn't loaded.

(he is running MacOS X 10.4.11 as me)

the standalonify.rb version i have is :
# $Id: /local/dcs/trunk/prog/gps/gpsrb/standaloneify.rb 1759
2006-03-03T12:37:58.626843Z jon  $


is it outdated ?
-- 
yvon

Re: [Rubycocoa-talk] objc_method documentation?

[Patrick G. <pge...@wa...>]

> Correct.  I haven't looked at the source, but assume that objc_method
> is just calling through to the objc runtime methods; see here in
> particular - http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html#/ 
> /apple_ref/c/func/class_addMethod

That's right. Ruby is calling it in imp_c_addRubyMethod_withType ( http://www.opensource.apple.com/darwinsource/10.5/RubyCocoa-57/RubyCocoa/framework/src/objc/OverrideMixin.m 
  )

 From the source of objc_method, you should be able to call it with  
more readable arguments :
objc_method [:BOOL, :id]
meaning returning BOOL and taking one NSObject. I didn't test it,  
though.

-Patrick