ruby bounties--list of bounties
in [Ruby]
|
From: Mike Dalessio on 25 Jan 2010 01:10 [Note: parts of this message were removed to make it a legal post.] On Sun, Jan 24, 2010 at 7:15 AM, Charles Oliver Nutter <headius(a)headius.com>wrote: > On Sat, Jan 23, 2010 at 11:49 PM, Roger Pack <rogerpack2005(a)gmail.com> > wrote: > > Looks like pure java Nokogiri is something popular--the bounty on it has > > already risen to $225 > > It's probably the most oft-encountered stumbling block for folks using > JRuby (these days), since Nokogiri itself has become very popular and > is now depended on by many other libraries. A pure-Java version would > never need special handling on any platform, would work on any > platform where JRuby works, and would not require native library > support at all. > > I implore gem authors: think about who you might hurt with hard gem > dependencies on native extensions. At least provide an alternative > path. > I'm in for $200 for a Java Nokogiri implementation. So is my partner in crime, Aaron. Consider it "conscience money" for all the puppies who died as a result of us writing and maintaining the JRuby FFI port of Nokogiri. :) > > - Charlie > > -- mike dalessio mike(a)csa.net
From: Phillip Gawlowski on 25 Jan 2010 02:29 On 25.01.2010 06:29, Aaron Patterson wrote: > I implore Ruby implementors to support the MRI C api, as it too is part > of Ruby's api. Either provide mswin32 (compiled with VC6), or mingw32 binaries (yes, binaries, not the source code), or use Java. -- Phillip Gawlowski
From: Phillip Gawlowski on 25 Jan 2010 02:38 On 25.01.2010 08:29, Phillip Gawlowski wrote: > On 25.01.2010 06:29, Aaron Patterson wrote: > >> I implore Ruby implementors to support the MRI C api, as it too is part >> of Ruby's api. > > Either provide mswin32 (compiled with VC6), or mingw32 binaries (yes, > binaries, not the source code), or use Java. "mswin32 *and* mingw32" is what I actually wanted to write. My apologies. -- Phillip Gawlowski
From: Tony Arcieri on 25 Jan 2010 03:11 [Note: parts of this message were removed to make it a legal post.] On Sun, Jan 24, 2010 at 10:29 PM, Aaron Patterson < aaron(a)tenderlovemaking.com> wrote: > I thought FFI was supposed to solve this problem. Is it not? > It "solves" it to a certain degree, but when deploying in enterprise environments it can be quite a hassle. Think: ancient versions of RHEL with ancient versions of libxml/libxslt. That's not to mention problems with 32-bit vs 64-bit environments: for some reason the 64-bit version of RedHat didn't package a 32-bit libxslt, but they did provide a 64-bit one. However, we originally installed a 32-bit JRE. Eep! 64-bit JRE is an "unofficially supported" configuration for our environment (they typically run 32-bit JRE on 64-bit RedHat for some reason). Nokogiri's great and we have everything working now (we had to do some symlink hackery though). However, it would definitely streamline the deployment process a lot if we didn't have native code dependencies, and right now Nokogiri is the only one we have. -- Tony Arcieri Medioh! A Kudelski Brand
From: Eleanor McHugh on 25 Jan 2010 07:36
On 25 Jan 2010, at 05:29, Aaron Patterson wrote: > On Sun, Jan 24, 2010 at 09:15:56PM +0900, Charles Oliver Nutter wrote: >> I implore gem authors: think about who you might hurt with hard gem >> dependencies on native extensions. At least provide an alternative >> path. > > I implore Ruby implementors to support the MRI C api, as it too is part > of Ruby's api. Think about who you hurt by not letting people reuse > valuable libraries written in C. :-) I implore Ruby developers to write in Pure Ruby and demand all these Ruby Implementors solve their "performance" problems ;p Ellie Eleanor McHugh Games With Brains http://slides.games-with-brains.net ---- raise ArgumentError unless @reality.responds_to? :reason |