Bob Nystrom is, apparently, writing a book, and tweeted an image for it that analogizes compilation to mountain climbing routes.
Made me think about some of the more Rococo compilation pipelines I’ve set up.
Self documenting code:
Run SWI-Prolog application that pulls selected modules out of other prolog applications, searches their code for library API calls, and does other introspection tricks, and reads the structured comments annotations, to assemble this info:
- Tree structure of available HTTP endpoints, with parameters
- Command line options
- Pengine publics not from system
Combines this with bits of markdown describing various parts of the system, and serves as the public API’s for the system.
After all, why use structured comments and literate programming when you can use the actual code to document?
Probably this trick only works if you can truly make sense of code programmatically. I’ve only really been able to do that with Prolog, despite other languages making a big deal of homoiconicity. Clojure fn bodies tend to be opaque.
Just because you make me check in Java:
Excel spreadsheet with a lot of information about computer vision building blocks.
The spreadsheet has some formulas that convert this info to Prolog code.
Export the Prolog code, run thru sed to fix up a line ending problem, execute the code, which generates a turtle file.
Run another Prolog program that reads the turtle file, generates a mass of Java files, and the XML crap that Maven, OSGi, and the rest of Java’s broken ecosystem requires.
Of Course the engineers need Photoshop, it’s in the toolchain
I’ve worked on a lot of graphics/games/entertainment stuff with cute bouncing bunnies (hence the blog name). The graphic artists work in psd files, at high resolution. The final website or whatever needs lo res png’s. But we make the artists do that conversion by hand each time they check in.
Dumb, dumb dumb. Have some engineer spend a few hours automating this.
Fun With Visio:
Hey, this problem would be easier to solve in a dataflow language.
Some hours of VBA later, I can set all this up by dragging symbols around in Visio.
OK, enough with the photoshop in the toolchain already
EZ way to write pick logic.
Create a CLUT (indexed color) image with whatever tool’s easy. When you want to do pick logic, just look up the color of the corresponding pixel and map that to whatever control. The OK button is that icky shade of green.
I usually just use a normal rgb image and make a line of pixels in the UL corner with the palette, since nobody uses CLUT’s any more
Hint: You can store the image at lower resolution if you don’t care about pick accuracy.
Bug #47 fixed by correcting autodocs
Michael Hendrix’s mavis pack adds types to SWI-Prolog. Yay!
So Prolog’s typeless. Where does the type info come from?
The pldoc literate programming system, of course!
Too much automation
A friend has things set up so running make pushes to github.
Years ago on DOS we wrote the serial number for our product directly into the executable, then patched the checksum. Only took me a couple hours to write that bit of code, including locating the executable format (pre internet) and figuring it out. Sigh, things get more complex.
For what it’s worth, I compiled with what would be the serial number string holding some unique marker like “hi, I am the marker”. Then I searched through the executable for it. In those days it was worth persisting the offset to a file.
Yet more Photoshop in the toolchain
Writing a game? The pick logic from image trick above also works for impassable terrain, power ups, etc.
If you do collision testing against a circular disc, make your life easy. Preprocess your maps.
Example: Say you have a bilevel map showing passable terrain, and 7 pixel radius (always use odd numbers for that) sprites. Map the bilevel image to grayscale, perform a radius 7 convolution with a hat kernal, threshold at 0.0001 and boom, you just have to test the center pixel at runtime.
All that math can be done in photoshop. The convolution is also known as ‘blur’. 8cD
Excel for config files
Excel is an excellent choice for config files.
I bet your favorite language has a reader for ODS or xlsx or some spreadsheet format.
Stick config values in Excel cells.
What’s that give me?
Config files usually have lots of places where info’s ‘usually’ the same. Names of fourteen different servers, which, 99% of the time, are all the same. Some port numbers that are just 1 more than the previous number. Etc. ad nauseum.
In excel, you can just have a formula.
Note that your reader will need to give you actual values, not formulas. 8cD Check that before betting career on this advice.
If that makes your manager and/or social worker hinky, have the Excel SS write out the XML or whatever abomination they’re making you use.
As Long as No One Knows, No One Gets Hurt
If you’re in Prolog, using anything but a file of prolog terms for config is a mortal sin. Say 10 Hail Marys and donate generously to Katolic Universitat Leuven or send Jan a nice recumbent bike.
If the pointy haired types insist that it’s ‘too complex’ for config, Use operators to make a DSL that looks like whatever brain dead config they want. Don’t tell.
Invent your own language
SWI-Prolog has plug in quasiquote support. I just resent that there’s no good editor support for inserting non-text stuff in them. Images? Naw, not interpretable as code.
In Second Life you can add bits of UI to your viewer.
These HUDs, as they’re called, are made, like everything else, in the world. You build a 3D object in the world, add scripts to make it do what you want, and then use a special command to ‘glue’ it to your viewer window.
I once wrote a complier for the Pathways product.
Following a ‘build script’ it generated a bunch of objects and stuck scripts in them. I’d then pick the objects up manually (limitation of the environment) and put them in the compiler for the next pass. After a few passes I had finished product.
A Whole Gallery of crazy code representations
OK, I’m wandering off crazy toolchains to crazy code representations, but whatever. Dr. David Touretsky solicited people to represent the DeCSS algorithm in creative ways as part of fighting the DMCA. They’re preserved in a gallery here.
SWISH sorta allows natural code representations
The SWISH online tool for SWI-Prolog allows one to make ‘notebooks’, that meld markdown, HTML, and prolog code sections. The Prolog code is runnable, via pengines.
You can also register ‘renderers’. So, for example, the output of the N queens example is drawn as a chessboard.
I keep trying to convince Jan that there should also be renderer support for the code itself. So, for example, openings for a chess program would be seen by the programmer as a series of chessboards.
8c( I think Jan thinks I’m bonkers.
So, don’t settle for boring toolchains! Your toolchain can be a useful tool for increasing productivity and entertainment value. Would that build utility be better as a minecraft object?
OK, back to my Labview!