#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-рамма на свете — uwuify (#amazingopensource?)

Hey, I think I really love you. Do you want a headpat?

⬇️

hey, (ꈍᴗꈍ) i think i weawwy wuv you. ^•ﻌ•^ do y-you want a headpat?

Пропускная способность считается в гигабайтах в секунду — отличное производительное решение, готовое для прода.

#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 анонимны, и это взрывает мозг тем, кто учился VCS на 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

libriscv is a simple, slim and complete sandbox that is highly embeddable and configurable. It is a specialty emulator that specializes in low-latency, low-footprint emulation. libriscv may be the only one of its kind. Where other solutions routinely require ~50-150ns to call a VM function and return, libriscv requires 3ns. libriscv is also routinely faster than other interpreters, JIT-compilers and binary translators. libriscv has specialized APIs that make passing data in and out of the sandbox safe and low-latency.

(thanks @itpgchannel)

#prog #amazingopensource

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

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

#prog #python #amazingopensource

#prog #article #amazingopensource

zizmor — статический анализатор для Github Actions, рождённый из-за фрустрации автора, вызванной тем, насколько легко использовать Github Actions небезопасно. Инструмент намеренно нацелен на то, чтобы иметь высокий signal to noise ratio по умолчанию.

В статье Introducing zizmor: now you can have beautiful clean workflows автор рассказывает о том, что это за инструмент и мотивации для его создания, а также некоторые детали реализации (написан на Rust, BTW).

В более технической статье Fun with finite state transducers автор рассказывает о том, как снизил на порядок количество данных, включаемых в инструмент. Эти данные используются для идентификации того, в каких контекстах YAML-файлов, настраивающих Github Actions, включение внешних данных небезопасно.

Если вы сомневаетесь, насколько этот инструмент нужен, то в статье zizmor would have caught the Ultralytics workflow vulnerability автор рассказывает, как zizmor мог бы предотвратить инцидент, который привёл к публикации как минимум двух вредоносных версий Python-библиотеки для машинного обучения и, предположительно, к компроментации репозитория целиком.

#prog #amazingopensource #article (и даже в какой-то мере #algo)

Stacktower.io (репозиторий) — инструмент для создания визуализаций зависимостей в духе известного комикса xkcd + история о его создании, с инкрементальным улучшением, начиная с брутфорса. История хорошо демонстрирует, насколько хорошо помогает знать prior art в computer science.