Forwarded from Plot
Комитет по охране памятников организовал экспертизу, чтобы определить, как звали убийцу Пушкина
Привет, это Софья. Смешная бюрократическая история развивается в Санкт-Петербурге.
Юристка Юлия Коновалова уже два года просит Минкульт и КГИОП* исправить ошибку в документах, которая закралась туда в 2001 году. В реестре объектов культурного наследия место дуэли Александра Пушкина на Коломяжском проспекте, в сквере у станции «Новая деревня», указано как «Место, где 27 января 1837 г. состоялась дуэль поэта Пушкина А.С. с Дантесом Э.».
Но Дантес — не Э., а Ж.Ш.! Жорж Шарль, французский офицер. Эдмон Дантес — это граф Монте-Кристо, главный герой романа Александра Дюма.
По словам Коноваловой, у нее нет никаких дел, связанных с Минкультом и КГИОП — и интерес к этому вопросу не связан с ее профессиональной деятельностью. Просто она хорошо училась в школе, любила Дюма — и точно знает, что Эдмон в этой истории не замешан. Опечатку, по ее словам, она увидела случайно. И из интереса обратилась в инстанции с просьбой ее исправить. Переписка длится с января 2023 года — опечатка все еще в реестре. КГИОП при этом ошибку признает — и обещает исправить, но только после вмешательства Минкульта. Минкульт кивает на КГИОП. Получается замкнутый круг. Все акты этой истории Коновалова описала здесь.
«Фонтанка» обратилась в КГИОП за комментарием — изданию тоже подтвердили ошибку. Чтобы исправить опечатку в постановлении правительства РФ, комитет огранизовал государственную историко-культурную экспертизу. Видимо, чтобы определить, что в Пушкина стрелял именно Жорж Шарль, а не вымышленный Эдмон. Или чтобы точно установить, что соперника Пушкина звали именно так — и никак иначе. Проверка идет, по информации издания, «за внебюджетный счет».
___
КГИОП — Комитет по государственному контролю, использованию и охране памятников истории и культуры
Иллюстрации: слева — Эдмон Дантес, граф Монте-Кристо. Справа — Жорж Шарль Дантес, соперник Пушкина.
Привет, это Софья. Смешная бюрократическая история развивается в Санкт-Петербурге.
Юристка Юлия Коновалова уже два года просит Минкульт и КГИОП* исправить ошибку в документах, которая закралась туда в 2001 году. В реестре объектов культурного наследия место дуэли Александра Пушкина на Коломяжском проспекте, в сквере у станции «Новая деревня», указано как «Место, где 27 января 1837 г. состоялась дуэль поэта Пушкина А.С. с Дантесом Э.».
Но Дантес — не Э., а Ж.Ш.! Жорж Шарль, французский офицер. Эдмон Дантес — это граф Монте-Кристо, главный герой романа Александра Дюма.
По словам Коноваловой, у нее нет никаких дел, связанных с Минкультом и КГИОП — и интерес к этому вопросу не связан с ее профессиональной деятельностью. Просто она хорошо училась в школе, любила Дюма — и точно знает, что Эдмон в этой истории не замешан. Опечатку, по ее словам, она увидела случайно. И из интереса обратилась в инстанции с просьбой ее исправить. Переписка длится с января 2023 года — опечатка все еще в реестре. КГИОП при этом ошибку признает — и обещает исправить, но только после вмешательства Минкульта. Минкульт кивает на КГИОП. Получается замкнутый круг. Все акты этой истории Коновалова описала здесь.
«Фонтанка» обратилась в КГИОП за комментарием — изданию тоже подтвердили ошибку. Чтобы исправить опечатку в постановлении правительства РФ, комитет огранизовал государственную историко-культурную экспертизу. Видимо, чтобы определить, что в Пушкина стрелял именно Жорж Шарль, а не вымышленный Эдмон. Или чтобы точно установить, что соперника Пушкина звали именно так — и никак иначе. Проверка идет, по информации издания, «за внебюджетный счет».
___
КГИОП — Комитет по государственному контролю, использованию и охране памятников истории и культуры
Иллюстрации: слева — Эдмон Дантес, граф Монте-Кристо. Справа — Жорж Шарль Дантес, соперник Пушкина.
😁22🥴4
Блог*
В const-контекстах теперь можно использовать &mut-ссылки
Я, кстати, пробовал свой compile-time fizzbuzz переписать, используя мутабельность, но короче или яснее он от этого не стал :/
Telegram
Блог*
#prog #rust #моё
(этот текст является логическим продолжением моей статьи о compile time Fizzbuzz, так что если вы её ещё не читали — настоятельно рекомендую начать с неё)
Кое-что при реализации всего этого дела я упустил: конечным продуктом всех этих type…
(этот текст является логическим продолжением моей статьи о compile time Fizzbuzz, так что если вы её ещё не читали — настоятельно рекомендую начать с неё)
Кое-что при реализации всего этого дела я упустил: конечным продуктом всех этих type…
😢2🤔1
#prog #rust #rustreleasenotes
(да, я пишу с опозданием почти в неделю, и что?)
Вышла версия Rust 1.85.0! Как всегда, тут только интересные мне части, остальное в полных заметках о релизе.
▪️Релизнули новую редакцию Rust 2024 edition! К сожалению, новая версия диапазонов не попала в эту версию.
🔸в
🔸также временные значения из последнего выражения в блоке теперь дропаются в конце блока, а не продолжают жить после него. Без этого изменения некоторый вполне нормально выглядящий код не компилировался:
🔸запрещены некоторые паттерны, которые крайне неочевидным образом взаимодействуют с pattern match ergonomics. Посмотрите по ссылке, там действительно странные вещи.
🔸
🔸cargo теперь по умолчанию учитывает MSRV при выборе версии зависимости.
Пачка изменений, связанных с unsafe кодом:
🔸
🔸атрибуты
🔸unsafe_op_in_unsafe_fn warn по умолчанию.
🔸ссылки на
🔸если компилятор не может вывести тип, к которому нужно привести выражение типа
▪️Теперь замыкания могут быть
В отличие от замыканий, возвращающих
▪️
▪️Для беззнаковых чисел, соответствующих
▪️В
▪️
(да, я пишу с опозданием почти в неделю, и что?)
Вышла версия Rust 1.85.0! Как всегда, тут только интересные мне части, остальное в полных заметках о релизе.
▪️Релизнули новую редакцию Rust 2024 edition! К сожалению, новая версия диапазонов не попала в эту версию.
🔸в
if let
значение, по которому идёт сопоставление с образцом, теперь дропается перед входом в else ветку вместо после конца if let. Это позволило, в частности, избежать багов, когда guard из примитива синхронизации живёт дольше необходимого.🔸также временные значения из последнего выражения в блоке теперь дропаются в конце блока, а не продолжают жить после него. Без этого изменения некоторый вполне нормально выглядящий код не компилировался:
// не компилируется до Rust 2024, компилируется после
fn f() -> usize {
let c = RefCell::new("..");
c.borrow().len()
}
🔸запрещены некоторые паттерны, которые крайне неочевидным образом взаимодействуют с pattern match ergonomics. Посмотрите по ссылке, там действительно странные вещи.
🔸
std::env::set_var
, std::env::remove_var
и std::os::unix::process::CommandExt::before_exec
теперь являются unsafe функциями. Сделать их unsafe
во всех редакциях, увы, мешает обратная совместимость.🔸cargo теперь по умолчанию учитывает MSRV при выборе версии зависимости.
Пачка изменений, связанных с unsafe кодом:
🔸
extern
-блоки теперь должны быть объявлены с unsafe, чтобы показать, что ответственность за корректность определений лежит на том, кто пишет extern
блок. Дополнительно определения внутри extern
-блока теперь могут быть помечены safe
. В этом случае компилятор будет предполагать, что для доступа и использования этих определений не нужны специальные предусловия, и их можно использовать вне unsafe
-блоков. В качестве примера можно привести sqrt
из стандартной библиотеки C: не смотря на то, что это внешняя функция, её можно вызвать с любым значением, не вызывая UB.🔸атрибуты
no_mangle
, export_name
и link_section
теперь должны быть записаны через #[unsafe(...)]. С этими атрибутами можно сломать гарантии, которые даёт компилятор, и компилятор не может проверить, что их использование корректно.🔸unsafe_op_in_unsafe_fn warn по умолчанию.
🔸ссылки на
static mut
являются по умолчанию ошибкой компиляции.🔸если компилятор не может вывести тип, к которому нужно привести выражение типа
!
, то он использует т. н. fallback. До Rust 2024 это был ()
, теперь это !
. Так как это может сломать существующий unsafe
-код, компилятор теперь по умолчанию даёт ошибку компиляции, если такое приведение происходит в unsafe-коде.▪️Теперь замыкания могут быть
async
!let mut vec: Vec<String> = vec![];
let closure = async || {
vec.push(ready(String::from("")).await);
};
В отличие от замыканий, возвращающих
async
-блок, футуры, возвращаемые этими замыканиями, могут использовать ссылки на то, что замыкание захватывает. В типах это выражается тем, что возвращаемые async
-замыканиями футуры связаны временем жизни с самим замыканием. Из-за того, что эту связь пока что невозможно выразить с обычными Fn*
-трейтами, в core::ops
добавили AsyncFnOnce, AsyncFnMut и AsyncFn. Как и обычные Fn*
-трейты, в ограничениях их можно использовать лишь в засахаренном виде.▪️
FromIterator
и Extend
теперь реализованы для всех кортежей до арности 12 включительно и имеют семантику, аналогичную Iterator::unzip
.▪️Для беззнаковых чисел, соответствующих
NonZero
и чисел с плавающей точкой добавили метод midpoint. Тривиальная вещь, но из-за переполнения её очень легко реализовать неправильно.▪️В
const
-контексте теперь можно использовать, помимо прочего, несколько простых арифметических функций на числах с плавающей точкой и swap
, как на ссылках, так и на сырых указателях.▪️
macro_rules
, объявленные макросами, теперь используют редакцию кода, в котором они раскрываются, вместо редакции кода, в котором определён внешний макрос.🎉12❤🔥2👍1
Мемный Болт Генона
Linus Torvalds Would Reportedly Merge Rust Kernel Code Over Maintainer Objections https://www.phoronix.com/news/Torvalds-Override-On-Rust-Code Открытка @itpgchannel
#rustforlinux
Дальнейшие события:
Линус 19 февраля в треде с обсуждением политики ядра насчёт кода на Rust ответил на комментарий Кристофа и указал на неадекватное поведение:
24 февраля Andreas Hindborg послал серию патчей, которые добавляли Rust-интерфейс для configfs. В числе получателей был указан и Кристоф Хэллвиг, который поддерживает в том числе и эту подсистему.
Ответа от него в этом треде не было: в тот же день он удалил себя из списка сопровождающих dma-mapping и configfs. При этом совсем из разработки ядра он не уходит: он всё ещё остаётся сопровождающим нескольких других подсистем.
Детский сад, ей-богу.
Дальнейшие события:
Линус 19 февраля в треде с обсуждением политики ядра насчёт кода на Rust ответил на комментарий Кристофа и указал на неадекватное поведение:
I find it distressing that you are complaining about new users of your code, and then you keep bringing up these kinds of complete garbage arguments.
<...>
So this email is not about some "Rust policy". This email is about a much bigger issue: as a maintainer you are in charge of your code, sure - but you are not in charge of who uses the end result and how.
<...>
You can't have it both ways. You can't say "I want to have nothing to do with Rust", and then in the very next sentence say "And that means that the Rust code that I will ignore cannot use the C interfaces I maintain".
<...>
But that "wall of protection" basically goes both ways. If you don't want to deal with the Rust code, you get no *say* on the Rust code.
Put another way: the "nobody is forced to deal with Rust" does not imply "everybody is allowed to veto any Rust code".
See?
24 февраля Andreas Hindborg послал серию патчей, которые добавляли Rust-интерфейс для configfs. В числе получателей был указан и Кристоф Хэллвиг, который поддерживает в том числе и эту подсистему.
Ответа от него в этом треде не было: в тот же день он удалил себя из списка сопровождающих dma-mapping и configfs. При этом совсем из разработки ядра он не уходит: он всё ещё остаётся сопровождающим нескольких других подсистем.
Детский сад, ей-богу.
🤡17❤🔥1🔥1🥰1🍌1
Forwarded from Too Long, Did Read
This media is not supported in your browser
VIEW IN TELEGRAM
Самый большой диван, который можно передвинуть за угол
https://www.quantamagazine.org/the-largest-sofa-you-can-move-around-a-corner-20250214/
Очень прикольная история!
В 1966 году математик Лео Мосер сформулировал задачу “moving sofa”:
Представим себе коридор шириной 1 ед с поворотом на 90° в конце.
Задача - найти максимально большой по площади двумерный диван, который можно продвинуть через угол.
Как оказалось, задача эта ни разу не тривиальная, и на ее решение ушло больше 50 лет.
Даже интереснее: в 1992 другой ученый по фамилии Гервер предложил супер нетривиальную форму дивана (на видео), при которой площадь достигает 2.2195 ед^2.
Но ни он, ни другие математики не могли формально доказать, что эта форма является оптимальной.
Пара интересных моментов:
- По сути, задача сводится к нахождению функции расчета площади произвольной двумерной фигуры.
Вот только в общем случае она не решается!
Простой пример: сравните формулу расчета площади круга и треугольника - ничего общего.
- Форма дивана Гервера состоит из 18 элементов сложной формы, и ее площадь не описывается ни в каких известных величинах (π и прочих).
Но, тем не менее, она является оптимальным решением задачи “двигающегося дивана”.
И вот в декабре 2024 молодой корейский математик Jineon Baek представил свое доказательство оптимальности дивана Гервера.
Он представил все допустимые варианты формы дивана в качестве точек бесконечно-мерного пространства, и создал такую фукнцию Q, которая удовлетворяла нескольким условиям:
- Для произвольной точки в пространстве диванов Q выдает значение, больше или равное площади дивана такой формы.
- Для точки, соответсвтующей дивану Гервера, значение Q = фактической площади дивана.
- Функция “ведет себя” похоже на параболу
Дальше ему оставалось доказать, что функция достигает максимума как раз в точке Q - тогда диван Гервера будет оптимальным решением задачи о перетаскивании дивана. Что он и сделал в своей 119-ти страничной работе.
Кстати, Герверу сейчас 75 и, с его слов, ему “повезло дожить до момента”, когда его решение наконец обосновали. Мощно!
Красивый и немного безумный мир математических задач, сформулировать которые может даже ребенок, а вот решать некоторые из них 30 лет, а потом еще 30 лет доказывать оптимальность решения)
https://www.quantamagazine.org/the-largest-sofa-you-can-move-around-a-corner-20250214/
Очень прикольная история!
В 1966 году математик Лео Мосер сформулировал задачу “moving sofa”:
Представим себе коридор шириной 1 ед с поворотом на 90° в конце.
Задача - найти максимально большой по площади двумерный диван, который можно продвинуть через угол.
Как оказалось, задача эта ни разу не тривиальная, и на ее решение ушло больше 50 лет.
Даже интереснее: в 1992 другой ученый по фамилии Гервер предложил супер нетривиальную форму дивана (на видео), при которой площадь достигает 2.2195 ед^2.
Но ни он, ни другие математики не могли формально доказать, что эта форма является оптимальной.
Пара интересных моментов:
- По сути, задача сводится к нахождению функции расчета площади произвольной двумерной фигуры.
Вот только в общем случае она не решается!
Простой пример: сравните формулу расчета площади круга и треугольника - ничего общего.
- Форма дивана Гервера состоит из 18 элементов сложной формы, и ее площадь не описывается ни в каких известных величинах (π и прочих).
Но, тем не менее, она является оптимальным решением задачи “двигающегося дивана”.
И вот в декабре 2024 молодой корейский математик Jineon Baek представил свое доказательство оптимальности дивана Гервера.
Он представил все допустимые варианты формы дивана в качестве точек бесконечно-мерного пространства, и создал такую фукнцию Q, которая удовлетворяла нескольким условиям:
- Для произвольной точки в пространстве диванов Q выдает значение, больше или равное площади дивана такой формы.
- Для точки, соответсвтующей дивану Гервера, значение Q = фактической площади дивана.
- Функция “ведет себя” похоже на параболу
Дальше ему оставалось доказать, что функция достигает максимума как раз в точке Q - тогда диван Гервера будет оптимальным решением задачи о перетаскивании дивана. Что он и сделал в своей 119-ти страничной работе.
Кстати, Герверу сейчас 75 и, с его слов, ему “повезло дожить до момента”, когда его решение наконец обосновали. Мощно!
Красивый и немного безумный мир математических задач, сформулировать которые может даже ребенок, а вот решать некоторые из них 30 лет, а потом еще 30 лет доказывать оптимальность решения)
🔥16👍6❤3❤🔥1
В CRI API есть метод GetContainerEvents, который возвращает стрим событий о контейнерах: создание, старт, остановка и удаление. Вопрос: почему у клиента напрочь отсутствует возможность задать при вызове фильтр, из-за чего фильтрацию по типам событий, меткам и прочему нужно выполнять клиенту, а контейнер-рантайму гонять лишние данные по сети? У ListContainers при этом задать фильтр при запросе можно.
#prog #бомбёжкипост
#prog #бомбёжкипост
🤔10
#prog #rust #article
Tokio + prctl = nasty bug
История дебага крайне странного бага, который сложился из двух дизайн-решений в HyperQueue и одного в tokio, каждое из которых по отдельности смотрится нормально (а ещё, на мой взгляд, из не очень полезного поведения линуксового API).
Tokio + prctl = nasty bug
История дебага крайне странного бага, который сложился из двух дизайн-решений в HyperQueue и одного в tokio, каждое из которых по отдельности смотрится нормально (а ещё, на мой взгляд, из не очень полезного поведения линуксового API).
👍7
#prog #rust #article
Rust Deep Dive: Borked Vtables and Barking Cats
Или о преступлениях по подмене таблиц виртуальных функций (miri не рад)
Rust Deep Dive: Borked Vtables and Barking Cats
Или о преступлениях по подмене таблиц виртуальных функций (miri не рад)
geo-ant.github.io
Rust Deep Dive: Borked Vtables and Barking Cats
No, this post does not contain cruelty towards animals but only to our own sanity. We will explore a
particular aspect of how Rust’s trait objects work behind the scenes and
take a deep dive down the rabbit hole. Sometimes it’s good to be reminded that
all…
particular aspect of how Rust’s trait objects work behind the scenes and
take a deep dive down the rabbit hole. Sometimes it’s good to be reminded that
all…
❤4🤔1