Know what's great for long-form text on these widescreen monitors? Multi-column layout!
And CSS has columns these days.
So just as long as there's an easy way to advance to the next column or page…
haven't quite got it. A column isn't exactly an element in the DOM, so I'm having trouble accurately querying its width, in order to know how much to scroll.
1980's-era graphics esoterica
In the days of 8-color displays (or 16, where the the second half was just brighter versions of the 8), I never saw a pattern in the order the colors came in for things like ANSI X3.64 codes. I assumed they had their small set of colors but the order was arbitrary.
But 8 is how high you can count in three bits: one bit each R, G, and B. The direction may differ between implementations; looks like ANSI X3.64 has Red as the lowest and CGA has Blue as the lowest. But the order of the colors just comes from counting up in binary.
0 0 0 - black
0 0 b - blue
0 g 0 - green
0 g b - cyan
r 0 0 - red
r 0 b - magenta
r g 0 - ~yellow~ brown?
They made a special case for brown, where the green bit only counts for half, because they thought it made a better palette than a dull yellow: https://en.wikipedia.org/wiki/Color_Graphics_Adapter#With_an_RGBI_monitor
Never would have guessed they went to extra expense for that CGA brown!
ubuntu snaps (~)
Using jq to parse output from snapd to generate commands to run through sudo is a fine activity for a winter evening, right?
I bet I was doing something else entirely before I stumbled across those old installations…
Clocks? Is the answer "clocks"?
Because the lower numbers are more common, not so surprising to allocate characters for some low numbers but not _all_ numbers, but then why twelve, and not ten or thirteen or fifteen or twenty?
Clocks go to twelve and are often marked with roman numerals.
Why are there distinct code points for the roman numerals one through twelve? https://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5Cp%7Bsubhead%3DRoman+numerals%7D
I guess they've been there since Unicode 1.0, so Wikipedia doesn't have any links to the proposals for their inclusion.
I made some skits showing the program I've been learning Rust with. https://keturn.gitlab.io/execthis/casts.html
(thanks asciinema, you're pretty great.)
The call for Title of Conf proposals https://www.titleofconf.org/cfp asks for writers AND for performers; musical parodies, original music, & original short plays: "stories that capture the day-to-day experience of creating software." Apply by Jan 25, 2020.
Show: May 7, 2020 in Detroit.
re: rust (early impressions)
And my rust-produced executable is a lot bigger than I expected. That's also the sort of thing I only noticed because of this low-footprint goal; it's a concern that will vanish as you move into medium-size programs.
I'm enjoying this as a learning exercise, but practically speaking, is it a good fit for this case?
Maybe should have stuck with Python, assuming there's a shared instance of it already installed on the target. Which would be true of pretty much all Ubuntu-derived installations (it's in ubuntu-core), but maybe it's not as core to Debian as I thought, and it's unclear what runtimes will be available to future versions of OS X. 🤷
Making guesses about portability is hard!
(The initial impetus for this utility was something I couldn't figure out how to make readable in POSIX sh/sed/awk.)
rust (early impressions)
So far, I think this Rust language is probably fine for writing and maintaining programs in.
I'm writing a tiny little utility. It needs so little from a runtime, and it's so peripheral to the system's core concerns, I thought stay-small-and-load-quick would be good qualities.
Seemed like a good candidate for an experiment with Rust, given its ahead-of-time compilation and lack of overhead for memory management.
What I've got so far — which barely does more than parse its arguments — is faster than a minimal CPython program and takes less memory, but CPython doesn't do so badly in comparison.
(I expect they probably scale very differently once you move out of this teensy-scale program; Python imports can accumulate fast.)
the documentation browser is real nice though. That search interface!
Kotlin, path manipulation
Speaking of Kotlin, how does Kotlin standard library deal with paths?
`File("/var/www").resolve(File("/etc/passwd"))` ends up with /etc/passwd, but I am much happier with that named "resolve" than "join".
`File(File("/var/www"), "/etc/passwd"))` doesn't error, but gives /var/www/etc/passwd. You can totally construct /var/www/../../etc/passwd that way, though.
That's `File(File, String)` but there is no `File(File, File)`.
And I don't find any other `File.x(File)` where `x` is anything like `child` or `descendant`.
extending classes (Kotlin +)
This also reminds me that Kotlin's ability to extend classes is real nice.
I could define an extension to pathlib.Path that provides a `safejoin` method. Logically, it's the same as providing a function `safejoin(path1, path2)`, but allows the syntax of `path1.safejoin(path2)`. That makes it look consistent with the original methods, and I can use it by importing safejoin without having to make any Path instance I see into an instance of some SafePath proxy or subclass.
Of course, if I pass that Path instance out to any other library, it's likely to still do the unsafe operation, but can't do anything about that without breaking contracts.
re: Python 3 (-), Old Man Yells At Cloud
It was also around the same time as a bunch of the async discussion, so to the extent that anyone who worked with t.p.filepath was paying attention to python-ideas, they were probably trying to keep tabs on that discussion more than pathlib.
Python 3 (-), Old Man Yells At Cloud
I was appreciating the fact that with Python 3, we finally get a Path type in the standard library.
Until I discovered that `Path('/var/www').joinpath('/etc/passwd')` doesn't throw `InsecurePath`.
Okay, I can imagine there are some use cases where you want to be able to represent `foo/../../assets` or something, but usually not, and resetting the root to `/` never.
which is why t.p.filepath has guarded against that sort of thing since its inception in 2003.
Come on, stdlib, where are my Batteries Included? PEP 428 even cites t.p.filepath as prior art, along with Unipath, which offers a method with similar protections.
I'm checking PEP 428's mailing list discussion, but I don't know how to find this amongst the fucktillion messages debating operator overloading. Maybe that's the answer: everyone who was tired of reading about operator overloading stopped thinking about this PEP.
Apparently explainshell has been around for years. How have we not met before now???