[13:58:04] [telegram] @josephseddon @amire80 here perhaps? :P [13:58:07] [telegram] Yeah! Here works [13:59:03] [telegram] Works for me, too. [14:00:35] [telegram] So basically graphoid is being undeployed in the short term. In the long term we are looking at building a new server side rendering component [14:01:50] [telegram] That means for the short term, graphs will be rendered on the front end [14:02:31] [telegram] Why not just bump up ram/processor or whatever the problem is server side? :P [14:03:06] [telegram] I was looking through some RfC and it felt weird. Kinda like noone got how the thing actually works so they decided to go this way [14:04:54] [telegram] @Thecladis the short version of the story as I was lead to understand is that the server Graphoid sits on needs to be deprecated. The version of vega we use isn't compatible with Kubernetes. [14:05:46] [telegram] It is not possible to run it in docker or what? 🤔 [14:07:39] [telegram] Basically this is a some very deep behind the hood issue, it seems illogical to solve this this way :p [14:08:22] [telegram] As if Telegram wanted to use another DBMS so they would ask me to store the GBs of my message history on my phone in the meanwhile [14:09:08] [telegram] Basically this is a some very deep under the hood issue, it seems illogical to solve this this way :p [14:09:20] [telegram] What is the performance impact on pages with graphs? [14:09:44] [telegram] What is the performance impact of front-end rendering on pages with graphs? [14:12:31] [telegram] @chicocvenancio depends on the graphs. The biggest performance issue will be graphs that rely on api calls such as to the WDQS. But WDQS graphs have been broken for the past 6+ months as well [14:17:15] [telegram] so, here you are! 😃 thanks for the invitation, @chicocvenancio (re @amire80: Works for me, too.) [14:17:26] [telegram] The earliest version of vega aren't backwards compatible with the latest versions. [14:18:01] [telegram] Now we could patch that but there is huge unease at using incredibly outdated renderers [14:18:18] [telegram] But but but step back a bit. Is there a backstory? [14:18:52] [telegram] A wiki page about the technology and the history of its development and deployment would be very useful. [14:19:15] [telegram] https://www.mediawiki.org/wiki/Extension:Graph [14:20:02] [telegram] It was presented on wikimania2015 at the very least, I think before that too [14:21:25] [telegram] https://www.youtube.com/watch?v=j7DTn9jHnI0 [14:21:46] [telegram] https://www.youtube.com/watch?v=j7DTn9jHnI0 [14:22:22] [telegram] Thanks, and a page about the undeployment and the switching to client-side? If it's on the same page, just tell me :) (re @josephseddon: https://www.mediawiki.org/wiki/Extension:Graph) [14:22:41] [telegram] @amire80 there is a phabtask [14:22:44] [telegram] (that page is longish and I didn't immediately see it) [14:22:50] [telegram] https://phabricator.wikimedia.org/T242855 [14:23:40] [telegram] Thank you! [14:28:26] [telegram] @amire80 difficulties with ownership detailed here: https://phabricator.wikimedia.org/T211881 [14:29:05] [telegram] Sigh. Wikimedia (is a wide sense) has always had a code ownership problem. [14:29:32] [telegram] @amire80 https://phabricator.wikimedia.org/T249419 [14:30:02] [telegram] Maybe because it's thought of as "code ownership" rather than "feature ownership", [14:30:53] [telegram] and I suspect there is no good definition anywhere what features are important for the editors community to have and to be maintained. [14:38:39] [telegram] there's not any plan or strategy on that? (re @amire80: and I suspect there is no good definition anywhere what features are important for the editors community to have and to be maintained.) [14:40:16] [telegram] I knew there was something wrng with WDQS graphs for long 😔 but I like graph a lot, and really hope it can be optimized with server side processing. But even now it is nice [14:40:25] [telegram] I knew there was something wrng with WDQS graphs for long 😔 but I like graph a lot, and really hope it can be optimized with server side processing. But even now it is very nice [16:37:52] [telegram] Hi all, I've been working on a project to create a local database of edits for research and I've been making plots from my DB. Does anyone know what happened from 14th-17th of September 2012?Raw countsDate Edit Count2012-09-12 126492012-09-13 345972012-09-14 936312012-09-15 1066652012-09-16 862432012-09-17 1138902012-09-18 18983 : https://tools-static.wmflabs.org/bridgebot/3ff470f4/file_206.jpg [16:48:40] [telegram] it could be mass creation of talk pages with a bot [16:52:36] [telegram] placing project marks, or placing or fixing some other maintenance talk page template [16:55:14] [telegram] I feel like there would be some wiki kerfuffle about such a large amounts of edits, at minimum a discussion. However I'm not sure where people were discussing in 2012 [16:55:37] [telegram] I could certainely try sample some edits from this time and see if there is a pattern [17:48:47] [telegram] We have hundreds of wiki’s. Which one are you looking at? [18:55:37] [telegram] enwiki namespace 1 [19:00:45] A bot, seemingly [19:02:28] Or two [19:02:29] | BG19bot | 44379 | [19:02:29] | Yobot | 347754 | [19:02:35] [telegram] actually I can query to see if that's the case :) [19:02:43] >select rev_user_text, count(rev_user_text) as cnt from revision inner join page on (page_id=rev_page) where rev_timestamp BETWEEN '20120914000000' AND '20120918000000' AND page_namespace=1 GROUP BY(rev_user_text) ORDER BY cnt; [19:02:59] ~431K [19:03:06] Basically, wikiproject tagging [19:06:36] [telegram] nice to validate my db :) I was worried I double parsed a lot of dumps [19:07:58] The fact there's also [19:07:59] | Magioladitis | 5354 | [19:08:09] I'm guessing Magioladitis was on a bot run that went wrong :) [19:14:06] [telegram] this is the graph for users I've got as bots (from https://petscan.wmflabs.org/?psid=15925943) : https://tools-static.wmflabs.org/bridgebot/2b8964b2/file_207.jpg [19:14:16] [telegram] so that explains it :) [19:32:45] [telegram] last thing I'll say on this Yobot performed 329486 edits in those four days :) [19:34:20] [telegram] last thing I'll say on this Yobot performed 329486 edits in those four days, Magioladitis indeed :) [19:44:53] [telegram] last thing I'll say on this Yobot performed 329486 edits in those four days, Magioladitis indeed :) (he was adding {{WikiProject Biography}} templates) [19:45:06] [telegram] last thing I'll say on this Yobot performed 329486 edits in those four days, Magioladitis indeed :) [19:45:07] [telegram] (they were adding {{WikiProject Biography}} templates) [19:59:32] Curious. My messages starting with | don't make it to telegram? [19:59:36] | test [19:59:41] | test [20:00:00] [20:02:29] | BG19bot | 44379 | [20:00:00] [20:02:29] | Yobot | 347754 | [20:00:05] [20:07:59] | Magioladitis | 5354 | [20:00:21] Even then.. [20:00:30] [21:00:00] [20:02:29] | Yobot | 347754 | [20:37:56] [telegram] I see it (re @wmtelegram_bot: [irc] | test) [20:38:38] Yes [20:38:40] But [20:39:20] [telegram] [20:59:36] | test [20:39:21] [telegram] [20:59:41] | test [20:39:22] [telegram] I did two. only one appeared here [20:42:01] [telegram] Oh, interesting [20:42:16] [telegram] The one prepended with space? [20:42:28] I think so, yeah [21:03:18] [telegram] I can change order of menus at MediaWiki:Sidebar. Is it possible to change the main content and insert something below the title? [21:09:45] [telegram] in this area? : https://tools-static.wmflabs.org/bridgebot/b340f824/file_209.jpg [21:09:52] [telegram] with some js — yes [21:29:57] [telegram] yes, that part [21:30:15] [telegram] ok... not an easy thing then [21:32:12] [telegram] Galder for the entire wiki? [[MediaWiki:Tagline]] [21:32:47] [telegram] Oh, true! [21:33:45] [telegram] For some reason uselang=qqx did not show it to me in a wiki with no tagline already added [21:34:35] [telegram] thanks! [21:35:34] [telegram] I don't know how to toggle it on/off. On mediawiki.org the message exists, but isn't shown (it's not in the generated HTML, so it's not hidden with CSS). So the mere existence of the message isn't all that's needed I think [21:35:51] [telegram] but on [[w:no:]] it is present [21:36:17] [telegram] (well, except for the main page that that link links to though) [21:37:34] [telegram] err, strike that, i was looking in the wrong place [21:37:59] [telegram] on MediaWiki.org it is indeed just hidden with CSS, in [[MediaWiki:Gadget-site.css]] (#siteSub) [21:38:11] [telegram] at euwiki we have it hidden with css [21:38:21] [telegram] but I was thinking on how it would feel inserting there wikibase-otherprojects [21:38:30] [telegram] it doesn't work so easy, so ... [21:38:31] [telegram] https://www.mediawiki.org/wiki/Manual:Tagline_(Site_Subtitle) yeah it seems that is the default state [21:38:42] [telegram] you have to unhide it (re @Thecladis: https://www.mediawiki.org/wiki/Manual:Tagline_(Site_Subtitle) yeah it seems that is the default state) [21:40:58] [telegram] Ah, yeah. Can easily be done with jQuery though (re @Galder: but I was thinking on how it would feel inserting there wikibase-otherprojects) [21:41:10] [telegram] How can I get a list of users that have between 75 and 85 edits, and their latest edit timestamp? In production I can run this, it runs quickly, and I think it gets a sensible result, with 757 rows in hewiki: [21:41:11] [telegram] select [21:41:12] [telegram] max(rev_timestamp) as 'latest edit time', [21:41:14] [telegram] user_editcount, [21:41:15] [telegram] user_name [21:41:16] [telegram] from [21:41:18] [telegram] user, [21:41:19] [telegram] revision [21:41:20] [telegram] where [21:41:21] [telegram] user_id = rev_user and [21:41:23] [telegram] user_editcount between 75 and 85 [21:41:24] [telegram] group by [21:41:25] [telegram] user_id [21:41:27] [telegram] order by [21:41:28] [telegram] max(rev_timestamp); [21:41:29] [telegram] (But do correct me it if it's wrong.) [21:41:31] [telegram] However, if I try to run the same on Quarry, I get Unknown column 'rev_user' in 'where clause'. It's probably related to the "actor migration", but I cannot figure our how to fix it. Any help?.. [21:41:32] [telegram] yes, actor migration [21:41:49] [telegram] join actor table [21:42:06] [telegram] https://www.mediawiki.org/wiki/Manual:Actor_table it is pretty straightforward [21:47:33] [telegram] Yeah, but if I try to rewrite it with rev_actor, it just runs and doesn't stop. Here's what I tried: [21:47:33] [telegram] use hewiki_p; [21:47:35] [telegram] select [21:47:36] [telegram] user_id, [21:47:37] [telegram] max(rev_timestamp) as 'latest edit time', [21:47:38] [telegram] user_editcount, [21:47:40] [telegram] actor_name [21:47:41] [telegram] from [21:47:42] [telegram] user, [21:47:44] [telegram] actor, [21:47:45] [telegram] revision [21:47:46] [telegram] where [21:47:48] [telegram] rev_actor = actor_id and [21:47:49] [telegram] actor_user = user_id [21:47:50] [telegram] group by [21:47:51] [telegram] user_id having user_editcount between 75 and 85 [21:47:53] [telegram] order by [21:47:54] [telegram] max(rev_timestamp); [21:47:55] [telegram] It's quite possible that it has silly mistakes. [21:49:23] [telegram] hm, why do you even use revison? [21:49:24] [telegram] To know the latest edit. [21:49:25] [telegram] you can just do this all with user table [21:49:55] [telegram] ah [21:49:59] [telegram] I have almost 0 experience with MySQL, so this might be worthless, but … [21:50:00] [telegram] group by [21:50:01] [telegram] user_id having user_editcount between 75 and 85 [21:50:03] [telegram] isn't this a bit weird? [21:50:05] [telegram] yes [21:50:14] [telegram] the condition should go to where clause [21:50:15] [telegram] I have almost 0 experience with SQL, so this might be worthless, but … [21:50:16] [telegram] group by [21:50:17] [telegram] user_id having user_editcount between 75 and 85 [21:50:18] [telegram] isn't this a bit weird? [21:51:13] [telegram] having makes sense when you are working with some stuff calculated in select clause, usually with aggregation functions, not for normal conditions [21:51:50] [telegram] It also gets stuck with the condition in where. [21:54:44] [telegram] https://quarry.wmflabs.org/query/45996 my version seems to work [21:54:54] [telegram] is this what you wanted? [21:56:21] [telegram] I am not very familiar with the syntax of performing joins by listing several tables in from condition, so I am not sure what is going on with your query. probably EXPLAIN can help to learn that [21:57:18] [telegram] (and at least before the actor migration it was advisable to use revision_userindex instead of revision on labs, not sure if this still applies, possibly yes) [22:22:47] [telegram] it seems not, your query has now finished executing and shows better results (re @Thecladis: is this what you wanted?) [22:25:31] [telegram] oh a silly mistake in join condition [22:26:05] [telegram] interesting, with the correct condition it also seems to now run slow [22:40:38] [telegram] now it seems to work faster with a subquery used instead, but I have failed to have it sorted properly https://quarry.wmflabs.org/query/45999