I suspect the world would be better if that percentage were even greater.
Interactive Programming… in C
I’ve been kind of interested in a type of “livecoding” where changes to a code base are immediately reflected in a running program. I’ve seen Inigo Quilez (author of the famed shadertoy.com) do this with a scaffold that he wrote using OpenGL. Literally as he types new shader code, the changed shader is loaded and executed, and the new graphic image forms the background of his editor.
You can see an example of this here:
I started working on a similar framework, and got the basics working (except that I didn’t write my own editor, but merely ran vi in a window and updated the fragment shaders running in a separate window) but today I discovered this kind of cool idea: doing the same sort of thing in C.
Chris Wellons wrote on his blog back in 2014 about a set of techniques that could be used to do the same sort of interactive stuff in C. The basic idea is to write a framework which constantly monitors a shared library, and when it is updated, reloads the library. If it is not, then it calls an “update” loop. I don’t think this is helpful for all sorts of programs, and there are a few details to be sorted, but it’s kind of cool. I can imagine giving this a try on one or two projects that I’ve been pondering. Archived for future reference.
Addendum: David Parrot posted this to my twitter feed:
@brainwagon Given wordpress seems to think that this is spam and disallows the comment, a comment for your interactive programming blog post:
Casey Muratori implemented this in his Handmade Hero series, videos below:https://t.co/2dtbPXJ7EHhttps://t.co/O4QqvOe9nH
— David Parrott (@eightlittlebits) January 17, 2018
In case twitter integration fails, it’s a link to Casey Muratori’s Homemade Hero on instantaneous live coding. I haven’t had a lot of time to watch the videos yet, but they seem very cool.
Comment from Chris
Time 1/17/2018 at 9:26 am
I’ve found this technique useful for rapid development of audio generation software on Linux.
One thing that caught me out was differences in the way that different compilers save object files. I recall that one compiler (either Clang or gcc) appeared to save the compiled file in two stages (saving a header first, then appending executable data at a later stage, perhaps), which confused the monitoring part of the code when it tried to load an incomplete library.