IRC Logs for #circuits-dev Saturday, 2013-02-02

mehereLooks ok.02:18
prologiccool02:54
mehereHI, prologic. Currently, every timer has its own generate_events, so if you have 100 timers (I have a lot in my application) you have 100 handlers for GenerateEvent. The "new" implementation has only a single generate_events in the scheduler, because it maintains a list of timers sorted by expiry time.02:59
prologic*nods*03:02
prologicrightio03:02
prologicbit like how I optimized the wsgi.Gateway to handle multiple apps03:02
prologicyeah I'm okay with this03:02
prologicobviously :)03:02
prologicI thought by more "efficient" it was going to be something more fancy03:03
prologiclike using signal.itimer or such03:03
prologicwhich isn't cross platform :/03:03
mehereRight, I only hat to merge the comments. Which makes me wonder what a story with "0" is.03:31
prologicwell 0 shouldn't even be there03:41
prologicheh03:41
prologicmost scrum estimation schemes don't have 003:41
prologic1, 2, 3, 4, etc03:41
prologic1, 2, 3, 5, 8, 13, etc03:41
prologic2, 4, 6, 8, 10, etc03:41
prologicI accepted it03:42
prologicas long as the tests pass03:42
prologiclooks like they do so  :)03:42
prologicstill have 6 failing windows tests03:43
prologichoping Mark will come by at some point and help out there03:43
prologicCan we call it04:54
prologicMultiTimer ?04:54
prologicand SingleTimer04:54
prologicand04:54
prologicTimer = SingleTimer04:55
mehereWe could, but the new implementation is intended as a replacement. Exactly the same API, exactly the same behaviour. Only the implementation differs. So why would we want to keep the old Timer implementation as "SingleTimer"?05:41
prologicahh05:43
prologicwhy indeed05:43
prologicI thought you were going to replace it05:43
prologicbut you added TimerSchedule?05:43
mehereYeah, but TimerSchedule is not intended to be used by the user, rather it is a "helper" where every Timer registers and that provides the "combined" generate_events. "For internal use only".06:40
prologicoh really?14:06
prologicso you still register Timer() instances14:07
prologicbut TimerSchedule takes care of every Timer instnace14:07
prologichmm14:07
prologiccan we at least put an s on the end then? :)14:07
prologicerr14:07
prologican r I meant14:07
prologicTimerScheduler14:07
prologicmehere, I disabled ci for a bit14:14
prologicwhile I update and push out docs14:14
prologicand test rendering14:15
prologicAhh you reenabled14:20
prologiccool14:20
prologic:)14:20
mehereWell, you are the native speaker. I thought of a schedule, "a plan" that lists all Timers to be fired (like a flight schedule). It is not a controller that actively schedules something. So from what my dictionary says, I still think that "schedule" describes it better than "scheduler", but English is not my first language.14:23
mehereI re-enabled ci because I saw that timer test failing (in ci only, in my 3.2 environment here it worked). But it really seems to have been a race condition. Now that I set the timer interval from 0.1 to 0.2 in the test there can no longer be any interference with the wait_for checking every 0.1s and it also works in ci. So you can again disable it if you like.14:27
prologichmm14:41
prologicbut it takes care of the generate_events though14:41
prologicso in a way it is both :)14:41
prologicboth a plan14:41
prologicand a controller14:41
prologicright? :)14:41
prologicnah I only disabled last night for a bit while I was updating docs and pushing out to readthedcos.org14:42
prologicI had ThomasWladmann from moinmoin reviewing docs14:42

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!