| 02:20 | <Domenic> | MikeSmith: so the problem with setting PYTHONPATH is that it then modifies the user's system forever. |
| 02:20 | <Domenic> | I'm trying to use sys.path.append in the python instead but no go... |
| 02:22 | <MikeSmith> | Domenic: hmm yeah I guess we may need to wait for TabAtkins’ fix then |
| 02:23 | <MikeSmith> | though well we could have the build script save the original PYTHONPATH value and then just restore it to that after |
| 02:28 | <Domenic> | Yeah... |
| 02:28 | <Domenic> | I tried just doing PYTHONPATH=... wattsi but it doesn't get passed down into the child python process |
| 02:29 | <Domenic> | Oh wait |
| 02:29 | <Domenic> | I seem to have forgotten how export works |
| 02:29 | <MikeSmith> | right yeah it must be exported for that tow roik |
| 02:29 | <Domenic> | It will only be for the duration of the script |
| 02:29 | <Domenic> | It only is global if you source the script |
| 02:29 | <MikeSmith> | ah yeah sure |
| 02:29 | <MikeSmith> | right |
| 02:31 | <Domenic> | Hmm but on this computer I can't get the PYTHONPATH fix to work either -_- |
| 02:35 | <MikeSmith> | I’ve also not gotten it working in my MacOS environment either |
| 02:36 | <MikeSmith> | I’m trying to figure out right now what specifically is failing and why |
| 02:41 | <TabAtkins> | Rather than messing around with paths, maybe just `pip install pygments` on the CI for now? |
| 02:44 | <Domenic> | TabAtkins: well it'd be nice if it worked for people building locally too |
| 03:08 | <MikeSmith> | Domenic: OK re-tested and exporting PYTHONPATH in build.sh is working as expected for me in my environment |
| 03:08 | <MikeSmith> | you want to PR it you want me to? |
| 03:20 | <Domenic> | MikeSmith: yeah that'd be great, and I'll test on my machine in an hour or two |
| 03:29 | <MikeSmith> | OK |
| 03:35 | <TimothyGu> | Domenic: are you not on a plane? |
| 03:35 | <Domenic> | TimothyGu: nope, tomorrow morning |
| 03:35 | <TimothyGu> | ah heh |
| 03:37 | <MikeSmith> | TimothyGu: so you’re working full-time at Google now? |
| 03:38 | <TimothyGu> | nope, just interning |
| 03:38 | <MikeSmith> | ah OK |
| 04:47 | <Domenic> | MikeSmith: sorry, did you figure out the pythonpath thing? I didn't see a PR, but looking back I guess I wasn't clear that I was suggesting you do it :) |
| 04:48 | <MikeSmith> | Domenic: I didn’t raise it yet |
| 04:48 | <MikeSmith> | but I will right now |
| 04:48 | <MikeSmith> | in further testing I found another problem that the pre->code change regressed |
| 04:48 | <MikeSmith> | all the included examples no longer actually get included |
| 04:49 | <MikeSmith> | because the regex in the perl script needs to be updated to account for that change |
| 04:49 | <Domenic> | Ah eek |
| 04:50 | <MikeSmith> | yeah see https://html.spec.whatwg.org/multipage/canvas.html#examples:the-canvas-element for instance |
| 04:50 | <MikeSmith> | anyway it should be easy to fix the perl script for that |
| 04:51 | <MikeSmith> | will do it after the build fix |
| 04:56 | <MikeSmith> | Domenic: oh but for the Docker files we don’t need/want to set the PYTHONPATH now? Because you updated those to pip install pygments? |
| 04:56 | <MikeSmith> | we want to keep it that way? |
| 04:57 | <MikeSmith> | I guess a downside of that would be, CI would be using a different Pygments than the local build |
| 04:59 | <MikeSmith> | so if/when TabAtkins makes changes/fixes to the highlighter Pygments copy, we could end up with the CI behavior being different, or even not having necessary fixes |
| 05:02 | <Domenic> | MikeSmith: no I didn't update those. I'm hoping that since docker uses build.sh any changes you make there will work also |
| 05:05 | <MikeSmith> | Domenic: so we want to keep the https://github.com/whatwg/html-build/commit/349edd8c21b3350e96b857ee75f24493089c2a7c change? |
| 05:05 | <MikeSmith> | = Install Python in Docker |
| 05:05 | <Domenic> | Ah yeah, that's necessary |
| 05:06 | <Domenic> | Basically revert the revert commit + whatever PYTHONPATH magic in build.sh fixes things |
| 05:14 | <Domenic> | hmm gotta get a couple hours sleep, back in a bit |
| 08:35 | <Domenic> | MikeSmith: seems to have worked. Some missing classes in the source code I guess, e.g. for https://html.spec.whatwg.org/multipage/workers.html#introduction-14 but the rest is working. I can try to PR later. |
| 08:35 | <MikeSmith> | Domenic: w00t |
| 08:35 | <MikeSmith> | thanks much |
| 08:36 | <MikeSmith> | dunno how we can audit those missing-classes cases |
| 08:36 | <Domenic> | No, thank you... A long journey, but pretty great results |
| 08:36 | <MikeSmith> | yeah, glad it actually ended up working, and performantly |
| 08:37 | <MikeSmith> | I’m (re)fixing the demos-examples include thing right now |
| 08:40 | <MikeSmith> | ...and ready https://github.com/whatwg/html-build/pull/173 |
| 08:41 | <Domenic> | Thanks, in a cab at the moment, but will test soon |
| 08:42 | <MikeSmith> | k |
| 08:42 | MikeSmith | heads off to cook dinner |
| 16:13 | <dtapuska> | should someone update the html-build readme? I wasn't aware my build was failing because of the new highlighter submodule so I had to go and init it and pull it to fix my build |
| 16:17 | <Domenic> | Ugggh that was supposed to be optional |
| 16:18 | <Domenic> | Like it would just detect the submodule absence and still work |
| 16:18 | <Domenic> | File an issue to make it so and we'll do that? |
| 16:18 | <Domenic> | After you inited it, things just worked though? That's good. |
| 16:19 | <dtapuska> | Ya the build fails horribly in the the highlighter isn't there |
| 16:19 | <Domenic> | I suppose we could make the script init for you, too. |
| 16:20 | <dtapuska> | ya essentially; cd highligher && git submodule init && git submodule update |
| 16:24 | <dtapuska> | Created https://github.com/whatwg/html-build/issues/174 |
| 16:49 | <MikeSmith> | my bad |
| 16:58 | <MikeSmith> | https://github.com/whatwg/html-build/pull/175 |
| 21:44 | <TimothyGu> | MikeSmith: dtapuska: is it normal? https://travis-ci.org/whatwg/html/builds/407814639 |
| 21:44 | MikeSmith | looks |
| 21:44 | <TimothyGu> | Tried restarting |
| 21:45 | <TimothyGu> | it was some kind of socket error |
| 21:45 | <MikeSmith> | OK, watching the log now |
| 21:47 | <TimothyGu> | yup there it is |
| 21:47 | <MikeSmith> | yup |
| 21:47 | <MikeSmith> | yeah that indicates it didn’t init the highlighter submodule |
| 21:47 | <MikeSmith> | you’re rebased against current master? |
| 21:47 | <MikeSmith> | on that branch |
| 21:49 | <TimothyGu> | hm let me try |
| 21:49 | <MikeSmith> | from https://github.com/whatwg/html/pull/3850 it seems you’re not rebased yet |
| 21:49 | <MikeSmith> | > TimothyGu added some commits 17 hours ago |
| 21:49 | <TimothyGu> | okay done |
| 21:49 | <TimothyGu> | lets see |
| 21:50 | MikeSmith | watches along again |
| 21:53 | <Domenic> | Rebasing whatwg/html shouldn't be necessary... |
| 21:53 | <Domenic> | This may be my fault: https://github.com/whatwg/html-build/commit/e1b191ce4d18f520795242c12359f6bed3182092 |
| 21:54 | <MikeSmith> | yeah it’s still failing |
| 21:54 | <Domenic> | Probably should revert that... and stop making untested changes. |
| 21:54 | <MikeSmith> | :) yeah seems it wasn’t redundant |
| 21:59 | <Domenic> | MikeSmith: TimothyGu: reverted. I'll work on actual CI for html-build now... |
| 21:59 | <TimothyGu> | restarted |
| 22:00 | <MikeSmith> | I should do confession and penance for every time I introduce a submodule depedency anywhere |
| 22:00 | MikeSmith | re-watches the CI build |
| 22:04 | <MikeSmith> | victory |
| 22:04 | <TimothyGu> | yay |
| 22:06 | <Domenic> | https://github.com/whatwg/html-build/pull/176 |
| 22:06 | <Domenic> | To put a stop to this madness |
| 22:07 | <TimothyGu> | Also, we probably want all the static resources like html-dfn.js on whatpr.org, no? |
| 22:08 | <Domenic> | Yeah whatpr.org needs to do the full html-build instead of just wattsi |
| 22:08 | <Domenic> | https://github.com/whatwg/html-build/issues/156 |
| 22:09 | MikeSmith | looks |
| 22:09 | <TimothyGu> | ah |
| 22:09 | <Domenic> | Basically I have an old issue to convert wattsi-server into html-build-server |
| 22:10 | <TimothyGu> | Domenic: get an intern to do it for you ;) |
| 22:12 | <TimothyGu> | Also https://whatpr.org/html/3850/webappapis.html#event-handler-attributes could use some heavy editorial review. The whole expose vs. specify distinction is quite irritating and I tried to make it clearer by "redirect" but it doesn't help much it seems |
| 22:15 | <Domenic> | Oh this looks fun |
| 22:20 | <Domenic> | TimothyGu: it seems like you need a concept to encapsulate "Let eventTarget be the EventTarget object for which the corresponding event handler is specified. If such an object does not exist, then return." |
| 22:21 | <TimothyGu> | Yeah precisely |
| 22:21 | <TimothyGu> | I want to be able to link "specified" |
| 22:21 | <Domenic> | Trying to figure out what the inputs are... output is an EventTarget I guess |
| 22:22 | <TimothyGu> | inputs are an EventTarget and a string (the name of the event handler) |
| 22:22 | <TimothyGu> | output is usually the input EventTarget, but not for body element |
| 22:22 | <TimothyGu> | and some event handlers |
| 22:22 | <Domenic> | OK. Then yeah, define something like "event handler target", and an algorithm (?) for deriving that from the input EventTarget and string? |
| 22:23 | <Domenic> | That algorithm may involve looking at some of the spec tables? |
| 22:23 | <TimothyGu> | hmm |
| 22:23 | <TimothyGu> | target |
| 22:24 | <Domenic> | Gosh this is a big rewrite |
| 22:24 | <TimothyGu> | Yes |
| 22:25 | <TimothyGu> | Specifically here's the part the "target" concept/algorithm should capture |
| 22:25 | <TimothyGu> | The body element exposes as event handler content attributes a number of the event handlers of the Window object. It also mirrors their event handler IDL attributes. |
| 22:25 | <TimothyGu> | The onblur, onerror, onfocus, onload, onresize, and onscroll event handlers of the Window object, exposed on the body element, replace the generic event handlers with the same names normally supported by HTML elements. |
| 22:26 | <TimothyGu> | The biggest thing was probably the switch to attribute change steps, as well as the new activate + deactivate algorithms |
| 22:27 | <Domenic> | Yeah agreed trying to figure out the counterpart to activate/deactivate in the old text |
| 22:27 | <TimothyGu> | deactivate didn't really exist |
| 22:28 | <TimothyGu> | That's what https://github.com/whatwg/html/issues/3836 is for |
| 22:28 | <TimothyGu> | Activate used to be "When an event handler H of an EventTarget object T is first set to a non-null value" |
| 22:28 | <Domenic> | TimothyGu: seems like onafterprint and the rest of the table following those you list also have a similar thing |
| 22:29 | <TimothyGu> | ah yeah I guess all of WindowEventHandlers |
| 22:30 | <Domenic> | So I think an algorithm, probably where one of the steps is "appears in table X's first column or table Y's first column" would be good. It would make it explicit that this body/window thing is an exception. |
| 22:32 | <Domenic> | Hmm the algorithm doesn't help clarify this situation much though: "When an EventTarget object that has one or more event handlers specified is created, its event handler map must be initialized such that it contains an entry for each event handler specified on that object." |
| 22:33 | <TimothyGu> | btw the .XXX box is wrong. it's not true for content attributes that contain invalid JS. it's a reminder for me to fix it |
| 22:34 | <Domenic> | I wonder if we could separate out all the event handler content attribute stuff |
| 22:34 | <Domenic> | OK time to pay attention to TC39 |
| 23:56 | <sangwhan> | Curious question which popped up during the TAG F2F, has there been any plans/work on a image decoder/encoder API? |