What is the difference between unsafeDupablePerformIO and accursedUnutterablePerformIO?
кто без гугля догадается, это стёб или настоящие имена?
#3038108. Видимо поведение .ghci в cabal repl обусловлено тем, что его тестировали только на :set prompt "λ> ". Оно работает.
В догонку к Хорошо. Создаю более другой пакет. В нём линкуюсь со своим пакетом и в .ghci использую его модули. Код выполняется, но символы которые определяются в .ghci в repl'е не видны.
Окей. cabal exec — ghci -package myshit. Теперь наконец работает всё! Если в пути к локальной packagedb нет юникода.
Дальше попытка использовать сандбокс от cabal без помощи cabal, но я уже заебался.
github.com
Почему хаскелисты могут въебать сигнатуру где хотят (или вообще не въёбывать чтобы компилятор вывел всё сам), а у раста всегда с этим какие-то сложности? Вон, уже дошло до выпиливания однозначно полезных фичей из языка.
Почему хаскелисты могут въебать сигнатуру где хотят (или вообще не въёбывать чтобы компилятор вывел всё сам), а у раста всегда с этим какие-то сложности? Вон, уже дошло до выпиливания однозначно полезных фичей из языка.
hackage.haskell.org
отдельно удивила архитектура лямбдабота.
Есть плагин, есть модуль. Внутри модуля есть команды. В интерфейсе команды есть процессы — функции, принимающие строку. А ещё есть колбэки, чтобы ловить выхлоп от команд снаружи. В результате, приходится крутиться как белка в колесе и пробрасывать с разных сторон эпичные костыли, чтобы обойти ограничения, заложенные внутрь.
Следующий бот для телеграма попробую сделать попроще.
на радостях закрыл весь бэклог по хаскельному лямбдаботу и выложил все собранные костыли на хакадж: отдельно удивила архитектура лямбдабота.
Есть плагин, есть модуль. Внутри модуля есть команды. В интерфейсе команды есть процессы — функции, принимающие строку. А ещё есть колбэки, чтобы ловить выхлоп от команд снаружи. В результате, приходится крутиться как белка в колесе и пробрасывать с разных сторон эпичные костыли, чтобы обойти ограничения, заложенные внутрь.
Следующий бот для телеграма попробую сделать попроще.
github.com
Столько всратости в одном посте
Столько всратости в одном посте
hackage.haskell.org но возможно есть что-то более общеупотребимое.
Хочу корутины. Суть такова: нужен трансформер, который позволит добавить к логике в виде последовательности действий добавить точки передачи управления вызывающей стороне с передачей туда информации о прогрессе или типа того. В принципе эта херня подойдёт
@klapaucius запилил хэштаблицы, ну а мне потребовался год, чтобы их донести до Hackage.
напишу и сюда для порядка.
hackage.haskell.org
напишу и сюда для порядка.
hackage.haskell.org
2021-06-01 22:56:28
Мистер, создайте уже *textlinux дистро, и в хаскель его на прувинг, и лучше в линух с *rt *realtime патчем! А?
ref: juick.com
воскресим первотег?
#2980231 я рассказывал об утекающих сокетах и грешил на сервер warp. Сегодня до меня, наконец, дошло, что это мой говнокод приводил к проблемам. Забивались очереди, по которым выстраивались коммуникации между серверными обработчиками запросов и фоновыми процессами.. Стоило затюнить скорость чтения из очередей и поставить метрики размера очередей на мониторинг — и, кажется, проблема ушла, warp ни при чём. А время покажет.
Не прошло и года. В
gitlab.haskell.org
Как обычно в таких случаях, алгоритм по-хорошему должен в константной памяти работать, но вместо этого память жрётся и жрётся в ходе работы программы, освобождаясь только в конце.
github.com
Есть ли варианты лучше, чем бинарный поиск по коду методом комментирования? Кажется, в случае хаскеля это вообще так себе метод поиска утечек, поскольку в случае когда мы комментируем какого-нибудь потребителя данных, мы можем ненароком внести ещё один space leak, например когда большой thunk вычисляется по ходу итеративного алгоритма в компактный результат, либо это вычисление откладывается до самого конца, накапливая большие thunk'и в памяти.
В программе space leak, но как искать его непонятно: ghc'шный профайлинг говорит, что всё занимается PINNED-памятью (поскольку я оперирую в основном ByteString'ами), и никаких подробностей о том, где она выделена, и что её держит, не говорит — Как обычно в таких случаях, алгоритм по-хорошему должен в константной памяти работать, но вместо этого память жрётся и жрётся в ходе работы программы, освобождаясь только в конце.
github.com
Есть ли варианты лучше, чем бинарный поиск по коду методом комментирования? Кажется, в случае хаскеля это вообще так себе метод поиска утечек, поскольку в случае когда мы комментируем какого-нибудь потребителя данных, мы можем ненароком внести ещё один space leak, например когда большой thunk вычисляется по ходу итеративного алгоритма в компактный результат, либо это вычисление откладывается до самого конца, накапливая большие thunk'и в памяти.
github.com вменяемый синтаксис для рекордов в хаскеле, дружит с DuplicateRecordFields.
type family FragmentUnique api :: Constraint where FragmentUnique (sa :<|> sb) = Or (FragmentUnique sa) (FragmentUnique sb) FragmentUnique (Fragment a :> sa) = FragmentNotIn sa (Fragment a :> sa) FragmentUnique (x :> sa) = FragmentUnique sa FragmentUnique (Fragment a) = () FragmentUnique x = () type family FragmentNotIn api orig :: Constraint where FragmentNotIn (sa :<|> sb) orig = And (FragmentNotIn sa orig) (FragmentNotIn sb orig) FragmentNotIn (Fragment c :> sa) orig = TypeError (NotUniqueFragmentInApi orig) FragmentNotIn (x :> sa) orig = FragmentNotIn sa orig FragmentNotIn (Fragment c) orig = TypeError (NotUniqueFragmentInApi orig) FragmentNotIn x orig = () type NotUniqueFragmentInApi api = 'Text "Only one Fragment allowed per api ‘" ':<>: 'ShowType api ':<>: 'Text "’."
#2972491. опубликовал плагин для servant с автогенерацией robots.txt и sitemap.xml: github.com
получил комментарий:
:)
вдогонку к получил комментарий:
Ненужно на ненужно для ненужно
:)