All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent
| #include "math/Matrix.hpp" | |
| #include <fstream> | |
| #include <memory> | |
| #include <array> | |
| #include <iostream> | |
| #include <algorithm> | |
| enum class BranchIndex { | |
| TopLeft = 0, | |
| TopRight, |
How do you send information between clients and servers? What format should that information be in? What happens when the server changes the format, but the client has not been updated yet? What happens when the server changes the format, but the database cannot be updated?
These are difficult questions. It is not just about picking a format, but rather picking a format that can evolve as your application evolves.
By now there are many approaches to communicating between client and server. These approaches tend to be known within specific companies and language communities, but the techniques do not cross borders. I will outline JSON, ProtoBuf, and GraphQL here so we can learn from them all.
Podman is such a cool project! However, there is no easy way to setup the nvidia-container-runtime and podman so that we can run unprivileged container in a gpu host. This is specially interesting in environments with multiple people accessing the same host (strong isolation between containers!!!).
Ubuntu: add-apt-repository -y ppa:projectatomic/ppa && apt install podman buildah skopeo
This document describes how to build a statically linked binary of Elm 0.19.1 for Linux x64 using docker. The binary is built using Alpine Linux in order to easily link it statically to musl libc. This is how the official Elm 0.19.1 Linux binary is built.
Elm is currently distributed using npm. For Linux x64 (but this applies to any architecture), this requires to have a single x64 binary that works on all Linux x64 distributions. This is considerably easier to achieve by building a statically linked binary that will only depend on the Linux kernel ABI and System Call Interface but not on userpace libraries (see here for a compatibility survey of a dynamically built executable).
The question of code-splitting in Elm comes up fairly routinely.
The apparent low-hanging-fruit of code-splitting with Elm's pure/immutable philosophy has led me to explore this a few times with my compiler work on Lamdera.
Here are some of the challenges I've found:
It's a little trickier than it looks because Elm's DCE is actually not DCE (dead code elimination) at all, it's LCI (live code inclusion).
Elm gets one thing amazingly right (which is unusual in most ecosystems) in that it has in its "default" testing tool built in support for property based testing1. This is a huge step forward since it makes property testing something easily reachable for by the average engineer without needing yet another dependency and boilerplate to set it up and so on.
However, there are a number of things we could do to make fuzz testing more effective and in that way make testing more effective.
The one thing it gets amazingly wrong is calling it fuzz testing. Sigh. Fuzz testing is the practice of trying to find inputs that will crash your program or make it behave in unexpected ways. Fuzzers in Elm aren't even trying, for instance float fuzzers don't send in NaN or -Infinity or even -0. Int fuzzers don't send in fractional numbers maquarading as floats. String fuzzers don't send in snippets that might trigger bugs in elm-parser. ↩
