after the freeze lifts, you also have multiple contributors dumping large PRs at the same time, missing out on the progressive integration that happens otherwise. This makes it difficult to figure out the cause of regression (think bisect but with large commits).
Code freezes like this are worst when there is no individual branching capability or local revision control, because that guarantees large commits.
my anecdata is that I have always filed manually by myself, but every time had a small adjustment made by the IRS... indeed filing a correct return the 1st time seems close to impossible.
it's funny because I have seen the opposite.
Engineer: "it crashed because it dereferenced a null pointer"
boss: "add null pointer checks everywhere!"
... and because it used "if" instead of "assert", it made the null pointer arg a valid argument, making it a tolerable state of the running software, which displaced the locus of crashes far from the source of the issue. Moral of the story, use "assert" to make it crash as early as possible and debug THAT. You want to restrict the representable states in the software, not expand them by adding null checks everywhere.
This is right on point. I read this book recently, by coincidence, and it's funny and fascinating at the same time (at least for someone who speaks both English and French).
My daily driver in 1998-1999 was a 43P (see http://www.ibmfiles.com/pages/rs6000type7043150.htm ), an earlier model of this.
With AIX, it was slowish, swapping to disk very easily (i.e. not enough RAM). I don't miss AIX much, though.
This uses the Most Significant Bits to pack some bits into pointers..
Another technique is to use the Least Significant Bits: indeed since pointers are 64 bit aligned, the lowest 3 bits are always zero, therefore it is possible to pack 3 bits of information there.
And there's a third technique in C++, which is to use placement new to morph an object in-place. This can be use to toggle between 2 classes with a boolean method, where one has this method return true and the other class has this method return false. This creates per-object state that really uses bits in the vptr to store this boolean state. Obviously this can be used with a whole set of classes to stores more bits. I have used this successfully to store values of refcount (each AddRef/Release using placement new to morph from RefCounted1/RefCounted2/../RefCountedN classes) to implement reference counting without a counter.
But really, the premise of using a shared map with
concurrent readers and writers seems like a good generator of hard-to-reproduce
bugs. IMHO shared-nothing (when feasible) is much easier to reason about, and possibly do periodic merging of thread-local updates, but I would avoid concurrent updates entirely (in particular if 2 threads race to update the same key... that goes to deeper design issues in the application).
Same here. I have never unlocked the macbook successfully the 1st time around (for a good 10 years), I always get a "wrong password" and have to re-enter.
My initial guess is that the text edit control has "select all content" set initially, so when you enter the 1st character, it's selected, and when you enter the following characters they overwrite that, essentially chopping off the 1st letter of the password (which is then incorrect, obviously). Unbelievable that this was never fixed (especially with IT-managed laptops that lock themselves very quickly).