https://github.com/libra/libra

85KLOC строк кода на Rust

Тёрка за $6000. QML.

UPD: https://bugreports.qt.io/browse/QTBUG-76084

Делаю echo -e "\033[1mSome Text", но текст не жирный, а обычный. Судя по тестам, Qt игнорирует «жирные» версии Source Code Pro, при том что они установлены. Вероятно проблема в fontconfig.

~> fc-match monospace
SourceCodePro-Regular.ttf: "Source Code Pro" "Regular"
~> fc-match monospace:bold
SourceCodePro-Bold.ttf: "Source Code Pro" "Bold"
~> fc-list 'Source Code Pro'
/usr/share/fonts/source-code-pro/SourceCodePro-BoldIt.ttf: Source Code Pro:style=Bold Italic
/usr/share/fonts/source-code-pro/SourceCodePro-Light.ttf: Source Code Pro,Source Code Pro Light:style=Light,Regular
/usr/share/fonts/source-code-pro/SourceCodePro-ExtraLightIt.ttf: Source Code Pro,Source Code Pro ExtraLight:style=ExtraLight Italic,Italic
/usr/share/fonts/source-code-pro/SourceCodePro-Bold.ttf: Source Code Pro:style=Bold
/usr/share/fonts/source-code-pro/SourceCodePro-ExtraLight.ttf: Source Code Pro,Source Code Pro ExtraLight:style=ExtraLight,Regular
/usr/share/fonts/source-code-pro/SourceCodePro-Black.ttf: Source Code Pro,Source Code Pro Black:style=Black,Regular
/usr/share/fonts/source-code-pro/SourceCodePro-Semibold.ttf: Source Code Pro,Source Code Pro Semibold:style=Semibold,Regular
/usr/share/fonts/source-code-pro/SourceCodePro-LightIt.ttf: Source Code Pro,Source Code Pro Light:style=Light Italic,Italic
/usr/share/fonts/source-code-pro/SourceCodePro-Medium.ttf: Source Code Pro,Source Code Pro Medium:style=Medium,Regular
/usr/share/fonts/source-code-pro/SourceCodePro-It.ttf: Source Code Pro:style=Italic
/usr/share/fonts/source-code-pro/SourceCodePro-Regular.ttf: Source Code Pro:style=Regular
/usr/share/fonts/source-code-pro/SourceCodePro-MediumIt.ttf: Source Code Pro,Source Code Pro Medium:style=Medium Italic,Italic
/usr/share/fonts/source-code-pro/SourceCodePro-SemiboldIt.ttf: Source Code Pro,Source Code Pro Semibold:style=Semibold Italic,Italic
/usr/share/fonts/source-code-pro/SourceCodePro-BlackIt.ttf: Source Code Pro,Source Code Pro Black:style=Black Italic,Italic
~> eselect fontconfig list | grep \*
Available fontconfig .conf files (* is enabled):
  [5]   10-hinting-slight.conf *
  [18]  30-metric-aliases.conf *
  [19]  40-nonlatin.conf *
  [20]  45-generic.conf *
  [21]  45-latin.conf *
  [22]  49-sansserif.conf *
  [23]  50-user.conf *
  [24]  51-local.conf *
  [28]  60-generic.conf *
  [29]  60-latin.conf *
  [32]  65-nonlatin.conf *
  [37]  70-no-bitmaps.conf *

В убунте и арче всё ок.

Куда копать?

12 ядер, 24 потока, базовая частота 3.8GHz и 4.6GHz в турбо.

Intel с уязвимостями больше не нужен?

Честно говоря не верил в 12/24, но AMD молодцы. Теперь есть повод обновится.

https://www.anandtech.com/show/14407/amd-ryzen-3000-announced-five-cpus-12-co...

Изучаю QML на примере Qt Quick Controls 2, но столкнулся с парой эпичных косяков:

1. Ресайз окна приводит к пляскам виджетов (пример). Советуют использовать софтварный opengl, но это убивает всю идею QML.
2. frameless window фактически нереализуем, так как при анимации пользовательские события блокируются. В итоге если у нас где-то крутится спинер - перемещать/ресайзить окно нельзя. При этом перемещать/ресайзить окно за пределы экрана тоже нельзя.

Вопрос к тем кто уже пытался что-либо соорудить на QML - как оно? Я так понимаю, что оно только для встройки, где окно всегда фиксированного размера.

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

Пытался понять как реализовать SVG фильтр feComposite, ибо SVG дока унылая, поэтому залез в сорцы вебкита. Там тоже документации ноль, ещё и код очень странный.

Вот что это за ужас (src):

static unsigned char clampByte(int c)
{
    unsigned char buff[] = { static_cast<unsigned char>(c), 255, 0 };
    unsigned uc = static_cast<unsigned>(c);
    return buff[!!(uc & ~0xff) + !!(uc & ~(~0u >> 1))];
}

Я так понимаю, они проверяют что int в 0..255 диапазоне, но уж слишком странным образом.

UPD: коммит, который добавил этот код.

В продолжение У 70% девелоперов Stackoverflow нет личной жизни

Разрабы испугались, и за год нарожали детей, чтобы снизить планку на 10%.

В остальном, без особых изменений. JS - самый популярный, Rust - самый любимый (4-е года подряд). По популярности: Python обогнал Java, TypeScript обогнал C, Go обогнал Swift.

src

Такой-то подарок после 3-х лет, а на лоре тишина.

QtWebEngine в принципе можно собрать без QML? Как я понял, это жёсткая зависимость, но не понятно почему.

https://blog.golang.org/survey2018-results

Из интересного:

• Гоферы не используют винду для разработки. Чисто виндузятников всего 5%. Лидирует естественно онтопик.
• Количество вимеров прилично сократилось. Большинство использует VS Code.
• Большинство гоферов тусуется на SO, что способствует популярности во всяких рейтингах языков (того же Rust сообщества на SO фактически нет, все сидят на /r/rust).
• Большинство гоферов знают/используют в том числе Python, Java, JavaScript. Плюсовиков хоть и много, но меньше даже С. Несмотря на рассказы некоторых личностей, что все плюсовики сбежали на go.

Потребовалось удалить директорию в python скрипте (я его вместо баша использую, ибо последний не для людей), а оказалось что не всё так просто. Банальный shutil.rmtree не работает, так как директория содержит .git. И вместо того, чтобы добавить force=True, пришлось городить:

def onerror(func, path, exc_info):
    import stat
    if not os.access(path, os.W_OK):
        os.chmod(path, stat.S_IWUSR)
        func(path)
    else:
        raise

shutil.rmtree('/path', onerror=onerror)

Это вообще нормально?! Когда уже сделают нормальную замену башу?

PS: нет, rsync не угонял мой аккаунт.

Обычная история: имеем одну мастер ветку, к которой привязаны теги/релизы. Публикуем релиз и начинаем заливать новый код. Вдруг оказывается, что нужно выложить багфикс релиз без новых изменений. Как это лучше организовать?

Очевидный ответ - git-flow. Но он больно сложный, особенно для простых репозиториев и маленькой команды.

Альтернативное решение - stable ветка. То есть master - это у нас develop (в терминологии git-flow), а stable содержит сами релизы.

Соответственно, когда нам нужно сделать хотфикс - мы создаем ветку от stable, фиксим баг, а затем сливаем её со stable и master.

Когда в master набирается достаточно изменений - сливаем их со stable и ставим тег/публикуем релиз.

Какие подводные камни у данного метода? Некоторые советуют по-прежнему использовать merge --no-ff, но я так и не понял какой от него толк, только коммиты засоряет. А хотелось бы, чтобы stable был зеркальной копией master, только «старой».

PS: использую git уже нацать лет, а он по прежнему как чёрный ящик.

Название темы тупое, но лучше не придумал…

Имеем QScrollArea, на которой находятся 4-е «mpv виджета», вертикальным списком.

• Если используем вариант отрисовки на нативном виджете - видео «рвётся» при прокрутке.
• Если используем вариант отрисовки на OpenGL виджете - GUI начинает лагать. Я так понимаю, что обновление контекстов блочит основной поток.

Может кто-то сталкивался с подобным? Есть ли смысл бороться с Qt или стоит сразу делать viewport на GL? Если да, то с чего начать? SDL?

Задача состоит в отображении n роликов одновременно с динамическим изменением их позиций. При этом сами ролики живут сами по себе и синхронизировать их нельзя (типа выводить все 4-е за раз).

Гугл анонинсировал новое ненужно: стриминг игр.

Важным для лора является то, что игры рендерятся на серверах с AMD + Vulkan + Linux.

Где-то год назад переехал с chromium на chrome, так как сборка начала занимать почти 6 часов (лиса за 45 мин собирается), а jumbo-build вешал систему. Сегодня решил ещё раз поиграться с jumbo-build, но в этот раз ограничив сборку 2-я потоками и добавив 8GB свопа к моим 8GB ОЗУ. Этого оказалось впритык, но зато хром собрался всего за три часа. И это в 2-а потока! Шах и мат фанбои хедеров, которые «не замедляют сборку».

Но не всё так просто. Решил запустить бенчмарк на обоих версиях, и получил ну очень странные результаты:

(больше - лучше)

chrome      | gentoo | чистый профиль  - 79
chromium    | arch   | чистый профиль  - 78
chrome      | Win 10 | чистый профиль  - 74
chromium    | gentoo | чистый профиль  - 71
chrome      | gentoo | текущий профиль - 67
firefox     | arch   | чистый профиль  - 63
chromium    | gentoo | текущий профиль - 61
firefox-bin | gentoo | чистый профиль  - 58
firefox     | Win 10 | чистый профиль  - 55

Как это объяснить? А вот так.

UPD: Kraken JavaScript Benchmark:

(меньше - лучше)

• chrome - 1129ms
• chromium - 1132ms
• firefox-bin - 1099ms

https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/commit/5d5046cb2e5c7...

Рад за гномеров, так как сам использую данный шрифт.

https://developers.redhat.com/blog/2019/03/08/usability-improvements-in-gcc-9/

В GCC 9 добавят форматирование ошибок как в rustc. В том числе и с json выхлопом, что облегчит жизнь IDE (и не только).

До уровня rustc, или хотя бы clang, ещё далеко, но прогресс радует.

Тут MS выложила свой калькулятор в опенсорс и я решил посмотреть его сорцы.

В целом всё очень даже прилично, за исключением странных примесей, типа:

    void WindowFrameService::RegisterRuntimeWindowService(TypeName serviceId, _In_opt_ Object^ service)
    {
        if (TryResolveRuntimeWindowService(serviceId))
        {
            throw ref new InvalidArgumentException(serviceId + L" already registered");
        }

        m_runtimeServicesMap[serviceId.Name] = service;
    }

_In_opt_, ^, throw ref? С MSVC почти не сталкиваюсь, к счастью, но они настолько исказили язык? У этого чуда есть название? Github по прежнему считает что это C++.

Есть feature ветка, в которой 100500 коммитов, при этом она развивается параллельно с master. Хочу сделать git rebase -i для всех коммитов в этой ветке.

Задача вроде простая, но ничего толкового/рабочего нагуглить не смог.

PS: я знаю про merge --squash, это не оно.

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

Алгоритм:

• Если скор меньше 50 (по умолчанию 45?) - пользователь может создать только одно сообщение и/или тему в день (количество обсуждается).
• В собственной теме ограничение снимается (это для адекватных новичков).

Плюсы:

• Нет нужны банить всем известных личностей. Достаточно срезать скор и ограничение на количество сообщений будет вступать в силу.
• Теряется смысл в виртуальных профилях, так как во всех новых профилях будет данное ограничение.

Под вопросом:

• Не ясно что делать с активными новичками. У меня нет статистики, но не думаю что новички будут создавать десятки тем в день.
• Не знаю насколько это сложно реализовать. Но не думаю что проверка скора, времени последнего сообщения и автора темы будет слишком сложной задачей.
• Сюда же можно добавить ограничение на возможность голосования, чтобы избежать накрутки (случаи бывали).