Hello,
I brought up this subject on #clasp IRC, but thought I would move the discussion to the mailing list.
[IRC log: http://log.irc.tymoon.eu/freenode/clasp?around=2015-06-19T16:13:25&types... ]
I'm looking into wrapping a large C++ library with CL. The library is an implementation of Open Inventor, coin, which is a C++ scene graph library based on OpenGL. I think eventually it would be an interesting project to port Open Inventor to CL natively. However, at present what I want to do is call it from CL. (For those of you doing chemistry with Clasp, having Open Inventor as a library in Lisp could help integrate the visualization of molecules into your workflow.)
[Coin: https://en.wikipedia.org/wiki/Coin3D ]
Currently, Clasp provides a lot of what I need to wrap Open Inventor. However, I would like to automatically parse (a large number of) C++ header files and generate CL bindings without writing a lot of boilerplate. I think it would be good idea to support both the native method Clasp uses, as well as standard FFI(s). As a side effect it would be nice to be able to produce a generic C API from the C++. The SGI release of Open Inventor had such a C API, and its conventions are documented. Open Inventor might be good starting point to automate wrapper generation, because the interface uses a limited subset of C++ features, having been written in the '90s.
I looked into using SWIG ( www.swig.org ), which is a general purpose wrapper for C/C++. Although I have successfully used it for projects in the past, SWIG is somewhat opaque (to me). It would be a good source of concrete techniques for this project though.
I'm willing to contribute to Clasp to add this capability, but I had a few further questions before I jumped in:
1) Should we add this capability to the subproject clbind? Create a new subproject?
2) Should we make the tool modular, so we can add other native bindings? I don't think we should re-invent SWIG, but you never know.
3) Is there a contribution policy for Clasp? Do you have a copyright assignment form?
4) Is the Clasp project ready for some high level documentation or is it in flux? I am willing to write documentation as I learn the system. I prefer to do it in LaTex.
Thanks,
(o> ( ) --++--Andy
Hey Andrew,
(1) So SAL9000 is interested in implementing something like this (automated C++ groveling and FFI building) in Clasp as well and he’s made a lot of progress understanding how to use the Clang ASTMatcher and AST libraries that are exposed within Clasp. So you guys should talk.
(2) I think you could to a lot better than SWIG on the groveling side given that we have a C++/C/Objective C compiler. SWIG has had C++ support “under development” for 15 years.
(3) There is no contribution policy for Clasp. What should it be? Are there any good models we can copy? If you keep it as a separate project for now then maybe there are no immediate issues.
(4) It’s ready for documentation and the programmers interface to Clasp is not in so much flux. What’s in flux is the underlying implementation which I’m working very hard on to make faster. LaTeX is great.
I’m happy to provide support and training to get people up and running but I don’t have an enormous amount of time so doing things with Clasp will require people who are pretty self-sufficient.
Best,
.Chris.
On Jun 19, 2015, at 5:12 PM, Andrew Robin a_t_robin@yahoo.com wrote:
Hello,
I brought up this subject on #clasp IRC, but thought I would move the discussion to the mailing list.
[IRC log: http://log.irc.tymoon.eu/freenode/clasp?around=2015-06-19T16:13:25&types... ]
I'm looking into wrapping a large C++ library with CL. The library is an implementation of Open Inventor, coin, which is a C++ scene graph library based on OpenGL. I think eventually it would be an interesting project to port Open Inventor to CL natively. However, at present what I want to do is call it from CL. (For those of you doing chemistry with Clasp, having Open Inventor as a library in Lisp could help integrate the visualization of molecules into your workflow.)
[Coin: https://en.wikipedia.org/wiki/Coin3D ]
Currently, Clasp provides a lot of what I need to wrap Open Inventor. However, I would like to automatically parse (a large number of) C++ header files and generate CL bindings without writing a lot of boilerplate. I think it would be good idea to support both the native method Clasp uses, as well as standard FFI(s). As a side effect it would be nice to be able to produce a generic C API from the C++. The SGI release of Open Inventor had such a C API, and its conventions are documented. Open Inventor might be good starting point to automate wrapper generation, because the interface uses a limited subset of C++ features, having been written in the '90s.
I looked into using SWIG ( www.swig.org ), which is a general purpose wrapper for C/C++. Although I have successfully used it for projects in the past, SWIG is somewhat opaque (to me). It would be a good source of concrete techniques for this project though.
I'm willing to contribute to Clasp to add this capability, but I had a few further questions before I jumped in:
Should we add this capability to the subproject clbind? Create a new subproject?
Should we make the tool modular, so we can add other native bindings? I don't think we should re-invent SWIG, but you never know.
Is there a contribution policy for Clasp? Do you have a copyright assignment form?
Is the Clasp project ready for some high level documentation or is it in flux? I am willing to write documentation as I learn the system. I prefer to do it in LaTex.
Thanks,
(o> ( ) --++--Andy
On Tue, 23 Jun 2015, Christian Schafmeister wrote:
(3) There is no contribution policy for Clasp. What should it be? Are there any good models we can copy? If you keep it as a separate project for now then maybe there are no immediate issues.
You might want to consider whether you will want to change the license in the future. If so, some kind of copyright assignment policy is probably necessary. Mercurial wanted to change its license around 2009-2010, and had great difficulty contacting contributors. Now I think it has some policy about assigning copyright. It should be easy to find out more about this if you want.
Regards, Faheem
(1) I believe that this tool should, at least initially, be written as an "application" rather than being part of Clasp in terms of the build system. This will reduce the amount of merging required (given how quickly Clasp is moving) as well as providing a proving ground for Clasp's support of such applications; I believe that CANDO does not fulfill this role given that Chris has decided to design it as a "fork" of Clasp. Admittedly, assuming that this project goes well, I would hope that the clbind-generator would become a part of the "standard library".
(2) According to my limited Lisp experience, I think that it would be relatively easy to keep the clbind-generator modular; this will at the very least simplify debugging and contribution, even if the structure is not flexible enough to introduce other targets.
If other targets are introduced, I believe that the first target should be whichever Common Lisp FFI system(s) are the de-facto standard outside of Clasp, so that Clasp code may become, to a certain extent, more portable to other Common Lisps. I do not expect full compatibility to be possible given Clasp's unique features.
(3) Multiple high-profile projects have run into copyright issues in the past; I believe that most of these stemmed from actions which legally require the consent of all contributors (who have contributed anything over 10 lines of code or equivalent) --- for example, relicensing from GPL to LGPL --- in combination with past contributors being out of contact for one reason or another, so their consent cannot be obtained.
This is, obviously, something for Chris to decide on.
I agree that keeping this tool (and other major projects like it) as independent project(s) will significantly simplify this issue.
(4) LaTeX is indeed great; however, I believe that there may be merit in investigating other documentation formats which may be more amenable to online publication, searching and introspection/reuse (e.g. export to/import from docstrings).
Note: I'm currently studying for exams, so my responses are likely to be delayed & I cannot commit a lot of time at the moment. After the 30th, I believe that I will have more time available for this project.
Regards, Georgiy (a.k.a. SAL9000 on freenode)
P.S: If you have received this message twice, I apologize in advance.
Hi Georgiy (and everyone else),
On Wed, 24 Jun 2015, Georgiy Tugai wrote:
(3) Multiple high-profile projects have run into copyright issues in the past; I believe that most of these stemmed from actions which legally require the consent of all contributors (who have contributed anything over 10 lines of code or equivalent) --- for example, relicensing from GPL to LGPL --- in combination with past contributors being out of contact for one reason or another, so their consent cannot be obtained.
Yes, this was something I mentioned in my message earlier today. I know a little bit about this, because I helped the Mercurial project track down some old contributors in 2009. They needed to change their license from GPL2 to GPL2+, I think. I forgot why exactly.
Anyway, some of those old contributors, dating from like 2005, were never tracked down. I remember going to considerable effort to try to locate someone from Singapore who was one of Mercurial's earliest significant contributors as of 2005, but without success. However, I believe they changed the license anyway.
See also https://mercurial.selenic.com/wiki/Relicensing
I thought (and said earlier) that Mercurial requested a copyright assignment from contributors, but I think I must have been mistaken. I see no signs of this. However, that does not make it a bad idea for the Clasp project,
It is worth noting that the legal umbrella for the Mercurial project is the Software Freedom Conservancy (https://sfconservancy.org/), loosely affiliated with the FSF (Bradley Kuhn is associated with both organizations in a senior capacity). Presumably the Conservancy advises them on such issues.
Chris, I'd recommend talking to them at some point. They could be a useful resource on legal matters.
Regards, Faheem Mitha
-
Andrew Robin -
Andrew Robin -
Christian Schafmeister -
Faheem Mitha -
Georgiy Tugai