Загадка #2896973 решена. Раньше у меня была 32битная система, а теперь 64. То есть гхц оперирует длинными интами, а в сишке по-прежнему int, то есть 32битные. Я попробовал там поменять на long — стало в 2 раза медленнее, то есть разница уже ближе к той что раньше.

Непонятно что делать с хаскелом. Ставить весь гхц 32битный я не пробовал, я даже не уверен как это сделать в 64битной системе. Менять тип с Int на Int32 не помогло.

что-то проебались полимеры по сравнению с #1628193 — в ghc-8.0.2 самый быстрый вариант раз в 5 медленнее чем сишка. Интересно, это си так улучшилось или гхц ухудшилось? Даже не знаю как проверить, всё уже другое.

Закинул удочку в Serokell, которые вроде б то под руководством Дарта Вейдера^W^WPhilip Wadler пишут свой альткойн на Хаскеле. Питерские, но ищут remote чуваков.

Они созрели и прислали тестовую задачу зафигачить распределенный леджер на блокчейне на хаскеле, с указанным криптоалгоритмом и простеньким API.

Говорят, что работы на 8-9 часов, прислали небольшую заготовку, которая по юникс сокетам коммуницирует, API неможко парсит, таймауты там тестовые имплементит, которые нужны по ТЗ, молодцы.

Бросаться в это? Кто пропустил и хочет, могу зафорвардить, они раскидали тем, кто выразил интерес в середине декабря.

А добавить баг в ghc и патч к нему с описанием "Marlow сказал, что это должно бы работать так, а не как сейчас" — это халяль или пацаны не поймут? :)

Что-то в stack намудрили такого, что я не могу теперь ghc 7.8.4 на ubuntu использовать. Только несколько вариантов 8.x предлагает. Накатил системный 7.8.4 и пытаюсь понять, как заставить его использовать.

Ищу утечку памяти в программе, где ее в принципе не должно быть: нет рутов, за которые можно было бы зацепиться. Будет или очень глупо, или очень интересно.

У меня проблема. Мне почему-то кажется, что если для типа t можно сделать (а -> b) -> t a -> t b, то и Applicative f => (a -> f b) -> t a -> f (t b) тоже можно и любой Functor — всенепременно Traversable.

Алсо недавно обнаружил что у ассоциированных с классом типофамилий могут быть параметры отличные от параметров класса. Жить сразу стало заметно легче.

А кто-нибудь уже написал генератор линз с полиморфным апдейтом на генериках? С мономорфными легко. gist.github.com — вот например вариант, который зажёвывает Proxy t и возвращает линзы в виде гетеросписка. Тут есть несколько решённых и нерешённых проблем (особенно мне нравятся отдельные инстансы для Applicative и для Functor), но в целом речь не об этом. gist.github.com — попытка проделать это же с полиморфными линзами проваливается где-то в районе инстанса для f :*: g. А всё потому что тип полученного произведения типов зависит от того какой «множитель» мы меняем. Где-то на этом месте фантазия моя подиссякла.

а если у меня запускается 20 тысяч тредов с bracket_ (atomically $ incrementCounter1) (atomically $ decrementCounter1 >> incrementCounter2) someShit, и в конце получается counter1 отрицательный, а counter2 равный числу тредов, то это же пиздец? Или есть какие-то объяснения?

gist.github.com — предлагаю небольшую игру. Суть игры в том, что вы будете пытаться доказать мне что реализация легковесных регионов по ссылке неполноценна и надо взять regions, а я буду вносить правки в gist и делать вид что так и было.

ucnv_getMaxCharSize strikes back.

Ставлю text-icu на Windows:
```
stack exec — pacman -Sy mingw64/mingw-w64-x86_64-icu
stack build text-icu
```

После этого, при попытке его использовать:
```
Prelude> import Data.Text.ICU
Prelude Data.Text.ICU> :t Root
Root :: LocaleName
Prelude Data.Text.ICU> Root
ghc.EXE: addDLL: icudt (Win32 error 126): The specified module could not be found.
```

Ок. Нашёл, где лежат dll-ки, положил копии с нужными именами (icudt58.dll -> icudt.dll).
(На всякий случай: инфа о пакетах в <stack_root>\snapshots\<...>\pkgdb\*.conf)
Теперь такая ошибка:
```
Prelude> import Data.Text.ICU
Prelude Data.Text.ICU> Root
ghc.EXE: C:\stack_root\snapshots\61ba18c6\lib\x86_64-windows-ghc-8.0.1\text-icu-0.7.0.1-3ZPlchKHjedDm1t6cAa5us\HStext-icu-0.7.0.1-3ZPlchKHjedDm1t6cAa5us.o: unknown symbol `ucnv_getMaxCharSize_58'

ghc.EXE: unable to load package `text-icu-0.7.0.1'
```

Погуглил. Есть пара похожих случаев. То ли версии icu 57, 58 проблемные, то ли либа text-icu что-то не учитывает.
github.com
Ещё вспомнил про #2885797 .

В итоге скачал icu версии 59, удалил text-icu, переустановил text-icu с указанием путей до этой версии.
```
stack exec — ghc-pkg unregister --force text-icu
stack install text-icu --extra-lib-dirs=C:\...\icu59\bin64 --extra-include-dirs=C:\...\icu59\include
```
Заработало.

Меняем Network.URI на URI.ByteString, regex-tdfa на regex-pcre и получаем ускорение разбора урлов на порядок, с 10 тысяч в секунду до ста тысяч. Хотя сишечке все равно проигрывает в два-три раза, но это уже нормально.

Положим у меня есть тип data T f = T (forall a. f a -> a) и линза вида Lens (f x) (f x) x x, где f — полиморфный контейнер фиксированного размера. Могу я как-нибудь при помощи второго наполнить первое?