Смотрел трансляцию и мне показалось, что AlphaStar побеждает во многом за счет более точного и быстрого микроменеджмента. Один раз он вообще зажал MaNa с трех сторон одновременно. Было бы интересно увидеть AI, который распознает изображение с экрана и управляет с помощью некоей эмуляции устройств ввода (задержки при перемещении курсора мыши, пропорциональные расстоянию, и т.п.). Основной интерес представляют, стратегия и «человечность» AI. A то, что он намного быстрее и точнее человека, известно и так.
Ваше решение обладает самобытностью, оно доведено до весьма приличного уровня и в принципе заслуживает уважения. Но я бы все же рекомендовал рассмотреть более «классический» вариант: Обычно входные данные разбиваются на токены лексическим анализатором, при этом каждому токену можно присвоить его местоположение (строка, столбец). В дальнейшем парсер анализирует последовательности токенов на предмет принадлежности грамматике, и, при нахождении «неправильного» токена, может извлечь нужную информацию о местоположении для указания точного места ошибки.
Если перед парсингом вы соединяете многострочные выражения в единые длинные строки, как тогда у вас организовано формирование сообщений об ошибках, ведь информация о текущей строке/колонке должна теряться?
Ну раз статья фактически состоит из кода, позволю себе его прокомментировать. Я сам начинал трудовую деятельность с предприятия, занимающегося ракетно-космической тематикой, поэтому хорошо представляю, как там любят аббривеатуры и какими предпочтениями обладают местные ветераны-программисты (из тех, кто застал становление компьютерной отрасли в СССР). Они безусловно молодцы, но я очень не рекомендую бездумно повторять за ними. Имена переменных и функций в вашем проекте могут показаться совершенно неочевидными для другого разработчика. Попробуйте не использовать аббривеатуры (кроме общепринятых, известных за пределами вашего предприятия), а так же не сокращать слова. Кроме того, не совсем понятно, зачем некоторые переменные-члены класса sigGenControl сделаны публичными.
Вы это говорите исключительно с точки зрения коммерческого проекта, которым занимаетесь на работе? А если я пишу OpenSource, я «по определению» не могу писать велосипед, даже если переизобретаю другое опенсорсное решение? Это все конечно придирки, просто я не совсем понял вашу мысль.
Однако открытый/бесплатный велосипед тоже является велосипедом. Где та граница, после которой велосипед переходит в категорию «существующее решение»? Если разработчик посвящает всё свое время (или большую его часть) велосипеду, то рано или поздно он доведет его до состояния «существующего решения». Если же велосипед написан второпях, плохо оттестирован, в нем отсутствует функциональность, имеющаяся в других готовых решениях, и он фактически просто затыкает какую-то дыру в проекте — это безусловно самый обычный велосипед.
Как бы появлялись существующие решения, если бы не было велосипедистов? Велосипеды нужны, как минимум для самообразования. Я считаю, что каждый нормальный программист должен попробовать реализовать что-нибудь вроде красно-черного дерева или даже компилятора для своего языка программирования. В процессе появляется более глубокое понимание предметной области, а так же приобретается уникальный опыт. Конечно, в большинстве случаев, подобные велосипеды не следует использовать в production. Для достижения высокого качества, велосипед нужно шлифовать годами, уделяя ему неприлично много времени. По сути, он должен стать основной, решаемой разработчиком задачей.
Насколько я понял, в вашем языке переменные не могут иметь тип «множество» или «словарь» (как в python и javascript), есть только массивы. Не думали добавить?
Я не работал над серьезными компиляторами (честно говоря никогда не слышал о коммерческой разработке компиляторов в РФ), поэтому не претендую на объективную истину. В моих велосипедах контекст ошибки был всегда понятен и проблемы сформировать хорошее сообщение с указанием точной позиции в тексте не возникало.
При реализации парсера вручную, хорошие сообщения об ошибках получатся без проблем сами собой.
Тут весь вопрос в том, какая именно у вас задача. Если требуется каждый день писать парсер для чего-то нового, конечно вариант готовой либы заруливает все остальное.
В случае реализации парсера самостоятельно, придется написать больше текста и потратить больше времени — это правда. Но время, необходимое на написание самого парсера, сильно меньше времени, необходимого на реализацию остальных компонентов компилятора/интерпретатора/VM. Тем более, что многие элементы парсера похожи, копипаст хорошо ускоряет процесс. Доказать я вам ничего не могу, мои высказывания основаны на небольшом личном опыте. Ученых степеней по теме не имею, в разработке серьезных компиляторов участия не принимал.
Лексер — весьма тривиальная вещь. Не особо сложнее, чем описать набор правил для того же flex. Парсер контекстно-свободной грамматики тоже не является rocket science. Другое дело, что при разработке парсера, придется в любом случае как-то описывать грамматику, что по сути эквивалентно созданию входных данных для bison. Тем не менее, при использовании готовых библиотек-построителей персеров, вы становитесь зависимы от них при весьма сомнительном уменьшении времени на разработку. Насколько оправдана такая зависимость — решать только вам.
Я не специалист, но тем не менее не совсем понимаю, зачем нужен весь этот зоопарк кодеков, за которые еще нужно платить отчисления? Тот же Opus (CELT+Silk) открыт, имеет низкую алгоритмическую задержку (пригоден для VoIP) и позволяет кодировать сигнал в весьма неплохом качестве. В чем проблема использовать его по Bluetooth?
Пожалуйста, сделайте возможность «перезаписать» сессию. Чтобы избежать появления сотен вкладок, я использую отдельую сессию для каждой «задачи». В таком режиме можно восстановить сессию, окрыть несколько новых вкладок, закрыть пару старых и захотеть сохранить это состояние в той же сессии. В настоящее время я могу только ввести имя новой сессии при сохранении и если это имя совпадет с уже существующей сессией, к нему будет добавлена цифра. Мне же хочется перезаписать текущую сессию.
Сравните текст в полях ввода Firefox сверху и Vivaldi снизу. То же самое происходит и со шрифтами на самих страницах. То, что в Firefox черное, в chrtomium-based браузерах и electron-приложениях темно серое.
Тут весь вопрос в том, какая именно у вас задача. Если требуется каждый день писать парсер для чего-то нового, конечно вариант готовой либы заруливает все остальное.