https://bitbucket.org/gds/ocaml_incrcomp/src/tip/lib/incrcomp.mli
Суть токова: меня достало то, что нужно уметь простые типа-ленивые вычисления, но с умным перевычислением, если что изменилось, но при взгляде на frp / react как-то всё падает.
Я кое-кому говорил, что уложусь в 10 строчек велосипеда -- так вот, ошибся, но потому, что хотел сделать относительно общо. Получилось вроде миленько, однако, прошу, покритикуйте идею, апи, инглиш, да и всё вообще. Моё ниасиляторство react'а, например, тоже можно.
Таки дошли руки до симуляции перегрызенного кабеля (спрашивал в #TP2TNF).
Хорошо иногда бывает параметризовать код IO-манаткой. Получилось так: https://gist.github.com/gdsfh/c0aa2733a6d09b49f894 . Работает замечательно. Благодаря fail_seed можно получать детерминированные фейлы, что помогает при отладке.
А отладка заключалась в том, что Lwt.join как-то странно себя ведёт. В документации сказано "падает, если какой-то из тредов падает", тогда как в реальном случае висит: http://pastebin.com/scLnbQ2A . Вотзефак?
Ебусь со всякой системщиной. Явно чего-то не хватает в императивном описании алгоритмов. Например:
1. указываем, что кое-какой процесс должен быть запущен на всех живых хостах из данного множества. Если хост из множества был дохлым, но потом ожил, то надо запустить процесс на нём тоже, когда он ожил.
2. спрашиваем что-то у процессов и ждём ответа, но, если хост умер (по независимым от нас причинам), и мы это знаем, то не надо ждать ответа. (таймауты тут сработали бы надёжно, но и без них часто ясно, что ответа не будет.)
Нужна какая-то декларативная шняга, что ли? Давайте идеи.
Единственный вестерн, который мне понравился -- "The Gunfighter", 8 минут: https://www.youtube.com/watch?v=JzFhlE1EByA
Мне бы ещё чуток инглиша, чтобы всё осилить в точности, но и так норм.