Ну через костыли какие-то только

глобальную переменную как в си которую тред должен поллить?

Это не та вещь которая нужна каждый день

вот тут это всё очень годно расписано http://chimera.labs.oreilly.com/books/1230000000929

Но когда ты будешь рад

Parallel and Concurrent Programming in Haskell By Simon Marlow

да, марловская книга прекрасна

глобальную переменную как в си которую тред должен поллить?

Норм костыли

да даже документации в Control.Exception хватит

MonadMask соотвественно обобщает mask на разные монадки

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

@elemir90 https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/asynch-exns.pdf

но практика показывает что марловской книги людям не всегда достаточно :(

@anpryl я думаю даже в вашей кодобазе это используется часто :)

Я такого не видел!

?

Ладн, почитаю. Хотя так просто не могу придумать никакого пьюр-обоснования

@anpryl все таймауты например

я, честно говоря, её по-диагонали прочитал, но мне хватило, чтоб понять, что надо иметь в виду асинхронные исключения и использовать bracket

сейчас часто за async прячется

типа race a b и все счастливы, а то что там MVar и асинхронные исключения, ну кому это важно?

@elemir90 в статье только старый API

block/unblock

вместо mask

это все естественно для базовых монадок типа ST/STM/IO

а кроме IO исключения возникнуть нигде и не могут же

а, есть же seq

Сегодня получился хороший поучительный вечер ?

ну асинхронное исключение может прилететь когда угодно

т.е. ты прав, но как бы это сказать

если сделать case somethingPure of ... то вот пока у нас матчится somethingPure там может прилететь исключение, если есть аллокации

@elemir90 посмотрел примеры зачем это может надо быть? там во вступлении

@elemir90 https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/asynch-exns.pdf

Ну такое, они семантику через пи-калкулус строят

Ну зачем это нужно я и так могу придумать. Интереснее было как можно было выкрутится, чтобы реализовать такое, не отходя от чистой лямбды. Спойлер: никто и не пытался

если сделать case somethingPure of ... то вот пока у нас матчится somethingPure там может прилететь исключение, если есть аллокации

ну да, это всегда надо учитывать, я лично всё либо в bracket заворачиваю, либо в resourcet, если много всего

ну жизнь же сложнее, особенно если всякая сеть/MVar/STM вокруг

т.е. проблемы конкурентности не сводятся к деаллокации ресурсов

у меня, к счастью, всё довольно просто

а если и упадёт - не жалко

у нас был интересный случай мы в cloud-haskell в одной функции раза 4 concurrency баги ловили

а если и упадёт - не жалко

Эрланг-программист в чате

2 человека которые в этом деле разбираются и построчно проверяли пытаясь прогонять всякие ситуации

:D

в итоге потом использовали специальный quickcheck-like шедулер

в итоге все работает

шудулер только для CH не обобщенный

для обобщенного нужно dejavu брать

Вы меня разочаровали, в общем, уйду в идрис. Модно, молодёжно

я думаю в идрисе тоже что-то такое есть, но через зад

=)

как и половина вещей там

он конечно клёвый, но блин..

я вот, кстати, вообще не в курсе, как там конкурентность рантаймом разруливается

там треды идриса 1-к-1 к тредам ОС?

я про сишный бэкенд, само собой

не в курсе если честно

я не дошёл до concurrency тами

я книгу уже 3 месяца читаю, да всё никак ниасилю

знание сабжа с одной стороны помогает, а с другой мешает - сейчас вот про State читаю, сил нет уже

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

я не очень понимаю аргумента..

Почему зафейлилось-то? Развитие-то продолжается

лол

Если бы я делал язык программирования с нуля, каким бы он был? Пофантазирую вслух. 1. Его компилятор (транслятор/интерпретатор) был бы очень рано забутстраплен с его же стандартной библиотеки. Пользу eating your own dog's food невозможно переоценить. 2. Я бы исключил из него математику (всю). Даже a = a+1 нельзя было бы написать. Вообще её наличие в языке уходит корнями в Fortran и другие мастодонты, а у нас немного другие нужды. Есть итераторы, есть ranges, хотите математики - велкам в библиотеки, не устраивайте мне тут mathcad. Заодно и массивы выкинул бы. 3. Уровни доступа переоценены. Достаточно было бы всего 2 -- public и package-protected (доступен только в этом пакете). Сделать public поля нельзя. 4. Пакеты. Само собой. Вложенные пакеты запретить. Вложенные классы - в пакет, в класс, в метод - разрешить. 5. Сделать метод или класс закрытым от наследования нельзя 6. Никаких setter-ов и getter-ов - только функции/методы. Ссылки на объекты и другие сущности должны быть first-class citizens, а не стыдливо вести себя как бесплотные указатели, унаследованые из си. 7. Модули - как класс, но существует в едином экземпляре, как пакет. 8. Типобезопасные макросы в языке иметь хорошо и правильно, но не на уровне syntax tree, а выше. Хотя можно не прятать это в компилятор, а выпустить macros sdk 9. JIT и эффективный GC переоценнены, а вот repl и хороший анализ ошибок - их, наоборот, не хватает 10. Все доступные инструменты сборки чудовищно гибкие. Модель требует переосмысления, и начинать его надо со сбора требований, при этом важно избежать ловушки, когда нам кажется, что требования и так выявлены (что там непонятного, это же очевидный сборщик). Мне кажется, уже на этом можно не одну голову сломать, но труд этот будет вознагражден.

Хорошо, что я в телеграме только в трех чатах. В двух уже это копипастили :)

Если бы я делал язык программирования с нуля, каким бы он был? Пофантазирую вслух. 1. Его компилятор (транслятор/интерпретатор) был бы очень рано забутстраплен с его же стандартной библиотеки. Пользу eating your own dog's food невозможно переоценить. 2. Я бы исключил из него математику (всю). Даже a = a+1 нельзя было бы написать. Вообще её наличие в языке уходит корнями в Fortran и другие мастодонты, а у нас немного другие нужды. Есть итераторы, есть ranges, хотите математики - велкам в библиотеки, не устраивайте мне тут mathcad. Заодно и массивы выкинул бы. 3. Уровни доступа переоценены. Достаточно было бы всего 2 -- public и package-protected (доступен только в этом пакете). Сделать public поля нельзя. 4. Пакеты. Само собой. Вложенные пакеты запретить. Вложенные классы - в пакет, в класс, в метод - разрешить. 5. Сделать метод или класс закрытым от наследования нельзя 6. Никаких setter-ов и getter-ов - только функции/методы. Ссылки на объекты и другие сущности должны быть first-class citizens, а не стыдливо вести себя как бесплотные указатели, унаследованые из си. 7. Модули - как класс, но существует в едином экземпляре, как пакет. 8. Типобезопасные макросы в языке иметь хорошо и правильно, но не на уровне syntax tree, а выше. Хотя можно не прятать это в компилятор, а выпустить macros sdk 9. JIT и эффективный GC переоценнены, а вот repl и хороший анализ ошибок - их, наоборот, не хватает 10. Все доступные инструменты сборки чудовищно гибкие. Модель требует переосмысления, и начинать его надо со сбора требований, при этом важно избежать ловушки, когда нам кажется, что требования и так выявлены (что там непонятного, это же очевидный сборщик). Мне кажется, уже на этом можно не одну голову сломать, но труд этот будет вознагражден.

очень толсто

Почему зафейлилось-то? Развитие-то продолжается

Я не хочу срачи устраивать. Просто я глубоко сомневаюсь, что можно эти ваши асинхронные исключения подогнать под чистую лямбду. В статье выше в качестве семантики используют трансляцию в pi-calculus. Белый гуглинг не дал мне ни трансляции, сохраняющей операционной семантику, пи-исчисления в лямбду, ни лямбда-обоснования для асинхронных исключений.

ERROR: S client not available

Я имел ввиду, что под выражением "идея зафейлилась" подразумевается какой-то окончательный вывод. Теорема "нельзя сделать асинхронные исключения на хаскеле". Ну это ж не так, может, в будущем чего-то придумают

я вижу описание операционной семантики, от pi-calculus там только возможность отправки сообщения

Я не хочу срачи устраивать. Просто я глубоко сомневаюсь, что можно эти ваши асинхронные исключения подогнать под чистую лямбду. В статье выше в качестве семантики используют трансляцию в pi-calculus. Белый гуглинг не дал мне ни трансляции, сохраняющей операционной семантику, пи-исчисления в лямбду, ни лямбда-обоснования для асинхронных исключений.

Я очень плохо в курсе, но вообще не припомню, чтобы в подходах с грязными лямбдами межпотоковый обмен эксепшнами как-то лучше решался. Во всяких ерлангоакковских актор моделях проблема по сути игнорируется. Но если посмотреть мотивацию в той статье - то само желание потока убить своё дитя рождается, как правило, от осознания, что он ему больше не нужен. А нежелание умирать, как сказал Александр, от осознания, что есть неосвобождённые ресурсы. Поэтому чисто из интуиции из соседнего чата проблема как-то должна решаться линейными типами или типа того, которые вполне вяжутся с чистыми лямбдами. Т.е. если широко посмотреть - ручное управление асинхронностью так же плохо вяжется с чистотой, как и ручное управление памятью.

@mkrentovskiy а как тебе nanomsg по сравнению с zeromq?

вопрос ко всем присутсвующим

А вот его я не трогал. Но у них один и тот же автор.

Льва Валкина можно поспрошать, он вроде высказывался.

да, я знаю там автор любит между пакетами переходить

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

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

Ну вот да, это немного подкупает.

С другой стороны, я сейчас скажу чернь - а чобы ни HTTP?

вообще http2 вполне себе вариант

мне не очень нравится, что в целом протокол сложный

т.е. у меня очень тупой паттерн

У тебя бинарные потоки?

но с другой стороны там решены проблемы

нет

в данный момент

Ну тогда можно и не 2.

сейчас json, но вообще ничего не мешает перейти на бинарные (кроме питона)

т.к. сейчас store везде вместо сериализации и его в питоне надо правильно переизобретать

а про nanomsg, в основном вопрос шило на мыло замена это или нормальная по сравнению с zeromq

А стор - это шмат памяти?

не настолько все плохо, применение Storable и что-то типа формата там есть

но без спецификации

Читал историю nanomsg - похоже какие-то человеческие факторы - проблемы заставили его форкнуть zmq, ему не нравилась демократия в разработке, в итоге пилил всё в одну каску, правок от других не принимал, и в итоге выдохся, по истории комитов видно что происходило.

Есть пост на тему http://sealedabstract.com/rants/nanomsg-postmortem-and-other-stories/

ну он любит "заканчивать" проекты

типа все - готово

В том то и дело, код накодил из любви к прекрасному, а про комьюнити - не интересно

В zmqguide Хейнджекс рассказывает что это отдельное дело, и специальный подход, и намеренный труд выполнен чтобы всё так организовать в истории zmq