tnelsond4

I use dwm and brave and 10 tabs or so and I'm usually at about 2-3gb of RAM used.

Inspired by BusyBox 9 years ago I wrote a multicall binary that you rename and manipulate to solve puzzles and learn to use the shell in the process. I should do more with it.

https://github.com/tnelsond/learn-linux-commandline

I meant to reply to John who was asking where someone was getting the 32768 number from. No idea if it's true, but that's the significance of that number.

Yeah that's the lore page does look like there's no downvoting submissions then and people are just trolling.

It's the maximum value of a signed 16 bit integer. But there's a GitHub page that explains hn lore.

Tvtropes really just categorizes and explains every possible archetype whether that's character, plot, or just anything that appears in a story. People lose a ridiculous amount of time reading all the tropes. A trope is like a cliché but it's not, because cliché's are hated whereas tropes can go either way.

For individual notes there's https://tvtropes.org

I was writing emscripten and getting lots of errors and problems and it wouldn't run at all, but rust with bindgen just kinda worked automatically.

My theory is that LLMs have the brains of hipster coders with their proclivity for rust and node etc.

Someone really should do some tests.

I was trying to get my c wasm module down in size and emmalloc is pretty small, but it requires a lot of js glue to make it work, but using a small allocator like walloc requires no glue and it's insanely small. I got my module down from 27kb to 17kb.

I'm gonna read this article and try making my own allocator next.

People have to talk about what's new and LLMs are new and they accelerate the creation of new things. And with that comes the appropriate backlash. The hate plus the love makes AI topics more and more discussed.

But I hear you, it feels like all the AI stuff has just cemented that I want to read stuff by humans and make stuff on my own. Artisanal code written by people like Bellard will always be more interesting than any AI thing.

Yeah that's probably the only thing in the world that could be scarier than the electron app they were replacing

Yeah, last year I discovered that AI writes better rust than C, so I switched to rust and it made some quick good code that it couldn't do in C.

But when I wanted to optimize and edit and reorganize bthe code it was difficult, so I did a rewrite in C and it was lighter and faster and simpler and less headache.

C for humans, rust for AI.

If you want a language that doesn't change it's hard to beat C which has only added extremely minor non-compatibility-breaking features every 15 years or so.

Not sure what the author is on about about it being difficult or not practical when most all of Linux userland is written in it.

Nice resource.

Makes me want to make a full game using JavaScript inside an SVG image.

Yeah, C is king right now.

If we could get jbig2 native support in browsers we could do monochrome black and white images at ridiculously small file sizes.

A page of sheet music can be as small as 8kb. I'm using a wasm decoder right now, but I could forsee using css filters after the fact to make it look less sharp and aliased

And this is how everything becomes a crappy pwa apps. (Though let's be honest, most Android apps already are)

Yeah, I had Claude generate me the jbig2 to 1-bit png wasm module from the jbig2 source so that there'd be no dependencies on zlib or libpng. Then I aggressively removed functions from 97kb down to 17kb. So if it's missing functions you need you may need to reset the files to the .bak and recompile.

Little endian. x86 and wasm have the same endianness so it's very straightforward. If I wanted to enable support for reading and writing on big endian systems I could patch a few lines very easily, but it seems to be a consideration unnecessary for most uses.

Instead of doing multiple columns, there's some of that with secondary and tertiary indexes, but mostly it's just key value.

To make the data more relational I find it's more natural to just have additional "columns" in separate peak files and when the peak files are queried they can be combined by headword. This is kinda like what parquet does putting all of one column together.

I could make PeakSlab have columns and have it query based off specific columns fairly easily, but it was a design decision to make things more tag based and less column based. I like that it's more flexible and less rigid in structure.

SQLite keeps everything relational and their raw filesizes are 50% larger than a .peak file, not sure what's exactly to blame, but I'm optimizing for small filesizes.

Yes this does seem almost exactly like what PeakSlab is doing. I'll have to investigate more how SSTables and memtables work to see if there's any improvements or anything to glean from them.

I'm storing null delimited sorted strings with an index that's an offset to where that entry begins, so if I wanted to do memtables for writing I would have to have two memtables and merge them on write? I've been considering this exact approach.

Even on warm start PeakSlab is twice as fast. It's not just download size, it's execution speed, zero copy, database decompression, etc.

That's why PeakSlab is written in c, because what's faster than casting the whole database to a struct? ;-P

I'll definitely have to look at this. I'm using binary search right now because it's fast enough and I understand it better, but I might replace it with hashes at some point.

I must've messed something up, but I remember some joins (was it full outer join?) being unbelievably slow? Was I doing something wrong?

I'm solving a simpler problem. Just making cross platform dictionary progressive web apps with indexes and full text search and HTML tags and uppercase letters inserted back into the text on render so they don't interfere with search.

SQLite is 1.2mb in combined wasm and JavaScript and not really designed for my use case, so I would have to add all the things i need anyway like compression and HTML tag insertion. For my use case which is just for pwas SQLite takes too long to load and the files are too big and the search isn't tailored. So I made something else in 38kb instead

Works on my wife's old iphone. I don't have a mac to test things on.

Even BerkeleyDB tries to be mutable. What I'm doing doesn't need the mutability so it's much more similar to dictionary formats (though probably simpler) than it is to a database. Though a lot of people do use full databases for immutable dictionary key-value stuff. I just couldn't get any database to work well enough for a pwa dictionary.

Yeah, that was my experience with Grok, whenever I gave it a file with over 400 lines it would just fail to comprehend it or be too lazy to write too much at a time. Splitting stuff up into separate files helped.

I love using zstd, it's so fast to decompress. I especially like that the JavaScript decoder is 8kb and still really fast. Though the 25kb wasm decoders are about twice as fast.

What are the advantages or reasons to use zstd in a 7z container versus just .zst?

Yes, because originally when I started PeakSlab it used the SQLite wasm build.

Generate it one time from a source tsv file or folder of media.

Believe me, I tried sticking to SQLite or aard2 or stardict, they just were fundamentally inadequate with no good pwa cross platform tooling.