| 05:17 | <gg20> | Hello? |
| 05:20 | <gg20> | sounds pretty quiet in here |
| 05:59 | <annevk> | That may be because it’s IRC and not Skype |
| 07:42 | <tkore\work> | lol @annevk |
| 08:44 | <tobie> | annevk: thought the urls through and you were right, I can dramatically simplify them. |
| 08:45 | <annevk> | \o/ |
| 08:55 | <tobie> | annevk: settled for: |
| 08:55 | <tobie> | https://www.irccloud.com/pastebin/oNS0tw98/ |
| 08:56 | <tobie> | annevk: it's important to do: /infra/45/7dfd134.html instead of /infra/7dfd134.html, otherwise you get lots of noise in diffs (e.g. between PR numbers) |
| 08:56 | <tobie> | When you have multiple PRs that have the same merge base |
| 08:56 | <annevk> | tobie: it seems nice to include the PR number actually |
| 08:57 | <annevk> | tobie: gives you some assurance you're looking at the correct thing |
| 08:57 | <tobie> | annevk: we could even do it for the diffs |
| 08:57 | <annevk> | tobie: please; thanks for doing this |
| 09:46 | <tobie> | annevk: done. |
| 10:50 | <annevk> | Domenic: I'm surprised https://lcov-report-sngrqbipez.now.sh/serializer.js.html ends up with 100% coverage even though nothing calls it with excludeParameters; I guess it doesn't do "dead code" detection, but that would be nice |
| 12:09 | <annevk> | hsivonen: isn't this removal of non-UTF-8 file paths still a theoretical concern even on modern platforms? |
| 12:10 | <annevk> | hsivonen: I thought APFS didn't enforce UTF-8 for instance |
| 13:45 | <hsivonen> | annevk: on Unix (except HFS+), file paths are sequences of bytes |
| 13:45 | <hsivonen> | annevk: on Windows, they are sequences of 16-bit units |
| 13:45 | <hsivonen> | annevk: so pretty much everywhere (except HFS+), paths are not guaranteed to be representable as Unicode |
| 13:46 | <hsivonen> | annevk: however, on *nix these days, if you want to make a text string out of a file path, decoding as UTF-8 is what makes sense |
| 13:46 | <hsivonen> | annevk: and on Windows, interpreting as UTF-16 |
| 13:47 | <hsivonen> | annevk: so any tool that assumes that paths fit in text is lossy |
| 13:47 | <hsivonen> | annevk: so if you are writing a backup tool or another kind of tool that has to be able to deal with all files, it's fundamentally wrong to let paths be represented as text as an intermediate operation |
| 13:47 | <annevk> | hsivonen: why not write non-lossy tooling? Or are we only talking about displaying these? |
| 13:48 | <hsivonen> | annevk: however, for many apps, it's good enough to be lossy and it's too hard to enforce the discipline that paths must be non-text objects |
| 13:48 | <annevk> | If we ever get RustFS I hope it guarantees Unicode |
| 13:49 | <hsivonen> | annevk: I argue that a Web browser, especially one whose parts are implemented in JS, is a program that just has to be lossy for paths that aren't valid UTF-16 on Windows or valid UTF-8 on *nix |
| 13:50 | <hsivonen> | annevk: I might have a different opinion if no part of file handling was implemented in JS |
| 13:50 | <hsivonen> | annevk: i.e. if it was all Rust |
| 13:50 | <hsivonen> | annevk: Rust's standard library models this stuff the right way |
| 13:50 | <hsivonen> | few things do |
| 13:51 | <hsivonen> | (Rust gets it right when few things do is a general theme when it comes to Unicode-ish things) |
| 13:52 | <hsivonen> | annevk: one thing on my mental todo list is researching if Microsoft browsers can represent arbitrary Unicode in file: URLs these days |
| 13:53 | <hsivonen> | it would be nice if we could make file: URLs on Windows less lossy than they are now in Firefox |
| 13:55 | <hsivonen> | paths are one of those things that superficially look like text, so programmers think it's OK to process them as text, but there's a subtle mismatch |
| 13:55 | <hsivonen> | this arises from kernel devs (both NT and *nix) kernel devs making it not their problem, so it's every userland app's problem |
| 13:56 | <hsivonen> | but with HFS+, we see what happened when well-intentioned kernel devs tried to make it their problem |
| 13:56 | <hsivonen> | from the frying pan into the fire |
| 13:59 | <annevk> | hsivonen: you mean the not quite NFD normalization? |
| 13:59 | <hsivonen> | annevk: yes |
| 14:00 | <annevk> | hsivonen: Rust is a good pointer point that low-level folks can get it correct |
| 14:01 | <annevk> | hsivonen: I'm a little sad APFS didn't enforce UTF-8, although even then I guess you haven't quite solved the display problem, but at least you use strings |
| 14:40 | <gsnedders> | annevk: I presume also wanting everything to be convertable from HFS+ to APFS made it impossible to enforce |
| 14:41 | <gsnedders> | (using text for all files is one thing Python 3 got wrong, IMO, as it makes it impossible to open some files) |
| 14:44 | <annevk> | gsnedders: why, HFS+ was Unicode-compatible |
| 14:44 | <annevk> | Oh Python. Whenever I use Python I always struggle with Unicode |
| 14:45 | <annevk> | You'd think that converting between integers and characters would be easier |
| 14:48 | <gsnedders> | annevk: mismatched surrogates, no? |
| 14:50 | <annevk> | gsnedders: I thought not |
| 15:06 | <Domenic> | annevk: that branch gets taken a bunch of times though since the zero-parameters case occurs. If we'd written it as two if statements we would have seen loss of coverage, yeah. |
| 15:07 | <annevk> | Domenic: seems the tooling should see that somehow |
| 15:07 | <annevk> | Domenic: and flag part of the || conditional as always being false |
| 15:08 | <Domenic> | Yeah, right now it only does branch granularity, not expression granularity; I haven't seen tooling for expression granularity yet. |
| 15:24 | <hsivonen> | annevk: looks like Python 3.6 tried to add back support for non-Unicode file paths on *nix. Not sure if paths that are invalid UTF-16 are representable in Python 3.x on Windows |
| 15:24 | <hsivonen> | annevk: https://www.python.org/dev/peps/pep-0519/ |
| 15:35 | <gsnedders> | hsivonen: oh I'd missed that entirely |
| 16:32 | <Mek> | okay, uploaded an initial attempt at better defining blob URLs... still a lot of work to do though... |
| 18:08 | <Domenic> | \o/ |
| 18:45 | <hsivonen> | GPHemsley: I take it that it's by design that MIME sniffing doesn't sniff files that start with BOM as HTML even if the BOM is followed by a pattern that would otherwise sniff as HTML? |
| 19:51 | <zcorpan> | hsivonen: maybe ask if abarth remembers? Iirc the patterns were based on data he gathered |
| 21:23 | <paul_irish> | annevk: i gave you Founder privs on this channel |
| 21:25 | <paul_irish> | annevk: you can have chanserv op you with: /cs op #whatwg annevk |
| 21:25 | <paul_irish> | annevk: and feel free to augment the access list with whoever you want. |
| 21:30 | <paul_irish> | I also gave channel op to Domenic, zcorpan, and MikeSmith to round things out a bit. |
| 21:31 | <Domenic> | ooh fun |
| 21:31 | <Domenic> | thanks paul_irish! |
| 21:32 | <paul_irish> | ( I don't entirely remember, but I guess this channel was unregistered 7yrs ago, so I kicked that off? ¯\_(ツ)_/¯ ) |
| 21:39 | <zcorpan> | Thank you paul_irish |
| 23:50 | <TabAtkins> | Yo, anyone reported yet that whatwg.org's https is broken? |
| 23:51 | <TabAtkins> | It's specifically html.spec.whatwg.org, actually. The more general domains work. |
| 23:56 | <hiroshige> | I also found the issue, but not sure where to report > SSL html.spec.whatwg.org |
| 23:57 | <hiroshige> | creating a github issue? (not sure) |