антон

Ну и источник, чтобы не был очередной #wafflecontext

#prog

Интервью от 2004 года с Julian Seward, создателем Valgrind. Не смотря на возраст материала, читать интересно.

Некоторые интересные моменты:

* В отличие от приличного количества инструментов из мира UNIX, Valgrind был создан в 21 веке (первая версия вышла в 2002 году)

* "One of the major parts of GHC I worked on was the back-end x86 and SPARC code generators, and the register allocator. From this I learnt a lot about the x86 instruction set and code generation techniques, and the idea of making a memory-checking tool for Linux came back into view."

* Вопреки расхожему мнению, название Valgrind — не сокращение от "value grinder" или чего-то похожего, как можно было бы подумать, а взято из скандинавской мифологии (передаю привет Антону)

* "Valgrind is only useful because C and C++ are such crappy programming languages."

* "Valgrind is loaded with assertion checks and internal sanity checkers which periodically inspect critical data structures. These are permanently enabled. I don't care if 5 percent or even 10 percent of the total run-time is spent in these checks—automated debugging is the way to go. As a result, Valgrind almost never segfaults—instead it emits some kind of a useful error message before dying. That's something I'm rather proud of."

#prog #article #soc

В основе библиотек для PBT (property-based testing) лежит фреймворк для нахождения и минификации набора аргументов, на котором выполняется некоторый предикат. Этот фреймворк можно применять для совсем разных целей, например, для того, чтобы найти набор предпочтений избирателей, на которых разные методики выборов дадут разные показатели (да, это всё ещё блог hypothesis).

И да, альтернативы обычному большинству голосов есть. В этой статье с интерактивными визуализациями от Nicky Case рассказывается о пяти различных альтернативах и о их разных свойствах. Абсолютно лучшей среди них нету, но все они выгодно отличаются от простого большинства отсутствием эффекта спойлера (когда введение в списки голосований непопулярного кандидата, который, тем не менее, оттягивает на себя голоса, позволяет сменить исход выборов между двумя наиболее популярными кандидатами).

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

Извините, но чуток #wafflecontext. Надеюсь, вы следите за новостями

Подписчики, дорогие мои, в довольно скором времени будет Rustcon. Мне туда хочется попасть (🧇), но идти просто слушателем не хочется а ещё меня жаба душит отдавать за билет 14 тысяч. Поэтому у меня есть хитрый план: взять один из своих авторских постов в Блог*е и переработать его в доклад. Так что у меня к вам вопрос: какой пост(ы), на ваш взгляд, заслуживает конвертации в доклад для конфы?

#prog #rust #моё

Как я уже рассказывал, гетерогенные списки (HList) бывают весьма удобными для различных выкрутасов на уровне типов. Сегодня я расскажу о том, как можно из отдельных компонент, реализующих поведение, диктуемое обобщённым типом, собрать HList, который будет выбирать нужную операцию в зависимости от типа — фактически, статический type dispatch. Для того, чтобы разговор был более конкретным, обозначим функционал, который мы будем пытаться совмещать:

trait Provide<Item> {
   fn provide(&mut self) -> Item;
}

И строительные блоки:

struct HNil;
struct HCons<H, T>(H, T);

Первое, что приходит на ум — это реализация в лоб, т. е. реализовать трейт для HCons в том случае, если его реализует либо голова, либо хвост:

impl<Item, H, T> Provide<Item> for HCons<H, T>
where
   H: Provide<Item>,
{
   fn provide(&mut self) -> Item {
       self.0.provide()
   }
}

impl<Item, H, T> Provide<Item> for HCons<H, T>
where
   T: Provide<Item>,
{
   fn provide(&mut self) -> Item {
       self.1.provide()
   }
}

Даже без запуска понятно, что это не сработает: если и голова, и хвост реализуют Provide<Item>, то у нас выходит две различные реализации для HCons. И действительно, компилятор жалуется:

error[E0119]: conflicting implementations of trait Provide<_> for type HCons<_, _>

Мы можем сделать разные трейты для Provide из головы и Provide из хвоста и потом объединить их при помощи blanket impl, но мы опять упрёмся в перекрывающиеся реализации. Так что же делать?

Проблема с наивным подходом состоит в том, что мы пытаемся реализовать один и тот же трейт двумя разными способами. А что, если мы вынесем источник, откуда взята реализация, в какой-то тип? В этом случае две реализации будут различаться путём до источника метода provide, а потому формально это будут два разных трейта (точнее, один, параметризованный двумя разными наборами тИповых аргументов). Явно этот путь нам прописывать не нужно, за нас его напишет вывод типов.

Вводить этот путь при помощи ассоциированных типов — тупиковый вариант, потому что они не являются параметрами трейтов. Нам придётся поменять определение Provide и внести в него ещё один тИповой параметр:

trait Provide<Item, Path> {
   fn provide(&mut self) -> Item;
}

И, конечно, добавить типовые маркеры, отвечающие за компоненты пути:

struct Itself;
struct Head<T>(T);
struct Tail<T>(T);

Теперь модифицируем реализации для Hcons:

impl<Item, H, T, HSource> Provide<Item, Head<HSource>> for HCons<H, T>
where
   H: Provide<Item, HSource>,
{
   fn provide(&mut self) -> Item {
       self.0.provide()
   }
}

impl<Item, H, T, TSource> Provide<Item, Tail<TSource>> for HCons<H, T>
where
   T: Provide<Item, TSource>,
{
   fn provide(&mut self) -> Item {
       self.1.provide()
   }
}

И... Оно компилируется. Что ж, сделаем пример:

struct Cloning<T>(T);

impl<T> Provide<T, Itself> for Cloning<T>
where
   T: Clone,
{
   fn provide(&mut self) -> T {
       self.0.clone()
   }
}

fn _test() {
   let mut list = HCons(Cloning(0), HCons(Cloning(()), HNil));
   let _: u32 = list.provide();
   let _: ()  = list.provide();
}

Как видите, всё прекрасно работает, нужные типы выводятся по возвращаемому результату. Сила вывода типа!

Окей, а что будет, если в списке окажется два типа, которые могут предоставлять требуемый тип, или, наоборот, не будет ни одного? Проверим:

let mut list = HCons(Cloning(()), HCons(Cloning(()), HNil));
let _: u32 = list.provide();

Ответ компилятора:

error[E0277]: the trait bound `HCons<Cloning<()>, HCons<Cloning<()>, HNil>>: Provide<u32, _>` is not satisfied
 --> src/lib.rs:47:23
  |
47 |     let _: u32 = list.provide();
  |                       ^^^^^^^ the trait `Provide<u32, _>` is not implemented for `HCons<Cloning<()>, HCons<Cloning<()>, HNil>>`

Что ж, вполне логичный ответ. А теперь для конфликтующих провайдеров:

let mut list = HCons(Cloning(()), HCons(Cloning(()), HNil));
let _: ()  = list.provide();

Ответ компилятора:

error[E0282]: type annotations needed
 --> src/lib.rs:47:23
  |
47 |     let _: ()  = list.provide();
  |                       ^^^^^^^ cannot infer type for type parameter `Path` declared on the trait `Provide`

Что ж, ошибка явно могла бы быть более внятной, но, по крайней мере, она есть.

Так что, мы закончили? Не совсем. Есть парочка вещей, которые мне не нравятся.

Во-первых, тем, кто это использует, придётся реализовывать Provide<Item, Itself> для своих типов, ибо навряд ли они такие же обобщённые. Несколько бойлерплейтно. Обходится созданием отдельного трейта, который будет реализовывать Provide<_, Itself> через blanket impl:

trait ProvideBase<Item> {
    fn provide_base(&mut self) -> Item;
}

impl<Item, T> Provide<Item, Itself> for T
where
    T: ProvideBase<Item>,
{
    fn provide(&mut self) -> Item {
        self.provide_base()
    }
}

Во-вторых, при реализации Provide можно использовать произвольные типы для путей, что позволяет немного сломать код:

impl Provide<u32, Head<Itself>> for HCons<(), HNil> {
   fn provide(&mut self) -> u32 {
       0
   }
}

// где-то в коде
let _: u32 = HCons(Cloning(42u32), HCons((), HNil)).provide();
         // ^~~ error: type annotations needed

Это было бы неприятным, если бы мы строили вокруг этого библиотеку, даром, что ломается пользовательский код. Оградиться от этого, теме не менее, достаточно просто: сделаем sealed trait для типов-компонент путей, повесим в качестве ограничения на тип Path в определении Provide, и реализуем для Head, Tale и Itself, но Itself оставим единственным публичным типом.

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

trait ProvideExt<T> {
   fn provide_via_path<P>(&mut self) -> T
   where
       Self: Provide<T, P>;
}

impl<Item, T> ProvideExt<Item> for T {
   fn provide_via_path<P>(&mut self) -> Item
   where
       Self: Provide<Item, P>,
   {
       self.provide()
   }
}

Ну и прежде чем закончить, хочу отметить, что решение с путями на уровне типов я придумал не на пустом месте, а вдохновившись вот этим постом Дэдфуда. Вот и всё, как всегда, весть код в гисте.

#prog #rust #menacingopensource

В Rust завезли SFINAE. Ну, почти.

#music #video

Потому что это, чёрт побери, замечательно.

youtube.com/watch?v=Q45yicposyI

В СМЫСЛЕ УЖЕ НОЯБРЬ

#prog #rust #python #successstory

"Just to see what happened, I copied the code over to Rust and made the nessecary syntax changes for it to compile (entirely the same code - just in Rust) - and voilà, reading the model now took 330ms, thats 15x faster, and the rasterization took just 25ms, which is a whopping ~2500x faster. Yes, 25 milliseconds instead of 61 seconds, same code, same algorithm"

old.reddit.com/r/rust/comments/qjxwni/we_just_massively_overdelivered_on_a_project

(thanks @psilon)

#prog #article

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

После этого можно продолжить тем, чтобы найти в кодовой базе конвертации "в" и "из" некоторого формата (не обязательно именно (де)сериализация, одни и те же данные часто могут быть представлены по разному в разных частях программы) и удостовериться, что их композиция является функцией идентичности, как и должно быть.

И чтобы окончательно развеять сомнения в практичности данного подхода, советую почитать заметку о том, как два разработчика, которые до этого не имели опыта с PBT, интегрировали Hypothesis в тестирование своей консольной программы. Как показывает эта заметка, даже частичный переход на Hypothesis может весьма сильно повысить эффективность тестирования — в частности, авторам удалось выяснить, что у них де-факто нигде нету чётко прописанный ограничений на содержимое одного из аргументов.

#cpp

https://twitter.com/Morwenn_Ed/status/1454968145203105795

(thanks @vpermilp)

xxx: дык зачем ты делал нехороше?)))) в ТЗ же ясно сказано: делайте хорошо, а плохо -- не делайте

#трудовыебудни

#prog #rust #article

Статья про проблемы с chrono (и про то, как наследие UNIX опять поднасрало).

TL;DR: chrono имеет проблемы с soundness, которые уже приводили к реальным сегфолтам в растовых программах, и не обновляется, а потому, по всей видимости, не получит фиксов никогда. В качестве альтернативы предлагают использовать time, ибо если раньше резон использовать chrono был из-за того, что у chrono более широкий спектр возможностей, то после выхода time v0.3 это уже далеко не столь справедливо.

#prog #python #meme

https://twitter.com/fasterthanlime/status/1248025337235210243

вафелька и амос показали мне что я не делаю ничего достойного внимания спасибо как теперь жить дальше

#prog #article

Статья (перевод) о том, какие офигенные вещи умудряются делать фанаты графических калькуляторов. Как насчёт загрузчика, работающего на реверс-инжинирнутых функциях и позволяющий запускать игры с gameboy?