gmane.comp.lang.ruby.ffi

Re: how to execute a pointer?

Wayne Meissner — 2013-06-01T06:35:12

You should be able to just declare the return type of the function to be an 
appropriate callback type.

e.g.
  attach_function :function_that_returns_function, [ ], callback([], :int)

fptr = function_that_returns_function()
result = fptr.call()

Or, you can wrap it up in a FFI::Function - 
see http://ffi.github.io/api/FFI/Function.html

e.g.
ptr = function_that_returns_pointer
fptr = FFI::Function.new(:int, [ ])
result = fptr.call()


On Wednesday, 29 May 2013 06:29:02 UTC+10, Jose Donizetti wrote:

Re: libnfc example troubles

Wayne Meissner — 2013-06-01T06:29:08

Try using Struct.by_value for the NfcLibrary::NfcModulation paramter 
to nfc_initiator_select_passive_target.
e.g.
attach_function :nfc_initiator_select_passive_target, [:pointer, 
NfcLibrary::NfcModulation.by_value, :pointer, :size_t, :pointer], :int

On Monday, 27 May 2013 06:09:44 UTC+10, Anders Konring Olesen wrote:

how to execute a pointer?

Jose Donizetti — 2013-05-28T20:29:02

Hi all, 

I mapped a function in ruby which returns a pointer to another function. 
How can I execute this pointer?

Thanks,
Jose.

libnfc example troubles

Anders Konring Olesen — 2013-05-26T20:09:44

Hi everyone. 

i need some backup to get going with my project trying to make ruby-wrapper 
for libnfc:

Test program(trying to simulate this<http://nfc-tools.org/index.php?title=Libnfc:quick_start_example> c 
example:):
 

require 'ffi'
load '~/Documents/nfc/nfc_library.rb'

device_ptr = FFI::MemoryPointer.new :pointer
context_ptr = FFI::MemoryPointer.new :pointer
target = NfcLibrary::NfcTarget.new

NfcLibrary::nfc_init(context_ptr)
device_ptr = NfcLibrary::nfc_open(context_ptr.read_pointer, nil)


NfcLibrary::nfc_initiator_init(device_ptr)
    
nmMifare = NfcLibrary::NfcModulation.new
nmMifare[:nmt] = :NMT_ISO14443A
nmMifare[:nbr] = :NBR_106

device_name = NfcLibrary::nfc_device_get_name(device_ptr)

puts device_name

NfcLibrary::nfc_initiator_select_passive_target(device_ptr, nmMifare, nil, 
0, target.pointer)


Output of testprogram(connecting to nfc interface but will call the last 
method with succes) :

ACS / ACR122U PICC Interface
-2


My FFI library:

module NfcLibrary
  extend FFI::Library
  ffi_li

Re: Cross-platform C code packaged in a gem

Jeremy Voorhis — 2013-04-18T20:48:58

Hi Hugo,

Ruby-LLVM does exactly this for the support library. We let rubygems build
the extension by invoking rake. Here are the relevant bits.

   - declare the extension:
   https://github.com/ruby-llvm/ruby-llvm/blob/master/ruby-llvm.gemspec#L22
   - define Rakefile for build process:
   https://github.com/ruby-llvm/ruby-llvm/blob/master/ext/ruby-llvm-support/Rakefile
   - loading the library by its relative path:
   https://github.com/ruby-llvm/ruby-llvm/blob/master/lib/llvm/support.rb#L15-L17

HTH,


On Thu, Apr 18, 2013 at 1:01 PM, Hugo Frappier <hugo-tuUNRQWA2OXQT0dZR+AlfA< at >public.gmane.org> wrote:

Cross-platform C code packaged in a gem

Hugo Frappier — 2013-04-18T20:01:50

Was anyone able to package cross-platform C code in a gem and loading
it with FFI?

I'm having a hard time compiling and linking the code (especially on
Windows) using extconf.rb.  I looked at all the github FFI projects
(the one listed on the Wiki) and none of them seems to be doing
something similar.

Thanks

Re: I wrote on advanced FFI usage

Kim Burgestrand — 2013-03-30T21:19:01

Hehe, yes. I wanted to see if I could run some MRI-working code (spotify gem + OpenAL) on JRuby,
and in doing that I ran into a few issues. The reason for doing that was because I became curious as

I was writing the article. I’m happy to say I managed to get it running on JRuby, streaming music from
the spotify API, bound with FFI, into the OpenAL API, bound with FFI. Really cool!
Yes. I have not yet found a blog post that explains the basics better than the wiki though. The wiki is
a nice collection of information, and it was pretty much my bible when I started with FFI, together with


the FFI source code. I believe there is place for yet another article on FFI, aimed at people beginning
with FFI for the first time.

This is a really nice way of using FFI, and I actually do this throughout all one of my FFI gems. The
spotify library in particular uses a reference counting mechanism, where some functions return pointers
that should have their reference increased, and I do that automatically with a simila

Re: I wrote on advanced FFI usage

Wayne Meissner — 2013-03-29T23:53:48

There are a few other tricks you can do:

1) Use as a result filter to automagically turn errno values into 
exceptions (not that I recommend exceptions-as-flow-control)
e.g.
    module PosixResult
      extend FFI::DataConverter
      native_type FFI::Type::INT

      def self.from_native(value, ctx)
        if value != -1
          value
        else
          raise SystemCallError.new("native error", FFI.errno)
        end
      end
    end

    attach_function :some_function_that_can_fail, [  ], PosixResult

2) Automagically convert and free pointer results.  
e.g. lets say you have a function that returns an allocated C string, and 
you need to free it yourself.  You /could/ use an AutoPointer, but to be 
kinder to the GC, you want to copy the string immediately to a GC managed 
object, and free the underlying C string.

    class AllocatedStringResult
      extend FFI::DataConverter
      native_type FFI::Type::POINTER

      def self.from_native(val, ctx)
        if val.null?
          nil
        els

Re: I wrote on advanced FFI usage

postmodern — 2013-03-29T22:44:29

Thank you for putting this together. I was meaning to write a more
details overview of FFI; all of the other blog posts only cover loading
a library and attaching some functions. I never knew about by_ref and
extending FFI::Pointer is brilliant.

On 03/28/2013 11:34 AM, Kim Burgestrand wrote:

Re: I wrote on advanced FFI usage

Wayne Meissner — 2013-03-29T06:15:09

Thats pretty cool!

(so now I know the story behind all those issues you raised against JRuby)

On Friday, 29 March 2013 04:34:14 UTC+10, Kim Burgestrand wrote:

I wrote on advanced FFI usage

Kim Burgestrand — 2013-03-28T18:34:14

Might be interesting to you since you are subscribed to the FFI mailing
list. The article is here:
http://www.elabs.se/blog/61-advanced-topics-in-ruby-ffi

If you have any reactions to what I've written I'd love to hear them.

Re: Re: AutoPointer on an array of structs corrupts the structs values

Maurizio De Santis — 2013-03-27T00:08:36

It works fine, thank you!

--

Maurizio De Santis


2013/3/26 Wayne Meissner <wmeissner-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

Re: AutoPointer on an array of structs corrupts the structs values

Wayne Meissner — 2013-03-26T13:53:15

Its not exactly corrupting the memory, it is just that when you access the 
second, etc element of the array, it is stepping by 1 byte, instead of 
GTop::MemoryMapEntry.size.

Its a bug, but since it is broken on both MRI and JRuby, you'll need to do 
a work-around.

Instead of this:
    ssi = GTop::MemoryMapEntry.new(ss_pointer[i])

use:
    ssi = GTop::MemoryMapEntry.new(ss_pointer + (i * 
GTop::MemoryMapEntry.size))


On Tuesday, 26 March 2013 10:23:47 UTC+10, Maurizio De Santis wrote:

AutoPointer on an array of structs corrupts the structs values

Maurizio De Santis — 2013-03-26T00:23:47

Hello,

I have an issue using FFI::AutoPointer on an array of structs.

This is the C function declaration:

glibtop_map_entry <https://developer.gnome.org/libgtop/stable/libgtop-procmap.html#glibtop-map-entry> * glibtop_get_proc_map (glibtop_proc_map <https://developer.gnome.org/libgtop/stable/libgtop-procmap.html#glibtop-proc-map> *buf, pid_t pid);

The returned value is an array of glibtop_map_entry structs should be freed using g_free .


If I declare the pointer to the array of structs entries using FFI::Pointer, 
everything works fine, and the output of the structs is correct:


s = GTop::ProcessMemoryMaps.new
addr = GTop.process_memory_maps(s, Process.pid)
ss_pointer = FFI::Pointer.new(GTop::MemoryMapEntry, addr)
s[:number].times do |i|
  ssi = GTop::MemoryMapEntry.new(ss_pointer[i])
  p Hash[ ssi.members.map { |m| [ m, 
ssi[m].is_a?(FFI::StructLayout::CharArray) ? 
ssi[m].to_s.force_encoding('UTF-8') : ssi[m] ] } ]
end
GTop::GLib.g_free ss_pointer


This is a part the ouput:


{:flags=>8191, :start=>

Re: Wiki list of projects using FFI

Wayne Meissner — 2013-03-21T09:29:31

Fixed that one, thanks.

The wiki used to be open, but there was some vandalism (which was fixed by 
someone else, as a wiki should be), and since there weren't a lot of 
modifications happening (~1 per month), I turned off write access.

On Thursday, 21 March 2013 17:47:04 UTC+10, Kim Burgestrand wrote:

Wiki list of projects using FFI

Kim Burgestrand — 2013-03-21T07:47:04

See here: https://github.com/ffi/ffi/wiki/Projects-Using-FFI

The libspotify-ruby project has moved 
to https://github.com/Burgestrand/spotify and is now just called `spotify`. 
Still heavily using FFI.

I’d update the list myself, but it appears to be closed from modification 
from non-collaborators.

Re: Passing a struct by value, and typedef

Maurizio De Santis — 2013-03-12T01:01:20

uhm, libglib-2.0.so ... I forgot the dash!!!! >.< thank you!!!

Ok, now I am at a good point: I think I'm managing an array of ints
correctly, included a custom free! \o/
Could you please confirm it? I'm interested above all at the part of the
pointer, if I managed them correctly, and if I used AutoPointer correctly
(the :g_free part included). It should be correct, but maybe you have some
suggestions.

This is glibtop_get_proclist:

unsigned * glibtop_get_proclist (glibtop_proclist *buf, gint64 which,
gint64 arg)


glibtop_proclist is a struct, while the returned value is an array of uint
of glibtop_proclist.number length, and it should be freed with g_free .

Here is my code (if you want you can see the full library at
https://github.com/ProGNOMmers/gtop ):

module GTop
  extend FFI::Library
  ffi_lib 'libgtop-2.0'
  typedef :int64,  :gint64
  typedef :uint64, :guint64
  typedef :ulong,  :uintptr_t
  attach_function :process_list, :glibtop_get_proclist, [:pointer, :gint64,
:gint64], :uintptr_t

  module GL

Re: Passing a struct by value, and typedef

Wayne Meissner — 2013-03-11T08:20:40

Isn't it libglib-2.0.so ?

i.e. try:

  ffi_lib 'glib-2.0'

If you just want to try and see if a library can be found by FFI, use this:

  ruby -rffi -e 'FFI::DynamicLibrary.open("libglib-2.0.so", 
FFI::DynamicLibrary::RTLD_LAZY | FFI::DynamicLibrary::RTLD_LOCAL)'


As for the pointer result, NULL is handled fine - just use Pointer#null? to 
check if the return value is NULL.


On Monday, 11 March 2013 02:50:27 UTC+10, Maurizio De Santis wrote:

Re: Passing a struct by value, and typedef

Maurizio De Santis — 2013-03-10T16:50:27

Thank you, the porting is going well; if you want you can see the progress
at https://github.com/ProGNOMmers/gtop .

Now I have some troubles: I need to use g_free from glib, so I tried to
wrap it:

require 'gtop'

module GTop
  module GLib
    extend FFI::Library
    ffi_lib 'libglib2.0'

    typedef :pointer, :gpointer

    attach_function :g_free, [:gpointer], :void
  end
end

On my pc libglib2.0.so is located inside /usr/lib/x86_64-linux-gnu/ , which
should be found since it is inside the ld paths, which on my machine are

# Multiarch support
/lib/i386-linux-gnu
/usr/lib/i386-linux-gnu
/lib/i686-linux-gnu
/usr/lib/i686-linux-gnu
# libc default configuration
/usr/local/lib
/usr/lib/nvidia-settings
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/mesa

but I get a LoadError:

Could not open library 'libglib2.0': libglib2.0: cannot open shared object
file: No such file or directory.
Could not open library 'libglib2.0.so': libglib2.0.so: cannot open shared
object

Re: Re: XNI and FFI summary?

Wayne Meissner — 2013-03-06T01:57:06

Performance will depend on the VM.  On JRuby, most ruby->C calls will be as 
fast as hand-written JNI - FFI in jruby-1.7.x is with invoke dynamic when 
calling functions with primitives - i.e. int, long, float, pointer, etc.  I 
just need to port that work over to XNI.

In general though, performance will be more limited to how fast the VM can 
execute ruby code (i.e. jruby == fast), and how much work is done on either 
side of the ruby <-> C boundary.

And, whilst performance is a goal, it is more important to make it easy for 
both people to write code, and for VM implementers to implement.  A 
JNI-style interface is very easy for VMs to implement, but once you get 
into managing object references, it is nasty for humans.  On the other 
hand, the MRI C api is easier(?) for humans, but murderously difficult for 
VM implementers - thats why we're kicking it out of JRuby.


On Wednesday, 6 March 2013 08:37:04 UTC+10, Jeremy wrote:

Re: Re: XNI and FFI summary?

Jon — 2013-03-05T23:38:00

I've always liked how you've split the C parsing between developer and computer for FFI, and I like what you're saying about XNI.

Don't let anyone sell you on changing to the C copy-n-paste style ;)




Jon

---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: < at >jonforums