swap

Check for error after cons'ing term.

pop_any()

dup

stack function.

pop()

Move pop_list().

No reason to pass expression to function.

pop_list()

Kind of a misnomer, you have to take the tail() of the stack yourself.
This function only returns the list from TOS.

Minor cleanup.

Swaack and error macro.

Use clear, set up for swaack.

Clear.

Did i not commit this?

A start on the joy() interpeter.

Minor cleanup.

Catch unbalanced brackets.

Minor cleanup.

Only allocate strings once.

That for loop in hash_fragment() is the gnarliest I've ever written.

Combine tokenizer and parser.

I'm pretty happy with this. It's iterative rather than recursive so you
won't blow out the call stack if you want to parse a million brackets
(intermediate results are stored on (another) little stack.)  It scans
the string and builds lists and sublists as it goes, without wasting
cons cells.

Thread error handling through tokenizer.

It turns out the error machinery was working...

So I was memset'ing the hash table and string table /after/ setting up
the left- and right-bracket tokens! So then when I tried to print the
token list and ht_lookup() dutifully set the error code when it couldn't
find the strings in the hash table, the system properly quit printing
and halted.  D'oh!  That was a subtle one.  Obvious in hindsight.

Fold parser code into joy_types.c

Add some docs, minor cleanup.

It seems to be working.

It took all expletive-deleted day but I finally nailed it down.  In the
end the last bug was I was decrementing a stack pointer /after/ trying
to load the item at the (empty) top of the stack.  Classic.

I still need to make it not re-allocate strings that it has already
interned, but beyond that I think it's fine.

tokenate() and reverse_list_in_place()

Use symbols for tokens for brackets.

Try a different tack on the parser.

Almost working parser.

Minor cleanup.

Some printing to see the machinery in action.

Joy parser in NCC.

A start on error handling.

Double hashing w/ extra bits of hash.

A start on a hash table for symbols.

Joy in UVM NCC code.

A bunch of stuff.

Minor cleanup.

Use defines to abstract font choice.

Clunky but now you only have to change the font name four time in one
place rather than N times in N places, eh?

Writing C again for the first time in ages (this and the Joy
interpreter) the using the preprocessor is like stone-age
meta-programming, from the lens of lisp it's like, "you do what to your
source code?".

A different font.

It's easy enough to substitute a different font in the call to
Imagemagick's `convert` tool, but in the case of pixel fonts, it will
scale them, so you're not getting a proper bitmap of the pixels, you're
getting a kind of screenshot of the pixels.

I want to make a different machinery for bitmapped pixel fonts, and I
want to make a simple DEFINE-based way to pick them without having to
edit your source code,  e.g. #define font_data font_PublicPixel_22_data
yeah?

After that, simple affine transforms for fake 3D..

Wu-ish lines.

Mostly working Wu-ish algorithm.

Minor cleanup.

Cicada bg, needs work.

Not as pretty as I'd hoped.

Putting a pin in Wu lines for tonight.  I'll lick it in the morning when
I'm fresh.

I clearly don't know what I'm doing.

Go to sleep!  Think, then type!

Is this fun?  Kinda.

I should break out the graph papaer and Abrash's Black Book and figure
out WTF I'm doing rather than just noodling around, eh?

Horizontal proto-Wu.

Horz/vert lines and boxes.

Aw, exit() doesn't work?

In any event, I can live with esc-to-quit (is there a callback to hook
into?)

But KEY_BACKSPACE doesn't seem to fire?

Maybe worth a bug report?

Ha ha!  The escape-to-quit behavior...

...seems to be baked into the UVM.

Add if..else ladder for keys.

I just noticed that I have KEY_BACKSPACE for the exit key rather than
KEY_ESCAPE as I had thought, yet escape key surely does exit the
program!

Escape key exits program.

minor edits

I don't think this is any better?

Draw chars when you click.

Pick a letter at random.

I wasn't checking that the destination values were not less than zero,
which let you click at the top/left edges of the screen and therefore
the carefree_alpha_blend_blit() would try to write to areas outside the
framebuffer.  I started to see "zalgol" pixels in the letters, so I'm
guessing the pixel data is getting stored just above the framebuffer,
which makes sense (because that's the order they appear in the source
code and this is a simple system!)  When you click at the top of the
screen it was writing pixels in the font data, eh?  Then when you click
elsewhere on the screen you get extra pixels with your letterforms and
it looks like Unicode Lovecraft puns.

A sort of blit.

Depend on graphics.h.

Move draw_background to own file graphics.h.

Switch font size to 22.

My old eyes ain't what they used to be.

Minor cleanup.

Try changing the font size.

Display font in anti-aliased glory!

Alpha blend font FTW!

Okay, alright, skipping blank pixels.

We have a character on the screen!

It looks like potato because no alpha blending yet, but it's certainly
there!  I don't like the spelling of the C code, but who cares?  It
works.

A start on draw_char().

Rename anim_callback to draw_background

because that's what it is

i can haz font data

ooo that's a finicky parser tho

Early days.  It's all good.

(But damn those Rust tracebacks, what a useless pile of text.  i know
the problem is in the parser!?  why is it showing me all the rust
internal crap and none of the actual stack trace of the ncc code?  I
mean, look at this thing:

    sforman@bock:~/src/Joypy/implementations/uvm-ncc % setenv RUST_BACKTRACE full
    sforman@bock:~/src/Joypy/implementations/uvm-ncc % gmake
    cd /home/sforman/src/uvm/ncc ; cargo run /home/sforman/src/Joypy/implementations/uvm-ncc/xerblin.c
        Finished dev [unoptimized + debuginfo] target(s) in 0.01s
         Running `target/debug/ncc /home/sforman/src/Joypy/implementations/uvm-ncc/xerblin.c`
    thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ParseError { msg: "expected identifier", line_no: 139, col_no: 20 }', src/main.rs:98:43
    stack backtrace:
       0:          0x10d741f - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h919bef3d5abebde9
       1:          0x10ee08e - core::fmt::write::h6413343c5226105f
       2:          0x10bce85 - std::io::Write::write_fmt::had0ddcb25461208f
       3:          0x10d71d5 - std::sys_common::backtrace::print::h5ed9962f90e9b258
       4:          0x10c6eff - std::panicking::default_hook::{{closure}}::h3978a8a8f5c1f893
       5:          0x10c6b91 - std::panicking::default_hook::h0cdbdd5201407347
       6:          0x10c75bb - std::panicking::rust_panic_with_hook::h15bc8b6da20c2af3
       7:          0x10d7777 - std::panicking::begin_panic_handler::{{closure}}::h082a693f9436206b
       8:          0x10d756c - std::sys_common::backtrace::__rust_end_short_backtrace::h56343aa2331ff455
       9:          0x10c7142 - rust_begin_unwind
      10:          0x10ed3d3 - core::panicking::panic_fmt::hf18d1d226927e137
      11:          0x10efa93 - core::result::unwrap_failed::ha5725a0b4539229c
      12:          0x105b505 - core::result::Result<T,E>::unwrap::h0f336a18a308049e
                                   at /wrkdirs/usr/ports/lang/rust/work/rustc-1.66.0-src/library/core/src/result.rs:1113:23
      13:          0x1068314 - ncc::main::h189929cbc5450262
                                   at /usr/home/sforman/src/uvm/ncc/src/main.rs:98:20
      14:          0x10611cb - core::ops::function::FnOnce::call_once::h8146a3c8fa28ca14
                                   at /wrkdirs/usr/ports/lang/rust/work/rustc-1.66.0-src/library/core/src/ops/function.rs:251:5
      15:          0x106e13e - std::sys_common::backtrace::__rust_begin_short_backtrace::h4e9f285841c55b79
                                   at /wrkdirs/usr/ports/lang/rust/work/rustc-1.66.0-src/library/std/src/sys_common/backtrace.rs:121:18
      16:          0x1069fa1 - std::rt::lang_start::{{closure}}::h8ca60a785648e691
                                   at /wrkdirs/usr/ports/lang/rust/work/rustc-1.66.0-src/library/std/src/rt.rs:166:18
      17:          0x10c1514 - std::rt::lang_start_internal::hadf3843363799440
      18:          0x1069f7a - std::rt::lang_start::h3ee6ffb894d9f1d3
                                   at /wrkdirs/usr/ports/lang/rust/work/rustc-1.66.0-src/library/std/src/rt.rs:165:17
      19:          0x10684ee - main
      20:          0x104f472 - _start
                                   at /usr/src/lib/csu/amd64/crt1.c:76:7
    gmake: *** [GNUmakefile:11: /home/sforman/src/uvm/ncc/out.asm] Error 101

There's ONE LINE from the ncc source: uvm/ncc/src/main.rs:98:20 which is a call
to parse_unit, but it's the following unwrap that seems to be causing the error
message?

This compiles.

I think I got it.

Adding a function and it still compiles.

This compiles and runs, include font.h but don't call init_font_data() yet.

So far...

Drawing pixel per mouse move is slow at 1280x800.

So let's just use a smaller screen for now, eh?

Repair damage during mouse move.

This is a compromise between updating the screen every frame (which
takes ~60% CPU on my old no-GPU hardware) and repairing damage from e.g.
dragging offscreen and back on, or covering and uncovering the window
with another window.

Ignore tryrax binary.

Let's use uvm.

https://github.com/maximecb/uvm

Allocate a buffer just large enough.

I figure that's worth the overhead of iterating twice.  It's happening
during a user interaction so there's plenty of time, eh?

Break up completion into simple and prefixed cases.

Handle completion of symbols with a prefix...

You can type stuff and then tab and it will work.  Before it would try
to complete the whole line, which didn't work.

Linenoise with rax.

Let's use rax to generate tab completions?

Line editing with linenoise.

https://github.com/antirez/linenoise
https://todo.sr.ht/~sforman/thun-der/33

Move and rename push_thing_onto_expression().

Minor cleanup.

typedef FTW

Wrap it?

I figured out how to spell it.

A little macro.

Let's use the idiomatic functions, eh?

That way the code is simpler and there aren't error messages scattered
all over the place.

How would you compile this?

    fn [+] step

SWIProlog

eval_joy_ast

A simple Joy-to-AST program.

Written in GNU Prolog, doncha know!?  :D

vlist.c

Minor cleanup.

Minor cleanup.

Minor cleanup.

pick and length

Minor cleanup.  This is pretty nice.

It's hard to believe this datastructure is so obscure!

Double list size each time; neat demo.

Set correct last_used when creating new vlist.

() is the null pointer