gaxun

Sure.

- On page 715 of Volume 4A, he had something like \`a when he meant to have just à.

- In Volume 1, Fascicle 1, there is a convention that the "main" entry point of an MMIX program begins at LOC #100. The convention is established early on and repeated throughout the text. However, at no point is it explained why LOC #100 was chosen (instead of LOC #0, LOC #80, or whatever). It could be gleaned through careful study -- LOC #0-#80 are reserved for trip/trap handling and one more location before #100 is reserved for a special second entry point -- but you basically had to read the entire fascicle to find /all/ of these. A naive user would be likely to try writing a program beginning at LOC #0 and wonder why it didn't seem to behave correctly. My suggestion was to just add a note explaining why LOC #100 was used. He agreed and you can find the added note in the latest errata for Volume 1, Fascicle 1.

Nice to see multiple of us are on here.

> I imagine most of these checks (definitely all $7 of mine)

The 0x$2.00 check I got from 10 Feb 2020 was for one typographical item in Volume 4A and one pedagogical improvement in Volume 1, Fascicle 1. So it is certainly possible to still get checks for material that is already published.

Since it is now 2020, anyone with bug reports from the typography stuff should send them in soon, wouldn't want to miss the deadline.

> when's the last time Knuth wrote a check for TAOCP?

Pretty recently. I just got one in the mail today.

The author should have written to Donald Knuth with an interview request for this piece. It would have added something special beyond just repeating what's already visible on his website.

I wrote to Professor Knuth about a project I did a year or two ago and was pleasantly surprised to receive a two page handwritten note in response. So it seems like the no-email filter is probably still working well for him.

Indeed.

Web browsers are generally free to use and there are several serious contenders and many less popular ones.

So the main thing they should be competing on is user experience.

But it seems to me that browsers frequently fail to deliver a user-first experience.

The browser should only take actions specifically requested by a user, as his agent. Everything about the experience needs to be reframed from that perspective.

Some browsers lately seem to be doing a little better at this, but just adding "advanced flag" features on to an existing product isn't going to help mainstream users at all.

> hurdle of setting up team repositories with safe credential management...like for any kind of collaboration

Identity continues to be the key selling point of keybase. I'm excited by this.

I can keep clones of my private repositories here. Things like dotfiles and configurations. That sounds like a good start. And I can also easily share code to people who need to see it.

I've been trying out this extension for a few days.

What I would really like to see from this extension is a 1-click way to sign any message I'm writing, anywhere on the internet. Along with that would be the ability to verify that a keybase signature found in the wild belongs to a particular keybase user. Then I can initiate out-of-band discussions with the author of a comment on someone's blog, not just with a Reddit or Hacker News poster.

Having the keybase chat button appear next to posts on sites like Reddit, HN, etc. seems like a great step toward a "metaweb" platform as well. For example, I could let someone know about the typo in their post via keybase chat, rather than polluting the public comment stream.

Very excited.

Thank you for the explanation. This has been my only experience with the W3C system and as an outsider it was very intimidating. I'm certainly willing to accept the idea that I wasn't going about things the right way or understanding what I was reading!

> there's nothing in the spec that prohibits extensions to the set of fields

Correct. But since it has all this "JSON-LD" stuff baked in, you need to also carefully define and publish the extra fields.

I tried emailing two of the names listed at the time, for two different purposes. I got a little bit of a response from one, nothing from the other.

I read the "rules" for W3C groups and in order to actually participate you need to be a member of a big organization and all this other stuff. I'm not sure anyone would have listened.

As I mentioned in another comment, these tests can be trivially passed. You just paste in some JSON data. To pass "all" the tests you actually only need to implement a small handful of the fields. The rest of the tests are qualified by something like "if present" -- so you pass those by just not having anything present in your test case.

When I use the hypothes.is extension, I see queries in my browser's developer console that do not look anything at all like they are querying annotation collections as defined in the spec.

The data returned from these queries is close to the spec but includes many fields that aren't in it. These extra fields seem to be conveying important information for their application.

Edit: I ran one of their annotations through the W3C tests. Five failed tests. Including one of the most important fields:

       {
          "name": "1:2 Implements **Annotation _id_ key** which has a **single value** that is a **string of format uri** - [model 3.1](https://www.w3.org/TR/annotation-model/#annotations)",
          "status": "FAIL",
          "message": "assert_true: ERROR: Annotation is missing id key or its value is not a single string of format uri.; expected true got false"
        },

This is why I said I'm not confident they are actually using it.