Станислав Макаров

Судя по PEP 399, модули с префиксом написаны на C (ну или просто являются "ускоренными" вариантами, написанными на языке, отличном от Python).

Что касается модулей не из стандартных библиотек, префикс может иметь смысл такой же как и везде в Python - означать, что данная библиотека не должна импортироваться напрямую, т.е. является приватной.

1. системы контроля версий (git)
   
2. базы данных
   
3. понимание как работают разные API (REST, SOAP)
   

В сторону ffmpeg

Берете гайд.
https://docs.microsoft.com/ru-ru/windows/msix/pack...
Тут типы описаны
https://docs.microsoft.com/ru-ru/windows/uwp/get-s...

Понимаете что это обычный архив.
Распаковываете его. Смотрите на структуру.
Если это натив то запускаете IDA
Если это NET то dotPeak

Библиотеки для чего? Если для интерфейсов, то QT, например.
MFC, пусть и мертворождённый, но до сих пор жив. И до сих пор такой же неудобный, как и 30 лет назад.

да нет никаких проблем, кроме времени.
большие системы (а это основной рынок чашки за последние 20 лет) – крайне инертный рынок и не любит колебаний/перемен.
любой перелом требует много лет, если не десятилетий.

простой пример из наглядных: большинство государственных (федеральных или на уровне штатов) систем в сша до сих пор работают на коболе и железе, которое сейчас либо не производится вообще, либо в штучных количествах.
и все это время (начиная с 60–70х) они совершенно спокойно работали. пока не настала пичалька в лице известного вируса и событий, вызванным им.

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

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

Итак, мы пишем на нашем высокоуровневом любимом языке, неважно JS/Rust/C#/Scala/Python или любой другой. В современном мире у нас скорее всего есть какая либо абстракция для работы с асинхронными апи, предоставляемая или стандартной библиотекой языка или сторонними библиотеками. Она может быть примитивной и основанной на колбэках или более продвинутой, вроде Future/Promise/Task или чем-то подобным. Иногда наш язык предоставляет синтаксис наподобие async/await для более простой работы с этими абстракциями, а иногда асинхронная работа может вообще быть скрыта от нас в рантайме языка, например как с горутинами в Go. Но в любом случае где-то под капотом у нас будет event-loop, а иногда и не один, так как никто не запрещает нам писать многопоточку в то же время используя асинхронные вызовы.

Сам event-loop - это не более чем обычный while(true) или любой другой бесконечный цикл. И внутри этого цикла наша программа имеет доступ на извлечение к некоторой очереди (если не знаете, что это за структура данных, то погуглите), которая содержит в себе результаты уже обработанных задач. Программа берет очередной результат, находит ожидающий ее колбэк/Promise/Future/Task и запускает выполнение ожидающего кода. Очередей опять же может быть несколько и обрабатываться они могут по разному, но это не важно. Важно то, что наш основной поток (или потоки) ничего не знают, о том как выполняются асинхронные задачи. Он лишь смотрит, есть ли в очереди результат, и если есть - обрабатывает его, а если нет, то принимает решение или выйти из цикла (и завершить поток, а иногда и весь процесс) или уснуть пока новых результатов не появится.

Но откуда же в очереди берутся результаты? Надо понимать, что асинхронная программа почти всегда многопоточная и результат операций попадает в очередь из фоновых потоков, которые просто блокируются в ожидании нужного ресурса (или сразу многих ресурсов, если используют системные апи вроде epoll или kqueue). Как правило такие фоновые потоки большую часть времени находятся в состоянии ожидания, а значит не потребляют ресурсы CPU и не попадают в планировщик ОС. Такая простая модель действительно позволяет сильно экономить ресурсы по сравнению с моделью, где множество потоков выполняют по 1 задаче и самостоятельно ожидают свои запросы.

Важно отметить, что в современном мире даже на среднеуровневых языках, вроде C или C++, не говоря уже о высокоуровневых, не реализуют асинхронность сами. Во-первых, на разных ОС для этого используются разные апи. Во-вторых, эти апи на разных ОС умеют обрабатывать разные типы ресурсов (с сетью вроде как умеют работать все основные ОС, но помимо сети асинхронно можно работать с пользовательским вводом, диском и периферийными устройствами, вроде сканеров, вебкамер и прочего цепляемого в usb). Наибольшую популярность (ИМХО) имеет кроссплатформенная библиотека libuv, хотя в Rust принято использовать mio (или даже абстракции над ней, вроде tokio), в C# подобные механизмы есть в .NET Core, а в Go оно уже зашито

Ок. С прикладным кодом вроде разобрались. А что же происходит в ядре ОС? Ведь, как писалось выше, у нас даже есть апи, чтоб ждать запросы пачкой. Все просто. Ядра ОС стали асинхронными еще до того, как это стало мейнстримом, если мы конечно имеем дело не с ОС реального времени (но у нас же винда/линь/мак/фряха, а не ОС для бортового компа боинга, где это критично). Смотрите, когда что-то происходит на внешней периферии (ну например диск запрошенные данные прочитал или по сети данные пришли, или юзер мышкой дернул), то формируется прерывание. CPU реально прерывает свою текущую работу и бежит смотреть что случилось, точнее вызывает обработчик предоставленный ОС. Но у ОС то есть основная работа, поэтому она скорее старается освободить обработчик и просто скидывает все данные в оперативку, а разбираться будет потом, когда очередь дойдет. Ничего не напоминает? Очень похоже, на то что происходило в event-loop, только вместо фоновых потоков "результаты" попадают в очередь из прерываний. А уже когда-то потом ОС отдаст данные в драйвер устройства, ну и т.д., пока они не дойдут до нашего прикладного приложения. Вот и все, никакой магии.

gcc -L<путь до каталога с библиотеками> -l<имя библиотеки>

Design of the FAT file system: Directory table

Нода не умеет typescript

Вариант 1: скомпилировать
устанавливаем:npm i typescriptи запускаем$(npm bin)/tsc examplesестественно нужен tsconfig.json
Вариант 2: ts-node
устанавливаем:npm i typescript ts-nodeи запускаем

$(npm bin)/ts-node examples/upload-story.example.ts

https://docs.python.org/3/c-api/index.html

Сделать Main возвращающим async Task и уже в нем эвэйтить что угодно.
В настройках проекта поставьте версию языка 7 или 8

Искусственный интеллект — название всей области, как биология или химия.

Машинное обучение — это раздел искусственного интеллекта. Важный, но не единственный.

Нейросети — один из видов машинного обучения. Популярный, но есть и другие, не хуже.

Глубокое обучение — архитектура нейросетей, один из подходов к их построению и обучению. На практике сегодня мало кто отличает, где глубокие нейросети, а где не очень. Говорят название конкретной сети и всё.

источник

function test(a, b=null, c=null) {
    console.log(a);
     if(b) console.log(b);
     if(c) console.log(c);
}

test(1) // консоль: 1
test(1, 2) // консоль: 1, 2

Решено: Это был формат .hta можно писать безбраузерные приложения + поддержка javascript

HTML Application — приложение Microsoft Windows, являющееся документом HTML, отображаемым в отдельном окне без элементов интерфейса обозревателя таких как строка меню, строка адреса, панель инструментов с помощью движка Microsoft Internet Explorer.