I have no idea if pure software projects are something desirable on this website, but I'm putting it here anyway! This software performs cartesian shifts on your gcode (RS-274), but really, it's a library for handling RS-274 in C++. That way, if your CAM processor outputs code in a strange location, you can simply shift it back to the origin. This process is also known as "center lower left" in some CAM processors, but most (that I know of) do not have this feature. As an added bonus, you could use it to do all sorts of other things, like simulations and the like.
I spent quite a lot of time on this today, and the code is now "memcheck clean" which means that Valgrind reports no memory leaks. Hooray! I think this is pretty well optimized now.
About a week ago I was working on another piece of software that uses this library (which I may release if it ever works) and I needed to make a shape fit in a very small box (< 1 unit square) because I hadn't set up the camera yet. (That's an OpenGL technicality.) So, I decided that instead of scaling an SVG and using CAM on that, I would instead tell the CAM to use twice as many pixels per inch in order to halve the size of the model, theoretically. As it turns out, that causes the output file to be huge. I was trying to process it when I saw that the program had been running for five minutes with no results. Confused, I looked at the file with Atom only to see that it also took forever to open it. When I looked at the file size I noticed that it was 35MB, which would explain why everything involving it was so slow. I wanted to fix that, because the parser got through 1.6x10^6 lines before crashing with an unfortunate segmentation fault. Thus, multithreading support was under way.
I was about to write about the re-write I just did, except before I published, I decided to do one last check to make sure it was really working. Good thing I did, because it was not working. I'll write the rest once I get the chance and the energy, but the gist is, RS274 got split into several classes and structs and is now fully multithreading capable. As in, if you feed it a 35MB text file, it will saturate your system resources until it's done. It's great, memory consumption is approximately linear!
As it turns out, there is a surprising amount of unwritten information in RS274 that can be synthesized via analysis. I've split this program into a CLI frontend and a library, and the library, named RS274, now supports doing some of this analysis. It now synthesizes the following meta-data from each file as it parses:
atof returns 0.0f if it fails to convert the given character string into a number. Who thought that was a good idea?!
Therefore, the code has a new hack: AFTER a line is parsed and "converted" to a number, a check is run to see if the variable that was used to set the coordinates is empty. If it is, then std::nan() is used to overwrite that section of the parsed line struct and later on, when it is important to know whether the variable was empty or not, std::isnan() is used to check. What a mess. I updated the Github repository with the latest changes, all seems to be well now. I'm working on compiled binaries to put on this page, because that 1Gb of free space on Hackaday.io is tempting me!