I'm sure the idea here was a physical quine, although since it only contains 2.5% of its own G-code it's not really a quine, any more than a "Hello World" program is a quine since the string "Hello World" is in the program text. It would be trivial to generate something like this depending on which part of the G-code you pick.
Many G-code dialects contain subprogram calls, loops, and conditionals that seem like they'd permit a physical quine. The standard RepRap firmware breaks the rules by taking input:
G-code is like assembly language for CNC. It’s human readable, you can write it by hand if necessary, most machines will compile it internally to machine instructions, and there are a million different flavors with incompatible macros, etc. The flavor I’m most familiar with is Klipper’s interpreter, which will let you write macros, but that would technically be cheating since you could just stuff an entire program into a macro.
For anyone thinking of this, I promise to be suitably impressed (defined as "upvoting it when I see it on Hacker News") if anyone does manage to get a true G-code quine in this sense. Go for it.
The origins of Automatically Programmed Tools (APT the precursor of g-code) is a fascinating read [1] about the early intentions of -- its a poem forseeing LLM & CAD:
(From THE NEW YORKER) Cambridge, Mass., Feb. Z5-The Air Force announced today that it has a machine that can receive instructions in English, figure out how to make whatever is wanted, and teach other machines how to make it. An Air Force general said it will enable the United States to "build a war machine that nobody would want to tackle. " Today it made an ashtray [2]. -- San Francisco Chronicle, March 28, 1959
That ashtray was teh 1st CNC'd object.
Noble [3] speaks about the political angle that was an underpinning motivation
Is anyone else confused by thier cookie consent banner? The switches start out gray and become black when toggled. which position means consent? It feels intentionally misleading.
> The switches start out gray and become black when toggled.
Rant: That type of slider-switch is an inferior usurper of the classic tickbox, that rode in on a wave of touch-screen-ification. Oh, it can be done well, sometimes, but it's just far-too-easy to do it badly.
In this case (useless colors, no intrinsic text labels, etc.) I think the remaining rule/clue is "Move the dot-nub towards whatever you want." So moving right is indicating you like the "We track you" text, while moving left indicates some kind of disagreement.
_____________________
> It feels intentionally misleading.
The "Accept All" button is worse:
1. It abuses UI conventions of position and color that belong to a "Proceed with what is shown" button.
2. Likewise, the text-label is ambiguous: It could mean "Accept All [of the choices which I've made and can see]"... But instead it means "Reject whatever is on-screen, and replace all choices with 'accept' cookies."
3. When it does erase/reset all choices made, it does so in a secretive way by also submitting and vanishing the dialog. The user never has any opportunity to realize that the machine implicitly flipped all choices to the right-most position.
Any one of these might be an innocent mistake, but all three sins together are a dark-pattern.
Don't print the braille document directly. Instead, I suggest printing a braille embosser. Think Gutenberg press. Then use that to press braille lettering onto a sheet of paper.
Although if you just want one sheet, I guess you could use the print directly, but maybe don't use PLA since it'd be kinda sharp and unpleasant to run your finger over.
> Manual contains only 2.5 percent of its own G-code in its first version. That low figure is part of the point. Current FFF 3D printing resolution and text scale place limits on how much code can fit onto the object while also describing the volume of the object itself. A fully self-contained version would enter an endless loop, since every printed mark would add more data to be described.
The fact that quines exist means that it must be possible to print a fully self-describing book of this sort, though it's possible that you'd require a more expressive language.
There's probably a way to make an xz file that decompresses to g-code for itself. But plain g-code is not powerful enough because it's just a list of movements due the tool head to perform - no computation.
`M98` allows for essentially function calls (nested or not.)
If you had a part of a machine that could save state (say.. turning on a coolant pump..) I wonder how much more of a turing machine you could wrastle into it.
(or you could just cheat and use one of the hundreds of gcode variants that have computational stuff stapled into them like the Fanuc equivalents, but that's sorta dishonest for the exercise)
And weirdly, neither does Klipper, despite having all the resources in the world to do so. Just not a priority since slicers don't produce code like that, and 99.999% of Klipper's job is to eat whatever a slicer sends it.
So suppose I attached an extruder to a Haas mill or something...
It's fascinating how revered people are who talk in metaphor and implication like this about relatively simple things, when far more complicated things are happening all the time inside their devices.
G-code by itself only describes the series of motor movements over time, though I think it would be practically feasible to have a book contain an executable script, which would generate the same g-code as the one used to print the book. It would be really interesting to see how large the resulting book is.
"This prompt, when fed to a sufficiently capable LLM, will generate the G-code to produce a 3D printed model of a book containing this quote, verbatim, in raised letters."
I'm sure the idea here was a physical quine, although since it only contains 2.5% of its own G-code it's not really a quine, any more than a "Hello World" program is a quine since the string "Hello World" is in the program text. It would be trivial to generate something like this depending on which part of the G-code you pick.
Many G-code dialects contain subprogram calls, loops, and conditionals that seem like they'd permit a physical quine. The standard RepRap firmware breaks the rules by taking input:
https://reprap.org/wiki/G-code#M98:_Call_Macro.2FSubprogram
but Fanuc and other dialects allow M97 to call a subroutine chained to the end of a program.
G-code is like assembly language for CNC. It’s human readable, you can write it by hand if necessary, most machines will compile it internally to machine instructions, and there are a million different flavors with incompatible macros, etc. The flavor I’m most familiar with is Klipper’s interpreter, which will let you write macros, but that would technically be cheating since you could just stuff an entire program into a macro.
For anyone thinking of this, I promise to be suitably impressed (defined as "upvoting it when I see it on Hacker News") if anyone does manage to get a true G-code quine in this sense. Go for it.
The origins of Automatically Programmed Tools (APT the precursor of g-code) is a fascinating read [1] about the early intentions of -- its a poem forseeing LLM & CAD:
(From THE NEW YORKER) Cambridge, Mass., Feb. Z5-The Air Force announced today that it has a machine that can receive instructions in English, figure out how to make whatever is wanted, and teach other machines how to make it. An Air Force general said it will enable the United States to "build a war machine that nobody would want to tackle. " Today it made an ashtray [2]. -- San Francisco Chronicle, March 28, 1959
That ashtray was teh 1st CNC'd object. Noble [3] speaks about the political angle that was an underpinning motivation
[1] http://portal.acm.org/citation.cfm?doid=960118.808374
[2] https://mitmuseum.mit.edu/collections/object/2007.037.001
[3] forces of production - a social history of industrial automation (Noble, mit press)
Is anyone else confused by thier cookie consent banner? The switches start out gray and become black when toggled. which position means consent? It feels intentionally misleading.
This is how you get statutory warning labels and nutrtion information labels on packages.
Because these folks always want to do the least legal thing allowed by law.
> The switches start out gray and become black when toggled.
Rant: That type of slider-switch is an inferior usurper of the classic tickbox, that rode in on a wave of touch-screen-ification. Oh, it can be done well, sometimes, but it's just far-too-easy to do it badly.
In this case (useless colors, no intrinsic text labels, etc.) I think the remaining rule/clue is "Move the dot-nub towards whatever you want." So moving right is indicating you like the "We track you" text, while moving left indicates some kind of disagreement.
_____________________
> It feels intentionally misleading.
The "Accept All" button is worse:
1. It abuses UI conventions of position and color that belong to a "Proceed with what is shown" button.
2. Likewise, the text-label is ambiguous: It could mean "Accept All [of the choices which I've made and can see]"... But instead it means "Reject whatever is on-screen, and replace all choices with 'accept' cookies."
3. When it does erase/reset all choices made, it does so in a secretive way by also submitting and vanishing the dialog. The user never has any opportunity to realize that the machine implicitly flipped all choices to the right-most position.
Any one of these might be an innocent mistake, but all three sins together are a dark-pattern.
I was going to say that this is the first physical quine but then I remembered that we actually had that a few billion years ago.
Cool idea for printing braille. I bet I could vibe code a program to convert .epub files to braille then to printable copies.
Don't print the braille document directly. Instead, I suggest printing a braille embosser. Think Gutenberg press. Then use that to press braille lettering onto a sheet of paper.
Although if you just want one sheet, I guess you could use the print directly, but maybe don't use PLA since it'd be kinda sharp and unpleasant to run your finger over.
I've also been idly contemplating 3D printing braille. Somewhat annoying that that's the cheap+easy option, but if it works...
:)
> Manual contains only 2.5 percent of its own G-code in its first version. That low figure is part of the point. Current FFF 3D printing resolution and text scale place limits on how much code can fit onto the object while also describing the volume of the object itself. A fully self-contained version would enter an endless loop, since every printed mark would add more data to be described.
The fact that quines exist means that it must be possible to print a fully self-describing book of this sort, though it's possible that you'd require a more expressive language.
There's probably a way to make an xz file that decompresses to g-code for itself. But plain g-code is not powerful enough because it's just a list of movements due the tool head to perform - no computation.
`M98` allows for essentially function calls (nested or not.)
If you had a part of a machine that could save state (say.. turning on a coolant pump..) I wonder how much more of a turing machine you could wrastle into it.
(or you could just cheat and use one of the hundreds of gcode variants that have computational stuff stapled into them like the Fanuc equivalents, but that's sorta dishonest for the exercise)
_If_ one is using a firmware which supports that.
Grbl, which many of the 3D printer firmwares are based on, does not (and no variables, or loops, or branching).
And weirdly, neither does Klipper, despite having all the resources in the world to do so. Just not a priority since slicers don't produce code like that, and 99.999% of Klipper's job is to eat whatever a slicer sends it.
So suppose I attached an extruder to a Haas mill or something...
It's fascinating how revered people are who talk in metaphor and implication like this about relatively simple things, when far more complicated things are happening all the time inside their devices.
Ironically, I don't know if you are referring to the article, the comment you are responding to, or the world in general.
G-code by itself only describes the series of motor movements over time, though I think it would be practically feasible to have a book contain an executable script, which would generate the same g-code as the one used to print the book. It would be really interesting to see how large the resulting book is.
"This prompt, when fed to a sufficiently capable LLM, will generate the G-code to produce a 3D printed model of a book containing this quote, verbatim, in raised letters."
"Some percentage of the time."
Compression could be interesting
Perhaps doing the g-code text as barcoding / q-code sequences might permit more code to be included in book?