пошел читать

конечно понятно почему это плохо, но без них код становится ужасным

или просто некомпилируемым

все зависимости в одном месте, в итоге модуль, который будет компилироваться и ghc и ghcjs будет зависеть вообще от всего, а должен наоборот, не зависеть ни от чего, по возможности

ну в этом третьем он мне скажет что конфликт

не скажет

а

а вот это интересно

просто возьмет первый попавшийся?

я для каждой такой сущности создаю модуль

и там описываю сущности

мне наоборот нравится что все в одном месте

я потом через 1 модуль все эти сущности реимпорт делаю

правда насчет GHCJS - действительно не приятно будет

но я таким не занимался сезе

ну это не совсем вопрос вкуса, это скорее вопрос того, как работать с зависимостями

ну у теябю все равно все приложение зависит от этого всего

а ты игрался с GHCJS?

только начал

а там есть что-то типа лайврелоада страницы?

и только на днях заставил это добро работать с reflex

хороший вопрос

ну во время разработки что-то поменял чуток

вроде как есть, но я до этого не дошел пока

и чтобы быстро результат увидеть

да, я понял, но не знаю

интересно

подозреваю, что все плохо

или это может сделать Luite но для остальных это сильно сложно

самый облом для меня оказался, что официальный servant-client не поддерживает ghcjs

чего я собственно хотел

то есть чтобы клиент генерировал ClientM, работающий через xmlHttpRequest

но этого пока нет, есть целых две сторонние имплементации для старых версий серванта, но они не компилируются с новым

так что там все очень сырое пока

и уж тем более live reload

с другой стороны, куча народу это пилит сейчас, так что скоро все будет круто, думаю

просто возьмет первый попавшийся?

да причем может одновременно 2 разных, если не повезёт с инлайнами

красиво

то есть я в общем верю, что это сделано for a reason, но это брутальщина какая-то конечно

А может кто-нибудь посмотреть вот на это http://lpaste.net/340541 и сказать, почему это плохо? Идея в том, что мы берем значение либо из кэша, либо делаем так, чтобы только первый запросивший клиент инициировал long IO action, а остальные блокировались на TMVar и ждали, пока IO action закончится, и потом все одновременно получали бы это значение. Я тут сильно подозреваю, что изобрел велосипед с додекаэдральными колесами. Есть ли какие-то хорошие библиотеки для этого?

А зачем так делать?

Ты хочешь запоминать результат долгого вычисления, это называется memoization

ну я так понял, что остальные треды должны ждать вычисления, а не повторять его

до мемоизации

https://hackage.haskell.org/package/io-memoize-1.1.1.0/docs/System-IO-Memoize.html

Внутрь не заглядывал

eagerlyOnce как раз то, что нужно

во! спасибо, посмотрю

код, который я выложил, оказался плохой, там возникает дедлок, если потоков больше двух. Интересно было бы понять, почему, но лучше взять библиотечную функцию

хотя судя по исходникам, это не совсем то

В конечном счете сделал через Async, там никаких дедлоков не возникает http://lpaste.net/340541

код, который я выложил, оказался плохой, там возникает дедлок, если потоков больше двух. Интересно было бы понять, почему, но лучше взять библиотечную функцию

там вобще race condition на race condition

нету гарантии что только 1 раз запустится тред

нету гарантии, что не перепишется, то, Value на Promise

хотя почему там deadlock сходу не вижу

ну и там MVar было бы проще

да, между проверкой и writeTVar есть окно, когда другие могут влезть и запустить

хотя Value на Promise я загнул

переход от Empty -> Promise неатомарный

тут как ни крутись

угу

тут если использовать то MVar

т.к. там IO можно запустить

надо Mvar попробовать

да

по идее Async должен взять на себя все случаю с exceptions и должно получиться без всякой страшной лапши с catch/finally

ERROR: S client not available

join $ modifyMVar (\case Empty -> do { async »= \x -> return (Promise x, wait x) } ; Promise w -> return (Promise w; wait w); }

Value кстати не нужно Async его уже содержит

о!

лихо

буду осмыслять

спасибо

Еще можно unsafePerformIO foo

Если NOINLINE сделать

Но лучше так не делать

о нет

для меня это имеет еще и некоторый педагогический смысл

поэтому лучше сделать "правильно", а не прогнуть систему под себя

Наверное лучше все что содержит unsafe лучше не делать

Привет всем. Когда-то установил себе haskell-stack, немного поигрался, месяц не трогал, думал начать проект, стал делать, и теперь постоянно выдает такую ошибку в линковщике(здесь про gcc, но у меня такая же с ghc). Может, кто сталкивался? http://stackoverflow.com/questions/1521859/nonrepresentable-section-on-output-error-during-linking-on-linux Сделано: - переустановил stack - удалил ~/.stack

Debian?

Да, sid

Используй cabal master

Стек не пофиксили еще вроде

В дебиане уже слишком новый gcc еще и с -fPIE если не ошибаюсь

Блин, точно. Я ж обновился на полтора гига неделю назад

Спасибо!

В ДЕБИАНЕ СЛИШКОМ НОВЫЙ ГЦЦ

В дебиане уже слишком новый gcc еще и с -fPIE если не ошибаюсь

Что? Поделил на ноль. Вот так неожиданность

Он с дурацкими опциями еще собран

Ну как для ghc дурацкими

А в арче, наверное, слишком старый gcc ?

> В дебиане уже слишком новый gcc еще и с -fPIE > с -fPIE > 2017 ну наконец то хоть в серверном линуксе стали интересоваться безопасностью

ну PIE было всегда

А в арче, наверное, слишком старый gcc ?

Какой сейчас там?

https://ghc.haskell.org/trac/ghc/ticket/12759

Там еще пара багов прилинковано

http://colah.github.io/posts/2015-09-NN-Types-FP/