snatchpiesinger

I assume that firing was a bit more selective in who they wanted to keep.

> Actually it was a bit unexpected that it would have known to do that; it must have used its complete IMU data to even know it was rolled, as plain accelerometer would have been pointing "down" as usual.

That actually feels like overengineering based on well-intentioned, but wrong specs. You probably want to just use sideways acceleration for "falling over" detection, instead of roll.

It's fine as long as you catch all exceptions, and only produce ones that you document. Your users aren't supposed to know that you used `requests` at all.

Python dlopens binary wheels with RTLD_LOCAL on Linux, and I assume it does the equivalent on Windows.

There were issues relatively recently with -ffast-math binary wheels in Python packages, as some versions of gcc generates a global constructor with that option that messes with the floating point environment, affecting the whole process regardless of symbol namespaces. It's mostly just an insanity of this option and gcc behavior though.

You can have private and public dependencies. Private dependencies are the ones that don't show up on your interface at all. That is you don't return it, you don't throw it or catch it (other than passing through), you don't take callbacks that have it in their signature, etc... You can use private dependencies for the implementation.

It should be safe to use multiple versions of the same library, as long as they are used as private dependencies of unrelated dependencies. It would require some tooling support to do it safely:

1. Being able to declare dependencies are "private" or "public".

2. Tooling to check that you don't use private dependencies in your interfaces. This requires type annotations to gain some confidence, but even then, exceptions are a problem that is hard to check for (in Python that is).

In compiled languages there are additional compilications, like exported symbols. It is solveable in some controlled circumstances, but it's best to just not have this problem.

The actual video title is "Lorenzetti Electric Shower Head", the HN submission title is edited to include the nickname "suicide shower head". I think the best would be is to just use the actual video title here.

FWIW it's just a nickname for their apparently dangerous design (which doesn't necessarily translate to actually dangerous), it has nothing to do with suicides.

> Aliasing in sound is usually painfully untolerable. It does not seem to be like that in graphics.

It's tolerable in graphics in many cases, but becomes painfully obvious when the spatial frequency of some model approaches the pixel grid's frequency, and you get very distracting Moiré patterns.

edit:

But I guess in 3D rendering you deal with this differently, probably. You probably don't want to spend resources on painting model details that are half a pixel in size, so they get entirely culled, instead of causing any Moiré problems.

There are two paths:

1. Fork and cherry-pick from upstream, don't accept contributions from outside. They need minimal changes.

2. Fork and maintain their fork independently, try to get community contributors too.

git log --first-parent

I wonder what the fallout of this will be. If this results in a successful fork of wordpress with a registry independent from Wordpress.org that would be quite ironic.

We also did it in uni, it was very exhausting. And after a full day of measurements noone ever had enough data to see the quantization of the charge of electrons.

> Cyclists rarely leave the bike lane for pleasure, it's usually either because a car is parked on the bike lane, pedestrians are walking on it, or because there's litter or a bad surface (bikes are much more sensitive to uneven road surface, but at the same time bike lanes, especially those that are separated from the road, are often built with lower standards than the streets).

Or you know, turning left (or turning right in the UK). Or entering a roundabout, where it's generally better to take your lane, if you are not leaving at the first exit.

It can get minified/optimized by a tool. The "source code" is what you immediately edit, but you might not distribute that version, only a "binary" derived from it.

I use DejaVu Sans Mono for programming, it places a dot inside 0.

Cool! My personal preference is Knuth-style line-breaks on binary operators and pipes, which means breaking before the operator/pipe symbol.

  foo -a -b \
  | bar -c -d -e \
  | baz -e -f

instead of

  foo -a -b | \
  bar -c -d -e | \
  baz -e -f

This doesn't seem to be an option, but could be easy to implement.

At the same time if you suggest "maybe we shouldn't use X, Y and Z analytics then" then you get laughed out of the room. So is there really a choice?

I would appreciate if it didn't send notifications about me having unread notifications. And no, I can't turn this notification off separately.

It's a bit cumbersome, and I think only recently you can make longer dependency chains. It's certainly not automated away with just git commands, but maybe there there is a Gitlab API way. The only way I know is to "edit" the PR (or MR in Gitlab speak) and paste the URL into some "depends on" field, then save.

There are certainly other problems as well, like you might have an MR 1 from feature1 to master, and MR 2 from feature2 to master which in turn depends on MR 1. Most likely your feature2 branch is off your feature1 branch, so it contains feature1's changes when compared to master, and that's what is shown in the Gitlab review UI. This makes reviewing MR 2's changes in parallel to MR 1 frankly impossible.

Having said that, I still think that this would be the right way to organize this kind of work, however Gitlab's execution is not great, unfortunately. Any of this is probably impossible in Github too. I wonder if Gerrit gets this right, I have no experience with it.

edit:

One interesting point of MR dependencies in Gitlab is that I think you can depend on MRs from other projects. This is sometimes useful if you have dependent changes across projects.

It's fine to break commit atomicity on feature branches. You can use git bisect --first-parent on you development/master branch.

Another way to look at this that this is 3 linearly dependent PRs masquerading as one. Make each a distinct PR and the problem goes away, especially if you can mark the PR to depend on another one (on Gitlab you can, not sure about Github). If you want to see each change as a single logical unit, then they will each be a distinct merge commit on your master branch, use `git log --first-parent-only master` to only see these kind of changes.

"Commit pending writes" and "discard file handle" should ideally be separate operations, with the former potentially returning errors and the latter being infallible. "Discard file handle" should be called from defer/destructiors/other language RAII constructs, while "commit pending writes" should be called explicitly in the program's control flow, with its error appropriately handled or passed up the stack.

Whether if it's allowed to write again after a "commit pending writes" operation or not is a separate design decision. If not, then in some languages it can be expressed as an ownership taking operation that still allows for handling the error.