 I've been changing my workflow these past few days from working with textual sources, to using something called structured editing. Normally you'd think of a program as source code made of text, but in structure programming, you edit the symbols of the program, in this case the bytecode, labels and comments. I use the textual representation when saving my work, so it can be versioned, but while working anything that is not a bytecode, a symbol or a comment is not recorded. 32 comments
This means that would I loose a source file, I can recover the sources from the rom and the symbols file and resume working on a project.  @neauoire could you integrate the symbols file into the ROM format, so that source code can always be recovered? (obviously, the symbols can always be stripped, but it would give a clear indication of the expectation of openness) @thamesynne I could yeah, also I think it would be pretty safe to pad the symbols to 0x10000, it would just make roms that are mostly empty space, but wouldn't bread compatibility @thamesynne I'd pick some lz compression scheme that could easily be implemented in uxntal ;) @neauoire lz4, maybe? pretty much any compression scheme will dispose of acres of white space @thamesynne yeah I was thinking something like that. I took at stab at an implementation once but it kicked my butt. I'd have to try again @neauoire might also be useful to look at Einar Saukas' Spectrum-targeted compression algorithms - although they're more concerned with decompression size and speed, assuming a "grown up" computer will throw billions of cycles at the compression  @mpcnat I'm glad you've enjoying these little experiments :) I'll keep poking at this a bit further.  @neauoire yes! this is how co works, the source code is natively a bytecode, and there is even a subset of the instruction set reserved specifically for source-only tokens (like newlines, indents, comments, and different types of label definitions) and then the text representation is really just a transformation layer/interface. and then there is also a symbol database integrated to the language tooling, similar to the βsymbol fileβ you mentioned (i imagine?) @jakintosh ah! very nice :) You could probably free the formatting stuff from the specs and put it in the symbols file! It's really nice to have it all in the symbols LUT, it simplifies things a lot I think. So a few days I've realized that I very much liked working using structured editing. Structured editing means that your editor is aware of the program's functioning enough that it handles how it should be presented, so you're not editing text as much as the underlying structure of the program. It's just a fancy way of saying that it's basically just a symbols aware disassembler. I've spent the past 2 days improving the UX so I could run the reassembler without going through the terminal. (the code formatting in the video is all messed up, it's the first time that I manage to connect all 3 parts of together and I was too excited to bother fixing up the syntax parser) The two hexadecimal editors are: - left: a rom file(binary blob with the bytecode) Assigning a type to a label(just a suffix extension in this case) allows me to display its content in whichever way I need(as opcodes, as letters, as hex bytes, or ..)    
[DATA EXPUNGED]
@prahou that's cream, the smalltalk font with slights modifications. You can grab it here: https://git.sr.ht/~rabbits/left/tree/main/item/etc/cream12.uf2
[DATA EXPUNGED]
@prahou you should ask @josh for help :)  @neauoire it was common for early Lisps (eg Acornsoft Lisp on the BBC Micro) to come with a structure editor, as they are very compact in Lisp. It was also common, and fun/dangerous, to extend the primitive structure editor with extra commands, by editing it. with itself of course! |
Gregory's Server
Some of the things that changes is that it standardize the coding style, type-awareness makes it so different types of data are displayed differently, that I never have to touch the formatting, that I can have assembly errors and hints appear directly in the IDE rendering.
In the video above, I can't break away from the formatting by adding linebreaks. Suffixing a labels with -bin, -txt, -icn -chr will render the body of the label differently.