Pinned toot

Researching new ways to write software that make it easier for newcomers to understand rather than for insiders to maintain. Build easy, reward curiosity, encourage lots of forks, delete unused features, more antifragile society.

Current project:

Rather than start with a desired syntax, Mu starts from the processor's instruction set and tries to get to _some_ safe and clear syntax with as few layers of translation as possible.

Pinned toot

Implementing orca in uxn is kicking my ass, maybe it's bigger than I can chew with my current knowledge.

Okay, this is probably an even better example of their performance. I'm not an expert by any means, but dang, they all seem absolutely solid performers. Fanny playing "Blind Alley":

Imagine becoming a fan of a band 50 years too late. πŸ˜†

Show thread

After a decade of waffling I finally started using NoScript. It's interesting. I mostly allow scripts, but make myself do so manually. And it's interesting to be aware of javascript usage on different sites. Like a geiger counter.

Just pushed to Uxn more progress in my in-Uxn assembler! Implemented so far:

βœ” Load/store helpers
βœ” Macro definitions

Missing are:

βœ– Executing macros
βœ– Literal data
βœ– Opcodes

I'm sure you'll agree that not being able to write any actual code is a mere nitpick and I'm basically finished...

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

Mu's HLL is now Turing-complete, I think.

Things to notice:
* Wordstar-style menu at the bottom.
* List of available primitive functions in bottom left.
* List of globals on the left side that updates as I add definitions.
* Matching parens highlighted as I type.
* Drilling down into the trace to understand how the program was evaluated.

Main project page:

Show thread

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.

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.

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...

OMG, this comment wins the internet today.

"Reading code diffs is like examining your life as the changes that happen over time but not actually _examining_ your life. This is how you wake up one day and realize that you don’t like the person in the mirror, or that nobody else does."

Thanks @colby

@paul @akkartik great comment by dhosek on HN about code reading ("clubs") and the relationship to LP <>

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 <>)

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.

Show older

Merveilles is a community project aimed at the establishment of new ways of speaking, seeing and organizing information β€” A culture that seeks augmentation through the arts of engineering and design. A warm welcome to any like-minded people who feel these ideals resonate with them.