clasp next steps ? speed-up ?

Andrew Robin andrew.t.robin at gmail.com
Tue Jun 23 16:50:16 UTC 2015


Yes, I want you to volunteer--but drmeister didn't send me to recruit you.
:)  I just don't want to see people interested in this project dropping out
because no one answers their post.  I'm not sure drmeister reads this
mailing list that he created either.  He isn't posting to it much, for
sure.  I'd like to see the project in a state where he doesn't have
to--where people like me can.  Currently, work on the project seems to get
done through the IRC #clasp channel.  I have counted about 5 different
modes of communication on the Clasp project.  I prefer the mailing list
format because it is threaded, coherent, archived, and doesn't challenge my
limited attention span.

So let's address some of your ideas:

(1) Clasp to avoid C++

This is the reason I am interested in the project, too.  I need to wrap a
large C++ library with Lisp--I want to use Lisp where I can.  Not because I
dislike C++, but for what I am doing Lisp is better in a number of ways.
C++1x gives more Lisp-like features, but it is just getting too
complicated, IMO.  I talked to drmeister and others on #clasp about having
a more transparent way (read least C++ LOC) of doing the binding.  His
current clbind subproject requires the use of C++ boilerplate.  It seems
like having the AST of the C++ code would allow generating even easier to
use binding code IN LISP.  I have a more detailed post on this mailing list
regarding this issue--no one commented on this one either :(

Ideally, a project like Clasp should help you do chemistry more
efficiently, not navigate mind bending C++ code.  It's obviously not there
yet, but I haven't given up hope.  I'm primarily a software developer, and
have experience working with scientists and engineers on technical
projects.  I hope to contribute that experience to this project.

(2) Project dependencies

Unfortunately, with newer projects it takes time to get things sorted out.
I get annoyed when I have to install a mess of dependencies which deprecate
older versions of software I depend on.  One recent project (which will
remain unnamed) I installed had a dependency chain that wiped out X windows
without asking!  I'm working on understanding the external dependencies of
Clasp better.

Again, ideally, it would be great to use standard (and older, stable)
packages, prebuilt.  drmeister has apparently patched LLVM and clasp (and
boost?) to get his code running.  Getting these patches accepted by
established, production projects to support a fledgling project like Clasp
would be hard (and maybe questionable).  One idea I had was to see if the
project dependencies could be extended (like with a plug-in) rather than
patched.

Ir regard to your specific issues, could you install a supported of emacs
in parallel, and use that for Slime?  I haven't ever done this myself
however.  Another thing that might help you is creating a VM or a partition
with a more recent version of your operating system for use with Clasp.
Again, I am not the one to ask about doing this--just ideas.

(3) Debugging

Yes, we want to get the best debugging information we can.  If I have any
ideas about this after working with Clasp more, I will post them to this
list.  Please let us know what you come up with.

(4) Anybody else?

If you are still reading this--anybody else have comments?  Chemists want
self-organizing molecules, I want self-organizing code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clasp-devel/attachments/20150623/3592d2f9/attachment.html>


More information about the clasp-devel mailing list