On Thu, Feb 5, 2015 at 11:12 PM, GitHub <[email protected]> wrote: > > > Log Message: > ----------- > 40477 > > 14669 Delay refactoring (part 2a) - avoid UI locking up when timer event > loop is stopped > https://pharo.fogbugz.com/f/cases/14669 > > > Thanks Max and Marcus for review and pushing this through.
Next step is Issue 14353 "Delay refactoring (Part 2) - change from milliseconds to microseconds" and I started to review rebasing this onto the latest build. Now left over from Part 1 ( https://pharo.fogbugz.com/default.asp?14261) is lots of conditional code wrap of the form... self newCodeEnabled ifTrue: [ "my new code" ] ifFalse: [ "the old code" ] However this conditional code wrap clutters things making it harder to review changes going forward. So I was wondering it was preferable for me to clean that out first, before pushing 14353 for review. For Part 1 it served a few purposes... (1) It was required to make an instantaneous transition to the new architecture. However this no longer required since integration of Issue 14669 now allows the DelayScheduler to be stopped to change code without locking the system. (2) It provided an emergency fallback to disable the new architecture, since this was deep-diving into critical infrastructure. However Part 1 was integrated in November, so is that long enough for the code to have proved itself? (3) It allowed easy switching back and forth for benchmarking. Maybe still useful, but I don't think this is enough on its own to keep the newCodeEnabled conditional code wraps. Benchmarking can still be done on separate build before and after integration of subsequent changes. Please advise how you'd like me to proceed. cheers -ben
