Yeah that works. But I also wanted the ability to produce JSON Patch and JSON Merge Patch formats. And to support set semantics, identifying objects by specified keys. And it works on YAML too.
Yeah. The design pattern sounds like there is one state, and it is shared. What STL has looks like, all instances look the same, hence only one state is possible. They are homonyms with slightly different etymologies.
Yeah, I have my doubts about the claim. I forgot what I read way back when as an intro book, but I suspect it was more like a month in my case, if that. But I remember having been surprised at various points that there was an undo (C-_), and a clipboard (C-y to paste) including a history (M-y). So yeah, I guess it depends on the scope.
Maybe it's a hyperbole? Dunno, doesn't really read that way.
How can you discover something on the terminal itself? You fall into a pattern and stick with it. It is only if you get out of band information that you can learn these tricks.
Bit confused by this comment. I don't think anybody suggested you're going to find these things solely by interacting with the terminal - but rather through "out of band information" as you put it, which in GP's case, as he said, was a book. The surprising part of TFA, and replies to my comment - to me anyway - is how one can go so many years without picking up that information.
I have never read a book about improving my terminal knowledge. I have a few tricks I have picked up over time (probably through posts like this!), but never done holistic research on the subject. Therefore, despite having used the terminal for decades, I likely have a similarly long list of basic terminal knowledge gaps. I do not know what I do not know.
An option if it gets way off would be to just express it as TZ shift. Current rate seems to be about a second every two years, so we have some hundreds of years before we need to even shift by 15 minutes. An amount of divergence that I suspect would not really be even noticeable, especially as it develops over hundreds of years. The TZ code is used widely and regularly and systems tend to know how to handle it. Leap seconds are always a bit of an adventure from what I understand. (I'm not a sysadmin, so I don't know the details.)
Like -- I don't know, but is it actually important that the solar day is tied to "wall clock day" so snugly? So what if it's a couple minutes off...?
> Like -- I don't know, but is it actually important that the solar day is tied to "wall clock day" so snugly? So what if it's a couple minutes off...?
Even when you're assigned a correct hour-aligned time zone, you'll be off by an average of 15 minutes! Wall clock time just fundamentally has never been precise enough for leap seconds to solve a problem, by two orders of magnitude.
A 15 minute shift once every hundred years would wreak havoc on all of the software built when the shift was too far away to worry about.
Better to design in the requirement for all software to support these shifts, like a random 10 minute shift every day. That way nobody will write software that doesn’t support the shift.
The trick that I heard is to just place the mouse on a clock. The second hand jiggles the mouse every minute. Can be stashed away in a drawer or something. Never tried this though.
You put postage on the letter, and the post office stamps the postage (to invalidate the postage). The stamp contains a date. You can't stamp something after having mailed it, that happens as part of the mail submission.
OK, I suppose this could be arranged. The seal has to be over the whole of the "back side" of the envelope, where the flap is. Then put the address and the postage over that, and the post office stamps it.
What confused me was how you would achieve post office stamping over a seal that's on the wrong side of the envelope, where the flap is.
I think they mean that a lot of runtime of any benchmark is going to be spent in the C bits of the standard library, and therefore not subject to the JIT. Only the glue code and the bookkeeping or whatnot that the benchmark introduces would be improved by the JIT. This reduces the impact that the JIT can make.
I used m4 to that effect to generate some set-like and map-like strongly-typed classes for a j2me project. Must have been 15 years ago.
For C and C++ in particular, X macros are another technique that can be used to generate boilerplate nicely. I use that quite a bit to this day, even in C++, where it's not needed as much due to templates.
