Для распознавания можно указать список возможных слов или фраз:
model = Model(model_name="vosk-model-en-us-0.22-lgraph")
trigger_words = ["please enter the number you hear", "please type the numbers you hear"]
numbers = ["one", "two", "three", "four", "five", "six", "seven", "eight", "nine", "zero"]
# You can also specify the possible word or phrase list as JSON list,
# the order doesn't have to be strict
rec = KaldiRecognizer(model,
wf.getframerate(),
f'[{", ".join(map(lambda s: json.dumps(s), trigger_words + numbers))}, "[unk]"]')
while True:
data = wf.readframes(4000)
if len(data) == 0:
break
if rec.AcceptWaveform(data):
print(json.loads(rec.Result())["text"], end=', ')
print(json.loads(rec.FinalResult())["text"])
Так можно избавиться от необходимости подбирать похожие команды
Извиняюсь, непонятно выразился. Да, конечно, pre-commit хук не заменяет проверку CI, а дополняет её, позволяет быстрее обнаружить проблему. Как прогон тестов локально и в CI. А вот когда хук не подходит для flow работы с git, не представляю. Сталкивался с неудобством в Python проекте, когда в существующий проект добавили форматтер, black, в хуки, он форматирует изменённые файлы, а свои изменения отдельно закоммитить сначала - только с --no-verify, потом уже отдельный коммит "Reformat". Но если изначально использовать в проекте, или при добавлении на все файлы прогнать - проблем не должно быть. А конкретно в этом случае, разве может быть нужно только один из изменённых go.mod и go.sum закоммитить?
Так вот и проблема в том, что пиксель в пиксель, и при использовании масштабирования приложение будет выглядеть коряво. Вот как выглядит Java Swing приложение - часть элементов масштабируется, часть нет.
Скриншоты
Большое разрешение с масштабированием, Swing приложение выглядит криво
Большое разрешение без масштабирования, все приложения выглядят одинаково
Разрешение поменьше без масштабирования, все приложения выглядят одинаково
В вашем случае скорее всего все элементы останутся неизменными и будут выглядеть мелко.
Если фонарь достаточно тонкий, можно просто катапультировать пилота «сквозь» него – специальные пробойники помогут креслу пройти через остекление, особенно если им при этом помогает дополнительная система, состоящая из пиротехнических шнуров, наклеенных на стекло и подрываемых в момент катапультирования
В целом соглашусь, но мне однажды подсказало то, что нагуглить не мог довольно долго. Причем оказалось, сделал ту же ошибку, что и я, пытаясь самостоятельно, но после копипасты текста ошибки поправил, а я по этой ошибке тоже разобраться не мог. Но да, это был hello world просто ради эксперимента, собрать LLVM IR в shared library.
Ух, со списками прям пылает, когда поиск есть, но только по одной букве. Вводишь вторую — ищет по ней как по первой.
Ну и например при выборе страны часто любят отсортировать список, но пару наиболее популярных — вверху. Логично, но почему бы по алфавиту не задублировать? Я так United States на Амазоне пару минут искал
Я бы не противопоставлял скачку веб-версии скачке через апи, это разные категории. Тут смотря как качать, конечно, можно через браузер страницы открывать (puppeteer, selenium и т. д.) и разбирать DOM, не работая с api сайта напрямую.
Но при больших объёмах это плохо масштабируется. А если качать без браузера, просто делать http запросы и разбирать респонсы, то и веб версии обычно через апишку качаются. А если нет json api на сайте, то часто и мобильное приложение получает html и отображает через webview. Правда ещё чаще это какой-нибудь мелкий сайт без приложения вообще.
А парсить html регулярками в любом случае не стоит, xpath обычно.
Приложения зачастую защищают от перехвата трафика, не только чтобы парсерам жизнь усложнить, но и для безопасности, если например платежи встроены. Запросы могут подписываться. В общем больше нюансов, чем на сайтах. Это всё обходится, конечно, и в каком-то конкретном случае приложение может быть защищено слабее, чем сайт, но в среднем собирать данные из приложения сложнее. Ну и плюс данные в приложении и на сайте могут отличаться.
Xpath подходит для большинства задач. И, если данные не лежат непосредственно в исходной страничке, а подгружаются скриптами, то делать такие же запросы и парсить json
Для распознавания можно указать список возможных слов или фраз:
Так можно избавиться от необходимости подбирать похожие команды
Тут же про то, что он гуглил скрипты, а не что он хотел сервера гугла удалить
А как тогда другие эмуляторы работают, образы игр в них же не защиты
Не «больше на двадцать-двадцать пять лет», а «больше двадцати-двадцати пяти лет» (на которые и была рассчитана она)
Извиняюсь, непонятно выразился. Да, конечно, pre-commit хук не заменяет проверку CI, а дополняет её, позволяет быстрее обнаружить проблему. Как прогон тестов локально и в CI. А вот когда хук не подходит для flow работы с git, не представляю. Сталкивался с неудобством в Python проекте, когда в существующий проект добавили форматтер, black, в хуки, он форматирует изменённые файлы, а свои изменения отдельно закоммитить сначала - только с --no-verify, потом уже отдельный коммит "Reformat". Но если изначально использовать в проекте, или при добавлении на все файлы прогнать - проблем не должно быть. А конкретно в этом случае, разве может быть нужно только один из изменённых go.mod и go.sum закоммитить?
А ещё можно сделать pre-commit хук, чтобы проблема обнаружилась раньше
Так вот и проблема в том, что пиксель в пиксель, и при использовании масштабирования приложение будет выглядеть коряво. Вот как выглядит Java Swing приложение - часть элементов масштабируется, часть нет.
Скриншоты
В вашем случае скорее всего все элементы останутся неизменными и будут выглядеть мелко.
Как на линуксах с пользовательскими настройками? Ну иконки/темы в пролете, я так понимаю, да и ладно, а что насчёт масштабирования на high DPI?
Насколько я понимаю, "особенно" означает, что это не обязательная опция
Всё-таки не обязательно:
Я правильно понимаю, что на графике «Agile coach» и «Agile Coach» выделены отдельно?
В целом соглашусь, но мне однажды подсказало то, что нагуглить не мог довольно долго. Причем оказалось, сделал ту же ошибку, что и я, пытаясь самостоятельно, но после копипасты текста ошибки поправил, а я по этой ошибке тоже разобраться не мог. Но да, это был hello world просто ради эксперимента, собрать LLVM IR в shared library.
Кажется мне, у вашей "хитрости" слишком высокая вероятность ошибки первого рода
Ух, со списками прям пылает, когда поиск есть, но только по одной букве. Вводишь вторую — ищет по ней как по первой.
Ну и например при выборе страны часто любят отсортировать список, но пару наиболее популярных — вверху. Логично, но почему бы по алфавиту не задублировать? Я так United States на Амазоне пару минут искал
Насколько я понимаю - нет, именно поэтому, когда он словил баг после перезагрузки, то телефон завис на "Pixe is starting".
Это hash в ruby, правда skill_list всё равно невалиден из-за многоточия
Я бы не противопоставлял скачку веб-версии скачке через апи, это разные категории. Тут смотря как качать, конечно, можно через браузер страницы открывать (puppeteer, selenium и т. д.) и разбирать DOM, не работая с api сайта напрямую.
Но при больших объёмах это плохо масштабируется. А если качать без браузера, просто делать http запросы и разбирать респонсы, то и веб версии обычно через апишку качаются. А если нет json api на сайте, то часто и мобильное приложение получает html и отображает через webview. Правда ещё чаще это какой-нибудь мелкий сайт без приложения вообще.
А парсить html регулярками в любом случае не стоит, xpath обычно.
Приложения зачастую защищают от перехвата трафика, не только чтобы парсерам жизнь усложнить, но и для безопасности, если например платежи встроены. Запросы могут подписываться. В общем больше нюансов, чем на сайтах. Это всё обходится, конечно, и в каком-то конкретном случае приложение может быть защищено слабее, чем сайт, но в среднем собирать данные из приложения сложнее. Ну и плюс данные в приложении и на сайте могут отличаться.
Получается, под компиляцией подразумевается только преобразование в объектный код? А что с компиляцией в asm.js/wasm, например?
Xpath подходит для большинства задач. И, если данные не лежат непосредственно в исходной страничке, а подгружаются скриптами, то делать такие же запросы и парсить json