кроме как самому обновить mingw-шную либу, что потребует пересбоки много чего, чего там сам пакман за меня не сделает?

или установки icu с сайта и добавления его в library path руками

λ> data Pet = Dog { _age::Int,_name::String} | Cat{_age::Int,_name::String} deriving (Show); $(makePrisms ''Pet); $(makeLenses ''Pet) λ> [Cat 3 "Tom", Dog 5 "Sparky"] ^.. traverse . _Dog . re _Dog . name ["Sparky"] тут без filtered, но приходится обратно восстанавливать рекорды, чтобы линзы по имени применить

немного оверхед

но учитывая что черт знает чем оно собиралось, то ловлением произвольных проблем?

немного оверхед

тогда _Dog . _2 или filtered. В случае с filtered всё равно "распаковка" делается два раза - в фильтре, потом в линзе.

линзы вообще не про эффективность :)

все зафьюзится

наверное

возможно

но это не точно

_X . re _X тоже может зафьюзится. Наверное

ну я про это

а никто nix под msys не пытался заводить?

Есть вопрос, может кто подскажет (не до конца въехал в type-level machinery). Есть функция: fft1D_m - https://github.com/Haskell-mouse/accelerate-fft/blob/master/Data/Array/Accelerate/Math/FFT/LLVM/Native.hs Сейчас функция позволяет делать построчное преобразование фурье только для 2-мерных массивов (DIM2), если сменить на переменную типа(чтобы построчный фурье можно было делать по n-мерным массивам), то компилятор ругается на тип подфункции go. Проблема в том, что в типе функции go( CArray (Int, Int) (Complex r)) в кортеже должно быть столько членов, какова размерность массива.

Мне в принципе хватает и по матрице, но хотелось бы расширить на массив произвольной размерности :-)

я бы не стал лезть в это если не прям-вот-надо

там все сложно

может кто дать список вот реально production-usage либ? Которые может не так интересны теорететически (типа рекурсивных схем), но которые используются в реальном мире)

Сам я вроде как поверхносно знаком с линзами, аналогично с сервантом, трасформерами, мтл, хочу познакомиться с варпом и вай поближе. Нашел сейчас pipe. Понял, что я действительно хочу найти работу на хаскеле, а значит нужно сместить фокус.

aeson, cassava, conduits, blaze

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

bytestring, vector

а вообще да

кстати на f(by).by haskell неупомянут на сайте

вообще что за дела

кложа скала котлин

Вроде как conduits успешно pipe заменили

И развиваются активней

я бы не стал лезть в это если не прям-вот-надо

Не, ну я могу написать эту функцию для 3 и 4 мерных массивов тем же макаром, но это ж не красиво) А что до лезть, то уже влез) изначально accelerate-fft не имел построчного фурье. Вот хочу доделать и пошлю пулл реквест

если нужно сделать для себя, про проще 3 и 4 сначала сделать, а потом уже играться с хорошим общим случаем

@kana_sama вот наш продакшн, если интересно (отфильтрованный от мусора, который точно большинству не нужен): http://lpaste.net/1446613601690320896 может, если пять–десять таких списков соберёшь, что-нибудь интересное и вырисуется (ну кроме “все юзают text, кто бы мог подумать”)

если нужно сделать для себя, про проще 3 и 4 сначала сделать, а потом уже играться с хорошим общим случаем

Для себя я уже давно сделал. Мне то нужно только построчное фурье по матрице и оно работает. Но я хочу это влить в библиотеку, и тут не хочется костылей.

Вроде как conduits успешно pipe заменили

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

Разница между conduits и pipes в сопутствующих либах

меня больше всего интересует работа с базами

persistent удобный, но куча ТН и какой-то он "императивный". Знакомый кидал какую-то либу на профункторах, opaleye

тут вообще все разное юзают

postgresql-simple, hasql

acid-state'а хватит всем, а так любые обертки над человеческими базами годятся, в принципе

это ещё, да

persistent удобный прикольно

acid-state хватит всем кому не нужно параллельного доступа, consistency, транзакций, хоть каких-то гарантий, что данные запишутся хорошо и правильно

/me злой какой-то сегодня

но ведь это правда :)

там есть issue старщшное

что данные бьются

у нас lmdb и hasql используются

но для lmdb я почти с нуля переписал либы

наверное rocksdb можно еще взять

acid-state хватит всем кому не нужно параллельного доступа, consistency, транзакций, хоть каких-то гарантий, что данные запишутся хорошо и правильно

Ну лол, нет, как раз эти проблемы проблемами не являются. Основные недостатки асида в том, что там есть ненужные чекпоинты (данные большие если хранишь, то оверхед по месту — нужно костылировать немножко), плюс он медленноват.

наверное rocksdb можно еще взять

Есть норм биндинги, да.

эти проблемы проблемами не являются?!

https://github.com/acid-state/acid-state/issues/79

LOL

недостатки в чекпоинтах?!

я не хочу как-то ночью проснутся и найти убитую базу

по сути средств восстановить ее нету

я бы упал под стол но у меня ноут на коленях стоит

эти проблемы проблемами не являются?!

параллельный доступ никому не нужен, консистентность норм работает, транзакции — просто создаешь отдельный конструктор

не надо мне ничего больше говорить, мне ноут жалко

https://github.com/acid-state/acid-state/issues/79

А, это дичь какая-то, лол. Я не встречал на практике.

там Durability нет - обо всем остальном можно уже не говорить

А, это дичь какая-то, лол. Я не встречал на практике.

конечно не встречал

ну я бы не стал ждать и переехал уже на что-то нормальное

у нас же форк асид-стейта, в котором я это пофиксил

:troll:

там Durability нет - обо всем остальном можно уже не говорить

Обычно как раз-таки все норм работает с durability.

у нас же форк асид-стейта, в котором я это пофиксил

this

ну вон issue говорит об обратном

вот идём и смотрим как работает sqlite

и смотрим как работает acid-state

this

ну на форках далеко не уедешь

и какие гарантии, что если у тебя провод питания вылетит во время fsync то данные будут читаемые

@lightgreen вы же на rocksdb перешли?

да

кроме каких-то мест, где нет

но скорее да чем нет

а ты кидал MR в acid state?

если вам не нужен concurrent access, то стоит говорить, нам не нужен concurrect access

с фиксом?

@lightgreen

там фикс так себе, если честно

мы его пообсуждали в каком-то issue

ни к чему не пришли вроде

вернее, не фикс обсуждали, а проблему

т.к. фикс = “если чекпойнт не парсится, ну давайте удалим его”

тут нечего обсуждать

да, кстати там где мы используем lmdb работает автор acid-state

ну или работал хз

во всяком случае когда выбирали технологии он участие принимал причем достаточно высоко

т.к. фикс = “если чекпойнт не парсится, ну давайте удалим его”

хорошее решение:)

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

поэтому данные вроде бы не потеряются

(это если игнорировать тот факт, что на самом деле в асиде нужно чистить почти все старые чекпоинты иначе там быстро размер базы растет в бесконечность)

норм решение, в общем-то ничего другого не придумаешь

ну кроме всяких постраничных дампов и доп чексумм на странице

(это если игнорировать тот факт, что на самом деле в асиде нужно чистить почти все старые чекпоинты иначе там быстро размер базы растет в бесконечность)

ну вот все кроме последнего чистить ок

там как раз функция есть, которая их в папочку переносит откуда их удобно удалить

на последнем Summer of code вроде кто-то начал писать опять базу на хаскеле