| 05:57 | <MikeSmith> | annevk: Domenic so for HTML checking of WHATWG specs with Travis I’d like to use a common script, and put it under version control somewhere in github/whatwg |
| 05:59 | <MikeSmith> | I guess one way would be a create a new “tools” or “common-tools” (or whatever) repo, and put it in there |
| 06:00 | <MikeSmith> | but that seems like overkill unless we anticipate we might need to add other common tools later |
| 06:03 | <MikeSmith> | so alternative is, I could just drop it in whatwg/infra |
| 06:05 | <MikeSmith> | which yeah, it’s a spec repo of its ownーnot a repo for common build infrastructureーbut seems like there’s nothing wrong with giving it the additional purpose of storing common build infrastructure/tooling |
| 06:07 | <MikeSmith> | to be clear, wherever we put it, the idea would be that I just update the various spec .travis.yml files to do “curl https://github.com/whatwg/infra/blob/master/html-check.sh && bash html-check.sh” |
| 06:09 | <MikeSmith> | so rather than repeating in N different repo .travis.yml files the same set of commands to call the HTML checker over the network API, I just move the commands into that script |
| 06:10 | <MikeSmith> | so then of course if we end up needing to make any changes/refinements to how the HTML checker gets called, we need to make the updates in only one places instead of in N different places |
| 06:11 | <MikeSmith> | * “curl -O https://github.com/whatwg/infra/blob/master/html-check.sh && bash html-check.sh” |
| 06:21 | <annevk> | MikeSmith: resources.whatwg.org has tools/ |
| 06:21 | <annevk> | MikeSmith: already used for a shared build script |
| 06:24 | <MikeSmith> | oh |
| 06:24 | <MikeSmith> | wonder how I forgot that |
| 06:25 | <MikeSmith> | ah |
| 06:25 | <MikeSmith> | annevk: no github repo backing that, right? |
| 06:26 | <annevk> | dmarr: it should get set dynamically by default |
| 06:26 | <MikeSmith> | ah |
| 06:26 | <annevk> | MikeSmith: there is whatwg/resources.whatwg.org |
| 06:26 | <MikeSmith> | found it nm |
| 06:26 | <MikeSmith> | yeah |
| 06:26 | <annevk> | Zoo time, ttyl |
| 06:28 | <MikeSmith> | annevk: enjoy |
| 12:49 | <annevk> | JakeA: if you want to make transfering signals work you need some kind of private MessageChannel |
| 12:49 | <JakeA> | annevk: I believe Domenic is doing the same for transferring streams |
| 12:50 | <annevk> | JakeA: or you need to keep a link back to the controller and fiddle with things there I suppose, but that seems weirder |
| 12:50 | <JakeA> | annevk: although, personally, I'd rather we explained message ports on top of streams :D |
| 12:50 | <annevk> | JakeA: yeah, streams and promises would need the same kind of feature |
| 12:50 | <annevk> | JakeA: I don't see how streams have any ability to cross threads |
| 12:51 | <JakeA> | annevk: data must already get from the network to the main thread somehow |
| 12:52 | <annevk> | JakeA: sure, we queue tasks with the data |
| 12:53 | <JakeA> | annevk: isn't that how message ports work? |
| 12:54 | <JakeA> | I think it's just because I find message ports more confusing than streams, so I'm leaning to the thing I understand most. Ignore me. |
| 12:55 | <annevk> | JakeA: yup, tasks can cross threads |
| 15:37 | <annevk> | JakeA: btw, the reason we cannot do "cancellation" is because of Event.prototype.cancelable |
| 15:39 | <annevk> | JakeA: mkwst: other terms we could consider "halt" / "stop" |
| 15:55 | <JakeA> | annevk: yeah, understand the legacy. I can put up with .cancel, but why not .abort? |
| 15:58 | <annevk> | JakeA: naming them all after abort is fine with me |
| 16:00 | <annevk> | JakeA: so with this new system we don't even have a revealing constructor for the object with abort() anymore |
| 16:00 | <annevk> | JakeA: you just pass in a signal object |
| 16:00 | <annevk> | JakeA: I guess that's fine |
| 16:01 | <annevk> | JakeA: oh, I forgot to mention in the Fetch PR, we'll need an example |
| 16:05 | <JakeA> | annevk: yeah, I wanted to start with the bits I was unsure of so I could get feedback. I can easily example the hell out of it later |
| 16:05 | <JakeA> | Also why are we all working on a Sunday? |
| 17:07 | <annevk> | Well, I worked less during the week since the kid couldn't go to daycare fulltime, but I also enjoy this topic 😊 |
| 17:08 | <annevk> | tobie: as a heads up, used Hangouts on you |
| 17:30 | <JakeA> | annevk: I don't think we need a revealing constructor, especially as one signal can feed many fetches |
| 17:31 | <JakeA> | annevk: the observer would be in a revealing constructor though |
| 17:31 | <annevk> | So controller/signal/observer |
| 18:08 | <MikeSmith> | annevk: for the HTML checker I was working today on adding a mechanism to allow filtering out particular errors/warnings based on regex match |
| 18:09 | <MikeSmith> | motivated by trying to deal with the “Text run is not in Unicode Normalization Form C” noise for the Encoding spec output files |
| 18:10 | <MikeSmith> | I think I actually have it working now locally |
| 18:11 | <MikeSmith> | and can push it to the checker tomorrow for testing |
| 18:11 | <annevk> | Cool |
| 18:12 | <MikeSmith> | so for deploy.sh we might want to provide a way to set ignore patterns per-spec |
| 18:13 | <MikeSmith> | is there some way now alreay for deploy.sh to set per-spec environment variables? |
| 18:15 | <MikeSmith> | I guess not yet, from looking at the sources |
| 18:18 | <MikeSmith> | ah but I see it can just pick up environment variables from .travis.yml |
| 18:18 | <MikeSmith> | OK so yeah I think I can make this work |
| 18:18 | <MikeSmith> | tomorrow |
| 18:36 | <dmarr> | annevk: it does seem to when i make a normal request in the console, but for some reason when calling from a bundled file, its not. maybe something with babel or webpack that is using a polyfilled fetch? im at a loss |
| 19:07 | <annevk> | dmarr: I have no experience with those |
| 19:07 | <annevk> | MikeSmith: yeah, we use that file for config; sounds nice! |