t
можешь как угодно звать. Главное, что все понимают, о ком речь
Minoru
окей
Size: a a a
2021 May 25
t
а кто не понимает, тот поймёт [дурацкий мем с волком]
💮
Сообщение от имени m4n71k0r было всего лишь 46 часов назад.
💮
(незапоминаемый ник был найден поиском слова «хуй» в сообщениях бота)
t
он, между прочим, дал тебе имя, розовый снежок!
t
хоть каплю уважения имей, ну!
t
=3
💮
Там всего 17 сообщений, из них два от m4n71k0r. Довольно эффективный способ найти, как оказалось.
Если бы не так, то я не знаю, как ещё искать кроме как вообще все сообщения бота перечитывать.
Если бы не так, то я не знаю, как ещё искать кроме как вообще все сообщения бота перечитывать.
💮
Хм, хотя по слову «мантикор» тоже ищется. Ладно…
c
Minoru
какие интересные штуки придумывают люди: https://github.com/cwebber/rebooting-the-web-of-trust-spring2018/blob/petnames/draft-documents/petnames.md TL;DR: вместо централизованной системы имён каждый актор в социальном графе имеет свою собственную «адресную книгу», в которой сопоставляет уникальные имена (типа .onion в Tor) с человекочитаемыми. Кроме того, каждый актор может публиковать отдельные записи (возможно, изменив человекочитаемое имя). Акторы могут искать адреса как в своей собственной книге, так и в книгах всех своих контактов
какие интересные штуки придумывают люди: https://github.com/cwebber/rebooting-the-web-of-trust-spring2018/blob/petnames/draft-documents/petnames.md TL;DR: вместо централизованной системы имён каждый актор в социальном графе имеет свою собственную «адресную книгу», в которой сопоставляет уникальные имена (типа .onion в Tor) с человекочитаемыми. Кроме того, каждый актор может публиковать отдельные записи (возможно, изменив человекочитаемое имя). Акторы могут искать адреса как в своей собственной книге, так и в книгах всех своих контактов
c
Minoru
ого, Бугаевский дописал свою книжку про Haskell! А я, кажется, дальше введения так и не прочитал ._.
ого, Бугаевский дописал свою книжку про Haskell! А я, кажется, дальше введения так и не прочитал ._.
c
Akon32
/me довёл до рабочего состояния асинхронный пример. https://gist.github.com/Akon32/38828abdb670801574fb28dbc5143c39#file-main-rs-L76
/me довёл до рабочего состояния асинхронный пример. https://gist.github.com/Akon32/38828abdb670801574fb28dbc5143c39#file-main-rs-L76
c
Akon32
пришлось разделить читателя-писателя и обвешать всё Mutex<...> и Arc<Mutex<...>> в случайных местах.
пришлось разделить читателя-писателя и обвешать всё Mutex<...> и Arc<Mutex<...>> в случайных местах.
c
Akon32
там какие-то странные принципы. без Arc<> нельзя передать ссылки на объект нескольким контекстам. без Mutex<> нельзя изменять то, что внутри Arc<>. а если мы делаем читателя и писателя одним объектом, то для чтения и записи из разных контекстов эти контексты должны одновременно взять мьютекс, т.к. нельзя передать этот общект иначе, чем Arc<Mutex<ChannelsObject>>.
там какие-то странные принципы. без Arc<> нельзя передать ссылки на объект нескольким контекстам. без Mutex<> нельзя изменять то, что внутри Arc<>. а если мы делаем читателя и писателя одним объектом, то для чтения и записи из разных контекстов эти контексты должны одновременно взять мьютекс, т.к. нельзя передать этот общект иначе, чем Arc<Mutex<ChannelsObject>>.
c
Akon32
*объект.
*объект.
c
Akon32
и в итоге вот такое "Arc<tokio::sync::Mutex<HashMap<TaskId, TaskResultReceiver>>>" ВЕЗДЕ.
и в итоге вот такое "Arc<tokio::sync::Mutex<HashMap<TaskId, TaskResultReceiver>>>" ВЕЗДЕ.
c
Minoru
на код не смотрел, но ты можешь внутри ChannelsObject держать Mutex<Reader> и Mutex<Writer>, и брать эти локи по-отдельности
на код не смотрел, но ты можешь внутри ChannelsObject держать Mutex<Reader> и Mutex<Writer>, и брать эти локи по-отдельности
c
Minoru
с километровыми типами борются как всегда, с помощью type alias-ов: type Foo = Arc<tokio::sync: …
с километровыми типами борются как всегда, с помощью type alias-ов: type Foo = Arc<tokio::sync: …
c
Akon32
не, там уже AsyncProcessChannelsWriter и AsyncProcessChannelsReader.
не, там уже AsyncProcessChannelsWriter и AsyncProcessChannelsReader.