Notices by mcc (mcc@mastodon.social)

He has rampaged over America as much and as long as he has because nobody wanted to accept the costs of stopping him. Nobody *wants* conflict. Every individual person who could have done something, looked at how doing something would interfere with their other plans, and chose themself. Decided to take the easy path, pull out an umbrella and not try to stop the rain. So it got worse. He saw it was working, and did more. And more.

The question is whether the world will react the way America did.

@jackpearse Well, that's interesting because that's something that would have happened even if Harris were President right now.

Wonder if which countries have good or bad responses to the Trump tariffs will be partially determined by whether the country's time zone happened to have their leaders awake or asleep during the block of time between Trump announcing the tarriffs and the markets opening in the US the following morning

(I am choosing not to use a CW on this post because this is very anodyne. If you reply with in-depth analysis, I suggest a pol CW.)

So I added some debug prints to the GC and upon looking at the outputs I *immediately*, intuitively understood what was wrong and how to fix it (you'll be unsurprised to learn it was an off-by-one error… every pointer was being updated to its correct new value minus one).

I made the fix. I reran the test.

It failed in the exact same way.

¯\_(ツ)_/¯

Okay the garbage collector now "works"! In the sense that it can remove garbage from the system. (The problem before was I have a list of roots which includes any item the VM is currently operating on,, and roots were… never… getting removed… from the root list.)

It still does *not* work, in the sense that after the collection every pointer in the system is pointing to the wrong object. Oops!

Can't sleep. Distracting thunderstorms. Stomach's angry.

Only one thing to do: Stay up and learn to write a Drop implementation

(I think this is probably pretty simple, it's just one of a few relatively basic Rust things I haven't yet turned out to have a need for)

Yes that's right I'm implementing OBJECT POOLING

Update: I wrote the tests, and it actually doesn't work. But I know why.

I do suspect I am going to write many more than 62 lines of code trying to *test* this.

Today I fixed it and now I have a 62 line GC (7 lines whitespace/comments) which is *slightly* less efficient than it could be due to every object being temporarily copied to a temporary heap object before the new space.

The original design *could* be made to work if I write my own implementation of Vec, which would be easy but annoying. The problem is I need to push to the end of a Vec while a mutable ref is held to one of its members, which *is* Rust invariant-safe, but not borrow-check-legal

Yesterday I wrote a copying garbage collector in 52 lines of code and in about an hour. It was I was *so* happy and satisfied and the code was so clean and elegant. Then I realized the way I had done it was incompatible with the Rust borrow checker and spent another hour or two trying to figure out how to work around it. The Rust Experience.

It's useless to anyone but me, but I am so proud of this little script.

https://github.com/mcclure/emily/blob/stable/develop/regression.py 2014 version— 217 lines

https://github.com/mcclure/bitbucket-backup/blob/archive/repos/emily-python/contents/develop/regression.py 2017 version-- 466 lines

https://github.com/mcclure/lisp0-experiment/blob/unstable/tools/regression.py 2024 version-- 450 lines

It's not "portable". I have to rewrite it a bit every new project I port it into. It's simple and it's adaptable and it does *exactly* what I need.

My "Test cases" are a few dozen programs with embedded comments explaining what STDOUT should be seen when they're run.

I've been writing all my new language's test code prepped to work with the regression test runner script I used with Emily and Emily2. I didn't actually have the test script itself in because I had to fuss with it a bit to teach it to run cargo before invoking the interpreter (so that the interpreter exists). Ran it and…

5 tests failed of 13.

That's good!!! That's extremely good!!!

Because that first failure? quote.ls0?

Looked at it. That's a real bug!!

The test runner found a bug ALREADY!

If you look close at that sample, you may notice the thing that distinguishes this lisp from other lisps, and the idea I wanted to play with that had me writing this in the first place: There are no functions in this LISP. Or rather there is no distinction between lists and functions. You put a list as the first item of an execution list, it just interprets it as a list of lines of LISP and executes them one by one. I was trying to make "TCL but LISP" and this is what I thought that would mean

I think maybe when I have this working, rather than trying to write it up I might make a short YouTube video about what makes it interesting. This would save my poor RSI and would also be a good way of getting some practice vlogging/kdenliving.

I had some time in a waiting room today, so my nameless experimental LISP now supports nested expressions as well as a slew of math operators.

I also realized (I skipped ahead a bit without fully testing the reader) that the parser chokes on negative numbers. "-5" is treated as a variable named "-5" instead of negative five. Oops.

Next: time Fix -5 and '()
[ which may in fact get me all the way to functions, because I'm doing things a little odd here ]

Note: Yes, true and false are T and nil

Andi McClure is writing a LISP. Why is she writing a LISP?

Update: The world remains predictable and understandable

*Blinks* I… hm.

I just sort of wrote a LISP interpreter, mostly over two days. It is 110 lines long (the interpreter part; this is not counting the GC or the reader/parser). It felt suspiciously straightforward to write, I didn't like, *design* it, I was just like, yeah I've written an interpreter core loop before? Do that again but in Rust. It just sorta fell out.

I am *terrified* by the question of what will happen if I attempt to run this.

To my surprise I get to the point in the LISP evaluator where I handle function return and I suddenly discover that it is easier to implement tail recursion than it is to not implement tail recursion. This is the second time this has happened in my career

Just got the "reader" working… I think next step is the garbage collector. I may or may not implement regression tests first. I've got a reader so that means something I can regression test.