@haskellru - страница 1816 - Telegram web archive

Alexander

Там треды держат локальную копию данных. Есть процедура, которая позволяет узнать, что переменная изменилась в треде. С помощью как раз этих чисел (это версии). Если изменилась, то нужно узнать перед коммитом, а не изменилась ли она еще и в другом месте. Разница в этих stamp как раз дает всю нужную инфу

Alexander

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

Да нет, я готов поотвечать, просто могу исчезнуть на время

Alexander

И еще будет неплохо, если вдруг вылезут баги. Маловероятно, но возможно

Alexander

data TVarHandle = TVarHandle OrigUStamp UpdatedUStamp Any

Any - для хранения произвольного типа переменной в мапе

кана

не-не, что за тип я понял

кана

вопрос был больше - что за поле

Alexander

поясни плиз, что такое Handle и что за Any выглядит как какое-то обновление твара с таким-то айди в твар с новым айди и новым значением

Handle - позволяет добыть из рантайма переменную

кана

то есть я правильно понял, что Handle это какая-то команда "твар с таким-то айди меняется на такую-то версию с таким-то значением"

Alexander

вопрос был больше - что за поле

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

Alexander

то есть я правильно понял, что Handle это какая-то команда "твар с таким-то айди меняется на такую-то версию с таким-то значением"

Это контейнер пользовательского значения, не команда

кана

а, хм, слово handle меня выбило

кана

нет плюсового бекграунда

кана

а в мапе айди-ключ это оригинальный айди твара?

Alexander

Ну, там есть представление на уровне интерфейса и на уровне рантайма. TVar - уровне языка, TVarHandle - на уровне рантайма. Первый - "аватар" второго

Alexander

а в мапе айди-ключ это оригинальный айди твара?

Да

кана

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

Alexander

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

Вроде того. Предыдущая версия ровно одна - та, которая лежала в главном контексте, когда мы стартовали atomically. В транзакции она может поменяться локально или нет

кана

в хендле оригинальный айди лежит просто для удобства?

кана

а так он и так ключ

Alexander

Вроде да, чот я подзабыл

кана

все таки нет, в хендле айдишки это не айди твара, это stagedUS из рантайма, который тут называется rtStamp, а что это такое я хз

Alexander

Аа. Айдишник вот этой атомарной сессии

Alexander

Когда тред меняет твар, он оставляет в ней свой id

Alexander

Еще надо помнить тот, который был в глобальной копии

кана

но там же и так TR

кана

или хочешь через какой MFix?

Alexander

Второе Я не уверен, может, этот коммент остался после переделок. Или, может, я имел в виду на идиому "go" переделать

Alexander

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

Alexander

там TR

Alexander

в stml вроде ничего тоже не накапливается

кана

хм, а где STM хранится контекст-то? Какая-то глобальная переменная?

Alexander

а зачем STM конекст (я не смотрел реализацию)

Alexander

поидее TVar должено быть достаточно, чтобы все делать

кана

ну я к тому, что STM между разными atomically хранит некоторый стейт

кана

в Гранина ссылка на этот стейт в иорефе контекста, который передается в atomically

кана

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

кана

или же оригинал как-то обошелся без глобального стейта между вызовами atomically (вызов atomically - выполнение транзакции?)

кана

что-то кода у STM подозрительно мало

Alexander

хм, а где STM хранится контекст-то? Какая-то глобальная переменная?

Есть прямо такая структура - Context. Там и хранится генеральная копия данных

Alexander

а зачем STM конекст (я не смотрел реализацию)

Чтобы уметь связывать разные процессы atomically

кана

Есть прямо такая структура - Context. Там и хранится генеральная копия данных

не-не, это у тебя

Alexander

или же оригинал как-то обошелся без глобального стейта между вызовами atomically (вызов atomically - выполнение транзакции?)

У оригинала совсем другой подход к реализации, ему не требуется генеральной копии.

Alexander

Там, если я не ошибаюсь, TVar являются активными объектами и версионируют данные, как им нужно

Alexander

или же оригинал как-то обошелся без глобального стейта между вызовами atomically (вызов atomically - выполнение транзакции?)

Да, вызов atomically - это выполнение транзакции

Alexander

что-то кода у STM подозрительно мало

Вот, я тоже удивляюсь. Но пока все тесты, которые я писал, проходили

Alexander

да, в обычной имплементации все что нужно живёт в tvar

Alexander

и в контексте создаваемым atomically

Alexander

в контексте лог чтения со значениями и gc root в твари мьютексы для лока очередь чтения и значение

Artem

Добрый вечер, всем. Могу ли я как-то упаковать несколько запросов возвращающих ClientM в один?(Вроде Task.WhenAny в C# или Promise.all в JS)

Зигохистоморфный

Добрый вечер, всем. Могу ли я как-то упаковать несколько запросов возвращающих ClientM в один?(Вроде Task.WhenAny в C# или Promise.all в JS)

sequence но это будет последовательно

Cheese

для параллельного есть mapConcurrently из async

Alexander

только из lifted-async или unliftio

Alexander

если прямо внутри clientM

Anonymous

@nihlet будет жить. Поприветствуем!

Artem

Кто работал с telegram-bot от @fizruk31337?

a66ath

я

a66ath

@fizruk31337 поддержка бота еще будет?

Artem

@a66ath, ты же делал кастомные запросы?

a66ath

@a66ath, ты же делал кастомные запросы?

В смысле?

Artem

@a66ath, обычные HTTP запросы к telegram API, которые не заимплеменчены у @fizruk31337

a66ath

Не юзал

Artem

Тебе хватало sendMessage и editMessage?

a66ath

У меня REPL

a66ath

Зачем мне что-то сложное

Artem

:C

Alexander

Важное уведомление для новичков в Haskell. Нужно относиться скептически ко всему, что говорится или утверждается в этом чате. Хаскеллисты делятся на "академиков" и "практиков". У первых проявляется узкий формалистический подход. Они могут утверждать, что какая-то вещь плоха или неприменима, ведь вот же есть пейпер, где так написано. Однако в пейперах чаще рассматривается узкая задача, с необходимыми исследователю ограничениями, потому что цель пейперов - в математических выкладках, для которых важны строго определенные начальные положения. На практике же задачи либо не требуют использовать инструмент так узко и без фантазии, либо ограничения вполне допустимы, либо можно применить какой-нибудь трюк, который академикам покажется "нечистым" и "небезопасным", из-за чего они его и не рассматривают вовсе. Это значит, что утверждения в этом чате о неприменимости все еще следует проверять экспериментом, не вычеркивать инструмент из своего набора, пока не найдено, что в вашей задаче он действительно неприменим. Также очень скептически стоит относиться ко всем околоформальным беседам про морфизмы, продвинутую магию на типах и прочий матан. Эти беседы ведет все та же академическая часть хаскеллистов, и они более всего заметны, что оставляет ощущение, что Haskell - сложный и непонятный. Однако на практике этот "высокий штиль" применяется очень редко, потому что в целом может вредить проекту больше, чем помогать: плохой поддерживаемостью, никому неизвестными ad-hoc решениями (вместо известных практик), и той пресловутой формалистской узостью применения инструментов. К сожалению, все еще существует некая убежденность академической части хаскеллистов в том, что если не формализовано - значит, не существует, или плохое. Но это лишь мнение. Ведь практика, как мы знаем, сильно расходится с теорией.