Dmitry
Ну вот я уже заметил :(
Dmitry
1 млн Int64 за 3.9 сек :(
Dmitry
Печаль!
A64m
это в каком векторе?
Dmitry
В Vector.Storable
Dmitry
Лучше другой?
A64m
не, нормально
Dmitry
А я правильно понимаю, что запись вида let !v = V.unfoldrN ... (1::Int64) приведёт к тому, что в v будет уже полностью вычисленное значение? Т.е. v не надо дополнительно форсить, правильно?
IC
https://nim-lang.org/assets/img/features/gc_latency.png всем гореть полчаса
A64m
> let !v = U.fromList [error "BANG!"] :: U.Vector Int in error "GNAB!" v
*** Exception: BANG!
error, called at <interactive>:18:22 in interactive:Ghci9
> let v = U.fromList [error "BANG!"] :: U.Vector Int in error "GNAB!" v
*** Exception: GNAB!
A64m
а что такого? вроде известно что у хаскеля паузы примерно как у явы, но похуже. еще и дефолтные настройки небось
A64m
только максимальная пауза как метрика смысла не имеет
A64m
http://mattwarren.org/images/2014/06/gc-pause-times-comparision.png
A64m
т.е. видно что у параллельного и псевдоконкурентного сборщика (CLR в данном случае) максимальные паузы примерно одинаковые.
A64m
разница в том, насколько часто эти паузы случаются
IC
https://github.com/WillSewell/gc-latency-experiment/blob/master/haskell/Dockerfile дефолтные )=
A64m
https://files.gitter.im/ruHaskell/forall/DzWB/blob
A64m
паузы хаскельного ГЦ дефолтные vs нормальные
Cheese
тогда «да, WHNF»
A64m
см. пример выше, естественно для боксед вектора
> let !v = V.fromList [error "BANG!"] :: V.Vector Int in error "GNAB!" v
*** Exception: GNAB!
A64m
тут без сюрпризов
Dmitry
А почему в error "GNAB!" v происходит вычисление второго аргумента?
A64m
не происходит, конечно
Dmitry
Вот тут:
let !v = U.fromList [error "BANG!"] :: U.Vector Int in error "GNAB!" v
*** Exception: BANG!
error, called at <interactive>:18:22 in interactive:Ghci9
Dmitry
А откуда тогда "BANG" ?
A64m
так в том и дело что из-за банга вектор раньше кидает исключение, чем error "GNAB!"
Dmitry
Это банг так меняет поведение let?
A64m
да, ну собственно для чего он и нужен
Dmitry
Перечитал про bang pattern'ы, стало ясно :)
Dmitry
А с -fllvm -optlo-O3 ещё бодрее!
Dmitry
Хех, сортировка 1 млрд (Int64, Int64) за минуту, ляпота. Можно даже в C не переходить, и так норм.
Хаскель
Усё. Одолел
https://github.com/uzhas-sovka/Haskell
Хаскель
замечания приветствуются.
Хаскель
Дока по hover не подхватывается. Хаддок и хугл сделал. В этот раз не ставил ничего с хаскель.орг. Может, в этом причина?..
Хаскель
Вчера в логе hie повсюду были
got HoverRequest:RequestMessage
сегодня на свежей инсталляции такого нет...
A64m
да, если так дела пойдут, может и дженерики с рекордами > 10 полей можно будет использовать
https://phabricator.haskell.org/D4766#132856
A64m
кто-то, оказывается, работает над GRIN бекендом https://github.com/grin-tech/grin
просмотрел по диагонали, в качестве фронтенда там GHC и idris
Alexander
тут на zurihack есть те кто работают
A64m
интересно, что не смотря на то, что они выдернули GRIN бекенд из JHC, это, похоже, не он, а заново написанный
Влод
а хаддок генерит же документацию для реэкспортов? (реэкспортов модулей и отдельных функций)
Нурлан
кто-нибудь может помочь со stack?
Нурлан
🙁
Нурлан
"""
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Already downloaded.
Installing GHC ...
Received ExitFailure 2 when running
Raw command: /usr/bin/make install
Run from: /Users/Kit/.stack/programs/x86_64-osx/ghc-8.2.2.temp/ ghc-8.2.2/
"""
Влод
а что не так?
Влод
ааа
Влод
https://github.com/commercialhaskell/stack/issues/3741
Влод
ну вот может тебе станет легче если ты поймёшь что ты не один
Влод
не знаю чем помочь
IC
> Looks like this was fixed in 8.4.1
stack setup --resolver nightly
A64m
да ладно, там какие-нибудь другие проблемы будут. гхц нормально поддерживается только на убунте, никс-ос и, может, генте, да и то врядли
A64m
(да и то не стекоделами, которым давно плевать на все)
Хаскель
На моей винде нормально стало.
A64m
повезло
Хаскель
Но я, подчёркиваю, не даю советов переходить на другие оси, как мне давали на других площадках сегодня. Только фпирёд!
Хаскель
Дока по ховеру не фурычит.
Хаскель
Вчера вся битва, оказывается, была за то, чтобы Script нормально в Атоме стек запускал.
Хаскель
HIE по существу не работает.
A64m
ну у меня-то hie на виндовс работает, я просто уже рефлекторно, видимо, прыгаю через все горящие кольца и не замечаю
Хаскель
Я сегодня воспроизвёл всё, что вчера сделал, и таки он не фурычит. Вчера заработал случайно.
Хаскель
Не ясно, куда копать.
A64m
я hie ставил так: клонировал, билдил, копировал бинарь туда, где его в путях видно. после этого вс код просто работает
A64m
но я понимаю, что у большинстав так просто все не заработает
A64m
(для 8.0.2 надо править стековый файл, чтоб использовать более новую версию yi-rope, правда)
Зигохистоморфный
Atom говна кусок
A64m
обычная история
Хаскель
я hie ставил так: клонировал, билдил, копировал бинарь туда, где его в путях видно. после этого вс код просто работает
Что-то странное. При клонировании yaml в заголовке
resolver: nightly-2018-06-02 # GHC 8.4.3
Соответственно пихается он в C:\sr\compiler-tools\x86_64-windows\ghc-8.4.3\bin\hie.exe
Хаскель
А вчера запихался в
C:\sr\compiler-tools\x86_64-windows\ghc-8.2.2\bin\hie.exe
Хаскель
Как такое может быть, если я ничего не менял?..
A64m
авторы hie поменяли, наверное. там постоянно повышается версия ghc который они собирают стеком по умолчанию
A64m
чтоб нужную версию собирать, надо вручную стековый файл указывать stack --stack-yaml=stack-8.2.2.yaml install
Хаскель
Ща попробую. Sounds reasonable.
Зигохистоморфный
чтоб нужную версию собирать, надо вручную стековый файл указывать stack --stack-yaml=stack-8.2.2.yaml install
Да как бы это в ридми написано. Странно, что люди такие ленивые
A64m
не знаю, насчет лени, по моему, ситуация, когда ленгвидж-костыль надо с гитхаба забирать и самому билдить - ненормальная.
Хаскель
В этом и есть вся писечка: только сильные духом проникают к Хаскеллю.