Size: a a a

2021 March 24
Блог*
#prog #forth #amazingopensource
источник
Блог*
Stoneknife Forth is a minimal forth translator that can compile itself. This compiler is so simple that it recognizes only one-letter identifiers.

This can be bootstrapped in two steps:

First of all Stoneknife is compiled by itself being interpreted by a slow interpreter written in python.

The second step is compiling with the compiler produced by the previous step. The result is a bootstrapped x86 ELF executable.

https://github.com/kragen/stoneknifeforth

#compiler #lowlevel #system #programming
источник
Блог*
#prog #c #amazingopensource
источник
Блог*
I have already written about Rui Ueyama and the family of small C compilers: 8cc and 9cc. I also mentioned chibicc, a project that complements Rui's book.

Last time I didn't notice how the author organized the repository of chibicc. Each commit is a single step from zero to a full-featured C11 compiler (without optimizations and proper allocation of registers).

The first commit in the repository only involves a simple compiler that reads a number and generates a program that can return this number on completion. The last commit includes all the source code of the compiler that can build real projects like Git, SQLite and libpng!

https://github.com/rui314/chibicc

#c #compiler #lowlevel #system #programming
источник
Блог*
#prog #gamedev
источник
Блог*
Зеркала в Duke Nukem 3D — всем известный пример того, как работали отражения в эпоху первых 3D-игр: вместо физической симуляции по ту сторону создавались отзеркаленные комнаты с повторяющими движения спрайтами.

Но выяснилось, что с технической точки зрения всё устроено ещё интереснее — стоило всего лишь включить режим noclip и поисследовать «зазеркалье».
источник
Блог*
источник
2021 March 25
Блог*
Переслано от ilya sheprut
кстати все заметили что депрессия и россия кончаются на одинаковые 4 буквы? совпадение? не думаю.
источник
Блог*
#prog #python

t.me/tipaproit/545
Telegram
Типа про IT
Известный факт, что CPython использует алгоритм djb2 для реализации своей строковой хеш-функции и выглядит он так:

unsigned long
hash(unsigned char *str)
{
   unsigned long hash = 5381;
   int c;
   while (c = *str++)
       hash = ((hash << 5) + hash) + c;
   return hash;
}


А hash уже применяется в реализации dict, set  и вообще везде, где нужна хэшируемость объекта. И, вроде бы, всё с ней хорошо, работает годами, только непонятно нихуя.

Магическое число 5381

— простое число
— недостаточное число
— нечётное число
— имеет бинарное представление 001/010/100/000/101
— в сравнении с другими имеет хороший лавинный эффект

Я не настоящий сварщик, поэтому будем считать, что такой ответ нас устраивает. Daniel J. Bernstein, автор сия алгоритма, отвечает на пацана, что всё посчитал и ему это число зашло больше остальных. Но вместо 5381 может быть и любое другое.

hash = ((hash << 5) + hash) + c

Что тут вообще происходит?! А это не более, чем hash * 33 + c. Так наши деды экономили процессорное время и умножали…
источник
Блог*
dereference_pointer_there
#prog #python

t.me/tipaproit/545
Telegram
Типа про IT
Известный факт, что CPython использует алгоритм djb2 для реализации своей строковой хеш-функции и выглядит он так:

unsigned long
hash(unsigned char *str)
{
   unsigned long hash = 5381;
   int c;
   while (c = *str++)
       hash = ((hash << 5) + hash) + c;
   return hash;
}


А hash уже применяется в реализации dict, set  и вообще везде, где нужна хэшируемость объекта. И, вроде бы, всё с ней хорошо, работает годами, только непонятно нихуя.

Магическое число 5381

— простое число
— недостаточное число
— нечётное число
— имеет бинарное представление 001/010/100/000/101
— в сравнении с другими имеет хороший лавинный эффект

Я не настоящий сварщик, поэтому будем считать, что такой ответ нас устраивает. Daniel J. Bernstein, автор сия алгоритма, отвечает на пацана, что всё посчитал и ему это число зашло больше остальных. Но вместо 5381 может быть и любое другое.

hash = ((hash << 5) + hash) + c

Что тут вообще происходит?! А это не более, чем hash * 33 + c. Так наши деды экономили процессорное время и умножали…
В Rust по умолчанию для HashMapHashSet) используется алгоритм SipHash (реализация в core). Интерфейс Hasher помимо метода write для хеширования также предоставляет методы типа write_u32 и write_i8, однако в текущем виде эти методы используют реализацию по умолчанию. Реализация этих методов напрямую может ускорить хэширование — и это изменение предлагалось, но, к сожалению, его пришлось отбросить, поскольку оно негативно сказывалось на времени компиляции некоторых бенчмарков :(
источник
Блог*
25 марта в Steam выходит головоломка Dorfromantik от берлинской инди-студии Toukana Interactive. Геймплей простой и медитативный — нужно собирать уютный городок, правильно выбирая места для построек.

Отлично подойдёт для тех, кто давно мечтал о Каркассоне без противников.
источник
Блог*
#prog #haskell

Статья ценна ещё и тем, что показывает, как все эти type-level навороты полезны на практике и что их использование стоит потраченных на их усвоение усилий.

А closed type families и GADT в Rust ну очень временами не хватает 😣
источник
Блог*
Алексис Кинг написала большую и очень классную статью про тайплевел-программирование на хаскеле:

https://lexi-lambda.github.io/blog/2021/03/25/an-introduction-to-typeclass-metaprogramming/
источник
Блог*
#prog #rust

Вышла версия Rust 1.51! Как обычно, я не буду перечислять всё, а отмечу только то, что интересно лично мне.

Невозможно не отметить самую важную фичу релиза: const generics 🎉! К сожалению, это всё ещё не полная версия, а стабилизация min_const_generics, то есть версия с серьёзными ограничениями, о которых можно подробнее почитать отдельно. Одни из них вполне понятны — это ограничения на использование выражений с использованием таких параметров — что вполне логично, поскольку в общем случае их унификация является достаточно сложной задачей, а вот ограничения на типы самих константых обобщённых параметров куда более обидны: использовать пока что можно лишь примитивные числовые типы, char и bool. С другой стороны, одной из главных причин стабилизации const generics была необходимость в возможности писать код, полиморфный по массивам произвольной размерности (что ранее решалось лишь частично при помощи копипаста, разбавленного макросами), и эту задачу нынешний вариант const generics решает.

Кстати, о массивах: этот релиз добавляет std::array::IntoIter, итератор для массивов, возвращающий элементы по значению. До этого релиза для того, чтобы вернуть итератор, возвращающий ряд некоторых значений, было несколько опций, каждая из которых малость попахивала: вызывать .into_iter() на векторе (и делать аллокацию там, где она не нужна), вызывать .iter().cloned()/.iter().copied() на литерале массива (что делает лишнее копирование, которое в некоторых случаях невозможно вовсе) или же .chain(...)-ить once-ы (что выглядит громоздко и, более того, достаточно медленно работает). Теперь же есть нормальные рабочий вариант. Почему же не добавили impl Intoiterator for [T; N], спросите вы? К сожалению, есть странные люди, которые вызывают .into_iter() на литералах массива, который ввиду авто-борровинга вызывает <&[T]>::into_iter, что, в принципе, аналогично вызову .iter(). Добавление реализации IntoIterator для массивов технически сломало бы этот код. Не исключено, что в будущем на этот шаг всё-таки пойдут, и array::IntoIter::new останется на свалке истории.

Cargo сделали чуток умнее: теперь резолвер фичей, если отдельно включить новую версию, не слепляет бездумно все фичи для каждой из зависимостей в одну (возрадуйся, @ihatereality!). В блогпосте есть примеры того, как старое поведение на практике ломало код. Это изменение позволило закрыть разом семь issue!

В Rust до этого релиза не было возможности получить по указателю на структуру указатель на её поле, не создавая промежуточную ссылку на поле. Одна из причин, почему это так сильно мешалось на практике — это отсутствие в Rust аналога offsetof из C. Существующий для этого крейт страдал от того факта, что для получений этого смещения брал ссылку на неинициализированные данные, что технически является неопределённым поведением. С добавлением макросов ptr::addr_of/ptr::addr_of_mut, которые позволяют брать адрес в виде сырого указателя без создания промежуточной ссылки, эта проблема уходит.

Одна из достаточно обоснованных претензий к Rust состоит в том, что из-за deref coercion часто неочевидно, какими методами обладает тип. Начиная с этого релиза, cargo doc добавляет в документацию методы, полученные при помощи deref coercion произвольной глубины применения. До этого изменения, если у нас были типы A, B и C с реализациями impl Deref<Target = B> for A и impl Deref<Target = C> for B, то документация к A показывала методы A и B, но не C. Теперь же будут видны и методы C.
источник
Блог*
Ну и из мелочей:
* теперь можно запустить вообще все тесты, используя cargo test -- --include-ignored. До этого можно было запустить либо основные тесты, либо игнорируемые, но не оба набора сразу.
* intra-doc-ссылки теперь могут ссылаться на примитивы, ассоциированные элементы (методы, типы, константы) и обобщённые параметры.
* добавлены методы std::iter::Peekable::{next_if, next_if_eq}, которые возвращают следующий элемент только в том случае, если он удовлетворяет предикату/равен переданному значению. Невероятно полезная вещь при написании парсеров.
* добавлен метод str::split_inclusive, который разбивает строку на подстроки по разделителю, включая сам разделитель в подстроки (возрадуйся, @rustamann!). Аналогичные методы добавлены для слайсов (split_inclusive/split_inclusive_mut)
источник
2021 March 26
Блог*
Извините, сейчас будет сложный прикол по #haskell
источник
Блог*
Переслано от Yuuri
[a, b, c, d, e, f ..] ⇔ map read $ unsafePerformIO $ httpRequest $ “http://oeis.org/search?q=“ ++ (intercalate “,” $ map show [a, b, c, d, e, f])
источник
2021 March 27
Блог*
#meme
источник
Блог*
источник
2021 March 28
Блог*
#prog #rust #article

Новая статья Амоса о пристальном взгляде на async в Rust. Чисто с точки зрения человека, который впервые с этим столкнулся, без сильного погружения в тонкости реализации async

(thanks @tapok_satan)
источник