| 00:25 | <MikeSmith> | botie: inform yoav lemme know if you need help getting html-build working locally (I've not seen the curl error with wattsi download before) |
| 00:25 | <botie> | will do |
| 01:45 | <botie> | yoav, at 2016-01-08 00:26 UTC, MikeSmith said: lemme know if you need help getting html-build working locally (I've not seen the curl error with wattsi download before) |
| 07:01 | <yoav> | MikeSmith: If you're around, I'd love some help |
| 07:02 | <yoav> | seems like the server from which wattsi is pulled is flaky |
| 07:02 | <yoav> | keep erroring out mid download |
| 07:15 | <yoav> | Oh, we're uploading source to the server cleartext??? Why don't we gzip it? |
| 07:18 | <MikeSmith> | hi yoav |
| 07:18 | <yoav> | hey |
| 07:18 | <yoav> | I'm installing wattsi locally |
| 07:18 | <yoav> | I'll bug you if that goes south :) |
| 07:18 | <MikeSmith> | hai |
| 07:19 | <MikeSmith> | that should workーI've been running it a lot lately |
| 07:19 | <MikeSmith> | though I have some pending PRs with refinements |
| 07:19 | <MikeSmith> | but as far as the curl problem, you mean http://ec2-52-88-42-163.us-west-2.compute.amazonaws.com/ which the wattsi output is pulled from? |
| 07:36 | <yoav> | MikeSmith: yeah |
| 07:36 | <yoav> | looks like my post gets an error mid way |
| 07:38 | <yoav> | free pascal???? |
| 07:38 | <yoav> | ftp://freepascal.stack.nl/pub/fpc/beta/3.0.0-rc1/ has no x86_64 OSX version |
| 07:39 | <yoav> | and brew gives me 2.6.4 |
| 07:46 | <yoav> | brew update cures it |
| 07:50 | <yoav> | now missing dateutils... |
| 08:16 | <annevk> | yoav: you can install from ftp://freepascal.stack.nl/pub/fpc/dist/3.0.0/ these days |
| 08:16 | <annevk> | yoav: the dmg in ftp://freepascal.stack.nl/pub/fpc/dist/3.0.0/i386-macosx/ should be okay |
| 08:17 | <yoav> | OK, thanks! I'll try it out |
| 08:18 | <annevk> | https://github.com/whatwg/wattsi/pull/12 for the change to 3.0.0 |
| 08:18 | <annevk> | MikeSmith: Domenic: ^ |
| 08:44 | <Ms2ger> | Domenic, do you want a fixup commit to review for https://github.com/whatwg/html/pull/482 or should I just force push? |
| 09:15 | <annevk> | Ms2ger: force push is fine |
| 09:16 | <Ms2ger> | Ok, thanks |
| 09:30 | <nox> | annevk: So can I go ahead to rename getter into legacygetter? |
| 09:31 | <nox> | Should I just write a PR for LegacyUnenumerable? |
| 09:31 | <annevk> | nox: yeah if you wanted to PR IDL you should do that |
| 09:31 | <nox> | annevk: Do what? :D |
| 09:32 | <nox> | I should stop asking multiple questions at once because I confuse myself in the process. |
| 09:32 | <annevk> | nox: rename getter and friends and add LegacyUnemumerable |
| 09:32 | <nox> | Ok. |
| 09:32 | <annevk> | probably distinct PRs, but I guess you know that |
| 09:33 | <nox> | Yes. |
| 11:25 | <rits> | annevk: hi, actually i was figuring out about this bug https://github.com/whatwg/html/issues/176 , as you did explained about the ArrayBuffer and to set the flag of request instance |
| 11:25 | <annevk> | MikeSmith: so does -Px86_64 break other platforms basically for wattsi? |
| 11:26 | <MikeSmith> | annevk: I think it won't have effect for other platforms |
| 11:26 | <annevk> | rits: ArrayBuffer seems unrelated to that bug unless I'm missing something |
| 11:26 | <annevk> | MikeSmith: perhaps we should just add it then? |
| 11:27 | <MikeSmith> | it wouldn't harm anything I guess |
| 11:27 | <MikeSmith> | but can you remind me what problem it solves? |
| 11:27 | <MikeSmith> | I remember some problem we had initially |
| 11:27 | <annevk> | MikeSmith: "If you're building on Mac OS X, the FreePascal compiler there defaults to building 32-bit binaries. But you can choose to build a 64-bit wattsi binary by adding -Px86_64 to the DEFINES line in the src/build.sh file" |
| 11:28 | <MikeSmith> | ok yeah |
| 11:29 | <MikeSmith> | I think there is no advantage to build 64-bit binaries |
| 11:29 | <MikeSmith> | oh, I guess you mean to eliminate the warnings? |
| 11:29 | <annevk> | MikeSmith: you did fix some of it in https://github.com/whatwg/wattsi/commit/fc38b65c0f2f45065db6f702e3a0408d7a886bc3 it seems |
| 11:29 | <MikeSmith> | yeah |
| 11:30 | <annevk> | MikeSmith: is there an advantage with 32-bit? I thought 32-bit is on its way out |
| 11:30 | <annevk> | MikeSmith: even phones use 64-bit these days |
| 11:30 | <rits> | annevk: amm yes, sorry i think i have interpreted to the ArrayBuffer because of the img, it's related to fetch standards, but i am not still very clear for the issue, if you could just give a brief idea |
| 11:32 | <annevk> | rits: update the image data, step 12, has "Fetch request", that request, needs to have https://fetch.spec.whatwg.org/#same-origin-data-url-flag set |
| 11:34 | <annevk> | rits: similar to how it has other things set, such as client, initiator, etc. |
| 11:36 | <MikeSmith> | annevk: IMHO the only reason to build a 64-bit binary would be if anybody had an enviroment that required itーI mean, if the 32-bit binary wouldn't run on somebody's system for some reason, or it ran but with some problems |
| 11:37 | <MikeSmith> | the thing is, the default behavior for fpc on OSX is to produce 32-bit binaries |
| 11:37 | <MikeSmith> | so IMHO we are probably best off sticking with the default behavior |
| 11:37 | <rits> | annevk: okay got that now, thanks |
| 11:38 | <annevk> | MikeSmith: but we're also saying that we cannot guarantee 32-bit compatibility in the README... |
| 11:39 | <MikeSmith> | yeah but in practice I think that doesn't matter, because nobody's actually trying to run wattsi on a 32-bit system |
| 11:39 | <MikeSmith> | anyway I don't feel strongly about it and in practice for us in this I think it makes no difference either way, so I'm fine with anything |
| 11:39 | <MikeSmith> | *in this case |
| 11:42 | <annevk> | MikeSmith: it seems to build and work fine without that flag so maybe the Troubleshooting note should say something else |
| 11:43 | <annevk> | MikeSmith: since I remember it not building before without that flag |
| 11:43 | <MikeSmith> | yeah |
| 11:43 | <MikeSmith> | ok, will update it |
| 12:48 | <MikeSmith> | annevk: https://github.com/whatwg/wattsi/pull/13 |
| 12:50 | <annevk> | merged |
| 12:51 | <MikeSmith> | ta |
| 13:26 | <smaug____> | MikeSmith: do I recall correctly that you had some page listing all the relevant web specs ? |
| 13:27 | <smaug____> | (while reviewing I often need to find random specs which I may or may not have read recently so awesomebar may or may not suggest the url) |
| 13:27 | <annevk> | smaug____: https://platform.html5.org/ |
| 13:28 | <smaug____> | how to get more specs added there |
| 13:28 | <annevk> | smaug____: https://github.com/whatwg/platform.html5.org |
| 13:28 | <smaug____> | thanks |
| 13:41 | <annevk> | wanderview: you around? |
| 13:42 | <annevk> | wanderview: I was curious how we model basic/cors/opaque responses in Gecko |
| 13:42 | <annevk> | wanderview: I don't really like the filter setup the specification has |
| 13:42 | <annevk> | wanderview: I wonder if it would simplify things if it was just a flag on response you'd have to check here and there |
| 13:43 | <annevk> | wanderview: which of course makes things a bit more dangerous if you don't know what you're doing, but hopefully folks writing specifications do know what they're doing... |
| 13:48 | <annevk> | Anyway, I guess I'll keep the current setup unless someone volunteers to redo it |
| 13:50 | <Ms2ger> | nikkibee might have thoughts too |
| 13:53 | <annevk> | true |
| 14:23 | <wanderview> | annevk: we do actually have a wrapper object like the spec |
| 14:23 | <annevk> | cool |
| 14:23 | <wanderview> | annevk: the filter/wrapper thing makes it easier to say "use the inner object here" without putting that logic in every getter on the response |
| 14:24 | <annevk> | yeah, I think it has the upside of it being very explicit when potentially dangerous stuff is going on |
| 14:28 | Ms2ger | wrote a couple simple tests, already has failures in Gecko and Chrome |
| 14:28 | <Ms2ger> | r? https://github.com/w3c/web-platform-tests/pull/2457 |
| 15:05 | <Domenic> | Ms2ger: I can try to get to that but will probably wait up to a week until I finish modules. But, if you have things that fail consistently in most/all browsers, maybe best to fix the spec? |
| 15:07 | <annevk> | Might also want to ask bz |
| 15:08 | <annevk> | He "loves" that stuff |
| 15:20 | <annevk> | So I messed up my local HTML checkout by merging something but not committing before MikeSmith committed something else |
| 15:20 | <annevk> | How do I undo this? |
| 15:20 | <Ms2ger> | Domenic, no two assertions fail in both Chrome and Firefox, I think |
| 15:21 | <Domenic> | annevk: git reset --hard origin/master will throw away all local changes |
| 15:22 | <annevk> | ta |
| 15:25 | <Ms2ger> | Domenic, thoughts on my reply on https://github.com/whatwg/html/pull/482 ? |
| 15:28 | <Domenic> | Ms2ger: I don't care about linebreaking much so maintaining surrounding style is fine. Will look over the rest when I get in to the office but I imagine I'll just end up merging |
| 15:28 | <Ms2ger> | Great, thanks :) |
| 15:30 | <annevk> | Domenic: empty robots.txt reduces error log messages |
| 15:30 | <annevk> | Domenic: so... mostly an Apache hack? |
| 15:31 | <Domenic> | Ah OK. Maybe add a comment explaining that. |
| 15:31 | <Domenic> | Although I don't know if there is comment syntax in robots.txt... |
| 15:35 | <annevk> | Done |
| 15:52 | <wanderview> | JakeA: ping |
| 15:53 | <wanderview> | can you refresh my understanding of how we intended updates to work on fetch events? |
| 15:54 | <wanderview> | my understanding seems different from what the spec says now... |
| 16:05 | <wanderview> | I wrote a spec issue: https://github.com/slightlyoff/ServiceWorker/issues/814 |
| 16:27 | <Ms2ger> | Huh |
| 16:27 | <Ms2ger> | I thought I found a bug in Chrome, wrote a test, and it only fails in Gecko |
| 16:29 | Ms2ger | is very confused now |
| 16:32 | <Ms2ger> | Looking at outdated chromium source: check |
| 16:32 | <Ms2ger> | Boolean argument that makes Gecko do something stupid: check |
| 16:38 | <Ms2ger> | (https://github.com/w3c/web-platform-tests/pull/2458) |
| 16:44 | <Ms2ger> | (Chrome was fixed in http://code.google.com/p/chromium/issues/detail?id=520849) |
| 16:58 | <rits> | annevk: https://html.spec.whatwg.org/#the-page i should just set the default directly to 8px because seamless browsing context is going to removed |
| 17:00 | <annevk> | rits: yeah, I think ideally you'd look at what that text said before seamless was introduced |
| 17:01 | <rits> | annevk: ok then is there any source for that |
| 17:01 | <annevk> | rits: well, the html git repository |
| 17:02 | <rits> | annevk: oh yeah, then it's perfect actually many sections needs a change as seamless is being removed that will help now, |
| 17:03 | <annevk> | rits: https://github.com/whatwg/html/commit/dfa3f22b5278113cba689c3cf6e358f17e334311 seems to be the commit |
| 17:03 | <annevk> | rits: there's many commits introducing seamless changes, you can use git log --all --grep='seamless' to find the hashes and messages |
| 17:05 | <rits> | annevk: great, i didn't knew about it, will solve it now |
| 17:28 | <zcorpan> | Domenic: annevk: i haven't reviewed module scripts yet (and not working today), but what happens when inserting a <script type=module> to the document after onload? |
| 17:28 | <Domenic> | zcorpan: it should just work |
| 17:29 | <zcorpan> | Domenic: just work as in execute like async? |
| 17:30 | <Domenic> | zcorpan: yeah I think so. Current commit might be a bit broken due to the bug aklein found. I am hoping to straighten that out today. |
| 17:30 | <Domenic> | And also spec the async attribute |
| 17:30 | <zcorpan> | Domenic: more concrete example: inserting two <script type=module src=...>, do they execute in insertion order or first-come order |
| 17:31 | <Domenic> | Oh I see |
| 17:31 | <Domenic> | The intent is insertion order unless you add the async attribute... I wonder if that is too confusing. |
| 17:32 | <zcorpan> | i suppose we should match <script defer>, though i don't recall what that does :-) |
| 17:33 | <Domenic> | I think that works... But maybe the inserted from scriptness overrides the deferness. |
| 17:33 | <Domenic> | I agree we should match |
| 17:35 | zcorpan | back to fredagsmys |
| 17:36 | <smaug____> | !seen foolip |
| 17:36 | <smaug____> | er, no such bot here I guess |
| 17:36 | <smaug____> | to detect !seen |
| 18:12 | <MikeSmith> | is there a test suite anywhere for JavaScript syntax errors? |
| 18:13 | <MikeSmith> | I mean where test cases with particular types of syntax errors |
| 18:13 | <MikeSmith> | e.g, "var ;" |
| 18:13 | <MikeSmith> | (missing variable name) |
| 18:17 | <Domenic> | MikeSmith: most JS parsers will do that |
| 18:18 | <MikeSmith> | Domenic: yeah I know but what I meant was I'd like a set of test cases to test with |
| 18:19 | <MikeSmith> | to compare error-reporting behavior |
| 18:19 | <MikeSmith> | messages |
| 18:20 | <Domenic> | MikeSmith: hmm yeah I am less sure on that, maybe Mozilla #jslang folks would know more... |
| 18:20 | <Domenic> | MikeSmith: I think filing an issue on https://github.com/estree/estree might also get the attention of the right people |
| 18:20 | <MikeSmith> | ok |
| 18:32 | <caitp> | MikeSmith: I think things like that are mostly covered by fuzz testers |
| 18:33 | <caitp> | test262 verifies some syntax errors, but I mean |
| 18:33 | <caitp> | the set of invalid inputs is vastly greater than the set of valid inputs |
| 18:33 | <caitp> | so it's hard to check them all in a test suite |
| 18:39 | <MikeSmith> | caitp: sure I understand that, but it's imaginable that a testsuite could be assembled around a useful subset of common errors |
| 18:41 | <MikeSmith> | actually, thinking about it, if an implementation uses some kind of message-properties file for its error messages, I could probably just construct a test suite from that, with at least one test for each type of message |
| 18:41 | <caitp> | could be |
| 18:41 | <MikeSmith> | I think I'll try that |
| 18:42 | <MikeSmith> | anyway, in general I find that the messages for syntax errors in Firefox devtools are more specific and helpful to authors than messages from most any other implementations are |
| 18:43 | <caitp> | usually things like this show up in an "unexpected token" path |
| 18:43 | <MikeSmith> | yeah |
| 18:43 | <MikeSmith> | which is not super helpful to a learner |
| 18:44 | <caitp> | yeah :( |
| 18:44 | <MikeSmith> | voila https://github.com/mozilla/rhino/blob/master/src/org/mozilla/javascript/resources/Messages.properties |
| 19:16 | <annevk> | jsbell: https://github.com/whatwg/encoding/pulls |
| 19:16 | <annevk> | jsbell: could you review them maybe? |
| 19:18 | <jsbell> | annevk: I can try. I was hoping someone more familiar with those encodings would. |
| 19:18 | <jsbell> | but I'll try and see if the description matches the change at least |
| 19:19 | <rits> | annevk: could you see this commit https://github.com/Ritsyy/html/commit/93f700f25224449aa38730a48b76814b5a0241cb |
| 19:23 | <annevk> | jsbell: yeah, I guess I need to be more patient |
| 19:24 | <annevk> | rits: when you refer to the algorithm, update should be lowercase |
| 19:24 | <annevk> | rits: and there's a space after algorithm that should be removed |
| 19:24 | <rits> | annevk: okay, thanks |
| 19:25 | <annevk> | rits: don't really have time right now to give it a thorough review though, weekend has started 😊 |
| 19:25 | <darobin> | slacker |
| 19:26 | <rits> | annevk: yes no problem, have a nice weekend :) |
| 19:28 | <annevk> | you too! |
| 19:28 | <annevk> | darobin: learned from the best |
| 19:28 | <darobin> | :) |