Radosław Bułat wrote:
Where can I file an issue? I have trouble to build in with ruby1.9 on 64bit.
Hop on the ruby-ffi project mailing lists, and I guess you can file a bug in the tracker there too:
http://kenai.com/projects/ruby-ffi
- Charlie
Charles Oliver Nutter wrote:
Charles Oliver Nutter wrote:
We (JRuby and Rubinius contributors) designed in the ability to specify calling convention for a given library bound through FFI. Largely this was needed to support Win32's stdcall, but if Linux/PPC has a different convention and libffi supports it, then FFi will too (though we may have to add it to the list of accepted conventions).
I'll check on the syntax we're supporting and get back to ya.
In the body of the module you're binding:
ffi_convention :stdcall # :default is for normal C convention
We could add whatever convention Linux/PPC needs.
Or, duh, have FFI use the appropriate default convention on the target platform. Either way, it should be simple to deal with.
- Charlie
Sean O'Halpin wrote:
Maybe I wasn't clear - what you're proposing is exactly what I
intended to convey. Thin wrapper in a single gem. Any abstractions
should be separate gems.
Perfect then 
Tom Enebo actually suggested just naming them the library name, as in libncurses, libtommath, whatever.
- Charlie
Clifford Heath wrote:
Charles Oliver Nutter wrote:
There's no support at the moment for callbacks-in-structs, but it's just a bug report (and ideally a patch) away
http://kenai.com/projects/ruby-ffiThanks Charlie. I registered at Kenai.com and can log in there
though only by emaill address, username login doesn't work), but
the Bugzilla instalce doesn't recognise the login details at all.
I'll try again later, in case there's a delayed processing step.
I can't see any separate registration for Bugzilla...
I'll make sure the Kenai guys know about the problem. Thanks for giving it a shot. If nothing else, email the dev mailing list.
- Charlie
Speaking of that Kenai thing, am I the only one who think it's a *major* pain in the derrière to use ?
···
On 11 nov. 08, at 06:27, Clifford Heath wrote:
Thanks Charlie. I registered at Kenai.com and can log in there
though only by emaill address, username login doesn't work)
--
Luc Heinrich - luc@honk-honk.com
Clifford Heath wrote:
Just some random thoughts, anyhow. I might have time to contribute code to this
effort in December.
Sounds like you've dealt with a lot of this stuff before. Can you re-post this to the main FFI mailing list?
- Charlie
Thanks Charlie, but I have already my own library which does more than Ruby-FFI
(typelib.sf.net and typelib.sf.net/html/ruby) so I'll probably be using libffi
directly.
Sylvain
···
On Tue, Nov 04, 2008 at 04:54:35AM +0900, Charles Oliver Nutter wrote:
Charles Oliver Nutter wrote:
Charles Oliver Nutter wrote:
We (JRuby and Rubinius contributors) designed in the ability to
specify calling convention for a given library bound through FFI.
Largely this was needed to support Win32's stdcall, but if Linux/PPC
has a different convention and libffi supports it, then FFi will too
(though we may have to add it to the list of accepted conventions).I'll check on the syntax we're supporting and get back to ya.
In the body of the module you're binding:
ffi_convention :stdcall # :default is for normal C convention
We could add whatever convention Linux/PPC needs.
Or, duh, have FFI use the appropriate default convention on the target
platform. Either way, it should be simple to deal with.
That's a little *nix-centric, no? If we had everything under ffi/
you'd be able to find everything in one place (e.g. easier to find
examples to copy from, easier to set up conventions for where to put
shared structs, constants, etc.). As for OS-specific libs, there could
be ffi/win32/ ffi/unix, where appropriate.
It would be useful to have conventions on how to implement thin layer
ffis (e.g. how to handle return values in *ptrs, how to implement
functons defined as macros, namespacing constants, etc.). This would
help POLS. Also, guidelines on how to portably implement layers for
32-bit/64-bit and endian-ness would be handy (I know I'd like some
tips).
While there is no general solution to converting header files,
projects such as SWIG have shown that you can get a lot done
automatically. It would be worthwhile to work on tools to help with
this - even an 80% solution removes a lot of the donkey work (as I'm
finding with my ncurses port).
My general opinion is that the more boring, mechanical, choice-free
and thoughtless we can make this work, the easier it will be to do and
so the more likely to get done.
Your cross-implementation FFI initiative is very welcome - it's a
liberating move. Now we can get on with the mindless (but worthy)
drudgery
Regards,
Sean
···
On Wed, Nov 5, 2008 at 4:34 AM, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
Tom Enebo actually suggested just naming them the library name, as in
libncurses, libtommath, whatever.
Nop, count me on that too.
Tried to use bugzilla to provide some patches, and is a no go, only
fall back to mailing list seems the alternative.
···
On Nov 11, 5:53 am, Luc Heinrich <l...@honk-honk.com> wrote:
On 11 nov. 08, at 06:27, Clifford Heath wrote:
> Thanks Charlie. I registered at Kenai.com and can log in there
> though only by emaill address, username login doesn't work)Speaking of that Kenai thing, am I the only one who think it's a
*major* pain in the derrière to use ?
--
Luis Lavena
Sylvain Joyeux wrote:
···
On Tue, Nov 04, 2008 at 04:54:35AM +0900, Charles Oliver Nutter wrote:
Charles Oliver Nutter wrote:
Charles Oliver Nutter wrote:
We (JRuby and Rubinius contributors) designed in the ability to specify calling convention for a given library bound through FFI. Largely this was needed to support Win32's stdcall, but if Linux/PPC has a different convention and libffi supports it, then FFi will too (though we may have to add it to the list of accepted conventions).
I'll check on the syntax we're supporting and get back to ya.
In the body of the module you're binding:
ffi_convention :stdcall # :default is for normal C convention
We could add whatever convention Linux/PPC needs.
Or, duh, have FFI use the appropriate default convention on the target platform. Either way, it should be simple to deal with.
Thanks Charlie, but I have already my own library which does more than Ruby-FFI
(typelib.sf.net and typelib.sf.net/html/ruby) so I'll probably be using libffi
directly.
Is your library compatible with JRuby? I think that's a key point for Ruby FFI.
- Charlie
Sean O'halpin wrote:
···
On Wed, Nov 5, 2008 at 4:34 AM, Charles Oliver Nutter > <charles.nutter@sun.com> wrote:
automatically. It would be worthwhile to work on tools to help with
this - even an 80% solution removes a lot of the donkey work (as I'm
finding with my ncurses port).Regards,
Sean
Eagerly awaiting your ncurses port...
Is it possible for you to document the procedure, how you go about doing
it, so one can follow that for another port, rather than be totally
lost.
--
Posted via http://www.ruby-forum.com/\.
It is not -- it is mainly C++ -- but given that most of the functionality is
written in C++ *and* I use that C++ interface in other C++ programs, moving to
Ruby-FFI is not practical for me. So ...
Sylvain
···
On Tue, Nov 04, 2008 at 06:45:27AM +0900, Charles Oliver Nutter wrote:
Sylvain Joyeux wrote:
On Tue, Nov 04, 2008 at 04:54:35AM +0900, Charles Oliver Nutter wrote:
Charles Oliver Nutter wrote:
Charles Oliver Nutter wrote:
We (JRuby and Rubinius contributors) designed in the ability to
specify calling convention for a given library bound through FFI.
Largely this was needed to support Win32's stdcall, but if
Linux/PPC has a different convention and libffi supports it,
then FFi will too (though we may have to add it to the list of
accepted conventions).I'll check on the syntax we're supporting and get back to ya.
In the body of the module you're binding:
ffi_convention :stdcall # :default is for normal C convention
We could add whatever convention Linux/PPC needs.
Or, duh, have FFI use the appropriate default convention on the
target platform. Either way, it should be simple to deal with.Thanks Charlie, but I have already my own library which does more than Ruby-FFI
(typelib.sf.net and typelib.sf.net/html/ruby) so I'll probably be using libffi
directly.Is your library compatible with JRuby? I think that's a key point for
Ruby FFI.
Eagerly awaiting your ncurses port...
I'm aiming to get a first cut out this week (just the very basics) to
get things moving, but it will take a while to get it all done,
especially the fiddly bits. I'm going to concentrate on the core
ncurses functionality. I'm not interested in panels or forms (better
done in Ruby IMHO).
Is it possible for you to document the procedure, how you go about doing
it, so one can follow that for another port, rather than be totally
lost.
Sure, as long as you don't mind long-winded stream of consciousness
Regards,
Sean
···
On Wed, Nov 5, 2008 at 5:11 PM, Nit Khair <sentinel.2001@gmx.com> wrote:
Hi,
I've just uploaded the ~very raw~ initial port of the core ncurses lib
to ruby-ffi. You can find it at:
git://github.com/seanohalpin/ffi-ncurses.git
This works with ffi-0.0.2 (which I got from the kenai project) - 0.0.1
left out typedefs for short ints.
To use:
require 'rubygems'
require 'ffi'
require 'ffi-ncurses
notes:
- example.rb shows basic usage
- to access stdscr, use the return value from NCurses.initscr
- I have not implemented any variadic functions (not supported by libffi AFAIK)
- there's also a wrapper for libdl called dlfcn.rb
- there's an experimental script (ex01-ffi-dl-stdscr.rb) which uses
dlfcn.rb to access the exported variables from the ncurses shared lib
(stdscr, curscr, etc.). This also shows how to access values returned
through pointers (see NCurses.wattr_get).
There are some rambling notes on implementation in
notes-on-ffi-curses.org. I'll tidy these up when I get some spare
time. Basically, I wrote a script
(generate-ffi-ncurses-function-signatures.rb) that mechanically
recovered the function signatures from the ncurses.h on my machine and
added some constants. I wasted a lot of time figuring out how to
access exported variables.
I've only just done a final test on OS X Tiger - haven't checked Linux
yet (should work but...)
I have not set up a project for this yet so please send any bug
reports, questions, etc. directly to me for the moment.
There are no tests - I wonder if anyone has any ideas how best to
write specs/tests for checking this kind of output?
Regards,
Sean
···
On Wed, Nov 5, 2008 at 5:11 PM, Nit Khair <sentinel.2001@gmx.com> wrote:
Eagerly awaiting your ncurses port...
Is it possible for you to document the procedure, how you go about doing
it, so one can follow that for another port, rather than be totally
lost.
Sean O'Halpin wrote:
···
On Wed, Nov 5, 2008 at 5:11 PM, Nit Khair <sentinel.2001@gmx.com> wrote:
Eagerly awaiting your ncurses port...
I'm aiming to get a first cut out this week (just the very basics) to
get things moving, but it will take a while to get it all done,
especially the fiddly bits. I'm going to concentrate on the core
ncurses functionality. I'm not interested in panels or forms (better
done in Ruby IMHO).Is it possible for you to document the procedure, how you go about doing
it, so one can follow that for another port, rather than be totally
lost.Sure, as long as you don't mind long-winded stream of consciousness
Oh and please, please guys, update anything that's not well-documented here:
http://kenai.com/projects/ruby-ffi/pages/Home
It's wide open...let me know if you can't edit.
- Charlie
Sean O'halpin wrote:
I'm aiming to get a first cut out this week (just the very basics) to
get things moving, but it will take a while to get it all done,
especially the fiddly bits. I'm going to concentrate on the core
ncurses functionality. I'm not interested in panels or forms (better
done in Ruby IMHO).
I am using panels and forms - *heavily*. I understand your last
statement to mean implementing p & f's in ruby itself, avoiding what
ncurses provides. Has anyone actually done that -- i would like to see
it and see how its better and if it can be reused.
···
--
Posted via http://www.ruby-forum.com/\.
I tried to run all examples but no one worked. It prints tons of:
/usr/lib/ruby/gems/1.8/gems/ffi-0.1.1/lib/ffi/ffi.rb:232: warning:
instance variable @ffi_convention not initialized
and last line:
example-printw-variadic.rb:7: undefined method `printw' for
NCurses:Module (NoMethodError)
Sean O'Halpin wrote:
I've just uploaded the ~very raw~ initial port of the core ncurses lib
to ruby-ffi. You can find it at:git://github.com/seanohalpin/ffi-ncurses.git
This works with ffi-0.0.2 (which I got from the kenai project) - 0.0.1
left out typedefs for short ints.
Very cool The early examples worked fine in JRuby but this one seems to blow up in MemoryPointer. I'll make sure wmeissner knows about it.
I know he's taken a step back from adding new features in 0.2.0 to make sure both JRuby and ruby-ffi are compatible again. Hopefully 0.2.0 will be out soon along with JRuby 1.1.6.
- Charlie
Oh and please, please guys, update anything that's not well-documented
here:http://kenai.com/projects/ruby-ffi/pages/Home
It's wide open...let me know if you can't edit.
- Charlie
This blog posting has the most information I have seen so far on FFI and
ruby
Hi Radosław,
my wrapper requires ffi-0.2.0 which you'll need to install from
source. You can get the source from the kenai project site at
http://kenai.com/projects/ruby-ffi (though you'll need to install
mercurial to get it).
The example ex01-ffi-dl-stdscr.rb does not currently work under Linux
- I'm looking into that. The only platform I know it works on is Mac
OS X Tiger. The other examples work on both OS X and Linux (with
ffi-0.2.0).
Regards,
Sean
···
2008/11/18 Radosław Bułat <radek.bulat@gmail.com>:
I tried to run all examples but no one worked. It prints tons of:
/usr/lib/ruby/gems/1.8/gems/ffi-0.1.1/lib/ffi/ffi.rb:232: warning:
instance variable @ffi_convention not initializedand last line:
example-printw-variadic.rb:7: undefined method `printw' for
NCurses:Module (NoMethodError)--
PozdrawiamRadosław Bułat
http://radarek.jogger.pl - mój blog