« Previous day | Index | Today | Next day » Channels | Search | Join
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
01:30 | timClicks has quit IRC | |
03:17 | manusheel is now known as manusheel_afk | |
05:26 | manusheel_afk is now known as manusheel | |
07:07 | mukul_afk is now known as mukul | |
07:41 | ayushg <ayushg!~ayushg![]() |
|
07:42 | ayushg | manusheel: sir i m having problem with xo its not booting and giving a 'Boot failed' error message at startup |
07:49 | mukul is now known as mukul_afk | |
08:36 | ayushg | alsroot: the nand of my xo is showing too many bad blocks can it be fixed |
08:37 | alsroot: xo can't boot nor can i reflash it as there are not enough good blocks | |
09:07 | ayushg has quit IRC | |
09:08 | ayushg <ayushg!~ayushg![]() |
|
09:40 | manusheel is now known as manusheel_afk | |
09:53 | ayushg has quit IRC | |
10:55 | kaare_alt has quit IRC | |
11:13 | shan <shan!7aa291e0![]() |
|
11:32 | shan_ <shan_!7aa291e0![]() |
|
11:45 | shan has quit IRC | |
11:55 | shan_ <shan_!7aa291e0![]() |
|
12:00 | mukul_afk is now known as mukul | |
12:18 | shan_ | mukul: around? |
12:23 | mukul is now known as mukul_afk | |
13:00 | manusheel_afk is now known as manusheel | |
13:05 | manusheel | alsroot: Hi Aleksey. |
13:05 | Around? | |
13:05 | alsroot | manusheel: hi |
13:06 | manusheel | alsroot: How are you doing today? |
13:06 | alsroot | manusheel: fine, how are you |
13:07 | manusheel | alsroot: Very well, thank you. |
13:08 | alsroot: Wish to ask you if you could review the patch submitted on SL #2164 by Shanjit - http://lists.sugarlabs.org/arc[…]tober/027579.html. Please let me know if you see any error in it. It has been 3+ days, and we haven't received a review on it. | |
13:10 | alsroot | manusheel: will do |
13:10 | manusheel | alsroot: Thank you Aleksey. |
14:25 | ayushg <ayushg!~ayushg![]() |
|
14:33 | manusheel | alsroot: Thanks for the feedback on the patch. Appreciate it. |
14:34 | alsroot | manusheel: dunno was patch workflow settled down or not, but CCing maintainers could be useful in some cases :) |
14:37 | manusheel | alsroot: Yes. We have started doing that. Not sure, whether the patch workflow has been settled or not. |
14:38 | alsroot: Thanks for the pointer. Aleksey, there are many of our patches that are lying on sugar-devel unreviewed. | |
14:38 | alsroot: Should we re-send them to the maintainer, CCing sugar-devel. | |
14:38 | alsroot | manusheel: well, I'm not sure how other people will consider CCing (even if they are maints) |
14:55 | anuragc <anuragc!~anurag![]() |
|
14:57 | manusheel | alsroot: Ok. |
14:57 | anuragc: Hi Anurag. | |
14:57 | anuragc | hell o sir |
14:58 | manusheel | Did you get a workaround for SL 2080? |
14:59 | anuragc | yes , i now understand the point that daniel pointed out , but nonetheless when applied practically the solution we have tried seems to improve the situation |
14:59 | manusheel: i will work this issue from the different and newly understood angle now | |
15:00 | manusheel | anuragc: Can you elaborate on your approach? |
15:00 | anuragc | manusheel: but it would be great if someone else can also test the previous change on their XO |
15:00 | manusheel: sure | |
15:01 | manusheel: I think modifying any thing in the icon characteristics wont solve anything | |
15:01 | manusheel | anuragc: Ok. |
15:01 | anuragc: Where will you be making changes then? | |
15:01 | anuragc | manusheel: as we have to counter the delay which is part of the preprocessing directive of the pulsing icon |
15:02 | so we need to cut on the processing on the tasks that take place just before the start of the pulsing icon | |
15:02 | manusheel | anuragc: Ok. At the code level, what does that lead to? |
15:02 | anuragc | and if to put it in technical terma we need to check the processes(loops and conditions) that are invoked just before the function call of the pulsing icon |
15:03 | manusheel | anuragc: Ok. |
15:03 | anuragc | manusheel: i think i can work around this tonight and we can have a patch in a better approach |
15:03 | manusheel | anuragc: Which methods are you planning to modify? |
15:03 | anuragc: Sure. | |
15:04 | anuragc | manusheel: that is the part to be determined now , i.e. which are the portions that need to be modified |
15:04 | manusheel: Also i got to know that the nand memory of Ayush's XO has gone bad | |
15:05 | so his xo is not booting now | |
15:05 | manusheel | anuragc: Ok. Ask him to write an e-mail about it at devel![]() |
15:06 | anuragc | manusheel:sure |
15:08 | shan_ has quit IRC | |
16:17 | manusheel | anuragc: Around? |
16:17 | anuragc: Let us discuss the final action plan on SL 2080 now. | |
16:18 | anuragc | manusheel: yes , sure |
16:18 | manusheel | anuragc: Are you ready with your analysis? |
16:19 | anuragc | manusheel: i was now working in the launchey.py in jarabe.view because it is where the animator.py is imported and the function is called for setting up the pulsing icon .py |
16:21 | manssheel: so i think that i have tp make the changes in this file to get it done in the right way , i cant see any sort of memory heavy task being done in this part of the code , by memory heavy i will count caclulations or recursive function calls | |
16:21 | but our only lead to solve this bug is to reduce the memory usage just before the pulsing icon starts | |
16:23 | manusheel | anuragc: Ok. |
16:23 | anuragc: Did you get an idea on how to do that? | |
16:23 | anuragc: Also, did you have a word with Bernie on it? | |
16:24 | anuragc | well , my idead was to lower the recursions or calculation that we find in this pre operation part but there is no such operation that was present there |
16:24 | well last time i had a word with him he was also clueless at this matter and whatsoever our last patch was madde incorporating his ideas only | |
16:25 | i would be back in 15 mins . Going to have dinner | |
16:25 | manusheel | anuragc: Ok. I just pinged him. Please be back in 15 minutes. |
16:26 | anuragc: Join our conversation at #sugar. | |
16:26 | ayushg: Did you go through the patch for SL 2064? | |
16:27 | ayushg | manusheel: sir do u mean 2164 |
16:29 | manusheel | ayushg: Yes, did you look at both 2164 and 2080? |
16:30 | ayushg | manusheel:sir i looked at 2080 in jhbuild but nothing significant is observed |
16:30 | manusheel:i forgot to look at 2164 | |
16:33 | manusheel:i will look at it ryt now | |
16:33 | anuragc has quit IRC | |
16:33 | anuragc <anuragc!~anurag![]() |
|
16:34 | anuragc | manusheel: sir i am back , lets continue our discussion |
16:34 | manusheel | anuragc: Sure. |
16:35 | anuragc | manusheel: so i was saying that , i my opinion the only points in a program that are processor intensive are where we do calculations or where we do repititive tasks like recursions |
16:36 | manusheel | anuragc: Ok. That is agreed. But, we do need to find the functions for the same. |
16:36 | anuragc: Let us try to dig a solution out. | |
16:36 | anuragc | manusheel: because they are the only points where the load could be reduced by taking alternative paths , at other points any reduction would come at cost of a feature that we dont want |
16:38 | manusheel: because if we look at class launchbox and function __init__() we can see that it is the point where the launch process starts | |
16:39 | manusheel : above class is to be found in jarabe.view.launcher.py | |
16:41 | manusheel | anuragc: Right. But, how do we take care of the starting frame? |
16:42 | anuragc: Daniel clearly mentioned that the starting frame was not taken into consideration/ | |
16:44 | anuragc | manusheel: actually what i found out is that here the process starts like a cycle of pulsein and pulse out, and continues in this cyclic order and tahts why we cant partcularly point out the starting frame , we have to take care of the things just before the commencement of the animation , that is the only way to take care of the starting frame as , here we have only two frames that repeat in an cylic order one after another |
16:45 | manusheel: that is the reason we were working out in the calculations pertaining to those two frames | |
16:45 | manusheel: in the last patch | |
16:47 | manusheel: since modifying any frame wont work , because here our situation is like this A B A B A B A B A where A and B are our two frames in the cyclic order , so if we change any thing in A then it affects the whole cycle and If we change any thing in the mid cyle that will affect the start too | |
16:48 | shan12 <shan12!~cuil![]() |
|
16:51 | manusheel | anuragc: Can you reply back to Daniel and copy sugar-devel on it? |
16:52 | anuragc | anuragc: sure i plan on doing so |
16:52 | manusheel | anuragc: I do get your analysis. We should explain what we were trying to do, and ask if there is a better approach for the same. |
16:52 | anuragc | anuragc: yes ,sure |
16:53 | manusheel | anuragc: Do copy James Cameron on it too. Kindly send me the e-mail for review before sending this one to sugar-devel. Wish to make sure that we are very clear on our explanation. We need to explain in detail. |
16:53 | shan12 has quit IRC | |
17:01 | ayushg | manusheel: sir i hv applied the patch submitted by shan on my jhbuild but it doesn't seems to be working |
17:03 | mukul_afk is now known as mukul | |
17:08 | anuragc | manusheel: sir i have sent you the mail that i intent to send to james , daniel and suar-devel |
17:08 | sugar* | |
17:18 | ayushg | mukul: hi |
17:18 | mukul | ayushg: hi |
17:24 | shan12 <shan12!~cuil![]() |
|
17:25 | ayushg | mukul: let's get started on 2063 |
17:26 | mukul: i was talking about it to manusheel sir | |
17:26 | mukul: he sugested it needs to be implemented on API level | |
17:27 | mukul: coz a process as such will require itself to be continously running and independent from other processes | |
17:27 | mukul: i suggest that we create it using pygtk rather than relying on alert classes | |
17:34 | ayush_ <ayush_!~ayushg![]() |
|
17:36 | ayushg has quit IRC | |
17:38 | ayush_ is now known as ayushg | |
17:41 | ayushg | alsroot: hi |
17:41 | mukul | ayushg: That is fine. Raising alerts is the 2nd part. First we need to concentrate on something that helps us read the logs. |
17:41 | alsroot | ayushg: hi |
17:43 | ayushg | alsroot: is there a way using which we can access every new line being outputted to shell.log in programming |
17:45 | alsroot | ayushg: you mean reading shell.log content? |
17:47 | ayushg | ayush:yeah |
17:47 | alsroot: yes | |
17:47 | alsroot | ayushg: you file object, http://docs.python.org/library[…]html#file-objects |
17:47 | *use | |
17:48 | ayushg | alsroot: is there any other way of using it besides file handling |
17:49 | alsroot | ayushg: shell.log is just a file, so you can read it as any other files |
17:50 | ayushg | alsroot: ok |
17:51 | mukul | shan12: Are you done with your packaging? |
17:52 | anuragc | alsroot: hello |
17:53 | alsroot | anuragc: hi |
17:53 | shan12 | mukul, nope.have some problem with that. will talk about it tommorow |
17:54 | mukul | shan12: Ok. I recommend you to go through the procedure I had mailed. It has been simplified to save time. |
17:54 | shan12 | mukul, okay. i did that. still have some problem. will call up and ask you tommorow |
17:54 | mukul | shan12: ok |
17:56 | anuragc | alsroot: i was working on bug #2080 (Pulsing icon delayed by 5 seconds or so) , i also submitted a patch for this , But i have some problems regarding this bug which i have pastebinned at http://pastebin.com/x6U6jM1y |
17:56 | alsroot: can you please have a look at it and provide me some tips | |
18:01 | alsroot | anuragc: it could be not trivial to "fix", because proper fix might be reimplementing pulse algorithm |
18:01 | ..to decrease cpu consumption | |
18:04 | anuragc | alsroot: true, i tried fixing the pulsing mechanism in my first patch but however the delay is caused by load on processor ude to processes that are running before the start of the pulsing icon so i recieved poinetrs on my patch to take care of things happening before the first frame of animation appear because after that any change wont affect the preceding delay |
18:04 | mukul | alsroot: How are exceptions reported in logs.... as ERROR...? |
18:06 | alsroot | mukul: use logging.error() |
18:06 | mukul | alsroot: Thanks |
18:09 | shan12 | alsroot, hi around? |
18:09 | alsroot | shan12: yup |
18:10 | shan12 | alsroot, hi, thanks for the review on my patch. there are a few things which i would be requiring pointers for. |
18:10 | alsroot | anuragc: sorry, I have no ideas |
18:11 | shan12 | firstly, i don't see how i can implement the alert notification inside misc.py . I mean since there isn't gtk used anywhere there, there is no way of introducing it |
18:12 | there is no window, in misc.py . So no way to introduce the alert icon there. | |
18:13 | alsroot | shan12: use journalactivity.get_journal() to get journal instance |
18:16 | shan12 | alsroot, but journalactivity.py imports misc.py. Not the other way round. |
18:21 | anuragc | alsroot: no problem, Appreciate your pointers |
18:23 | alsroot | shan12: well, in my mind having code in every misc.resume() invocation will be less useful rather then fixing import issue |
18:34 | shan12 | alsroot, i could not get you . fixing the import issue? there seems no reason to do that. journalactivity.py has to import misc.py , to actually launch any activity, and changing that would require a big effort |
18:36 | alsroot | shan12: not sure if adding an alert to 10 place in code sounds less efforts |
18:40 | shan12 | alsroot, do correct me if i am wrong. Shouldn't all alerts to be displayed in journal activity be put into journalactivity.py ? The reason for this being it is the final window displaying to the user |
18:40 | alsroot | shan12: yup |
18:41 | shan12 | alsroot, and that is what i have tried to implement. |
18:43 | alsroot | shan12: the simplest way could be just passing journalactivity object to misc.resume |
18:44 | ..but maybe not so useful way | |
18:50 | shan12: btw there are 6 misc.resume() invocations in the journal code | |
18:54 | shan12 | alsroot, yes, are you thinking of importing journalactivity to misc.p/y |
18:54 | misc.py? | |
18:56 | alsroot | shan12: nope, misc could have something like set_alert_window() method to store window object for later usage and add_alert() to raise an alert in journal |
19:03 | shan12: or better, implement activitywindow.py with parent window class and implement activitywindow.add_alert() that will use privetly stored activity object to popup an alert | |
19:03 | s/activity object/window object/ | |
19:06 | shan12 | alsroot, okay, having a look at possible solutions |
19:31 | mukul is now known as mukul_afk | |
19:38 | anuragc has quit IRC | |
20:12 | shan12 | alsroot, don't you think the pointer provided by you is almost similar to what the patch tries to implement? The only difference being that journalactivity import a window from misc.py now, whereas earlier it was just checking the values(checked & checker) in misc.py and based on them showing the alert. |
20:17 | alsroot | shan12: the difference is that the logic scattered between misc.resume and misc() invocation (not all) |
20:17 | ..in your patch | |
20:19 | shan12: btw, if I got it right, patch covers only one usecase (from list journal), there are at least two files that invoke misc.resume() | |
20:24 | shan12 | the other is favouritesview.py. |
20:25 | alsroot | shan12: expandedentry.py and palettes.py |
20:30 | tabs <tabs!~Tabitha![]() |
|
20:35 | shan12 | alsroot, what if in misc.resume, if a signal be emitted? and that be caught by journal activity ?, and that signal could activate the alert box code? just a suggestion. |
20:40 | alsroot | shan12: but you don't have an object to emit event for, so you need to pass the activity or create "resume" signal for activity or create Activity.resume() instead of misc.resume |
20:41 | shan12: maybe, at the end, create JournalActivity.resume() will be most useful | |
21:00 | shan12 | alsroot, could you please explain what part of the code would JournalActivity.resume will execute ? |
21:01 | alsroot | shan12: just moving misc.resume to JournalActivity.resume, so you will have a window to add alert |
21:09 | ayushg has quit IRC | |
21:11 | shan12 | okay, got it. So, basically , since misc.resume is used at almost every other place, we will basically limiting ourselves only to a limited part by calling JournalActivity.resume and not misc.resume. correct? |
21:11 | be limiting* | |
21:12 | alsroot, okay, got it. So, basically , since misc.resume is used at almost every other place, we will basically limiting ourselves only to a limited part by calling JournalActivity.resume and not misc.resume. correct? | |
21:13 | alsroot | shan12: the rest of code will just call get_journal().resume instead of misc.resume |
21:19 | walterbender <walterbender!~chatzilla![]() |
|
21:45 | shan12 has quit IRC | |
21:53 | shan12 <shan12!~cuil![]() |
|
21:55 | shan12 | alsroot, here's what i am trying to do. in listview.py on clicking an icon. control is transferred to get_journal.resume , instead of misc.resume. get_journal.resume has same implementation as of misc.resume |
21:57 | alsroot, sounds good? | |
21:59 | alsroot | shan12: there are more places where misc.resume is used (including out-of-journal code) |
21:59 | ..not only listview.py | |
22:00 | shan12 | alsroot, yes , so i am assuming there too a change from misc.resume --> get_journal.resume will be required. |
22:02 | alsroot | shan12: ok then |
22:30 | tabs has quit IRC | |
22:34 | tabs <tabs!~Tabitha![]() |
|
22:40 | shan12 has left #sugar-newbies | |
22:40 | shan12 has quit IRC | |
23:21 | tabs has quit IRC |
« Previous day | Index | Today | Next day » Channels | Search | Join