#prog #python #amazingopensource

Ruff

An extremely fast Python linter, written in Rust.

⚡️ 10-100x faster than existing linters
🐍 Installable via pip
🛠 pyproject.toml support
🤝 Python 3.11 compatibility
📦 Built-in caching, to avoid re-analyzing unchanged files
🔧 Autofix support, for automatic error correction (e.g., automatically remove unused imports)
📏 Over 500 built-in rules
⚖️ Near-parity with the built-in Flake8 rule set
🔌 Native re-implementations of dozens of Flake8 plugins, like flake8-bugbear
⌨️ First-party editor integrations for VS Code and more
🌎 Monorepo-friendly, with hierarchical and cascading configuration

<...>

> Ruff is so fast that sometimes I add an intentional bug in the code just to confirm it's actually running and checking the code.

#prog #rust #typescript #amazingopensource

Typical — IDL, который предоставляет одновременно:

* типобезопасность
* бинарную совместимость между схемами разных версий
* СУММ-ТИПЫ
* обязательные поля в схеме (я смотрю на тебя, Protobuf)
* возможность постепенно мигрировать поля из статуса опциональных в статус обязательных и наоборот

В Readme подробнее рассказывается, как достигается последний пункт за счёт новой концепции ассиметричных полей. Из недостатков можно отметить разве что небольшое число бекендов: пока что Typical умеет генерировать код только для Rust и Typescript.

(thanks @ployd)

#prog #amazingopensource

ast-grep — инструмент для структурного поиска и замены с паттернами не на уровне текста, а на уровне синтаксических деревьев.

Построен поверх tree-sitter, поэтому охват языков, корректность и произодительность на уровне.

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

Поддерживает предзаписанные правила (в YAML 😒), с возможностью вынесения в отдельные файлы общих определений.

Может быть использован как линтер, для поиска паттернов, но без замены.

#prog #amazingopensource

wuffs (Wrangling Untrusted File Formats Safely) — язык (и компилятор) для написания программ обработки данных, который компилируется в C. Язык намеренно весьма ограниченный — в частности, в нём отсутствует IO и способы динамически управлять памятью, да и в принципе доступ к сисколам. Язык также memory safe: компилятор отказывается компилировать программу, в которой индексы выходят за границу массива (а также если в ней где-то есть переполнение).

Несмотря на ограниченность языка и намеренно простые проверки диапазонов переменных, на практике он с успехом подходит для написания (де)кодировщиков медиаформатов — реализации на wuffs по производительности обгоняют существующие реализации на C и Rust.

(thanks @experimentalchill за привлечение внимания к этой вещи — взято из поста про ошибки реализации в CRC32 в Linux)

#prog #rust #amazingopensource

git-absorb

You have a feature branch with a few commits. Your teammate reviewed the branch and pointed out a few bugs. You have fixes for the bugs, but you don't want to shove them all into an opaque commit that says fixes, because you believe in atomic commits. Instead of manually finding commit SHAs for git commit --fixup, or running a manual interactive rebase, do this:

git add $FILES_YOU_FIXED
git absorb --and-rebase

git absorb will automatically identify which commits are safe to modify, and which staged changes belong to each of those commits. It will then write fixup! commits for each of those changes.

With the --and-rebase flag, these fixup commits will be automatically integrated into the corresponding ones. Alternatively, you can check its output manually if you don't trust it, and then fold the fixups into your feature branch with git's built-in autosquash functionality:

git add $FILES_YOU_FIXED
git absorb
git log # check the auto-generated fixup commits
git rebase -i --autosquash master

Является портом аналогичной вещи для Mercurial: hg-absorb

#prog #rust #article #amazingopensource

Automating Cargo project configuration using cargo-wizard

TL;DR: I created a Cargo subcommand called cargo-wizard that simplifies the configuration of Cargo projects for maximum runtime performance, fastest compilation time or minimal binary size.

Не смотря на то, что способы настройки проектов на cargo для перечисленных целей известны, на практике их применение затруднено:

1) О них надо знать. Документация cargo хоть и вполне хорошая, но очень уж обширная, и там есть не вся информация для достижения этих целей.
2) Их надо применить. Не то чтобы это само по себе было сложно, но для этого нужно прописывать конфигурацию в разных секциях Cargo.toml, а значимый эффект они зачастую дают в комплексе.

Kobzol создал инструмент для того, чтобы по возможности решить обе проблемы. Использование одного инструменты позволяет перечислить все нужные настройки в одном месте, а также применить их к целому workspace одним махом. При этом у cargo wizard есть и более вдумчивый режим, который позволяет предварительно посмотреть все вносимые изменения и настроить индивидуально каждое из них.

#prog #amazingopensource

fq — jq for binary files

github.com/wader/fq

(thanks @oficsu)

#prog и, пожалуй, #amazingopensource

#prog #amazingopensource

grpcurl is a command-line tool that lets you interact with gRPC servers. It's basically curl for gRPC servers.

The main purpose for this tool is to invoke RPC methods on a gRPC server from the command-line. gRPC servers use a binary encoding on the wire (protocol buffers, or "protobufs" for short). So they are basically impossible to interact with using regular curl (and older versions of curl that do not support HTTP/2 are of course non-starters). This program accepts messages using JSON encoding, which is much more friendly for both humans and scripts.

Из недостатков можно отметить, что из пакетных менеджеров есть пока только в homebrew и aur.

#prog #rust #amazingopensource

Rustlings Rewrite

Этот же человек взял на себя сопровождение rustlings и выпустил новую версию. Помимо всего прочего, rustlings теперь можно установить при помощи cargo install! И ещё можно добавлять свои упражнения, а у имеющихся упражнений после решения показывается идиоматичный вариант.

#prog #amazingopensource

Sectorforth — a 16-bit x86 Forth that fits in a 512-byte boot sector.

#prog #amazingopensource

Automatically inferring file syntax with afl-analyze

Инструмент для фаззинга AFL использует покрытие потока исполнения для того, чтобы генерировать новые кандидаты тестовых данных. Это позволяет эффективно фаззить софт. Однако оснастка для анализа покрытия может быть использована и для других целей.

Один из инструментов, который использует эту оснастку — afl-analyze. Мутируя входные данные и наблюдая за поведением программы, обрабатывающей вход, он может автомагически до некоторой степени разобрать структуру входа на уровне до байтов.

На скриншоте представлен результат запуска этого инструмента на файле PNG и программе для его чтения.

#prog #amazingopensource

ripgrep-all — ripgrep, but also search in PDFs, E-Books, Office documents, zip, tar.gz, etc.

Поддерживает добавление пользовательских адаптеров для поиска внутри файлов других типов.

#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.

#prog #amazingopensource

DWARF Explorer (dwex)

A cross-platform GUI utility for visualizing the DWARF debugging information in executable files, built on top of pyelftools and filebytes. Runs on Windows, MacOS X, and Linux.

Ввиду того, что написано на Python, пользоваться этим может быть не очень удобно, особенно на Windows.

#prog

А ещё, так как форк открытый, это и #amazingopensource

#prog #article #amazingopensource

Jujutsu (jj) — система контроля версий, которая концептуально проще git и при этом мощнее.

Неплохой (но местами устаревший) обзор Jujutsu — jj init — сделал Chris Krycho. Также есть пока что неполный туториал от Стива Клабника, который тот написал главным образом для того, чтобы самому лучше разобраться с Jujutsu. Этот туториал даже рекомендуется в официальной документации.

Сразу скажу: jj работает поверх git, так что её можно поставить поверх имеющегося репозитория и потом без проблем удалить. (у jujutsu также есть нативный бекенд, но он пока не готов и не рекомендуется к использованию)

Что же такого примечательного в этой VCS? Попробую объяснить (но лучше почитайте по ссылкам, чесслово, там хорошо описано). В обоих описаниях бросается в глаза наличие операций, описанных в Where are my Git UI features from the future?.

Как и git, jj идейно работает на снапшотах файловой системы. В отличие от git, коммиты в jj напоминают объекты в ООП: они мутабельны и имеют идентичность, которая остаётся постоянной при изменениях самих коммитов — да, в том числе при ребейзах.

В отличие от git, в jj нет отдельной стадии стейджинга изменений и фиксации коммита. Более того, jj вообще не использует индекс — jj отслеживает изменения файлов и автоматически записывает их в текущий коммит (не волнуйтесь, есть средства для разбиения изменений). Для того, чтобы закончить с текущим коммитом, достаточно вызвать jj new для создания нового коммита, который отпочковывается от текущего. Описание для этого вводить необязательно — его можно добавить задним числом. Недостаток этого решения — большинство инструментов поверх git предполагают использование индекса и потому не очень хорошо стыкуются с jj.

Как я уже сказал, описание коммитов можно добавлять и менять в любой момент, вне зависимости от того, какой коммит текущий.

Ветки в jj анонимны, и это взрывает мозг тем, кто учился CVS на git (мне в том числе). Именованные ветки из git доступны в jj под именем bookmarks, и, в отличие от git, эти указатели не смещаются автоматически при добавлении дочерних коммитов — для этого нужно вызвать отдельную команду. Это выглядит неудобным, но по факту это даёт некоторые преимущества. Одно из них — нет нужды придумывать имя для каждого логического изменения. Оно требуется лишь тогда, как нужно расшарить изменения с другими. Другое — если в локальной копии слишком много изменений и стало понятно, что они идут куда-то не туда, можно просто откатиться до ветки (при условии, что локально её не двигали) и просто дропнуть коммиты после неё.

Коммиты можно свободно двигать в истории. В отличие от git rebase, имена коммитов после этого не меняются.

Ребейз и мердж в jj всегда успешно завершаются. Это не означает, что конфликты невозможны. Но в jj конфликты являются первоклассными значениями. Это позволяет слить несколько последовательностей коммитов в одну и разобраться с конфликтами позднее (и потом, возможно, слить разрешения конфликтов с мердж-коммитами).

Команда jj undo отменяет действие предыдущей команды. Дико не хватает этого в git.

Почти все команды jj позволяют указывать коммиты, на которых они действуют (и используют текущий коммит, если этот аргумент не указан). Более того, это может быть несколько коммитов — или revset в терминологии jj. Задавать revset-ы можно при помощи отдельного достаточно мощного языка выражений. В качестве побочного эффекта это означает, что, помимо всего прочего, в jj можно сделать мердж больше двух веток сразу.

Например, для того, чтобы просмотреть все локальные "ветки" (коммиты без дочерних коммитов), можно использовать jj log -r 'heads(all())'. all() возвращает все коммиты в репе, а heads извлекает из набора коммитов те, у которых нет дочерних. Если этого недостаточно и нужно добавить контекста — скажем, по два родительских коммита — можно использовать jj log -r 'ancestors(heads(all()), 2)'. (это лишь мой пример, по умолчанию jj log использует несколько более полезный формат)

#prog #amazingopensource

miniserve — for when you really just want to serve some files over HTTP right now!

Написано на Rust, один бинарь, может отдавать не только отдельные файлы, но и директории. Ещё пачка фичей, почитайте README.