Кому понадобится наложить на видео или стрим overlay с нажатыми клавишами, мне понравились вот эти два решения:

Это плагин для obs с набором готовых настроек и атласов для отображения раскладки клавиатуры или игрового манипулятора с состоянием их клавиш:
https://obsproject.com/forum/resources/keyviz.1565/
https://github.com/mulaRahul/keyviz

Это самостоятельная программа с большим количеством настроек, которая показывает на экране нажатые клавиши и их сочетания:
https://obsproject.com/forum/resources/input-overlay.552/
https://github.com/univrsal/input-overlay

Я такую как раз использовал в последнем видео.

ссылка на канал | ссылка на группу

ссылка на канал | ссылка на группу

// compile_flags.txt
...
-fexec-charset=windows-1251

Никто не знает можно ли как-то clangd указать execution charset для строковых литералов?

Файл исходного кода у меня в utf-8, но -fexec-charset=windows=1251 перекодирует строки в windows-1251 в скомпилированной программе.

Соответственно я хочу, чтобы визуальные подсказки по ordinary string literal отображались с правильным размером типа данных (const char[N]) и правильными кодами символов (codepoint).

При указании аргумента, отличного от utf-8, для -finput-charset или -fexec-charset, в редакторе появляется ошибка:
Invalid value 'windows-1251' in '-fexec-charset=windows-1251' clang(drv_invalid_value).
Ошибка появляется для любого значения, отличного от utf-8.

По информации из интернета я понял, вроде, что дело то ли в используемом кодировщике iconv или ICU и какой-то их особенности под windows в виде отсутствии поддерживания другой кодировки.
То ли это особенность самого clangd, который также не поддерживает кодировку любую другую кодировку кроме utf-8.

ссылка на канал | ссылка на группу

ссылка на канал | ссылка на группу

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

Версия g++ на данный момент последняя стабильная: 14.2.0.
Версия clang++ и clangd на данный момент отстаёт от стабильной всего на 5 minor версий: 19.1.1.

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

Репозиторий git.
Репозиторий llvm.

ссылка на канал | ссылка на группу

ссылка на канал | ссылка на группу

⚠️ не используйте этот способ, пока не прочитаете обновление по этой публикации:
https://t.me/a248640develop/330

Продолжаю настраивать чистый и пустой vs code после переустановки windows 11.

Следующая проблема, с которой я столкнулся, оказалась в отсутствии папки bin компилятора в переменных среды (PATH), из-за этого не запускается скомпилированная им программа, так как она не полностью самодостаточна и зависит его его библиотек времени выполнения (runtime).

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

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

Я знаю, что в терминале можно временно изменять переменные окружения.
Например, для cmd будет: set path=path_to_compiler_bin;%path%.
Это самый простой способ временно изменить PATH и запустить процесс с этими изменёнными переменными, и чтобы windows смогла найти все нужные exe и dll файлы.

Я подумал, а можно ли как-то в vs code перед запуском терминала выполнить какую-то свою команду или запустить скрипт?
Как активация виртуального окружения python, например.
Да, можно, для этого есть настройка "terminal.integrated.shellArgs.windows": [""], но она, к сожалению или к счастью, стала устаревшей и была удалена.

На замену ей пришли профили терминала: "terminal.integrated.profiles.NNN", в которых можно не только создавать свои, но и переопределять настройки для стандартных, можно поменять не только аргументы, которые мне были и нужны, но и путь до исполняемого файла и даже иконку.

В настройки уровня пользователя, проекта или решения нужно добавить следующий текст:

// settings.json
{
    "terminal.integrated.profiles.windows":
    {
        "Command Prompt":
        {
            "path":
            [
                "${env:windir}\\Sysnative\\cmd.exe",
                "${env:windir}\\System32\\cmd.exe",
            ],
            "args":
            [
                "/k",
                "echo hello & echo world & prompt $g$s",
            ],
            "icon": "terminal-cmd",
        },
    },

    "terminal.integrated.defaultProfile.windows": "Command Prompt",
}

И в итоге вместо стандартного содержимого терминала:

Microsoft Windows [Version 10.0.22631.4602]
(c) Корпорация Майкрософт (Microsoft Corporation). Все права защищены.

C:\Users\user>_

В моём случае будет:

hello
world

> _

Я для примера решил вывести текст hello и world на разных строках и изменить префикс ввода (не знаю как на русском это назвать лучше).
Любителям "а как убрать путь из консоли" посвящается).

Вместо команды "echo hello & echo world & prompt $g$s" можно сделать вызов любого скрипта, даже vcvarsall.bat, что позволит легко использовать компилятор cl.exe (MSVC).

ссылка на канал | ссылка на группу

Немного полезной информации).

Мне всегда было интересно, где взять оригиналы стандартных фонов рабочего стола windows.

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

Немного погуглил и нашёл:
В windows 10 и 11 стандартные фоны хранятся в папке "C:\Windows\Web".
Обычно, в этой папке есть ещё подпапки для каждой из тем (например, Flowers, Windows) и разрешений экрана (например, 4K).

Теперь фон блокировки выглядит точно так же, как и фон рабочего стола.

Если кому-то будет интересен фон для светлой и тёмной темы в разрешении 4K, я их приложил к этой публикации.

Для любителей особо тёмной чёрной темы, я сделал чёрно-белый вариант тех фонов:
img0Blacked.jpg и img19Blacked.jpg

ссылка на канал | ссылка на группу

ссылка на канал | ссылка на группу

Совершенно случайно при редактировании файла вместо ctrl + C нажал ctrl + shift + C, и внезапно у меня открылась отдельная от vs code обычная cmd консоль.

Подумал, что-то тут не так, в смысле..., откуда появилась консоль, если я просто копировал текст?

Решил проверить текущие горячие клавиши / назначения клавиш.
Оказывается, в vs code есть (или появилось) назначение клавиш по умолчанию ctrl + shift + C на открытие внешнего терминала.

Интересно, а меняет ли vs code этому новому процессу консоли переменные среды PATH, если из как-то менять или дополнять через настройки?
Хороший вопрос, который надо будет проверить.
(Оказалось, нет, только cwd меняет)

Обычно, я стараюсь какие-то незначительные вещи не выкладывать в виде публикации в канале, а просто кидаю в группу.
Но последние три дня я 24/7 мучаюсь с vs code и, кажется, у меня есть интересные результаты и выводы, а также, возможно, я случайно нашёл один баг).
Перед написанием огромной публикации, что, на самом деле, является очень большим и трудоёмким процессом, особенно в моём-то стиле написания, хочется сделать какие-то простые публикации, не напрягаться сильно, и чтобы канал не пустовал.

Да и такая информация может быть кому-то полезна).

(И никто не сказал, что "трудоёмкий труд" это речевая ошибка, тавтология)

ссылка на канал | ссылка на группу

1 часть
2 часть

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

Решил пока остановиться на поиске способа для tasks.json, так как с настройкой на уровне settings.json всё оказалось просто и понятно, она прекрасно работает, как и задумано, а вот для задач всё странно.

Я нашёл параметр options.env.path, но в процессе экспериментов и тестирования различных комбинаций настроек, я заметил неожиданное и непонятное, неправильное поведение.

Если определить этот параметр глобально на уровне tasks или локально на уровне уровне отдельной задачи и изменять там переменную среды path, то задачи типа process почему-то перестают находить стандартные системные исполняемые файлы, например, cmd.exe.

Такое чувство, что ломается или затирается path для самого vs code.
Но я такого ещё не видел, чтобы настройки в vs code могли менять его собственные переменные окружения, или чтобы задача сразу использовала изменённые переменные окружения для запуска процесса, дочерний процесс может их только наследовать или получать переопределённую версию.

Таким образом никакие мои настройки не должны приводить к тому, чтобы vs code не мог найти при запуске process задачи cmd.exe, так что я думаю, что я нашёл баг.
Нигде в документации я не нашёл каких-то предостережений или правил, которые запрещали бы мне изменять path для дочернего процесса, и что это бы сломало запуск задач.

При этом, если указать полный путь до cmd.exe, то задача успешно запускается и процесс получает правильный изменённый path.

Ещё я заметил, как мне кажется, странное поведение при определении настройки options.env.path как глобально, так и локально.
Если в глобальной настройке переопределить path, а в локальной оставить пустой список:

// глобально
"options":
{
    // изменение только переменной path
    "env":
    {
        "path": "C:\\HELLO;${env:path}",
    },
}

// локально
"options":
{
    // пустой список, ничего не добавляется, не изменяется и не удаляется
    "env":
    {
        
    },
}

То задача запускается со значением path по умолчанию, наследованным от vs code.
Не знаю, должно ли быть именно такое поведение или тут тоже что-то не так, но мне показалось это странным и неочевидным, что усложнило мне тестирование и эксперименты.

ссылка на канал | ссылка на группу

1 часть
2 часть

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

{
    "version": "2.0.0",
    "tasks":
    [
        // bug task process
        {
            "label": "bug task process",
            "type": "process",
            "command": "cmd.exe",
            // "command": "${env:windir}\\System32\\cmd.exe",
            "args":
            [
                "/c",
                "echo",
                "%path%"
            ],
            "group": "build",

            // "options":
            // {
            //     "env":
            //     {
            //         "path": "C:\\HELLO;${env:path}",
            //     },
            // }
        },

        // bug task shell
        {
            "label": "bug task shell",
            "type": "shell",
            "command": "echo",
            "args":
            [
                "%path%"
            ],
            "group": "build",

            // "options":
            // {
            //     "env":
            //     {
            //         "path": "C:\\HELLO;${env:path}",
            //     },
            // }
        },
    ],

    // "options":
    // {
    //     "env":
    //     {
    //         "path": "C:\\HELLO;${env:path}",
    //     },
    // }
}

Учтите особенности переопределения глобальных настроек локальными и для тестирования не оставляйте полностью незакомментированным блок options.env.path, если хотите закомментировать только значения в env параметре.

Чтобы исключить влияние кеширования значения path, которое может повлиять на результаты запуска будущих задач, после каждого запуска задачи, я принудительно убивал процесс терминала.

Сначала попробуйте запустить обе задачи без каких-либо изменений:
Обе задачи успешно запустятся и выведут вам ваше системное или пользовательское значение переменной среды path.

Пример вывода shell задачи:

*  Executing task in folder project: echo %path% 

C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\Users\user\AppData\Local\Microsoft\WindowsApps;
*  Terminal will be reused by tasks, press any key to close it.

Пример вывода process задачи:

*  Executing task in folder project: C:\windows\System32\cmd.exe /c echo %path% 

C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\Users\user\AppData\Local\Microsoft\WindowsApps;
*  Terminal will be reused by tasks, press any key to close it. 

Однако, стоит раскомментировать параметр options.env.path глобально или локально, shell типы задач будут успешно запускаться и выводить переопределённое значение path:

*  Executing task in folder project: echo %path% 

C:\HELLO;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\Users\user\AppData\Local\Microsoft\WindowsApps;
*  Terminal will be reused by tasks, press any key to close it. 

А process типы задач будут выводить ошибку:

Executing task in folder project: C:\Users\user\storage\development\project\cmd.exe /c echo %path%
The terminal process failed to launch: Path to shell executable "C:\Users\user\storage\development\project\cmd.exe" does not exist.

Но если вместо "cmd.exe" указать "${env:windir}\\System32\\cmd.exe", process задачи тоже будут работать:

*  Executing task in folder project: C:\windows\System32\cmd.exe /c echo %path% 

C:\HELLO;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\Users\user\AppData\Local\Microsoft\WindowsApps;
*  Terminal will be reused by tasks, press any key to close it.

ссылка на канал | ссылка на группу

Есть обновление по этой публикации, где я предлагал использовать параметр "terminal.integrated.profiles.windows" для изменения значения системной переменной path по умолчанию у встроенного терминала и при запуске задач.

Изначально, я искал это решение именно для той цели, но потом подумал для примера добавить выполнение команд некоторых действий при запуске.
В той публикации видно, что всё работает, текст выводится, префикс ввода меняется.

Однако, на этом плюсы заканчиваются.
Когда я попробовал запустить задачу типа shell, они оказались сломанными.
С чего бы тут начать объяснение...
Ну, начну с того, что тут есть две причастные стороны.

Почему-то cmd не поддерживает выполнение нескольких команд, разделённых аргументами командной строки.
У cmd довольно большой список аргументов, поэтому я покажу сокращённый пример синтаксиса и ключей, которые я использовал, полный список вы можете сами посмотреть в документации.

cmd [/c|/k] [/d] [<string>]

В синтаксисе не указано, что есть возможность выполнения нескольких [<string>], а если запускать несколько cmd подряд, то это не будет иметь нужного эффекта, так как они не будут наследовать переменные среды друг друга, так как являются независимыми процессами.

При запуске задач типа shell vs code использует полный путь до исполняемого файла терминала или его оболочки и какие-то аргументы по умолчанию, после этого он добавляет command и args из описания задачи.

И при изменении args для профиля терминала через параметр "terminal.integrated.profiles.windows", vs code почему-то просто конкатенирует новые аргументы с аргументами по умолчанию, хотя такое поведение кажется нелогичным.

Например, так выглядит команда по умолчанию при запуске shell задачи с command "echo" c args "world" :

C:\windows\System32\cmd.exe /d /c echo world

А если добавить переопределение аргументов запуска терминала:

"terminal.integrated.profiles.windows":
{
    "Command Prompt":
    {
        "path":
        [
            "${env:windir}\\Sysnative\\cmd.exe",
            "${env:windir}\\System32\\cmd.exe",
        ],
        "args":
        [
            // "/k",
            "/c",
            "echo",
            "hello",
        ],
        "icon": "terminal-cmd",
    },
},

То vs code почему-то пытается выполнить такую команду:

C:\windows\System32\cmd.exe /k /c echo hello /d /c echo world

Хорошо, что это не влияет на process задачи, но тогда возникает вопрос, а зачем тогда все эти изменения аргументов командной строки в профиле терминала.

Если бы cmd имел синтаксис "cmd [/c|/k] [/d] [<string>] [/c|/k] [/d] [<string>]..." или vs code при переопределении настроек профиля терминала добавлял только command и args из задачи без конкатенации аргументов терминала по умолчанию, то это бы работало, но увы.

Поэтому я не рекомендую использовать предложенный мной способ для cmd.exe.
Если вы используете другие терминалы или их оболочки, посмотрите shell integration в документации vs code.

А если вам нужно только добавить или изменить переменные среды, то я нашёл настройку "terminal.integrated.env.windows", которая работает просто идеально: влияет как на встроенный терминал, так и на задачи вида shell и process, и не ломает их:

"terminal.integrated.env.windows":
{
    "path": "C:\\HELLO;${env:path}",
},

Кстати, в vs code можно создавать свои пользовательские настройки, которые через переменные можно использовать в других конфигах vs code.
И несмотря на то, что в редакторе кода пользовательские настройки будут наполовину серыми по причине "Unknown Configuration Setting", они всё равно будут прекрасно работать.

Например, настройку "terminal.integrated.env.windows" можно объединить с пользовательскими настройками, и получится что-то такое:

"mySettings.compilerPath": "C:\\compiler\\bin",
"mySettings.gitPath": "C:\\git\\bin",
"mySettings.pythonPath": "C:\\python\\bin",
"mySettings.customPath": "${config:mySettings.compilerPath};${config:mySettings.gitPath};${config:mySettings.pythonPath};${env:path}",

"terminal.integrated.env.windows":
{
    "path": "${config:mySettings.customPath}",
},

ссылка на канал | ссылка на группу

ссылка на канал | ссылка на группу

Впервые за много лет я снова увидел VHS кассеты.
Сегодня её вручную ручкой крутил).

Нашёл дома старый VHS проигрыватель и кассету в нём, которую мне очень нравилось в детстве пересматривать.
В процессе перемотки кассеты я услышал громкий шелест ленты.
Мне показалось это странным, и я сразу прервал процесс перемотки и извлёк кассету.
Оказалось, магнитная лента вылезла и перекрутилась.
Пришлось гуглить, как снять стопор в кассете, выровнял, распутал и заправил ленту обратно.

ссылка на канал | ссылка на группу

Зашёл сегодня в настройки роутера и случайно обратил внимание в разделе WAN на значение IP адрес, оно было вида 172.24.86.40.
Потом проверил IP, например, на сайте myip.com.
Там отображался отличный от WAN IP вида 83.224.86.40.

Стало интересно, а почему так.

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

Решил узнать, к какой классификации и диапазону IP относятся те двое.
Первый это class B private (172.16.0.0-172.31.255.255), а второй это class A public (1.0.0.0-127.0.0.0).
То есть эти IP адреса имеют разную классификацию и попадают в разные диапазоны публичности.

У роутера для подключённых устройств есть своя локальная сеть, а из-за недостатка адресов ipv4 у провайдера (ISP) используется NAT (сетевая трансляция адресов), которая транслирует запросы от множества локальных адресов на один публичный в интернет и обратно транслирует ответ.

То есть между моим роутером и интернетом как минимум стоит ещё оборудование провайдера с настроенным NAT.
Ещё можно сделать вывод, что мой IP является серым, то есть на него нельзя напрямую делать запросы из интернета.

ссылка на канал | ссылка на группу