DDSDev

DOTS stands for “Data-Oriented Technology Stack”, which is a collection of Unity technology to include their Entity Component System framework, the Burst Compiler, and their Job system.

Each of these technologies have their own descriptions, but a very quick (and perhaps over simplified) explanation:

ECS is a framework where you have entities that themselves have one or more components, acted on by systems. The way these components are laid out in memory and acted upon by systems is typically more cache friendly then traditional game engine design with heap allocated GameObjects that are themselves a mess of pointers (Structs of Arrays vs Arrays of Structs)

Burst allows you to annotate functions, jobs and systems written in a subset of unmanaged C# that compiles to highly optimized instructions for better performance.

The job system allows you to schedule jobs with dependencies in a useful way that can help enable parallelism without manually having to deal with thread primitives. The jobs can also be burst’s themselves and used in a non-parallel manner if you don’t have something easily parallelizable.

To my knowledge, China is a signatory to UNCLOS, but has disputes around it's "islands" in the South China Sea and their relation to the EEZ. I acknowledge that China's relationship to UNCLOS, as a minimum, is complicated and rapidly evolving, but I dispute that they do not have a right to transit passage. Or to be more specific, I would put forward that they would have a plausible argument to claim transit passage.

The United States has not ratified UNCLOS, and regularly claims the right of Transit Passage. In fact, this fact is one of the reasons why Iran claims that the United States cannot enter into Iranian TTW while making a Strait of Hormuz transit - because the US has not ratified UNCLOS, their claim is that the US cannot claim transit passage. For the United States (or any Western Nation) to make the claim that China cannot claim Transit Passage would lend weight to Iran's argument, which you can imagine, they would not want to do.

I do not want to make any assumptions around your specific views on this matter - you may hold the opinion that China could not claim transit passage, however I wanted to interject some perspective that:

1. That may not be universally agreed upon 2. Specifically, the United States and it's allies may not make that argument because it would put them in a negative position for other international disputes.

While what you are saying is technically true, Chinese ships would be allowed to exercise their right of Transit Passage under UNCLOS through the Strait of Gibraltar.

I am the main author behind the JS/TS integration for emacs-ng. I still think it is one of the cooler things I have done that people have taken note of.

I am a game programmer by trade, and I had experiencing embedding JS into projects from a previous engine I worked on where JS was the primary gaming scripting layer.

I love emacs and I love lisp in general - I added JS to emacs mainly to find out if I could do it. I also had a hope that adding JS could expand emacs usage to people that don't know elisp, and have JS be a "gateway" into elisp.

I think that the JS integration is a huge testament to the flexibility and quality of emacs and elisp.

As I have gotten older, I've had less and less time for open source, but I don't consider this project abandoned. I still want to upgrade us to the latest deno. My previous upgrade attempt (which you can see in draft PR at the time of this comment) was a little too ambitious - I tried to move us to a more multithreaded approach, but I think I need to work on this more incrementally.

As a game dev, factorio has always been a title that i would absolutely love to see the original source code for.

Also, for anyone who’s first question was “how is this legal”:

“When asked about the legality of this whole endeavour, they showed great understanding and allowed the project to be released, provided it won’t be used for commercial purposes.”

For anyone curious, Smedley Butler died in 1940[1]

[1] https://en.wikipedia.org/wiki/Smedley_Butler

It was an emacs fork that used TypeScript/Javascript alongside elisp. I am currently in the process of upgrading to deno 1.30.3 right now.

I apricate the time that the deno team has spent having a separation between deno/deno_core/deno_runtime. The deno codebase is well organized and overall high quality.

One issue I've run into as someone who has embedded these libraries into another other project is that there are a lot of really nice features are only available in deno proper (everything under their cli/ directory https://github.com/denoland/deno/tree/main/cli) vice deno_runtime and deno_core. Specifically, typescript is implemented in cli/

A user of runtime or core could just reimplement those features piece meal, however I ended up just forking deno and adding a lib.rs that just exposes the code in cli/ as a library, and it has worked out pretty well for my needs.

This is a really cool project!

One thought that I have: would there be an issue sending this file in an unsecure context where MITM is a possibility? Alice sends Bob her HTML file over an unsecured medium, and Jane intercepts this traffic, and gives Bob a modified HTML file that will report the password back to Jane. Jane can set it up so that the browser still displays the local file as it's source, but has an HTTP request in the background phone home back to Jane's server.

My scenario only works if Bob doesn't inspect the page source before entering their password, or if the modifications are sufficiently obfuscated.