All times shown according to UTC.

Time Nick Message
02:12 kcw_ joined #miro-hackers
02:12 kcw left #miro-hackers
09:27 maggie_s joined #miro-hackers
09:52 zanoi morning
10:07 CarlFK left #miro-hackers
10:57 maggie_s left #miro-hackers
13:22 willkg joined #miro-hackers
13:22 willkg hi!
13:54 willkg left #miro-hackers
13:56 willkg joined #miro-hackers
14:10 zanoi hi
14:11 willkg, there seem to be lots of hardcoded "Miro" strings in application.py are they all mistakes?
14:34 bendk, you there?
14:35 bendk hey zanoi
14:36 I think that we shouldn't ever be hardcoding Miro in a string a user will see
14:36 zanoi bendk, ok, i'll change those strings then
14:36 bendk, was gonna ask you about something else though
14:37 bendk, back when you reviewed the shuffle I did the changes and some more bugfixes
14:38 should I added the history thing, should I just push that to master & 4.0.2?
14:39 and I fixed another small shuffle bug but I am not sure whether you want that fix in 4.0.2
14:39 bendk I think that's good, can you tell me what the changesets are?
14:40 zanoi it's 37d13ba, 9222865, 05eb076 in the shuffle branch
14:42 with the last shuffle issue fixed we should never have an exception when accessing a previous/next shuffle item. However, I thought we should definitely let the try catch stuff stay but log a warning in case it happens
14:48 bendk zanoi: so they all seem fine for 4.0.2
14:48 I think for master we might want to take a different track
14:48 I think we've sort-of talked about it
14:48 janetPCF joined #miro-hackers
14:48 bendk it's weird that the filter code is in itemlist, rather than itemtrack
14:49 moving that code upwards makes all these special cases not needed
14:50 zanoi bendk, hmm..would that also fix 05eb0760e?
14:51 bendk oh, maybe not
14:51 yeah that should go into master
14:53 zanoi and 9222865 probably as well then?
15:02 bendk If ItemList didn't filter out items, I don't think 9222865 would be necessary
15:08 zanoi Hm..I don't quite understand. Then we would still catch exceptions which never should be raised but we wouldn't log it
15:09 imho we should probably either let it propagate it or log a warning
15:09 bendk oh
15:09 yes, I'm hoping to be able to remove the KeyError
15:10 but I'm not sure if this change is going into 4.1, we need to decide if it's a priority or not
15:10 so I guess we should just wait on checking things in and make a ticket that we should either check your changes in, or refacter itemlist/itemtrack
15:15 zanoi we could use bug 17508 or make a new one
15:23 bendk, do you know if there is a way to "migrate" prefs.py settings? As in, adding new settings whose default values are based on existing prefs.py settings values?
15:25 bendk I don't think we have one
15:25 willkg zanoi: we do a bit of that in platform-specific update functions.  most specifically with MOVIES_DIR.
15:26 zanoi: but there's no portable infrastructure for it.
15:26 zanoi willkg, ok, thx
15:28 janetPCF1 joined #miro-hackers
15:28 janetPCF1 left #miro-hackers
15:30 janetPCF left #miro-hackers
15:43 CarlFK joined #miro-hackers
16:48 janetPCF joined #miro-hackers
17:27 arpu joined #miro-hackers
17:32 natea joined #miro-hackers
19:18 arpu left #miro-hackers
19:26 kcw_ left #miro-hackers
19:33 kcw joined #miro-hackers
20:29 zanoi left #miro-hackers
20:29 zanoi joined #miro-hackers
21:28 janetPCF left #miro-hackers
22:09 natea left #miro-hackers
22:10 willkg left #miro-hackers
22:10 willkg joined #miro-hackers
22:18 maggie_s joined #miro-hackers

← Previous day | Index | Server Index | Channel Index | Today | Next day → | Atom Feed | Search | Google Search | Plain-Text | plain, newest first