Forum: Ruby 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 <blackapache512-ticket@yahoo.com> 
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.

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

On Mar 8, 8:56 am, Aston <blackapache512-tic...@yahoo.com> 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

(2010/03/09 1:04), Luis Lavena 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.

2010/3/9, NARUSE, Yui <naruse@airemix.jp>:

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

On Mon, Mar 8, 2010 at 10:08 AM, Daniel Berger <djberg96@gmail.com> 
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

On Mon, Mar 8, 2010 at 9:56 AM, Aston <blackapache512-ticket@yahoo.com> 
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 9:56 AM, Aston <blackapache512-ticket@yahoo.com> 
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

Hello,

2010/3/9, NARUSE, Yui <naruse@airemix.jp>:
> 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.

I tried new dl on mswin64, and built it with the following$B!!(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 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.

> 2. test/dl/test_dl2.rb cause SEGV
>    This is critical.
> 
> 3. 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 Nutter wrote:
> On Mon, Mar 8, 2010 at 9:56 AM, Aston <blackapache512-ticket@yahoo.com> 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.  :-)

You can view my changes here:

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

________________________________
From: Charles Oliver Nutter <headius@headius.com>
To: ruby-talk ML <ruby-talk@ruby-lang.org>
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 Berger <djberg96@gmail.com> 
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! 
http://downloads.yahoo.com/in/internetexplorer/

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] http://github.com/bpmcd/win32ole

2010/3/11, Aaron Patterson <aaron@tenderlovemaking.com>:
> On Thu, Mar 11, 2010 at 12:56:31AM +0900, wanabe wrote:
.. snip..
>> 2. test/dl/test_dl2.rb cause SEGV
>>    This is critical.
>>
>> 3. 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?