[07:52:31] <joakino>	 morning
[08:20:36] <phuedx>	 o/ joakino
[08:21:53] <joakino>	 \o
[08:22:43] <phuedx>	 so many emailzzz
[09:33:40] <thedj>	 https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Article_talk_page_editing_in_mobile_view_in_partially_broken
[09:45:59] <jdlrobson>	 hey phuedx 
[09:46:02] <jdlrobson>	 hey joakino 
[09:46:18] <jdlrobson>	 UK hours today :)
[09:47:33] <joakino>	 hi jdlrobson 
[09:47:54] <jdlrobson>	 require / modules.export got merged!
[09:48:01] <phuedx>	 o/
[09:48:19] <joakino>	 jdlrobson: are there any docs
[09:48:23] <joakino>	 i couldnt find any
[09:48:28] <jdlrobson>	 heh nope
[09:48:33] <jdlrobson>	 what do you need help with i can write them
[09:48:44] <jdlrobson>	 https://gerrit.wikimedia.org/r/#/c/260167/ < but in mean time this explains the benefits
[09:48:46] <joakino>	 jdlrobson: can you join tracy and show me how it works?
[09:48:48] <jdlrobson>	 sure
[11:50:02] <jdlrobson>	 joakino: with regards to the current mw.loaded.require implementation - if the ResourceLoader module is a folder of files with the same name surely then it is compatible with nodes require?
[11:51:04] <joakino>	 jdlrobson: example?
[11:51:27] <jdlrobson>	 so if I have a folder resources/mobile.overlay
[11:51:54] <jdlrobson>	 and that has multiple files inside the folder e.g. ContentOverlay.js Overlay.js
[11:52:44] <jdlrobson>	 If I define a module in package.json e.g. { "name" : "mobile.overlays", "main" : "resources/mobile.overlays/index.js" }
[11:53:05] <jdlrobson>	 then wouldn't require( 'mobile.overlays' ) in node do the same as it would in ResourceLoader ?
[11:54:36] <joakino>	 jdlrobson: in that case yes, if resources/ was node_modules/ or resources/ was added to NODE_PATH, no need to have package.json with main either
[11:55:23] <jdlrobson>	 so that seems fully within our control no?
[11:55:33] <joakino>	 jdlrobson: if you name your resourceloader modules like a folder path or file path then yes, they could be made compatible with node
[11:55:41] <joakino>	 *node's require
[11:56:02] <joakino>	 jdlrobson: yeah, a convention
[11:56:34] <jdlrobson>	 and in theory, in future you could make mw.loader.require able to load files if we really wanted to by treating ./ differently - although not sure of the practicalities or use cases just yet
[11:56:49] <jdlrobson>	 in theory we could stop ResourceLoader modules from being able to start with './'
[11:56:58] <jdlrobson>	 *names of ResourceLoader modules
[11:57:13] <joakino>	 why would you?
[11:57:48] <joakino>	 the thing is I've seen comments about resource loader modules not being a parallel with node modules (which are files), see https://gerrit.wikimedia.org/r/#/c/281908/ for example in the comments of the review
[11:58:12] <joakino>	 this needs more thought i think
[11:58:55] <joakino>	 given those comments, I'm not sure if autogenerating ResourceModules entries is really a good idea
[11:59:06] <jdlrobson>	 Yeh I need to read that patch from adrian
[11:59:08] <joakino>	 jbut it sure as hell is painful to manage
[12:00:20] <joakino>	 allrights gonna go walk the dog
[12:00:20] <joakino>	 i'll come back later
[16:34:31] <phuedx>	 y'know
[16:34:39] <phuedx>	 i really thought we were going to clear the board this week
[16:40:19] <joakino>	 phuedx: you've always been a dreamer
[16:42:43] <phuedx>	 a cautious optometrist
[16:45:20] <phuedx>	 hanging out in tracy
[16:45:25] <phuedx>	 (as always)
[16:46:21] <phuedx>	 65daysofstatic's "wild light", released in 2013, is easily my album of 2016
[16:50:31] <phuedx>	 mdholloway: ^^ (maybe)
[16:51:02] <mdholloway>	 phuedx: ooh, i'll check it out!
[16:52:19] <phuedx>	 maxbinder: you went there!
[16:52:36] <maxbinder>	 phuedx: merg?
[16:52:46] <phuedx>	 your bold suggestion
[16:53:01] <maxbinder>	 it was so bolded! :)
[16:53:32] <maxbinder>	 phuedx: (increasingly I'm hearing shock and awe from you and wonder if I should scale back my invasion)
[16:53:52] <phuedx>	 nope
[16:53:59] <phuedx>	 don't
[16:54:04] <phuedx>	 i'm in favour of the strategy
[17:00:59] <phuedx>	 joakino: standerp
[17:01:30] <maxbinder>	 nzr are you joining for web standup today? Unclear
[17:03:48] <nzr>	 maxbinder: have the iOS est
[17:03:51] <nzr>	 maxbinder: :(
[17:04:06] <maxbinder>	 nzr: word, figured. Any idea when you'll start phasing out?
[17:04:26] <nzr>	 maxbinder: lets talk about it
[17:04:35] <nzr>	 i have been having a lot of conflicts 
[17:04:49] <maxbinder>	 nzr: ok
[17:14:11] <phuedx>	 out for 20 minutes
[17:24:05] <jdlrobson>	 cya guys im off for the day
[17:24:19] <jdlrobson>	 phuedx: i will be around in morning to wrap up lazy load references 10am-midday if that works for you
[17:33:54] <matanya>	 bearND: hi there
[17:34:07] <bearND>	 matanya: hello
[17:34:38] <matanya>	 first of all - awesome work on the mcs work with the app
[17:34:51] <matanya>	 i really really like the definition feature
[17:35:05] <matanya>	 bearND:  can it be brought to more languages ?
[17:36:11] <bearND>	 matanya: it can but it'll require some effort since there doesn't seem to be a consistent structure of the content in the various wiktionary sites.
[17:36:36] <bearND>	 I'm going to cc mdholloway since he's the main guy who has worked on that
[17:36:56] <matanya>	 can voluenteers help with it ?
[17:37:26] <bearND>	 matanya: i think so
[17:38:51] <mdholloway>	 matanya: hi there!  yes, bearND is correct about why it's difficult to expand to other languages.  volunteer help welcome!
[17:39:25] <matanya>	 hi mdholloway, can you describe the work needed ?
[17:39:51] <matanya>	 and also: can mobile web/desktop use those goodies too ?
[17:40:46] <dbrant>	 matanya: there's virtually no consistency in the content presentation across the different language Wiktionariae. That's why we focused only on English, and when we see encouraging engagement numbers, we can decide to pursue further work on integrating with other languages.
[17:40:51] <dbrant>	 matanya: The way that volunteers can help is by encouraging editors to follow a common template across the different languages.
[17:41:15] <matanya>	 what is that template ?
[17:41:27] <mdholloway>	 matanya: i don't think there is one :(
[17:41:48] <dbrant>	 matanya: we'd have to decide on it :)  but the English version seems fine enough
[17:42:40] <matanya>	 I See, this is all great, and any help i can provide or make others help will be given, just let me know :)
[17:42:51] <mdholloway>	 matanya: to go to your second question, anyone who wants can use the definition endpoint, although i'm not aware the web team has any plans to use it right now
[17:43:26] <matanya>	 ok, good to know
[17:43:46] <mdholloway>	 matanya: thanks, and i'm glad you're enjoying the feature!
[17:45:05] <phuedx>	 jdlrobson: sure
[17:46:16] <matanya>	 :)
[17:52:12] <niedzielski>	 dbrant: o/ i had a question on ReadingListImageFetcher and the page image database. Maybe we talked about this before but I can't remember what was concluded? I don't really understand why we even need the page image database since our networking layer provides caching. Subsequently, I don't understand why ReadingListImageFetcher is needed over jus
[17:52:13] <niedzielski>	 t plugging the URLs into Fresco's equivalent of a NetworkImageView
[17:53:06] <niedzielski>	 dbrant: any reason not to zap this class and just use the thumbnail URLs from the Reading List page table directly?
[17:53:27] <dbrant>	 niedzielski: i was about to ask if you're up for a quick batcave?
[17:53:41] <niedzielski>	 dbrant: sure, omw
[18:01:39] <joakino>	 heading out
[18:01:47] <joakino>	 have a nice day
[18:04:32] <bmansuro_>	 later
[18:05:36] <mdholloway>	 niedzielski: how do I get the DiskStatus of a ReadingListPageDiskRow?
[18:05:59] <mdholloway>	 niedzielski: ReadingListPageDiskRow.dat() gives me a ReadingListPageRow, but that doesn't have a diskStatus() method
[18:06:12] <mdholloway>	 niedzielski: only ReadingListPage does
[18:18:13] <niedzielski>	 mdholloway: does status() not work?
[18:19:11] <mdholloway>	 niedzielski: aha, that's it, thanks
[18:19:31] <niedzielski>	 👍
[18:35:15] <dbrant>	 bearND: can this be resolved? https://phabricator.wikimedia.org/T126934
[18:35:48] <bearND>	 dbrant: yes, will do so shortly
[19:17:15] <niedzielski>	 dbrant: better safe than sorry, are the three reading list ui patches ready for merge?
[19:17:42] <dbrant>	 niedzielski: the first two are. I'm just about to upload the third.
[19:17:58] <niedzielski>	 dbrant: okey dokey
[19:26:57] <dbrant>	 niedzielski: patch 3 ready now
[19:27:20] <niedzielski>	 dbrant: cool. one question so far, does Log.e not print the stack?
[19:28:00] <dbrant>	 niedzielski: i don't believe so..
[19:29:13] <niedzielski>	 dbrant: so when you go to dev settings and tap the crash button, that doesn't give you a trace in a master build?
[19:30:15] <niedzielski>	 dbrant: i actually get two traces: one for the crash taking down the app and another for the app restarting and the crash reporter sending it in
[19:32:16] <dbrant>	 niedzielski: oh, hang on: in the third patch, I actually modified HockeyAppExceptionHandler to explicitly print the stack trace, precisely because I wasn't seeing the trace in logcat.
[19:32:33] <dbrant>	 niedzielski: ...but now I am seeing the trace twice, the second time when HockeyApp sends it
[19:32:43] <dbrant>	 niedzielski: let me take that bit out
[19:38:30] <dbrant>	 niedzielski: r4r
[19:38:47] <niedzielski>	 👍