Минутка гордости за Java, или как в Америке негров линчуют.
Решил попробовать сегодня Haskell, задачки на нем порешать.
Хрена с два, stack постоянно падает с Access Violation (Windows 10 x64).
Экзешник, конечно, генерируется - но к каким проблемам это всё ведёт - непонятно.
Вначале меня забросило на форумы Elm, который тоже пострадал от того же бага, но там люди быстро что-то бинарно запатчили, пересобрали с древним GHC, и оно заработало.
В Haskell Stack, одно из решений - включить опцию --ghc-options="-fexternal-interpreter", но это экспериментальная шняга, временами ломающая сборку в Stack и несовместимая с Intero.
То есть, интеграция с IDE работать не будет (например, плагин для IDEA зависит именно от Stack и Intero).
Жить без IDE? Да ну нафиг.
Выяснилось, что это баг, который завели 2 года назад, но всего лишь и 5 месяцев назад всё ещё не было разумного решения:
https://ghc.haskell.org/trac/ghc/ticket/13112Опытным путем оказалось что, никакой GHC 8.6.3 не крашится в Access Violation. Похоже, багу пофиксили, но на трекере факт решения не отметили. Так что, конкретная версия, и когда ее починили, не ясна.
Дальше я много мучался, включаял и выключал внешний GHC. Потом понял, что Stack и так качает ту же версию GHC, что и я.
Проблема не в GHC из тулчейна. Проблема в том, что Stack собран с древнючим GHC, в котором бага не пофикшена.
Ну, выкачал Git-репозиторий самого Stack. Жутко мучался, пытаясь понять, как это пересобирать и как проапгрейдить до свежей версии компилятора. Ну, там две системы сборки, всё непросто.
Никакой документации по сборке, конечно, нет. Чтобы абы кто собирать не начал, значит, грязными ногами своими топтаться - это же центральная часть экосистемы, понимать надо!
В конце концов дошел до того, что всё как бы собирается, кроме самой важной зависимости - библиотеки, которая в Stack отвечает за обработку схемы зависимостей, называется Pantry.
Сборка модуля Pantry.Storage виснет. Вначале она просто честно висла, выжирая 20% процессора. Потом я наклянчил у гугла параметры --interleaved-output и --cabal-verbose, и стал наблюдать.
Там же обнаружилось, что если запустить команду с --no-strip --fast -fexternal-interpreter, то сборка сразу крашится. А если просто с --fast -fexternal-interpreter, то внешний интерпретатор запускается и жрёт 0% процессора. А в других случаях запускается и жрёт 20%.
В ходе бессмысленных метаний по гуглу (как это отлаживать я хз), обнаружилась следующая бага:
https://github.com/well-typed/generics-sop/issues/93Оказывается, конкретно на Windows в GHC 8.6.3 поломали Template Haskell, что бы это ни значило. Любое использование TH приводит к тому, что компилятор зависает навечно.
Баг (
https://ghc.haskell.org/trac/ghc/ticket/16057) обещают пофиксить в 8.6.4, но пока сборок этой версии нет.
Сборка master branch репозитория GHC я оставил на самый конец.
Сейчас пытаюсь собрать всё с 8.4.4
Но там происходит какой-то dependency hell, в котором даже allow-newer: true не помогает. Что-то там куда-то не туда кэшируется. Что будет, если попробовать вмешаться в это руками и Кабалой подумать страшно.
Вот как-то так.
Непросто становиться сверхчеловеком, но результат будет стоить того!