Flip clock pre pre pre pre release - Page 11 - maemo.org

Active Topics

Firefox with Leste (10)
to Maemo 7 / Leste by teroyk - 3 days, 23 hrs ago
more...

Page 11 of 67

Thread Tools

	daperl	2009-01-08 , 00:00
	Posts: 2,427 \| Thanked: 2,986 times \| Joined on Dec 2007	#101

Originally Posted by danramos

Rather than sleeping as a way of freeing up CPU cycles and checking every minute (I'd also immediately considered drifting and imprecision as issues if this is implemented), is there a way to use a system interrupt based library to run the update code every time the system's clock has incremented the minute? I'm not familiar with programming in python, but I would assume this would mean using a library that deals with the HAL (Hardware Abstraction Layer) interface? This would offload the work from the app and leave it up to the operating system to run the routine as an event.

Syncing in user space should be simple. The following psuedo code would cost very little and makes the reasonable assumption that sleeping will take no less than 60 seconds and no more than a 120 seconds.

Code:

def clock_update():
  while not_done:
    now = get_system_time_in_seconds()
    update_clock (now)
    sleep_time = 60 - now MOD 60
    sleep_for_seconds (sleep_time)

clock_update_thread = threading.Thread (target=clock_update)
clock_update_thread.start()

__________________
N9: Go white or go home

Quote & Reply |

The Following 2 Users Say Thank You to daperl For This Useful Post:
danramos, Faz

	danramos	2009-01-08 , 00:11
	Posts: 4,672 \| Thanked: 5,455 times \| Joined on Jul 2008 @ Springfield, MA, USA	#102

Originally Posted by daperl

Syncing in user space should be simple. The following psuedo code would cost very little and makes the reasonable assumption that sleeping will take no less than 60 seconds and no more than a 120 seconds.
Code:
def clock_update():
  while not_done:
    now = get_system_time_in_seconds()
    update_clock (now)
    sleep_time = 60 - now MOD 60
    sleep_for_seconds (sleep_time)

clock_update_thread = threading.Thread (target=clock_update)
clock_update_thread.start()

Oooo.. true.. true. This would still use sleep, free up CPU cycles AND consistently keep the clock very reasonably accurate. This goes around the whole need for dillying with interrupts.

Simple and effective.

I love it.

Quote & Reply |

The Following User Says Thank You to danramos For This Useful Post:
Faz

	daperl	2009-01-08 , 00:24
	Posts: 2,427 \| Thanked: 2,986 times \| Joined on Dec 2007	#103

Originally Posted by danramos

Oooo.. true.. true. This would still use sleep, free up CPU cycles AND consistently keep the clock very reasonably accurate. This goes around the whole need for dillying with interrupts.

Simple and effective. I love it.

Something similar could be used for accurate alarm threads. Multi-alarm cooking timers could be things of the past.

__________________
N9: Go white or go home

Quote & Reply |

jolouis	2009-01-08 , 14:23
Posts: 631 \| Thanked: 837 times \| Joined on May 2007 @ Milton, Ontario, Canada	#104

Originally Posted by daperl

Syncing in user space should be simple. The following psuedo code would cost very little and makes the reasonable assumption that sleeping will take no less than 60 seconds and no more than a 120 seconds.
Code:
def clock_update():
  while not_done:
    now = get_system_time_in_seconds()
    update_clock (now)
    sleep_time = 60 - now MOD 60
    sleep_for_seconds (sleep_time)

clock_update_thread = threading.Thread (target=clock_update)
clock_update_thread.start()

Interesting, see I started picking at the code yesterday with the aim of helping out by getting the whole "don't do anything while the tablet is inactive" thing sorted out. I'm not a big python person (in fact some parts of it drive me crazy compared to other languages, but that's just me!), but I'm really interested in this project so I wanted to try and help. See I just took Ciro's updated code and adapted the logic so that it makes sense... If you look at his last post he started with:

Code:

ctime = 
time.ctime()
pygame.time.set_timer(DRAW_CLOCK_EVENT,(60-int(str(ctime[17])+str(ctime[18])))*1000)

Which is brilliant, causes the event to fire at exactly the correct time; the only thing I found odd was that he then went on to fire the event every 60 seconds after that, instead of using the same calculation to fire it at exactly the right time. So he suggested:

Code:

 if timesixty == False:
      pygame.time.set_timer(DRAW_CLOCK_EVENT, 60000)
      timesixty = True

But really that doesn't make sense... why not just do the proper time adjusted calculation each time the clock updates? That way it's always accurate... and it's one call to the ctime() method, so not exactly CPU intensive or anything. So my version ended up with the if statement looking like this:

Code:

 elif event.type == DRAW_CLOCK_EVENT:
    #Clear the current timer
    pygame.time.set_timer(DRAW_CLOCK_EVENT, 0)
    
    if ci.fcmode==0:                      #Redraw the clock only
      ci_gfx.drawclock()                  #  when is visible
    else:
      ci_gfx.drawalarm()                # no need to redrawm, anyway in not cheap
	
	#recalculate time until next second and reset delay as required
    ctime = time.ctime()
    pygame.time.set_timer(DRAW_CLOCK_EVENT, (60-int(str(ctime[17])+str(ctime[18])))*1000)

Everytime the update runs it clears the old timer value (just incase soemthing odd happens during the update? I'm not 100% sure about the functionality of the set_timer method as I'm thinking along the lines of JavaScript's setInterval), then once the update has completed the timer is recalculated (that way the wait is accurately calculated again AFTER all potentially time-consuming code has been run).

Basically the same sort of solution, just a different way of going about it. Second point though... I tried implementing the power notification stuff using the osso module, but seem to have run into the same problems as others found when developing maemoClock, etc: set it all up just before the while True loop like this:

Code:

def state_cb(shutdown, save_unsaved_data, memory_low, system_inactivity, 
    message, loop):

    print "System Inactivity: ", system_inactivity
    if system_inactivity:
        #Clear the current timer
        pygame.time.set_timer(DRAW_CLOCK_EVENT, 0)
    else:
        #make the update and stuff happen now
        pygame.time.set_timer(DRAW_CLOCK_EVENT, 10)

    return False


osso_c = osso.Context("flip_clock", "0.7", False)
device = osso.DeviceState(osso_c)
device.set_device_state_callback(state_cb, system_inactivity=True, user_data=None)

Which in theory should work... when system is inactive it causes the event looper to abort, preventing any kind of screen refresh/update; and when it becomes active again the screen refresh/update is restarted almost immediately. However the callback never gets executed. A lot of googling later has indicated that there's something more to the problem here... I think it's something to do with the pygame.event.wait() call, but I tried swapping that out for just some sleep and pygame.event.get() setups and it still never actually gets called. Perhaps some kind of thread or something is needed?

Great app though, awesome work to everyone involved!

Thanks,
-Rob

Quote & Reply |

The Following User Says Thank You to jolouis For This Useful Post:
Faz

	ciroip	2009-01-08 , 14:29
	Posts: 334 \| Thanked: 366 times \| Joined on Nov 2008 @ Italy	#105

It seem I ll have a really busy weekend catching up all the suggestions and comment of the past 10 days. Time to reach a real computer (I followed the thread using only the N810 for a while) and Ill put my hand in the flipclock muddy code. Before leave for the xmas/newyear break I tried to use the pybattery status as a modules (and showing a progress bar of the status) and it seem working just fine. Again Ill keep the thing as modular as my poor python skill will allow so there should be no problem testing all the different technics proposed on the forum. The thread obviously grown over my aspectative and I can feel the pressure

. It is amazing how a 'simple' application trigged so many great 'spinoff' arguments. I m flattered and before return to work I just want to say thank you to all people who spent time to look at the thing.
Since is 'real'work in progress (Im still not sure if the clock and the alarm works

, and this for a clock/alarm program is probably bad...) I thinked that the app didnt deserve a debianizing (and since I write using shortcuts, tricks, weirdo technics is a pain to try to packagin it everytime (I still have no clue and since now qwerty12 made up all the packagings, and make realize that is not a so simple task. I ll try to release the long promised plain naked optimized version and ask to qwerty12 to do the job and ask to the maemo folks to promote to extra and give to everyone on the thread the credits they deserve and have the satisfaction to see the thing finally in the wild.
Peace and love, peace and love

Quote & Reply |

The Following 4 Users Say Thank You to ciroip For This Useful Post:
danramos, Faz, qwerty12, timsamoff

jolouis	2009-01-08 , 14:41
Posts: 631 \| Thanked: 837 times \| Joined on May 2007 @ Milton, Ontario, Canada	#106

Glad to hear that you're back on the job there Ciro! Nice to know you got the pybattery stuff going as well, that will certainly make things better! I'd found some suggestions about utilizing the power management/monitoring stuff from Kagu as well; not sure how much they overlap, but the Kagu one seems pretty extensive:
http://kagumedia.com/projects/kagu/b.../kagu/maemo.py

Thanks again for this awesome app, looking forward to seeing the full final working version with integrated system alarmd functionality and full power management (lol and maybe a way to exit without having to manually issue a kill command at some point!)

Quote & Reply |

The Following User Says Thank You to jolouis For This Useful Post:
ciroip

	qwerty12	2009-01-08 , 15:36
	Posts: 4,274 \| Thanked: 5,358 times \| Joined on Sep 2007 @ Looking at y'all and sighing	#107

Originally Posted by ciroip

Since is 'real'work in progress (Im still not sure if the clock and the alarm works , and this for a clock/alarm program is probably bad...) I thinked that the app didnt deserve a debianizing (and since I write using shortcuts, tricks, weirdo technics is a pain to try to packagin it everytime (I still have no clue and since now qwerty12 made up all the packagings, and make realize that is not a so simple task. I ll try to release the long promised plain naked optimized version and ask to qwerty12 to do the job and ask to the maemo folks to promote to extra and give to everyone on the thread the credits they deserve and have the satisfaction to see the thing finally in the wild.
Peace and love, peace and love

I have become really lazy (and I do apologize) and have kinda let this slip to the side regarding packaging. If you get out a version that you want packaged, let me know here or on IRC and I will package it.

Quote & Reply |

The Following User Says Thank You to qwerty12 For This Useful Post:
danramos

	ciroip	2009-01-08 , 15:59
	Posts: 334 \| Thanked: 366 times \| Joined on Nov 2008 @ Italy	#108

Originally Posted by qwerty12

I have become really lazy (and I do apologize)

You know qwerty12 that you are giving a great service to the project and to the entire nokia tablet scene. My main concerne is not wasting your time and as you noticied all the previous releases were pretty experimental and they didnt 'deserve' the deb. The raw compressed sources release worked fine (and probably even better than the deb for checking the code since everything were at the same place) but it's a joy to see an application packaged with the icon placed int the menu

So no need to apologize and hope everyone spent some nice holydays.

Quote & Reply |

The Following 3 Users Say Thank You to ciroip For This Useful Post:
danramos, Faz, qwerty12

	ciroip	2009-01-08 , 16:51
	Posts: 334 \| Thanked: 366 times \| Joined on Nov 2008 @ Italy	#109

Originally Posted by jolouis

I'd found some suggestions about utilizing the power management/monitoring stuff from Kagu as well;
http://kagumedia.com/projects/kagu/b.../kagu/maemo.py

... with integrated system alarmd functionality and full power management ...

at a 1st look the kagu works seem empressive, Ill cross check everythin and see how much i will understand about the entire topic.
I am waiting for someone came up with a comment about the advantages to use the alarmd. My (limited) experience is that the daemon is not really reliable. It hang and there is no easy way to be sure if the thing is running or whatever. My actual approach here is: if the application is running the alarm works, otherwise 'ciccia', no alarm. Maybe Im missing something (im really far from being a linux expert) so, in case noone will showup with something convincing to try to use the alarmd ill keep comparing the alarm variable setted directly from inside the clock.
PS Ill think a decent way to kill the app...

Quote & Reply |

The Following User Says Thank You to ciroip For This Useful Post:
Faz

jolouis	2009-01-08 , 19:02
Posts: 631 \| Thanked: 837 times \| Joined on May 2007 @ Milton, Ontario, Canada	#110

Originally Posted by ciroip

I am waiting for someone came up with a comment about the advantages to use the alarmd. My (limited) experience is that the daemon is not really reliable. It hang and there is no easy way to be sure if the thing is running or whatever. My actual approach here is: if the application is running the alarm works, otherwise 'ciccia', no alarm.

Utilizing alarmd gives you a lot of very handy and awesome benefits compared to just setting the alarm within your app; from my understanding of it by using the alarmd interface:
- Your app doesn't have to be running for the alarm to occur. You can actaully setup the alarm to launch your app if you want, so that when an alarm goes off the clock app will open if it's not there already.
- Alarmd will continue to run and trigger events at all power states of the tablets. This is important as it relates to your power savings features. If you implement proper power savings when the tablet goes into idle (not used), your application should literally stop doing anything so that the tablet can save power; it's awefully difficult to keep checking the time and comparing it to the given alarm schedule though if your app isn't doing anything, so the only way to make it work would be to have your app continue to run at some level, which wastes power.
- Alarmd has the added ability to trigger alarms even when the tablet is "off" mode... that is, if you set and alarm and turn the tablet off, put the tablet on charge, the alarm will still execute normally. Good for those times when you have something like a daily alarm, and one night have your tablet off and forget to turn it on... alarm will still run.

I'm sure there are other reasons, but from my understanding of it those are the obvious ones. The biggest point, of course, is that whole alarms will still run even if your clock is not. This is a major point. Think of it this way... if you set an alarm, then do some other stuff on the tablet (surfing the web, reading an ebook etc) before going to sleep and forget to switch back to the flipClock, your alarm will never go off! If you implement alarmd functionality then in this same scenario you can make the tablet automatically change to the flipClock app (and even open it if you had closed it before), and handle the alarm as expected.

Quote & Reply |

The Following 9 Users Say Thank You to jolouis For This Useful Post:
ciroip, danramos, daperl, Faz, fredoll, Jaffa, nilchak, RogerS, timsamoff

Page 11 of 67

Active Topics

Firefox with Leste (10)

Notices