gcodepreview

the proposed application seems a very narrow one. A better option maybe would be a collaborative approach where it is acknowledged that code which cannot be easily explained/documented maybe needs to be re-written: https://www.folklore.org/Inside_Macintosh.html Just watched MIT's OCW for Introductory Python, and one of the suggestions there for debugging was describing the code to a child (or kitten, or stuffed animal) --- of course the best code is that which never needs to be written (using a library), but arguably second-best is the code which is correct and doesn't need to be debugged, so third-best would be code which is documented well enough that it may be debugged/re-written easily. When I looked for Literate Programming tools for my current project, I didn't find anything which seemed a good fit, so resorted to asking on tex.stackexchange.com https://tex.stackexchange.com/questions/722886/how-to-write-... which allowed me to create: https://github.com/WillAdams/gcodepreview/blob/main/literati... which I've been using in: https://github.com/WillAdams/gcodepreview/blob/main/gcodepre... (which is currently being re-written in Python) Quite simplistic, but working with the linear .tex file is way better than my previous approach of tiling 3 different files open in 3 different OpenPythonSCAD instances and using a fourth window to test the code. I'd be very interested in suggestions of other tools and resources to consider. I've been collecting LP texts at: https://www.goodreads.com/review/list/21394355-william-adams... (in particular, while not an LP text, Ousterhout's _A Philosophy of Software Design_ was quite striking and reading through it and then reviewing my code to apply its principles one chapter at a time helped immeasurably) The idea that they have here of using AI to make a first automated pass at documentation and then editing it by hand seems like a lot of extra work, and likely to create the possibility of introducing some subtle misunderstanding in the text which is then difficult to ferret out.

reviously discussed here previously: https://news.ycombinator.com/item?id=37979758 and https://news.ycombinator.com/item?id=40228068 - BRL-CAD --- _the_ venerable choice, but the interface is so old school and programming-like, most folks won't even consider it - OpenSCAD --- 3D modeling for programmers --- the great thing about it is, anything which one can describe mathematically can be modeled --- the awful thing about it is, what one can model is limited by one's mathematical knowledge. A further concern is that DXFs from it are just polylines, no arcs --- I've been working to address that using OpenPythonSCAD at: https://github.com/WillAdams/gcodepreview LibreCAD is workable for 2D, though I only use it for file conversion. The other notable options are OnShape (free for public designs), Alibre (quite affordable), Solidworks for Makers (for values which include non-commercial usage watermarking).

7/breaking-out-... - OpenSCAD: Make 3D things w/o having to use a full-fledged CAD program - BlockSCAD: Make 3D things w/o typing: https://www.blockscad3d.com/editor/ (though to be fair, https://github.com/derkork/openscad-graph-editor also allows that) - PythonSCAD: variables and file I/O for OpenSCAD (though to be fair, RapCAD had the latter, it was just hard to use it w/o traditional variables) https://pythonscad.org/ Still working through a re-write of my OpenSCAD library in Python: https://github.com/WillAdams/gcodepreview and am hopeful that a tool like to https://nodezator.com/ will make that graphically accessible (w/o going into OpenSCAD mode to use OSGE).

aving the typeset PDF w/ its hyperlinked ToC and marginalia and indices helps a lot in having a "nice" version which I can look through to remind myself of what was intended at a given point, and most importantly, to find _where_ that was written down. Working on a re-write now --- we'll see if this holds up for that.