Использование MonadPlus в FRP.Reactive.FieldTrip

Question

Я изучаю FRP в данный момент через адаптер FieldTrip. И столкнулся с проблемой странным способом планирования кадров и интеграции. Поэтому сейчас я пытаюсь создать собственный маркер Event для выравнивания степпинга поведения.

Итак ...

flipflop :: Behavior String
flipflop = stepper "none" (xflip 2) where
    xflip t0 = do
        t <- withTimeE_ (atTime t0)
        return "flip" `mplus` xflop (t+3)
    xflop t0 = do
        t <- withTimeE_ (atTime t0)
        return "flop" `mplus` xflip (t+2)
txtGeom = ((uscale2 (0.5::Float) *%) . utext . show <$>)
main = anim2 (txtGeom . pure flipflop)

Вопросы это:

Почему этот пример приводит к утечке памяти? Есть ли безопасный способ построить последовательность событий, в которой каждое следующее запланировано в зависимости от предыдущего?

Answer 1

Похоже, что присоединение к событиям таким образом не будет работать. Попробуйте вместо этого:

import FRP.Reactive
import FRP.Reactive.FieldTrip
import Graphics.FieldTrip
import Control.Monad
import Control.Applicative


flipflop = stepper "none" $ either (const "flip") (const "flop")
            <$> eitherE (atTimes ((+2) <$> [0,5..])) (atTimes [5,10..])

txtGeom = ((uscale2 (0.5::Float) *%) . utext . show <$>)
main = anim2 (txtGeom . pure flipflop)

К сожалению, в этой версии все еще есть утечка, но она намного меньше. Примерно через минуту работы ОЗУ было около 9,7 МБ.

Также есть функция flipFlop, которая создает Behavior Bool. Это хорошо сработало для триггера, но я не видел чистого способа добавить «нет» в течение первых двух секунд.

Я тоже пробовал это

flipflop = stepper "none" $ (const "flip" <$> (atTimes ((+2) <$> [0,5..])))
                            `mplus` (const "flop" <$> atTimes [5,10..])

, который работает идентично первой версии.

Конечно, это не очень помогает для динамического планирования в соответствии с тем, о чем вы спрашиваете. К сожалению, я не верю, что этот вариант использования работает в Reactive.

Я очень восхищаюсь работой, которую произвела Reactive, и я хочу, чтобы она мне понравилась, но кажется, что это крайне сложно рассуждать. Эта ветка из списка рассылки является примером проблемы (и решения!), Которая кажется распространенной. Кроме того, библиотека «unamb» (которая лежит в основе большей части Reactive) выявила ряд очень тонких ошибок в многопоточности GHC, которые приводили к хаосу с результатами, пока они не были исправлены вокруг ghc-6.12. Хотя это ни в коем случае не вина Конала или других участников Reactive, это значительно усложнило использование фреймворка, особенно с более ранними версиями GHC.

Вы можете попробовать другие пакеты FRP. У Yampa есть звуковая реализация, и я слышал, что Elerea относительно просто подобрать, и у него есть хорошее демонстрационное приложение .