They also screwed up the API token detection and also blocked a bunch of 1st party tool users for ~24h.

Support consisted of AI bots saying you did something stupid, you did something wrong, you were abusing the system, followed by (only when I asked for it explicitly) claiming to file a ticket with a human who will contact you later (and it either didn't happen or their ticket system is /dev/null).

(By the way this is the 2nd time I've been "please hold" gaslit by support LLMs this exact same way, the other being with Square)

What are x bookmarks? I think I need a concrete example.

Also what are its actual features? What does it export? High resolution media? Author information? Replies?

But also, this feels like a 5 minute vibe coded project you put together on a whim to try to make money. 50% of the description on every page is about paying you. I want a good twitter exporter, but I want something the author is invested in enough that it might conceivably work 5 months later too.

X is Twitter. You bookmark practically anything (post, comment, quote) and can find it later in one place.

I did put it together on a whim because I don't trust that something won't happen to X.com some years in the future with Elon and you legitimately cannot export your bookmarks from X. If that happens, your bookmarks will be lost.

Yes, it is a paid product because I put serious time into it and I designed it to be something I would use myself (even if I make no money off it).

Features are really simple. The annual license is $4.69 because I expect people to export their bookmarks only once every few months.

1. Chrome extension to scrape your bookmark page. You can find plenty of extensions that will do this, but they give you a JSON/CSV file that's not very useful.

2. The viewer is paid. You import the JSON from Step 1 and it loads all your bookmarks.

3. You can tag your bookmarks. You can download the media files embedded into each bookmark. You can delete your bookmarks.

4. You can export your bookmarks as another JSON that you can save or give to a friend (if you trust them with your private data).

5. I may add AI tagging for Claude to suggest tags for your bookmarks.

The non-fixed type system per https://ja.wikipedia.org/wiki/%E5%92%8C%E6%99%82%E8%A8%88 was called "futei jihou" (non-fixed time system), same with other sites https://museum.seiko.co.jp/knowledge/relation_16/ . "Temporal hour system" seems like the correct translation.

My guess is that "wari koma" here means basically "separated panels" (wari: broken, koma: panel). Wadokei means (traditional) Japanese timepiece.

Just double checking, but the day and night were each given 6 hours, not 12.

Why don't they just sell docker containers in the cloud? Why are they wrapping it up as a business-only local development compliance thing? And since they haven't published any pricing, why is it so expensive?

Once you're in a cohort how do you actually use it?

You get an API key

Moving closer to the screen would increase the FOV.

This is a setting by the site owner though, isn't it?

Years ago I was searching for why emulators don't recompile to native bytecode and it seemed like the consensus at the time was that JIT etc was faster. I can't find it now, but IIRC I remember replies from maintainers saying it was a bad idea.

What changed since then, since this seems to be a trend? Is this more for more modern systems that have more static code?

Static code. Also, very fine details of the machine because less important.

When emulating a NES (for example), you really have to emulate every register, how registers change, and also weird effects like instructions that take longer to read or write values, as games rely on that stuff. Once you have modern systems where much of the code was originally C, it becomes less important to ensure every register has exactly the right values when a subroutine finishes in most cases, you can rely that (most) of the code follows standard calling conventions.

You really don't. Most of the time the code will be doing normal things. So you can have other code that also does the same thing.

>and also weird effects like instructions that take longer to read or write values

The percentage of a code in the ROM that depends on such things is a small percent.

The problem with NES emulation (having written a fairly bad one) is it can be hard to predict when you need to be careful, particularly in the presence of self-modifying code and interrupts. If it was easy to figure out, emulators wouldn't have to keep such careful track of this stuff either.

It's a combination of things. The floodgates were opened when the N64 recompiler popped up a couple (?) of years back. Really got interest going.

I also think tooling got better, and with the advent of AI engineering it made all of this a lot more accessible.

It depends on the platform you're targeting.

Something like a SNES will always have the same hardware no matter what (okay, leave out the expansion chips inside cartridges, or fold them into "same hardware").

Something like a PC will have any old random shite you care to plug into it.

Something like an Xbox 360 is kind of halfway between.

With a SNES you can rely on the fact that a vertical blanking interrupt will happen 50 times a second no matter what, and you get so many instructions before your video output is halfway down the screen no matter what, and then if you want to play silly games like changing a PPU register to dick about with the screen mode you can. You have to take into account things like it taking more time for certain types of memory access like if you cross a 256-byte page boundary, but since when you get down this far you're doing it all in assembler you can place your code and data exactly where you want to get exactly the behaviour you want.

When you emulate this, you must emulate every aspect of this behaviour correctly or things will fall apart. Think about things like the "open bus bugs" that trip up emulation - some games rely on silly tricks like expecting the capacitance on the pins of the chips to hold a value like a crazy single-byte DRAM for a moment while they look somewhere else. If your emulator just goes "okay no devices are enabled so the bus is simply pulled high to 0xff" that will fail.

With a PC you've got a wider variety of hardware, and a deeper level of abstraction. You don't have to care about flipping registers at just the right time, you just throw some textures and polygons at the GPU and let it do its thing. It'll tell you when it's ready for more. This is why you get the same experience between your AMD GPU, your NVidia GPU, your Intel GPU, and hell why not just have software OpenGL too (because it's slow but that's how we used to do it in the olden days).

So if you wanted to run a SNES game on modern hardware you'd be better off emulating the hardware directly, bugs and all, and then running the "real" game binary.

But if you wanted to run something like an Xbox 360 game - written using "modern" development techniques, where a lot of the hardware is abstracted away behind drivers and libraries - you might well just break it down into functional blocks of code, rewrite them for your native CPU, and shim the calls to the libraries to talk to the ones you have on your native system.

A bit of code that rotates a set of vertices and flings them at the GPU will look pretty much the same in C on any platform, but it'll compile to very different assembly language. That's okay though! If you understand how the instructions relate to the data you can just kind of translate one set of opcodes to another and expect it to be more-or-less right. You can even (kind of) do this automatically!

This isn't obvious to me. You can have javascript external to the svg for making it interactive, it doesn't have to be embedded in the svg. And the interactivity for json canvas isn't embedded in the canvas json either.

If we're adding external interactivity, we're treating each as a custom DSL format and need to evaluate them as such:

JSON Canvas:

    graph primitive
    easier to read, write, and reason about
    harder to render

SVG:

    path primitive
    easier to render
    harder to read, write, and reason about