steerablesafe

The specification does have a hierarchical outline, and you can click on cross references too. Of course navigation can still be cumbersome, linking to chapters can also be awkward (tip: right click on outline element and copy link works in Firefox).

There are some problems of the spec though, and navigation is not the most pressing one. The spec is huge, support for less used parts is spotty in various PDF readers. It also has inaccuracies (not corrected in errata) and underspecified parts.

No worries! How did you find the "opensource.adobe.com" link? I can't hit it with google, even with aggressive searches like "site:opensource.adobe.com filetype:pdf". And I can't seem to navigate there from the main page.

Ah, thanks for the link. For some reason that link doesn't turn up in google search for me, however hard I try. Of course the ISO one is also authoritative, but not free.

What would be also cool is a syntax aware custom merge driver for git, but that's probably even harder.

You can have the numpad on the left, but I rarely saw keyboards like that. I saw some odd "left-handed" rubber dome keyboards, but that's it. You can also have a distinct numpad and put it anywhere.

Sometimes the bottleneck is on the server end, and often they throttle throughput per connection. Some download mangers allow you to download the same file through multiple connections and range request. Having said that I think it's a little bit rude to work around the intended throughput limitation.

I recommend aria2 for a similar purpose. Just `apt install aria2`. I'm just a happy user.

From the pricing page, limits seem to be on number of documents, not number of pages. Is the number of pages per document also limited?

It feels like an awkward middle ground. Like this method has a limited entropy output for the first 2000 coin flips (first 1000 double-heads/double-tails/mixed entries), and then suddenly it adds back a ton of lost entropy.

An other commenter linked to some papers for asymptotically optimal entropy generation, I wonder if there is more of a streaming method there. It feels like there has to be, even maybe after a slow start. My naive intuition is that after 1000000 coin flips you have a good idea what p is, and then you can basically do arithmetic coding from there. Of course a theoretically correct method can't do exactly this, but it might asymptotically approach it.

> My mouse looked like Christmas tree until I installed some electron app on windows.

At least solaar exists for Logitech stuff. Too bad it's still not something Logitech provides, but the reverse engineering work of some volunteers.

https://pwr-solaar.github.io/Solaar/

My impression is that arithmetic coding is the inverse. You have N symbols with different known probabilities, and you turn it into a stream of 1/2 probability random bits.

edit: On second thought this is probably a bijection and you can call it "arithmetic coding" in either direction.

This method generates approximately

  log_2(sqrt(1/(2*pi*p*(1-p))) - 1000*log_2(p^p * (1-p)^(1-p))

bits of entropy from 1000 coin flips, where "p" is the probablity of flipping heads.

Neumann's method generates 1000/(p(1-p)) bits of entropy from 1000 coin flips. The theoretical maximum is

  -1000*log_2(p^p * (1-p)^(1-p))

but it requires knowing "p" exactly. This method is close to the theoretical maximum. I didn't plug in numbers, or analyise further, but it's far better than Neumann's method.

One obvious drawback is that you have to flip the coin a 1000 times to produce the first unbiased random bit, while Neumann's method starts producing bits much earlier.

Arithmetic coding.

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

As an outsider to web development, @when would be a weird choice. If CSS wants to enable 3rd party tooling to take some of the syntax space, then it should declare some parts of the syntax never to be taken by core CSS (if it's not already done this way). Then this syntax clash would never be a problem between a 3rd party tool like sass and CSS.

In this case I think it's on sass to introduce the awkward workaround on the syntax clash.

> is it even legal to memcpy more than a T's worth of data into a T? (IMO you shouldn't be doing that, but I think it's legal in C, and not with my template trick.)

How can you know if it's a single `T` or an array of `T` objects? You can memcpy into an array of `T` through a `T*` with no limitation on the size. I don't see anything inherently wrong with that either.

It's well defined in the system V ABI, isn't it? Compilers do follow that. Otherwise no layout is defined by the C and C++ standards, even outside of bitfields.

edit: It's under "Bit-Fields" in [1]. I'm not entirely happy with the wording, but it's there.

[1] https://raw.githubusercontent.com/wiki/hjl-tools/x86-psABI/x...

Bitfields are standard, what are you talking about?

I expected C with libcurl on the list, but in a sense that might be the toughest to implement.

From experience, opening a bank account in the UK takes a while. And for that time you need cash on hand, or a working foreign bank account/bank card.

I guess I can understand that from an ease of configuration standpoint. Having said that I had no trouble with setting up zerotier VPN, which is also very easy to configure.

Any reason you don't use some kind of VPN solution for that instead?

That's easier said then done, when you integrate over a high dimensional (possibly infinite) space.

Keep calm and continue using Debian.

`puts` has a return value indicating success or failure.

edit: https://cigix.me/c17#7.21.7.9.p3

You can't have bugs if you don't have a specification. [insert meme here]

This is not a technical issue. But if you aim for the software to be packaged in official distro repositories, they possibly don't want you to have other backported dependencies, such as a new version of libstdc++, or you to vendor in those libraries.

Yes, the quote for [meta] only specifies UB (although it should arguably be IFNDR). If yourself implemented `your::is_constructible_v`, then in translation units it instantiated differently for the same template arguments, then it would be ODR-violation according to https://eel.is/c++draft/temp.point#7.sentence-4 .

NVIDIA could have violated some patents with their design themselves (even unknowingly). There are legitimate reasons why NVIDIA wouldn't want the leak to happen, even if other companies likely wouldn't touch it.

I agree that there is little reason to not use a newer compiler to target an older distro, but there is one issue: the standard library. With newer language versions the standard library also grows. Older distros ship with older standard libraries, and they probably don't have the newer language facilities in them.

At work we sidestep this by building the new C++ standard library implementation against an old libc, and ship it with our product. I can imagine that this could be problematic for other software though, especially ones that normally ship with the disto.

There is no ODR violation in this itself either:

  template<class T>
  class S {
  public:
    // template<std::enable_if_t<((void)sizeof(T), true), bool> = false>
    explicit S(unsigned char *) {
      static_assert(sizeof(T) > 0, "oops");
    }
  };

It was always about usage. Some constructs are easier to misuse than others.