aks

@froos@post.lurk.org i've since found simple replacements for the remaining stuff i usually miss from libc: qsort: i turned this macrofied qsort back into a stdlib.h-compatible one: https://github.com/nothings/stb/blob/31c1ad37456438565541f4919958214b6e762fb4/deprecated/stb.h#L8721-L8846 malloc/free: turns out the original K&R book ("The C Programming Language") chapter 8.7 has an elegant malloc, meant as a teaching example, but it works: https://github.com/noncombatant/kr-malloc/blob/main/original_kr_malloc.c

@ahihi@anticapitalist.party @froos@post.lurk.org ooh, i'm not familiar with it, but C dependencies tend to be a pain unless they can be vendored. we used to compile with emscripten which provides libc/libm/etc, but ended up doing the nostdlib clang thing because it felt better i guess :) (also, a personal excuse is that emscripten works poorly on freebsd)

@froos@post.lurk.org probably best to avoid malloc/free as much as you can, like the static mem stuff in dough.c, but in audio engines you have samples and delay buffers as these things that can have any size, and may come and go… i'm thinking k&r malloc might be fine for those

@bubobubo ooh Forth! is it available somewhere? i'm curious because it looks a lot like my own ideas for using Forth in live coding, except I also thought about having special bracket tokens / stack values you can use for making array / pattern literals, eg. instead of "c2 c4 2 choose" you could write "[ c2 c4 ] choose", and "{c2 d2}*4" in Strudel's mini-notation might look like "[ c2 d2 ] 4 *"

@bubobubo cool! the ctrl+s for stack - is it a live debugger or something? i once did an ugly neovim/lsp hack where you could debug your forth-like code (see the stack under the cursor) while typing it (also goto next/prev iteration for loops)