Hello Matt, On Thu, Aug 18, 2016 at 5:44 PM, Matthew Keeter <matt.j.kee...@gmail.com> wrote: > Hi Guile-folks, > > I wrote a computer-aided design (CAD) tool that you may find interesting. > > It’s a solid modeling tool that uses Guile scripts to define objects (and > constructive solid geometry + functional representations under the hood). > > Project page: http://www.mattkeeter.com/projects/ao/ > Source: https://github.com/mkeeter/ao
This is a really awesome project. Just recently I was lamenting that I didn't know how to use any CAD tools and was wishing that there was one that used Guile. Good timing! The section of the website that explains the advantage over software like OpenSCAD really resonated with me. It seems like a successful application of the Emacs design philosophy to computer aided design. Unfortunately, I haven't been able to build Ao because I can't get CMake to find my glfw3.pc pkgconfig file. PKG_CONFIG_PATH was set appropriately as I use GuixSD which has no notion of the global /usr directory. Do you know how to explicitly tell the build system about glfw3.pc? > I’d love feedback – Scheme is relatively new to me, so I’m sure there are > more elegant ways to accomplish a lot of what the code implements. I think so far you've done a great job, so consider the following criticism to be of the "it would be really cool if..." variety. I watched the video of Ao in action, and while auto-reload of script files is cool, it's no replacement for a REPL server. So, in addition to having that REPL attached to your terminal's STDIN/STDOUT, it's possible to make a REPL server[0] in guile that listens on a port or uses a UNIX domain socket. This unlocks great hacking power for Emacs users who can use Geiser[1] to connect to the REPL and write/eval code directly from their Scheme buffers. This kind of interaction is much preferred over having to save and reload entire script files as it allows for more incremental computation and a faster feedback loop. Additionally, embedding Guile in a C/C++ application has become a somewhat discouraged practice. The recommended architecture these days is to write the entire program in Guile and use the foreign function interface to access C libraries (GLFW and friends, in your case) when needed. This would make Ao a Guile library in addition to an executable, and having everything written in Guile means that users can easily hack on any part of Ao from the comfort of their REPL without having to edit C code and recompile. There's a good article written by Python programmers[2] that explains the advantages of extending over embedding. I don't know how feasible this is to do in the case of Ao, but I've had good luck in the past transforming software from an embedded model to an extended one. The more code that is written in Scheme the better! Anyway, great work! I hope I can get this to build at some point, and if you ever make an official release please let us know so that someone can package it for GNU Guix. :) - Dave [0] https://www.gnu.org/software/guile/manual/html_node/REPL-Servers.html [1] http://geiser.nongnu.org/ [2] https://twistedmatrix.com/users/glyph/rant/extendit.html
