[Win32utils-devel] Comments for Daniel Berger blog post
djberg96 at gmail.com
Tue Aug 11 19:40:48 EDT 2009
On Fri, Aug 7, 2009 at 5:16 PM, Luis Lavena<luislavena at gmail.com> wrote:
> Hey Daniel,
> I'm trying to leave you a comment on this article you wrote:
> But since you disabled OpenID and anonyous, I'm not fond to register
> for another account just to reply your comments.
I don't see a way to allow OpenID on LJ. If there's a way, I'll enable
that. I won't allow anonymous comments, though.
> Quoting your post:
> Unfortunately, I've slammed into the cold hard fact that FFI just
> isn't the grand solution we all hoped it would be. The first problem
> is that libffi, the underlying source for C based implementations,
> isn't going to build without the gcc toolchain. That pretty much
> leaves everyone but Linux, FreeBSD and OS X in the dust, including two
> heavy hitters, MS Windows and Solaris (if you're using the Sun Studio
> That is incorrect. Ruby-FFI team worked and integrated rake-compiler
> project in the build process to be able to deliver a binary gem that
> install and run flawlessly on both mswin32 (VC6) and mingw32 (GCC).
> If you're asking to build it against Visual Studio, of course it will
> fail, but I suggest you send patches to improve that process, it is
> now on GitHub:
I'm not going to install mingw just so I can build FFI. If we can get
it to build with VS that would be great.
> Then there's the issue of JRuby's lack of support for certain parts of
> C, such as file descriptors, as my attempt to port file-temp
> You have a point over there, but transfering file descriptors across
> implementations would be impossible, because that would remove the
> safe lock around the whole managed idea.
If I can't get at low level details with JRuby, like file descriptors
and pointer function addresses, then JRuby is officially hopeless as a
system's programming language.
> What about IronRuby? They would face the same issue with file descriptors.
We'll have to wait and see, but somehow I doubt it.
> So now I'm in a dilemma. If I want to write cross-platform code that
> will work with JRuby and C based implementations, I'm relegated to
> keeping two (or more) separate source files, one for MRI and one for
> JRuby. It would more likely be 3, as I'll still need a separate source
> file for Windows, since the code is radically different from its *nix
> counterpart most of the time.
> Why so? I mean, you can have several files in the same gem that, based
> on the platform, get required independently. Perhaps I'm missing your
> point, but would love to explore the issue you're facing to help you
> find the balance and a solution
People keep telling me this, but I've yet to see it in practice. As
far as I can tell you have to generate the gems up front. I don't see
a way to dynamically determine, at the point of installation, which
file should be considered the "real" file.
Please take a look at sys-proctable for the most extreme case of
variable source code, and tell me how you would handle it.
> On top of that I've heard disturbing reports that there is little
> interest in supporting FFI on Windows, in which case we may as well
> declare it dead in the water. Whether you like it or not, Windows is a
> major player and its here to stay. If it's not going to work on
> Windows you may as well chuck it now and stick with C extensions.
> You can't impose the platform to anyone, even less in the OpenSource
> community. That's why I've created rake-compiler to help them support
> Now that FFI builds with RubyInstaller and DevKit, bug and patches can
> be provided by other developers. FFI team announced there will be no
> official support since the core team doesn't run Windows, but that
> doesn't mean they are not fond to integrate these changes.
> Wonder why your negative comment about it or if you haven't heard the
> news about Ruby-ffi 0.4.0 release with native gems for mingw32 and
I didn't know about it. I will try ruby-ffi 0.4.0 and see how it goes.
Honestly, though, if JRuby can't support some of the features I want,
I don't see any point in converting most of my current C extensions to
FFI. Then people can choose whatever compiler they wish. :)
More information about the win32utils-devel