Anonymous
а монадические стэки разве не есть то самое окружение, которое неудобно воссоздавать?
Нурлан
Нурлан
надо следить что бы передаваемый список в head всегда был не пустой
Нурлан
При создании большой функции когда head зарыт в коде это будет не заметно.
Нурлан
и компиляция пройдет на ура
Нурлан
хотя может это вопросы к проектированию
Нурлан
Кажется у Вершилова, я видел его доклад на митапе, где он рассказывал про систему с введением области определения для функций
Влод
ты всё ещё рассказываешь про то как важно тестировать программу и искать все возможные краевые условия для входных данных, даже при условии хорошей типизации.
Boris говорил про то, что нужно следить за результатом и забыть про вероятность порождения всяких побочных эффектов (там к примеру какой-нибудь поток незавершился, а функция вернула ок результат)
Нурлан
а как же побочные эффекты в IO? Но я тебя понял.
Нурлан
С haskell я почти убрал из цикла тестирование мелких функций, для меня достаточно того, что код с ней скомпилился.
Влод
Нурлан
Влод
Нурлан
а почему просто не создавать побочных эффектов в своем коде на python или чтом там еще это есть?
Влод
ну не ты создашь, так кто-то другой
Нурлан
А если все грамотно написано, то для меня важнее ошибка области определения.
Влод
напишешь комментарий "пожалуйста пишите в этой функции без побочных эффектов" и где-нибудь уровнем ниже в вызываемых функциях всё равно появятся побочные эффекты. короче тебе просто удобно знать какие функции ок работают, какие стоит попроверять внимательнее
ㅤ
подскажите, верно ли утверждение, что программу на хаскеле можно не тестить за счет того, что система типов гарантирует правильность? (если система типов адекватно отражает предметную область, конечно)
характер тестов изменяется, баланс смещается в тестирование логической связанности, нежели латание мелких технических дыр
иными словами хаскель код без тестов изначально выше качеством чем на других яп даже с тестами, хаскель код с тестами еще лучше
Влод
о, спс
Igor
я недеюсь он хоть на хаскеле написан 😏
Kirill
столкнулся с проблемой запуска тестов через stack test
у меня есть стандартный stack проект. код в app/, тесты в test/
в .cabal в test-suite секции прописана зависимость от моего "бинарника". stack ghci запущенный из test/ определяет модули которые я импортирую в Spec.hs и позволяет вызвать main и прогнать тесты.
Однако, stack test падает: Failed to load interface for ‘Handlers’. 'Handlers' — это мой модуль который я тестирую.
видимо, нужно что-то дописать в .cabal, но я не смог нагуглить что.
подскажите, пожалуйста, что делать?
Евгений
подскажите, верно ли утверждение, что программу на хаскеле можно не тестить за счет того, что система типов гарантирует правильность? (если система типов адекватно отражает предметную область, конечно)
Если ты хочешь что-нибудь, что позволяет избежать тестирования, то лучше посмотреть куда-нибудь в сторону идриса.
В хаскеле с этим есть кардинальная проблема -- любой тип населён значением undefined, а значит типовая корректность по сути ничего не гарантирует.
В принципе если писать аккуратно, избегать разных нехороших функций типа fromJust, то добиться корректности проще чем в "обычном языке"™, но это будет держаться на доверии и человеческом факторе
Serghei
Сори за офтоп, а чем так примечателен clang? при использовании clang в софтине, которую я ковыряю, при сборке, больше memory leaks. Кроме все прочего, valgrind мне теперь из исходников нужно собирать, потому как со стобильной версией - parse_type_DIE: confused by: DWARF 4 и все дела. На глаз g++ собирает быстрее. По скороти выполнения не отличается. Вот второй день вожусь с ним (до этого даже не смотрел) и не пойму, а чего так все кипятком писают?
Anonymous
Сори за офтоп, а чем так примечателен clang? при использовании clang в софтине, которую я ковыряю, при сборке, больше memory leaks. Кроме все прочего, valgrind мне теперь из исходников нужно собирать, потому как со стобильной версией - parse_type_DIE: confused by: DWARF 4 и все дела. На глаз g++ собирает быстрее. По скороти выполнения не отличается. Вот второй день вожусь с ним (до этого даже не смотрел) и не пойму, а чего так все кипятком писают?
Нормальная архитектура. Хорошие сообщения об ошибках (цветные!).
Евгений
Нормальная архитектура. Хорошие сообщения об ошибках (цветные!).
Они в gcc свежем тоже цветные
Igorek
а как в stack Обновить версию ghci?
Igorek
я сделал stack upgrade - он всеравно мне 7.10 подсовывает
Vasiliy
stack upgrade обновляет сам stack, а ghci используется той версии, которая прописана в stack.yaml
Igorek
ок. а как это для stack repl поменять?
Vasiliy
запускаемый вне проекта? поправить глобальный конфиг в ~/.stack/global-project/stack.yaml
Igorek
странно, у меня нет этого файла и папки
Igorek
я под вендой
Igorek
ладно, наверное 7.10 должно быть достаточно. хочу просто поиграться с Parsec
Igorek
его нет в импортах
Vasiliy
под вендой не знаю, где он лежит
Igorek
import Text.Parsec.String
<no location info>:
Could not find module `Text.Parsec.String'
Igorek
его надо качнуть отдельно или как?
Vasiliy
просто stack install parsec
Vasiliy
или даже megaparsec, он более модный
Igorek
о, спасибо огромное
Alexander
версию снапшота поднять в проекте или глобально, потом stack setup
Misha
А кто знает какой-нибудь stm-friendly heap? Хочу сделать lru поверх stmcontainers.map, но нужен какой-то heap, можно конечно сделать TVar (Data.Heap a) но тогда там будет весь contention
Vladislav
@weonn, тут спамеры пожаловали
Dmitry
два гигабита хаскел закрывате бодрячком
Dmitry
на виртуалке. через UDP
Alexey
столкнулся с проблемой запуска тестов через stack test
у меня есть стандартный stack проект. код в app/, тесты в test/
в .cabal в test-suite секции прописана зависимость от моего "бинарника". stack ghci запущенный из test/ определяет модули которые я импортирую в Spec.hs и позволяет вызвать main и прогнать тесты.
Однако, stack test падает: Failed to load interface for ‘Handlers’. 'Handlers' — это мой модуль который я тестирую.
видимо, нужно что-то дописать в .cabal, но я не смог нагуглить что.
подскажите, пожалуйста, что делать?
Ммм. У меня, вот, тесты, бенчи и бинарники зависят от библиотеки. То есть общий код в library. И отдельные екзешники — тестовые, бенчевые и рабочие зависят от либы. Так работает. А чтобы тест зависел от екзе, не пробовал.
Alexander
А кто знает какой-нибудь stm-friendly heap? Хочу сделать lru поверх stmcontainers.map, но нужен какой-то heap, можно конечно сделать TVar (Data.Heap a) но тогда там будет весь contention
где-то был пакет с пачкой структур STM но на память не скажу
Misha
я знаю только https://hackage.haskell.org/package/stm-containers
Misha
но там все достаточно такое basic
Alexander
я обычно по месту пишу
Alexander
если не слишком умное надо
Alexander
не, что-то ещё было
Alexander
а может там не STM а просто non-blocking структуры
Alexander
те же ребята что unagi-chan делали вроде
Misha
вот скорее non-blocking
Alexander
самое что похожее у меня однопоточное было
Alexander
мне нужно было хитрый фильтр рисовать
Alexander
чтобы всякие всплески событий ужимал
Alexander
т.к. сишная аппликуха могда генерить их тысячами в секунду
Alexander
причем 500 событий и 500 их отмен в каком-то порядке
Misha
ну я не ожидаю каких-то больших нагрузок, скорее там может быть просто сравнительно большой объем (единицы гигабайт наверное) и хочется максимально положиться на STM для корректности, пусть даже с потерей перфоманса. Так что наверное TVar (Data.Heap a) пойдет.
Misha
ну и еще в идеале надо запилить STM.IxSet
Misha
но тут я не потяну пока
Alexander
было что-то такое уже
Alexander
TStore или как-то так
Alexander
не знаю production ready или нет
Misha
TCache наверное
Alexander
наверное
Misha
но он вроде как с претензией на замену acid-state
Misha
хотя я не подробно не смотрел
Misha
и бенчмарков не видел
Kirill
Ммм. У меня, вот, тесты, бенчи и бинарники зависят от библиотеки. То есть общий код в library. И отдельные екзешники — тестовые, бенчевые и рабочие зависят от либы. Так работает. А чтобы тест зависел от екзе, не пробовал.
мне уже рассказали, что общий код не нужно в app/ держать :)
перенёс его в src/ и всё стало ок
blkmrkt
мне уже рассказали, что общий код не нужно в app/ держать :)
перенёс его в src/ и всё стало ок
Угу, в main у меня только парсинг args и env, дальше runApp ... IO с нужными параметрами
Boris
Есть ли вменяемые реализации дирамид? Те, которые находил очень бедные
Boris
Пришлось свою накатать, но она специфичная получилась
Boris
И еще - кто нибудь юзает quickcheck вместе с test-framework?
Boris
Там можно указать число прогонов по каждому тесту?