So I need to rethink how Teliva displays run-time errors. Now I hazily remember Turbo Pascal having a "press any key to continue" prompt on run-time error.
I did finish after all. An hour into the day, after doing other stuff (going over review jam feedback with Teliva, creating a list of bugs), it occurred to me to get "press any key" by adding just one line of code to Teliva and recompiling. That got me debugging again.
But this video is going to be useless. Across two sessions, I have an hour of me umming and aahing, muttering and swearing.
http://akkartik.name/post/silfen-paths
Many thanks again to https://compudanzas.net for play-testing it and making it 10x more hospitable a road to travel.
Watch me (slowly and laboriously) work through a problem from last year with Teliva
https://archive.org/details/akkartik-teliva-2021-11-30 (video; 15 minutes)
I've been introspecting for most of 2021 on where I wanted to go with Mu. I'd never had any expectation that it would ever be mainstream popular, but I had hoped to coalesce a small community around it, of the scale of say suckless. In 2021, after 5 years of prototypes I found myself asking myself the hard question: why are so few people making the leap from reading about it and starring/liking/boosting/upvoting it to actually trying it out and playing with it? Which led me to the question of, what should attract them to build things atop Mu? The tough answer to face up to was: nothing. Mu today can't really do much. In particular, not having network drivers is a killing limitation. All you can build with it are toys, and I didn't set out to build toys.
Though I do have an older variant of Mu that runs on a Linux kernel. That should in principle provide easy network access. I always felt ambivalent about relying on the kernel, though. What's the point of being so draconian about avoiding C in Mu and building everything from scratch, if my stack includes C from the kernel? And then I learned about how the firmware sausage was made. I'd built Mu to advocate against the constant push to build languages atop other languages, but I started to realize that complexity grows not just upward but also downward. I'd built Mu with some idea of minimizing total complexity of a computing stack, but along the way I started to realize that reality has inextricable complexity that's independent of what we're trying to use it for. The goal shifted from minimizing total complexity to "finding a narrow waist of reality," something that provides a consistent experience above it while relying on very little below it. In this new framing it stopped to matter how deep things extended below. Because really, we're always going to depend on a deep stack going all the way down to electrons and quarks.
Ok, so networking is hard to recreate and some C is ok but not too much. I started casting about for a minimal stack that's built directly in C (because minimizing layers of abstraction is still just good engineering). Lua fits the bill quite nicely. Linux kernel + libc + 12kLoC for Lua is arguably as minimal an implementation of networking as I'm going to get. And Lua packs an impressive amount of technical depth in 12kLoC to make its programs go fast. Graphics is still too much, though. The Lua eco-system already has https://love2d.org for anyone wanting to do graphics. I have nothing to offer there. But I hope to make progress on the original goal of Mu, before all the feature creep:
- Apps are easy for anyone to run. The infrastructure they need is easy to build.
- Apps are easy for anyone to run.
- Once you start getting used to running an app, it's easy to poke inside the hood. Small changes can be made in an afternoon.
- When modifying an app, it's difficult to end up in irrecoverable situations or bugs that are too hard to track down. (That's really what all of Mu's memory safety was aiming for.)
So I'm going to spend the next 5 years wondering why nobody's trying this out :D It's quite possible that text mode is just a bridge too far for everyone else. We'll see.
(original conversation with Andrew Owen)
Oh, is it Advent time already?! I've been remiss. If you're looking for something slightly different (easier, more collaborative) this year, I have this guided tour of Mu in 16 gradually-escalating tasks for your consideration.
Many thanks to https://compudanzas.net for play-testing all the tasks and making many suggestions for improving it. Send compliments their way, blame me if you find anything off.
(Obviously none of this is original development. I'm just putting together libraries created by my betters.)
Try it out:
git clone https://github.com/akkartik/teliva
cd teliva
make linux
src/teliva chesstv.tlv
Known issues:
- Code browser is broken for this app. It's likely the callback.
- Reading from network blocks keypresses.
Main project page: https://github.com/akkartik/teliva
I've been programming in C++ for a long time, and just ran into a very surprising situation in C.
$ cat x.c
inline int foo(void) {
return 42;
}
int main(void) {
return foo();
}
$ gcc -c x.c
$ gcc x.o
undefined reference to 'foo'
$ gcc -O1 -c x.c
$ gcc x.o
# no error
If you compile without optimizations, the `inline` keyword does nothing -- but the function is still excluded from the object file.
https://luapower.com/philosophy
<3
One of the hidden gems in luapower is this little bash script called multigit. It.. oh heck, I'll just let you read about it and have your mind blown: https://github.com/capr/mgit
Relevant excerpt:
"NO [SUB-]DIRECTORIES
This may be a hard sell but I stand by it. [Sub-]directories are evil. Not so much because of semantics, but because of the tools we use suck at working with them. No global overview; instead you have to navigate them."