YB
последний кейс должен быть ошибочным
Почему?
Size: a a a
2020 December 06
K
Почему?
потому что я этого и добиваюсь
K
use structopt::clap::ArgGroup;
use structopt::StructOpt;
#[derive(Debug, StructOpt)]
#[structopt(
group = ArgGroup::with_name("verbose"),
group = ArgGroup::with_name("quiet").conflicts_with("verbose"),
)]
struct Opt {
#[structopt(long, group = "verbose")]
verbose: bool,
#[structopt(long, group = "quiet")]
quiet: bool,
}
fn main() {
dbg!(Opt::from_args());
}
Остановился пока вот на таком, но оно падает со stack overflow -_-
отлищно, у ArgGroup есть флажок
multiple, вот так работает:use structopt::clap::ArgGroup;
use structopt::StructOpt;
#[derive(Debug, StructOpt)]
#[structopt(
group = ArgGroup::with_name("verbosity").multiple(false),
)]
struct Opt {
#[structopt(long, group = "verbosity")]
verbose: bool,
#[structopt(long, group = "verbosity")]
quiet: bool,
}
fn main() {
dbg!(Opt::from_args());
}
YB
потому что я этого и добиваюсь
А. Значит, я вопрос не понял. Да, если ты хочешь сделать всё няшно и условно декларативно, то придётся залезть руками в clap, там без вариантов. structopt довольно простой сам по себе.
R
чем обычно делают бродкаст стримов? задача - множество получателей сообщений из синглтона-консьюмера кафки (на rust-rdkafka). показалось что подходят крэйты bus и broadcaster
R
хотя не, broadcaster судя по активности в репозитории, не подойдет
https://github.com/leo60228/broadcaster
https://github.com/leo60228/broadcaster
K
чем обычно делают бродкаст стримов? задача - множество получателей сообщений из синглтона-консьюмера кафки (на rust-rdkafka). показалось что подходят крэйты bus и broadcaster
Не уверен, что это вообще правильный подход — броадкастить сообщения из кафки, когда их можно паралельно читать. Читай велосипедить event-sourcing поверх event-sourcing-а.
Вариант
Вариант
tokio::sync::broadcast, только нужно смотреть по требуемым гарантиямRS
Не уверен, что это вообще правильный подход — броадкастить сообщения из кафки, когда их можно паралельно читать. Читай велосипедить event-sourcing поверх event-sourcing-а.
Вариант
Вариант
tokio::sync::broadcast, только нужно смотреть по требуемым гарантиямэкономиить на десериализации можно
K
ну или crossbeam::chanel как еще один вариант
RS
ну или crossbeam::chanel как еще один вариант
а рингбуферов нет в кросбиме клёвых?
K
экономиить на десериализации можно
ага, в обмен на баги (и вероятно просевший перформанс)
E
подскажите: в tokio::sync::mpsc::channel() есть параметр buffer; по какому принципу значение buffer выбирать?
R
Не уверен, что это вообще правильный подход — броадкастить сообщения из кафки, когда их можно паралельно читать. Читай велосипедить event-sourcing поверх event-sourcing-а.
Вариант
Вариант
tokio::sync::broadcast, только нужно смотреть по требуемым гарантиям> параллельно читать
напрямую из консьюмера? мне показалось что таким образом сообщение получит только один подписчик
напрямую из консьюмера? мне показалось что таким образом сообщение получит только один подписчик
K
подскажите: в tokio::sync::mpsc::channel() есть параметр buffer; по какому принципу значение buffer выбирать?
Методом тыка и прогона на пиковой и/или "странной" нагрузке.
Чем меньше буффер — тем больше шансов, что таски будут ждать пока из него вычитают.
Чем больше буффер — тем сложнее заметить какие-либо траблы с синхронизацией к примеру, ну и сам расход памяти.
Чем меньше буффер — тем больше шансов, что таски будут ждать пока из него вычитают.
Чем больше буффер — тем сложнее заметить какие-либо траблы с синхронизацией к примеру, ну и сам расход памяти.
E
Методом тыка и прогона на пиковой и/или "странной" нагрузке.
Чем меньше буффер — тем больше шансов, что таски будут ждать пока из него вычитают.
Чем больше буффер — тем сложнее заметить какие-либо траблы с синхронизацией к примеру, ну и сам расход памяти.
Чем меньше буффер — тем больше шансов, что таски будут ждать пока из него вычитают.
Чем больше буффер — тем сложнее заметить какие-либо траблы с синхронизацией к примеру, ну и сам расход памяти.
а где об этом написано?
RS
> параллельно читать
напрямую из консьюмера? мне показалось что таким образом сообщение получит только один подписчик
напрямую из консьюмера? мне показалось что таким образом сообщение получит только один подписчик
не, N консумеров с разными консумер-груп-ид можно
K
а где об этом написано?
Возможно где-то в блог постах/статьях в интернетах. Но в целом следует из опыта и фразы:
"The channel will buffer up to the provided number of messages. Once the buffer is full, attempts to send new messages will wait until a message is received from the channel"
"The channel will buffer up to the provided number of messages. Once the buffer is full, attempts to send new messages will wait until a message is received from the channel"
R
не, N консумеров с разными консумер-груп-ид можно
это кажется накладно - создавать нового консьюмера на каждый новый сабскрипшен
E
Возможно где-то в блог постах/статьях в интернетах. Но в целом следует из опыта и фразы:
"The channel will buffer up to the provided number of messages. Once the buffer is full, attempts to send new messages will wait until a message is received from the channel"
"The channel will buffer up to the provided number of messages. Once the buffer is full, attempts to send new messages will wait until a message is received from the channel"
а откуда эта цитата? это в документации ?