[00:00] hey karni [00:00] yo duanedesign [00:01] karni: who would know about tritcask? Did you say verterok wrote it? [00:03] duanedesign: verterok is your man [00:04] duanedesign: dude.. why would you be interested in *such* details, are you applying for a software engineer position at canonical :D ? [00:04] :) [00:05] karni: now i am trying to help a user with a traceback I have never seen before [00:05] File "/usr/lib/pymodules/python2.7/ubuntuone-client/ubuntuone/syncdaemon/tritcask.py", line 408, in iter_entries [00:05] fmap = mmap.mmap(self.fd.fileno(), 0, access=mmap.ACCESS_READ) [00:05] ValueError: mmap offset is greater than file size [00:05] duanedesign: sounds interesting. I'd help you, but I have this terribly dumb assignment due previous Friday, meh. [00:05] duanedesign: nice :> [00:06] hope you get it done. [00:08] duanedesign: meh. I will. It just unbelivably sucks. I'm bending the time-space-learning-curve at canonical, and still I have to give written assignments remotely related to programming itself. Who care's if the organizations structure is flat or tall, or what are the dependencies. I care that I do what I like, and I know I have my managers I report to. How complex is that :P [00:08] Meh. I'll shut up, whining will get me nowwhere. [00:09] *nowhere [00:10] sometimes it helps get it of your chest, so to speak :) [00:11] Yeah [00:36] LP #657850 [00:36] Launchpad bug 657850 in ubuntuone-client (Ubuntu Natty) (and 5 other projects) "Ubuntu One Preferences applet doesn't display info properly (affects: 22) (dups: 5) (heat: 91)" [High,Fix released] https://launchpad.net/bugs/657850 [02:55] hi [02:55] is possible run U1 on fedora 15 ? [03:27] Does the Ubuntu One Account Recovery service forcibly drop capital case letters in usernames ? [03:27] and if so... it will actually block my own username (first letter capital) from being completely usable with the service [04:12] does anyone run a nvidia graphics card in here? [04:12] after i installed mine it boots up out of range now [04:13] any suggestions? [04:13] on fixing it? [04:13] GalahadForce: you probably want a more general ubuntu channel. graphics cards and the Ubuntu One service aren't really related [04:39] GalahadForce: like rmcbride said; you might want to try plain #ubuntu [04:39] adorilson: i would say possible, yes; easy, no. :) [09:00] morning === Chipaca` is now known as Chipaca [10:54] dobey, I will try [10:55] Morning! [10:56] morning karni === teknico is now known as teknico_away [12:10] morning all [12:11] morning duq [12:11] *duanedesign [12:11] :) [12:11] hi duanedesign [12:11] [duq is much better as a name] [12:11] :D [12:19] * fagan break [12:19] (made a good bit of progress on what im doing just have some fiddly stuff I should ask about after break) [12:35] hello everyone! [12:36] morning nessita [12:42] rye: ping [12:44] jeroen-, pong [12:45] oh hello rye [12:45] i was curious about the status of my files [12:45] jeroen-, i do remember about the recovery and working with the developer to find out the proper way to recover the files [12:46] i understood the admins should be able to restore them, right? [12:46] jeroen-, yes, the example file i gave you earlier is still allocated in the storage and databases but marked as inaccessible [12:47] rye: well I really hope someone can fix this [12:47] rye: if I must do something to speed uo the recovery, please let me know? [12:48] jeroen-, i am extremely interested in this since it impacts the possibility to recover the files for everybody [12:48] jeroen-, i have your email, should I need some more info from you I will send you a message [12:49] rye: OK, thanks in advance for your help - I really appreciate your help [12:50] rye: another interesting thing that it is possible that files can dissepear like this [12:50] jeroen-, and I am very sorry for such kind of unpleasant experience with Ubuntu One, but I am doing my best to make it recoverable [12:50] jeroen-, you might have removed metadata folders, in this case this is quite hard to say what happens [12:51] rye: yes maybe, but still the files are gone :( [13:07] rye: good morning! Have you seen an error like this before? http://ubuntuforums.org/showthread.php?t=1775986 [13:07] duanedesign, oh [13:08] duanedesign, no [13:08] duanedesign, but something tells me that the file is of 0 length [13:08] verterok, http://ubuntuforums.org/showpost.php?p=10923290&postcount=3 [13:08] ahhh === teknico_away is now known as teknico [13:49] standup in 10? [13:50] It seems like alecu and ralsina arent around and mandel is pretty quiet so he might not be around either [13:54] thems the breaks kid [13:54] of course stand up in 6'! [13:54] fagan: ralsina is off for the week [13:54] the cake is a lie [13:55] dobey: sometimes, yes. [13:55] nessita: oh [13:55] fagan: mandel should be working, and alecu is in a kindergarten meeting [13:55] nessita: I didnt know that I thought he was off till he got back to ar [13:55] nessita: ah ok [13:56] nopes, for the whole week, he's on holidays [13:56] :-) [13:56] so standup anyway with the like 3 or 4 of us [13:56] of course! [13:59] nessita: well I was wlaking the dog, but I have been working :) [13:59] very quietly [13:59] :) [14:00] moi [14:00] me [14:00] mandel: how was the photo shooting last night? [14:00] me [14:00] me [14:00] mandel say me :) [14:01] alecu says: [14:01] DONE: got VS2008 compiling txnamedpipes, testrunner for it at https://code.launchpad.net/~alecu/txnamedpipes/run-tests-batch/+merge/64747 TODO: work on the tests broken on the qt+txnamedpipes branch BLOCKED: hopefully not today [14:01] mandel: me? [14:01] fagan: go [14:01] DONE [14:01] * Fixed most of the issues with my branch [14:01] * Did all of alecu's list I think [14:01] TODO [14:01] * Fix a failure and an error im getting. The failure I dont have a clue about but the error is an easy fix. [14:01] Blocked [14:01] * by stupidity [14:01] thisfred: gogo [14:01] me [14:02] DONE: reviews | Bug #779851 [14:02] Launchpad bug 779851 in ubuntuone-client "Ubuntu One's Unity progress bar is uninformative when transferring a single file (affects: 2) (dups: 1) (heat: 23)" [Wishlist,Confirmed] https://launchpad.net/bugs/779851 [14:02] TODO same bug, whatever needs doing [14:02] BLOCKED: no [14:02] λ DONE: bug $797870, reviews, discussions [14:02] λ TODO: expenses, fix more stuff [14:02] λ BLCK: None. [14:02] dobey: you in a hurry? :-) [14:02] mandel: go [14:03] DONE: bug #797411, bug #797294, bug #797860 [14:03] TODO: finish up bug #797294, catch up with mandel re: SyncDaemonTool 4 windows, bug #798198 [14:03] BLOCKED: nopes [14:03] NEXT: mandel [14:03] Launchpad bug 797411 in ubuntuone-client "Extend SyncDaemonTool API (affects: 1) (heat: 389)" [High,Fix committed] https://launchpad.net/bugs/797411 [14:03] Launchpad bug 797294 in ubuntuone-control-panel "Implement preferences tab in the QT version (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/797294 [14:03] Launchpad bug 797860 in ubuntuone-dev-tools "Remove signals receivers as part of cleanup (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/797860 [14:03] Launchpad bug 798198 in ubuntuone-control-panel "Implement clicked callback for buttons that link to the web (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/798198 [14:03] DONE: workd of the vm helper implementation onwidnows. All test were broken but I have fixed them, I propose a merge but I push the wrong version will fix that so that it can be reviewd. Push the qt integration tests brach of txnamedpipes for alecu to work on. [14:03] TODO: finish sdtool for windows. [14:03] BLOCKED: no [14:03] OH: I have to go to the dentist at 4, so I will be gone for an hour or so (7 hours from now) [14:03] dobey: my turn was after thisfred, you stole it from me! :-) [14:03] thisfred: ack [14:03] nessita: you went first! [14:04] dobey: no, that was alecu's standup [14:04] mandel: what bug # is the stdtool thingy? [14:04] heheh [14:04] * dobey bans standup-by-proxy [14:05] nessita: ah, I need to creat it [14:05] * fagan bans dobey making rules :D [14:05] (oh crap I cant make rules either) [14:05] go get me a danish [14:05] mandel: please do that before working on tasks. Please please please! [14:05] apple, with cinnamon [14:05] and a chai latte [14:06] dobey: yes sir that will take 4-7 working days [14:06] mandel: also, please make the bug reports for the rest of your pending tasks (and use the u1-zomg-windows tag). Thanks! [14:06] nessita: sure [14:06] nessita: when do we mumble? [14:06] mandel: as soon as alecu stops by [14:07] when you're in the pub [14:07] oh [14:07] mumble, the software [14:07] mandel: you need to have lunch? [14:07] mandel: hopefully you already had it :-) (is late there!) [14:07] nessita: yes, but it does not take me long, I'll put the pizza in the oven [14:08] mandel: I think you have at least 30 minutes, so enjoy [14:08] nessita: and spaniards have lunch very late, usually 2:30, 3:00 pm :) [14:08] nessita: I'll be paying attention to irc [14:08] mandel: isnt that because you are sleeping from 11-2 [14:10] good morning, #ubuntuone! [14:10] morning alecu [14:11] fagan: I wake up at 7, so I doubt it [14:11] siesta is *after* lunch [14:12] mandel, got the branch, so I'll work on the tests right now. [14:12] ahhh [14:12] mandel, thanks! [14:12] alecu: hi there. We are having the windows catch up mumble after mandel has lunch [14:12] Chipaca: ^ [14:13] nessita, perhaps we can start 10' before the standard thursday progress meeting. Or do it in the same meeting. [14:13] nessita: or we can have it now if is short (pizza in the oven) [14:14] alecu: I don't think we're having the standard thursday meeting, since ralsina is not around [14:14] alecu, mandel: now or later, as you both wish [14:14] I think is better now [14:14] * alecu is already on mumble [14:14] now :) [14:15] Chipaca: can you make it to mumble now? [14:15] nessita, alecu: I'm launching mumble right now [14:16] nessita: right now i have a web meeting [14:16] Chipaca: you prefer we waiting for you? [14:16] nessita: iwould, yes [14:16] Chipaca: how long is the web meeting? [14:17] nessita: dunno, martin isn't here so dunno [14:17] you're gonna wait until he's back? :) [14:17] Chipaca: np. We 3 are in mumble, so just jump in when you're ready [14:17] Chipaca: you could just declare it over with :) [14:17] Chipaca: speak loud, since you need to beat The Cure singing in the back :-P [14:18] mandel, when you are done pizzaing, here's a branch that can use your review: https://code.launchpad.net/~alecu/txnamedpipes/run-tests-batch/+merge/64747 [14:18] nessita: I'm not gonna join, but if you guys need reviews or anything just tell me, I have work I can do, but I can easily be interrupted [14:18] alecu: cool, looking at it right now [14:18] thisfred: thanks!!! [14:18] thisfred: are you working on windows stuff? [14:18] dobey: not at all [14:19] alecu: why the double cd .. [14:19] mandel, because somehow cd ..\.. [14:19] alecu: you could remember the location where you started the script and get back to it, which is nicer :) [14:19] did not work. [14:19] mandel, like pushd and popd? === m_conley_away is now known as m_conley [14:20] mandel, I would do it, but I can't test it on xp to make sure it works, as I only have a seven vm [14:20] alecu: something like this: http://weblogs.asp.net/whaggard/archive/2005/01/28/get-directory-path-of-an-executing-batch-file.aspx [14:20] alecu: get the current dir of execution, store it in a var, move where ever you want, and then cd to the dir [14:21] alecu: but there is nothing interesting to it, you can leave it like it is :) [14:21] alecu: I was just asking :P [14:21] dobey: any news on the review for u1devtools? [14:22] nessita: i am looking at it right now [14:22] thanks [14:22] mandel, it seems that pushd and popd also work on seven's cmd.exe [14:22] alecu: wanna go down that path then? [14:22] mandel, but I would not worry about that, that script is a POS, and we'll probably be redoing it laters anyway when we have a jenkins running all this. [14:23] mandel, don't know if they work on xp [14:23] alecu: ok, we can forget about it, it work anyway :) [14:23] mandel, http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/pushd.mspx?mfr=true [14:23] mandel, they work on xp [14:24] alecu: could you take a look at the runtest script I did for SSO? there you can find the way to get the path to the pthon executable, your script will only work if the person already has it [14:24] mandel, sure. That's the kind of review I was expecting :-) [14:25] alecu: hehe [14:25] alecu: also reseting the python path to the previous value would be nice ;) [14:29] mandel, !!!! [14:29] mandel, in the run-tests.bat you use PYTHONPATH as the path to python, not to the libraries [14:29] mandel, that sounds very very troublesome. [14:30] mandel, I believe we should change that, or it will give us trouble later. [14:30] alecu: sounds reasonable, is just a s/PYTHONPATH/blahpath [14:31] mandel, I'll make a branch for that on -sso, don't worry. [14:33] alecu: thx!! [14:34] * mandel pizza eating [14:35] nessita: btw, how did you test such that add_signal_handler() created new dbus connections? [14:35] nessita: because i am not seeing that :-/ [14:35] dobey: I'm not following, sorry. add_signal_handler where? [14:36] nessita: you were saying that we need to do this removing of signal handlers in the tearDown because it was creating new connections to the dbus daemon that weren't getting dropped on close(), no? [14:36] at lesat, that's what i understood from your comments yesterday [14:37] dobey: not exactly, what I said was: when creating a new signal receiver, either using proxy.connect_to_signal or proxy.add_signal_handler (or similar name), that signal receiver adds a new entry in the self.bus.list_names [14:38] dobey: if you check the list_names content at tearDown, before flushing and closing, the signal hndler is there. It is removed when closing, but I think is more cleaner to explicitely remove it before closing [14:39] to avoid any possible timing issues, I'm not sure that self.bus.close() blocks until all the cleanup is fully completed [14:39] huh, so i am not seeing that behavior when i do self.bus.add_signal_receiver(); list_names() doesn't get bigger [14:40] dobey: try proxy.connect_to_signal() [14:40] where proxy is a dbus proxy [14:50] mandel, nessita, please review: https://code.launchpad.net/~alecu/ubuntu-sso-client/fix-batch-pythonpath/+merge/64834 [14:51] ack [14:52] hmm [14:56] hey guys, just wondering if there is any slowness on the network, seem to be syncing at around 3kb/s [14:59] alecu: I have that task list done ish and all of the commented out bits out of there [14:59] just have 1 failure and 1 error [14:59] nessita: still the list_names() is not growing for me [14:59] the failure I dont know how to fix though [14:59] fagan, nice [15:00] nessita: alecu: mumble? [15:02] Wow that was loud tunder [15:02] It was like outside my window [15:02] nature's trying to tell you something ;-) [15:04] teknico: yeah its saying im hungry feed me that dog thats barking next door [15:05] "nature says… stfu or gtfo" [15:05] hah [15:07] alecu: hmmm no failure anymore dont really know why that fixed itself but anyway. 2 errors that im not really sure what to do with. When you have some time could you look at i [15:07] *it [15:07] fagan, busy now, sorry. [15:08] alecu: yeah I know when you time no rush === zyga is now known as zyga-food [15:20] dobey: not sure what to answer, it was for me. Even so, I'm not sure why you seem unsure to approve the branch, since removing the signal receivers is part of the expected cleanup, as far as I see. [15:21] nessita: why is it expected? because i didn't remove the list they get added to by some tests, to avoid breaking all those tests right off the bat? [15:23] dobey: by expected cleanup I mean: you create a file, is expected that tearDown will remove it. You create a listener, is expected that listener is unsubscribed. Same for signal receivers. [15:23] anyways, I don have the time to argue about this [15:23] dobey: you can not approve, I'll see what we can do after the 24th [15:24] I meant: you can "not approve" it :-) [15:32] nessita: ok, i needinfoed it, and we can argue later :) [15:32] dobey: thanks [15:33] nessita: ping [15:33] mandel: pong [15:33] nessita: can you look at https://code.launchpad.net/~mandel/ubuntuone-client/working_windows_vm_helper/+merge/64804 [15:34] mandel: yessir [15:34] when possible ofcourse [15:34] in about 15 minutes [15:38] mandel, please, review again the run-tests.bat branch, now based on your code and without hardcoding the name of the folder (it used to be build\lib.win32-2.7, but that name would surely change depending on platform and on python version) [15:38] mandel, https://code.launchpad.net/~alecu/txnamedpipes/run-tests-batch/+merge/64747 [15:38] alecu, on it [15:39] mandel, this one too: https://code.launchpad.net/~alecu/ubuntu-sso-client/fix-batch-pythonpath/+merge/64834 [15:40] alecu: runt-test-batch approved, shall I mark it as approved? [15:41] mandel, no need, just done it. [15:41] alecu: the other one is also ready to be approved [15:41] mandel, cool, thanks. [15:41] np [15:42] mandel, will tarmac merge txnamedpipes? [15:42] no [15:42] alecu: no, it has to be done manually [15:42] is a windows only project :( [15:43] but i want to fix that eventually [15:58] nrn [16:03] Heyo! I am interested in porting ubuntuone-couch to use dh_python2 (as it came up in its MIR and the transition is a release goal). Does anyone here know about efforts to convert the various ubuntuone packages? I'm under the impression that they all need to be changed in lockstep? [16:04] hey mterry :) [16:04] fagan, hi! :) [16:04] thisfred owns that according to lp [16:05] (the project not the porting thing) [16:06] mterry: yes, it is a somewhat difficult problem [16:06] I own u1couch yes, but as to the concerted effort, I don't think so, yet. dobey?^ [16:06] Doesn't mean we won't though [16:06] ah [16:09] thisfred, well, this is blocking my deja-dup MIR, so I have a vested interest. Unfortunately, all the packages have to be done together [16:09] Is there any objection to me going through and working on that across the ubuntuone* packages? [16:10] dobey: wherein lies the difficulty? [16:10] I'd be happy to help, also [16:10] Note http://wiki.debian.org/Python/PythonSupportToDHPython2 [16:11] But there was a question on #ubuntu-devel just now about how to prevent partial upgrades for a set of packages like this that is doing the transition. I'm going to ask on the mailing list for input [16:11] mterry: i think if we should do it, we should do it in nightlies PPA first [16:12] and the hard part is ubuntuone-client, and i think there might be an issue with dh_python2 and the special .pth stuff we do [16:12] not sure though on that [16:16] nessita, alecu: I'll be away from 20 min [16:16] mandel: ack [16:16] bye mandel! [16:16] nessita: Hi Nataly, could you please help me with this: http://paste.ubuntu.com/628024/ [16:16] nessita: I'm trying to call "authenticate" (not working from my Java source), but I can't instanticate SingleSignOnAPI [16:16] it's complaining about BasicAuthorizer, which I took from piston-mini-client [16:17] karni: I never used the piston API, so I don't know what a piston SingleSignOnAPI is :-). You need to ask achuni or pindonga (they both are from ISD and in charge of that) [16:17] nessita: ok thank you [16:18] welcome! [16:19] oh crap a plummer has come to fix my heating need to head off a bit early [16:20] alecu: the branch is at lp:~shanepatrickfagan/ubuntu-sso-client/nm-state-bug-fix get to it when ever you have time and send me an email. Ill get to it around 8pm UTC when im back [16:20] It should get to all of the things on that task list [16:21] be back a bit later then [16:22] fagan, if you are confident about it, propose it for reviewing, from the launchpad page. [16:22] alecu: not confident it still has errors that im not really sure on how to fix [16:22] Its the dbus stuff im pretty sure [16:23] off to get lunch, bbiab [16:24] the code is fine though and its working just something weird is going on. (I think I need to add a mock dbus thingy to a bit to fix it and I tried that but it didnt seem to work right so I pulled it and thats why im asking about it) [16:24] * fagan needs to use better english :) [16:25] anyway be back a bit later [16:26] fagan: alecu: isn't there a proposed branch to fix that already? https://code.launchpad.net/~mterry/ubuntu-sso-client/nm0.9/+merge/63869 [16:26] or is this yet another nm related issue? [16:27] oh nm, I think it is [16:27] thisfred, it seems to fix the same issue [16:28] thisfred, fagan started working on this branch before the london sprint [16:28] I know [16:28] thisfred, so probably there's overlapping work [16:28] I made that branch without being aware of the other [16:28] but continuing on this when it's already fixed seems not all that useful [16:28] I like mterry's solution though. [16:28] me too :) [16:29] So I suggest fagan abandons his, and finds a new issue to work on [16:29] thisfred, I think it's still useful for fagan to keep working on it even though it might not be merged, so he gets more familiar with our process. [16:29] ok [16:29] thisfred, but if there's a better issue for him to work on... I agree. [16:30] yeah, maybe finding one will take as much time as continuing down this path. I'll keep an eye out for more useful work [16:33] mterry: dobey made a branch for ussoc to refactor our tests in ussoc, so we can ask you to add more tests to yours without so much trouble [16:33] dobey: did you talk to mterry about the nm tests? [16:35] nessita, already in the branch [16:35] mterry: great! did you add the tests we were thinking on ask as well? :-D [16:36] nessita, I believe so (added tests for old states as well as new ones) [16:36] nice! [16:36] mterry: need a review? [16:37] nessita, https://code.launchpad.net/~mterry/ubuntu-sso-client/nm0.9/+merge/63869 [16:44] thisfred, pitti just replied to my ubuntu-devel email about dh_python2 and shared a strategy for doing updates asynchronously. So we could just update ubuntuone-couch and leave the rest. I'm willing to do the work, but if you'd rather take it, that's fine with me [16:45] mterry: It may be faster if you do it, but I'll make sure it gets reviewed quickly [16:46] * mterry looks at it [16:46] just ping me with the proposal [16:46] thisfred, cool, thanks [16:47] thisfred, wait, what do you mean proposal? It should just be a debian/ directory change. Would you prefer to review that too? [16:48] ehm, dunno. We have separate packaging branches for everything u1 I think [16:49] which I don't know the review process for. dobey? [16:51] ah, he's gone, anyway [16:51] https://code.launchpad.net/~ubuntuone-control-tower/ubuntuone-couch/packaging-dailies [16:51] is where the packaging branch lives for the nightlies ppa [16:52] If you propose against that, we'll have a chance to test the change in the wild before proposing it for oneiric, I gues [16:52] s [16:54] mandel: review finished, several needs fixing and needs information. PIng me back when those are fixed/answered. Thanks! [16:54] nessita: is that the u1-client branch? [16:55] mandel: yeah, the vm_helper [16:55] nessita: ok, let me fix those [16:55] I'll have lunch soon, after reviewing mterry's branch [16:58] how do I access this from other pc's? [17:01] mterry: approved! [17:01] * nessita -> lunch [17:01] yay [17:21] nessita, mterry: i have a concern about a couple of the NM states and how we're using them [17:22] mterry: so my concern with only converting one thing to dh_python2 is that it will break everything else in ubuntuone, which i'd rather avoid :) [17:22] hrmm [17:23] mterry: so it should be ok in u1 stuff, theoretically; as we already do the magic .pth file stuff [17:28] nessita, mterry: added my concern about _SITE and _LOCAL states to the proposal [17:30] mandel: does working_windows_vm_helper replace provide_window_vm_helper? [17:31] * fagan back [17:39] dobey: yes, is there a problem with that? [17:40] dobey: tat sounds harsher that I intended :) [17:42] mandel: just making sure since you didn't request a review from me :) [17:43] and isn't hasattr() supposed to be evil and you shouldn't be doing that? [17:43] dobey: hmm is that the one that swallows exceptions? [17:44] i think so [17:44] and where you're using it, doesn't seem right anyway, but maybe i'm confused about share_id vs. volume_id in that use case [17:46] dobey: we have the same in the linux code: http://bazaar.launchpad.net/~mandel/ubuntuone-client/working_windows_vm_helper/view/head:/ubuntuone/platform/linux/vm_helper.py [17:49] mandel: eww [17:50] 80 [17:50] else: [17:50] 81 [17:50] share_id = share.id [17:50] when is that ever night the right thing to use? :) === IAmNotThatGuy is now known as M0hi [17:51] dobey: when we build the share path, we use the share id to ensure path uniqueness [17:52] yes [17:52] isn't that what the code is doing? [17:52] but is there ever a time when share.id is not the correct thing to poke? [17:52] it's tryiing volume_id, then share_id, then id [17:53] all attribues on the share object (theoretically) [17:53] dobey: right, but the call is applied on different share objects [17:53] some are share offer, some other are shareresponse, and other is the share as a volume [17:54] ok, but still, hasattr() is evil, no, and we shouldn't be using it? [17:54] dobey: seems like it, though I keep using it as well... [17:55] googling now [17:55] why not do try:/except AttributeError:? [17:56] look! [17:56] a post from Cheepaca http://chipaca.com/post/3210673069/hasattr-17-less-harmful [17:56] dobey: in any case, we should not use try/except but : if getattr(instance, attr, None) is not None [17:57] hmm [17:57] I'm fine with asking changing hasattr to getattr() is not Nonw [17:57] None* [17:57] ok [18:02] dobey: which parameter did I have to pass to use the txnamedpipe reactor in u1dev tools? [18:04] mandel: --reactor=txnp iirc [18:04] dobey: ok, I remember it was something like that, I forgot the np :P [18:05] mandel: whatever the filename in ubnutone/devtools/reactors/ for the module is, is what you pass as the argument to --reactor= :) [18:05] for future easy lookup with ls :) [18:05]