Hey All, I just spent a few hours banging my head against a gotcha with the `framework` method -- if there happens to be a file or directory in the current directory with the name of the framework, the method fails: $ touch Cocoa $ macruby -e 'framework "Cocoa"' -e:1:in `<main>': framework at path `Cocoa' cannot be located (RuntimeError) $ rm Cocoa; mkdir Cocoa $ macruby -e 'framework "Cocoa"' -e:1:in `<main>': framework at path `Cocoa' cannot be loaded: Error Domain=NSCocoaErrorDomain Code=4 UserInfo=0x200241e20 "The bundle “Cocoa” couldn’t be loaded because its executable couldn’t be located." I ran into this while trying to setup unit testing for a Cocoa framework I'm writing. XCode 4 automatically creates a directory for each target you create. Thus, when I tried to load my framework, it saw my project target directory and thought it had found the framework. I think the `framework` method should be updated to avoid this gotcha. Currently, it just tests for existence of a file or directory. I'm happy to start working on a patch, but wanted to ask if there's any possible reason the `framework` method is this naïve? christian.
Hi Christian, As long as performance isn't affected, I think that making #framework smarter shouldn't be a problem. - Matt Sent from my iPhone On Mar 12, 2011, at 17:19, Christian Niles <christian@nerdyc.com> wrote:
Hey All,
I just spent a few hours banging my head against a gotcha with the `framework` method -- if there happens to be a file or directory in the current directory with the name of the framework, the method fails:
$ touch Cocoa $ macruby -e 'framework "Cocoa"' -e:1:in `<main>': framework at path `Cocoa' cannot be located (RuntimeError)
$ rm Cocoa; mkdir Cocoa $ macruby -e 'framework "Cocoa"' -e:1:in `<main>': framework at path `Cocoa' cannot be loaded: Error Domain=NSCocoaErrorDomain Code=4 UserInfo=0x200241e20 "The bundle “Cocoa” couldn’t be loaded because its executable couldn’t be located."
I ran into this while trying to setup unit testing for a Cocoa framework I'm writing. XCode 4 automatically creates a directory for each target you create. Thus, when I tried to load my framework, it saw my project target directory and thought it had found the framework.
I think the `framework` method should be updated to avoid this gotcha. Currently, it just tests for existence of a file or directory. I'm happy to start working on a patch, but wanted to ask if there's any possible reason the `framework` method is this naïve?
christian. _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Cool. I've compiled MacRuby from source and discovered a test for the 'framework' method in test-macruby/cases/framework_test.rb. What's the best way to run the tests in this directory? It doesn't seem to be run by `rake spec` and I couldn't find another task that seemed to run these. On Mar 12, 2011, at 8:35 PM, Matt Aimonetti wrote:
Hi Christian,
As long as performance isn't affected, I think that making #framework smarter shouldn't be a problem.
- Matt
Sent from my iPhone
On Mar 12, 2011, at 17:19, Christian Niles <christian@nerdyc.com> wrote:
Hey All,
I just spent a few hours banging my head against a gotcha with the `framework` method -- if there happens to be a file or directory in the current directory with the name of the framework, the method fails:
$ touch Cocoa $ macruby -e 'framework "Cocoa"' -e:1:in `<main>': framework at path `Cocoa' cannot be located (RuntimeError)
$ rm Cocoa; mkdir Cocoa $ macruby -e 'framework "Cocoa"' -e:1:in `<main>': framework at path `Cocoa' cannot be loaded: Error Domain=NSCocoaErrorDomain Code=4 UserInfo=0x200241e20 "The bundle “Cocoa” couldn’t be loaded because its executable couldn’t be located."
I ran into this while trying to setup unit testing for a Cocoa framework I'm writing. XCode 4 automatically creates a directory for each target you create. Thus, when I tried to load my framework, it saw my project target directory and thought it had found the framework.
I think the `framework` method should be updated to avoid this gotcha. Currently, it just tests for existence of a file or directory. I'm happy to start working on a patch, but wanted to ask if there's any possible reason the `framework` method is this naïve?
christian. _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi Christian, These tests should probably be removed, they are not used anymore (these were used before we switched to RubySpec). The correct thing to do is probably make a macruby spec (under the spec/macruby directory). How do you intend to change #framework exactly? Maybe you should work on a patch first, and we can iterate on it, then write the spec/test later. Thanks for helping :) Laurent On Mar 12, 2011, at 10:54 PM, Christian Niles wrote:
Cool. I've compiled MacRuby from source and discovered a test for the 'framework' method in test-macruby/cases/framework_test.rb.
What's the best way to run the tests in this directory? It doesn't seem to be run by `rake spec` and I couldn't find another task that seemed to run these.
On Mar 12, 2011, at 8:35 PM, Matt Aimonetti wrote:
Hi Christian,
As long as performance isn't affected, I think that making #framework smarter shouldn't be a problem.
- Matt
Sent from my iPhone
On Mar 12, 2011, at 17:19, Christian Niles <christian@nerdyc.com> wrote:
Hey All,
I just spent a few hours banging my head against a gotcha with the `framework` method -- if there happens to be a file or directory in the current directory with the name of the framework, the method fails:
$ touch Cocoa $ macruby -e 'framework "Cocoa"' -e:1:in `<main>': framework at path `Cocoa' cannot be located (RuntimeError)
$ rm Cocoa; mkdir Cocoa $ macruby -e 'framework "Cocoa"' -e:1:in `<main>': framework at path `Cocoa' cannot be loaded: Error Domain=NSCocoaErrorDomain Code=4 UserInfo=0x200241e20 "The bundle “Cocoa” couldn’t be loaded because its executable couldn’t be located."
I ran into this while trying to setup unit testing for a Cocoa framework I'm writing. XCode 4 automatically creates a directory for each target you create. Thus, when I tried to load my framework, it saw my project target directory and thought it had found the framework.
I think the `framework` method should be updated to avoid this gotcha. Currently, it just tests for existence of a file or directory. I'm happy to start working on a patch, but wanted to ask if there's any possible reason the `framework` method is this naïve?
christian. _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On Mar 14, 2011, at 1:11 PM, Laurent Sansonetti wrote:
Hi Christian,
These tests should probably be removed, they are not used anymore (these were used before we switched to RubySpec).
The correct thing to do is probably make a macruby spec (under the spec/macruby directory).
How do you intend to change #framework exactly? Maybe you should work on a patch first, and we can iterate on it, then write the spec/test later.
As a TDDer, I went to the specs first :) My update is pretty simple so I just went ahead and wrote the patch, added to this ticket: https://www.macruby.org/trac/ticket/1198 In short, I changed Kernel#framework to *always* treat strings like 'Cocoa' as a framework names that resolve against the main bundle, system paths, and DYLD_FRAMEWORK_PATH. Anything that looks like a path gets resolved against the current directory (unless it's absolute, of course). Paths are anything with a slash or '.framework' on the end, essentially. Based on the existing code, I think this was the expected behavior, but it had the gotcha I experienced.
Thanks for helping :)
No problem! christian.
participants (3)
-
Christian Niles
-
Laurent Sansonetti
-
Matt Aimonetti