Kartik Agaram @akkartik@merveilles.town

Left: Lv2 Grape Hyacinth BULBLING

🌱 burrows deep
🌷 cute of flower
🌻 bees like me

Right: Lv40 Grape Hyacinth SORROWLORD

🃏 mid-game boss
😭 inspires fear
🌋 automatically splits into 50 bulbs as you dig it up

#florespondence #theVent

hey, any merveillians got knowledge about modems? im thinking about how expensive mobile devices can be and if we can do better....

Writing an IDE for the Orca livecoding language in stack-machine assembly.

A feature of INTERCAL-72 not documented in the original manual was that it required a certain level of politesse from the programmer. If fewer than 1/5th of the program statements included the PLEASE qualifier, the program would be rejected as insufficiently polite. If more than 1/3rd of them included PLEASE, the program would be rejected as excessively polite.

http://www.muppetlabs.com/~breadbox/intercal-man/s10.html

I miss how old BIOS machines felt.
With UEFI, you really get the feeling there's something underneath, slightly slowing everything down and doing unnecessary things.
BIOSes just felt a lot closer to the machine, written in mostly pure assembly, minimizing code space as much as possible to save on ROM.

https://sbtcvm.blogspot.com/

In, Through, and Beyond #Saturn's #Rings
#Astronomy #Picture of the Day

https://apod.nasa.gov/apod/ap210404.html

#APOD

i'm more of a 16 bit kind of witch but i gave writing my own uxn vm a shot~

the computer's here, just need the peripherals...

A tiny 8-bit DAW running on a stack-machine.

@paul @akkartik great comment by dhosek on HN about code reading ("clubs") and the relationship to LP <https://news.ycombinator.com/item?id=26668822>

This (esp. "the biggest challenge is just finding a starting point") matches the lessons I've internalized over the last ~3 years. My main takeaways whether you're doing proper LP or not, is that just like a book you:

1. need to provide an obvious place to start, and
2. should write code top-down (see also <https://www.teamten.com/lawrence/programming/write-code-top-down.html>)

OK, say what you will for the logic behind the 9P protocol, but I will die on this hill.

#9P is pretty damn complex, in exactly the same sort of way that the SD protocol is complex.

There are a ton of websites talking about how awesome and simple it is; yet, precious few of these sites actually attempt to write their own implementation from scratch. Even Writing a 9P Server from Scratch relies heavily on pre-existing infrastructure.

It might be simple compared to NFS, AFS, or other distributed filesystems. But, in absolute terms, it's still damn complex.

In particular, my beefs include:

I can see the manage for clients to manage tags; but, WTF is up with Fids? Why do I have to manage them? The server is already stateful; it should be managing them for me.
Qids are useless as far as I can see. I can't tell why a client would ever want to know a Qid.
The error handling mechanism of the Twalk command is just ... bizarre. I think it's because it allows the client to determine where in the path component list the error lies. Wouldn't a simple ordinal in an Rerror message be as useful? KISS!!!
The Rerror message format is confining. It desperately needs to be redefined as follows, at the very minimum:
Rerror[1] tag[2] code[8] why[8] msg[s]

where code provides a meaningful-to-computers error code. The why field is qualified by code, and helps in diagnosing why the error occurred in the first place. (For Tripos users, these fields are equivalent to the res1 and res2 fields in an IORequest block.) msg would be as it currently is.

Implementing even the most basic version of Twalk is stupidly hard. So many details to keep straight in your head while coding its handler!

I've already written about 350 lines of 9P handling code, and it'll probably be closer to 450 to 500 lines after I've finished implementing Twalk. I haven't even come close to implementing support for read, write, open, close, stat, wstat, etc.

I have no confidence that I'm actually implementing this protocol correctly.

Very frustrating.