uwp закапывают же

а что вместо?

О, клин код закапывают на хабре https://habr.com/ru/post/508876/

наконец-то

Я её начал читать (давно, до фшарпа), но у меня случилась передозировка ООП и я подумал, что или я тупой, или все вокруг, которые эту книгу боготворили

Тогда я ещё не очень понимал как всё работает, поэтому своё мнение о книге оставил при себе.

О, клин код закапывают на хабре https://habr.com/ru/post/508876/

не знаю как эту (она хоть тоненькая) - а вот code complete давно в печку пора

не знаю как эту (она хоть тоненькая) - а вот code complete давно в печку пора

да и GoF

а то мы так и не избавимся от AbstractFactoryGatewayManagerProvider

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

Я её начал читать (давно, до фшарпа), но у меня случилась передозировка ООП и я подумал, что или я тупой, или все вокруг, которые эту книгу боготворили

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

https://i.gyazo.com/15d6e8d30c749d55db0c504a3d76494f.png ну пздец, первым коментом такую макулатуру советовать (ну моооооооожет быть в 2008 году еще было ок)

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

я с трудом могу коменты читать на хабре, честно признаюсь.

ух, бля

ух, бля

https://memepedia.ru/wp-content/uploads/2018/10/obezyana-mem.jpg в тоже самое время все любители f#

Это профессионалы

Если кому интересно, во что преобразовался мой вчерашний pr : https://github.com/fsprojects/Fabulous/pull/771

как там было? "Зато писать на F# сможет НЕпрограммист, а математик, физик, химик или иной инженер."

ух, бля

ну откуда им знать...

мне кажется пора делать "F# lives matter" или типо того

долой объективацию функциональных языков

скинем с себя оковы долбоебизма ярых фп-шников и ярых ооп-шников

Если кому интересно, во что преобразовался мой вчерашний pr : https://github.com/fsprojects/Fabulous/pull/771

скажу честно, стало ещё непонятнее!

я даже повкуривал 5 минут

Сперва бы доказать, что фшарп функциональный. А для этого определить, какой язык является функциональным.

скинем с себя оковы долбоебизма ярых фп-шников и ярых ооп-шников

объединимся с кложиристами единым фронтом за прагматичное фп

Если кому интересно, во что преобразовался мой вчерашний pr : https://github.com/fsprojects/Fabulous/pull/771

можешь пояснить как это работает? /// Here we put an inbox into the "waiting" state and wait for render finishes Debug.WriteLine "View invoked" async{ inbox.Post (Blocked true) program.syncAction (fun()->updateView msg) () inbox.Post (Blocked false) } |> Async.Start return! loop (isRendering,state,false) Это код обработчика инбокса. Здесь мы асинхронно кладём сами себе Blocked true, Blocked false (при этом у нас в мейлбоксе может быть очередь сообщений и эти Blocked будут в очереди предположим сотые) А потом возвращаем isRendering = false, хотя вроде syncAction уже начался (асинхронно)

isRendering параметр в loop поменяется на true только когда мы обработаем первый месадж Blocked (хотя рендеринг уже идёт)

короче, я нихуя не понял.

Идея какая - копить стейт, пока идёт обработка предыдущего

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

Условно, если рендер долгий

Он будет происходить реже

Независимо от числа апдейтов

Я и хотел, чтобы ты глянул

Мейлбокс неблокирующийся естественно

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

допустим. Но тут другое очередь mailbox: Render ---> Render isRendering: false async render process: stopped обрабатываем первый месадж Render, асинхронно стартуем рендер процесс, кладём Blocked true месадж в мейлбокс, нам ещё насовали Render в инбокс mailbox: Render --> BlockedTrue --> Render --> Render isRendering: false async render process: started!!! обрабатываем второй рендер. isRendering всё ещё false, стартуем ещё один ебучий рендер процесс, кладём ещё Blocked True месадж в мейлбокс, нам ещё насовали mailbox: BlockedTrue --> Render --> Render --> BlockedTrue --> Render --> Render isRendering: false async render process: started!!! async render process 2: started!!!

Ну рендеры очень быстро отстреливают

Которые блокированные

Ну рендеры очень быстро отстреливают

приведённый выше сценарий реальный

и всё зависит от шедулера тред пула

Но над синхронизацией надо подумать

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

Можно, конечно , сделать ещё один мейлбокм

надо просто мутабельную переменную сделать

вместо аргумента loop функции

Мутабельная из асинка

Ну хз

Блок можно из асинка наружу вынести просто

Который самый первый

Хотя там тоже проскочит

Тяжко всё

ну я бы впендюрил мутабельную переменную. Если ты боишься за захват кложуры, то передавай её явно byref

Переменная порешает,да

Если я цикл апдейта пропустил, нестрашно

Хотя задачка, млин

то есть у тебя loop будет такой let mutable isRendering = false let rec loop(isRendering: byref<bool>, ...) return! loop(&isRendering, ...)

в теле лупа мутируем, да

никаких кложур, всё чисто.

Да, блокировку сделаю мутаблом

да, тогда ты сразу будешь получать инфу о процессе рендеринга, не будет двойного старта рендер процесса и можно избавиться от месаджей Blocked

От блока низя, наверное

ну у тебя блок теперь переменной выражается

Я ж там запускаю дорендер

На новый стейт

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

но да, может через очередь лучше

Через очередь как-то спокойнее

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

По идее так будет правильнее

ну да

Спасибо, этот момент и смущал в имплементации

Приятно, когда можно с умными людьми посоветоваться

ныряем в темные глубины

Подскажите, пожалуйста, как синхронизовать 2 ConcurrentDictionary У меня есть что-то типо сессии, одна сессия на одну группу, в ней хранятся обработчик команд для сессии и айдишники пользователей находящихся в сессии Есть менеджер сессий, его задача - отдавать сессию по айдишнику пользователя (один ConcurrentDictionary с ключом айдишника пользователя, где значение ссылка на сессию), и отдавать сессию по айдишнику группы (второй ConcurrentDictionary с ключом айдишника группы, где значение ссылка на сессию) Можно как-то обойтись без lock-а, и чего это будет стоить?

Подскажите, пожалуйста, как синхронизовать 2 ConcurrentDictionary У меня есть что-то типо сессии, одна сессия на одну группу, в ней хранятся обработчик команд для сессии и айдишники пользователей находящихся в сессии Есть менеджер сессий, его задача - отдавать сессию по айдишнику пользователя (один ConcurrentDictionary с ключом айдишника пользователя, где значение ссылка на сессию), и отдавать сессию по айдишнику группы (второй ConcurrentDictionary с ключом айдишника группы, где значение ссылка на сессию) Можно как-то обойтись без lock-а, и чего это будет стоить?

А ну то есть, забыл написать сам вопрос, но уже больше не надо, расписав я понял что я не понимал)

ух, бля

Я как-то читал подобный код. Врагу не пожелаешь

Все методы класса: void -> void

Неявное программирование

Не говоря уже о невозможности параллелизма на уровне методов

Все методы класса: void -> void

Вот я себе нечто подобное и представил, да