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

Presumably the combination of concentration, fine motor skills, and language use.

GGP presented it as if there's something unique to handwriting that's important for cognitive development. I have guesses too, but I'd like to know what research etc led to this claim, and if there's more details or nuance.

> PS: If you’ve read this far, congrats and happy first of April!

It's April 2 here. I'm kind of wondering how good an idea April fools is on the global internet.