[erlang-questions] What should go into the FFI chapter of the book
Tue Dec 11 14:34:43 CET 2007
I agree with you on everything you wrote below. This is just the kind
of feedback I love.
I have also been told that there's work on WxWidgets as a linked-in
My focus is to both finish the book quickly and to keep it
informative. This requires a compromise and I suspect that the book
will not look like anything I envisioned in the beginning.
It may well be that it's better to either describe the WxWidgets
driver than to write a Cocoa bridge for the book. Describing existing
code takes far less time than writing significant new code bases.
WxWidgets is also cross-platform so Windows and Linux users of Erlang
could run it, unlike the Cocoa bridge.
In the end it may well suffice for me to just elaborate on what you
listed below. There's more than enough content, complexity and value
in doing this. I think I'll try to start down this path and see what
On Dec 11, 2007, at 1:04 PM, Serge Aleynikov wrote:
> I think it would be useful to cover link-in drivers from the
> following perspective:
> 1. C types: ErlDrvData, ErlDrvBinary, ErlIOVec, etc. and how to
> marshal terms to Erlang using these primitives.
> 2. Taking advantage of driver queues.
> 3. Monitoring health of Pids from C, and performing driver shutdown
> or resource cleanup when a Pid dies.
> 4. Highlighting differences between output methods (output, output2,
> 5. Handling events from other sources (driver_select, ready_input,
> ready_output and event callbacks) in the driver.
> 6. When to use ei and when not to.
> At least there is currently no in-depth illustrated coverage of
> these subjects and one has to go through a broad trial-and-error
> cycle (at least I know I did :-( ) that keeps the learning curve
> pretty steep before he/she learns these concepts and the mysterious
> veil of driver complexity dissolves.
More information about the erlang-questions