Whilst I'm not a big fan of rdoc, any doc would be better than none.
At the very least, a lot of C functions need rdoc turned off for them.

I did start using yardoc to build documentation for FFI, in a
different tree; if you want to look at that, its over at
http://github.com/ffi/ffi-yardoc

I quite like yardoc, and I want the API doc to be implementation
independent, which rdoc generated from a C extension is kind of not -
it seems like the the C implementation details leak thru.



On 12 May 2010 10:18, Chuck Remes <cremes.devlist@mac.com> wrote:

> Way ahead of you, Wayne. You may recognize some of the text on that page...
>
> BTW, I would like to add some rdoc to the classes but I don't know how to do that for methods that are part of the C extension and have no ruby equivalent. I'll look into the rdoc syntax and see if there's a way I can achieve that. Any problem with that?
>
> cr
>
> On May 11, 2010, at 6:09 PM, Wayne Meissner wrote:
>

>> Well, now that you are wise in the way of pointers, please go ahead
>> and fix the damn page :-)
>>
>> If something on the wiki doesn't look right, fix it - its a wiki after
>> all.  (and if your changes aren't right, in theory someone else will
>> rip your stuff out ... ad infinitum).
>>
>>
>>
>> On 12 May 2010 08:59, Chuck Remes <cremes.devlist@mac.com> wrote:

>>> I'll make the modifications for #1 and #2.
>>>
>>> The text at the top (#3) was put there by someone else. I just added to the page. It didn't look right to me, but it's been there for a while so I didn't touch it. :)
>>>
>>> cr
>>>
>>> On May 11, 2010, at 5:33 PM, Wayne Meissner wrote:
>>>

>>>> It looks pretty good.
>>>>
>>>> A couple of nits:
>>>>
>>>> 1) The LibC module can just use:
>>>>   ffi_lib FFI::Library::LIBC
>>>>
>>>> ffi knows that means "whatever the libc on this system is supposed to
>>>> be", since its a pretty common library people want to map in, and the
>>>> name differs across platforms (e.g. on linux, its libc.so.6, macos is
>>>> libc.dylib, windows is msvcrt.dll, aix is something weird, etc.
>>>>
>>>> 2) The first arg to MemoryPointer.new can in fact be either a symbol,
>>>> or anything that responds to #size.
>>>> e.g.
>>>>  class S < FFI::Struct
>>>>    layout :i, :int
>>>>  end
>>>>  FFI::MemoryPointer.new(S, 1, false)  # Will allocate space for one
>>>> instance of S, without clearing the memory first
>>>>
>>>> 3) The bit at the top about copying pointers is ... confusing.  A
>>>> pointer is merely a Fixnum that holds a native memory address, so
>>>> there is no need to do anything special to "copy" a pointer - just
>>>> assign it to a like you would any other Fixnum.  Think of "Pointer" as
>>>> "fixnum with methods to read/write the native memory at the address".
>>>>
>>>> The example:
>>>>
>>>> b = MemoryPointer.new(:pointer).write_pointer(some_pointer.read_pointer)
>>>>
>>>> Doesn't do what you think.  It reads a pointer from the memory
>>>> pointed-to by some_pointer, allocates a new chunk of memory, and
>>>> writes that pointer value into that memory - it doesn't copy the value
>>>> of some_pointer to a new pointer.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 12 May 2010 02:02, Chuck Remes <cremes.devlist@mac.com> wrote:

>>>>> I just wrote an update to the wiki page on pointers at http://wiki.github.com/ffi/ffi/pointers
>>>>>
>>>>> I'd appreciate it if someone more knowledgeable would check it over (the bottom section under the sub-heading) and verify that what I wrote is correct. It seems to be working for me but I've been wrong before! :)
>>>>>
>>>>> cr
>>>>>
>>>>>

>>>
>>>

>
>