ghci что то сломалось

Попробуй из haskell оверлея.

Подписался.

Nensha, в оверлее есть свой ghci?

Nensha, в оверлее есть свой ghci?

(ghc) быть может он и одинаковый...

в любом случае флаг binary должен спасти отца чего-то там...

ghci это пара строчек на сях, запускающая ghc --interactive

Какая-то генто-проблема - http://www.haskell.org/pipermail/haskell-cafe/2012-May/101065.html, там тоже ничего не решили. Можно попробовать флаги, оверлей или просто самому поставить ghc и cabal.

В любом случае 7.4.2 есть только в оверлее =)

у меня работает за счёт binary, сейчас попробую без этого флага

ghci это пара строчек на сях, запускающая ghc --interactive

Только на sh, а не на сях.

Вам же четко ghc написал, что пакет base зафейлился. Мой вам совет: не ставьте хаскеллевые либы через гентушный пакетный менеджер и не будет таких проблем. А пока могу дать два совета по решению проблемы:

1. Перемерджите пакет base (хз, в какой гентушный пакет он у вас входит, сами разберетесья, я думаю)

2. fuck the system! Через cabal-install поставьте локальную версию base или глобально через ключ --global (чревато!)

Перемерджите пакет base

Находится он в пакете GHC-7.4.2 как ни странно

fuck the system!

Вообще пробовал собрать haskell-platform из сорцов в хомяк, но были ошибки компиляции, как всегда загадочные без четких сообщений что не так.

Пересборка base из cabal-install не получается, говорит что пакет уже установлен (что вполне логично), персборку GHC выполнял без результатно.

Может есть рецепт кроссдистрибутивной установки haskell-platform и GHC в хомяк ? Ну то есть даже GHC не ставить из пакетника ?

Может есть рецепт кроссдистрибутивной установки haskell-platform и GHC в хомяк ?

Скачать бинарную сборку GHC, сделать ./configure --prefix=хомяк && make install. Потом скачать cabal-install и сделать sh bootstrap.sh, добавить $HOME/.cabal/bin в $PATH, сделать cabal update и дальше cabal install что угодно. Платформу НЕ ставить.

Ну и если ставить GHC в /home, то тоже обновить ему PATH, конечно.

лады, попробую дома.

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

У меня работает и собранный. Попробуйте собрать с флагом binary,

1. откройте bug в нужном месте

2. приложите emerge --info

и да,

fuck the system! Через cabal-install поставьте локальную версию base или глобально через ключ --global (чревато!)

http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a...

Учить параграф: Why you should use your distribution’s package management system

А ты ставь больше через дистр. Оне тебе понаставят.

Хотя действительно странно... Криво слинкировалось?

Лично я беру бинарники с офсайта и ставлю их в ~/opt/ghc (configure --prefix=$HOME/opt/ghc && make install)

Cabal по-умолчанию с опцией --user хранит пакеты в ~/.cabal

Ставлю cabal-install c опцией --user (с ним по-жизни масса мороки). После чего, добавляю ~/opt/ghc/bin и ~/.cabal/bin в PATH

Затем cabal install alex; cabal install happy

Cabal-install понимает, что пакеты писать нужно в юзерскую область.

Все отлично работает, хранится в хомяке и не засоряет систему (Ubuntu x86_64).

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

Учить параграф: Why you should use your distribution’s package management system

Если человек думает, что пакетный менеджер нежен не для менеджа пакетов, то тут уже поздно что-то учить.
«Fuck the system!» же

Подробные описания подстилок и подпорок на пять предложений замечательно подчёркивают отличность и удобность работы.

Особенно хорошо убунта проявляет себя при новом релизе гхц
!

Особенно хорошо убунта проявляет себя при новом релизе гхц

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

Платформу НЕ ставить.

А почему, собственно?

А почему, собственно?

Ну, данный способ предполагает установку минимума - GHC и утилиты cabal-install (cabal-install is a package manager, but with lack of 'unmerge'), всё остальное можно доставить. Платформа это несколько другой способ - может кому-то и нужно. Она, в принципе, ставится точно так же - сначала GHC, потом тарбол платформы вместо тарбола cabal-install и уже вместе с дополнительными пакетами, которые, возможно, и не нужны (OpenGL, например, не всем нужен).

Звучит так, как будто платформа не является простым множеством пакетов с фиксированными версиями.

but with lack of 'unmerge'

Но соответствующий костыль легко пишется.

ghc / driver / ghci / ghci.c это виндовое чтоли?

Там рядом даже ico есть. В ghc.mk условная компиляция - shell везде кроме Windows и ghci.c для Windows.

спс, буду знать

В тред призывается разработчик Gentoo из Haskell team

cast qnikst

Сиё достопочтенное заведение уже представляет Nensha

Вам же четко ghc написал, что пакет base зафейлился. Мой вам совет: не ставьте хаскеллевые либы через гентушный пакетный менеджер и не будет таких проблем.

это конечно ЛОР, но всё же убедительно попрошу не давать вредных советов. Спасибо за понимание.

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

ща попробую в коробке воспроизвести и там уж разбираться будем. А то единственный живой ноут у меня с outdated версиями.

ух-ты Nensha уже тоже успел в девах оказаться? о.О =)

Научитесь сначала хаскелевые пакеты через свой portage правильно контролировать, а потом учите, что вредно, а что полезно.

конкретные проблемы назовёшь? пока управление пакетами через emerge удобнее _любого_ из остальных вариантов, т.к. хотябы наличием haskell-updater.

и да ТС, #gentoo-haskell или issue tracker оверлея это гораздо более правильное место, чтобы решить проблему, если ты в это заинтересован.

и да, по поводу проблем, и того, что такое «правильно» я спрашиваю вполне серьёзно, можно и вне ЛОРа.

issue tracker оверлея

А где такое есть ?

Я вот думаю что «правильно» это когда твой хаскелевый пакет можно всегда развернуть на любой системе (в идеале даже офтопик), по этому ставить пакеты из portage и рассчитывать, что везде будет только уютненький гентомирок - это не сурьезно. Жабы, питоны, руби, лиспы - у всех свой пакетник, который умеет ставить пакеты в хомяк, и управлять ими независимым от дистра способом. Это еще более актуально для хаскеля, у которого версия библиотеки может сильнее влиять на результат чем название лол.

Квест пройден на домашнем компе запустился leksah, кстати почему его называют устаревшим Г ? Работает прекрасно, настоящая ИДЕ для хаскеля.

Проверю на работке - отпишусь.

https://github.com/gentoo-haskell/gentoo-haskell/issues

но на irc://#gentoo-haskell@freenode.net может быть и быстрее, правда лучше быть там где-то днём по MSK.

есть только 1 способ правильно написать билд систему хацкельного пакета это использовать .cabal. И это совершенно никак не относится к разворачиванию пакета в системе.

Для того, чтобы не превращать систему в помойку есть два способа: 1). быть Ъ lxf-щиком, 2). использовать пакетный менеджер дистрибутива.

Что такое ebuild для haskell пакетов - это обёртка вокруг сборки кабалом, которая так же указывает зависимости так, чтобы их понимал пакетный менеджер генты. Так же возможность подправить зависимости, т.к. зачастую в пакетах на hackage они излишне жесткие, и добавить патчи, т.к. зачастую без них пакеты могут криво работать. Все эти исправления делаются сразу и по возможности отдаются в апстрим.

При этом в 95% ebuild генерируется автоматически, программой hackport.

Таким образом: при использовании пакетного менеджера ты получаешь system-wide консистентный набор пакетов, которые протестированы (минимум на собираемость вместе + тесты в пакетах).

Учитывая, что haskell пакеты используют статическую линковку + очень сильно изменчивый ABI + то что кабал сам не разруливает изменения в dependencies (что приводит к смене ABI), использование менеджера пакетов это очень логично. Т.к. ручное управление приводит к танцам с ghc-pkg --unregister и в конечном счёте часто проще удалить .cabal, чем разбираться.

P.S. можешь ещё посмотреть как сделаны g-ctan, g-cpan и т.п. для летехов, перлов, пхп идея та же.

ух-ты Nensha уже тоже успел в девах оказаться? о.О =)

Та для меня тоже новость... Я пока только wannabe :3

Я вот думаю что «правильно» это когда твой хаскелевый пакет можно всегда развернуть на любой системе

Не правильно. Если я хочу установить Leksah на win я скачаю msi или другой нормальный установщик, если я захочу установить на RedHat я буду использовать rpm, если я захочу установить на LFS я буду писать скрипты, которые заменят мне то, что делает portage.

Квест пройден на домашнем компе запустился leksah, кстати почему его называют устаревшим Г ?

Тоже иногда им пользуюсь, не знаю почему.

Научитесь сначала хаскелевые пакеты через свой portage правильно контролировать, а потом учите, что вредно, а что полезно.

Ну ты ведь знаешь как их «правильно» контроллировать и уже готов поделиться своими достижениями?

Ну ты ведь знаешь как их «правильно» контроллировать и уже готов поделиться своими достижениями?

Да, я знаю, как правильно. У хаскеля пакеты не раскиданы по всему интернету, а хранятся в одной базе на hackage (за редкими исключениями), и есть свой пакетный менеджер. Вот и оставьте хаскель в покое. Пусть все зависимости и конфликты разруливают cabal-install и ghc-pkg.

А то получается какое-то половинчатое решение. Какие-то пакеты у вас в дереве есть, каких-то нет и начинаются танцы с бубном при установке тех пакетов, которых у вас нет в вашем portage.

В чем конкретно мои претенции к portage в отношении haskell сейчас уже не скажу, потому что бросил это дрочерство где-то год назад и обратно на генту что-то не тянет. Помню только, что долго мучился с portage и в итоге плюнул и поставил все ручками через cabal-install.

Эта претензия ко всем породам linux относится, кстати. Нафига пихать в свои базы пакетов хаскелевые либы, если не в состоянии заменить cabal-install и hackage?

У хаскеля пакеты не раскиданы по всему интернету, а хранятся в одной базе на hackage

если ты читал, что написал qnikst, то именно их-то все и используют

и есть свой пакетный менеджер

где?

Пусть все зависимости и конфликты разруливают cabal-install и ghc-pkg

ещё раз повторяю специально для вас... http://en.wikipedia.org/wiki/Package_management_system

a collection of tools to automate the process of installing, upgrading, configuring, and removing software packages from a computer.

cabal-install и ghc-pkg никак не могут отлеживать non-cabal зависмости в системе (да, если ты посмотришь в оверлей скажем, то оказывается таких зависимостей очень много) - это лишь первый шаг как вы будете загаживать свою систему, кроме того как cabal-install будет решать проблемы совместимости? поддержка stable / unstable, вся работа этих пакетов будет просто отдельно жить от системы, но вы забываете как она зависит он неё, поговори с меинтейнерами cabal-install, Common Architecture for Building Applications and Libraries is not designed to be a package manager.

Какие-то пакеты у вас в дереве есть, каких-то нет и начинаются танцы с бубном при установке тех пакетов, которых у вас нет в вашем portage

hackport merge x11-wm/xmonad - если это танцы с бубном, то мне вас просто жаль, но да действительно часто не хватает просто взять пакет из hackport, на некоторые пакеты накладываются патчи, корректируются зависимости и делается другая работа, что бы облегчить пользователям жизнь.

Помню только, что долго мучился с portage и в итоге плюнул и поставил все ручками через cabal-install.

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

ещё раз повторяю специально для вас... http://en.wikipedia.org/wiki/Package_management_system

Какой-то убунтоид не знает, что бывают и другие пакетные менеджеры. И что?

если ты читал, что написал qnikst, то именно их-то все и используют

Спасибо, Кэп, а я и не знал...

cabal-install и ghc-pkg никак не могут отлеживать non-cabal зависмости в системе (да, если ты посмотришь в оверлей скажем, то оказывается таких зависимостей очень много) - это лишь первый шаг как вы будете загаживать свою систему, кроме того как cabal-install будет решать проблемы совместимости? поддержка stable / unstable, вся работа этих пакетов будет просто отдельно жить от системы, но вы забываете как она зависит он неё, поговори с меинтейнерами cabal-install, Common Architecture for Building Applications and Libraries is not designed to be a package manager.

Знаешь... И об этом я в курсе, но это еще не повод городить свои костыли в отдельно взятой системе. К тому же кроме cabal-install (который 'not designed to be a package manager') есть еще ghc-pkg. Он тоже не пакетный менеджер? А вместе?

С зависимостями от нехаскелевых библиотек и программ конечно сложно, но проблему эту нужно решать несколько иначе, чем пытаясь интегрировать hackage в систему. Вы, конечно, можете думать по-другому, это лишь мое мнение.

hackport merge x11-wm/xmonad - если это танцы с бубном, то мне вас просто жаль, но да действительно часто не хватает просто взять пакет из hackport, на некоторые пакеты накладываются патчи, корректируются зависимости и делается другая работа, что бы облегчить пользователям жизнь.

Про hackport не знал. Спасибо, но уже не попробую. Но все равно спасибо.

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

portage и экосистема действительно не так сложны, но в некоторых случаях они добавляют лишние ограничения и использовать их становится неудобно. Gentoo я бросил по другой причине в любом случае. У меня банально слабый комп, чтобы постоянно что-то компилировать. И напоследок...

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

Многим хочется работать, а не настраивать постоянно систему. С этим я соглашусь.

Какой-то убунтоид не знает, что бывают и другие пакетные менеджеры. И что?

facepalm, Нужно было почитать: что такое пакетный менеджер

И об этом я в курсе, но это еще не повод городить свои костыли в отдельно взятой системе.

Ещё как повод! А «костылями» я назову ваши действия по обновлению пакетов, контроль зависимостей, удаление пакетов с зависимостями, обновление базовой платформы и пр...

Вы, конечно, можете думать по-другому, это лишь мое мнение.

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

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

Все ограничения так же просто снимаются при желании, разве нет?

У меня банально слабый комп, чтобы постоянно что-то компилировать.

Ну в это я не поверю. 1 - это обширная база бинарных пакетов 2 - это ваше «постоянно».

Многим хочется работать, а не настраивать постоянно систему. С этим я соглашусь.

Только уберите слово постоянно. Конечно, многие из нас одержимы этим, может быть даже и я (хотя для работы уж как-то нахожу время, ну когда на лоре не сижу), но другая половина спокойно работает =) Слишком как-то часто у вас «постоянно».

Замените слово «постоянно» на «систематически». Уже легче?

Спасибо, Кэп, а я и не знал...

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

Знаешь... И об этом я в курсе, но это еще не повод городить свои костыли в отдельно взятой системе. К тому же кроме cabal-install (который 'not designed to be a package manager') есть еще ghc-pkg. Он тоже не пакетный менеджер? А вместе?

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

1). ты накатал кучу больших постов, но так и не удосужился объяснить почему это костыли. Действительно, для пользователя появляется только одна новая проблема - сгенерировать ебилд хакпортом; ну на самом деле ещё подправить зависимости, из-за одной полезной политики haskell-team. Зато в замен у пользователя существует 1). единое средство управления пакетами (а не костыль под язык) 2). средство опознавания и разрешения блокировок, 3). средство восстановления системы. Разница на порядок, сравнимый уровень удобства может быть только в контролируемой помойке типа nixos, но AFIU там тоже используются свои пакеты.

Многим хочется работать, а не настраивать постоянно систему. С этим я соглашусь.

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