Все так или иначе содержат утечки памяти либо имеют неработающие примитивы. Если, конечно, речь идет о там фрп которое Functional Reactive Programming.
Наиболее современная реализация -- Data.Reactive, в ней к сожалению неправильно работает join (особенно в фильтрации событий) и исключительно криво работают recursive integrations (людям из маиллиста непросто было даже сделать шарик отскакивающий от границ экрана
( ... )
Наиболее современная реализация -- Data.Reactive, в ней к сожалению неправильно работает join (особенно в фильтрации событий) и исключительно криво работают recursive integrations (людям из маиллиста непросто было даже сделать шарик отскакивающий от границ экрана).
Про фильтрацию событий: мне вообще непонятно, зачем было делать события списками. У себя я просто сделал процессы -- подождали события и вернули значение. Никаких списков и фильтров. Как-то не нужны оказались.
А кто такие recursive integrations? Какие с ними сложности?
Не говорите так, если бы не утечки, все бы давно с Fran развлекались и не мучались бы. Специально чтобы избавиться от утечек и создано было arrow-based frp, которое (в теории) засчет ограничений должно "нормализовывать" конструкции. Вот подробнее об этом: http://people.cs.uu.nl/johanj/afp/afp4/hudak.ppt
Позже был найден нормальный способ избежать ликов, реализованный в Data.Reactive. Но Data.Reactive пока что работает весьма плохо.
Не говорите так, если бы не утечки, все бы давно с Fran развлекались и не мучались бы. Специально чтобы избавиться от утечек и создано было arrow-based frp, которое (в теории) засчет ограничений должно "нормализовывать" конструкции. Вот подробнее об этом: http://people.cs.uu.nl/johanj/afp/afp4/hudak.ppt
Позже был найден нормальный способ избежать ликов, реализованный в Data.Reactive. Но Data.Reactive пока что работает весьма плохо. У Fran насколько я понимаю утечки были вообще очень суровые (там вроде Behaviour моделился чуть-ли не прямо как Time -> a). Если описывать Behavior тупым continuation и не писать рекурсивных выражений типа "e = 1 + integral e" (хаскелл все-таки уравнения не решает), то проблем особых нет. Возможно их нет только в кемле, в котором вообще таких выражений записать нельзя, но раз получилось обойтись без
( ... )
> Не очень понял про способ избежать ликов в Data.Reactive?
Если б я сам понял, я был бы очень счастлив :-)
Про примерно этот метод было еще в старом блоге Luke Palmer (да и вобще по идее проще всего разобраться в коде fregl, он относительно простой). Вроде бы оно все на stm базируется. Если вы что-нибудь поймете, объясните пожалуйста :-)
А Data.Reactive по-моему я вобще понять в ближайшие пару лет не смогу :-)
> Фиг знает, попробую поиграться в хаскеле, есть подозрение, что проблема не в FRP.
Вот у меня как раз подозрение что проблема в хаскеле. Потому что ну как можно 10 лет ресерчить и не сделать ни одной работающей нормально реализации? :-)
А можно как-нибудь посмотреть на ваши работы в этом направлении? Очень интересно.
Что-то у него ссылка на fregl куда-то на luigi.org, а тот недоступен.
А название поста или какие-нить ключевые слова, как поискать "про примерно этот метод".
Вот у меня как раз подозрение что проблема в хаскеле. Потому что ну как можно 10 лет ресерчить и не сделать ни одной работающей нормально реализации? :-)
Вот и у меня такое подозрение. Я читал про time/space leak-и и так до конца и не понял про что это они все пишут (вернее понял, но не понял где и зачем надо так писать, чтобы эти утечки появились). Читаю блог Conal-а и в последнее время вообще не понимаю те проблемы, которые он пытается решить (вернее понимаю, что они к его Data.Reactive относятся и еще к каким-то абстрактным задачам, но с моими задачами оно ну никак не соприкасается).
А можно как-нибудь посмотреть на ваши работы в этом направлении? Очень интересно.Дык я не ученый, я программер. У меня нет работ, у меня проекты. Вот сейчас пытаюсь выцепить, то что более-менее оформилось и сделать из этого библиотеку на хаскеле (изначально у меня все на кемле). Ее думаю куда-
( ... )
Fran/FranTk/Frob/Yampa/DataDriven/Reactive/Frapjax -- это только более-менее известные. И с каждой можно работать. Есть недостатки и недоработки (как и в любых исследовательских проектах), но использовать можно. Если стрёмно, можно не использовать ;). Просто программы будут чуть длиннее и глюкавее (да и то не факт).
Reply
Reply
Reply
И представьтесь, пожалуйста.
Reply
Reply
А чем потоковые процессоры не подходят?
Reply
Про фильтрацию событий: мне вообще непонятно, зачем было делать события списками. У себя я просто сделал процессы -- подождали события и вернули значение. Никаких списков и фильтров. Как-то не нужны оказались.
А кто такие recursive integrations? Какие с ними сложности?
Reply
Reply
> Утечек они сами по себе не содержат.
Не говорите так, если бы не утечки, все бы давно с Fran развлекались и не мучались бы. Специально чтобы избавиться от утечек и создано было arrow-based frp, которое (в теории) засчет ограничений должно "нормализовывать" конструкции. Вот подробнее об этом: http://people.cs.uu.nl/johanj/afp/afp4/hudak.ppt
Позже был найден нормальный способ избежать ликов, реализованный в Data.Reactive. Но Data.Reactive пока что работает весьма плохо.
Reply
> Т.е. утечки -- это вообще не проблема.
> Утечек они сами по себе не содержат.
Не говорите так, если бы не утечки, все бы давно с Fran развлекались и не мучались бы. Специально чтобы избавиться от утечек и создано было arrow-based frp, которое (в теории) засчет ограничений должно "нормализовывать" конструкции. Вот подробнее об этом: http://people.cs.uu.nl/johanj/afp/afp4/hudak.ppt
Позже был найден нормальный способ избежать ликов, реализованный в Data.Reactive. Но Data.Reactive пока что работает весьма плохо.
У Fran насколько я понимаю утечки были вообще очень суровые (там вроде Behaviour моделился чуть-ли не прямо как Time -> a). Если описывать Behavior тупым continuation и не писать рекурсивных выражений типа "e = 1 + integral e" (хаскелл все-таки уравнения не решает), то проблем особых нет. Возможно их нет только в кемле, в котором вообще таких выражений записать нельзя, но раз получилось обойтись без ( ... )
Reply
Если б я сам понял, я был бы очень счастлив :-)
Про примерно этот метод было еще в старом блоге Luke Palmer (да и вобще по идее проще всего разобраться в коде fregl, он относительно простой). Вроде бы оно все на stm базируется. Если вы что-нибудь поймете, объясните пожалуйста :-)
А Data.Reactive по-моему я вобще понять в ближайшие пару лет не смогу :-)
> Фиг знает, попробую поиграться в хаскеле, есть подозрение, что проблема не в FRP.
Вот у меня как раз подозрение что проблема в хаскеле. Потому что ну как можно 10 лет ресерчить и не сделать ни одной работающей нормально реализации? :-)
А можно как-нибудь посмотреть на ваши работы в этом направлении? Очень интересно.
// pierre
Reply
А название поста или какие-нить ключевые слова, как поискать "про примерно этот метод".
Вот у меня как раз подозрение что проблема в хаскеле. Потому что ну как можно 10 лет ресерчить и не сделать ни одной работающей нормально реализации? :-)
Вот и у меня такое подозрение. Я читал про time/space leak-и и так до конца и не понял про что это они все пишут (вернее понял, но не понял где и зачем надо так писать, чтобы эти утечки появились). Читаю блог Conal-а и в последнее время вообще не понимаю те проблемы, которые он пытается решить (вернее понимаю, что они к его Data.Reactive относятся и еще к каким-то абстрактным задачам, но с моими задачами оно ну никак не соприкасается).
А можно как-нибудь посмотреть на ваши работы в этом направлении? Очень интересно.Дык я не ученый, я программер. У меня нет работ, у меня проекты. Вот сейчас пытаюсь выцепить, то что более-менее оформилось и сделать из этого библиотеку на хаскеле (изначально у меня все на кемле). Ее думаю куда- ( ... )
Reply
Reply
Reply
Reply
Reply
Leave a comment