The Uxn Ecosystem(100r.co)
100r.co
The Uxn Ecosystem
https://100r.co/site/uxn.html
57 comments
Some of the stuff is truly fascinating. My favourite: Solar Collector Tubes (cooking using the sun, including baking bread).
https://100r.co/site/solar_evacuated_tube_cooking.html
https://100r.co/site/solar_evacuated_tube_cooking.html
Also, they are active 9front users because they got fed up on dependencies (on any OS) and bloat. 9front it's very small and everything it's statically compiled while having a very small API. Crosscompiling it's a breeze and it automatically makes you competent on CS on reading then Plan9 Intro book from Ballesteros.
For anyone interested in this, Devine also has a personal wiki at https://wiki.xxiivv.com/site/home.html
There's so much cool stuff in there.
There's so much cool stuff in there.
Also, they post on Mastodon (since way before the recent migration waves), at:
https://merveilles.town/@neauoire
https://merveilles.town/@rek
and the instance created by them hosts a rather fine community of people:
https://merveilles.town/public/local
https://merveilles.town/@neauoire
https://merveilles.town/@rek
and the instance created by them hosts a rather fine community of people:
https://merveilles.town/public/local
[deleted]
I'm really impressed that they have the energy / motivation / time to write a virtual machine after dealing with all these "real world" issues !
Also impressed that it runs on a lot of real hardware apparently. I have seen many VM projects but they seem kind of isolated within other computers.
The extreme constraints definitely push the design in a different direction
Also impressed that it runs on a lot of real hardware apparently. I have seen many VM projects but they seem kind of isolated within other computers.
The extreme constraints definitely push the design in a different direction
Yeah, the same witht the Z-machine for text adventures (and terminal games like tetris, trek or rogue for the Z-machine)
.
Once you compile the game with Inform6 (an easier OOP lang than Python, rooms and objects are described almost as if they were a config file), the game runs from DOS/Amiga/Atari machines to Win/Lin/Mac/Android/iOS and even Haiku.
There is a huge subculture of sailors on Youtube, which is part of my escapism entertainment.
Of course Youtube’s algorithm being Youtube’s algorithm and capitalism being capitalism a large part of those sailing videos is bikini content. But at the same time a large part of the sailing existence is repairing, renovating and upgrading their small yachts, from fiberglassing to solar to watermaking. As you say, a peek into a fascinating existence.
Of course Youtube’s algorithm being Youtube’s algorithm and capitalism being capitalism a large part of those sailing videos is bikini content. But at the same time a large part of the sailing existence is repairing, renovating and upgrading their small yachts, from fiberglassing to solar to watermaking. As you say, a peek into a fascinating existence.
As someone who recently moved onto a boat after discovering all those YouTube channels, I agree! I've found the less produced channels to be the most exciting.
Yes. The trick is to find these channels early and then bear to unfollow them when they get to streamlined.
My favorite recent channel is called “Boring Sailing,” which the algorithm served up, but has very few subscribers. It’s actually—truly—been boring to watch, at times, but you have to root for him!
“Wilding sailing,” on the other hand, is a much more ambitious labor fest, with the boat owner restoring a catamaran he bought for 2k Euros. That’s been inspiring, entertaining, and really worth subscribing to.
“Wilding sailing,” on the other hand, is a much more ambitious labor fest, with the boat owner restoring a catamaran he bought for 2k Euros. That’s been inspiring, entertaining, and really worth subscribing to.
Shitting in the seas is more complex than I thought.
Not always. A lot of the boats I've been on opt for a bucket instead of a head.
I admire this team very much. See also this great article about searching for simpler and simpler models of computing: https://100r.co/site/weathering_software_winter.html
Discussed here:
Weathering Software Winter - https://news.ycombinator.com/item?id=34219654 - Jan 2023 (28 comments)
Weathering Software Winter - https://news.ycombinator.com/item?id=34219654 - Jan 2023 (28 comments)
I think 100r reminds me of the thing we're missing the most nowaydays - bravery.
We're afraid to take chances, to explore ideas, to take a slightly harder path or to explore difficult challenges. We're risk averse and we're unwilling to try new things. Reading about their trips, about all the work they do on the boat and their approach to code (love the concept of making software for one person!) makes me feel like a coward and how I would love to be more brave about how I deal with code, life and the environment around me...
I appreciate all your work Rek and Devine. I'm glad yo see you busy doing nothing...
We're afraid to take chances, to explore ideas, to take a slightly harder path or to explore difficult challenges. We're risk averse and we're unwilling to try new things. Reading about their trips, about all the work they do on the boat and their approach to code (love the concept of making software for one person!) makes me feel like a coward and how I would love to be more brave about how I deal with code, life and the environment around me...
I appreciate all your work Rek and Devine. I'm glad yo see you busy doing nothing...
immibis(3)
The author's account on Mastodon (https://merveilles.town/@neauoire) is a treasure trove of many cool little projects and screenshots from the parallel computing universe that is Devine's computer.
I strongly recommend the podcast episode with him at Future of Coding: https://futureofcoding.org/episodes/044.html and the follow up where he talks about Orca, his incredible live music environment: https://futureofcoding.org/episodes/045.html
He's, along with the old Lispers on these forum, the reason why I'm spending so much time thinking about alternative computing and niche programming languages. Uxn is on my todo list, I'm busy with the Smalltalk family these days before diving in on Forth and Uxn :)
I strongly recommend the podcast episode with him at Future of Coding: https://futureofcoding.org/episodes/044.html and the follow up where he talks about Orca, his incredible live music environment: https://futureofcoding.org/episodes/045.html
He's, along with the old Lispers on these forum, the reason why I'm spending so much time thinking about alternative computing and niche programming languages. Uxn is on my todo list, I'm busy with the Smalltalk family these days before diving in on Forth and Uxn :)
They mentioned a calendar that breaks the year into twenty-six fortnights labeled by alphabets A to Z. But, 26 fortnights is only 364 days. Are you going to make years of only 364 days in this calendar, or will adding extra days beyond these 26 fortnights, or something else?
>him
It says "they/them" right there on the mastodon profile you linked.
It says "they/them" right there on the mastodon profile you linked.
I always love to see them on the front page, not only is the software they write really interesting, all the works they're doing to make the boat as self-sufficient as possible is incredible.
Any Blame! fans? [1] [2]
1: https://wiki.xxiivv.com/site/devine_lu_linvega.html
2: https://blame.fandom.com/wiki/Davine_Lu_Linvega
1: https://wiki.xxiivv.com/site/devine_lu_linvega.html
2: https://blame.fandom.com/wiki/Davine_Lu_Linvega
Both Blame! and Ergo Proxy[1] :)
1: https://100r.co/site/pino.html
1: https://100r.co/site/pino.html
One of their sites I actually check often is their recipes one: https://grimgrains.com/site/home.html
Some fun stuff in there, for the chef/cooking types around here.
Some fun stuff in there, for the chef/cooking types around here.
Maxine Chevalier-Boisvert (of note here due to her Basic Block Versioning JIT work and more recently yjit) has been working on similar ideas recently…
https://pointersgonewild.com/2023/02/24/building-a-minimalis...
This is a fascinating and elegant little virtual machine design that I think many here would find interesting.
What blows me away is how practical it is. They've ported it to every piece of junk they had laying around, and wrote tons of software. It's not just a design on someone's web page, they're making tools, games, art.
For gaming it's good, but sadly for software it lacks Unicode support. I wouldn't mind basic support with GNU unifont in further revisions.
Altough the complexity would skyrocket.
Then, if I wanted to write an adventure in Spanish I would omit the tildes, starting question/interrogation symbols and I would map ñ to ny.
Altough the complexity would skyrocket.
Then, if I wanted to write an adventure in Spanish I would omit the tildes, starting question/interrogation symbols and I would map ñ to ny.
> for software it lacks Unicode support
That's not an inherent limitation of the VM at least, just of the current software ecosystem. It would be possible and practical to make a tiny unifont-based Unicode text library. Though handling bidirectional text, joined scripts and vertical scripts would be something else… :(
That's not an inherent limitation of the VM at least, just of the current software ecosystem. It would be possible and practical to make a tiny unifont-based Unicode text library. Though handling bidirectional text, joined scripts and vertical scripts would be something else… :(
This illustrates just how complex even the "basic" stuff turns out to be in practice. Text rendering hates you[1]. Even if you take obvious shortcuts/compromises like limiting yourself to monospace, you'll get bitten by "double width" characters. Kudos to those who try, rather than bundling a copy of Chrome with their chat app.
[1]: https://faultlore.com/blah/text-hates-you/
[1]: https://faultlore.com/blah/text-hates-you/
I tried to tell other people that (and more; there are even more problems with Unicode than mentioned in that article) but they don't believe me and they believe that Unicode is good anyways.
I design my own programs and specifications to avoid Unicode as much as possible, even when multilingual text (sometimes even in languages that Unicode does not have) is desirable.
I design my own programs and specifications to avoid Unicode as much as possible, even when multilingual text (sometimes even in languages that Unicode does not have) is desirable.
Yeah, that's why ASCII with a few of accenter chars and glyphs [áéíóüñ] would be enough with just a small extended western table. Optional as a library, OFC.
By default you write ASCII chars from a table with a "display" device. I prefer uxn's simplicity over my own complex locales. Anyway, as I said, a tiny .tal code for extended chars wouldn't be very big.
Some fonts for uxn (look at the ~rabbit repos at git.sr.ht) already bring extended chars.
Some fonts for uxn (look at the ~rabbit repos at git.sr.ht) already bring extended chars.
> [...] ASCII with a few of accenter chars and glyphs [áéíóüñ] would be enough [...]
Making a bespoke ASCII extension would be a step back - by about 30 years. You don't need a lot of code to support UTF8; if you're concerned about runtime memory usage, you can make your rune type take 8 bits and support only the U+0000-00FF range[1]. It happens to cover all of [áéíóüñ] and a whole bunch of other languages - unfortunately, not my native one, which would leave me gravely upset ;P
[1]: https://www.unicode.org/charts/PDF/U0080.pdf
Making a bespoke ASCII extension would be a step back - by about 30 years. You don't need a lot of code to support UTF8; if you're concerned about runtime memory usage, you can make your rune type take 8 bits and support only the U+0000-00FF range[1]. It happens to cover all of [áéíóüñ] and a whole bunch of other languages - unfortunately, not my native one, which would leave me gravely upset ;P
[1]: https://www.unicode.org/charts/PDF/U0080.pdf
Then you could just implement ISO-8859-1 instead. It is the same range but a simpler encoding, and external programs could be used for conversion if necessary.
1. UTF8 encoding is trivial and everything already speaks it by default nowadays; 2. it is useful to explicitly differentiate byte arrays from text; 3. if you'd change your mind later on and decide you do want to support Japanese (like here: https://100r.co/site/niju.html), you haven't dug yourself into a hole.
1. UTF-8 is not an unreasonable encoding, but it is an encoding of an unreasonable character set and is also unnecessary here. It is better to avoid needing unnecessary conversions that will then be needed in both programs, even though it should not be necessary. Not everything is using UTF-8 and Unicode. I continue to use (and write) programs that do not use Unicode. (And, if it is necessary, conversion program can also be written in uxn; the fact that uxn does not use Unicode does not prevent this; you can implement whatever character sets/encodings that you want to do.)
2. Sometimes it might, but that has nothing to do with uxn. Sometimes it isn't helpful to be differentiated anyways, and sometimes this differentiating byte arrays from text causes problems, too (it isn't really so uncommon).
3. The niju program does not use Unicode and does not need it; it works better without it. If you do want more sophisticated Japanese text, even then there are better ways than using Unicode.
2. Sometimes it might, but that has nothing to do with uxn. Sometimes it isn't helpful to be differentiated anyways, and sometimes this differentiating byte arrays from text causes problems, too (it isn't really so uncommon).
3. The niju program does not use Unicode and does not need it; it works better without it. If you do want more sophisticated Japanese text, even then there are better ways than using Unicode.
The problem it's uxn it's ported to tons of devices. Would utf8 work under platforms like the Nintendo DS or DOS with a simple header file?
UTF8 is an extremely simple and lightweight text encoding. Check out Plan 9's man page on UTF, it would fit on a t-shirt: https://plan9.io/magic/man2html/6/utf
Unicode is also just a representation for text, and a handful of common operations - you work with arrays of characters, rather than arrays of bytes. It was worth its cost on 1992 hardware; Nintendo DS is over a decade more recent.
I recommend studying libutf in sbase[0]. It's not a single header file solution (although utf.h[1] is an excellent place to start reading), but it does provide a fairly comprehensive implementation. There's also a good introduction to Unicode in Plan 9's C programming guide[2]. Even if you choose to only support runes that fit in a single byte, you gain the ability to tell byte blobs apart from text, which is useful both for reasoning about your program, and for future-proofing it, in case you needed to put places like Łódź or Πάτρα on your map.
[0]: http://git.suckless.org/sbase
[1]: http://git.suckless.org/sbase/file/utf.h.html
[2]: https://plan9.io/sys/doc/comp.html
Unicode is also just a representation for text, and a handful of common operations - you work with arrays of characters, rather than arrays of bytes. It was worth its cost on 1992 hardware; Nintendo DS is over a decade more recent.
I recommend studying libutf in sbase[0]. It's not a single header file solution (although utf.h[1] is an excellent place to start reading), but it does provide a fairly comprehensive implementation. There's also a good introduction to Unicode in Plan 9's C programming guide[2]. Even if you choose to only support runes that fit in a single byte, you gain the ability to tell byte blobs apart from text, which is useful both for reasoning about your program, and for future-proofing it, in case you needed to put places like Łódź or Πάτρα on your map.
[0]: http://git.suckless.org/sbase
[1]: http://git.suckless.org/sbase/file/utf.h.html
[2]: https://plan9.io/sys/doc/comp.html
Should do! All the detail would be inside uxn, and the whole idea is that uxn virtualizes away from the underlying environment.
For a more mainstream take on the concept it's also worth to check out RISC-V. Implementing a baseline RISC-V interpreter VM without any extensions is a ~day of work (I've done it; it's a little more complex than their ISA, but not by much), and it can essentially run any piece of software you can throw at it as real compilers can target it. (You still need to supply the rest of the VM though to get I/O and such.)
Retro style gaming based in Forth, low specs, virtual machine ported to nearly everywhere. Kinda like the Z-Machine, but for pixels.
Good for GB style games without battling the Z80-like instructions and without worring if you would burn the physical LCD on a weird cycle timing bug on displaying sprites.
Good for GB style games without battling the Z80-like instructions and without worring if you would burn the physical LCD on a weird cycle timing bug on displaying sprites.
uxn is one of those things I know of and read about for quite a long time, but never end up trying myself. Those "limited on purpose" community-supported systems are a really cool concept.
I had done some stuff with uxn and I wrote my own emulator too (called uxn38); uxn is not too difficult to implement. I think that is is better than some similar designs. I am glad that it does not use Unicode. There are other advantages, too. But, there are some problems, such as the lack of seeking files, and the friend port is no good because it ends up being too complicated (even if it seems simple).
2021 interview with 100r https://esoteric.codes/blog/100-rabbits
Devine and Rekka are great and I love what they do and how they do it.
A very inspiring duo.
In another life maybe.
[0]: https://100r.co/site/dry_toilet_installation.html