#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)
"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)
Reddit
r/rust on Reddit
We just massively overdelivered on a project thank... - 835 votes and 103 comments
Блог*
#prog #article Статья (и продолжение) о дизайне hypothesis — библиотеки для property-based тестирования (вообще для Python, но с портами на другие языки, включая Rust). В отличие от родоначальника подхода QuickCheck, в котором для генерирования произвольных…
#prog #article
Не смотря на то, что property-based часто поразительно эффективно, начать использовать его на практике часто сложно, поскольку инварианты, которые требуют проверки, как правило, не очевидны. В этом случае можно начать с простого: для начала просто проверять, что функция в принципе не падает при всех допустимых значениях аргументов. В какой-то степени это походит на фаззинг, однако такой подход отличается осведомлённостью о типах и имеет преимущество в виде автоматической минификации фейлящих наборов аргументов.
После этого можно продолжить тем, чтобы найти в кодовой базе конвертации "в" и "из" некоторого формата (не обязательно именно (де)сериализация, одни и те же данные часто могут быть представлены по разному в разных частях программы) и удостовериться, что их композиция является функцией идентичности, как и должно быть.
И чтобы окончательно развеять сомнения в практичности данного подхода, советую почитать заметку о том, как два разработчика, которые до этого не имели опыта с PBT, интегрировали Hypothesis в тестирование своей консольной программы. Как показывает эта заметка, даже частичный переход на Hypothesis может весьма сильно повысить эффективность тестирования — в частности, авторам удалось выяснить, что у них де-факто нигде нету чётко прописанный ограничений на содержимое одного из аргументов.
Не смотря на то, что property-based часто поразительно эффективно, начать использовать его на практике часто сложно, поскольку инварианты, которые требуют проверки, как правило, не очевидны. В этом случае можно начать с простого: для начала просто проверять, что функция в принципе не падает при всех допустимых значениях аргументов. В какой-то степени это походит на фаззинг, однако такой подход отличается осведомлённостью о типах и имеет преимущество в виде автоматической минификации фейлящих наборов аргументов.
После этого можно продолжить тем, чтобы найти в кодовой базе конвертации "в" и "из" некоторого формата (не обязательно именно (де)сериализация, одни и те же данные часто могут быть представлены по разному в разных частях программы) и удостовериться, что их композиция является функцией идентичности, как и должно быть.
И чтобы окончательно развеять сомнения в практичности данного подхода, советую почитать заметку о том, как два разработчика, которые до этого не имели опыта с PBT, интегрировали Hypothesis в тестирование своей консольной программы. Как показывает эта заметка, даже частичный переход на Hypothesis может весьма сильно повысить эффективность тестирования — в частности, авторам удалось выяснить, что у них де-факто нигде нету чётко прописанный ограничений на содержимое одного из аргументов.
hypothesis.works
Getting started with Hypothesis - Hypothesis
Getting started with Hypothesis Hypothesis will speed up your testing process and improve your software quality,
but when first starting out people often struggle to figure out exactly how to use it.
Until you’re used to thinking in this style of testing…
but when first starting out people often struggle to figure out exactly how to use it.
Until you’re used to thinking in this style of testing…
xxx: дык зачем ты делал нехороше?)))) в ТЗ же ясно сказано: делайте хорошо, а плохо -- не делайте
#трудовыебудни
#трудовыебудни
#prog #rust #article
Статья про проблемы с chrono (и про то, как наследие UNIX опять поднасрало).
TL;DR: chrono имеет проблемы с soundness, которые уже приводили к реальным сегфолтам в растовых программах, и не обновляется, а потому, по всей видимости, не получит фиксов никогда. В качестве альтернативы предлагают использовать time, ибо если раньше резон использовать chrono был из-за того, что у chrono более широкий спектр возможностей, то после выхода time v0.3 это уже далеко не столь справедливо.
Статья про проблемы с chrono (и про то, как наследие UNIX опять поднасрало).
TL;DR: chrono имеет проблемы с soundness, которые уже приводили к реальным сегфолтам в растовых программах, и не обновляется, а потому, по всей видимости, не получит фиксов никогда. В качестве альтернативы предлагают использовать time, ибо если раньше резон использовать chrono был из-за того, что у chrono более широкий спектр возможностей, то после выхода time v0.3 это уже далеко не столь справедливо.
вафелька и амос показали мне что я не делаю ничего достойного внимания спасибо как теперь жить дальше
#prog #article
Статья (перевод) о том, какие офигенные вещи умудряются делать фанаты графических калькуляторов. Как насчёт загрузчика, работающего на реверс-инжинирнутых функциях и позволяющий запускать игры с gameboy?
Статья (перевод) о том, какие офигенные вещи умудряются делать фанаты графических калькуляторов. Как насчёт загрузчика, работающего на реверс-инжинирнутых функциях и позволяющий запускать игры с gameboy?
www.thirtythreeforty.net
The Insane Innovation of TI Calculator Hobbyists
Never underestimate the determination of a kid who is time-rich and cash-poor
#prog #rust #rustlib
Если вам вдруг потребовалось вынимать байтики из
lib.rs/crates/utf8-chars
Если вам вдруг потребовалось вынимать байтики из
BufRead и на лету декодировать в char, то для этого есть библиотека.lib.rs/crates/utf8-chars
Lib.rs
utf8-chars — Rust data encoding library
Char-per-char iterator and `read_char` method for `BufRead`
Блог*
#prog #video Как писать тесты (если быть более точным — тесты для property-based тестирования). Лично для меня поразила идея metamorphic testing — простая и вместе с тем плодотворная. https://youtu.be/zvRAyq5wj38
Hillel Wayne
Metamorphic Testing
Confession: I read the ACM Magazine. This makes me a dweeb even in programming circles. One of the things I found in it is “Metamorphic Testing”. I’ve never heard of it, and nobody I knew heard about it either. But the academic literature was shockingly impressive:…
#prog #ocaml #article
Не смотря на то, что исторически property-based testing применялось для тестирования чистых функций, технически ничто не мешает тестировать и функции с некоторыми побочными эффектами. Тем не менее, при переносе этого подхода на компиляторы возникает очевидная проблема: все сколько-нибудь полезные программы обладают побочными эффектами, и языки далеко не всегда определяют порядок вычислений достаточно точно, чтобы предсказать вывод обладающей побочными эффектами фрагмента программы исключительно по исходному коду. Одним из таких языков является OCaml: среди его реализаций есть как те, которые вычисляют порядок аргументов слева направо, так и те, которые вычисляют справа налево. Это делает генерацию исходных программ с целью тестирования несколько затруднительной, поскольку вывод даже корректно скомпилированной программы может зависеть от реализации.
В статье Effect-Driven QickChecking of Compilers авторы решили эту проблему, спроектировав генератор, который создаёт лишь программы, вывод которых не зависит от порядка вычислений. Сделали они это путём введения рудиментарной системы эффектов (попутно доказав её корректность) и архитектуры генератора, позволяющей на ранних этапах генерации отбрасывать альтернативы, которые бы привели к зависимости от конкретного порядка вычислений. Вместе с генератором они также спроектировали минификатор, позволяющий минифицировать программы с сохранением полезного свойства независимости (впрочем, это получилось скорее автоматически ввиду того, что это свойство было закодировано в эффектах, а элементарные операции минификации сохраняли тип).
Генератор получился достаточно ограниченным. Он генерирует только весьма узкое подмножество всех программ (в частности, никакого полиморфизма, ни по типам, не по эффектам), и, в частности, генерирует только программы, которые гарантированно завершаются. Вдобавок, введённая система эффектов отслеживает исключительно сам факт наличия побочного эффекта, но не его конкретную разновидность. Тем не менее, даже такое ограниченный инструмент оказался полезным на практике. Используя реализацию QuickCheck для OCaml для свойства "для любой программы, сгенерированной генератором, вывод этой программы при использовании двух разных компиляторов одинаков", авторы смогли обнаружить четыре новых бага, а также найти два уже ранее известных.
P. S.: единственное, что меня смущает — это лемма об ослаблении контекста типизации в разделе, в котором доказывается корректность системы типов с эффектами:
Не смотря на то, что исторически property-based testing применялось для тестирования чистых функций, технически ничто не мешает тестировать и функции с некоторыми побочными эффектами. Тем не менее, при переносе этого подхода на компиляторы возникает очевидная проблема: все сколько-нибудь полезные программы обладают побочными эффектами, и языки далеко не всегда определяют порядок вычислений достаточно точно, чтобы предсказать вывод обладающей побочными эффектами фрагмента программы исключительно по исходному коду. Одним из таких языков является OCaml: среди его реализаций есть как те, которые вычисляют порядок аргументов слева направо, так и те, которые вычисляют справа налево. Это делает генерацию исходных программ с целью тестирования несколько затруднительной, поскольку вывод даже корректно скомпилированной программы может зависеть от реализации.
В статье Effect-Driven QickChecking of Compilers авторы решили эту проблему, спроектировав генератор, который создаёт лишь программы, вывод которых не зависит от порядка вычислений. Сделали они это путём введения рудиментарной системы эффектов (попутно доказав её корректность) и архитектуры генератора, позволяющей на ранних этапах генерации отбрасывать альтернативы, которые бы привели к зависимости от конкретного порядка вычислений. Вместе с генератором они также спроектировали минификатор, позволяющий минифицировать программы с сохранением полезного свойства независимости (впрочем, это получилось скорее автоматически ввиду того, что это свойство было закодировано в эффектах, а элементарные операции минификации сохраняли тип).
Генератор получился достаточно ограниченным. Он генерирует только весьма узкое подмножество всех программ (в частности, никакого полиморфизма, ни по типам, не по эффектам), и, в частности, генерирует только программы, которые гарантированно завершаются. Вдобавок, введённая система эффектов отслеживает исключительно сам факт наличия побочного эффекта, но не его конкретную разновидность. Тем не менее, даже такое ограниченный инструмент оказался полезным на практике. Используя реализацию QuickCheck для OCaml для свойства "для любой программы, сгенерированной генератором, вывод этой программы при использовании двух разных компиляторов одинаков", авторы смогли обнаружить четыре новых бага, а также найти два уже ранее известных.
P. S.: единственное, что меня смущает — это лемма об ослаблении контекста типизации в разделе, в котором доказывается корректность системы типов с эффектами:
If
∆;Γ,(x : τ′),Γ′ ⊢ e : τ & φ and τ′′ ⊑ τ′
then
∆;Γ,(x : τ′′),Γ′ ⊢ e : τ & φ
или, если словами, произвольный тип внутри контекста типизации можно заменить на тип с более слабым эффектом. Лично мне это не кажется очевидным от слова совсем.Forwarded from Аниме-блог | Cheetamaru
Метка подсчёта — иероглиф 正
Когда нужно посчитать на бумаге, сколько раз случилось какое-либо событие, мы обычно используем четыре вертикальные палочки и одну их перекрывающую — такой полный рисунок означает «5 штук».
Этот символ распространён практически во всех Европейских странах и в Америке.
Но в странах, где используются китайские иероглифы, функцию метки подсчёта выполняет иероглиф 正. Его значение — «правильный, справедливый», но в контексте подсчёта значение не важно. Важно, что он пишется пятью строками.
Поэтому в аниме, когда персонажи хотят подсчитать, например, сколько человек проголосует за тот или иной вариант проведения школьного фестиваля, на школьной доске можно увидеть иероглифы 正.
#JapanFact
Когда нужно посчитать на бумаге, сколько раз случилось какое-либо событие, мы обычно используем четыре вертикальные палочки и одну их перекрывающую — такой полный рисунок означает «5 штук».
Этот символ распространён практически во всех Европейских странах и в Америке.
Но в странах, где используются китайские иероглифы, функцию метки подсчёта выполняет иероглиф 正. Его значение — «правильный, справедливый», но в контексте подсчёта значение не важно. Важно, что он пишется пятью строками.
Поэтому в аниме, когда персонажи хотят подсчитать, например, сколько человек проголосует за тот или иной вариант проведения школьного фестиваля, на школьной доске можно увидеть иероглифы 正.
#JapanFact
Аниме-блог | Cheetamaru
Метка подсчёта — иероглиф 正 Когда нужно посчитать на бумаге, сколько раз случилось какое-либо событие, мы обычно используем четыре вертикальные палочки и одну их перекрывающую — такой полный рисунок означает «5 штук». Этот символ распространён практически…
И ведь не сказать, что это какая-то неразумная вещь: в отличие от перечеркнутых палочек, фигура после учёта каждого предмета выглядит заметно иначе, чем после учёта других, так что так куда сложнее перепутать, скажем, "3" и "4"