Skip to content
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

Infinite Loop When using (d)pSwitchB #22

Closed
DavidEichmann opened this issue Jul 16, 2016 · 3 comments
Closed

Infinite Loop When using (d)pSwitchB #22

DavidEichmann opened this issue Jul 16, 2016 · 3 comments
Labels

Comments

@DavidEichmann
Copy link

I'm having issues using pSwitchB. I've made a simple program below that demonstrates the issue. When the switch occurs (input value is 3), this goes into an infinite loop, presumably because each time the switch occurs, a new one is immediately triggered. I though using dpSwitchB would solve this problem, but it only delays the issue till the next sample. Am I using (d)pSwitchB incorrectly?

module Main where

import FRP.Yampa

eventAt3 :: SF Integer (Event ())
eventAt3 = arr $ \t -> if t == 3
                        then Event ()
                        else NoEvent

swit :: [SF Integer (Event ())] -> SF Integer [Event ()]
swit actors = pSwitchB
        actors
        (arr (\(_, es) -> () <$ catEvents es))
        (\colSfs _ -> swit colSfs)

main :: IO ()
main = print $ embed (swit [eventAt3]) (0, [(1,Just 1),(1,Just 1),(1,Just 2),(1,Just 3),(1,Just 4)])
@ziriax
Copy link

ziriax commented Jul 16, 2016

It had been a decade since I did Haskell, so my answer might be silly and wrong. But it seems you are switching into the same list of actors.

(\colSfs _ -> swit colSfs)

Could you try

(\(_:colSfs) _ -> swit colSfs)

@DavidEichmann
Copy link
Author

So that would solve the infinite loop, but it isn't the behaviour I am looking for: I need to keep the actor. What I ultimately want is for actors to be able to spawn new actors, so the code would actually look more like this:

(\colSfs _ -> swit (eventAt3 : colSfs))

which would make the situation even worse.

@Linearity
Copy link

The combined signal functions are recursively switching to each other because they both produce a trigger event at time 3. Using a delayed combinator is no help because

  1. it does not change the input, and
  2. the signal functions before and after the switch are the same, so their output is the same.

The solution is to pass the trigger event signal through notYet, which suppresses events at local time 0. Therefore the first signal function will switch at time 3 (local time 3) and the second signal function will not switch at time 3 (local time 0).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants