Implementing structural editing in #uxntal. I remember having lots of fun with THINK Pascal when the IDE was reformatting my program automatically and I've been meaning to have this as part of my workflow now.
Implementing structural editing in #uxntal. I remember having lots of fun with THINK Pascal when the IDE was reformatting my program automatically and I've been meaning to have this as part of my workflow now. 31 comments
@csepp I agree, these source files as so tiny! This is all assembled code right, so the only strings in the project are label names and comments. It was surprisingly easy to implement, it'll change how I code a lot I suspect. @neauoire Wait what, so you are technically using a disassembler / binary editor? That is even cooler than what I thought was going on. π @csepp yeah, it assembles and disassembles, keeping comments and all types of labels. The source code is actually the binary file itself along with the symbols file. @neauoire Ohh so that's why Oquonie comes with a symbols file, I thought it was just for debugging. @csepp ah yes that's not a hex editor, that's just left, here's the hex editor with the ascii data, and overlapped in the step debugger, and the raw binary. I have this crazy idea in mind that goes something like this, in a single keystroke: - Assemble a program in the classic uxn self-modification style @neauoire So one thing about evolutionarily evolving "programs" is that code tends to have a "rough" fitness landscape, so that the shortest-(hamming/edit)-distance path between two fit points may be mostly unfit or mostly nonfunctional. My conclusion working with this sort of thing only works well when the shape of the fitness landscape can be made smooth. Then again, if the peturbation is being done by a human mind instead of an algorithm, maybe you actually *can* find good outcomes that way @mcc right now I'm focusing on two cases where I can raise warnings: - Ranges that can be reduced, where the boundaries of the tests never reach the literal boundaries set in the program. @neauoire Off-topic, but that Cream font you customized looks glorious every time I see it in one of your posts. Iβm curious if thereβs any existing way to convert the UFX font to something like OTF? @josh I'm not too familiar with the OTF format, but the ufx format should be easy to convert to a bitmap :) Maybe you can do bmp/tga -> otf? @neauoire Thanks, will have to tinker with it! Already found your specs of course, but figured Iβd ask about any existing tools before attempting to write my own. @josh let me know if you need a hand getting to the glyph data in the binary file. You can use this to see what to expect: https://wiki.xxiivv.com/site/turye.html @neauoire Thanks so much for offering, will see how far I get once I find some free time to tinker with it. And had already poked around in Turye βΊοΈ @neauoire A few missteps after slightly misunderstanding the spec but I got there! The harder part is going to be figuring out how to turn the pixel data back into a bitmap/raster font. To be continued! @josh could the docs be improved somewhat? @neauoire Dunno if the problem was with the doc (was using https://wiki.xxiivv.com/site/ufx_format.html) or my brain: @neauoire I originally tried laying out all the tiles contiguously in the specified order (2x tiles tall for UF2), and then selecting slices from that offsetting by character widths, which was as wrong as it was overcomplicated. The way it acutally works obviously makes way more sense -- pixel data is always the same size and the character widths are just bounds inside it. This is obvious in retrospect but somehow wasn't to me at the beginning! π |
@neauoire This is really neato. π
Structural editing is part of why I want to use a TLV based "sourceless" representation in my PocketViewer thingy. (The other is compactness.)
It's interesting that the builtin microlisp editor is also technically just a structural editor for lists, but the interface is like ed(1).
Unixy software wastes so much code space and CPU cycles with parsers, so for a truly low tech solution, I think it's best to stick to a single simple grammar.