> cassette deck on his desk

Greybeard reporting for duty: https://en.wikipedia.org/wiki/Commodore_Datasette

Looks like the C64 is behind it (underneath a..?) and there’s a small corner of 5.25” diskette station further back.

Probably not his daily drivers.. :)

Yeah, behind datasette it looks like there's C64 C parked, and above is a laser 300 (which makes sense if guy is australian) and we can also see 1541-ii behind that, on the top.

Right, laser 300 was called the VZ300 here. I'm out of desk space so I had to put the VZ300 on a stand above my C64C. Maybe AI can finally help me code some C64 and VZ games. :-)

If only! It's kind of a blessing and a curse for us who still code for c64 (demo scene). It looks like llm may help you, but it's usually gibberish 6502 asm. I've seen similar with z80 but on spectrum.

I think generating assembly with an LLM would be like copying from a magazine back then: nothing learned.

But I wonder, do LLMs help explain chunks of 6502 assembly code, in your experience? Say, if one was learning.

yeah that certainly does happen. Especially if you give it the context of the machine since 6502 itself and opcodes do you no good unless you know the memory layout/ map which is in a sense what machine you're on. NES and C64 are 6502, heck even SNES is but 6502 opcodes are nothing since action is in memory you're interacting with.

When you provide context and the memory map, it does help explaining what algos you're looking at and what's going on. I've had a bit more luck with gemini rather than claude on this vs in general claude codes better. ChatGPT is for the most part lost in hallucinations.

A.B.K. Always Be Knolling.

https://www.youtube.com/watch?v=s-CTkbHnpNQ

URL shorteners significantly increased in popularity as Twitter did. There was originally a 140 character limit that became quite squeezed when adding most URLs, especially to blog posts where the title is part of the URL.

Later, adding things like analytics and tracking (eg: not just in social media, but also in email campaigns) became another reason to use them, especially for those less tech inclined.

For those interested, there's a new set of hour-long videos on the PBS site that has more about the recent Pompeii excavations.

There are four so far. Not sure if there will be more: https://www.pbs.org/show/pompeii-the-new-dig/

I've heard 6 at Fordow, and 30 or so Tomahawks across Natanz and Isfahan.

They carry 2x each, so 6 planes 12 bombs. And then single plane natanz, 2 bombs

I heard the same as well, the reference was to an interview Trump gave on Fox.

My expectation is that it was 3 rounds of 2 MOPs, hedging bets and potentially cresting a larger hole than drilling a hole one bomb at a time.

I think they may be asking about the CPU cache.

You have to go out of your way to make a hash that doesn't fit into L1, so again they're all basically the same.

You'll probably end up fitting entirely inside the reorder buffer plus a sequential stream from memory, with the actual caches almost irrelevant.

Sure. Any worthwhile hash function will fit in the instruction cache. But there are ways to make more or less efficient use of the data cache.

> Any worthwhile hash function will fit in the instruction cache.

Yes, I'm talking about the data cache.

> But there are ways to make more or less efficient use of the data cache.

How?

You need to touch every byte of input, and nothing should be faster than going right through from start to end.

> And if you're storing enough state that it doesn't fit in your registers, the CPU will put it into the data cache.

And there's 150+ registers in the actual chip.

But my argument is more that there isn't really an efficient or inefficient way to use L1. So unless you have an enormous amount of state, the question is moot. And if you have so much state you're spilling to L2, that's not when you worry about good or bad cache use, that's a weird bloat problem.

_Fitting_ in the instruction cache isn't hard, but you'd also ideally let there be room for some other code as well :-) For a hash map lookup, where the hashing is frequently inlined a couple of times, code size matters.

I haven't used Claude Code, but I have used Windsurf, Cursor, and Continue. They all do well with their own "rules" files. I essentially understand that as something similar to a System prompt sent before a chat session. I even have pretty specific rules on styling that are unique to me, and it generally follows those.

It's also worth asking what rule it would need in order to follow the rule. On occasion, a rule I've added isn't quite followed. So I'll respond immediately pointing out what it did, that the rule is in the file, and then will ask it to tell me how I should modify, or add to, the rule in order for it to be easier to follow.

I'd imagine Claude Code has something similar that might be worth looking into.

I have used Joplin daily for years. The only thing I _REALLY_ wish they did was allow you to just store and display notes as plain text.

Instead, there is always either markdown or rich text formatting involved. And there's no ability to disable that.

That always seemed odd to me to force that kind of decision on users.

I don’t understand… occasionally I use markdown and switch to the viewer mode to see it rendered, but most of the time I stay in the editor mode where everything is just plain text.

I do that. And it's not bad. But it still doesn't treat the input/interface strictly as plain text.

I can't remember all the little things that happen, which wouldn't happen in a plain text editor, but if you type hyphen-space, then hit enter, the line is deleted and your cursor stays on that line instead of advancing to the next.

It's a trivial example, but things like that happen.

OK, I can reproduce that on the iOS Joplin app, but not on the desktop app. Weird.

I suppose you can enclose whole notes in a code block (```)

This is true in the US legal system. This is far less true in the general social system.

In my "social system" no one is less trustworthy than the CIA.

For people interested in this sort of thing, I recently published a blog post looking at counts of HTML tags and their attribute values from a 2.9B page Common Crawl dataset. [1]

There's also a SQLite DB available to download of the top 1k tag+attr+value combinations. [2]

[1] https://webparsing.io/blog/hidden-in-html-parsing-page-layou... [2] https://webparsing.io/data/commoncrawl-2024-11-html-tags-att...

I think someone who works on Chrome did something a few years ago - though I can't remember exactly what they were trying to figure out.

If anyone is interested in an example of how ZSTD's dictionary compression performs against standard gzip, a number of years ago I put together an example using some Common Crawl data.

"I was able to achive a random WARC file compression size of 793,764,785 bytes vs Gzip's compressed size of 959,016,011" [0]

In hindsight, I could have written that up and tested it better, but it's at least something.

[0] https://github.com/benwills/proposal-warc-to-zstandard?tab=r...