Ciro Santilli @cirosantilli  40

One of the key advances of the previous update was to show include headers on the table of contents.

This was to allow splitting source files freely.

While that goal was in principle achieved in that commit, when I went ahead to split the huge index of cirosantilli.com into multiple files, I notice several bugs that took a week to fix.

After all of these were solved, I finally managed to split the README at: github.com/cirosantilli/cirosantilli.github.io/commit/84c8a6e7fdbe252041accfb7a06d9b7462287131 and keep the previous desired output. You can now see that the README contains just:

This split led to a small positive modification of the output as follows. Previously, a section such as "Quantum Electrodynamics" would have been present in the monolithic README.ciro as:If you visited cirosantilli.com/quantum-electrodynamics, you would see see a link to the "nosplit" version, which would link you back to cirosantilli.com#quantum-electrodynamics, but that is not great, since this is was a humongous page with all of the README.ciro, and took long to display.

After the split, = Quantum electrodynamics is present under science.ciro, and the nosplit version is the more manageable cirosantilli.com/science#quantum-electrodynamics.

The key changes that were missing for that to happen were:

Currently, none of the crucial cross file features like \x, \Include and table of contents are working. I was waiting until the above mentioned features were done, and now I'm going to get to that.

And do 5 big queries instead of hundreds of smaller ones.

For example, a README.ciro document that references another document saying:needs to fetch "speed-of-light" from the ID database (previously populated e.g. by preparsing light.ciro:to decide that it should display as "Speed of light" (the title rather than the ID).

Previously, I was doing a separate fetch for each \x[] as they were needed, leading to hundreds of them at different times.

Now I refactored things so that I do very few database queries, but large ones that fetch everything during parsing. And then at render time they are all ready in cache.

This will be fundamental for the live preview on the browser, where the roundtrip to server would make it impossible

E.g.:

README.cironot-readme.cirothe table of contents for index.html also contains the headers for not-readme.ciro producing:

This feature means that you can split large input files if rendering starts to slow you down, and things will still render exactly the same, with the larger table of contents.

This will be especially important for the website because initially I want users to be able to edit one header at a time, and join all headers with \Include. But I still want the ToC to show those children.

This was a bit hard because it required doing RECURSIVE SQL queries, something I hadn't done before: stackoverflow.com/questions/192220/what-is-the-most-efficient-elegant-way-to-parse-a-flat-table-into-a-tree/192462#192462 + of course the usual refactor a bunch of stuff and fix tests until you go mad.

github.com/cirosantilli/node-express-sequelize-nextjs-realworld-example-app contains the same baseline tech as OurBigBook, and I have been use to quickly test/benchmark new concepts for the website base.

I'm almost proud about that project, as a reasonable template for a Next.js project. It is not perfect, notably see issues on the issue tracker, but it it quite reasonable.

The side effects of ambitious goals are often the most valuable thing achieved once again? I to actually make the project be more important thatn the side effects this time, but we'll see.

Since the last update, I've made some major improvements to the baseline tech of the website, which I'll move little by little into OurBigBook. Some of the improvements actually started in OurBigBook.com. The improvements were:

Name of the clade of archaea plus eukarya proposed at: www.frontiersin.org/articles/10.3389/fmicb.2015.00717/full. Much better term than prokaryote as that is not a clade. Let's hope it catches on!

Bibliography:

One specific software project, typically with a single executable file format entry point.