mightyhttpd кто-то из взрослых использует?

mighttpd - на хаскеле!:)

ну это ж прекрасно

наверное.

я даже не знал про такое:)

ни документации, ни примеров, ни помощи если что-то где-то сломается. но наверное можно починить самим

http://www.mew.org/~kazu/proj/mighttpd/en/

если бы он еще терминировал ssl

@qnikst посоветовал - будем его мучать:)

короче в haproxy вроде можно подпихнуть что-то для раздачи статики, хотя он наверное и сам умеет

погодите. это что, просто варп?

ну с конфигом в файлике

а чем это отличается сервант на варпе выставить в интернет? статику раздавая каким-нибудь middleware ?

там поди и ssl можно терминировать

это хитрый варп

не видел чтобы кто-то кроме казу использовал

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

там от варпа отличается preforkом и еще чем-то

казу спрашивал с нгинксом и даже обгонял его на статике

не знаю как

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

там с вебсокетами беда на сколько я понял

я тоже так думаю, он конечно просто настраивается но проще что-то более проверенное

это ж для статики, какие там вебсокеты?

ну чисто для статики он подойдет

а так чтобы поставить перед всеми приложениями

https://github.com/wireapp/wire-server

https://github.com/wireapp/wire-server

Много разных вкусностей

подскажите, верно ли утверждение, что программу на хаскеле можно не тестить за счет того, что система типов гарантирует правильность? (если система типов адекватно отражает предметную область, конечно)

Неверно

нет

Нет

ты хотел сложить 2 и 2, а случайно написал 2 + 3

тебе никакой статический анализатор такого рода ошибки не отловит

оох точно

спасибо

Если бы так было - все бы писали ПО на хаскеле и никаких багов)

но чистые функции значительно проще тестировать - не нужно воссоздавать окружение и следить за чем-либо кроме результата

а монадические стэки разве не есть то самое окружение, которое неудобно воссоздавать?

но чистые функции значительно проще тестировать - не нужно воссоздавать окружение и следить за чем-либо кроме результата

Вот тебе еще пример head []

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

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

ты не опроверг его слова

При создании большой функции когда head зарыт в коде это будет не заметно.

и компиляция пройдет на ура

хотя может это вопросы к проектированию

Кажется у Вершилова, я видел его доклад на митапе, где он рассказывал про систему с введением области определения для функций

ты всё ещё рассказываешь про то как важно тестировать программу и искать все возможные краевые условия для входных данных, даже при условии хорошей типизации. Boris говорил про то, что нужно следить за результатом и забыть про вероятность порождения всяких побочных эффектов (там к примеру какой-нибудь поток незавершился, а функция вернула ок результат)

а как же побочные эффекты в IO? Но я тебя понял.

С haskell я почти убрал из цикла тестирование мелких функций, для меня достаточно того, что код с ней скомпилился.

?

а почему просто не создавать побочных эффектов в своем коде на python или чтом там еще это есть?

ну не ты создашь, так кто-то другой

А если все грамотно написано, то для меня важнее ошибка области определения.

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

ERROR: S client not available

подскажите, верно ли утверждение, что программу на хаскеле можно не тестить за счет того, что система типов гарантирует правильность? (если система типов адекватно отражает предметную область, конечно)

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

о, спс

я недеюсь он хоть на хаскеле написан ?

столкнулся с проблемой запуска тестов через 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, то добиться корректности проще чем в "обычном языке"™, но это будет держаться на доверии и человеческом факторе

Сори за офтоп, а чем так примечателен clang? при использовании clang в софтине, которую я ковыряю, при сборке, больше memory leaks. Кроме все прочего, valgrind мне теперь из исходников нужно собирать, потому как со стобильной версией - parse_type_DIE: confused by: DWARF 4 и все дела. На глаз g++ собирает быстрее. По скороти выполнения не отличается. Вот второй день вожусь с ним (до этого даже не смотрел) и не пойму, а чего так все кипятком писают?

Сори за офтоп, а чем так примечателен clang? при использовании clang в софтине, которую я ковыряю, при сборке, больше memory leaks. Кроме все прочего, valgrind мне теперь из исходников нужно собирать, потому как со стобильной версией - parse_type_DIE: confused by: DWARF 4 и все дела. На глаз g++ собирает быстрее. По скороти выполнения не отличается. Вот второй день вожусь с ним (до этого даже не смотрел) и не пойму, а чего так все кипятком писают?

Нормальная архитектура. Хорошие сообщения об ошибках (цветные!).

Нормальная архитектура. Хорошие сообщения об ошибках (цветные!).

Они в gcc свежем тоже цветные

Они в gcc свежем тоже цветные

А хорошие=понятные?

а как в stack Обновить версию ghci?

я сделал stack upgrade - он всеравно мне 7.10 подсовывает

stack upgrade обновляет сам stack, а ghci используется той версии, которая прописана в stack.yaml

ок. а как это для stack repl поменять?

запускаемый вне проекта? поправить глобальный конфиг в ~/.stack/global-project/stack.yaml

странно, у меня нет этого файла и папки

я под вендой

ладно, наверное 7.10 должно быть достаточно. хочу просто поиграться с Parsec

его нет в импортах

под вендой не знаю, где он лежит

import Text.Parsec.String <no location info>: Could not find module `Text.Parsec.String'

его надо качнуть отдельно или как?

просто stack install parsec

или даже megaparsec, он более модный

о, спасибо огромное

версию снапшота поднять в проекте или глобально, потом stack setup

А кто знает какой-нибудь stm-friendly heap? Хочу сделать lru поверх stmcontainers.map, но нужен какой-то heap, можно конечно сделать TVar (Data.Heap a) но тогда там будет весь contention

@weonn, тут спамеры пожаловали