I have a different theory. There are tons of wars and conflicts in the Middle East. Saudi Arabia vs Yemen, Iran vs Irak, Pakistan vs India, civil war in Syria, civil war in Somalia, civil war in Sudan, and everybody else is fighting ISIS. It’s not like the US/West are not involved or that the conflicts are any less bloody or that the parties have "better reasons" to kill each other. And still, they receive no where near as much attention and criticism as Israel/Palestine. I also don’t think the reason is antisemitism (at least in the West). I think the reason is that the West has to view everything through the lens of the culture war: it’s white vs brown and white is evil, therefore Israel is evil.
Israel has created its own perception of itself to the world. They gave up all sense of humanity to go on a revenge spree and now they don’t know when to stop because the whole world sees them as monsters so they probably think it couldn’t get any worse.
Changing the convo to talk about some other wars than Israel / Gaza is just another kind of deflection technique to avoid responsibility.
If it isn’t the antisemitism card, it’s the deflection card.
I encountered another pitfall when using `new URL` to check if a text contains urls. It accepts strings like ”example:”, “next:", etc. as valid urls because it interprets the string before the colon as a custom protocol. This is a real edge case in the spec, because with common protocols, just "http:", "https:" is not accepted as a valid url.
It's correct, though. The URI scheme for HTTPS may always include a domain name, but my-app: is just as valid a URL as anything else. A protocol where everything is optional and the default opens a screen with all fields empty is valid, though unlikely.
For instance, an empty mailto: will reliably launch an email client, even if no address is specified. I think it's the second most used protocol in web links, after HTTP(S).
If you want to to URL parsing by brute forcing URL constructors, you probably don't want application URLs in the first place. You should probably start with https:// and http://, or make use of the weird double slash HTTP introduced into the URL by matching on :// instead.
If you want to get real anal about it the API should probably called URI instead of URL. The latter should describe where to access the resource, not just how to identify it, and to truly be able to do that you must also know something about the scheme.
At the very least you must know whether the scheme imposes further restrictions on the individual parts of the URI, otherwise you can only determine whether it's a valid URI but not truly say whether it's a valid URL.
In practice no one really cares much about the distinction between identifiers and locators, and arguably it was a mistake to try and make that distinction in the spec. But it is in there after all and I find it a bit ironic that the authors of the JS spec chose to ignore it. There's probably good reason for it, but still.
What does "unsound method" mean in this context? Doesn’t that mean, if it finds a bug that this may not actually be a bug? I.e. it may give false positives?
I keep hearing this and I'm very interested. But most recommended resources I've seen so far are more targeted at Physicists. Any good text book for CS people?
Edit: nevermind, read in other comments that https://bivector.net/ has a ton of resources.
For me the big advantage is that it integrates much easier with my development environment. For example if I have a language server for some programming language running in Docker, it’s not obvious to me how to make it talk to my editor on the host. I can expose a port but both the editor and the language server need access to the code base I’m working on. I can mount the code base as a volume but the language server gets confused about absolute paths that are not matching and stuff like this.
Horn clauses just mean you can have a whole bunch of things saying "if x then y is true" where X is constrained to be a monotonic (i.e. no negation) Boolean function (i.e. OR and AND).
Given some starting known true values in the system (e.g. debug_build=true, platform_is_windows=true, build_curl_library=true) you solve to find the minimum set of other variables that need to be true.
Each variable can then have some effects tied to it (e.g. if build_curl_library is true, then make sure curl.c is compiled and curl/include is in the include path)
Being Horn Clauses, the solving is basically a flood fill - as soon as you know a variable is true, it is locked in as true. If there was negation, then you can have weird contradictions and reasoning about the system starts being really difficult.
reply