warning about mising C extension with 0.7.0

[schmurfy]

I get that:

Compiled extensions not installed, pure Ruby Atomic will be used.

And when I look at the gem folder there is not c extension installed :(

[jdantonio]

What operating system are you using? Mac OS X?

To avoid the problems normally associated with compiling native extensions we produce pre-compiled gem builds. There was a problem with the build process on OS X that I haven't had an opportunity yo resolve yet, so C extensions are disables on that platform. The full functionality of the gem is available even when pure Ruby is used.

I've been thinking a lot about the native C and Java code and how best to handle it. My current thinking is that it may be best to move the native code into a different gem and make it an optional dependency. I haven't had an opportunity to propose that idea to the team yet.

[chrisseaton]

@jdantonio I like the model that chunky_png and oily_png, and psd.rb and psd_native have - one gem defines the behaviour in pure Ruby, the other monkey patches those methods to use native extensions. Keeping the behaviour in sync might be problem - someone sends a PR and you have to ask them to go to a different repo and update that as well.

[jdantonio]

@chrisseaton I'm not familiar with those gems (other than through the performance optimization article you wrote) but I think that you and I have the same idea. Keep all the pure Ruby code in this gem and move all the C and Java code into another gem (perhaps the original ruby-atomic). This gem would then detect if the native gem has been installed and if so would defer to the native code.

[chrisseaton]

This gem would then detect if the native gem has been installed and if so would defer to the native code.

I don't think you need this bit. The idea is that the Ruby gem is oblivious of any other gems or native extensions. The native gems then monkey patch the original gem - they don't create their own methods, they just replace existing ones.

[schmurfy]

Yes I forgot to mention it was on Mac OS X.
I am not sure how I feel about it but monkey patching might work, why not keep everything at the same place and just compile what is needed ? What are the issues ?
(splitting the code in multiple gems is a good way to have them out of sync and will be more annoying to manage for those making the releases)

Anyway no matter how this is implemented we need a way to know which version we are using, a method which returns something like :ruby, :java, :native .
I already had issues with eventmachine in the past not properly installing its native extension and being able to check what is loaded really helped, now I just raise if we are in the wrong mode.
(This is especially critical with eventmachine since the C, Ruby and Java version are not in sync at all xD)

[pitr-ch]

I would rather not split, I am afraid of maintainability as well. Nevertheless if we split, I would advocate for keeping one repository with multiple gemspecs which would pick the right files form the repository.

+1 to be able to read what implementation is used. (Can be done already by looking at superclass name, not the best though.)

[schmurfy]

Multiple gemspec could be a good idea indeed :)
To know which implementation is used EventMachine expose a method I can't remember but it looks something like: EventMachine.reactor_mode and the returns is similar to what I wrote above.

Edit: While not on topic I still wonder why the atomic gem had to be merged.

[pitr-ch]

Hm, I've just saw 0.7.0 August 13, 2014 x86_64-darwin-13 yanked on https://rubygems.org/gems/concurrent-ruby/versions I guess that's why we see Compiled extensions not installed, pure Ruby Atomic will be used. on OS X. @jdantonio?

[jdantonio]

There was a problem with the OS X native extensions. The full path to the compiled extensions--as it appeared on my personal machine--was written into the bundle. The extensions, therefore, only worked for me. I lacked sufficient experience compiling C code on OS X to solve the problem, so I yanked the build. I have not had an opportunity to revisit.

[pitr-ch]

@jdantonio thanks for the explanation. I guess this is also the reason why we see Compiled extensions not installed, pure Ruby Atomic will be used. because there is no precompiled version available, right?