Ну например ASR PRO и аналоги. ИМХО: ошибки должны вы проверять и составлять доки о том, почему у вас решение так, а не иначе (ну если хотите выглядеть честно перед потребителями). Что касается стоимости, то АЛИСА очень переоценена и ваши хозяева зарабатывают не малые деньги на ней. Как на железке, так и на подписках. Так что чип, который в розницу 300-500р можно списать на расходы. А по факту, дешевое баловство, уважаемый практик;) Вы хоть отвалы Matter бриджей исправьте, раз уж вы в IOT влезли;)
Я думаю, что можно было бы использовать готовые чипы для распознавания двух активационный слов. Тогда бы было честное аппаратное отключение микрофона. В таком режиме время обработки команды активации составило бы 30-50 мс
ИМХО: ни один "контекст" не спасет от ошибок нейронок. Рано или поздно она ошибётся. Пусть это будет не сразу. Но, например, это случится после 200-500k токенов, либо после сжатия. Это будет 100%. Необходимо использовать ограниченные инструменты-навыки. Кому интересно, можете глянуть мой проект в профиле...
Да, я считаю, что программист должен напрягаться больше конечного пользователя. Если в функции аргументом указан тип A, то и переменную необходимо передавать этого типа, а не другого. Если в документации нет, достаточно посмотреть на константы и объявленные переменные. Что касается "нормальной" документации, то это ошибки разработчика библиотеки, а не какого-то конкретного ЯП. Во поводу "тайпкастить" (ну и словечко) ошибки: посмотрите например на функционал errors.Is и errors.As. Видно, что вы даже не пытались разобраться в теме. Ну и на последок:
fn load_block_constants(&mut self, hash_header: &[u8; 72], target: &[u64; 4]) {
let mut hash_header_gpu = self._module.get_global::<[u8; 72]>(&CString::new("hash_header").unwrap())
.map_err(|e| {
error!("Failed to get global 'hash_header': {}", e);
Error::from(e.to_string())
}).unwrap();
hash_header_gpu.copy_from(hash_header).map_err(|e| {
error!("Failed to copy hash_header: {}", e);
Error::from(e.to_string())
}).unwrap();
let mut target_gpu = self._module.get_global::<[u64; 4]>(&CString::new("target").unwrap())
.map_err(|e| {
error!("Failed to get global 'target': {}", e);
Error::from(e.to_string())
}).unwrap();
target_gpu.copy_from(target).map_err(|e| {
error!("Failed to copy target: {}", e);
Error::from(e.to_string())
}).unwrap();
}
Начнем с того, что автор подменяет понятия. Ребята, вы не "пользователи" библиотеки, вы программисты. ИМХО: Да, надо просматривать чужие пакеты/библиотеки, что бы в продакшн не было сюрпризов. Что касается enum, передача int вместо константы, это ошибка программиста, а не пользователя. Далее не понятно утверждение автора о том, что в Go нет типизированных ошибок. Судя по коду проверки, автор даже не пытался разобраться. Во многих случаях автор статьи указывает на проблемы с копипастой, а это уже человеческий фактор, а не ошибки ЯП. Так же автор возмущается тем, что в Go нельзя использовать синтаксический сахар и приходится проверять переменную ошибки, в тоже время пишет, что для одного канала необходимо возвращать две переменных. Вся статья, по сути, основана на привычках автора, а не особенностях языка. А, как говорится, на вкус и цвет, фломастеры разные. Есть в Go моменты, которые и мне не нравятся. Например, серилизация структур из-за выравнивания в памяти. Но утверждать, что Go не подходит для больших проектов... Вы все дружно пользуетесь докерами, кубиками и т.д. Что-то пока не видел потенциальной замены на Rust
Особенно когда автор и, судя по всему, большинство комментаторов не умеют в Go;) ИМХО: статья о том, что прежде чем браться за работу, нужно изучать матчасть. Я, например, не умею Rust, мне не понятен его синтаксис. Хотя приходилось пару раз править код на Rust и Elixir. Но я не пишу, что это "убогий" язык;)
Ну например ASR PRO и аналоги. ИМХО: ошибки должны вы проверять и составлять доки о том, почему у вас решение так, а не иначе (ну если хотите выглядеть честно перед потребителями). Что касается стоимости, то АЛИСА очень переоценена и ваши хозяева зарабатывают не малые деньги на ней. Как на железке, так и на подписках. Так что чип, который в розницу 300-500р можно списать на расходы. А по факту, дешевое баловство, уважаемый практик;) Вы хоть отвалы Matter бриджей исправьте, раз уж вы в IOT влезли;)
Я думаю, что можно было бы использовать готовые чипы для распознавания двух активационный слов. Тогда бы было честное аппаратное отключение микрофона. В таком режиме время обработки команды активации составило бы 30-50 мс
А подскажите, как в логи попадает "Алиса" или "Яндекс" если писали, что активация передачи данных происходит ПОСЛЕ произнесения этой команды?
Получается, что логируется все, произнесённое рядом с колонкой?
ИМХО: ни один "контекст" не спасет от ошибок нейронок. Рано или поздно она ошибётся. Пусть это будет не сразу. Но, например, это случится после 200-500k токенов, либо после сжатия. Это будет 100%. Необходимо использовать ограниченные инструменты-навыки. Кому интересно, можете глянуть мой проект в профиле...
Из семейства qwen для кода Qwen3.5-27B попробуй. ИМХО: значительно лучше работает, чем Qwen3-Coder-Next.
Вы оказываете услуги хостинга. Человек вам предъявил чеки оплаты ваших услуг. А кто там владеет доменом, дело десятое...
Да, я считаю, что программист должен напрягаться больше конечного пользователя. Если в функции аргументом указан тип A, то и переменную необходимо передавать этого типа, а не другого. Если в документации нет, достаточно посмотреть на константы и объявленные переменные. Что касается "нормальной" документации, то это ошибки разработчика библиотеки, а не какого-то конкретного ЯП. Во поводу "тайпкастить" (ну и словечко) ошибки: посмотрите например на функционал errors.Is и errors.As. Видно, что вы даже не пытались разобраться в теме. Ну и на последок:
Как тут кастуются ошибки?
Начнем с того, что автор подменяет понятия. Ребята, вы не "пользователи" библиотеки, вы программисты. ИМХО: Да, надо просматривать чужие пакеты/библиотеки, что бы в продакшн не было сюрпризов. Что касается enum, передача int вместо константы, это ошибка программиста, а не пользователя. Далее не понятно утверждение автора о том, что в Go нет типизированных ошибок. Судя по коду проверки, автор даже не пытался разобраться. Во многих случаях автор статьи указывает на проблемы с копипастой, а это уже человеческий фактор, а не ошибки ЯП. Так же автор возмущается тем, что в Go нельзя использовать синтаксический сахар и приходится проверять переменную ошибки, в тоже время пишет, что для одного канала необходимо возвращать две переменных. Вся статья, по сути, основана на привычках автора, а не особенностях языка. А, как говорится, на вкус и цвет, фломастеры разные. Есть в Go моменты, которые и мне не нравятся. Например, серилизация структур из-за выравнивания в памяти. Но утверждать, что Go не подходит для больших проектов... Вы все дружно пользуетесь докерами, кубиками и т.д. Что-то пока не видел потенциальной замены на Rust
Особенно когда автор и, судя по всему, большинство комментаторов не умеют в Go;) ИМХО: статья о том, что прежде чем браться за работу, нужно изучать матчасть. Я, например, не умею Rust, мне не понятен его синтаксис. Хотя приходилось пару раз править код на Rust и Elixir. Но я не пишу, что это "убогий" язык;)
Заголовочек поправьте. Архитектура не соответствует;)