Окно в закабаленный мир не нужно :)

[dastapov]

Я тут читал залежи в google reader и наткнулся на пост, озаглавленный "Окно в закабаленный мир". В нем были описаны какие-то жуткие ужасы о том, как сетапить окружение для разработки на Haskell, и я хотел бы рассказать, как это делал я. Писать буду только про Linux, т.к. с Windows у меня никакого опыта нет.

GHC

В Страшном Посте пишут "C Linux все проще, но несколько дольше, потому, что GHC под ним нужно собирать.".

Я решительно не согласен. Собирать GHC надо только тогда, когда ты что-то правишь в самом GHC, или тебе нужен самый наираспоследний bleeding edge. Автор Страшного Поста собирает из исходников релиз-версию GHC, что начисто лишено смысла.

У меня было так:
* В /usr/bin стоит какой-то умеренно древний GHC, идущий в дистрибутиве (у меня был Debian, и там был GHC 6.12.3)
* В ~/devel/ghc-<version> ставится сколько угодно более новых версий GHC

Ставятся они просто - скачивается бинарная сборка для linux, разворачивается, ./configure --prefix=~/devel/ghc-<version> && make install. После этого дописываем ~/devel/ghc-<version>/bin в PATH, и все готово.

Нужно собрать другой версией? Правим PATH (или тупо дописываем спереди), и все.

cabal

Ставим какой-то cabal из дистрибутива (или бинарную сборку с сайта cabal), затем cabal update && cabal install cabal-install. Все, у нас новый cabal, руками собирать ничего не надо.

Дописываем в PATH директорию ~/.cabal/bin, куда по умолчанию ставятся бинарники из устанавливаемых бинарных пакетов, и на этом возня с cabal-install заканчивается.

Апгрейды и reset the world

У меня как-то не наблюдалось описываемых автором ужасов про то, что alex и happy надо ставить как-то особенно. Cabal install alex happy, и вся печаль.

Да, у cabal-install вплоть до версии 0.14 было не очень с dependency resolution, поэтому --dry-run был показан при любом нетривиальном апгрейде.

Впрочем, если что-то и шло наперекосяк, то всегда можно было достаточно быстро поправить ситуацию при помощи ghc-pkg deregister или в самом крайнем случае снести ~/.cabal/lib/*/версия-компилятора, сделать deregister всему и переставить пакеты заново - благо, можно сделать "cabal install" в директории с твоими исходниками, и все зависимости будут установлены. Делал я это, помнится, ровно один раз, поломав базу своими же патчами к cabal-install, и кроме этого случая каких-то супер-страшных проблем с поддержанием пакетной базы не испытывал (я могу сравнивать с python и ruby, если что)

<растопыривание пальцев> Мой опыт с Haskell заключается как в написании прикладного кода, так и в написании патчей к GHC, и когда я этим плотно занимался, у меня на машине было до 7 разных версий GHC, несколько разных версий Cabal и cabal-install, и пять-десять собственных пакетов в работе. Так что я уверенно утверждаю, что сложно делать не надо, надо делать просто. </растопыривание пальцев>

Comments

[jdevelop.livejournal.com]

GHC на фрибзд ставится из портов довольно странно, но есть бинарные сборки

а вот про конфликты зависимостей из --global и локальных в кабале наслышан не только я

[nponeccop.livejournal.com]

Моё решение таково:

Linux:

1. Чтобы не компилить, использую binary-based Linux distribution
2. Чтобы не компилить свежачок, использую rolling-release Linux distribution
3. Чтобы не было депенденси хелла, библиотеки к своим проектам ставлю всегда локально, будь то перл, ноуд или хаскелл.
4. В Хаскеле - дополнительая подстилка cabal install cabal-dev

в арклинуксе pacman -S ghc предлагает 7.4.1 в бинарном виде c 3 марта, через месяц после официального релиза. Мне этого хватает.

Windows:

1. Использую Haskell Platform.
2. Если очень нужно что-то свежее - ставлю ghc binaries после haskell platform и использую cabal-install из платформы для установки библиотек под новый компилятор. Если для библиотеки требуется configure - отказываюсь от винды.

[bytebuster463.livejournal.com]

А я вообще не понимаю, о чём речь. :)
Ну ладно, собирать, с грехом пополам, научились. Ну, смогли с помощью кабалы собирать инсталляторы. А дальше? Intellisence? Дебаггинг?

В Eclipse давно есть (http://eclipsefp.sourceforge.net/ocaml/index.html) поддержка OCaml.
Про видимо-студию и F# вообще молчу, там всё в одном флаконе, включая кривые breakpoints.

[gds.livejournal.com]

если чо, для окамла недавно появилась крутая штука TypeRex для емакса. Очень многое из того, что требуется от IDE, оно покрывает.

[bytebuster463.livejournal.com]

Ухты! Спасибо, реально, покрывает очень многое.

[gds.livejournal.com]

ага. И даже очень вменяемо разрабатывают -- даже от меня приняли пару (2..3, вроде) моих фичереквестов/багфиксов.

кстати, для подобной мелочи, которая появляется в процессе хода времени, хороша жаббер-конференция ocaml@conference.jabber.ru , там про TypeRex обсуждали уже весьма давно. (хотя, "давно" -- это не какое-либо обвинение, ни в коем случае.)

[bytebuster463.livejournal.com]

Познавательно, благодарствую.

[http://users.livejournal.com/_adept_/]

Дебаггинг для Haskell - это вообще что-то непонятное. Отладочный вывод и логгинг рулит, а дебаггинг с ленивой семантикой дружит слабо.

А как эклипс+окамл ведут себя на больших проектах - есть опыт? Если так же, как с явой, я лучше пешком постою. Подозреваю, что так же, и тормознутость там от эклипса, а не от языка.

Автодополнение меня устаивает в исполнении hippy-expand в emacs, ocamlspot закрывает вопрос с "а какого типа у нас вот это выражение?", а большего мне не надо. Отлаживать локально то, что я пишу, один фиг не выйдет, так что отладчик и брейкпоинты меня не греют. Впрочем, на TypeRex я таки собираюсь смотреть, только руки пока не дошли.

[bytebuster463.livejournal.com]

Дебаггинг для ФП - это, действительно, очень особенная штука.
Не могу найти ссылку, но, кажется у Thomas Petricek была статья на эту тему. Суть её - в том, что проблема даже не в ленивых вычислениях, а в немутабельности. Нет переменных - теряется смысл breakpoints и watch.

Но есть смысл смотреть на параметры вызова. А эти параметры не все среды умеют нормально показать.

Нет, больших проектов не катал, только для себя баловался.

[helvegr.livejournal.com]

> В Eclipse давно есть поддержка OCaml.

А Вы пользуетесь этим плагином? Смущает "early development stage (alpha)" и отсутствие обновлений с 2004 года (актуальный репозиторий я не смог найти). EclipseFP для Haskell (форком которого, как я понимаю, является окамловый) выглядит поживее (http://eclipsefp.github.com/).

[migmit.livejournal.com]

Я собирал из исходников релиз-версию. Это имело смысл: я на Mac OS X, gtk у меня поставлено из макпортов и слинковано с макпортовой версией libiconv; хаскель в макпортах старый как это самое, бинарная сборка слинкована с системной libiconv, и с макпортовой gtk работать отказывается. Пришлось поставить бинарную сборку, а затем пересобрать её же, подсунув ей макпортовую libiconv.

Надо сказать, что процесс это был, хотя и долгий, но моего личного участия не требующий, если не считать самого начала.

[egorfine.livejournal.com]

Ты это видел?

https://www.facebook.com/photo.php?fbid=10150729122853640&set=a.446570498639.240991.774128639&type=1&theater

[http://users.livejournal.com/_adept_/]

А что там? "This content is not available or you do not have permissions ..."

[egorfine.livejournal.com]

[http://users.livejournal.com/_adept_/]

O_o

o_O

В голову приходит только мультик про козленка и "мама, он и меня посчитал!"