Maybe it's the other way when driving on the left? :)
1,184 karma · joined December 29, 2018
As an alternative, the encoding/decoding roundtrip using protobuf seems reasonable to me, catches the footgun of using floating-point version numbers (it becomes a parse error), whitespace/multiline concatenation being more obvious, and allowing comments (compared to JSON):
( cat << EOF
# yes, comments are allowed
name: "Python package"
on: "push"
build {
python_version: ["3.6", "3.7", "3.8", "3.9", "3.10"]
steps: [
{
name: "Install dependencies"
run:
"python -m pip install --upgrade pip\n"
"pip install pytest\n"
"if [ -f 'requirements.txt' ]; then pip install -r requirements.txt; fi\n"
},
{
name: "Test with pytest"
run: "pytest\n"
}
]
}
EOF
) | protoc --encode=Config config.proto | protoc --decode=Config config.proto
name: "Python package"
on: "push"
build {
python_version: "3.6"
python_version: "3.7"
python_version: "3.8"
python_version: "3.9"
python_version: "3.10"
steps {
name: "Install dependencies"
run: "python -m pip install --upgrade pip\npip install pytest\nif [ -f \'requirements.txt\' ]; then pip install -r requirements.txt; fi\n"
}
steps {
name: "Test with pytest"
run: "pytest\n"
}
}For example, in the wire-format, a string and a sub-message are encoded as the same type (a blob - varint + sequence of bytes), but using the schema they are clearly interpreted differently.
Sure, it is possible to make a self-describing protobuf message which includes the schema in protobuf representation, but that is a special-case.
On the motherboard there was a jumper which took the input from the turbo switch.
To provide feedback to the user, some cases ran a wire from the turbo switch to a bi-color LED on the front of the case as well as to the motherboard to control the turbo state.
On fancier cases they had multiple seven-segment LEDs which had a multi-state jumper for each segment, which decided to light that segment depending if the switch was on or off (example: http://www.minuszerodegrees.net/led_speed_display/LED%20disp...), so you could display either the two different clock frequencies, or a "HI"/"LO" message, or anything you wanted. And connecting that switch input to the motherboard wasn't necessary for the LED to change, so I guess that is how your father's was setup :)
From "SEC 2: Recommended Elliptic Curve Domain Parameters":
"... one type being parameters associated with a Koblitz curve and the other type being parameters chosen verifiably at random"
"Verifiably random parameters offer some additional conservative features. These parameters are chosen from a seed using SHA-1 as specified in ANSI X9.62 [X9.62]. This process ensures that the parameters cannot be predetermined."
Common QEMU frontends may have a UI button or keyboard sequence to do this for you (they connect to the monitor backend and send the same command, either as text or as JSON (in "qmp" mode)).
> Marlett is a TrueType font that has been used in Microsoft Windows since Windows 95. The operating system uses this font to create user interface icons that are used in the menus and windows.
So, no better than XML really :D
JSON.stringify(JSON.parse('{"kids":10000000000000001}')) -> '{"kids":10000000000000000}'
Which "RAW" format? I think that is the problem - there are many and few are completely documented, which is where DNG comes in (https://www.adobe.com/content/dam/acom/en/products/photoshop...).
Great point about throwing away metadata, and probably worthwhile to safeguard that one's flavor of RAW files (CR2/NEF/etc) can be reliably read in the future when the software necessary to read them inevitably disappears from the cloud.
A fair-few DOS applications (via DPMI) also implemented virtual memory schemes like a "real OS" - I remember POVRay 2.0 officially requiring 2 MB of RAM, but was able to start on my 1MB 386SX machine (albeit with 1-2 mins of HDD-thrashing...).