Ruby::DL vs Ruby::FFI

Ruby.DL and FFI libraries are great for programmers like me who are not
internet programmers, but are more interested in scientific and number
processing etc.

I really like FFI, though I started with DL since at that time FFI won’t
build on windoz. Good part of DL is that it is part of standard libary,
not supported (fully) by JRuby though. FFI on the other hand has matured
and is available on windoz, greatest joy is same script will, in all
probability run across all implementations.

recently few days back I saw some svn msgs suggesting that DL’s
dependency on libffi was removed, since libffi won’t build on windoz
(again!). so my question is will DL in future be based on libffi ? why
just not use FFI. Its API and idea is very good and ruby like, against
DL’s idea of giving in C snippets to be interpreted by DL ?

Aston

  The INTERNET now has a personality. YOURS! See your Yahoo! 

Homepage. http://in.yahoo.com/

On Mon, Mar 8, 2010 at 4:56 PM, Aston [email protected]
wrote:

I really like FFI, though I started with DL since at that time FFI won’t
build on windoz.

The building of ffi gem happens under Linux/OSX, until a few weeks ago
the environment of the gem author was borked, and that was the reason
there has been no binary for Windows yet.

recently few days back I saw some svn msgs suggesting that DL’s dependency
on libffi was removed, since libffi won’t build on windoz (again!). so my
question is will DL in future be based on libffi ? why just not use FFI. Its
API and idea is very good and ruby like, against DL’s idea of giving in C
snippets to be interpreted by DL ?

Ruby core developers state is not compatible with MSVC, and is not
“out of the box”, you need to use a script wrapper around configure
which was added recently as contribution my mozilla labs. (msvcc.sh)

I’ve tried with old Visual C 6.0 and it doesn’t work without a lot of
tweaking, the configure process is not great and you still need
certain MSYS tools (bash and such). Haven’t tested newer Visual C
versions since semi-official builds use Visual C 6.0

I think that is the reason got rejected.

If someone can work on a CMake configure script, Ruby-Core can use
that to build and install libffi, then I think libffi can be back to
replace DL.

Since time to do that means money, I’ve money to give for it, $100 USD.

Anyone interested in build a CMake replacement for libffi autoconf
please let me know.

On Mar 8, 8:56 am, Aston [email protected] wrote:

Ruby.DL and FFI libraries are great for programmers like me who are not internet programmers, but are more interested in scientific and number processing etc.

I really like FFI, though I started with DL since at that time FFI won’t build on windoz. Good part of DL is that it is part of standard libary, not supported (fully) by JRuby though. FFI on the other hand has matured and is available on windoz, greatest joy is same script will, in all probability run across all implementations.

recently few days back I saw some svn msgs suggesting that DL’s dependency on libffi was removed, since libffi won’t build on windoz (again!). so my question is will DL in future be based on libffi ? why just not use FFI. Its API and idea is very good and ruby like, against DL’s idea of giving in C snippets to be interpreted by DL ?

FFI will build on Windows, so long as you’re using mingw and gcc.
Actually, FFI won’t build on any platform without gcc at the moment as
far as I know, so if you were thinking of building it with the Sun
Studio Compiler or the HP-UX compiler, for example, you’re out of
luck.

DL, so far as I know, will build on any platform with any compiler.

Regards,

Dan

Just wanted to get my two cents worth in: I use Ruby for DSP processing,
so all this is very important to me too.

cheers,
e

(2010/03/09 1:04), Luis L. wrote:

on libffi was removed, since libffi won’t build on windoz (again!). so my
tweaking, the configure process is not great and you still need

Anyone interested in build a CMake replacement for libffi autoconf
please let me know.

I confirmed Aaron’s ext/dl can work with following
patched libffi on mswin32/VC9.
http://sourceware.org/ml/libffi-discuss/2010/msg00049.html

If this also works on mswin64 and libffi merge this,
we can reimport Aaron’s new ext/dl.
Please try this who have other than mswin32/VC9 and feedback to libffi.

Oh, I mistook mailer’s operation.
Sorry, please ignore.

2010/3/9, NARUSE, Yui [email protected]:

On Mon, Mar 8, 2010 at 9:56 AM, Aston [email protected]
wrote:

recently few days back I saw some svn msgs suggesting that DL’s dependency
on libffi was removed, since libffi won’t build on windoz (again!). so my
question is will DL in future be based on libffi ? why just not use FFI. Its
API and idea is very good and ruby like, against DL’s idea of giving in C
snippets to be interpreted by DL ?

Why not build DL atop FFI, and get FFI into Ruby 1.9.2?

JRuby already has a partial start on a DL that just uses FFI:

http://github.com/jruby/jruby/blob/master/lib/ruby/1.8/dl.rb

and

http://github.com/jruby/jruby/blob/master/lib/ruby/1.8/dl

A DL that uses FFI would work without modification or build hassles on
any impl+platform that supports FFI.

  • Charlie

On Mon, Mar 8, 2010 at 10:08 AM, Daniel B. [email protected]
wrote:

FFI will build on Windows, so long as you’re using mingw and gcc.
Actually, FFI won’t build on any platform without gcc at the moment as
far as I know, so if you were thinking of building it with the Sun
Studio Compiler or the HP-UX compiler, for example, you’re out of
luck.

JRuby supports FFI on Windows just fine.

  • Charlie

Hello,

2010/3/9, NARUSE, Yui [email protected]:

I confirmed Aaron’s ext/dl can work with following
patched libffi on mswin32/VC9.
Mladen Turk - MSVC build

If this also works on mswin64 and libffi merge this,
we can reimport Aaron’s new ext/dl.
Please try this who have other than mswin32/VC9 and feedback to libffi.

I tried new dl on mswin64, and built it with the followinge$B!!e(Bpatch.
But there is three issue at least.

  1. object’s memsize can’t calculate correctly.
    It will be solved if libffi support ffi_raw_size() on mswin64.

  2. test/dl/test_dl2.rb cause SEGV
    This is critical.

  3. some tests fail.

diff --git a/ext/dl/closure.c b/ext/dl/closure.c
index 593d566…3d0c7ad 100644
— a/ext/dl/closure.c
+++ b/ext/dl/closure.c
@@ -41,7 +41,9 @@ dlclosure_memsize(const void * ptr)

 if (ptr) {

size += sizeof(*cls);
+#if !defined(FFI_NO_RAW_API) || !FFI_NO_RAW_API
size += ffi_raw_size(cls->cif);
+#endif
size += sizeof(*cls->argv);
size += sizeof(ffi_closure);
}
diff --git a/ext/dl/method.c b/ext/dl/method.c
index 1bd0fa8…5705f55 100644
— a/ext/dl/method.c
+++ b/ext/dl/method.c
@@ -43,7 +43,9 @@ dlfunction_memsize(const void *p)

 if (ptr) {

size += sizeof(*ptr);
+#if !defined(FFI_NO_RAW_API) || !FFI_NO_RAW_API
size += ffi_raw_size(ptr);
+#endif
}
return size;
}
diff --git a/win32/win32.c b/win32/win32.c
index 5189826…268c3c7 100644
— a/win32/win32.c
+++ b/win32/win32.c
@@ -5278,11 +5278,7 @@ _ftol2_sse(double d)
int
signbit(double x)
{
-#ifdef _M_IX86
int *ip = (int *)(&x + 1) - 1;
return *ip < 0;
-#else
-# error not supported
-#endif
}
#endif

On Mon, Mar 8, 2010 at 9:56 AM, Aston [email protected]
wrote:

recently few days back I saw some svn msgs suggesting that DL’s dependency
on libffi was removed, since libffi won’t build on windoz (again!). so my
question is will DL in future be based on libffi ? why just not use FFI. Its
API and idea is very good and ruby like, against DL’s idea of giving in C
snippets to be interpreted by DL ?

Why not build DL atop FFI, and get FFI into Ruby 1.9.2?

JRuby already has a partial start on a DL that just uses FFI:

http://github.com/jruby/jruby/blob/master/lib/ruby/1.8/dl.rb

and

http://github.com/jruby/jruby/blob/master/lib/ruby/1.8/dl

A DL that uses FFI would work without modification or build hassles on
any impl+platform that supports FFI.

  • Charlie

On Thu, Mar 11, 2010 at 12:56:31AM +0900, wanabe wrote:

I tried new dl on mswin64, and built it with the following patch.
But there is three issue at least.

  1. object’s memsize can’t calculate correctly.
    It will be solved if libffi support ffi_raw_size() on mswin64.

I applied this part of the patch:

http://github.com/tenderlove/ruby/commit/736cfc3392f3827d8debdc00454ad11ac67377de

The win32/win32.c part didn’t apply in my fork.

  1. test/dl/test_dl2.rb cause SEGV
    This is critical.

  2. some tests fail.

I will test 2 and 3 when I get my copy of windows.

Thank you for testing this!

On Wed, Mar 10, 2010 at 11:43:20PM +0900, Charles Oliver N. wrote:

On Mon, Mar 8, 2010 at 9:56 AM, Aston [email protected] wrote:

recently few days back I saw some svn msgs suggesting that DL’s dependency
on libffi was removed, since libffi won’t build on windoz (again!). so my
question is will DL in future be based on libffi ? why just not use FFI. Its
API and idea is very good and ruby like, against DL’s idea of giving in C
snippets to be interpreted by DL ?

Why not build DL atop FFI, and get FFI into Ruby 1.9.2?

DL is not a subset of FFI.

JRuby already has a partial start on a DL that just uses FFI:

http://github.com/jruby/jruby/blob/master/lib/ruby/1.8/dl.rb

and

http://github.com/jruby/jruby/blob/master/lib/ruby/1.8/dl

A DL that uses FFI would work without modification or build hassles on
any impl+platform that supports FFI.

My fork of Ruby already contains DL built on top of FFI. Unfortunately
my patch was rolled out because it doesn’t work on Windows with MSVC.
We’re working on that. :slight_smile:

You can view my changes here:

http://github.com/tenderlove/ruby/commits/ffi

On Mar 10, 2010, at 11:37 PM, Aston wrote:

Studio Compiler or the HP-UX compiler, for example, you’re out of
luck.

JRuby supports FFI on Windows just fine.

  • Charlie

JRuby is of course an excellant option for us, but it can still improve if it starts supporting win32ole
we need win32ole since we are required to parse some MS apps generated *.xml files
and they are generated by MS DOM impl, sometimes REXML just errors out and MSXML does it fine

Here’s a project that is providing the beginning of win32ole support for
jruby [1]. Please try it out with your application to see if it works.
File tickets or provide patches for broken or missing functionality.

cr

[1] GitHub - bpmcd/win32ole: WIN32OLE JRuby Native Extension

2010/3/11, Aaron P. [email protected]:

On Thu, Mar 11, 2010 at 12:56:31AM +0900, wanabe wrote:
… snip…

  1. test/dl/test_dl2.rb cause SEGV
    This is critical.

  2. some tests fail.

I will test 2 and 3 when I get my copy of windows.

I fixed some tests and ext/dl/lib/dl/pack.rb. See r26980-26984, ruby
trunk.
There are still some tests failure, but they also appear with old-DL on
mswin32.
So mswin64 specific issue might be gone now, I think.

But r26982 is very, very ugly.

Does Anyone rewrite it?


From: Charles Oliver N. [email protected]
To: ruby-talk ML [email protected]
Sent: Wed, 10 March, 2010 8:12:11 PM
Subject: Re: Ruby::DL vs Ruby::FFI

On Mon, Mar 8, 2010 at 10:08 AM, Daniel B. [email protected]
wrote:

FFI will build on Windows, so long as you’re using mingw and gcc.
Actually, FFI won’t build on any platform without gcc at the moment as
far as I know, so if you were thinking of building it with the Sun
Studio Compiler or the HP-UX compiler, for example, you’re out of
luck.

JRuby supports FFI on Windows just fine.

  • Charlie

JRuby is of course an excellant option for us, but it can still improve
if it starts supporting win32ole
we need win32ole since we are required to parse some MS apps generated
*.xml files
and they are generated by MS DOM impl, sometimes REXML just errors out
and MSXML does it fine

  Your Mail works best with the New Yahoo Optimized IE8. Get it NOW!