[erlang-questions] SWIG and Erlang?

[Michael Truog]

John Hughes wrote:
> Every now and then someone comments that an Erlang back-end for SWIG would 
> be nice, but there doesn't seem to be anything available. Just wondering if 
> anyone is sitting on a prototype, or just has looked hard at the problem of 
> creating one?
>   
I know that many people use SWIG. However, for fun, I created a way of 
making Erlang->C/C++ bindings using macros. It just seemed like a 
no-nonsense way to learn more about the details of port drivers and 
ports. Also, the compile time dependency is Boost instead of SWIG. The 
bindings then use C++ instead of C. Otherwise, the code you generate 
should be easier to customize. The code is called the "Generic Erlang 
Port [Driver]" and version 0.6 can be found here:
http://forum.trapexit.org/viewtopic.php?p=44406#44406

I can look at doing the same thing for SWIG. However, I was hoping for 
feedback as to whether the generated port driver code has any problems 
anyone can point out that relate to the Erlang code in 
test_bindings.erl. I have read that production quality linked in port 
drivers must use monitors and I don't understand why, if only one 
process manages the port driver. I also am wondering if outputv() can 
always be more efficient than control(), command(), or output() (from 
the driver_entry struct), since I haven't seen if ErlIOVec is allocated 
with a char buffer passed to one of the other functions mentioned. I 
also am using native endianess because I don't see a good reason to 
always use big endian, if the managing process is always on the same 
host as the port/port_driver. If there is a better pattern for sending 
to the port from many separate processes and receiving from the owner in 
an efficient way that is less synchronous, I would like to know. Any 
thoughts would be appreciated.
> John H 
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
>   
Thanks,
Michael