Я не знаю, еще не дожил до такого возраста, но кажется что надо как то поскромнее что ли, или упомянули бы других причастных лиц для приличия (а то читаешь и ждешь, что вот-вот появится описание белого плаща...)
Круто. Вспомнился фильм «Адреналин» (с Джейсоном Стэтхэмом который).
А по теме, кажется мне, что возраст вам мешает, было бы 27 — уже бы давно взяли кто-нидь.
DS — дело молодых, имхо.
Я не подготовился, если честно. Да и правда, тяжело выставлять изделие на вид.
Но я давно понял, что «бояться глупо»(с), когда увидел (и сейчас иногда натыкаюсь), что другие выкладывают, и потом еще с пеной у рта защищают.
Вам бы объяснить не мешало этот афоризм. Что имеете ввиду именно вы.
Потому что не все пойдут в первоисточник смотреть толкование.
А поймут как — «твой софт — дерьмо»(с).
Если вы именно это имеете ввиду, обоснуйте тогда.
Понял вас теперь.
Повторять не буду, но уверен, что получится не хуже точно, если разобраться в них.
Здесь смысл этой поделки — не в процессе, не в правильно выбранном фундаменте, не в красоте кода.
Смысл — быстрый результат, что я имею ввиду:
— прочитал эту статью;
— взял с полки;
— быстро накидал скрипт;
— захотелось понять что внутри? — быстро понял как это все работает, потому что рабочий код без определений структур, вспом функций и тп — 300 строк кода (с междустроч пробелами еще, если считать).
— захотелось поправить, или добавить свое — без проблем. Повторю — без проблем, потому что код очень простой: парсинг — это одна функция, которая вызывает себя же рекурсивно, выполнение скрипта — 2 функции, работают в паре, то есть одна из другой вызывается, тоже с рекурсией. Вся рекурсия построена на индексе массива операций, больше никаких связей между вызовами, один индекс. Все, больше там ничего нет.
А теперь представьте, что будет если он будет построен на этих двух (re2c + lemon), бесспорно крутых вещах:
— прочитал эту статью
…
— захотел понять что внутри, чтобы что то изменить. Заглянул внутрь — и припух.
Те, у кого есть время, желание или академ интерес разбираться — сами возьмут re2c или подобное.
Эта вещь для других, для тех кому надо бежать, их основная масса, по моему.
И все что я пишу в опенсорс — для этой категории людей — кому нужен результат быстро, без заморочек. Посмотрите ради интереса остальные мои проекты на гитхабе — они все подобны этому — просты, работают сразу, разбираться долго не надо.
Не, все ок. Это у нас такой менталитет мне кажется (может и не только у нас).
Хабр еще относительно нормальный в этом смысле.
Может это и правильно, надо как то фильтровать поток, а то затопит всяким.., если все будут хлопать и поддерживать любую писанину.
У Дудя помню в его кино про SV, было про это тоже.
Сам столкнулся с необходимостью использования lua только один раз, и то на самом деле можно было обойтись. Не так много ПО, где нужно давать скрипты пользователям.
Для прототипа (быстро накидать, посмотреть, проверить) я бы его взял.
А в практическом плане, наверно, да, соглашусь с вами, что не вариант.
Про asn.1 не слышал.
Дальше баша не смогу прыгнуть точно, потому что на прикладном уровне нахожусь, то есть сложно сделать что-то оригинальное, не изучая теорию, не сравнивая мду собой разные подходы и тд.
Да и времени (желания) особо нет копать глубоко.
Привет.
Побольше бы тех подробностей:
— какие контроллеры,
— как данные от них завели в zabbix,
— какой минимальный цикл опроса датчиков получился. Мне вот думается, что не меньше секунды, поэтому для насосов норм, а для быстродей-х процессов не пойдет.
— до этого ведь была у вас какая-то скада уже (не может быть, чтобы производство без картинки для оператора), чем лучше стало?
— есть промышленные системы мониторинга (типа ibapda), своих денег стоит. Брали на посмотреть? По сравнивали бы…
ну и тд
Как то так бы делал:
Память пусть в потоке камеры остается.
Камера в своем потоке циклически записывает кадры в свой буфер (состоит из структур типа — {frame, flag}) и пишет флаг для каждой позиции — «кадр обновлен».
В рабочем потоке (одном из) бежать по буферу камеры, искать обновленный кадр, его брать себе — копируя в свою память, флаг менять — «кадр взят в работу».
Камера может обновить кадр, только если в этой позиции стоит флаг «взят в работу». Если нет таких, то есть все потоки заняты, то пропускает этот кадр.
В общем — не плохо.
А если конкретную задачу решать — 16 потоков, кадры с камер(ы?),
то я бы ограничился контролем за счетчиком выделенной памяти в каждом потоке, например, так:
const size_t BUFF_SZ = 10000;
vector<byte> buffer(BUFF_SZ);
size_t bufCPos = 0; // в каждом потоке свой буфер, поэтому без atomic
byte* popMem(size_t frameSz){
if (bufCPos + frameSz > BUFF_SZ){
return nullptr; // памяти не хватает - пропускаем кадр
}
bufCPos += frameSz;
return buffer.data() + (bufCPos - frameSz);
}
void pushMem(size_t frameSz){
bufCPos -= frameSz;
}
Выделение-освобождение памяти это ведь операция, над которой хотелось бы не задумываться (в идеале), поэтому… из преимуществ остается только первое, но его можно добиться и проще (и то стоит заморачиваться, только если это действительно нужно).
По моему вы зациклились на этих плюсах.
В жизни много других вещей. У меня в 29 лет была уже жена, дочь 5 лет и ипотека. Плюсы тоже были и сейчас есть, только на 5м месте, наверно.
Про себя опять — я вот хочу на питон перелезть со временем, потому что там тупо проще.
"Фатальных недостатков" не вижу уже давно ни в чем, можно пользоваться любыми инструментами, считаю.
Хочется успеть сделать что-то стоящее, пока к сожалению только карикатуры получаются, ничего оригинального.
Вот бы!
А по теме, кажется мне, что возраст вам мешает, было бы 27 — уже бы давно взяли кто-нидь.
DS — дело молодых, имхо.
Но я давно понял, что «бояться глупо»(с), когда увидел (и сейчас иногда натыкаюсь), что другие выкладывают, и потом еще с пеной у рта защищают.
Потому что не все пойдут в первоисточник смотреть толкование.
А поймут как — «твой софт — дерьмо»(с).
Если вы именно это имеете ввиду, обоснуйте тогда.
Повторять не буду, но уверен, что получится не хуже точно, если разобраться в них.
Здесь смысл этой поделки — не в процессе, не в правильно выбранном фундаменте, не в красоте кода.
Смысл — быстрый результат, что я имею ввиду:
— прочитал эту статью;
— взял с полки;
— быстро накидал скрипт;
— захотелось понять что внутри? — быстро понял как это все работает, потому что рабочий код без определений структур, вспом функций и тп — 300 строк кода (с междустроч пробелами еще, если считать).
— захотелось поправить, или добавить свое — без проблем. Повторю — без проблем, потому что код очень простой: парсинг — это одна функция, которая вызывает себя же рекурсивно, выполнение скрипта — 2 функции, работают в паре, то есть одна из другой вызывается, тоже с рекурсией. Вся рекурсия построена на индексе массива операций, больше никаких связей между вызовами, один индекс. Все, больше там ничего нет.
А теперь представьте, что будет если он будет построен на этих двух (re2c + lemon), бесспорно крутых вещах:
— прочитал эту статью
…
— захотел понять что внутри, чтобы что то изменить. Заглянул внутрь — и припух.
Те, у кого есть время, желание или академ интерес разбираться — сами возьмут re2c или подобное.
Эта вещь для других, для тех кому надо бежать, их основная масса, по моему.
И все что я пишу в опенсорс — для этой категории людей — кому нужен результат быстро, без заморочек. Посмотрите ради интереса остальные мои проекты на гитхабе — они все подобны этому — просты, работают сразу, разбираться долго не надо.
Хабр еще относительно нормальный в этом смысле.
Может это и правильно, надо как то фильтровать поток, а то затопит всяким.., если все будут хлопать и поддерживать любую писанину.
У Дудя помню в его кино про SV, было про это тоже.
Для прототипа (быстро накидать, посмотреть, проверить) я бы его взял.
А в практическом плане, наверно, да, соглашусь с вами, что не вариант.
Дальше баша не смогу прыгнуть точно, потому что на прикладном уровне нахожусь, то есть сложно сделать что-то оригинальное, не изучая теорию, не сравнивая мду собой разные подходы и тд.
Да и времени (желания) особо нет копать глубоко.
Себя для объективности не забывайте (проеб-ся лишних 2 дня — какой ты нах лид — в сторону!)
Побольше бы тех подробностей:
— какие контроллеры,
— как данные от них завели в zabbix,
— какой минимальный цикл опроса датчиков получился. Мне вот думается, что не меньше секунды, поэтому для насосов норм, а для быстродей-х процессов не пойдет.
— до этого ведь была у вас какая-то скада уже (не может быть, чтобы производство без картинки для оператора), чем лучше стало?
— есть промышленные системы мониторинга (типа ibapda), своих денег стоит. Брали на посмотреть? По сравнивали бы…
ну и тд
Память пусть в потоке камеры остается.
Камера в своем потоке циклически записывает кадры в свой буфер (состоит из структур типа — {frame, flag}) и пишет флаг для каждой позиции — «кадр обновлен».
В рабочем потоке (одном из) бежать по буферу камеры, искать обновленный кадр, его брать себе — копируя в свою память, флаг менять — «кадр взят в работу».
Камера может обновить кадр, только если в этой позиции стоит флаг «взят в работу». Если нет таких, то есть все потоки заняты, то пропускает этот кадр.
А если конкретную задачу решать — 16 потоков, кадры с камер(ы?),
то я бы ограничился контролем за счетчиком выделенной памяти в каждом потоке, например, так:
Выделение-освобождение памяти это ведь операция, над которой хотелось бы не задумываться (в идеале), поэтому… из преимуществ остается только первое, но его можно добиться и проще (и то стоит заморачиваться, только если это действительно нужно).
В жизни много других вещей. У меня в 29 лет была уже жена, дочь 5 лет и ипотека. Плюсы тоже были и сейчас есть, только на 5м месте, наверно.
Про себя опять — я вот хочу на питон перелезть со временем, потому что там тупо проще.