Thank you for fully fixing LaTeX for me.

The best package manager that I like the most for C++ is Pixi (https://pixi.prefix.dev), that works really well.

I can only talk about my own motivation to continue developing and delivering LFortran. Flang is great, but on its own I do not think it will be enough to fix Fortran. What I want as a user is a compiler that is fast to compile itself (under 30s for LFortran on my Apple M4, and even that is at least 10x too long for me, but we would need to switch from C++ to C, which we might later), that is very easy to contribute to, that can compile Fortran codes as fast as possible (LLVM is unfortunately the bottleneck here, so we are also developing a custom backend that does not use LLVM that is 10x faster), that has good runtime performance (LLVM is great here), that can be interactive (runs in Jupyter notebooks), that creates lean (small) binaries, that fully runs in the browser (both the compiler and the generated code), that has various extensions that users have been asking for, etc. The list is long.

Finally, I have not seen Fortran users complaining that there is more than one compiler. On the contrary, everybody seems very excited that they will soon have several independent high-quality open source compilers. I think it is essential for a healthy language ecosystem to have many good compilers.

The complete system of 28 chips had 74,442 transistors. From that it follows that some chip had at least 74,442 / 28 = 2,659 transistors. But I am guessing some chips had less, and some chips had more. I am curious how many transistors the chips had on this computer, specifically what was the maximum amount per IC.

https://certik.github.io/slabikar-otf/

I tried to organize many physics subjects in a similar manner, with many worked out examples (minimal, but non-trivial/complete):

https://www.theoretical-physics.com/dev/index.html

I think exactly the approach that you took with Flang should work with LFortran also.

The demo at https://dev.lfortran.org uses our direct WASM backend that does not use LLVM. It is currently more limited, and indeed, we currently do not support the cubic power x**3 there, only square power x**2. Our most advanced backend is LLVM, and that of course supports x**3 and a very wide subset of Fortran (such as 60% of all SciPy packages fully compile and all SciPy tests pass). However, LLVM is huge and relatively slow, so we do not use LLVM in the online demo, which runs the compiler itself in the browser.

For offline LLVM based WASM compilation I think LFortran is ready be tried. We'll be happy to help!