Pull to refresh
3
0

Пользователь

Send message

Сейчас ещё есть проект бекенда на основе gccjit, но пока скорее как порт на платформы, куда llvm не привезли.

Читается ЛаТеХ. Вставьте сюда любимую шутку про картинок и latex.

Конструктора без параметров нет.

Так есть же Kotlin no-arg: JPA support

Так наверное можно же (разве что из коробки без поддержки, держитесь там), но std::promise это стандартный контейнер чтобы вернуть один «ответ», а пример на генераторе и «ответов» будет много или даже 0. А корутины чтобы сделать промис на вектор бесполезны.

Учитывая что у Яндекса есть свой DNS это очень смешно.

тянущие инернет со спутника, где трафик или стоил в десятки раз дешевле

Суровые провайдеры

Я помню школьником был на экскурсии в офисе Intel, и там явно говорили, где можно фотографировать, а вот всё остальное ваще-ваще нельзя.

Синтаксически звучит как шелловое/перловое doThings && reportSuccess || die, кажется ещё в Руби было что-то похожее, люди пользуются. Работает естественно из-за чуть других причин.

Вообще начав читать статью подумал что будет безопасность в вакууме без конкретики, а потом такое мясо пошло. Хорошая статья, спасибо.

Спасибо! Там внутренняя кухня и наверняка беда была не только в общении с базой, но я уже думал подозревать своё неправильное понимание что Postgres обещает, а что нет. А в результате обещает больше чем я думал, и это радует, спасибо огромное за разъяснение и ваши статьи!

Я задался этим вопросом потому что, как мне казалось, в паре быстро работавших моих тестов я ловил аномалию что следующая читающая транзакция как будто была выполнена до COMMIT предыдущей и не увидела изменений (хотя остальное было консистентно, никаких частичных / фантомных / неповторяемых чтений) и начал думать, чем там можно помочь кроме втыкания sleep. Формально сериализуемость, насколько я знаю, не запрещает таких аномалий: гарантируется лишь существование пост-фактум какого-то порядка применения с теми же наблюдаемыми эффектами; как раз линеаризуемость (и её надмножества по допускаемым аномалиям) говорит о том, что порядок какой-то известен. Тем более что во всех анализах Postgres на консистентность, которые я читал (в том числе отсылающих к Jespen), уделялось внимание в первую очередь ветке сериализуемости и её фрагментам (Snapshot Isolation, Repeatable Read, ...), а о линеризуемости не говорилось ничего. В документации, насколько я помню, этому много внимания не уделяется, хотя зная все детали реализации это может быть и очевидно.


Вы сейчас говорите, что всё же транзакция, начатая после завершения другой (можно ли это формализировать? happens after сообщения об успешности COMMIT?) точно будет в сериализуемом порядке после неё?

Собственно, к Urent с обысками не пришли. Интересно почему и кто их владелец ах тоооочно.

Статья старая, но я не побоюсь задать вопрос на тему.


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


Нет ли механизмов попросить PostgreSQL о некой частичной линеаризуемости? Мне приходила идея, которую после этого поста я могу сформулировать: в рамках клиента отслеживать номера выполненных этим клиентом транзакций, и при каждом открытии транзакции сбрасывать её, пока предыдущие не уйдут за «горизонт». Это несколько дуболомно (и нисколько не эффективно, предполагаю), но для моих целей консистентности в интеграционных тестах должно помогать, если вообще работоспосбно. Есть ли у более знакомого с внутренней кухней автора идеи, а ещё лучше жизненный опыт, на этот счёт?

Это всё хорошо, но кажется про наличие или отсутствие фигурных скобочек всё же миф? Никакой метрики на тему в файле по ссылке нет для незнакомого с кодовой базой gcc взгляда.

Посмотрите обязательно на tmux, он куда живее в плане экстеншенов и новых фич.

На тему rate limits: внутри AWS провайдера, как мне кажется, видел что-то похожее на встроенный exponential backoff, то есть даже если вдруг рейт лимит выстрелит, инструмент попытается восстановиться. Видимо другие провайдеры могут быть не настолько стабильны.

Суровая статья, никто не комментирует. Много хороших советов, спасибо!

Была новость, что кто-то через веб-консоль заслал навалидный бюллетень, то есть испортил его.

Вообще учитывая, что при любом разговоре о буме инди-игр вспоминают и Braid, кажется, сделал. Тетрис и GTA, конечно, перебирть так не получится.

Пути Дуровых неисповедимы. Хотели и денег поднять, и криптовалютную инфраструктуру сильную запустить. Ах если бы сработало, да? Представьте, как уже сказали в соседних комментариях: криптокошелёк прямо в приложении Телеграмма (или хотя бы глубоко интегрированное), с умными кошельками и дешёвыми транзакциями меньше чем за секунду… Денег почему-то захотели: видимо карманных денег Дуровых, плюс сколько туда ещё уже инвестировали, мы не знаем, не хватает на все крутые примочки.

Information

Rating
Does not participate
Registered
Activity