[MacRuby-devel] Rspec Stopped Running Under Macruby

[Shannon Love]

I had previously had Rspec running under Macruby before I tried to use RVM to manage my ruby installs. Something went awry with RVM and I had to uninstall. After that Rspec stopped working under Macruby. I

I found that my RVM had installed Macruby 0.11 dev in or over my 0.10 install and that remained even after I had removed RVM so I used pkgutil to uninstall all Macruby, then I reinstalled the system ruby package and then reinstall Macruby 0.10

The system ruby 1.8.7 runs rspec installed with its gem command just fine. However, if I uninstall the system rspec and install with macgem, I get the following error trying to either execute a file with rspec calls or running rspec from the command line with or without any options or files.

<code>
/Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/Gems/1.9.2/gems/rspec-core-2.6.0/lib/rspec/core/world.rb:14:in `empty_without_conditional_filters?': undefined method `empty?' for #<Enumerator:0x2002a76c0> (NoMethodError)
from /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/Gems/1.9.2/gems/rspec-core-2.6.0/lib/rspec/core/world.rb:131:in `announce_exclusion_filter:'
from /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/Gems/1.9.2/gems/rspec-core-2.6.0/lib/rspec/core/world.rb:103:in `announce_filters'
from /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/Gems/1.9.2/gems/rspec-core-2.6.0/lib/rspec/core/command_line.rb:19:in `run:'
from /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/Gems/1.9.2/gems/rspec-core-2.6.0/lib/rspec/core/runner.rb:80:in `run_in_process:'
from /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/Gems/1.9.2/gems/rspec-core-2.6.0/lib/rspec/core/runner.rb:69:in `run:'
from /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/Gems/1.9.2/gems/rspec-core-2.6.0/lib/rspec/core/runner.rb:11:in `block'
localhost:SetUpRspec developer$ which rspec
</code>

The the actual error line is here and it appears to be part of the way that Rspec processes command line arguments:

<code>
module RSpec
module Core
class World

module Describable
PROC_HEX_NUMBER = /0x[0-9a-f]+@/
PROJECT_DIR = File.expand_path('.')

def description
reject { |k, v| RSpec::Core::Configuration::CONDITIONAL_FILTERS[k] == v }.inspect.gsub(PROC_HEX_NUMBER, '').gsub(PROJECT_DIR, '.').gsub(' (lambda)','')
end

def empty_without_conditional_filters?
14 => reject { |k, v| RSpec::Core::Configuration::CONDITIONAL_FILTERS[k] == v }.empty?
end

def reject
super rescue {}
end

def empty?
super rescue false
end
end
</code>

I'm a ruby noob but I think it's trying to process a block returned by `super rescue` and it expects a collection but receives an enumerator instead. Why that is, I don't know.

Repeated macgem installs of the rspec gem do nothing to alter the issue. I can't find any other references to similar problems. I assume that in my naivety with RVM and ruby in general, I wrecked something somewhere in the system that breaks rspec or macruby but I don't know how to fix it.

Thanks,
TechZen
_______________________________________________
MacRuby-devel mailing list
MacRub...@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[Christian Niles]

Hey Shannon,

I just ran into this problem myself. I believe it has something to do with RSpec 2.6, since I don't get the error when rspec 2.5 is installed.

Can you try downgrading and see if that helps you as well?

christian.

[Shannon Love]

Christian,

Reverting to Rspec 2.5 allowed rspec to run under macruby (so far.) However, it is extremely slow compared to running under system ruby. it takes 10+ seconds to run just an empty test and pegs out one of my cores to do so.

Macruby should run faster than the system ruby 1.8.7 so I think I've still got a Macruby problem somewhere. Guess I need to do another post.

Thanks,
Shannon

[Christian Niles]

I have the same (performance) issue too. I believe this is due to MacRuby's JIT, which compiles the ruby source into machine code using LLVM. This improves performance dramatically for long-running apps, but in our case it seems to cause a big up-front penalty.

Does anyone else on list know if there is a way to disable the JIT? I'd love to do some performance comparisons and see if this helps.

[Mark Rada]

Rspec 2.6 works on the macruby nightly builds.

Load times are partly due to rubygems being very slow on MacRuby and rspec being split into 4 gems (plus one other external gem).

The other problem is that you have to JIT all the code at run time; you should be able to cut the load time in half by compiling rspec and its dependencies, but that has a couple of caveats right now, you can read more about it in the README for my rubygems plugin:

https://github.com/ferrous26/rubygems-compile

Also, there are a couple of issues in the macruby trac related to slow gem loading time. You may wish to add a comment there about rspec.

Mark Rada
mr...@marketcircle.com

[Nat Brown]

am i understanding the option being described here as manually forcing a pre-compile of .rb gems to .rbo cached to the gems directory (with caveats like no backtrace, ymmv)?

anybody working on a generic (system-wide or per-user or configurable?) cache of arbitrary .rb -> .rbo similar to how rubyinline works, where llvm intermediaries being built are automatically cached and invalidated when the associated/underlying .rb changes?

i would be interested to help if somebody is already in-flight with that, or take a stab it if nobody is -- lmk pls.

thx, n@

[Mark Rada]

On 2011-05-20, at 3:28 PM, Nat Brown wrote:

am i understanding the option being described here as manually forcing a pre-compile of .rb gems to .rbo cached to the gems directory (with caveats like no backtrace, ymmv)?

Almost. You lose backtraces right now, but that is a temporary tradeoff; eventually MacRuby will be able to give backtraces for pre-compiled code. Also, there is the auto_compile command in the plugin that automatically compiles gems as you install them.

anybody working on a generic (system-wide or per-user or configurable?) cache of arbitrary .rb -> .rbo similar to how rubyinline works, where llvm intermediaries being built are automatically cached and invalidated when the associated/underlying .rb changes?

i would be interested to help if somebody is already in-flight with that, or take a stab it if nobody is -- lmk pls.

That sounds interesting and potentially very useful, but not too difficult to do. Unfortunately I am already in the middle of too many different projects so I wouldn't be able to help much. :(

thx, n@

Good luck,

Mark Rada
mr...@marketcircle.com

[Shannon Love]

I it appears I spoke to soon in my previous mail. Reverting to Rspec 2.5 got me to where I could run basic test but now I get sig fault when I try to use an expectation (should statement.) It even happens with example code I copied from the rspec 2.5 docs.

Just for grins, I ran rspec own spec for the expectations and as I expected, they crashed as well.

I think I'll have to abandon rspec and macruby for now as I have run out of time to fiddle with it.

[Christian Niles]

On May 20, 2011, at 12:28 PM, Nat Brown wrote:

> anybody working on a generic (system-wide or per-user or configurable?) cache of arbitrary .rb -> .rbo similar to how rubyinline works, where llvm intermediaries being built are automatically cached and invalidated when the associated/underlying .rb changes?
>
> i would be interested to help if somebody is already in-flight with that, or take a stab it if nobody is -- lmk pls.

I'm not working on this, but I've been thinking this past week about the other direction -- distributing compiled code (frameworks, static libraries) in gems. There's no package manager in the Cocoa world and it'd be really nice to simplify the process of importing 3rd-party code.

For example, take a look at Cedar:

https://github.com/pivotal/cedar

How nice would it be to reduce this install (along with OCMock and OCHamcrest) to something like 'gem install ...'?

I'm spending some time over the next couple works playing with this idea. Maybe I'll have something to share by WWDC!

christian.