Как насчет чего-то действительно полезного? whalemod

$ git clone https://github.com/xbt573/whalemod
$ cd whalemod
$ make
# insmod ./whale.ko
$ cat /dev/whale

        .
       ":"
     ___:____     |"\/"|
   ,'        `.    \  /
   |  O        \___/  |
 ~^~^~^~^~^~^~^~^~^~^~^~^~

#prog #shit

#prog #rust #meme

От прекрасной подписчицы

Хочешь лёгких денег?

Поменяй монеты на купюры

Ruby vs Python, the Definitive FAQ

Наконец-то, по настоящему полезная статья

#math

Complexity zoo — онлайн-энциклопедия классов сложности.

Если бы наша жизнь была телесериалом, то последний сезон был бы таким странным, что даже создатели 'Твин Пикс' сказали бы: 'Это уже чересчур'.

#prog #go #article

What’s New in Go 1.22: slices.Concat

<...>

Early versions of the Concat proposal included a destination slice argument, like append. (Concat(dest []T, ss ...[]T) []T.) Why doesn’t the final version of slices.Concat have a destination argument to allow users to reuse an existing slice as backing?

The issue goes back to what is called the problem of aliasing. <...> But what if you are concatenating the parts of a slice onto itself? Take this example:

s := []int{1, 2, 3, 4}
_ = slices.ConcatWithDestination(s[:0], s[3:4], s[2:3], s[1:2], s[0:1])
// What is s now?

A naïve implementation of slices.ConcatWithDestination would clobber the 1 at the start of the slice with 4 before copying it onto the end of the slice, so that you end up with 4, 3, 3, 4 instead of 4, 3, 2, 1 as intended.

<...>

In the end, it was decided that just always returning a new slice would keep the implementation of slices.Concat simpler and help prevent any issues with accidentally aliasing a slice and getting unexpected results, so the destination slice argument was dropped.

(thanks @golang_for_two)

Ubuntu is based

(on Debian)

#prog #shell #article

The Five Meanings of #. And What Does ${####} Mean?

На тот случай, если вы считаете синтаксис bash простым.

#gamedev #pixelart #video

Пиксель-арт, как и любая двухмерная графика — это не риггинг, в случае изменения внешности персонажа анимацию нужно делать с нуля.

Или нет? В этом видео автор показывает, как можно сделать для пиксель-арта аналог натягивания материалов на трёхмерные модели.

TL;DR: пиксели в анимации вместо того, чтобы описывать непосредственно цвет пикселя при рендеринге, описывают UV-координаты на текстуре, откуда берутся итоговые цвета.

youtu.be/HsOKwUwL1bE

P. S.: можете посмотреть его shorts, человек очень хорош в анимации персонажей в пиксель-арте.

#prog #rust #shell #article

Nushell turns 4 years old!

Вместо обзора развития — истории того, как пользователи используют nu для своих задач.

(а было это в августе. Я тормоз, да)

#prog #shell #article

The Bourne shell is not a programming language

Before you rise in righteous indignation, let me say that that doesn't mean that you can't write programs in the Bourne shell; you can write programs in anything that's Turing-complete if you try hard enough. It's just that you shouldn't.

<...>

Unfortunately I don't think there's a really good Unix programming language to replace the Bourne shell, which is one of the reasons that writing programs in the Bourne shell remains so tempting.

#prog #python #article

ABI compatibility in Python: How hard could it be?

Нативные расширения для Python могут распространяться в двух формах: в исходниках и в пресобранных бинарях.

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

Для второго варианта — распространения в заранее собранных бинарях — есть стандартный формат, wheel. Недостатком этого подхода является то, что под каждую комбинацию OS, версии CPython и архитектуры нужно делать свой бинарь, что выливается в дополнительную нагрузку для разработчиков для тестирования под каждую из комбинаций. Вдобавок, если поддерживаемой версии wheel под тройку требований нет, пользователь в пролёте — ему остаётся только собирать самостоятельно. В частности, при релизе новой минорной версии CPython пользователям надо ждать, пока разработчики не соберут wheel под эту новую версию.

Для того, чтобы облегчить жизнь и пользователям, и разработчикам, разработчики CPython предоставили ручки, позволяющие выставлять разработчикам нативных расширений стабильное API со стабильным ABI. С технической точки зрения это выражается в установке макроса Py_LIMITED_API в значение конкретной версии API перед включением заголовочных файлов, предоставляющих интерфейс к CPython. Это стабильное ABI называется abi3, и пакет с нативным расширением может иметь тег, говорящий, что код собран относительно этого ABI конкретной версии.

У этого подхода, однако, есть гигантский недостаток: никакой инструмент цепочки упаковки пакета, его распространения и использования — включая сам CPython — не проверяет, что тег abi3 и конкретная версия выставлены корректно. Иными словами, ничто не останавливает пользователей от того, чтобы подгрузить к интерпретатору расширение с некорректным ABI. Последствия этого также плачевны, как и при любом несовпадении ABI, и могут варьироваться от (при удаче) отсутствия каких-либо проблем до крашей или, что гораздо хуже, порчи памяти.

В Trail of bits разработали инструмент, который как раз и проверяет, насколько расширение, заявленное, как поддерживающее abi3, действительно является таковым. Для исследования того, насколько этот инструмент полезен, авторы статьи проверили пакеты, скаченные с PyPI за последние 21 день (на момент написания статьи, т. е. 15 ноября 2022 года). По части результатов процитирую статью дословно:

Of the 357 valid packages, 54 (15 percent) contained wheels with ABI version violations. In other words: roughly one in six packages had wheels that claimed support for a particular Python version, but actually used the ABI of a newer Python version.

More severely: of those same 357 valid packages, 11 (3.1 percent) contained outright ABI violations. In other words: roughly one in thirty packages had wheels that claimed to be stable ABI compatible, but weren’t at all!

In total, 1139 (roughly 3 percent) Python extensions had version violations, and 90 (roughly 0.02 percent) had outright ABI violations. This suggests two things: that the same packages tend to have ABI violations across multiple wheels and extensions, and that multiple extensions within the same wheel tend to have ABI violations at the same time (which makes sense, since they should share the same build).

Советую прочитать статью, которая несколько более подробно рассказывает о проблеме, которую представленный инструмент может диагностировать, а также рассказывает о конкретных некорректных пакетах.

В статье мимолётом упоминается, что им не удалось найти кошкодевочек, в отличие от moyix.

#prog (somewhat #python) #menacingopensource #article

Someone’s Been Messing With My Subnormals!

TL;DR: After noticing an annoying warning, I went on an absurd yak shave, and discovered that because of a tiny handful of Python packages built with an appealing-sounding but dangerous compiler option, more than 2,500 Python packages—some with more than a million downloads per month—could end up causing any program that uses them to compute incorrect numerical results.

Или чуть более подробно: в силу каких-то сомнительных решений в GCC (равно как и в clang, который старательно скопировал его поведение) активация флага -Ofast подразумевает активацию флага -ffast-math, который, в свою очередь, при компиляции разделяемой библиотеки генерировал для неё конструктор, который, помимо всего прочего, выставлял в процессоре флаг, регулирующий поведение операций над плавающей точкой — более конкретно, FTZ/DAZ, при активации которого операции, которые выдали бы субнормальные числа с плавающей точкой, вместо этого выдают ноль. Несколько нативных расширений были скомпилированы с флагом -Ofast, которые в результате стали расширениями, банальный импорт которых менял поведение арифметики чисел с плавающей точкой для всего процесса, включая код из NumPy.

#prog #cpp

libawful — a collection of awful archetypes for testing generic code.

When writing a generic library, one often needs to test generic components with types having infrequent characteristics. This is to make sure that a generic component is not assuming more about its inputs than it should. libawful is a collection of types with unusual properties that can be used to check for corner cases when implementing generic components. The project contains a single header, <awful.hpp>, which defines all the archetypes.

В СМЫСЛЕ УЖЕ ФЕВРАЛЬ