Fields Medal Updated 2025-07-16
That 15,000 canadian dollar prize though, what a joke! That's what you get when an impoverished scientist, and not a rich industrialist, creates a prize!
This example is the same as nodejs/sequelize/raw/parallel_select_and_update.js, but going through Sequelize rather than with Sequelize raw queries. NONE is not supported for now to not have a transaction at all because lazy.
Sample invocation:
node --unhandled-rejections=strict ./parallel_select_and_update.js p 10 100 READ_COMMITTED UPDATE
where:
Other examples:
  • node --unhandled-rejections=strict ./parallel_select_and_update.js p 10 100 READ_COMMITTED UPDATE
Then, the outcome is exactly as described at: nodejs/sequelize/raw/parallel_select_and_update.js:
This example contains a deterministic demo of when postgreSQL serialization failures may happen.
Tested on PostgreSQL 13.5.
This example is similar to nodejs/sequelize/raw/parallel_update_async.js, but now we are doing a separate SELECT, later followed by an update:
  • SELECT FROM to get i
  • update on Js code newI = i + 1
  • UPDATE SET the newI
Although this specific example is useless in itself, as we could just use UPDATE "MyInt" SET i = i + 1 as in nodejs/sequelize/raw/parallel_update_async.js, which automatically solves any concurrency issue, this kind of code could be required for example if the update was a complex function not suitably implemented in SQL, or if the update depends on some external data source.
Sample execution:
node --unhandled-rejections=strict ./parallel_select_and_update.js p 2 10 'READ COMMITTED'
which does:
Another one:
node --unhandled-rejections=strict ./parallel_select_and_update.js p 2 10 'READ COMMITTED' 'FOR UPDATE'
this will run SELECT FOR UPDATE rather than just SELECT
Observed behaviour under different SQL transaction isolation levels:
  • READ COMMITTED: fails. Nothing in this case prevents:
    • thread 1: SELECT, obtains i = 0
    • thread 2: SELECT, obtains i = 0
    • thread 2: newI = 1
    • thread 2: UPDATE i = 1
    • thread 1: newI = 1
    • thread 1: UPDATE i = 1
  • REPEATABLE READ: works. the manual mentions that if multiple concurrent updates would happen, only the first commit succeeds, and the following ones fail and rollback and retry, therefore preventing the loss of an update.
  • READ COMMITTED + SELECT FOR UPDATE: works. And does not do rollbacks, which probably makes it faster. With p 10 100, REPEATABLE READ was about 4.2s and READ COMMITTED + SELECT FOR UPDATE 3.2s on Lenovo ThinkPad P51 (2017).
    SELECT FOR UPDATE should be enough as mentioned at: www.postgresql.org/docs/13/explicit-locking.html#LOCKING-ROWS
    FOR UPDATE causes the rows retrieved by the SELECT statement to be locked as though for update. This prevents them from being locked, modified or deleted by other transactions until the current transaction ends. That is, other transactions that attempt UPDATE, DELETE, SELECT FOR UPDATE, SELECT FOR NO KEY UPDATE, SELECT FOR SHARE or SELECT FOR KEY SHARE of these rows will be blocked until the current transaction ends; conversely, SELECT FOR UPDATE will wait for a concurrent transaction that has run any of those commands on the same row, and will then lock and return the updated row (or no row, if the row was deleted). Within a REPEATABLE READ or SERIALIZABLE transaction, however, an error will be thrown if a row to be locked has changed since the transaction started. For further discussion see Section 13.4.
A non-raw version of this example can be seen at: nodejs/sequelize/parallel_select_and_update.js.
../../../nodejs/sequelize/raw/parallel_update_worker_threads.js contains a base example that can be used to test what can happen when queries are being run in parallel. But it is broken due to a sqlite3 Node.js package bug: github.com/mapbox/node-sqlite3/issues/1381...
../../../nodejs/sequelize/raw/parallel_update_async.js is an async version of it. It should be just parallel enough to allow observing the same effects.
This is an example of a transaction where the SQL READ COMMITTED isolation level if sufficient.
These examples run queries of type:
UPDATE "MyInt" SET i = i + 1
Sample execution:
node --unhandled-rejections=strict ./parallel_update_async.js p 10 100
which does:
The fear then is that of a classic read-modify-write failure.
But as www.postgresql.org/docs/14/transaction-iso.html page makes very clear, including with an explicit example of type UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 12345;, that the default isolation level, SQL READ COMMITTED isolation level, already prevents any problems with this, as the update always re-reads selected rows in case they were previously modified.
If the first updater commits, the second updater will ignore the row if the first updater deleted it, otherwise it will attempt to apply its operation to the updated version of the row
Since in PostgreSQL "Read uncommitted" appears to be effectively the same as "Read committed", we won't be able to observe any failures on that database system for this example.
nodejs/sequelize/raw/parallel_create_delete_empty_tag.js contains an example where things can actually blow up in read committed.
prime-number-theorem Updated 2025-07-16
Consider this is a study in failed computational number theory.
The approximation converges really slowly, and we can't easy go far enough to see that the ration converges to 1 with only awk and primes:
sudo apt intsall bsdgames
cd prime-number-theorem
./main.py 100000000
Runs in 30 minutes tested on Ubuntu 22.10 and P51, producing:
Figure 1.
Linear vs approximation plot
. and are added to give a better sense of scale. is too close to 0 and not visible, and the approximation almost overlaps entirely with .
Figure 2.
. It is clear that the difference diverges, albeit very slowly.
Figure 3.
. We just don't have enough points to clearly see that it is converging to 1.0, the convergence truly is very slow. The logarithm integral approximation is much much better, but we can't calculate it in awk, sadface.
But looking at: en.wikipedia.org/wiki/File:Prime_number_theorem_ratio_convergence.svg we see that it takes way longer to get closer to 1, even at it is still not super close. Inspecting the code there we see:
(* Supplement with larger known PrimePi values that are too large for \
Mathematica to compute *)
LargePiPrime = {{10^13, 346065536839}, {10^14, 3204941750802}, {10^15,
     29844570422669}, {10^16, 279238341033925}, {10^17,
    2623557157654233}, {10^18, 24739954287740860}, {10^19,
    234057667276344607}, {10^20, 2220819602560918840}, {10^21,
    21127269486018731928}, {10^22, 201467286689315906290}, {10^23,
    1925320391606803968923}, {10^24, 18435599767349200867866}};
so OK, it is not something doable on a personal computer just like that.
python/sphinx Updated 2025-07-16
To run each example and see the output run:
./build.sh
xdg-open out/index.html
qiskit/hello.py Updated 2025-07-16
Our example uses a Bell state circuit to illustrate all the fundamental Qiskit basics.
Sample program output, counts are randomized each time.
First we take the quantum state vector immediately after the input.
input:
state:
Statevector([1.+0.j, 0.+0.j, 0.+0.j, 0.+0.j],
            dims=(2, 2))
probs:
[1. 0. 0. 0.]
We understand that the first element of Statevector is , and has probability of 1.0.
Next we take the state after a Hadamard gate on the first qubit:
h:
state:
Statevector([0.70710678+0.j, 0.70710678+0.j, 0.        +0.j,
             0.        +0.j],
            dims=(2, 2))
probs:
[0.5 0.5 0.  0. ]
We now understand that the second element of the Statevector is , and now we have a 50/50 propabability split for the first bit.
Then we apply the CNOT gate:
cx:
state:
Statevector([0.70710678+0.j, 0.        +0.j, 0.        +0.j,
             0.70710678+0.j],
            dims=(2, 2))
probs:
[0.5 0.  0.  0.5]
which leaves us with the final .
Then we print the circuit a bit:
qc without measure:
     ┌───┐
q_0: ┤ H ├──■──
     └───┘┌─┴─┐
q_1: ─────┤ X ├
          └───┘
c: 2/══════════

qc with measure:
     ┌───┐     ┌─┐
q_0: ┤ H ├──■──┤M├───
     └───┘┌─┴─┐└╥┘┌─┐
q_1: ─────┤ X ├─╫─┤M├
          └───┘ ║ └╥┘
c: 2/═══════════╩══╩═
                0  1
qasm:
OPENQASM 2.0;
include "qelib1.inc";
qreg q[2];
creg c[2];
h q[0];
cx q[0],q[1];
measure q[0] -> c[0];
measure q[1] -> c[1];
And finally we compile the circuit and do some sample measurements:
qct:
     ┌───┐     ┌─┐
q_0: ┤ H ├──■──┤M├───
     └───┘┌─┴─┐└╥┘┌─┐
q_1: ─────┤ X ├─╫─┤M├
          └───┘ ║ └╥┘
c: 2/═══════════╩══╩═
                0  1
counts={'11': 484, '00': 516}
counts={'11': 493, '00': 507}
qiskit/qft.py Updated 2025-07-16
This is an example of the qiskit.circuit.library.QFT implementation of the Quantum Fourier transform function which is documented at: docs.quantum.ibm.com/api/qiskit/0.44/qiskit.circuit.library.QFT
Output:
init: [1, 0, 0, 0, 0, 0, 0, 0]
qc
     ┌──────────────────────────────┐┌──────┐
q_0: ┤0                             ├┤0     ├
     │                              ││      │
q_1: ┤1 Initialize(1,0,0,0,0,0,0,0) ├┤1 QFT ├
     │                              ││      │
q_2: ┤2                             ├┤2     ├
     └──────────────────────────────┘└──────┘
transpiled qc
     ┌──────────────────────────────┐                                     ┌───┐   
q_0: ┤0                             ├────────────────────■────────■───────┤ H ├─X─
     │                              │              ┌───┐ │        │P(π/2) └───┘ │ 
q_1: ┤1 Initialize(1,0,0,0,0,0,0,0) ├──────■───────┤ H ├─┼────────■─────────────┼─
     │                              │┌───┐ │P(π/2) └───┘ │P(π/4)                │ 
q_2: ┤2                             ├┤ H ├─■─────────────■──────────────────────X─
     └──────────────────────────────┘└───┘
Statevector([0.35355339+0.j, 0.35355339+0.j, 0.35355339+0.j,
             0.35355339+0.j, 0.35355339+0.j, 0.35355339+0.j,
             0.35355339+0.j, 0.35355339+0.j],
            dims=(2, 2, 2))

init: [0.0, 0.35355339059327373, 0.5, 0.3535533905932738, 6.123233995736766e-17, -0.35355339059327373, -0.5, -0.35355339059327384]
Statevector([ 7.71600526e-17+5.22650714e-17j,
              1.86749130e-16+7.07106781e-01j,
             -6.10667421e-18+6.10667421e-18j,
              1.13711443e-16-1.11022302e-16j,
              2.16489014e-17-8.96726857e-18j,
             -5.68557215e-17-1.11022302e-16j,
             -6.10667421e-18-4.94044770e-17j,
             -3.30200457e-16-7.07106781e-01j],
            dims=(2, 2, 2))
So this also serves as a more interesting example of quantum compilation, mapping the QFT gate to Qiskit Aer primitives.
If we don't transpile in this example, then running blows up with:
qiskit_aer.aererror.AerError: 'unknown instruction: QFT'
The second input is:
and the output of that approximately:
[0, 1j/sqrt(2), 0, 0, 0, 0, 0, 1j/sqrt(2)]
which can be defined simply as the normalized DFT of the input quantum state vector.
react/ref-click-counter.html Updated 2025-07-16
Dummy example of using a React ref This example is useless and to the end user seems functionally equivalent to react/hello.html.
It does however serve as a good example of what react does that is useful: it provides a "clear" separation between state and render code (which becomes once again much less clear in React function components.
Notably, this example is insane because at:
<button onClick={() => {
  elem.innerHTML = (parseInt(elem.innerHTML) + 1).toString()
we are extracing state from some random HTML string rather than having a clean JavaScript variable containing that value.
In this case we managed to get away with it, but this is in general not easy/possible.
Four-day workweek Updated 2025-07-16
We need this. The five day week is designed to suck all the mental life of an average mental worker person, and it leaves basically nothing if they "do their job really well".
test_executables.js Updated 2025-07-16
This script tests all executables under a selected directory.
Ciro Santilli has been writing scripts of that type for a long time in order to test his programming self-learning setups with asserts.
The most advanced of those being the test system of Linux Kernel Module Cheat.
But had too much stuff that would be specific to that project, so Ciro decided to start this new one in Node.js, hopefully it will also be the last he ever writes.
A sample usage of the test library can be seen at: nodejs/sequelize/test.
webpack/no-js-inject Updated 2025-07-16
This example shows how you could manually include the dist/index.js that is output from webpack into your index.html.
This is generally not what you want to do, because what you actually want to do is to use a Js output name with a hash in it, so that browsers only need to refetch when the name changes.
And to do that, we have to let webpack dynamically inject that unpredictable hash as done in webpack/template with:
new HtmlWebpackPlugin({
  filename: 'index.html',
  // Inject the include to our hashed filename,
  // since it is not deterministic due to the hash.
  inject: true,
  template: path.resolve(__dirname, 'index.html'),
}),
webpack/template Updated 2025-07-16
../webpack/template contains a reasonable starter template.
This will produce, under dist/ the following minimized files:
You can also run this test with the development server on localhost:9000:
npm start
which uses unminimized outptus, and automatically push reloads the page whenever you change any of the input files!

There are unlisted articles, also show them or only show them.