Блог*
#prog #rust #rustreleasenotes Вышла версия Rust 1.84.0! Как всегда, тут только некоторые вещи, а остальное в полных заметках о релизе. ▪️Когерентность — свойство системы типов Rust: для любой наперёд заданной пары трейта и типа существует не более одного…
Please open Telegram to view this post
VIEW IN TELEGRAM
Блог*
#video Да это и не #meme особо. Почаще говорите парням комплименты, пожалуйста. youtube.com/watch?v=jKhP750VdXw
YouTube
grown men .0002 seconds after being complimented
Nebula: https://go.nebula.tv/mancarryingthing
Letterboxd: https://letterboxd.com/ManCarrying/
Twitter: https://twitter.com/ManCarrying
Merch: https://mancarryingthing.com
Our second channel: https://www.youtube.com/channel/UC8aGE10t6QrcdRMpgorwkAA
Patreon:…
Letterboxd: https://letterboxd.com/ManCarrying/
Twitter: https://twitter.com/ManCarrying
Merch: https://mancarryingthing.com
Our second channel: https://www.youtube.com/channel/UC8aGE10t6QrcdRMpgorwkAA
Patreon:…
#prog #rust хайлайты.
TL;DR: тык.
Среди многих хороших вещей, которые есть в Rust — указание версии, начиная с которой определение стабильно. Главным образом это относится к API в стандартной библиотеке, но эта информация также хранится и для фич компилятора — это позволяет компилятору указывать на то, что
Долгое время эта версия указывалась вручную. Это обычно не так сложно — новое определение попадает в stable-версию, которая на три версии старше текущей. Однако PR в Rust имеют свойство затягиваться — особенно для больших и сложных фич типа non-lexical lifetimes — и потому эти атрибуты требовалось периодически обновлять. Так как это не очень интересная работа, а упустить эти атрибуты при работе очень легко, часто в master эти указания на стабильную версию попадали неверными, из-за чего их приходилось править задним числом после мерджа (например).
Для того, чтобы избежать подобных происшествий, в конце августа 2022 года est31 добавил поддержку заменителя версии. Именно, все новые стабильные фичи должны теперь вместо конкретной версии использовать строку
Однако определение этого шаблона нужно иметь и в сорцах компилятора — для того, чтобы корректно распознавать определения с указанием этой строки в качестве стабильной версии и давать связанные с версиями диагностики. По понятным причинам это определение используется в коде компилятора, ответственного за парсинг атрибутов. Чтобы избежать перезаписывания определения шаблона, в replace-version-placeholder был захардкожен путь до файла, отвечающего за эту часть компилятора. Однако структура компилятора не является отлитой в граните, и периодически файлы перемещают или переименовывают. Периодически меняется путь и до файла, содержащего определение шаблона, из-за чего инструмент для замены версий начинает заменять то, что не надо, и его надо править, чтобы поменять путь, который исключается из обработки.
Чтобы исключить подобную чехарду, Pietro Albini придумал гениальный ход с заменой определения шаблона в коде. Вот как определение
А вот как оно же выглядит после:
Несмотря на то, что определение де-факто осталось тем же, исходники теперь не содержат строку
Но всё равно смешно.
TL;DR: тык.
Среди многих хороших вещей, которые есть в Rust — указание версии, начиная с которой определение стабильно. Главным образом это относится к API в стандартной библиотеке, но эта информация также хранится и для фич компилятора — это позволяет компилятору указывать на то, что
#![feature(...)]
уже стабилизирована и потому не требует аннотаций в коде.Долгое время эта версия указывалась вручную. Это обычно не так сложно — новое определение попадает в stable-версию, которая на три версии старше текущей. Однако PR в Rust имеют свойство затягиваться — особенно для больших и сложных фич типа non-lexical lifetimes — и потому эти атрибуты требовалось периодически обновлять. Так как это не очень интересная работа, а упустить эти атрибуты при работе очень легко, часто в master эти указания на стабильную версию попадали неверными, из-за чего их приходилось править задним числом после мерджа (например).
Для того, чтобы избежать подобных происшествий, в конце августа 2022 года est31 добавил поддержку заменителя версии. Именно, все новые стабильные фичи должны теперь вместо конкретной версии использовать строку
"CURRENT_RUSTC_VERSION"
, и tidy (линтер компилятора) в CI проверяет, что это действительно так. Для того, чтобы менять версию на актуальную, этот же PR добавил для этого автоматический инструмент — replace-version-placeholder — который запускается каждый раз, когда отпочковывается новая бета-версия. Это очень тупой инструмент, который использует простую текстовую замену (буквально str::replace)Однако определение этого шаблона нужно иметь и в сорцах компилятора — для того, чтобы корректно распознавать определения с указанием этой строки в качестве стабильной версии и давать связанные с версиями диагностики. По понятным причинам это определение используется в коде компилятора, ответственного за парсинг атрибутов. Чтобы избежать перезаписывания определения шаблона, в replace-version-placeholder был захардкожен путь до файла, отвечающего за эту часть компилятора. Однако структура компилятора не является отлитой в граните, и периодически файлы перемещают или переименовывают. Периодически меняется путь и до файла, содержащего определение шаблона, из-за чего инструмент для замены версий начинает заменять то, что не надо, и его надо править, чтобы поменять путь, который исключается из обработки.
Чтобы исключить подобную чехарду, Pietro Albini придумал гениальный ход с заменой определения шаблона в коде. Вот как определение
VERSION_PLACEHOLDER
выглядело до его PR:pub const VERSION_PLACEHOLDER: &str = "CURRENT_RUSTC_VERSION";
А вот как оно же выглядит после:
pub const VERSION_PLACEHOLDER: &str = concat!("CURRENT_RUSTC_VERSIO", "N");
Несмотря на то, что определение де-факто осталось тем же, исходники теперь не содержат строку
CURRENT_RUSTC_VERSION
, а потому replace-version-placeholder файл не меняет. Это изменение позволило не только свободно перемещать исходники, но и убрать фильтрацию по имени файла из инструмента. Естественно, Pietro написал в комментариях, зачем это надо.Но всё равно смешно.
GitHub
Avoid replacing the definition of `CURRENT_RUSTC_VERSION` by pietroalbini · Pull Request #135173 · rust-lang/rust
Before this PR, replace-version-placeholder hardcoded the path defining CURRENT_RUSTC_VERSION (to avoid replacing it). After a refactor moved the file defining it without changing the hardcoded pat...
Блог*
#prog #rust хайлайты. TL;DR: тык. Среди многих хороших вещей, которые есть в Rust — указание версии, начиная с которой определение стабильно. Главным образом это относится к API в стандартной библиотеке, но эта информация также хранится и для фич компилятора…
Please open Telegram to view this post
VIEW IN TELEGRAM
#prog #amazingopensource
Josh — Just One Single History
README:
Combine the advantages of a monorepo with those of multirepo setups by leveraging a fast, incremental, and reversible implementation of git history filtering.
Из руководства пользователя:
The idea behind josh started with two questions:
1. What if history filtering could be so fast that it can be part of a normal, everyday workflow, running on every single push and fetch without the user even noticing?
2. What if history filtering was a non-destructive, reversible operation?
Что позволяет сделать этот инструмент? Например, склонировать отдельную директорию из репозитория, как отдельный репозиторий, который содержит только коммиты, связанные с этой директорией и её содержимым (первый пример в README). Причём директория может быть произвольной, а не из какого-то заданного заранее списка. josh даже позволяет сделать репозиторий из директории, которая в репозитории пока отсутствует!
Подобный склонированный под-репозиторий ведёт себя так же, как обычный git-репозиторий, и поддерживает тот же набор операций. В частности, новые коммиты будут видны в его истории, но при этом будут прозрачно интегрированы в историю исходного репозитория.
Josh также поддерживает более продвинутую функциональность для переобозначения директорий, когда, например, каждый подпроект содержится в отдельной директории, но при этом требует файлы из некой общей директории (второй пример в README).
Бонусом josh также даёт возможность делать запросы по содержимому репозитория через GraphQL API без необходимости клонирования репозитория целиком. Даже если вы не собираетесь использовать трюки с переписыванием истории, одно это уже может быть полезно.
Узнал про этот инструмент из этого PR в репу Rust, который преобразовал rustc-dev-guide из сабмодуля в директорию в составе основной репы с использованием josh.
Josh — Just One Single History
README:
Combine the advantages of a monorepo with those of multirepo setups by leveraging a fast, incremental, and reversible implementation of git history filtering.
Из руководства пользователя:
The idea behind josh started with two questions:
1. What if history filtering could be so fast that it can be part of a normal, everyday workflow, running on every single push and fetch without the user even noticing?
2. What if history filtering was a non-destructive, reversible operation?
Что позволяет сделать этот инструмент? Например, склонировать отдельную директорию из репозитория, как отдельный репозиторий, который содержит только коммиты, связанные с этой директорией и её содержимым (первый пример в README). Причём директория может быть произвольной, а не из какого-то заданного заранее списка. josh даже позволяет сделать репозиторий из директории, которая в репозитории пока отсутствует!
Подобный склонированный под-репозиторий ведёт себя так же, как обычный git-репозиторий, и поддерживает тот же набор операций. В частности, новые коммиты будут видны в его истории, но при этом будут прозрачно интегрированы в историю исходного репозитория.
Josh также поддерживает более продвинутую функциональность для переобозначения директорий, когда, например, каждый подпроект содержится в отдельной директории, но при этом требует файлы из некой общей директории (второй пример в README).
Бонусом josh также даёт возможность делать запросы по содержимому репозитория через GraphQL API без необходимости клонирования репозитория целиком. Даже если вы не собираетесь использовать трюки с переписыванием истории, одно это уже может быть полезно.
Узнал про этот инструмент из этого PR в репу Rust, который преобразовал rustc-dev-guide из сабмодуля в директорию в составе основной репы с использованием josh.
GitHub
GitHub - josh-project/josh: Just One Single History
Just One Single History. Contribute to josh-project/josh development by creating an account on GitHub.
Блог*
#prog #amazingopensource Josh — Just One Single History README: Combine the advantages of a monorepo with those of multirepo setups by leveraging a fast, incremental, and reversible implementation of git history filtering. Из руководства пользователя:…
Обсуждение в Rust Zulip по поводу переноса rustc-dev-guide
Forwarded from Хреногубка
Практически в каждой мужской руке, которую ты жал, когда-то был член. Спустя время Хреногубка вернется к вам с новыми фактами.
#prog #rust #rustasync
Async Rust is about concurrency, not (just) performance
(Alternative title: In defense of async (Rust))
TLDR: I think that the primary benefit of async/await is that it lets us concisely express complex concurrency; any (potential) performance improvements are just a second-order effect. We should thus judge async primarily based on how it simplifies our code, not how (or if) it makes the code faster.
Async Rust is about concurrency, not (just) performance
(Alternative title: In defense of async (Rust))
TLDR: I think that the primary benefit of async/await is that it lets us concisely express complex concurrency; any (potential) performance improvements are just a second-order effect. We should thus judge async primarily based on how it simplifies our code, not how (or if) it makes the code faster.
Kobzol’s blog
Async Rust is about concurrency, not (just) performance
TLDR: I think that the primary benefit of async/await is that it lets us concisely express complex concurrency; any (potential) performance improvements are just a second-order effect. We should thus judge async primarily based on how it simplifies our code…
Forwarded from Сова пишет…
Вот в ЭКОСИСТЕМЕ APPLE есть такое приложение как iPhone Mirroring
Его суть в том, чтобы я мог лежа на диване с ноутбуком потыкать в нужные мне приложения на айфоне не вставая, особенно полезно, если айфон на зарядке в другой комнате.
Что интересно, эта фича работала несколько недель сразу после релиза, а потом перестала.
Месяцем позже Apple выкатили апдейт для всех устройств и вроде заработало.
Сейчас я решил снова воспользоваться этой фичей: мне пришло уведомление с айфона, тыкнул, открылось iPhone Mirroring.
Но! Apple предлагает мне встать, найти айфон и разблокировать его, чтобы использовать эту фичу!
Но тогда нафига мне эта фича? Как так?
Его суть в том, чтобы я мог лежа на диване с ноутбуком потыкать в нужные мне приложения на айфоне не вставая, особенно полезно, если айфон на зарядке в другой комнате.
Что интересно, эта фича работала несколько недель сразу после релиза, а потом перестала.
Месяцем позже Apple выкатили апдейт для всех устройств и вроде заработало.
Сейчас я решил снова воспользоваться этой фичей: мне пришло уведомление с айфона, тыкнул, открылось iPhone Mirroring.
Но! Apple предлагает мне встать, найти айфон и разблокировать его, чтобы использовать эту фичу!
Но тогда нафига мне эта фича? Как так?
Блог*
Вот в ЭКОСИСТЕМЕ APPLE есть такое приложение как iPhone Mirroring Его суть в том, чтобы я мог лежа на диване с ноутбуком потыкать в нужные мне приложения на айфоне не вставая, особенно полезно, если айфон на зарядке в другой комнате. Что интересно, эта фича…
Фейл примерно на уровне десктопного WhatsApp. Для контекста: десктопное приложение WhatsApp есть, но для того, чтобы им пользоваться, нужно иметь под рукой рабочий и подключённый к интернету телефон с установленным и залогиненым WhatsApp
Forwarded from Технологический Болт Генона
This media is not supported in your browser
VIEW IN TELEGRAM
Doom в Word'е
GitHub
https://github.com/wojciech-graj/doom-docm
ЗЫ У меня LibreOffice не заработало. Было ожидаемо 🌝
How it works
The Word document contains the library doomgeneric_docm.dll and doom1.wad game data encoded in base 64, which a VBA macro extracts onto the disk and then loads. Every game tick, doomgeneric.dll creates a bmp image containing the current frame and uses GetAsyncKeyState to read the keyboard state. The main VBA macro's game loop runs a tick in doom, then replaces the image in the document with the latest frame.
GitHub
https://github.com/wojciech-graj/doom-docm
ЗЫ У меня LibreOffice не заработало. Было ожидаемо 🌝