Someone getting the odd coffee money is hardly operating a "venue for profit"; they are just trying to get by any way they can.

  1> let ((x 3) (step 2) (width 5)) ((2 * step + x) mod width)
  2

  2> *listener-auto-infix-p*
  t
  3> *listener-auto-compound-p*
  t

I've come up with a very good way of handling infix in Lisp, and documented it in a decent amount of detail as well, not just as a manual for the user but anyone wanting to implement something similar.

https://www.nongnu.org/txr/txr-manpage.html#N-BEB6083E

Suppose your brain were somehow exploited for generating text, while you are under anesthesia. That would be definitely unconscious.

Though it's possible that parts of your brain are conscious, but have no access to express that because they don't control the body, nor directly receive any sensory information. I.e. that "you" that is unconscious when anaesthesized might not be the only consciousness in your brain, just the visible one.

Pack that shit full of silicone dielectric grease, check it every year or two, and it should be good for decades.

The claim is that FLAC decoding digital hardware performs processing which causes noise ("computer hash") if it is not isolated from the audio paths. He gives an example of some hardware where isolation eliminates the problem, supposedly.

I'm skeptical of the claim. Not in the sense whatsoever that I suspect it being false (I don't), but in the sense that the same noisy hardware would produce some "computer hash" even if it were processing uncompressed waveform data. I don't know anything about FLAC, but cursory searches suggest that decoding it is very lightweight. Whether processing raw PCM samples, or decoding FLAC, the hardware would mostly be idle in between producing audio frames (unless it is an embedded processor that is very low in terms of computational power?)

Anyway, he's not simply an crackpot claiming that FLAC quality is inherently different from WAV.

Already, "git push" stops from clobbering: it warns that your proposed push is non-fast-forward and that you need --force.

If you are using git as intended, that's all the warning you need.

I understand that there are dubious workflows out there where a repo has multiple downstream users and they are all doing "git push --force", without coordinating with each other. They need a double force to make sure that they are clobbering what they think they are clobbering.

If that's not you (which it arguably shouldn't be, and certainly isn't me), you don't need to know about force-with-lease.

The only thing I would ever do with --force-with-lease is go "oh", and immediately repeat the command with --force, knowing that I'm in a situation in which the check is not applicable.

Even if the force were erasing a new commit that came from another repo, I would know that. Like I pushed something into upstream U from repo B, but I'm fixing the situation out of repo A which hasn't picked up the change. Yes, I know what I'm doing, that's why I'm using --force, and don't require --simon-says-force. I want the chain of commits I now have in A to be exactly what is in U, as a rare exception to normal git use. After I'm done from A, I will switch back to B, do a "git fetch" and probably "git reset --hard origin/master" to make B look like U.

"Four models. One topology — designed by Darren Myers, engineered by Bob Stadtherr. Driven from a state-of-the-art active power supply that delivers performance benefits no traditional transformer-based passive supply can match. Class A bias of 50 watts means your music spends 99% of its time in the most linear region of the amplifier's operation"

Yikes; run the other way ...

All of this still overlooks the fact that the changes are not lost. Say someone (like one of the personalities in your head you don't know about) publishes a change which you unknowingly clobber with a "git push --force". That someone will notice when they fetch the repo: it has diverged from their clone and when they look at the history of master vs origin/master, they will see that their commit which they are sure they pushed does not appear in origin/master.

If you have multiple downstream checkouts and manage to clobber something with force pushes, you can recover. Then have a word with yourself and work smarter going forward.

1.0 lies on the right side of the bin 7. But 0.0 lies on the left of bin 0.

The standard approach assumes that we have centered samples: that zero is dead black, plus (and minus!) some uncertainty and so is bin 7.

If the sampling of the intensity is distortion-free (no clipping took place due to overexposure) then bin 7 represents a range of possible values centered around 1.0.

It is not a half-sized interval.

> This means that when converting floating-point values in the [0,1] range back to integers, the extreme bins have effectively half the width of other bins.

Under any interpretation whatsoever of the image samples, there is latitude for interpreting the maximum value 255 as being distortion: clipping from an arbitrarily higher value. Shifting things by 0.5 doesn't fix this issue of not knowing whether 255 means that an intensity close to 1.0 is being represented (no distortion), or an outlier intensity of 37.49 (severely clamped). That could go the other way too.

In other words, there is a possible bias in the extreme bin. The signal could be limited such that the bin's full sampling range is not in effect, or the signal could be overwhelming, so that values far outside of the range are clipped and included.

The only way around this is to make the highest value a canary which represents "clipped value". That is to say, 255 means "clipped datum", so that only 254 and below is sampling of unclipped signal. Machine-generated image (e.g. 3D rendering) then avoid the 255 value, and camera sensors are calibrated so that it doesn't occur when technical images are being shot.

If you can make the vehicular homicide look like an accident, you are scot-free, except for increased insurance premiums. No criminal charges, and no civil case to face.

https://en.wikipedia.org/wiki/George_Stinney

https://www.cbc.ca/news/canada/british-columbia/gay-basher-g...

6 years is not a lot, but it's the same length of sentence handed around the same time to a random murderer who killed a welder from Thailand.

https://www.cbc.ca/news/canada/edmonton/killer-of-thai-welde...

From these we know two things: a human life is not worth a fuck in Canada, but at least gay and non-gay is about the same.

But, oh, bombs, drones and air strikes will yield much better long-term results in Iran.

The benefit that everything is integrated, so there are no games with having to cherry pick things this way and that and losing fixes.

The apparent downside is that there is no isolation. Inside some of those #ifdefs is code that you are not building. But changes you are making can break that code for someone else.

While this may seem risky, it's actually better. Breaking something now is better than someone cherry picking your fix 8 months later into their branch and then dealing with the breakage.

Fixes to common code never get left behind; everyone working off the trunk instantly gets them.

The #ifdefs are immediately and constantly visible, telling you where the code is that is or is not part of what you are doing, and reminding you of its existence. They greatly discourage refactoring parts that you cannot test.

There is pressure to keep those #ifdefs clean, whereas people go hog wild when they have their own branch, thinking they can rewrite whatever they want to suit what they are doing.

The predecessor dialects of C were being silly to actually have a pointer word inside the declared array object; C kind of returned to the normal "assembly-like state of things" by treating a region of storage declared as an array as a base pointer, without that pointer being stored alongside the array.