to post messages and comments.

Хочу плагин к GHC, который вычисляет какие исключения может бросать функция. Причем, какой-нить тупой, ей даешь на вход текстовый файлик со списком:

Module.function : Module.Exception

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

А какие существуют рекомендации по дефолтному количеству ядер и вообще железу для хаскелльных приложений? Есть приложение, где не получается честно замерить пока что, а рекомендации по железу уже нужны. С ОЗУ там понятно — чем больше, тем лучше, а по количеству ядер ЦПУ капается производительность где?

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

а можно каким-то образом отключать ghc-options: -event-log, если через cabal/stack включается --profile? Просто обычно с профилем не собираешь, а -event-log удобно выносить сразу в cabal файл, чтобы не забывать с ним собирать, т.к. с его поддержкой код пойдет в т.ч. в production.

1.hs:16:1: error:
• Invalid declaration for ‘FieldType’; you must explicitly
declare which variables are dependent on which others.
Inferred variable kinds:
p :: N
t :: Type
i :: Fin p
• In the type synonym declaration for ‘FieldType’


А вот как это явно указать?

‰ time cabal build
Package has never been configured. Configuring with default flags. If this
fails, please run configure manually.
Resolving dependencies...
Configuring muesli-0...
Building muesli-0...
Preprocessing executable 'Muesli' for muesli-0...
[1 of 2] Compiling Muesli ( Muesli.hs, dist/build/Muesli/Muesli-tmp/Muesli.o )
[2 of 2] Compiling Main ( Main.hs, dist/build/Muesli/Muesli-tmp/Main.o )
Linking dist/build/Muesli/Muesli ...
cabal build 567.09s user 79.04s system 116% cpu 9:16.86 total
‰ du -sh dist/build/Muesli/Muesli
10M dist/build/Muesli/Muesli
‰ strip dist/build/Muesli/Muesli
‰ du -sh dist/build/Muesli/Muesli
6.2M dist/build/Muesli/Muesli

Три гига рамы выжрал алсо.

Make the crash happen as early as possible. -debug already turned on lots of assertions, one of which might trigger. Also, try +RTS -DS which turns on a bunch of extra "sanity checking", i.e. expensive assertions about the state of the runtime at regular points. One thing this enables is a full sweep of the heap after each garbage collection to make sure there are no dangling references. Also, it fills all free memory with the value 0xaaaaaaaa (the sound of GHC disappearing down a hole).

Запиливал проект на ghc-7.10.1.
Думаю, а попробую.
Собираю проект с stack.
stack init --solver # честно выкачивает 7.10.1
stack build
Два часа проходит, и не справляется.

Качаю 7.10.2.
rm -rf stack
Пересобираю stack.
Пересобираю проект cabal + ghc-7.10.2.
Думаю, а попробую.
Собираю проект с stack.
stack init --solver
stack build
Два часа проходит, и не справляется.

Образовалась забавная проблема: один и тот же код собранный ghc 7.6.3 и ghc 7.8.4 после запуска занимает разный private bytes. 6 Мб и 104 Мб соответственно.
Всё бы ничего, но во втором случае довольно быстро кончается память. Подскажите куда копать.
ghc 32 битный, система 64 битная.

Интересно, а реально ли портировать GHC на UEFI окружение, чтобы можно было писать ФП-буткиты^W красивые загрузчики с блекджеком и шлюхами?
С чего следует начать? Наверно с запиливания возможности генерить бинарники диалекта PE+, используемого в UEFI? Разделяемых библиотек в UEFI нет, всё динамически через COM^W интерфейс «протоколов», так что хаскелистам не привыкать. Хотя, первым делом придётся портировать integer-gmp на UEFI...
Может быть кто-то из таких же извращенцев уже данным вопросом занимается?

В продолжение предыдущему посту:

```
Prelude Control.Exception> error "a" `catch` (\e -> getMaskingState >>= print . flip const (e :: SomeException))
MaskedInterruptible
Prelude Control.Exception> getMaskingState
Unmasked
```

Вот такое вот "ха-ха". Надо теперь потестить мелкие паттерны и подумать как теперь жить с этим знанием и насколько часто можно было допустить ошибку. Т.е. не пускать действие из exception handler а делать верно, т.е.

не

go `catchSome` (const go)

а, например,

let fix f = maybe (fix f) return (Just <$> f `catchSome` (cont $ return Nothing))
in fix go

Кто-нибудь может пояснить по: (комментарий из rts/Exceptions.cmm)

Furthermore, asynchronous exceptions are masked automatically during the execution of an exception handler.

Т.к. это выглядит очень странно и go `catch` (const go) явно ж не должен
пускать go второй раз с замаскированными исключениями. Ползать по всему коду base, чтобы проследить что там происходит мне лень :)



полный текст:


A thread can request that asynchronous exceptions not be delivered
("masked") for the duration of an I/O computation. The primitives

maskAsyncExceptions# :: IO a -> IO a

and

maskUninterruptible# :: IO a -> IO a

are used for this purpose. During a masked section, asynchronous
exceptions may be unmasked again temporarily:

unmaskAsyncExceptions# :: IO a -> IO a

Furthermore, asynchronous exceptions are masked automatically during
the execution of an exception handler. All three of these primitives
leave a continuation on the stack which reverts to the previous
state (masked interruptible, masked non-interruptible, or unmasked)
on exit.

без Functor m
compiler/utils/MonadUtils.hs:82:10:
Could not deduce (Functor m)
arising from the superclasses of an instance declaration
from the context (Monad m)
bound by the instance declaration
at compiler/utils/MonadUtils.hs:82:10-44
Possible fix:
add (Functor m) to the context of the instance declaration
In the instance declaration for ‘Applicative (StateT s m)’

с Functor m
compiler/utils/MonadUtils.hs:82:10: Warning:
Redundant constraint: Functor m
In the instance declaration for ‘Applicative (StateT s m)’

про то какие пакеты стоит проверить на предмет того, что удаление зависимости от трансформеров их не поломает:

Don't worry, we've never given any promise about GHC APIstability across major versions (or minor versions, for that
matter.)

ghc

написал предложение по тому чтобы избавиться от зависимостей от трансформеров в ghc-lib (с proof of concept патчами, конечно же). тут же пришли дебьяновый меинтейнер и стакановый начальник и очень поддержали идею, надеюсь удастся протолкнуть (правда в 7.12 уже скорее всего).

7.8.4 собирает, а 7.10 нет, есть идеи куда копать?

src/Control/Eff/Cut.hs:70:2:
Illegal equational constraint Data.OpenUnion.Internal.OpenUnion2.Member'
Choose r
~ 'True
(Use GADTs or TypeFamilies to permit this)
When checking that `loop' has the inferred type
loop :: forall r a.
(Data.OpenUnion.Internal.OpenUnion2.Member' Choose r ~ 'True) =>
[Eff (Exc CutFalse :> r) a]
-> Free (Union (Exc CutFalse :> r)) a -> Eff r a
In an equation for `call':
call
= loop []
where
loop jq
= freeMap
(\ x -> return x `mplus'` next jq)
(\ u
-> case decomp u of {
Right (Exc CutFalse) -> ...
Left u' -> ... })
check ::
Member Choose r =>
[Eff (Exc CutFalse :> r) a]
-> Union r (Eff (Exc CutFalse :> r) a) -> Eff r a
check jq u | Just (Choose [] _) <- prj u = next jq
check jq u | Just (Choose [x] k) <- prj u = loop jq (k x)
check jq u | Just (Choose lst k) <- prj u = next $ map k lst ++ jq
check jq u = send u >>= loop jq
next :: Member Choose r => [Eff (Exc CutFalse :> r) a] -> Eff r a
....