It's in the air

https://thomashunter.name/posts/2025-03-23-post-apocalyptic-computing

On 2025-03-26 04:44, Virgil Dupras wrote:
> Hello all,
>
> The article is there:
>
> https://www.wired.com/story/forth-collapse-os-apocalypse-programming-language/
>
> Some nuances that I wish I had communicated more effectively, but all
> in all, it's ok. People wanting nuances can come and read the walls of
> text on the websites.

Hi!

I've been cleaning some things up these past few days, I've created a 
collection of single-file implementations of most of the utilities I use 
daily, I feel like these might come in handy to kickstart a duskOS 
desktop experience.

https://wiki.xxiivv.com/site/utilities

I'm putting the final touches on a graphical front-end for the 
self-hosted assembler, it should be ready in a day or two.

I'm doing this for someone who works entirely from a NDS, but this will 
be nifty on Dusk as well, so you can assemble without having to go

Hey Virgil and everyone,

I figured this would impact the uxn implementation, but I've recently 
rewritten the C core using mostly `int` whenever possible and manually 
handling the masking of bytes and shorts, there's hardly any place where 
using char can't be replaced with a int, and when a byte is specified, a 
0xff AND mask does the job.

I've been super busy with uxn recently, there's a whole bunch of desktop 
utilities(spreadsheet, calendar, etc..) that might be useful to get 
started with a Dusk desktop system :)

https://wiki.xxiivv.com/site/utilities

I agree with your impression and I'd like to expand on this a bit from 
living inside of Macintosh world for a few months two years ago.

One of the most exciting thing to me about the ecosystem, despite it 
being closed, is how it allowed for so much extensibility. The docs were 
great and that lead devs to create customization tools that are equally 
nice.

During that era, Apple released ResEdit, which shows an incredible gap 
in philosophy against today's Apple devices. It seems unthinkable today 
to even imagine them making available something like this. I often think 
about ResEdit, it required a certain know-how to use properly and not 
mess up your computer with it, but there was a trust there, that is gone 
now.

Hi everyone,

Sorry I've been quiet on the list, I've been working hard at improving
the varvara docs and creating examples for the different devices and
things. There has been a lot of activity lately, between the FPGA
port, the WASM implementation, etc.. I wanted to do a little change to
the File device and I wanted to know what you thought, so those who
don't know, the File device has a stat* port:

> The directory listing for a single file or directory can be obtained when File/stat* is written, and will write the same format as above, including the newline, into the memory buffer. If File/success* reads zero, the file or directory doesn't exist or the region is too small to fit the line.

The only usage I've ever had of the port was ever to get the first 4
characters, which look like these:

There's a ton of good ideas in there, as people implement them in
their projects, I'll refer them to this thread so they can follow your
standards. :)

I'm on the 16-bit relative thing, i'll add soon :)

What would the align directive do?

On 9/5/23, felix.winkelmann@bevuta.com <felix.winkelmann@bevuta.com> wrote:
>> You've been ahead of the curve for most recent features, if you had to
>> think of one from uxnasm38 that you think will soon make it's way
>> upstream, what do you think it would be? :)
>
> I've not looked at uxnasm38, but my personal wishlist is this:
>
> - encoding raw 16 bit relative offsets
> - an "align" directive
>

It seems I'm only playing catch up with your features! it's really
cool you've gotten to the point where you needed lambdas too. I
thought about backward lambdas, but I found it was messing up with
validation a bit, since I never explicitly want to declare stack
definitions to backward local labels, like the entry label in a loop.
But it might be worth adding at some point if someone finds a use for
it. I love using lambdas, it has totally changed the way I do controls
routing, it was very annoying to have to give names to these sorts of
disposable labels:
https://git.sr.ht/~rabbits/left/tree/main/item/src/left.tal#L313

For anyone reading and wanting to have a look at zzo38's assembler,
here's the code: https://github.com/zzo38/uxn38/blob/trunk/uxnasm.c

> Can arity checkers detect infinite recursion? My intuition is that this is the halting problem, and therefore impossible. So removing bounds checks on stack ops leaves the door open for stack corruption and therefore very odd and unpredictable behaviour in such cases.

I'm not sure how this fits with the halting problem, but in uxntal,
the arity checker will not let you recurse if the body that you're
jumping to imbalances the stack, is that an issue you've had with
uxnbal? It validates most recursion that I've found but it's possible
that it misses some specific patterns. I have yet to implement lambdas
support, that one is a bit tricky. Right now, I just mark these jumps
as unsafe.

Hi bd!

Thanks for clarifying and counting cycles, that paints a much clearer picture :)

I've spent most of yesterday playing with this and being to handle
testing code at the uxntal level is very nice, having to flag the
emulator with debug wouldn't be as practical. Oquonie already has a
debug/release file setup, and so it was easy to add stack depth
checking to my vectors.

At runtime, I found that at the root level of each vector, DEI2 both
wst/rst and comparing against #0101 was really nice, what I do is
print the stack(#010e DEO) and trigger a crash(#010f DEO) on
imbalance. This replicates the earlier behavior somewhat, and finding