mnarayan01

Yea I'm not getting the need to keep _source in collections.namedtuple at all. For teaching purposes, you can just present the existing implementation...I don't see what purpose having that teaching code be in the core distribution serves?

I agree with everything you're saying (though my favorite is probably addresses containing newlines). My point is just that in practice it's not terribly useful, e.g. why HTML5 defines its own: https://html.spec.whatwg.org/multipage/input.html#valid-e-ma....

> or a valid email regexp

In terms of standards, there's not a whole lot you can do beyond validate the domain if it includes one. You can take the HTML5 approach (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...), but that means leaving out at least theoretically valid email addresses.

I remember reading about some framework which was doing something nutty like embedding actual data in the comments on a function, and then parsing out those comments at run-time. For what it's worth, I believe it was on HN and in relation to the caveats for older V8 optimization w.r.t. function length (https://top.fse.guru/nodejs-a-quick-optimization-advice-7353...), but it was years ago so, as you say, hopefully they moved to something less insane in the intervening time.

Aside since you're here. The "Would it be possible to write a tool to convert serialized AST back to JS?" portion of the FAQ (https://github.com/syg/ecmascript-binary-ast#faq) says that it would be possible to generate source which would be "semantically equivalent" -- you might want to call out the Function.prototype.toString exception explicitly there, though admittedly that level of pedantry might be more obscuring than enlightening.

For those curious about how this would deal with Function.prototype.toSource, via https://github.com/syg/ecmascript-binary-ast#functionprototy...:

> This method would return something like "[sourceless code]".

Consider the need to block on e.g. the DOM.

Via https://github.com/easylist/easylist/commit/a4d380ad1a3b33a0... by one of the Easylist maintainers:

> If it is a Circumvention/Adblock-Warning adhost, it should be removed from Easylist even without the need for a DMCA request.

Anyone know why he's saying this?

Edit: I guess he's referring to the following via https://easylist.to/2013/05/10/anti-adblock-guide-for-site-a...:

> Anti-Adblock should only be challenged if the system limits website functionality or causes significant disruption to browsing

1. Functions which are "longer than they should be" decrease code quality.

2. Measuring the "number of lines per function" is extremely easy.

Code quality tools have a bad tendency to equate (1) and (2) for the same reason that the proverbial drunk searches for his keys under the streetlight. This has legitimately bad consequences.

This is further compounded by the way that small functions ease mock-based testing. While certainly attractive in the abstract, when a code base is overly influenced by this I find that it is substantially more difficult to understand via inspection.

All that said...I find the whole "X considered harmful" formulation almost unbelievably annoying. Here it doesn't even make any sense.

> I'm not recommending this, but it meets many of his criteria.

Woah...déjà vu.

> It baffles me that some people thinks Firefox is becoming a “Chrome clone”, it’s just not the case, it’s just plain silly to make such statement.

If you use a much narrower definition of "clone" than is typically used in this context, then sure. If, however, you use "clone" a bit more flexibly, and note the word "becoming", then it's a different story. That's not to say that Firefox won't be better than Chrome, and it's certainly not to say that it won't have any advantages over Chrome, but it is giving up some of its major current advantages.

He should have been told regardless. I can totally understand, sympathize, and even potentially agree with an evaluator not wanting to deal with sloppy handwriting, but a context-free failing grade is just totally unacceptable.

Page swapping seems like it makes a lot of sense to include in the load average. Disk I/O seems like something more towards the opposite end of the spectrum, though TASK_KILLABLE (https://lwn.net/Articles/288056/) presumably mitigates this where used.

> Application software MUST NOT use a searchlist to resolve a localhost name.

Anyone using DNS search lists to have localhost resolve to e.g. localhost.example.com would potentially have problems. Obviously this is a pretty weird thing to intentionally do, but it currently gives you a quick way to get around certain issues. Obviously this is ugly, but in some ways that actually makes breaking it more problematic: Things which this breaks are likely to be things that are difficult to fix.

I think this is also an argument with potential (at least when presented as here, i.e. without excessive reference to WannaCry), but I think you need to either have a decent amount of affirmative evidence against him having sold Kronos or to wait at least several days before using the DOJ's absence of presented evidence as evidence of absence.

W.r.t. the latter, I'm not saying that the DOJ should have had him arrested if it lacks serious evidence of his guilt. I'm saying that his arrest has happened; it's too late to stop it. The question is whether it should have happened, and, since we're highly unlikely to be able to change anything within a few days, it seems like it makes sense to wait a few days before asserting that the DOJ lacked evidence to support the arrest if only to avoid poising the well. If it turns out that they didn't have any evidence, then the arrest was a problem which needs to have consequences. But I think being over-eager at this point greatly lowers the probability of there being any such consequences.

As someone who's not sure where I stand on this, I feel like Hutchins supporters are doing themselves a disservice by overly-conflating this with WannaCry. I think there's potentially a good argument to be made along the lines of "Hutchins good work w.r.t. WannaCry is the only reason that anyone (including law enforcement) is aware of semi-historical Kronos, so going after him for Kronos is equivalent to going after him for WannaCry." Additionally, there may well be other arguments in his favor that I'm not even thinking of.

But those arguments need to be made (and the one I outlined would need decent factual details). That said...maybe glossing over (or even totally ignoring) Kronos is the best way for Hutchins supporters to go...but if it is, that seems an unfortunate reflection on society.

Firefox tries to minimize breaking API changes, but there have certainly been plenty of them. While avoiding API changes presumably made the switch to multiprocessing more difficult, it didn't stop it; they made the switch. The fundamental problem with extensions and multiprocessing (at least from the perception of someone who wrote FF extensions) is the obvious one: Rather than having everything for all windows in a single thread, now you have them in different processes; communication goes from literally nothing to IPC.

I think it's an auto-antonym, i.e. divide opcodes into three sets:

  1.  Documented
  2.  Undocumented and throws #UD
  3.  Undocumented but does not throw #UD

Some people will use "Illegal instruction" to refer exclusively to (2), some as exclusively to (3), and some as both (2) and (3).

Edit: Interesting to see https://github.com/xoreaxeaxeax/sandsifter/tree/dff63246#fla... for how the author of Sandsifter describes the --ill option:

> --ill - the inverse of --unk, search for invalid disassemblies (instructions that do not successfully execute but that the disassembler acknowledges)

If we assume "disassembler acknowledges" is approximately equivalent to "documented", then --ill is actually looking for a subset of (1): "Documented but throws #UD"...which also seems fairly natural, at least in this context.

There might not be enough to get e.g. one of the private keys, but you could probably use it to check for someone else in the contact list.

The CRL also seems like it might be possible to at least pivot off of, at least if the signing wasn't checked when writing the archive.

> Why can I not "Create an app loading screen" without service workers? Why can I not "Create an initial app UI to load instantly"? Seems these are trivially possible with regular Javascript, but maybe I'm misunderstanding?

If you're waiting on async requests than everything is fine without Service Workers, but if you're performing computation then the whole UI will be blocked.

For this to be taken seriously, I think you need to demonstrate that you're capable of using WebRTC to do what you need. Without a decent nod in that direction, people are going to think that you're just not aware of the potential complexities.

> UDP is not streamed but message based protocol. As WebSockets implement their transport layer over pure TCP, WebUDP could implement it's own layer over pure UDP for various reasons.

As soon as your message exceeds the MTU, things get complicated. Sure you can layer something to re-assemble, but if packets are dropping, this is going to start getting problematic really fast. And if packets are not dropping, then TCP shouldn't overly increase latency anyway.

> Emacs maintainers sometimes commit directly in the Elpa repository (and package maintainers are expected to deal with the consequences, such as "two diverging mainlines")

Is a model like this what you mean when you say "No, we would continue to use Github for the foreseeable future"? I guess if you're doing all the legwork, it won't be overly visible to other people who want to contribute. Still though...

EME removes much of the cost associated with adding DRM to content in exchange for increased portability of content that is DRM'd.

This doesn't seem like a good trade-off to me. Yes it's only for "media", but once it's essentially free to add DRM, I foresee a whole bunch of current content becoming "media" in ways that I'm going to find unfortunate even totally disregarding the DRM aspects.

That said, I neither consume much content that's currently DRM'd nor do I have any technical difficulty accessing such content, so other's might want different trade-offs.

> If that's what content creators want, isn't it in their right?

Absolutely. That's not particularly relevant to the normative question of whether the HTML standard should make adding DRM less of a pain point though.

Even if the sampling was rigorously random and no projects were dropped after starting, there would still likely be a bias towards small, "long tail", projects. It seems plausible that these types of projects would have more errors (or vice versa).

> Also certain games such as FPS are still better off with UE, as that's what it was designed for.

What game types would you consider Unity to have better performance and/or tooling for? Also, if you're feeling generous, why?

> I've always been confused by why Ruby uses symbols so much.

Good: Other people mainly covered it. Also note that when writing extensions using the C API, accepting options as symbols is generally much more convenient.

Less good:

  val = "something"
  val = :something
  # Saves one character and no need for an end token.

  { "key" => val }
  { key: val }
  # Saves four characters.

Where are you getting O(sqrt(n)) space from? The linked article says O(n) for compact dynamic arrays.

The are many things which are difficult to measure directly, and thus people tend to use indirect measurements instead; school-learned math is full of such things. Consider a fairly simple example: "What is the factorial of a number?"

Determining whether a student knows this is going to take a bit of work (particularly if they lack a formal way to specify it e.g. Pi notation or even a programming language), but we might approximate it by instead asking "What is the factorial of 5?" Now obviously this is not a perfect measure of what we're actually looking for even in the absence of calculators (e.g. someone might memorize 5! = 120), but it's easy to evaluate and is probably a decent proxy in the absence of calculators.