Поддержка Qt Creator в Gentoo - это какой-то стыд и позор. Мало того, что бородатая версия, так ещё и clang-code-mode сломали в последнем обновлении.

Есть решения кроме сборки QtC из сорцов самостоятельно?

nvidia не обманула, новая видяха и вправду на 50% быстрее 2080 Ti (и в 2-3 раза быстрее Radeon VII), что является одним из самых больших скачков в производительности. И это не говоря о 3090, которая появится в ближайшее время.

https://www.guru3d.com/articles-pages/geforce-rtx-3080-founder-review,1.html

В продолжение темы: Объясните сишную магию

Ковыряю сорцы Skia и наткнулся на такой забавный ужас (ссылка):

int fLastMoveToIndex = 5; // любое число
fLastMoveToIndex ^= ~fLastMoveToIndex >> (8 * sizeof(fLastMoveToIndex) - 1);

Экспериментально удалось выяснить, что данный код меняет знак и отнимает 1 только если число положительное. Как он это делает - я даже знать не хочу.

Вопрос: что мешало написать банальный if, или хотя бы оставить комментарий? Типичное сишное какерство?

PS: производительно данного куска кода на погоду не влияет.

Кто бы мог подумать, ещё лет 5 назад, что питон получит типизацию и функциональщину. Но нет:

def is_tuple(node: Node) -> bool:
    match node:
        case Node(children=[LParen(), RParen()]):
            return True
        case Node(children=[Leaf(value="("), Node(), Leaf(value=")")]):
            return True
        case _:
            return False

История показывает, что участь любого популярного ЯП - С++ ужас.

https://www.python.org/dev/peps/pep-0622/

Спустя 1000 лет, GitHub решил обновить свой дизайн. Я, в целом, позитивно воспринимаю изменения, но это полный ужас. С моим ОКР, сам факт того, что теперь всё съехало влево - уже приговор. Да и редизайн в целом ограничился увеличением скругления углов и заменой всех цветов на более блёклые. Теперь даже GitLab выглядит не так ужасно…

И это сразу после новости о новом HIG для macOS, к которому тоже тонна вопросов.

Решил посмотреть что из себя представляет ungoogled-chromium, поэтому собрал его из сорцов на генте. 2.5 часа с lto…

Чего я не ожидал, так это прироста «производительности». В бенче https://browserbench.org/Speedometer2.0/ :

• google-chrome-bin - 135.5
• ungoogled-chromium - 152.4

Почти 10% прирост на ровно месте. В обоих тестах использовался чистый профиль.

Есть объяснение такому поведению?

Нужна self-hosted галерея/каталогизатор для фото/видео с упором на теги.

Нужно:

• Поиск по нескольким тегам сразу + возможность исключений.
• У тегов могут быть типы/категории/цветовое различие. Теги должны отображаться рядом с каждым фото.
• Нужно некое подобие «ленты». Например при сортировке по дате.
• Должно выглядеть вебдванольно.

Самое близкое из того что нашёл - это Lychee. Но там теги в зачаточном варианте.

PS: booru не подходит тоже, ибо привет из 90-х

И с большим отрывом.

https://stackoverflow.blog/2020/05/27/2020-stack-overflow-developer-survey-results/

https://www.chromium.org/Home/chromium-security/memory-safety

Не прошло и года с последних откровений: Про статическую типизацию и безопасный доступ к памяти, как гугл пришёл к тем же выводам, что и MS.

Что на это скажут приверженцы «они просто не умеют писать на C/C++», «в C++ тоже есть умные указатели, зачем вам этот раст» и «понанимали дебилов»?

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

Имеется привычная ситуация: UI, в котором пользователь бездумно жмакает кнопочки, которые в свою очередь запускают асинхронные/параллельные задачи. Это может быть как и GUI, так и сайт, посылающий запросы серверу.

А теперь начинается интересное:

1. Любое действие должно быть отменяемым (не убивание потока, а штатное завершение). Большинство async кода что я видел, не поддерживает такую простую фичу. Видимо вебсерверам это не интересно. Даже в Go, с его горутинами, это достигается велосипедами, а не средствами языка.
2. Любое действие может быть продолжено. Это немного похоже на предыдущую задачу, но с тем нюансом, что у нас задача представляет собой не loop {}, а цепочку действий.
3. Задача может общаться с родителем. Запрашивать новые данные, подтверждать действия.
4. Задача может использовать глобальный контекст. То есть живёт не сама по себе.
5. Задача может запускать свои асинхронные задачи и на неё распространяются те же требования, что и выше.
6. Это не должно превратиться в callback hell.

Язык роли не играет. Производительность тоже. Интересует сам алгоритм.

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

https://www.linux.org.ru/forum/talks/15707915

У пациента явное отклонение от нормы. А теперь ещё и про вирус начал шизу писать, на пару со Stanson. Напильника забанили, теперь очередь этих.

https://github.com/microsoft/BosqueLanguage

Основные фичи:

• GC в виде счетчика ссылок, ага
• immutable
• нет циклов, только функциональщина
• дженерики, в том числе variadic
• sum types/adt
• синтаксически, смесь C++, Rust, Swift и OCaml, но страшнее
• optional - часть языка, ака оператор ?
• рекурсия должна быть явно объявлена через ключевое слово recursive
• трансплитер написан на typescript и выплёвывает C++ (но это не точно)
• они ещё используют Z3, но не ясно как именно

Пример:

entity Person {
    field name: String; 
}

function foo(arg?: {f: Int, n?: String} | String | Person): String {
    if(arg == none) {
        return "Blank";
    }
    else {
        return switch(arg) {
            type Record => arg.n ?| "Blank"
            type String => arg
            type Person => arg.name
        };
    }
}

foo()                    //"Blank"
foo(none)                //Type error - none not allowed
foo("Bob")               //Bob
foo(Person@{name="Bob"}) //Bob
foo({f=5})               //"Blank"

foo({f=1, n="Bob"})      //"Bob"
foo({g=1, n="Bob"})      //Type error - Missing f property

Собственно понадобились древовидных/иерархических конфиги для написания людьми. Такой себе DSL. Человек пишет декларативный конфиг - прога его обрабатывает и выдаёт результат.

Требования:

1. Минимальное количество синтаксического шума.
2. Коментарии.
3. Многострочный текст.
4. Иерархичность.
5. Популярный формат, чтобы либа была для любого языка.

Что имеем:

• YAML

  Самый очевидный выбор. Но провозившись с ним неделю - я возненавидел его. Он до безобразия переусложнён и не очевиден. Я до сих пор не могу предугадать как мой конфиг будет распарсен - это провал. Я даже пытался написать простенький парсер, чтобы лучше понять его. Но только больше запутался.

• XML

  Тот случай, когда дедушка XML подходит лучше всего. Но хотелось бы что-то более простое.

• JSON

  Не подходит по всем параметрам. Не для людей.

• JSON5

  Ближе всего к идеалу, но малораспространён.

• TOML

  Всем хорош, но не древовидный (да, если костыль, но это тихий ужас).

Есть идеи?

PS: шутки про s-expressions не интересны

В очередной раз столкнулся со старой проблемой: valgrind позволяет найти медленные функции до тех пор, пока они не инлайнятся. Можно это как-то обойти? У меня пару десятков функций, которые в релизе превращаются в одну. Как найти причину тормозов - не ясно.

Может есть какой-то профилировщик, который выплюнет asm и покажет какие куски дольше всего выполнялись? Типа flame graph.

PS: интересует софт только под линь.

ttf-parser — это библиотека для разбора TrueType/OpenType шрифтов. В новой версии появилась полноценная поддержка переменных шрифтов (variable fonts) и C API, вследствие чего я решил прорекламировать её на лоре.

До недавнего времени, если была необходимость работы с TrueType шрифтами, было ровно два варианта: FreeType и stb_truetype. Первый является огромным комбайном, второй поддерживает довольно небольшое количество функций.

ttf-parser находится где-то посредине. Он поддерживает все те же TrueType таблицы (формат TrueType состоит из множества отдельных бинарных таблиц) что и FreeType, но не занимается отрисовкой самих глифов.

При этом, ttf-parser содержит множество других значительных отличий:

1. ttf-parser написан на Rust без использования unsafe. FreeType и stb_truetype написаны на C.
2. ttf-parser является единственной безопасной (memory-safe) реализацией. Чтение произвольной памяти невозможно. Во FreeType постоянно исправляют уязвимости, а stb_truetype в принципе не предназначен для чтения произвольных шрифтов.
3. ttf-parser является единственной thread-safe реализацией. Все методы парсинга константны. Единственным исключением является задание координат для переменных шрифтов, но эта функция reentrant. FreeType в принципе однопоточный. stb_truetype - reentrant (можно использовать отдельные копии в разных потоках, но не одну из множества).
4. ttf-parser является единственной реализацией не использующей аллокации в «куче». Это позволяет ускорить разбор и избежать проблем при OOM.
5. Также, почти все арифметические операции и приведение числовых типов проверяются (в том числе статически).
6. В самом худшем случае библиотека может бросить исключение. При этом в C API исключения будут перехвачены и функция вернёт ошибку, но не упадёт.

И несмотря на все гарантии безопасности, ttf-parser также является и самой быстрой реализацией. Например разбор CFF2 в 3.5 раза быстрее чем в FreeType. Разбор glyf тем временем на 10% медленнее чем в stb_truetype, но это из-за того, что он не поддерживает переменные шрифты, для реализации которых требуется хранить доп. информацию. Больше подробностей в README.

>>> Подробности

Не успел Dropbox порадовать переписыванием своего движка на Rust, как появились новые вакансии у Apple:

https://jobs.apple.com/en-us/details/200144575/software-engineer

Following a very successful first foray into Rust we are migrating an established codebase from C to Rust, and building new functionality primarily in Rust.

Перемещено a1batross из development

При нажатии темнеет экран, но через пару сек возвращается в норму. Не пойму что он пытается сделать и как это отключить.

Бесит потому, что Fn+F11 у меня увеличивает громкость и я часто промахиваюсь.

Как я понял, QtC работает только со специально собранным clang. Иначе получаем:

:-1: error: Failed to analyze "test.cpp": Clang-Tidy and Clazy finished with exit code: 1.

Есть какие-то методы решения этого бага? Ничего толкового/рабочего не нагуглил.

PS: dev-qt/qt-creator-4.10.1, sys-devel/clang-8.0.1/9.0.1

PSS: почему qtc вечно такой бородатой версии в генту?

Собственно есть идея написать статическое веб-приложение для разбора определенного бинарного формата. Такой себе аналог Kaitai Struct IDE, но для одного формата.

Слева у нас HexView, справа - TreeView. Проблема в том, что TreeView может содержать под 100к записей, соответственно нужна реализация, способная это переварить.

Как я это вижу:

• Read-only HexView. Нужно отображать не больше пары мегабайт. Но нужна возможность выделять блоки байт (как в Kaitai Struct IDE).
• TreeView, способный или переваривать 100500 записей, или способный подгружать/парсить дочерние элементы при необходимости (даже лучше).
• react + material-ui PWA на github pages с TypeScript для парсера бинарника.

Соответственно, кто-то пишет морду, а я пишу разбор. Всё это публикуется на github под MIT.

Если кому-то интересно - пишите сюда. Сам я такое не потяну, так как в вебе полный 0 и времени учить всю эту кухню пока нет.

Не в jobs, ибо на интерес.