[03:41] <mmcc> back, looking at those branches now
[05:06] <mmcc> had to mess with how the tests were run, but managed to get u1-client tests running on win7
[05:06] <mmcc> was complaining about not finding comtypes, but 'python' on the command line found it OK
[05:07] <mmcc> ended up running 'python ..\..\bin\u1trial-script.py blah'
[05:07] <mmcc> plenty of failures
[05:07] <mmcc> and slow enough to type a running commentary. here come the ActionQueue tests
[05:13] <mmcc> never mind, only a small number of failures
[05:35] <mmcc> tests OK, but still not working IRL for me, cp is not starting ubuntu-sso-login correctly. tracking through to the popen call
[05:38] <mmcc> oh right, the sync_menu dummy problem is probably killing my syncdaemon
[05:38] <mmcc> that's at least part of what's going wrong here
[05:44] <mmcc> fixed that, and my syncdaemon log shows this error now: http://paste.ubuntu.com/1282529/ -- maybe I don't have the syncdaemon.conf file in the right place?
[05:44] <mmcc> I'm going to defer this to tomorrow now
[08:39] <JamesTait> Good morning all! :)
[10:09] <mandel> alecu, mmcc, ralsina, I have found a very annoying thing in the control panel. we have two different requests to the account info, one in the account tab and a diff one in the main controlpanel widget (controlpanel.py) I think we should have a single one
[10:10] <ralsina> mandel: yes, that was mentioned yesterday, that we have two calls to most things on startup
[10:10] <ralsina> mandel: so yes, if you see it easy to clean, go ahead
[10:11] <mandel> ralsina, yes, and that makes it slower, the interesting thing is that if we have a single one we will be able to at least update the data (name and usage) in the main widget when we update the accounts tab
[10:11] <mandel> ralsina, and if that is made a looping call even better
[10:11] <ralsina> mandel: looping call is better
[10:12] <mandel> ralsina, yes, that will mean that the tab and the top bar will be update all the time, but that should be a diff bug
[10:12] <ralsina> but we must make sure it doesn't block. And then the accounts tab doesn't need to block at all either
[10:12] <ralsina> so that tab becomes "fast"
[10:12] <mandel> ralsina, exactly, account info tab does not longer need to do a request every time, just when really needed
[10:12] <mandel> I mean, is not longer needed
[10:13] <mandel> ralsina, but that is a diff bug which I can also fix
[10:13] <mandel> in a diff branch better :)
[10:55] <mandel> ralsina, I have noticed that we are using our widgets wit the qtdesigner generated file, how is that done with the ubuntuone-control-panel?
[10:59] <ralsina> mandel: I don't understand the question
[10:59] <mandel> ralsina, you know when you create custom PyQT widgets and later used them in the qtdesigner, well, I forgot how to do that..
[11:00] <ralsina> oh
[11:00] <ralsina> ok, right click on the widget, then "promote"
[11:00] <ralsina> let me rephrase
[11:00] <ralsina> you put a placeholder widget, then you right click and promote it. But are you doing a custom widget?
[11:02] <mandel> ralsina, yes, a want to add a custom tabwidget so that it control the overlays of the inner widgets correctly
[11:02] <mandel> ralsina, are you suer is with promote?
[11:02] <ralsina> mandel: totally sure
[11:02] <mandel> ralsina, I mean, it needs the imports etc.. from the python code
[11:02] <ralsina> mandel: yes
[11:02] <ralsina> mandel: look at how it's done where we are using it :-)
[11:02] <ralsina> you can tell it the "include file" which is really an import
[11:03] <mandel> ralsina, oh, ok then
[11:03] <ralsina> mandel: but you probably don't need one, really
[11:04] <ralsina> mandel: can you talk this with gatox when he starts?
[11:04] <mandel> ralsina, sure, but I think we need one to do things properly
[11:05] <mandel> ralsina, we have a lot of overlays that are doing things in the wrong way..
[11:05] <ralsina> mandel: yes, but properly means many things :-)
[11:05] <ralsina> mandel: for an example on how it's done, check mainwindow.ui
[11:05] <ralsina> mandel: keep in mind that the overlay of a tab should not block the tab widget, just the contents of the tab
[11:05] <ralsina> which is why currently all tabs inherit from something that has the overlay
[11:06] <mandel> ralsina, yes, that is what I'm doing, but I want to be able to do the following: tab_widget.show_overlay = false and doe the right thing, I of course can do the same (loop over the tabs and don't show the overlay) but that means that the controlpanel.py code is doing more than it should
[11:07] <mandel> ralsina, ideally the tabwidget should deal with that, not the controlpanel code
[11:25] <gatox> good morning!
[11:34] <mandel> gatox, ralsina: fix => lp:~mandel/ubuntuone-control-panel/double-gathering can you try it on a mac or a windows machine to see how it works?
[11:35] <gatox> mandel, checking on windows
[11:37] <mandel> ralsina, gatox, I also fixed the bug in which the overlay is removed before we have the username in the label, is there a bug number for that?
[11:38] <mandel> it really really got me annoyed :P
[11:38] <gatox> mandel, no that i am aware of
[11:38] <mandel> joshuahoover, rye ^
[11:39] <gatox> mandel, do you want me to run the tests or execute control panel with your branch?
[11:39] <mandel> gatox, just run control panel with it
[11:39] <mandel> gatox, the following should happen, you just see on overlay, as soon as the user account info is there you can switch the tabs and you will see the correct overlay per tab
[11:40] <rye> mandel: hm, i don't think I've seen a bug for that, it used to be this way from the beginning and (i guess) nobody thought that was a bug
[11:41] <mandel> rye, hehe I'll make one then :)
[11:43] <mandel> ralsina, gatox, we should not show the overlay if we got the result very fast from the backend, I find it very annoying to see it for a nanosecond
[11:47] <mandel> gatox, does it work?
[11:48] <gatox> mandel, i'm seeing the single overlay..... but for some reason i'm not getting the info to show.... so the overlay never goes away.... but the same is happening in trunk for me on windows
[11:48] <mandel> gatox, hum.. that is annoying..
[11:48] <gatox> mandel, but is working for you?
[11:48] <mandel> gatox, on mac does work
[12:01] <mandel> ralsina, gatox, alecu, I have a very simple way to fix the issue with the acocunt info being outdated
[12:01] <mandel> waht about to connect to the upload done and then ask for the account info then?
[12:02] <mandel> is not a looping call so you will be as close as the truth as possible without using to many resources or adding anything to sd
[12:12] <alecu> mandel: sounds like half of the perfect solution
[12:12] <alecu> mandel: what if another computer is doing the uploads?
[12:12] <alecu> mandel: or a phone
[12:12] <mandel> alecu, true, we would have an issue there
[12:13] <mandel> alecu, although, we can also connect to the downloads ;)
[12:13] <alecu> mandel: right :-)
[12:13] <alecu> mandel: anyway, we should only call this operation say, a maximum of once per minute.
[12:13] <mandel> alecu, then you have nearly a perfect solution with a small development investment
[12:14] <mandel> alecu, agreed, we have to have an upperbound of some kind
[12:14] <alecu> mandel: so, if too many uploads and downloads are happening at the same time, the quota webapi is only called once per minute still.
[12:15] <mandel> alecu, ues, makes perfect sense, else with 1000000 small files you are performing a dos attack to the rest api
[12:15] <alecu> mandel: also, we should split the "quota call" and "account call" at the control panel backend level.
[12:15] <mandel> alecu, 100% agree, that delay in the username stuff is probably due to that quota info
[12:15] <alecu> mandel: anyway, we would be performing a smaller scale DDOS on our api, if we call it once per minute from every connected computer :-)
[12:16] <alecu> mandel: no, I've checked it yesterday, and the quota is the fastest part.
[12:16] <mandel> alecu, really? weird!
[12:16] <alecu> mandel: here's the timing on a sample control panel startup:
[12:17] <alecu> account call: 1.9406189918518066
[12:17] <alecu> account call: 2.4485630989074707
[12:17] <alecu> quota call: 0.28434205055236816
[12:17] <alecu> quota call: 0.3152000904083252
[12:17] <mandel> alecu, I think that is why I dont like the looping call, connecting to upload and download should be ok if we make an uper bound, similar to what we do with the notifications, right?
[12:17] <mandel> wow, the account call is very slow!
[12:17] <alecu> mandel: it's probably touching a lot of db tables
[12:17] <alecu> mandel: also, we are calling each api twice on every u1cp startup.
[12:18] <alecu> mandel: luckily, both account calls are done at the same time.
[12:18] <alecu> don't know if it's good or bad luck, though :-)
[12:18] <mandel> alecu, yes, no problem for that, I have a fix :)
[12:19] <mandel> alecu, let the account tab do the call and tell the controlpanel it got the data
[12:19] <mandel> alecu, which also means we could update the usage every time the user opens the account tab
[12:19] <alecu> mandel: yes... but I don't like that as much :)
[12:20] <mandel> alecu, is not nice, I know, else we can do the opposite, let the contorl panel tell the tab it got the info
[12:20] <mandel> alecu, but I don't see how bad is the first idea...
[12:21] <alecu> mandel: no, I meant I don't like: "we could update the usage every time the user opens the account tab"
[12:22] <mandel> alecu, oh, well, we are already doing the request, we might as well use the data everywhere, right?
[12:23] <alecu> mandel: oh, so it won't be exclusive to that! you mean, we use the info there, and we use the info after downloads and uploads too.
[12:23] <mandel> alecu, yes
[12:23] <mandel> alecu, is to improve the smartness at boot time, not to fix the other problem :)
[12:45] <mandel> ralsina, gatox, can you review: https://code.launchpad.net/~mandel/ubuntuone-control-panel/double-gathering/+merge/129871 it fixes the double overlay problem and a other small bug
[12:46] <gatox> mandel, ack
[12:47] <mandel> gatox, I preferred to create a new widget rather than adding more logic to the controlpanel.py
[12:53] <ralsina> mandel: looking
[12:53] <mandel> gatox, ralsina, I'm also going to reduce the number of calls we do to the account info which is a simple fix and might make the app faster on mac os x and windows
[12:54] <ralsina> mandel: right, it's just deleting stuff and getting from the parent
[12:54] <mandel> ralsina, kinda :)
[12:55] <mandel> ralsina, also, read the backlog, maybe connecting to download and upload to update the quota info is a better idea
[12:55] <mandel> ralsina, less development and will get good enough results
[12:56] <mandel> ok, off to have lunch
[12:59] <gatox> mandel|lunch, +1
[13:07] <ralsina> officially good morning!
[13:07] <gatox> ralsina, officially hi
[13:13] <ralsina> mandel|lunch: in lines 53+ of the diff, you are setting "is_processing" which sets the overlay, *after* you do the API request, so while the request is done, the UI looks unblocked, is that intentional? Why are we bloking there for?
[13:13] <gatox> ralsina, dobey i've fixed the qthread problem..... if you can, please take a look at: https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/u1-cp-qthread/+merge/129722
[13:14] <ralsina> gatox: sure!
[13:14] <gatox> ralsina, thx
[13:15] <ralsina> gatox: oh, so, basically not use a thread in the tests?
[13:15] <ralsina> gatox: doesn't that make the test cover less?
[13:16] <gatox> ralsina, we are using the qthread..... but running run directly instead of start().... so it doesn't run as a thread, but like a normal function call...... to avoid the race condition
[13:17] <ralsina> gatox: yes, right, so we block on it
[13:17] <ralsina> gatox: so, I am just wondering if we are leaving something untested
[13:17] <ralsina> gatox: but I guess for what this tests, it's ok
[13:17] <gatox> ralsina, yes, but only for the tests...... because to test that the info is being generated correctly.... we need to wait until the info is processed
[13:18] <alecu> ralsina, gatox: we are using the qtreactor to run these tests on linux, right?
[13:18] <dobey> alecu: yes
[13:18] <gatox> alecu, yes.
[13:19] <alecu> gatox: perhaps we should be using python's thread instead of qt? to be compatible with the reactor, I mean.
[13:19] <ralsina> alecu: the thing is, the test has to wait for the thread anyway
[13:19] <gatox> alecu, i'm using qthread to be able to emit a signal
[13:20] <dobey> alecu: control-panel doesn't use twisted on linux though, i don't think?
[13:20] <dobey> alecu: the only reason we're using twisted in the tests on linux, is because it's the test runner we have to work with
[13:21] <dobey> of course, we'd still have this issue on win/osx
[13:21] <alecu> dobey: right.
[13:21] <gatox> dobey, which issue? (this fixes the problem in win and osx too)
[13:21] <dobey> gatox: the issue of the problem that using qthread was meant to solve
[13:22] <gatox> ah
[13:22] <ralsina> I think gatox solution is good, but we could think of a way to do this without threads. It just seemed simpler at the time.
[13:22] <dobey> and thus, having to wait on a thread in the tests
[13:22] <ralsina> gatox: why not start the thread and just join() it?
[13:23] <dobey> and using threads and twisted together can get complicated
[13:23] <gatox> ralsina, i wanted to avoid the threading part for the tests.... but if you think is best
[13:24] <alecu> dobey: why is it different when using twisted? threads get complicated anyways
[13:24] <ralsina> gatox: well... I am +0 there really
[13:24] <ralsina> gatox: but running it in a thread means we can't do things in the function that don't work on threads :-)
[13:24] <dobey> alecu: using pure python threads with twisted is a bit more complicated than say, using twisted's deferreds/callLater/etc stuff
[13:24] <ralsina> gatox: and that if we do, it will crash the test
[13:25] <dobey> alecu: we ran into some issues early on with twisted+glib+dbus+threads (don't remember if you were here for that or not)
[13:25] <ralsina> gatox: let me think it 5' and I'll have an opinion :-)
[13:26] <gatox> ralsina, i can wait() (qt way) for it if you want..... no problem
[13:26] <gatox> just a couple of lines more
[13:26] <dobey> also, trial at least doesn't make testing things that use threads easy, outside of twisted's deferreds/callLater/etc stuff
[13:26] <alecu> dobey: yes, I saw some of those. iirc, they were related to the static gnome keyring bindings.
[13:27] <ralsina> I vaguely remember thread-related crashes in the gtk preferences thing at some point?
[13:28] <dobey> alecu: no, this was before that
[13:28] <dobey> ralsina: that was a different issue, if there were any such crashes
[13:28] <gatox> ralsina, do you want me to change it to wait() or do you want to think about it?
[13:28] <ralsina> gatox: think
[13:28] <gatox> ack
[13:29] <ralsina> ok, mgmt call coming, gatox +1
[13:29] <dobey> the issues i'm talking about, i think were at a point when we were even using plain twisted reactor, and not even the glib reactor
[13:29] <gatox> ralsina, +1 to what?.....
[13:29]  * gatox is confused
[13:29] <ralsina> gatox: your branch :-)
[13:29] <gatox> ralsina, ahhhh... i thought you were going to request a change maybe
[13:30] <ralsina> gatox: I was thinking about asking for one, but then I stopped :-)
[13:30] <gatox> ok, so i only need dobey approval now
[13:32] <gatox> need to restart...... unity crashed badly..... brb
[13:44] <gatox> dobey, it fails again!
[13:45] <gatox> ok..... this just doesn't make any sense......
[13:45] <chaselivingston> ping mmcc: can you ping me when you login for the day?
[13:46] <dobey> gatox: makes perfect sense to me
[13:46] <gatox> dobey, why? explain to me please
[13:49] <dobey> gatox: it seems like the start() call is being called before everything is fully initialized; probably some yields need to be added or removed
[13:50] <grammoboy> hi, iam uploading a 3.8 gb file
[13:51] <grammoboy> loading please wait ..
[13:51] <grammoboy> any chance it will succeed?
[13:51] <gatox> dobey, mmmmm.. yes..... it seems that _get_volumes_info is being executed..... and it shouldn't...... that is being patched before creating the instance..... but.... why this doesn't fail here? i can't understand how to reproduce it
[13:52] <dobey> grammoboy: it will eventually succeed; might take quite a while though
[13:52] <grammoboy> k
[13:52] <dobey> gatox: i have no idea why it's not failing outside of tarmac
[13:53] <gatox> dobey, mmmm i think i have an idea
[13:54] <gatox> let me try something
[14:05] <mandel> ralsina, line 53?
[14:05] <mandel> ralsina, you mean this =>  self.is_processing = False
[14:05] <mandel> 59	+        self.ui.tab_widget.show_overlay = True
[14:06] <mandel> ralsina, is being set to false, which removes the overlay, and that is because loading the data takes some nano seconds and is a little annoying
[14:23] <gatox> dobey, i'm pretty sure i've just fix the thing..... if i'm wrong, i'll buy you a beer! jeje https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/u1-cp-qthread/+merge/129722
[14:28] <dobey> https://code.launchpad.net/~dobey/ubuntuone-client/grrrr-gir-4-0/+merge/129904 could use a couple reviews
[14:28] <dobey> hrmm, we need to fix the tests to not use so much memory in u1-client
[14:30] <gatox> dobey, reviewing
[14:31] <mandel> dobey, will review asap
[14:35] <gatox> dobey, your branch has some conflicts with trunk
[14:36] <gatox> dobey, ahhhhh sorry
[14:36] <gatox> stable
[14:48] <gatox> dobey, +1
[14:49] <alecu> hey all, I'm missing the standup: thanks to a friend's wife that's a heart doctor I just got an out of schedule appointment for an extra checkup I need before my vacations.
[14:49] <alecu> so, I'll be back in a few hours.
[14:49] <alecu> ralsina, gatox ^
[14:51] <mandel> alecu, much better than if he is a gynecologist :)
[14:51] <gatox> alecu, ack ack!
[14:52] <dobey> gatox: hey, your branch merged
[14:52] <gatox> dobey, \o/ i don't have to buy you a beer! jejeeee
[14:53] <gatox> finally.....
[14:54] <dobey> fixing pyflakes is hard :-/
[14:55] <mandel> ralsina, alecu, gatox, we seem to call account_info from several places, I think the best is to do what alecu already mentioned, split the call between quota and account info
[14:55] <gatox> dobey, i know....
[14:55] <gatox> been there
[14:55] <gatox> mandel, sounds reasonable
[14:59] <mandel> gatox, never ever tell people you like coldplay..
[15:00] <gatox> mandel, why?
[15:00] <gatox> mandel, it's a good band!
[15:00] <dobey> me
[15:00] <thisfred> me
[15:00] <mandel> gatox, told you over twitter :)
[15:00] <mandel> me
[15:00] <briancurtin> me
[15:00] <gatox> me
[15:00] <mmcc> me
[15:03] <ralsina> go ahead, am on the phone
[15:03] <dobey> DONE: catch up, bug #1066943 (trunk, 4-0), partial fix for false positive redefinition of unused import in pyflakes
[15:03] <dobey> TODO: bug triage, fix bugs, move off pylint, investigate packaging u1db-client/u1db-serve scripts
[15:03] <dobey> BLCK: None.
[15:03] <dobey> thisfred: go
[15:03] <thisfred> DONE: plan u1db handover/wrap (not much) TODO: u1db handover/wrap BLOCKED: no NEXT: mandel
[15:03] <mandel> DONE: Booked flight to CPH. Fixed bug 1065513 bug 1067329 bug Look at why we all sooo many times account_info
[15:03] <mandel> TODO: Fix some code in the unity branch I proposed to be merged. Do paper work on canonical admin
[15:03] <mandel> BLOCKED: no
[15:03] <mandel> briancurtin, please
[15:03] <briancurtin> DONE: rebuilt the jenkins setup on ec2-windows so now everything is operational. started hacking up a plan to remove windows batch files from everywhere in favor of python scripts. pushed two stupid fixes i forgot about.
[15:03] <briancurtin> TODO: reviews, installer, figure out why client tests are failing on my machine but not jenkins
[15:03] <briancurtin> NEXT: gatox
[15:04] <gatox> DONE:
[15:04] <gatox> Finally figure it out what was the problem with the qthread bouncing branch and fixed... AND MERGE! Couple of reviews.
[15:04] <gatox> TODO:
[15:04] <gatox> Keep fixing u1-cp related issues.
[15:04] <gatox> BLOCKED:
[15:04] <gatox> No
[15:04] <gatox> mmcc, go
[15:04] <mmcc> DONE: more pyobjc menu, review path stuff, bug fix in sync_menu
[15:04] <mmcc> TODO: more pyobjc menu, your reviews
[15:04] <mmcc> BLOCK: no
[15:05] <mmcc> comments? EOM? bueller?
[15:09] <ralsina> EOM
[15:09] <ralsina> sorry guys I am so intermittent, but... busy.
[15:11] <dobey> time for lunch break
[15:11] <dobey> bbiab
[15:19]  * gatox lunch!
[15:31] <mmcc> does anyone have a link to a picture or video of how the sync menu looks on ubuntu (not the systray.py Qt one, but the one we don't own that will actually get used)
[15:35] <ralsina> mmcc: gatox_lunch does
[15:35] <ralsina> mmcc: I must have it somewhere, but not a recent one
[15:35] <mmcc> ralsina: I figured, but didn't' ping him 'cause you know, lunch :) it's not super urgent. do you remember if it draws progress bars for the uploads?
[15:37] <ralsina> mmcc: it does, yes
[15:38] <ralsina> mmcc: and really ugy ones (they have the length of the text)
[15:40] <mmcc> ralsina hm. well, I guess I'd have to see that since the ones I'm drawing have the same length as the text too…
[15:43] <ralsina> mmcc: hey, ugly yet portable ;-)
[15:45] <mmcc> ok, I was testing with filenames all the same length. the prog bars don't shrink to match the text, so the bars are always a certain size… need to test the corner cases here
[15:47] <mmcc> ralsina: here's what the cocoa sync menu looks like now: http://ubuntuone.com/2LEI6YG79vXCxhhWrhDIbq
[15:49] <ralsina> that looks good
[15:51] <mmcc> yeah, not bad - I'd like the progress bars to be less visually heavy. It'd be nice if the rows were the same size as the recent transfer rows
[15:51] <mmcc> same height
[15:54] <ralsina> mmcc: yes, but... 1stworldproblems
[15:55] <ralsina> it's about 10px taller, but there is a whole progressbar there... is the bar height tweakable?
[15:56] <ralsina> mmcc: you could go for the skinny-bar look like safari scrollbars. Also, a less shiny color
[15:57] <ralsina> mmcc: but I have no idea of platform expectations there
[15:57] <mmcc> sorry, afk for a sec
[15:58] <mmcc> ralsina: the bar height is tweak able a bit, but it's set at the smallest that interface builder lets you set. I think maybe I can squeeze it more in code though
[15:58] <mmcc> also I need to check the color, since half the time I try it it's a disabled grey color
[16:01] <ralsina> mmcc: ack
[16:16] <mandel> ok, EOD for me catch you tom!
[16:25] <karni> bye mandel
[16:29] <briancurtin> mmcc: https://code.launchpad.net/~mikemc/ubuntuone-control-panel/remote-folders-fix/+merge/126037 is now confliced on trunk (because you had to wait so long for my review, sorry)
[16:30] <ralsina> elopio: lunchtlunchtime!
[16:31] <mmcc> brb. briancurtin yes, I knew that'd happen. I'll fix it
[16:33] <dobey> hmm
[16:33] <dobey> does anyone know anything about _ast?
[16:35] <gatox> mmcc, ralsina do you still need the video?
[16:35] <elopio> ralsina: ¡buen provecho!
[16:36] <mmcc> gatox: sure if it's just a link
[16:36] <gatox> mmcc, yes......
[16:40] <mmcc> briancurtin: that reminds me, I tried to review your bin-finding branches last night but ran into some problems launching syncdaemon. did you happen to see what I said in the scroll back?
[16:40] <mmcc> briancurtin: I think it might be related to not finding the right conf files when running from source? here's the SD trace back: http://paste.ubuntu.com/1282529/
[16:41] <briancurtin> mmcc: i didnt get anything. i just close my IRC when im done
[16:41] <mmcc> oh one of those
[16:41] <gatox> mmcc, this one? http://youtu.be/qOmaBCayQAo
[16:43] <mmcc> briancurtin: here's what I wrote last night, not too much more enlightening, but: http://paste.ubuntu.com/1283397/
[16:44] <mmcc> gatox: yep, that's good - thanks!
[16:44]  * mmcc goes to see what happens with a super long file name on my code
[16:45] <briancurtin> mmcc: on the comtypes problem, setting up a proper buildout requires some manual intervention because of the [windows] section doesnt play nicely with the rest. im hopefully done fiddling with buildout for the rest of my life, and the manual step is pretty easy (just add the comtypes path to sys.path in python-script.py)
[16:46] <briancurtin> mmcc: any of those u1trial-script.py and python-script.py files are out of whack on windows depending on what buildout commands you run. i just insert whatever ends up missing when i run
[16:46] <mmcc> briancurtin: hmm. in my buildout, comtypes is just in the eggs/ directory as you'd expect, and 'import comtypes' works when I run 'python' or 'python.exe'
[16:46] <mmcc> just u1trial doesn't seem to have it for some reason
[16:47] <briancurtin> exactly
[16:47] <mmcc> right
[16:47] <briancurtin> thats part of what was confusing me for so long because i could import comtypes (thanks to python-script.py) but running the tests would fail (thanks to u1trial-script.py)
[16:47] <mmcc> aha. let's see if I can stare at the buildout cfg and suss this
[16:48] <mmcc> if you feel me pull the air hose, PULL ME UP
[16:48] <briancurtin> i wouldnt spend too much time on it. it's already nicer than it used to be, and you only need to do those manual steps when setting up the first time of an env (which isn't often)
[16:50] <mmcc> I know what's up - comtypes is only in the 'windows' section, which builds its own interpreter, so that's why python sees comtypes. all the other sections that build a script only have development:eggs in their eggs dependency
[16:50] <mmcc> I think we just need to add comtypes to the development eggs
[16:50] <mmcc> testing…
[16:53] <briancurtin> mmcc: it might work because comtypes is just pure python, but it depends on pywin32 so if it ever comes up that it tries to import it, it'll fail there
[16:54] <briancurtin> im pretty sure thats why we have the split. we used to just have it in development but commented out for non-windows
[16:55] <mmcc> yeah, it solves the problem on windows but if I try to do it on darwin, it has some problems installing comtypes
[16:55] <mmcc> but just this: "error: comtypes\__init__.py: No such file or directory" -- weird
[16:57] <mmcc> yeah, easy_install horks on comtypes for some reason
[16:58] <ralsina> mmcc: we may have to do an egg and install from there
[16:58] <mmcc> ok, so the manual fix is either edit your u1trial / u1lint / pyflakes and pylint scripts or edit buildout.cfg on windows to add comtypes to the development section :\
[16:59] <briancurtin> mmcc: i'd rather just leave it as-is and do the minimal edit to get it going. it's not too bad, just tricky until we've now gone through it
[16:59] <briancurtin> next time i complain about comtypes not importing, it *should* take 2 seconds to realize
[16:59] <ralsina> put it in the README I guess
[16:59] <mmcc> briancurtin: yeah. FWIW, I think the minimal edit is editing buildout.cfg -- one script vs four
[17:00] <briancurtin> mmcc: but doesnt it screw *you* up on mac if it goes in development? it'll work for me
[17:02] <mmcc> briancurtin: it does screw me up, yes. but as long as you're hand-editing files to hack it to work, hand-editing buildout.cfg and re-generating the other four scripts seems easier
[17:03] <mmcc> I know, let's write a script to generate buildout.cfg based on the platform!
[17:03] <mmcc> bonus points if it uses autotools
[17:03] <ralsina> mmcc: wellllllll
[17:04] <briancurtin> ralsina: 1-1? irc or mumble?
[17:04] <ralsina> briancurtin: in 5' please, I am finishing another call
[17:04] <briancurtin> np
[17:04] <mmcc> you know, when I was reading up on buildout, I was wondering why they didn't just use makefiles. I decided it made sense but argh, half-assed dependency and substitution rules
[17:08] <ralsina> mmcc, briancurtin: the solution to all problems http://davidjb.com/blog/tag/buildout
[17:08] <ralsina> using mr.scripty you can use conditionals inside buildout.cfg :-)
[17:09] <mmcc> what a great hack
[17:09] <ralsina> examples here https://github.com/collective/mr.scripty/tree/master/mr/scripty
[17:10] <ralsina> it's deeply evil
[17:10] <mmcc> yep, just add dots to get around blind ini parser. :D
[17:11] <mmcc> not sure this helps us with the present problem though :\
[17:11] <ralsina> mmcc: yes, you can change the egg list when the platform changes
[17:11] <ralsina> mmcc: so you only add comtypes on windows
[17:13] <mmcc> ralsina: aha! I didn't know they exposed the buildout section objects to those script tags. I'd only seen them used as code to be inserted into a generated executable
[17:13] <ralsina> of course this means we would have to install mr.scripty manually before running our buildout, which is more work that just installing comtypes manually in windows ;-)
[17:14] <mmcc> does it? buildout can find mr.scripty if it's in a few well known places
[17:15] <ralsina> in any case, it was just an idea :-)
[17:16] <mmcc> yeah, that totally works. it found mr.scripty
[17:16] <ralsina> team, go read your email now ;-)
[17:16] <mmcc> ralsina: ALL OF IT? ohgodno
[17:17] <ralsina> no, just the one from the big boss
[17:27] <ralsina> mmcc, dobey; get tickets
[17:28] <ralsina> gatox: you too if you read this :-)
[17:28] <gatox> ralsina, what?
[17:28] <ralsina> gatox: sprint tickets
[17:28] <gatox> ralsina, ahhhh..... reading
[17:31] <dobey> hmm
[17:40]  * mmcc reaches for hipmunk.com…
[17:41] <briancurtin> mmcc: back to your comment on the branches - with current trunk (now including your sync menu fixes) and my two bin-finding branches to SSO and U1C, everything works. i'm looking into why you might not have that conf file. have you ran the tests on the branches? i believe setup may move that file into the right spot IIRC?
[17:42] <mmcc> setup… hmmm. setup sounds like a good idea
[17:44] <ralsina> mmcc: never tried hipmunk.com "sort by agony" looks interesting!
[17:44] <mmcc> ralsina: it's very accurate. I've never disagreed with their agony sortings. although I was always searching with other people's money, so maybe my agony weights would change…
[17:45] <mmcc> briancurtin - no setup for u1-client, but run-tests.bat copies the conf files into data/… I'm not totally sure that's what is going on though
[17:48] <ralsina> mmcc: IIRC, the files are copied by "setup.py prepare"
[17:49] <ralsina> mmcc: as well as by run-tests
[17:49] <mmcc> ralsina: u1-client has no setup.py
[17:51] <mmcc> hrm, it looks like it's just not seeing logging.conf
[17:53] <ralsina> mmcc: the one from -installer does it
[17:53] <mmcc> well good news, running ubuntuone-syndaemon directly seems to work :\
[17:54] <ralsina> mmcc: usually, to run from sources, we have to copy that by hand
[17:54] <mmcc> ralsina: copy it to where?
[17:54] <ralsina> mmcc: into data
[17:54] <mmcc> well, I have a copy in ubuntuone-client/data/logging.conf. I think run-tests.bat put it there, it has that command
[17:55] <ralsina> windows/clientdefs.py has to be copied into ubuntuone and windows/logging.conf has to be copied to data
[17:55] <mmcc> yes, run-tests.bat does both of those
[17:57] <dobey> _ast is hard.
[18:15] <ralsina> dobey: you said that yesterday. So, still hard? ;-)
[18:16] <dobey> the documentation doesn't really tell you how to get the information you want out of the api
[18:16] <dobey> and the api itself is not obvious
[18:16] <gatox> dobey, if you need help with ast let me know.... i've playing A LOT with that, pyflakes, etc
[18:16] <dobey> and i think pyflakes is doing some stuff fairly wrong, so it's not a great example, and it doesn't show me how to do what i want to do, since it's not already doing it
[18:17] <gatox> and yes.... the doc is awful
[18:17] <dobey> gatox: of course i need help :)
[18:17] <dobey> i also need a resurrection ship that has a continuous supply of bodies to encapsulate my consciousness into
[18:20] <gatox> dobey, ejejejeje
[18:20] <mmcc> dobey: beware, after a few copies the clones get messy
[18:21] <dobey> mmcc: no more than 3 active at once. keeps it nice and sane
[18:22] <dobey> oh i guess mandel didn't review my branch
[18:22] <dobey> mmcc: want to take a poke at it? :) https://code.launchpad.net/~dobey/ubuntuone-client/grrrr-gir-4-0/+merge/129904
[18:22] <mmcc> dobey: since it might be obscure-ish, I'm thinking of "MOON", which is pretty good: http://www.imdb.com/title/tt1182345/
[18:22] <mmcc> dobey: sure I will poke away
[18:23] <dobey> mmcc: that is a great film
[18:24] <mmcc> a good soundtrack for working too, if you can work with anxiety and creeping dread
[18:25] <dobey> how can you work without it?
[18:26] <ralsina> I thought of http://www.imdb.com/title/tt0117108/ which is a very not great film
[18:26] <mmcc> dobey: just avoid twisted, cross-language bridges, and under-documented macro languages. Zero dread!
[18:27] <mmcc> ralsina: come on, that's classic michael keaton! Pride of Pittsburgh!
[18:28] <dobey> lawl
[18:28] <briancurtin> hahah
[18:29] <ralsina> Hey, Michael keaton was great in ... that one with Jennifer Lopez and George Clooney? ;-)
[18:29] <dobey> ralsina: Batman?
[18:30] <ralsina> dobey: no, different batman
[18:30] <ralsina> ;-)
[18:32] <dobey> heh
[18:32] <dobey> Mr. Mom
[18:33] <dobey> alright, need to run for a few, brb
[18:50] <mmcc_> briancurtin: when you run from source on windows and it works, are you still doing the thing with three separate console windows?
[18:55] <ralsina> So, the new team has a Mike, a Michael and a Michal
[18:55] <ralsina> Interesting phone calls ahead.
[18:56] <gatox> jeje
[18:56] <chaselivingston> ralsina: just call everyone by their irc name :)
[18:58] <ralsina> I also have a call with Roberto Roberta and Robert. Life is evil.
[19:02] <briancurtin> mmcc: i can do it that way, but in order to test all this stuff i've been just starting U1CP and letting it do its thing
[19:03] <mmcc> briancurtin: interesting. do you have a logging.conf in ubuntuone-control-panel/data by any chance?
[19:05] <briancurtin> mmcc: i do not. i'll try to find where that lives
[19:05] <mmcc> briancurtin: it should live in ubuntuone-client/data after run-tests puts it there
[19:06] <gatox> alecu, ping
[19:06] <briancurtin> mmcc: ah, i do have a ubuntuone-client/logging.conf but not control-panel
[19:06] <mmcc> but syncdaemon/config.py looks for it in a relative directory so when I run u1-cp from the cp directory, it will find syncdaemon.conf but not logging.conf
[19:06] <mmcc> this is why I can run syncdaemon from the u1-client dir but not from the u1-cp dir
[19:06] <mmcc> however, I don't know why it's working for you :)
[19:07] <mmcc> look at get_config_files in ubuntuone/syncdaemon/config.py - it gets the path to syncdaemon.conf relative to __file__ but does not do the same for logging.conf
[19:08] <dobey> damn
[19:08] <dobey> this is not the fun-dip i remember
[19:10] <mmcc> briancurtin: I think we must be launching cp differently somehow. if I change get_config_files to look for  __file__/../../data/logging.conf, everything works great
[19:10] <briancurtin> mmcc: where are you launching CP from? the CP top level dir of the checkout or within bin?
[19:11] <mmcc> briancurtin: I'm launching from the CP top level, with 'python bin\ubuntuone-control-panel-qt'
[19:11] <mmcc> briancurtin: where are *you* launching from?
[19:11] <briancurtin> same
[19:12] <mmcc> but… but…
[19:12] <briancurtin> mmcc: and PYTHONPATH=..\ubuntu-sso-client;..\ubuntuone-client;.
[19:12] <mmcc> briancurtin: yeah, me too
[19:13] <mmcc> O WAIT I KNOW. you've actually installed this thing on your system so you are probably getting logging.conf from the installed location
[19:13] <karni> ralsina: haha. Feel free to call me karni :) That makes one Mike/Michael/Michal less.
[19:13] <briancurtin> mmcc: ah, correct
[19:14] <mmcc> briancurtin: so, this is probably still a bug. I'll look at the logs to see if there's a good reason for it, but it should really run without being installed first. *whew*
[19:14] <mmcc> good news is I already know how to fix it
[19:15] <briancurtin> nice
[19:19] <dobey> hmm, i sense i may run into a problem having this much fun dip in such a close proximity to myself, and my equipment
[19:20] <dobey> gatox: do you know how to get more info from ExceptHandler in _ast? or also the full info for Import and ImportFrom?
[19:21] <gatox> dobey, what do you mean with the whole info from import..... for example if you have: import bla.bla.foo..... or from bla.bla import foo....... get: "bla.bla.foo"?
[19:22] <dobey> gatox: i mean, for example, 'import foo as bar' to always be able to directly point at a variable that contains the foo, and another that contains the bar (and similar for from imports)
[19:23] <gatox> dobey, i think i undeerstand..... let me create an example and i'll show you
[19:23] <gatox> dobey, i'll take me a couple of mins
[19:23] <dobey> for example, pyflakes currently treats "import foo as bar, baz as bar" and "try: import bar except: bar = None" as the same error, when they aren't the same thing at all
[19:24] <dobey> sure, thanks
[19:38] <gatox> dobey, let me know if this is what you need or i can keep improving this: http://paste.ubuntu.com/1283735/
[19:39] <gatox> dobey, if that isn't what you need... i'll need an example to understand better the problem please
[19:40] <dobey> hmm
[19:40] <gatox> nop?
[19:40] <dobey> well there are a couple problems. while trying to fix the annoying for us, i found a few more weird corner cases where it's wrong
[19:42] <dobey> gatox: do you know anything about TryExec/ExceptHandler also?
[19:43] <gatox> dobey, never play with that specific part.... but if you explain me what you need, i can take a look... most of ast is the same, with just a few different attributes and how they combine
[19:44] <dobey> gatox: well, i was just thinking that try/except ImportError needs to be special cased for the "redefinition of unused 'foo'" errors we keep hitting
[19:45] <gatox> dobey, and you want to detect if we are importing the same thing inside a try/except code..... i can do that..... the problem is..... that i'll give you some ast way to figure it out..... but pyflakes has some crazy structures, so i don't know how difficult will be to integrate that into pyflakes
[19:46] <dobey> pyflakes is rather simple really. it's just that the ast structures are crazy
[19:46] <dobey> is ast different from _ast btw?
[19:47] <gatox> dobey, _ast is a more low level module..... i only use it to compare some data type in one particular case returned by ast.... but you can do almost anything with just ast (more high level module)
[19:48] <dobey> ah, pyflakes seems to mostly use _ast
[19:48] <dobey> maybe making things harder than it should be
[19:48] <gatox> dobey, i can code something to try to detect name collision or not inside try/except and send that to you.... play with ast is actually really fun for me :D
[19:48] <dobey> ok
[19:49] <gatox> dobey, ok.... i'll work on that and let you know when i have something to see if that is what you need
[19:50] <ralsina> dobey, gatox: according to the docs, _ast is not meant to be used directly :-(
[19:50] <dobey> gatox: if i just knew how to get at the exception type that's being trapped with "except ImportError" for example, i could probably figure out the rest
[19:50] <ralsina> all its API is private
[19:50] <gatox> dobey, yes.... that's not difficult
[19:51] <gatox> ralsina, yes.... that's way i use always ast.... and i only needed _ast one time in the past for somethign reallyyyyyyyy particular
[19:51] <dobey> ralsina: lol "private" :)
[19:54] <ralsina> dobey: well, it's ... discreet? slightly embarrasing? ;-)
[19:54] <dobey> i still wonder how contributions to pyflakes are actually supposed to work, in terms of process
[19:58] <dobey> oh, "ast" was added in 2.6; and pyflakes probably still works on 2.5
[19:59] <dobey> but _ast just has the various Node classes anyway it seems
[20:14] <gatox> dobey, almost have it..... just a couple of mins
[20:24] <ralsina> gotta go pick up the kid!
[20:33] <gatox> dobey, take a look at this and let me know if it's helpful: http://paste.ubuntu.com/1283850/
[20:40] <dobey> hrmm
[20:40] <briancurtin> anyone besides mmcc around for a quick review? https://code.launchpad.net/~brian.curtin/ubuntu-sso-client/correct-subprocess-args/+merge/129442 its mostly the same as another branch that a few of you reviewed for u1client
[20:42] <gatox> dobey, nop?
[20:45] <dobey> gatox: not exactly, but i figured out what i need in pyflakes
[20:45] <dobey> gatox: so a few lines helped :)
[20:45] <gatox> dobey, good..... so, can i eod? :P
[20:45] <gatox> or do you need anything else?
[20:46] <dobey> you can eod. if i need more help at this point it will have to happen tomorrow anyway :)
[20:47] <gatox> dobey, ok...... see you tomorrow!
[20:47] <gatox> eod here...... bye people!
[20:49] <briancurtin> thanks dobey
[20:52] <dobey> sure
[21:13] <dobey> in other news
[21:13] <dobey> HOORAY
[21:14] <briancurtin> ast or fun-dip related?
[21:15] <dobey> both?
[21:15] <dobey> i have a patch to pyflakes which successfully gets rid of the RedefinedWhileUnused which has been so annoying for us
[21:15] <dobey> now to figure out how to get it upstream
[21:16] <briancurtin> nice. pyflakes is a project by divmod (the twisted people) IIRC
[21:18] <dobey> yeah
[21:18] <dobey> but i seem some weird branches on lp named "pyflakes-ng" and i don't really know what they're for, or how different they are
[21:18] <dobey> and i haven't received any replies to my pyflakes inquiries in #twisted :(
[21:19] <dobey> and then there's the whole licensing/copyright issue
[21:37] <mmcc> well that's interesting. the test for get_config_files is testing a patched get_config_files
[21:38] <mmcc> or rather, a test that should be testing the real function is testing the patched fake. there's more than one test for get_config_files
[21:41] <dobey> briancurtin: looks like you need to fix a test in that sso branch
[21:42] <briancurtin> dobey: i got it. there was a test for the special case, but since we removed the special case i removed the test. it got lost in the shuffle of other failing tests i'm seeing
[21:42] <dobey> ah
[21:43] <mmcc> brb…
[21:43] <dobey> need to run, later all
[22:11] <mmcc> ok, going to do lunch then EOD and work more tonight so my wife can go to the DMV
[22:31] <grammoboy> hm maybe torrent works better to share  files with your friends
[22:32] <grammoboy> large files that is
[22:32] <grammoboy> ubuntuone is stll busy with my 3.6 gb files, now for 12h already
[22:46]  * briancurtin heads to dinner, bye everyone
[23:26] <mareklug> hi there.  I run Mac OS X 10.8.2 natively, and just tried Ubuntu One, and purchased one song.  It's been 5 hours, and it still has not synced locally (in ~/.ubuntuone/Purchased for Ubunto One)
[23:26] <mareklug> Purchased from Ubuntu One *