Created by Pavel Klavík
https://orgpad.info/s/highperf
Instead f(x,y,z) write (f x y z).
REPL + hot code reloading
Shell programming. Custom serialization and parsing.
POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 48
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
licenseID=string&content=string&/paramsXML=string
Reinventing custom language for everything.
For example, event system is really complex.
Of course, one has to understand it first. For example, the article below just says "I don't know how to write efficient Clojure."
https://blog.asciinema.org/post/smaller-faster/
Clojure works with values which cannot be changed. But it is possible to efficiently create modified values.
Rich Hickey created these data structures so they are efficient enought for 99% of all applications. Time to reading is 1-2x, time of writing is 1-4x. Often, the program can be in total more efficient which is counterintuitive.
2x speed improvement when doing a lot of consecutive changes in a data structure.
https://github.com/erikbern/git-of-theseus
We repeatedly draw a cell outside of the screen. For a selected width, we let the browser to compute the corresponding height. We are searching a space of possible sizes to find an ideal size.
You see them all around here. For example, the cells have springs attached, attracting them to their new positions. Thanks to this, animations can be smoothly assembled and connected. This method of animation was devised by designers at Apple.
OrgPad doesn't solve these with simulation but by solving the differential equations of spring motion. The spring has two parameters:
These parameters define three types of springs:
Different formulas are used for them, into which initial position and velocity are substituted.
The entire process is repeated by running about 25 iterations.
The computation runs in a standalone thread as a WebWorker. The result is then sent to the main thread which animates nodes and links to their new positions.
We use Archimedian forces, so force is a change in position, not velocity. It is much easier and it gives good results.
All forces applied on a cell/link are composed and we apply only their sum.
They have both position and size. Sizes may change as cells are opened/closed or change their content.
Forces shift cells.
When cell rectangles are close to each other or overlap, they apply repulsive forces on each other. When they are further than a fixed limit, there are no repulsive forces anymore.
Forces bend links in their direction.
Bended links are quadratic Bezier curves. Sufficiently straight links are line segments.
When a link is near a cell to which it is not attached, they apply repulsive forces on each other. Computation is much slower for bended links than for straight ones (roughly 10x slower).
Parallel links repulse each other. It works very well for a few links which is sufficient.
Originally we applied them but they pushed cells to close to each other. It was not possible to have long links within the graph. Since we are creating an assistent which does not draw graphs from nothing, they are not that necessary.
Shared for everyone and stored at the server. All nodes are closed.
Each browser window displays its own, according to which cells are currently opened. Expanded graph is used for working but it is not shared with the server and others.
Everyone can have different cells opened so displayed layouts are different. How should we interpret changes in one layout to another layout?
We try to make the expanded graph as close to the packed one as possible, otherwise changes in the expanded graph would be too different from changes in the packed one. Therefore cells are slightly pushed towards their original packed positions.
Ideal speed of recomputation would be 100 to 200 ms while doing many more iterations. We can do it for small graphs but not for large ones. Till recently, the biggest bottleneck was rendering so we did not do further performance improvements.
Only when this bended line is near a cell, the exact distance is computed. Almost always it is not true, so it greatly improves speed of bended links.
