Also, they (the Callahan government) had a plan to bring state of the art semiconductor manufacturing to the UK. Basically TSMC but in Wales. Thatcher killed it.
https://en.wikipedia.org/wiki/Transputer TV-toy
https://www.abortretry.fail/p/inmos-and-the-transputer TV-toy
https://www.transputer.net/tn/50/tn50.html M212 details
https://forums.atariage.com/topic/271372-flare-technology-an... 9.2mb/s bandwidth+sequencer_list
But not all is well with Org Mode syntax either. Many git hosters have only a very rudimentary implementation of a parser and writing a parser for it is not actually that easy. Its dynamic nature requires at least a 2 step approach of parsing and then later checking all kinds of definitions at the top of a file and further processing the document according to that. It's power comes at that cost. That's probably why we have so many Markdowns, but only one Org Mode (OK maybe a few, counting Vim and VSCodium plugins, that achieve a feature subset).
I will say though, that org mode syntax is much better suited for writing technical documentation than markdown. The only issue is, that not so many people know it or want to learn it, and I don't know a way to change that. Perhaps that effort to have the org mode syntax separately defined (https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Over...) by the same author will help creating more support for the format in various tools.
Just wanted to say that I share data between different blocks in different languages through files and env variables (I add :session shared to the src blocks that need to access this). That is useful also to have src blocks you can execute repeatedly and that depend on something like an aws identity being assumed (you just assume it in the first block that shares the session).
I agree it's messy, it's just a mess that works for me.
With org mode in mind, ideally you would have language support for this ie. Comments are scoped metadata that can be formatted, tested, linked etc.
You need a well defined spec like djot as a DSL for this to work, so that parsers can be easily written for it. This level of language support allows many different views onto the source code. We’re not there yet.
Does the language give any guarantee that TCO was applied? In other words can it give you an error that the recursion is not of tail call form? Because I imagine a probability of writing a recursion and relying on it being TCO-optimized, where it's not. I would prefer if a language had some form of explicit TCO modifier for a function. Is there any language that has this?
https://github.com/ablevm/able-forth/blob/current/forth.scr
I do prefer this as it keeps the language more regular (fewer surprises)
ClassiCube has a WIP GBA port, but according to commits it only hits 2 FPS as of now and is not listed in its README.
On a related tangent, there's also Fromage, a separate Minecraft Classic clone written for the PS1 (https://chenthread.asie.pl/fromage/).
since we still have the tracing overhead and the same lifetimes, we haven't really gained that much by having manual memory.
D's best take at this is a compile-time assert that basically forbids us from allocating GC memory in the affected region (please correct me if I'm wrong), but that is pretty limited.
does anyone else have a good narrative for how this would work?
I'd have thought that allocating a block of memory per-GC type would work. As-per Rust you can use mainly one type of GC with a smaller section for eg. cyclic data allocated in a region, which can be torn down when no longer in use.
If you think about it like a kernel, you can have manual management in the core (eg. hard-realtime stuff), and GC in userland. The core can even time-slice the GC. Forth is particularly amenable as it uses stacks, so you can run with just that for most of the time.