[17:51] <manusheel> shan: Hi Shan.
[17:51] <shan> manusheel, hello sir
[17:51] <manusheel> shan: Around?
[17:51] <shan> manusheel, yes sir
[17:51] <shan> i am here
[17:53] <manusheel> shan: You were able to include the recommendations by alsroot in your patch, except one of them.
[17:53] <manusheel> shan: Your response was quick, which is good.
[17:53] <shan> manusheel, yes sir, i will have a word with alsroot now.
[17:54] <shan> alsroot, hi around?
[17:54] <manusheel> shan: Did you discuss with Aleksey on how you plan to implement the remaining feature?
[17:54] <alsroot> shan: ho
[17:57] <shan> alsroot, hi, i had a look at the pointers provided by you yesterday. but, since downloaded activities show in the journal directly. I see no reason as to why implement a get_journal.resume.
[17:57] <shan> downloaded activities show only up in the journal. *
[17:58] <alsroot> shan: what about resuing from journal palette or from pasting an .xo from clipboard
[18:00] <shan> alsroot, i could be wrong here, do correct me if i am. Even after pasting it has to be launched from the journal.
[18:01] <alsroot> shan: on pasting journal execs misc.resume thus downgrading will silently skipped
[18:02] <alsroot> s/pastings/resumed-from-palette-or-from-details-dialog/
[18:03] <shan> execs?
[18:03] <alsroot> shan: executes
[18:07] <shan> alsroot, okay. having a look now. get back to you in some time. So, that will be the only issue right?
[18:08] <alsroot> shan: the issue is simple, instead of adding alert to 3 places(and possible new resume invocations), better to have it in resume()
[18:14] <shan> alsroot, so basically what i should try to implement is  "try not using listview.py and somehow get the pop-up alert to be started from misc.resume "
[18:15] <shan> alsroot, would that be a much appropriate approach?
[18:16] <alsroot> shan: not from misc.resume, it can't import activity class (to avoid circle dependencies), as I said, I can't find better option than moving misc.resume to journal activiity class method
[18:21] <shan> alsroot, i think i got your idea. This wouldn't be involving changing misc.resume to get_journal.resume ?..would it?
[18:22] <alsroot> shan: what I meant is just moving misc.resume() to JournalActivity.resume, get_journal() is just a method to get JournalActivity instance
[18:22] <mukul> alsroot: Does sugar crash whenever an unhandled python exception occurs? Then 2063 doesn;t make much sense.
[18:24] <alsroot> mukul: afaik it doesn't
[18:25] <mukul> alsroot: Can I test that?
[18:25] <alsroot> mukul: just grep for all alert invocations in sugar prokect sources
[18:27] <alsroot> mukul: oops, sugar can be aborted on exception while launching
[18:27] <alsroot> mukul: but after that, all unhandled exceptions will be just logged
[18:28] <alsroot> ..it is not sugar specific but regular glib/gtk behaviour because exceptions could be thrown only as reaction on glib event
[18:31] <mukul> alsroot, Ok I get it.
[18:32] <alsroot> mukul: forget about alert invocations, I jsut misread ticket
[18:34] <manusheel> alsroot: Making changes at sugar.logger APIs won't help?
[18:35] <alsroot> manusheel: yeah, looks like, there is excepthook
[18:36] <manusheel> alsroot: Ok, then, we should be able to resolve it by introducing changes at the Sugar API level.
[18:38] <alsroot> manusheel: why? just doing some stuff in excepthook w/o API changes
[18:39] <manusheel> alsroot: Ok, that was a proposal. Great, if we can do changes using the excepthook without API changes, that would be great.
[18:41] <shan> alsroot, yes, yes. sorry i mistyped. But will we be moving misc.resume() to JournalActivity.resume everywhere? or only in listview.py?
[18:42] <shan> by everywhere, i mean all those places, where misc.resume() is invoked. We would not be doing that right? ( i am asking this just to confirm the thought process )
[18:44] <manusheel> mukul: Did you discuss with alsroot on the excepthook available to us at the Sugar level?
[18:44] <mukul> manusheel: No. a
[18:44] <alsroot> shan: since misc.resume will be moved to JournalActivity.resume, you need to change all misc.resume invocation (might look invasive but this fix will go to 0.92 I guess)
[18:46] <mukul> alsroot: Can you guide me on this excepthook feature?
[18:47] <alsroot> mukul: see python docs for sys module
[18:51] <shan> alsroot, that would mean, that misc.resume will never be required again and instead wherever it was to be called JournalActivity.resume should be called in its place. This will take considerable time too. Also, in all places where this is to be done importing of JournalActivity (and others if any ) will be required. right?
[18:52] <alsroot> shan: yup, in all this code import journal.misc anyway so importing another journal module is not a problem
[18:53] <shan> yes, that won't be a problem, will do that. Thanks a lot. I will try this out immediately and will get back to you in a while.
[19:19] <mukul> alsroot: How can excepthook by used for Bug 2063?
[19:19] <ubot2> Launchpad bug 2063 in launchpad-foundations "Trying to reach upstream of a package gives me an error" [Medium,Fix released] https://launchpad.net/bugs/2063
[19:20] <alsroot> mukul: thats the question, anyway if you need a hook for unhandled exceptions, excepthook is the option