On Thu, Mar 31, 2016 at 10:23 PM, Óscar Fuentes wrote:
> consequences.) How objects created by the module system interact with
> garbage collection is an start.
Every emacs_value allocated inside a Lisp-exposed function becomes
invalid when control of the function ends (when it exits) unless you
return that value or you mark it global with the the
env->make_global_ref() API call.
As I was googling for a browseable emacs git repo to look quickly at
emacs-module.h I've noticed that Syohei Yoshida (cc'ed) has figured a
lot of things out by himself (kudos to you!) and has already made some
simple and not-so-simple modules:
- dead simple module that exposes an ioctl syscall to Lisp
- json parser/encoder
this one is interesting because he has done some benchmarks!
- libGeoIP binding
- libbarcode binding
- libmemcached binding
- libyaml binding
- libqrencode binding
- embedded Lua interpreter
- embedded Ruby interpreter
- wrapper that lets you implement modules in Nim
I've looked briefly at most of them and I think they are good
examples. Especially how he only implements low-level functionality of
package xyz in a xyz-core module which is exactly how I envisioned it.
- Tom Tromey has also made a binding on libffi which means you can
call C stuff from Lisp without writing a module.
It seems the japanese-speaking Emacs community has picked up on the
modules feature quite fast. I found several article/blog about it. Too
bad I can't read it, it looks interesting :)
- article on how the emacs-eject module was done
- article on the module feature with *benchmarks* and side-by-side
code comparison. Very cool!
Syohei, I really like what you did and I would be interested in your
feedback on what could be improved, what should we add&optimize in the
module API, etc.