I'm currently testing out TextMate for doing some Ruby coding. It gets very high marks from the community at large and so far things have looked fairly good.
However, I ran into a bug and I need the list's help to solve it.
The code I'm writing and testing uses the plist gem [1] from rubyforge. Whenever I try to test code that uses any functionality from that gem, the test fails with the following error:
1) Error: test_temp(TC_MyTest): NameError: uninitialized constant Some::Plist method some in temp.rb at line 12 method test_temp in tc_temp.rb at line 13
(where Some is a class I created for the purpose of trapping this bug.)
I searched for this problem and discovered another complaint about it back in July [2] along with a response [3]. The response wasn't very helpful for figuring out a workaround, so I thought I'd ask again.
How can I modify TextMate so it doesn't stomp on the ruby namespace for Plist? Alternately, how can I modify my ruby code to avoid the namespace collision? BTW, I have already "deleted" the Property List Macro Bundle from TextMate but that didn't appear to have any positive effect.
I've already tried different scoping shenanigans with modules and the :: scope operator, but it still blows up. Thanks for your help.
cr
[1] http://plist.rubyforge.org/ [2] http://article.gmane.org/gmane.editors.textmate.general/11813 [3] http://article.gmane.org/gmane.editors.textmate.general/11814
On Tuesday, November 14, 2006, at 03:12PM, cremes.devlist@mac.com wrote:
I'm currently testing out TextMate for doing some Ruby coding. It gets very high marks from the community at large and so far things have looked fairly good.
However, I ran into a bug and I need the list's help to solve it.
The code I'm writing and testing uses the plist gem [1] from rubyforge. Whenever I try to test code that uses any functionality from that gem, the test fails with the following error:
- Error:
test_temp(TC_MyTest): NameError: uninitialized constant Some::Plist method some in temp.rb at line 12 method test_temp in tc_temp.rb at line 13
(where Some is a class I created for the purpose of trapping this bug.)
I found a solution though I don't like it very much. I changed my #require to use the absolute path to the plist gem, so now there isn't a name collision.
Interestingly, TextMate does have its own plist implementation. It's stored at TextMate.app/Contents/SharedSupport/Support/lib and is a compiled binary object. It's using lots of CoreFoundation stuff internally (run 'nm plist.bundle' for a list of symbols) and thankfully there aren't any method name collisions.
Is there a way to force TextMate to put your local gems repository earlier in the load path than its own internal libraries?
cr
On 14. Nov 2006, at 23:04, cremes.devlist@mac.com wrote:
[...] I found a solution though I don't like it very much. I changed my #require to use the absolute path to the plist gem, so now there isn't a name collision.
You can also do:
require 'rubygems' require_gem 'plist'
Interestingly, TextMate does have its own plist implementation. It's stored at TextMate.app/Contents/SharedSupport/Support/lib and is a compiled binary object. It's using lots of CoreFoundation stuff internally (run 'nm plist.bundle' for a list of symbols) and thankfully there aren't any method name collisions.
The TM plist uses CoreFoundation, meaning it can read ASCII (old- style/openstep) and binary property lists in addition to XML plists -- the rubygem version only does the latter.
Is there a way to force TextMate to put your local gems repository earlier in the load path than its own internal libraries?
The problem with that is, then TM would start “crash” from getting the wrong plist, in all the TM commands which use our plist extension.
But probably we can re-export RUBYLIB for scripts running under RubyMate to not have TM’s support path included -- though personally I do much enjoy having it there.
-
Allan Odgaard -
cremes.devlist＠mac.com