[00:16:32] why not name it "project scope"? [03:29:00] I've gone another step down the path. Z35672 : https://tools-static.wmflabs.org/bridgebot/4365fc8d/file_80621.jpg [04:00:11] @Dnshitobu I'm just listening to the Volunteer's Corner, and I heard your question about copying the structure of Australia to Ghana. There are two things I think would help: Firstly, "Copy fragment to clipboard" when editing Australia, then paste in Ghana. Secondly, I got most of the structure from the headings and subpages listed on the English Wikipedia article on [04:00:11] Australia, w [04:00:13] hich you might want to do for Ghana too. [06:29:13] @vrandecic also on the VC recording, regarding your answer about future performance improvements. It seems to me that the calls from AW are rarely hitting caches. The only time I'm sure that I *do* see good cache behaviour is when I switch the rendering language of an AW article back to one that I have previously loaded - that is almost instantaneous. But other [06:29:13] scenarios should d [06:29:14] o better: even if you just reload the same page in your browser, it seems to recalculate everything, even though the calls are identical. Admittedly this is downstream of everything that @dvd_ccc27919 is hoping for, but the rendering speed of AW itself probably matters a lot to users who plan to spend most of their efforts constructing articles instead of functions. [06:40:07] I was actually hoping to allow Abstract Wikipedia articles to have a shared context (re @u99of9: @vrandecic also on the VC recording, regarding your answer about future performance improvements. It seems to me that the calls ...) [06:42:34] Understood. I'm just picking up one of the threads Denny mentioned at the start of his answer. I'm not really addressing your hope, which is a good desire, but is more complex than I can foresee answers to. (re @dvd_ccc27919: I was actually hoping to allow Abstract Wikipedia articles to have a shared context) [07:42:27] *T422613* is progressing. (re @u99of9: @vrandecic also on the VC recording, regarding your answer about future performance improvements. It seems to me that the calls ...) [07:45:52] Great, I've now subscribed. But I don't think the current bit is working as expected: "the existing fragment-level memcached caching in AbstractWikiRequest / CacheAbstractContentFragmentJob, which will continue to serve its original purpose of absorbing repeat fragment calls close to the orchestrator." Why would reloading the page take so long to rerender? (re @Al: [07:45:53] T422613 is progressing.) [07:57:35] I can’t say for sure. It looks like the fragment calls are queued without regard to whether memcached results exist. This is reasonable given the future expectation that stored results will exist in the durable layer, but it does mean that the end user repeatedly experiences the queuing time even when every call result is eventually returned from memcached. (re @u99of9: [07:57:35] Great, [07:57:37] I've now subscribed. But I don't think the current bit is working as expected: "the existing fragment-level memcached cac...) [07:59:16] Do we have a way of testing if the call results did come from memcache? (re @Al: I can’t say for sure. It looks like the fragment calls are queued without regard to whether memcached results exist. This is rea...) [08:01:01] If so, reloading a complex sentence would take a similar time to a sentence spacer! (re @u99of9: Do we have a way of testing if the call results did come from memcache?) [08:03:27] I don’t think so, not directly. (re @u99of9: Do we have a way of testing if the call results did come from memcache?) [08:04:10] That is what I would expect. (re @u99of9: If so, reloading a complex sentence would take a similar time to a sentence spacer!) [08:04:24] I'll try some more indirect experiments, because I've got a hunch. (re @Al: I don’t think so, not directly.) [08:05:53] Any thoughts on this Al GrounderUK ? (re @u99of9: It looks like YoshiRulz did this at https://www.wikifunctions.org/w/index.php?title=Z13464&diff=275373&oldid=275372 but now Z134...) [08:07:18] Yeah, v2 broke it. (re @u99of9: Any thoughts on this Al GrounderUK ?) [08:07:19] I think it's an invisible problem like we sometimes get when we change the keys of a Type. (re @u99of9: Any thoughts on this Al GrounderUK ?) [08:08:31] Was it this broken before YoshiRulz made the signature edit that we discussed? (re @Al: Yeah, v2 broke it.) [08:09:01] Yes. (re @u99of9: Was it this broken before YoshiRulz made the signature edit that we discussed?) [08:12:13] Actually, maybe it was only Z13466 that v2 broke. There might be two separate issues here. (re @u99of9: Was it this broken before YoshiRulz made the signature edit that we discussed?) [08:29:45] As far as I knew all of the V2 issues were resolved. Are you aware of other things still down? (re @Al: Actually, maybe it was only Z13466 that v2 broke. There might be two separate issues here.) [08:50:01] Good question. There’s *T423853*, but I don’t think there are any others that I neglected to raise. (re @u99of9: As far as I knew all of the V2 issues were resolved. Are you aware of other things still down?) [11:58:57] Looking at Z33748, there might even be three. (re @Al: Actually, maybe it was only Z13466 that v2 broke. There might be two separate issues here.) [22:17:28] Thanks for filing T427454 (re @Al: Looking at Z33748, there might even be three.) [22:18:57] Sorry I forgot about it previously. (re @u99of9: Thanks for filing T427454) [22:21:41] All good. It has popped up a few times when I tried to do natural language work. So I think resolving it will unlock progress. [22:43:08] I think it would work with a helper function implemented in code, but a helperless implementation (Z35755) is misbehaving. (re @u99of9: All good. It has popped up a few times when I tried to do natural language work. So I think resolving it will unlock progress.)