Подписчики, чат канала подвёргся внезапному наплыву новых пользователей. Обычно это означает массированную спам-атаку. Во избежание неудобств я временно закрыл публичный доступ к Чат*у.

Также я скопом удалил всех новых участников чата. Если вдруг я удалил кого-то из реальных людей, не ботов — пишите в личку (ссылка в описании канала), разберёмся в частном порядке

UPD: волна вроде кончилась, Чат* снова открыт

Ей-богу, когда-нибудь я удалю канал, просто случайно нажав не туда

#gamedev #video

Alexis Kennedy out of context

Source

Ужас какой.

Как будто там есть, за чем следить.

Если медленно скроллить можно увидеть мультик 🫨
https://github.com/barak/opencv/blob/master/modules/features2d/src/fast.cpp

Опять

#meme про экзамены

Так, блэт, почему уже три (если я не сбился со счёта) человека изъявили желание, чтобы я был их daddy? 🤔

#prog

Опыт работы с VSCode Live share

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

итак, сам список:
• дерганная работа — в direct-режиме и даже если пинг между участниками низкий задержка при использовании live share может составлять несколько секунд. почему? черный ящик имени майкрософта.
десинк порой настолько сильный что у хоста вместо написанного мной кода — каша.

• невозможность поднять свой релей — issue закрыт как "not planned"

• кривая работа с кодом — тайпинги прогружаются через раз, Quick Fix работает, упаси дьявол, 1 раз из 10.
а если ты через тот же Quick Fix пытаешься импортировать какой-то файл — удачи, бро, велик шанс, что он не увидит, где можно импорт взять (даже если он в локальном файле а не в стороннем модуле)

• кривая работа с терминалом — он может тупо зависнуть, если происходит какая-то активная фигня (например — сборка докер имеджа). то какое решение?
либо переподключиться, либо попросить хоста (если это не ты) открыть другой термниал. очень удобно 👍

ну и для нотки лирики: за 2 часа парного кодинга мне пришлось переподключаться около 6-7 раз.

#prog #ocaml #article

Oxidizing OCaml (1, 2, 3) — серия из трёх статей, описывающая дополнения в OCaml, позволяющие добавить в язык некоторые из присущих Rust концептов — владение, лайфтаймы и уникальные ссылки — и таким образом привнести довольно конкретные преимущества для написания корректных и более экономно использующих ресурсы программ. Всё это — через систему аннотаций режимов (mode), ортогональных системе типов и друг другу и потому не влияющих на разрешимость вывода типов (для авторов предложенных изменений это важно).

Настоятельно советую прочитать оригинальные статьи, но что-то я перескажу и тут.

Первая статья: Oxidizing OCaml: Locality. В ней рассказывается про режим локальности значений. В отличие от полиморфных ссылок Rust, этот режим поддерживает лишь два возможных варианта: global (вариант по умолчанию) и local.

Времена жизней глобальных (global) значений могут жить независимо от исполнения различных функций. Как следствие, компилятор вынужден все подобные значения класть в кучу и делегировать управление временем их жизни рантаймовому сборщику мусора. На использование локальных (local) значений накладываются ограничение: именно, подобные значения не могут пережить функцию, в которой они находятся. В терминах escape analysis это значения, которые не escape текущую функцию. Так как подобные ограничения излишне строги, язык предоставляет возможность явно выделить local значение во внешнем регионе вместо текущего. Так как escape analysis — это не какая-то новая вещь, определить локальные значения возможно статически во время компиляции.

Введение этого режима даёт два преимущества.

Во-первых, локальные значения можно выделять на стеке — и в случае OCaml это несколько более существенное преимущество, поскольку стековый аллокатор не обязан использовать под стек ту же память, что и стек потока управления. Это позволяет достигнуть более высокой производительности, поскольку использование стекового аллокатора не триггерит использование сборщика мусора, а также естественный LIFO паттерн доступа к стековой памяти приводит к лучшей утилизации кеша процессора. Для сравнения, в текущей реализации OCaml сборщик мусора поколенческий, и для младшего поколения используется кольцевой буфер. Малая сборка мусора относительно дешёвая, но каждый объект, который переживает её, уходит в кучу для старых объектов, обход которой дороже. Вдобавок, использование кольцевого буфера повышает шанс, что аллокация новых значений приведёт в вымыванию из кеша старых значений.

Во-вторых, локальность позволяет строить более корректные API. В качестве примера в статье приводится функция Core_unix.with_file. Эта функция принимает на вход имя файла и коллбек. Семантика достаточно проста: функция открывает файл с указанным именем, отдаёт дескриптор коллбеку, после чего закрывает файл и возвращает результат вызова коллбека. Всё бы ничего, но OCaml — не чистый язык, а потому переданный коллбек может захватить внешнее изменяемое состояние и сохранить файловый дескриптор в нём. Попытка воспользоваться этим дескриптором приведёт в лучшем случае к ошибке, а в худшем — к взаимодействию с некоторым другим файлом, если дескриптор будет переиспользован. Локальность позволяет решить эту проблему. Указав режим аргумента коллбека, как local, мы наложили на коллбек требование, что аргумент не утечёт. Таким образом, мы можем быть уверены, что после завершения коллбека аргумент существует лишь в with_file, и потому его можно передать в close, не опасаясь ошибок.

Как вы могли заметить, local лишь накладывает ограничения на использование, а потому, по идее, можно передать global значение туда, где ожидается local значение. И действительно, на вариантах режима локальности есть отношение субтипизации: global является подтипом local.

Автор отмечает, что локальность с успехом используется на практике.