New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix fpsWhen #141

Closed
wants to merge 14 commits into
base: master
from

Conversation

Projects
None yet
2 participants

jvoigtlaender added some commits Jan 25, 2015

dropRepeats on input to fpsWhen
... making the handling more robust
removed superflous test in fpsWhen
... it's superfluous since by the dropRepeats on the isOn-signal no two
false will occur consecutively there, and since the timer is not running
if wasOn = false
another refactoring in fpsWhen
... to prepare the next change
one fix in fpsWhen
when isOn-signal jumps from false to true, we should return 0 in *that*
round, not return some "old" delta while forcing the *next* round to
return 0
simplify in fpsWhen
... possible since the ticker will now *always* be sent the value false
only
another fix in fpsWhen
when isOn-signal was true and a ticker event arrives, compute delta from
previous and current time, not from what is on the deltas signal (which
would be wrong on the first update)
fix preceding "fix"
... by making the timestamps of the ticker signal available in
startStopTimer
final fix in fpsWhen
when isOn-signal jumps from true to false, make sure that the last time
slice is returned, not the delta of the previous round (which will be
what is still on the state signal)
simplification in fpsWhen
specifically, no foldp-ing over state needed anymore, since only the
timestamps of the ticker signal are used at all

jwmerrill added a commit to jwmerrill/core that referenced this pull request Jan 25, 2015

Fix semantics of fpsWhen.
fixes #139
alternative to #141

Semantics:

1. fpsWhen fires whenever isOn changes, or its internal setTimeout fires
2. Its value is a timedelta, which is 0 when isOn changes from false to true,
or is the time elapsed since the last event otherwise. As a corrolary, summing
deltas gives exactly the time between when isOn transitioned from false to
true, and when it transitioned from true to false.
@jwmerrill

This comment has been minimized.

Show comment
Hide comment
@jwmerrill

jwmerrill Jan 25, 2015

Contributor

I think the semantics here are now correct.

I took a stab in #142 at implementing the same semantics in a different way. The main difference is to timestamp the combination of isOn and ticker, instead of timestamping them separately, which allows a little less branching inside the update function. @jvoigtlaender, what do you think about that as an alternative?

Contributor

jwmerrill commented Jan 25, 2015

I think the semantics here are now correct.

I took a stab in #142 at implementing the same semantics in a different way. The main difference is to timestamp the combination of isOn and ticker, instead of timestamping them separately, which allows a little less branching inside the update function. @jvoigtlaender, what do you think about that as an alternative?

@jvoigtlaender

This comment has been minimized.

Show comment
Hide comment
@jvoigtlaender
Contributor

jvoigtlaender commented Jan 26, 2015

Closing this in favour of https://github.com/elm-lang/core/pull/142.

@jvoigtlaender jvoigtlaender deleted the jvoigtlaender:fix-fpsWhen branch Feb 6, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment