что может означать, когда stack repl не грузит модуль, потому что он объявлен в нескольких файлах и дальше список из двух одинаковых файлов? причем проблема как-то проходит сама

> The proposal is that class arguments in contexts of type signatures and class declarations may be arbitrary types, e.g. > g :: (C [a], D (a -> b)) => [a] -> b

если кто-нить человеческими словами напишет объяснение то спасибо

а лучше пример для чего там оно конкретно в файле нужно было

вернее не двух одинаковых, конечно, а один и тот же файл присутствует в списке дважды

wuss-1.1.6: unregistering ... » add one package; rebuild everything » from stack, with love > yeah, I'm often struck by how much stack likes building

как правильно писать и читать big endian числа? в качестве несущей, например, ByteString

какая правильная библиотека для этого?

cereal?

binary например

если даблы, и старая версия байнери, то binary-ieee754 еще понадобится

старая версия байнери — это какая?

там неправильный Double?

В binary наркоманская кодировка даблов: 24 байта,, неверно кодируются трансфинитные числа

В binary наркоманская кодировка даблов: 24 байта,, неверно кодируются трансфинитные числа

А зачем оно так было?

Ну типы чтобы не привязываться к IEEE754... Тяжелое насление RealFloat

Ужас

λ> Data.ByteString.Lazy.length $ Data.Binary.encode (0 :: Double) 13

да не сериализационным интерфейсом байнери, а байточесательным

где всякие getInt32le

там неправильный Double?

там емнип вообще его нету

да не сериализационным интерфейсом байнери, а байточесательным

что не так с сериализационным?

старая версия байнери — это какая?

во времена 8.0 была еще старая, времен всяких 8-х лтс-ов

там емнип вообще его нету

есть, но странный. я выше привёл 13 байт

что не так с сериализационным?

не дает выбрать как именно байты чесать

Они формат таки сломали? Было же 24, точно помню

есть, но странный. я выше привёл 13 байт

я же говорю, речь про функции типа putFloat64be

не дает выбрать как именно байты чесать

на входе 4 байта, на выходе Word32, в документации BigEndian. какие варианты для чесания?

@qnikst спаммеры ^

я же говорю, речь про функции типа putFloat64be

они неправильные? не IEEE?

в старой версии ИХ НЕТ

@catamorphism fixed

спасибо

а что у нас сэры, пэры и прочие господа для графов юзают?

IntMap

если же надо читать Word32 то даже допотопной вресии байнери достаточно, без второго пакета

в старой версии ИХ НЕТ

в текущей тоже нет. спасибо, я разобрался

а что с бекендсикретом?

поломался?

хаскелиты всех разогнали

IntMap

я надеюсь это не про графы ответ

про графы

в текущей тоже нет. спасибо, я разобрался

как нет-то вот они https://hackage.haskell.org/package/binary-0.9.0.0/docs/Data-Binary-Get.html#v:getDoublebe

я чего-то в этой жизни не понимаю в таком случае

ну везде где нужны были графы, ничего специального не использовали

как нет-то вот они https://hackage.haskell.org/package/binary-0.9.0.0/docs/Data-Binary-Get.html#v:getDoublebe

хм, я искал Float16, Float32, Float64

а работали поверх Int или HashMap

в зависимости от задачи

хм, я искал Float16, Float32, Float64

они так в в отдельном пакете назывались

Зефиров в parsci такое писал http://hackage.haskell.org/package/GraphHammer

> analyses

@catamorphism hi there, smug asshole https://twitter.com/Hillelogram/status/978836401092427776

> analyses

PRs are welcome

хотя там вроде некуда PR делать

@catamorphism hi there, smug asshole https://twitter.com/Hillelogram/status/978836401092427776

дым от пердаков аж из окна видно

в общем если кому надо я наверное могу восстановить код по tgz

они так в в отдельном пакете назывались

эх, теперь они в обоих называются Floatbe и Doublebe. а 16-разрядного в обоих нет

не уверен что GraphHammer юзабельный

а они в IEEE754 вообще есть?

single - 32, double 64

а half

ок

для half была либа у кметта

/me помнит как half (через openexr) 10 лет назад завоевал индустрию графония. И как потом игроделы приписали победу себе

Я с double precision алетаю на проблемы с округлением и переполнения. Как жить с half вообще не представляю

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

half для хранения по большому счёту

Я с double precision алетаю на проблемы с округлением и переполнения. Как жить с half вообще не представляю

long double!

И на точность плевать. Там же 3-4 значащих цифры

quad precision тогда уж

ну и судя по смешным роликам из игр понятно как они там физику считают

А как надежнее отсечки сделать, чем с помощью threadDelay? threadDelay дает слабые гарантии что выполнение к этому треду перейдет когда надо(ну и я из него хочу другие треды покиллять).

у тебя это действительно проблема?

теоретизирую

я просто думаю что не узнаю даже, если это будет проблемой

в рамках чистого haskell более надёжного не будет

имхо

какой-нить с тред сделать из него форкнуть другой тред, который независимо от rts работать будет и не возвращаться

там делей на системном таймере

но тогда возникнет вопрос, как покилять треды и вернуться в rts