Окно в закабаленный мир не нужно :)
2012-04-19 06:10 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dastapovЯ тут читал залежи в google reader и наткнулся на пост, озаглавленный "Окно в закабаленный мир". В нем были описаны какие-то жуткие ужасы о том, как сетапить окружение для разработки на Haskell, и я хотел бы рассказать, как это делал я. Писать буду только про Linux, т.к. с Windows у меня никакого опыта нет.
В Страшном Посте пишут "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 update && cabal install cabal-install. Все, у нас новый cabal, руками собирать ничего не надо.
Дописываем в PATH директорию ~/.cabal/bin, куда по умолчанию ставятся бинарники из устанавливаемых бинарных пакетов, и на этом возня с cabal-install заканчивается.
У меня как-то не наблюдалось описываемых автором ужасов про то, что 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, и пять-десять собственных пакетов в работе. Так что я уверенно утверждаю, что сложно делать не надо, надо делать просто. </растопыривание пальцев>
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, и пять-десять собственных пакетов в работе. Так что я уверенно утверждаю, что сложно делать не надо, надо делать просто. </растопыривание пальцев>
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2012-04-19 05:26 pm (UTC)а вот про конфликты зависимостей из --global и локальных в кабале наслышан не только я
(no subject)
Date: 2012-04-19 06:09 pm (UTC)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 - отказываюсь от винды.
(no subject)
Date: 2012-04-19 06:42 pm (UTC)Ну ладно, собирать, с грехом пополам, научились. Ну, смогли с помощью кабалы собирать инсталляторы. А дальше? Intellisence? Дебаггинг?
В Eclipse давно есть (http://eclipsefp.sourceforge.net/ocaml/index.html) поддержка OCaml.
Про видимо-студию и F# вообще молчу, там всё в одном флаконе, включая
кривыеbreakpoints.(no subject)
Date: 2012-04-19 06:47 pm (UTC)(no subject)
Date: 2012-04-19 06:57 pm (UTC)(no subject)
Date: 2012-04-19 07:06 pm (UTC)кстати, для подобной мелочи, которая появляется в процессе хода времени, хороша жаббер-конференция ocaml@conference.jabber.ru , там про TypeRex обсуждали уже весьма давно. (хотя, "давно" -- это не какое-либо обвинение, ни в коем случае.)
(no subject)
Date: 2012-04-19 07:20 pm (UTC)А как эклипс+окамл ведут себя на больших проектах - есть опыт? Если так же, как с явой, я лучше пешком постою. Подозреваю, что так же, и тормознутость там от эклипса, а не от языка.
Автодополнение меня устаивает в исполнении hippy-expand в emacs, ocamlspot закрывает вопрос с "а какого типа у нас вот это выражение?", а большего мне не надо. Отлаживать локально то, что я пишу, один фиг не выйдет, так что отладчик и брейкпоинты меня не греют. Впрочем, на TypeRex я таки собираюсь смотреть, только руки пока не дошли.
(no subject)
Date: 2012-04-19 10:29 pm (UTC)А Вы пользуетесь этим плагином? Смущает "early development stage (alpha)" и отсутствие обновлений с 2004 года (актуальный репозиторий я не смог найти). EclipseFP для Haskell (форком которого, как я понимаю, является окамловый) выглядит поживее (http://eclipsefp.github.com/).
(no subject)
Date: 2012-04-20 10:44 am (UTC)Надо сказать, что процесс это был, хотя и долгий, но моего личного участия не требующий, если не считать самого начала.
(no subject)
Date: 2012-04-20 01:54 pm (UTC)(no subject)
Date: 2012-04-20 02:04 pm (UTC)Не могу найти ссылку, но, кажется у Thomas Petricek была статья на эту тему. Суть её - в том, что проблема даже не в ленивых вычислениях, а в немутабельности. Нет переменных - теряется смысл breakpoints и watch.
Но есть смысл смотреть на параметры вызова. А эти параметры не все среды умеют нормально показать.
Нет, больших проектов не катал, только для себя баловался.
(no subject)
Date: 2012-04-27 05:50 pm (UTC)https://www.facebook.com/photo.php?fbid=10150729122853640&set=a.446570498639.240991.774128639&type=1&theater
(no subject)
Date: 2012-04-27 08:11 pm (UTC)(no subject)
Date: 2012-04-27 08:23 pm (UTC)(no subject)
Date: 2012-04-27 08:36 pm (UTC)o_O
В голову приходит только мультик про козленка и "мама, он и меня посчитал!"