RubyMotion?

[elcuervo]

I'm considering to use concurrent-ruby on some of my projects. For one of them some people are asking me for RubyMotion support and that'd require some work to implement concurrency since I'm already using Celluloid. Since I might take that road that will it make sense to add RubyMotion support for this gem? Or that's way out of the scope?

[mighe]

Our gem does not require any external dependency and every component is available in a full standard Ruby 1.9 implementation, so it should already run.
Do you the chance to try concurrent-ruby out on RubyMotion?

[jdantonio]

@elcuervo I apologize, but my knowledge of RubyMotion is minimal. Are you asking if this gem will work with RubyMotion, or are you suggesting extending the gem with RubyMotion-specific optimizations?

This gem is 100% pure Ruby and should run under any compliant interpreter.

We have started to implement conditional JRuby-specific optimizations and are experimenting with CRuby/MRI-specific extensions as well. The idea is that the gem automatically detects which platform it is installed on and will include the relevant optimizations. If there is a way to implement similar optimizations on RubyMotion we'd be happy to explore that approach. So long as we provide a consistent API and behavior across all platforms we're happy to optimize when possible.

[elcuervo]

Well, my knowladge is minimal as well. Here's the deal: I'm the author of airplay and I'm considering switching to concurrent-ruby. I need more control on the things I'm doing right now, and I really love zero-dependency.

Some people are asking me to port the gem to be RubyMotion compatible and since I'll have to do that maybe it will make sense to work in a implementation for concurrent-ruby since I saw the jruby/rbx flags in the code.

I'm basically asking if I add a RubyMotion wrapper for the calls you'd be open to merge it. The idea is to use the GCD to handle thread dispatching.

[chrisseaton]

A new executor using GCD would make a lot of sense, and maybe some other primitives could directly use GCD such as queues and barriers. It would be really interesting to benchmark Ruby's primitives against GCD and Java.

[jdantonio]

@elcuervo We'll happily support additional platform-specific optimizations.

Our rule is to have a pure-Ruby implementation of every class/module/abstraction in the gem but support platform-optimized implementations where able (we'll be adding CRuby extensions soon). So long as the GCD versions support the same API and exhibit the same behavior as the pure Ruby versions, we'd be happy to include it.

[elcuervo]

Awesome. I'll start working on that and keep you in the loop. ❤️

[jamonholmgren]

An issue right now that I see is that you're using require in each file, which isn't supported in RubyMotion (since runtime require isn't available). If you were to switch to something like motion-require and change all requires to require_relative it might work, but likely have issues there as well. RubyMotion is mostly Ruby-compliant but not fully due to its compiled nature and having to abide by Apple's rules.

[chrisseaton]

For RubyMotion can you not just monkey patch require to be motion_require?

[jamonholmgren]

Good question, I should try it. It would be awesome to have this gem available in RubyMotion.

[jdantonio]

I recently purchased RubyMotion after seeing @lrz speak at Steel City Ruby. I haven't had a chance to work with it yet, but I do hope to make this gem compatible.

@jamonholmgren Any help you can provide would be greatly appreciated.

[jamonholmgren]

@jdantonio I'd be happy to help. Right now a bit buried with client work but eventually I'll give it a go.

[jdantonio]

@jamonholmgren Great. Thank you!

[jamonholmgren]

@jdantonio

I've played with this some. Since most of the classes are POROs, this is certainly possible to port at least some of this to RubyMotion. Monkeypatching require to be a no-op does work (just tested it).

I think it might cause disruption in your code base beyond what you'd likely want to allow. For example, your Rakefile and Gemfile would both need to be split into two: one for RM and one for Ruby. C extensions won't be possible (I'm not sure yet how much of your code base relies on them). Specs will need to be somewhat rewritten. And I'm not sure what else yet.

It might be best to create a new RubyMotion-specific gem and copy over relevant code. Some of the classes could probably benefit from the use of GCD (Grand Central Dispatch) rather than using threads.

It's also possible that we could create a subfolder that holds the RubyMotion-specific code and refers back to the lib folder for shared code.

Either way, it'll be a lot of work. Unless there's a lot of demand for it I'd recommend tabling the discussion for now. Much as I'd like to see this lib in RM, it's probably not worth doing quite yet.

[jdantonio]

@jamonholmgren Thank you very much for taking the time to look into this. None of the C or Java code in the gem is necessary--everything is written in pure Ruby and native code optimizations are only triggered on supporting platforms. In theory we could follow that same pattern for RubyMotion, but so far there isn't any demand. Your recommendation to not pursue this right now seems like the wise approach.