3 ms·

I've used the Racket FFI for some important tasks, and it's very easy to use. However, it's not as fully baked as the Python one (I've found bugs due to GC inte

I've used the Racket FFI for some important tasks, and it's very easy to use. However, it's not as fully baked as the Python one (I've found bugs due to GC interactions) and it's weirdly slow (a few too many levels of wrapping). That said, I still use Racket extensively and enjoy it.

neilv 7y ago
You found bugs in the FFI mechanism itself, or in FFI bindings that someone had written for a particular library?
- pavpanchekha 7y ago
  In the interaction between FFI, GC, and hash tables, so yes, in the FFI itself, not in particular bindings: https://github.com/racket/racket/issues/2702 https://github.com/racket/racket/issues/2702 https://github.com/racket/racket/issues/2263 https://github.com/racket/racket/issues/2263 There were workarounds (in Racket you can instruct the GC not to move your FFI objects) and I believe the underlying issues have been fixed. I must add that I got immediate and comprehensive support from the core developers, who not only fixed the bug but also suggested the workaround (so I could continue to support all our target versions of Racket).
  - neilv 7y ago
    Thank you for your great bug report on this, and I'm glad to see it was in good hands.
yomly 7y ago
This is the write up I was looking for as this is the use case I've had in mind for Racket of late after reading Felleisen's LOP paper. Would love to know more about your experiences with doing Racket FFI. How hard were the bugs around GC to discover and workaround? What were you building in Racket?
- pavpanchekha 7y ago
  See my responses to a sibling comment for Github bug reports. I had a great experience with them: very fast triage and fixes, plus a lot of help developing a workaround so we could target a range of Racket versions. (Distros still ship some old versions!) These bugs were found while working on Herbie <http://herbie.uwplse.org/> http://herbie.uwplse.org/>. We use the FFI to bind to your machine's math libraries so we can properly evaluate how accurate a floating-point expression is on your machine.

neilv 7y ago

You found bugs in the FFI mechanism itself, or in FFI bindings that someone had written for a particular library?

pavpanchekha 7y ago
In the interaction between FFI, GC, and hash tables, so yes, in the FFI itself, not in particular bindings: https://github.com/racket/racket/issues/2702 https://github.com/racket/racket/issues/2702 https://github.com/racket/racket/issues/2263 https://github.com/racket/racket/issues/2263 There were workarounds (in Racket you can instruct the GC not to move your FFI objects) and I believe the underlying issues have been fixed. I must add that I got immediate and comprehensive support from the core developers, who not only fixed the bug but also suggested the workaround (so I could continue to support all our target versions of Racket).
- neilv 7y ago
  Thank you for your great bug report on this, and I'm glad to see it was in good hands.

yomly 7y ago

This is the write up I was looking for as this is the use case I've had in mind for Racket of late after reading Felleisen's LOP paper. Would love to know more about your experiences with doing Racket FFI. How hard were the bugs around GC to discover and workaround? What were you building in Racket?

pavpanchekha 7y ago
See my responses to a sibling comment for Github bug reports. I had a great experience with them: very fast triage and fixes, plus a lot of help developing a workaround so we could target a range of Racket versions. (Distros still ship some old versions!) These bugs were found while working on Herbie <http://herbie.uwplse.org/> http://herbie.uwplse.org/>. We use the FFI to bind to your machine's math libraries so we can properly evaluate how accurate a floating-point expression is on your machine.