[02:03:32] Hello josephine_l niedzielski ! [02:03:42] Hi Nicolas! [02:04:01] I just sent a few crash reports. [02:04:18] and the pic that caused them [02:04:33] Nicolas: hello :) [02:04:40] Hi! [02:04:56] Nicolas, yeah, I have been looking at them. I don't see the pic though? [02:05:03] Hi niedzielski :) [02:05:21] I forgot to press Send haha [02:05:28] Nicolas, oh, haha [02:05:40] in the wire now [02:06:30] Nicolas, niedzielski - would it be okay to prevent this crash via a try-catch block? [02:06:40] So even if it can't getLatitude() it will just move on [02:10:09] Nicolas: can you send me a copy? i'm not sure which bug you're referring to [02:10:34] niedzielski, try https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/commons-app-android/T31oUnHPxko/gnOf2PjhFQAJ [02:11:09] josephine_l: thanks :) [02:11:50] https://groups.google.com/d/msg/commons-app-android/T31oUnHPxko/S_ATDM_hFQAJ [02:13:08] josephine_l: i think the problem is that you're calling MyLocationListener.onLocationChanged() with the result of getLastKnownLocation() which you know can return null [02:13:48] josephine_l: if i understand right, i would just add a null check around the call to onLocationChanged on line 49 [02:14:14] niedzielski, ah, okay, thanks. So just return if null? [02:16:30] josephine_l: if the null check is at line 49, allowing initialization of your listener to complete, i would just wrap the method in a location != null conditional. the reason is that multiple function exit paths can be hazardous when the function is larger or the exit path is not near the top [02:17:22] niedzielski, gotcha. :) [02:17:26] josephine_l: your code would continue on as per usual. if the location listener received an update, you can then use that nonnull location [02:18:57] niedzielski, Nicolas , I attempted the fix and submitted a pull request [02:20:49] niedzielski, Nicolas - do you think this week would be a good time to do the new feature announces on the mailing lists etc? [02:21:53] josephine_l: i vote yes :) [02:22:53] niedzielski, sweet. :) I'll start on the documentation after that I guess, while waiting for the bug reports to come in? [02:24:14] josephine_l: that sounds good. i think Nicolas has been tracking enhancements. if you run out of docs, you look for a tiny one of those at your own discretion [02:25:09] merged! Yes announcing the new features is a good idea now [02:25:20] niedzielski, sure, will do. It's okay if I don't complete the extra enhancements in time for the Outreachy deadline right? I can just continue on with it after? [02:25:28] (after pushing to play store and waiting a few hours) [02:25:41] niedzielski, because I'm worried I might pick one that takes a bit too long to do, heh. [02:26:23] Nicolas, okay, will do. :) [02:26:33] josephine_l: yeah, that's completely optional. please don't feel pressured to pick up more than agreed to [02:27:33] niedzielski, sure thing. It will be beneficial to myself to do the extra stuff anyway, since I learn a lot from them. I just didn't want to jeopardize the final evaluation. :) [02:28:57] niedzielski, when you were talking about documenting the new classes and methods, did you mean in the code? [02:30:18] josephine_l: i did. i meant javadocs for the devs [02:31:31] niedzielski, okay, gotcha. And Nicolas, you meant a more general summary on the GitHub wiki, right? So I'll do both of those? Some things will be repeated but I think that will still be useful. [02:33:21] Yes, I feel that suggestions are sufficiently complex that an explanation outside of the source code would help. Or to avoid repeating too much, a user-level explanation could be good enough, explaining what get suggested and why. [02:34:26] Nicolas, gotcha, thanks. I'll start on that after doing the announces. :) [02:37:06] Nicolas, niedzielski - was there anything else we needed to discuss? [02:37:12] By the way, when the app crashed, it crashed *immediately* after selecting the picture, not after a while as I would have expected (for instance because it failed to get a GPS signal or something) [02:38:00] Nicolas: that's because we were immediately calling the callback with a null value from last known location [02:38:20] getLastKnownLocation returns synchronously and doesn't block waiting for a location [02:38:29] josephine_l: nothing on my end :) [02:38:32] I see! [02:39:07] niedzielski, oh, interesting... [02:39:27] Nicolas: i think if you turn off location services and reboot the device, then launch the activity, getlastknownlocation would return null... i think [02:40:41] Nicolas, niedzielski - btw the version after 1.9 is 1.10 right? [02:44:18] josephine_l: yep [02:44:52] niedzielski, haha, thanks. Will push the new release to Google Play shortly. [02:47:27] 👍 [02:48:35] niedzielski, lol, what was that? :) [02:49:20] josephine_l: it should be appearing as a thumbs up. is it not showing up> [02:49:23] > [02:49:26] oops, ? [02:49:47] niedzielski, it appears as a bunch of weird symbols. Four 0s in a square :P [02:49:48] showing up correctly as thumb up here (Ubuntu xchat) [02:49:59] Ooh. I'm using Hexchat, haha. [02:51:12] for 10 seconds I was thinking hexchat was a way to chat with hexadecimal codes only. That would explain the 0s. [02:51:47] Nicolas, lol!! [02:52:09] My hex codes are awful. I'd never be able to use that sort of hexchat :P [02:52:56] Wikipedia's XChat article starts like this: "XChat was ..." I am living in the past haha [02:53:55] josephine_l Nicolas: i've been using Kiwi IRC (https://kiwiirc.com/client) and it's been pretty decent. i tried weechat, hexchat, shout, and a number of other clients and this seems like the nicest looking and simplest one of the lot. [02:55:22] oh, web-based? [02:56:47] I quite like Hexchat. But then again the last time I ever used an IRC client was 10 yrs ago, and it didn't have username highlighting or anything, so my standards are pretty low... :P [02:56:51] Nicolas: yeah, you can wrap it in an electron shell too. it works ok [03:12:07] niedzielski, Nicolas , I'm gonna afk for a bit. See you guys next time :) [03:14:43] josephine_l: later :) [16:05:24] niedzielski, dbrant, bearND|afk had one of the last app versions had some changes in the network request handling? A user reported that he has some timeout errors since one of the last errors when browsing using a slow network: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=8864500 [16:10:05] FlorianSW: hm, for #1, this report is from december. i believe this was one of our most stable prod and beta releases. however, we did fix a number of 404 and beta-only content service issues since then. for #2, we do have simple wikipedia support. [16:11:20] FlorianSW: btw, thanks for that nice patch yesterday :) [16:14:00] niedzielski: I know that it's from december :P I took some time and answered some old (nearly 150-200) tickets and asked, if the problem still exists. This was one of the responses. And the conversation showed, that he already has this problem ;) [16:14:18] niedzielski: thanks :) I think I'll try to respond to all comments today :) [16:15:53] FlorianSW: ah, sorry! I was on the first message in the thread and didn't see your follow up. My mistake! [16:18:05] FlorianSW: ah ok, hm. I see in the screenshot that they appear to be roaming. I wonder if they have some data limitation enabled when roaming. [16:19:51] niedzielski: was my first thought, too, but he's (that's how I understood his answer) is always on a 2G network, and I don't think, that a network operator slows down the speed more than 2G :P So, the problem is still, that he has the problem since one of the last updates, not before :( [16:25:14] FlorianSW: we did upgrade our network client library in December (https://phabricator.wikimedia.org/rAPAWfefd4fab4c45e193de460e2d2d42f11a9218c018). we have a major version upgrade of the library planned this sprint (T126101). maybe check in after that goes through? [16:25:14] T126101: Upgrade OkHttp and friends to v3.0.1+ - https://phabricator.wikimedia.org/T126101 [16:27:02] niedzielski: I'm ok with it, I answer him, that we want to wait until the next upgrade and that he should test this before we do anything else. I'll put the ticket on "waiting" for (how long do you think you'll need to release an upgraded version?) [16:30:32] FlorianSW: the work hasn't been started yet but will likely make the next beta. i would expect it sometime in the next 3 weeks at the latest. [16:31:08] niedzielski: ok, thanks, I'll put it back to waiting for 4 weeks to be sure :) [16:31:48] https://phabricator.wikimedia.org/rAPAW0aeafc950d487d3434de5b634014207771c40d5d [16:32:30] T109376 [16:32:30] T109376: Bug: Page image thumbnails in history, saved pages, etc. do not respect namespace - https://phabricator.wikimedia.org/T109376 [16:32:34] FlorianSW: thank you! [16:32:40] lol cool [16:33:46] dbrant, niedzielski would you like to recheck https://phabricator.wikimedia.org/T127087 ?:/ [16:37:42] FlorianSW: unicode font issue (os-specific); merged as duplicate [16:38:04] FlorianSW dbrant: looks fine on API 23. i'll follow up with a screenie [16:39:52] thx dbrant & niedzielski :) [16:48:03] niedzielski, dbrant another question :P As you may know, I develop on a virtual machine (windows wtf! :P), that's why I don't want to use an AVD to test the app (it's to slow without VT), so I usually plug in my phone and use that instead. But unfortunately the usb connection (or the adb connection only, don't know) stops transferring the app apk to my device (while copying using the file manager of Ubuntu works without any [16:48:03] problems) and the Android Studio "Run" tab stucks at "Uploading apk to ...". Do you know any solution or do you have an idea to fix that? :( [16:50:13] FlorianSW: never had that issue... although I know that USB in a virtual machine can be spotty. [16:54:01] FlorianSW: you could try ADB over the network via USB (http://stackoverflow.com/questions/12477987/android-usb-debugging-in-virtualbox/12557836#12557836) or Wi-Fi (adb tcpip && adb connect 192.168.1.fun) [16:55:17] oops, that's adb tcpip 5555. i use it pretty regularly to avoid the hassle of a cable [16:58:00] FlorianSW: if you have a spare machine, you could also try using it as a dedicated emulator machine, or go a step further and install an android-x86 like, and run that over the network too. [16:58:53] niedzielski: I already have a second machine where I started to develop on the app, but my goal is to reduce the use of machines to one :P [16:59:03] I'll try the tcpip way now, maybe that's ok :D [16:59:08] thanks for the input! [17:00:19] FlorianSW: ah, i'm in the same boat. i like just having the one machine. for development, the emulators are a little slow but pretty great overall. i'm hoping some day soon they'll have a chrome / arc welder workflow [17:01:16] niedzielski: I loved the emulator, too, but I'm using Virtual Box, where the guest can't have VT, and it's (at least for me) really really slow to run an emulator on an emulated machine without VT :) [17:03:14] FlorianSW: doesn't the emulator support windows (either AOSP or android-x86 with VirtualBox or Genymotion)? i think you could just launch the emualtor on the host and port forward to the client. [17:03:39] hi bmansurov. just to make sure: I don't see any survey responses, yet. Given that it was scheduled to be deployed in today's SWAT, I thought I'd check with you. [17:03:51] * dbrant develops on windows, like a boss. [17:04:00] lzia: yeah, the patch had a problem [17:04:08] lzia: i submitted a new one, waiting for it to be merged [17:04:15] perfect. thanks bmansurov. [17:05:05] niedzielski: hmm, that could be an idea :) I'll check that, too :) [17:05:10] dbrant: +1! :D [17:05:36] dbrant: http://windows95tips.com/post/63040080957 [17:05:46] rofl [17:05:50] * niedzielski no one [17:15:16] > adb shell [17:15:19] $ su [17:15:24] # stop adbd [17:15:26] damn!!!!! [21:24:56] jhobs: in case not clear i would suggest doing the upstream patch alongside other tasks [21:25:12] otherwise for the next 2 months it's all you will be working on. [21:25:54] jdlrobson: oh yeah don't worry that's the plan [21:31:39] jhobs: i just saw it took up most of your time last sprint so was keen to free you from those shackles if it wasnt clear :) [21:35:20] jdlrobson: yeah I think I was just tip-toeing too much. I'll be less tentative.