>> Если я правильно понимаю, make был сделан для C/C++ и в основном работает с ними.
Нет. Это универсальная система, не привязанная к языкам. Есть совершенно разные проекты, которые собираются при помощи make. Триада «configure && make && make install» это очень древняя вещь ) Но т.к. make действительно уже старенький, новые проекты уже строят на чём-то более современном… cmake в частности.
>> Скажите, как можно сделать проверку выполнения цели в make?
Ну может я не совсем понимаю Вашу задачу. make — более рассчитан на присутствие или отсутствие файлов, атрибуты их изменения. Соответственно ваши «цели» должны что-то такое «производить» в виде файлов, чтобы можно было понять
что уже всё есть. Ну например пусть будет проверка установлен ли паке mypack в системе
В этом примере при команде make all пакет установится только первый раз,
т.к. в случае успеха будет создан файл mypack.dep, то при повторном make, эта команда не будет исполнена. Как-то так (я не очень большой специалист в make).
P.S. Это примитивный пример, make позволяет делать более сложные и иерархичные вещи. Его цель «управление зависимостями» сборки.
М-м… ну вообще-то он даже синтаксисом на ваше решение похож :)
Конечно в плане проверки «установлен ли пакет»… надо самому правило написать,
но make более масштабная вещь, в каком-то смысле это не его уровень.
Для автоматизации развёртывания это как раз ansible со товарищи…
Так что Вы зря про «точно нет»…
P.S. Просто он наиболее близок к bash, как я понял Вам это удобно. Все цели
это по сути bash команды.
Эх… хотелось проще. В Virtualbox это буквально одной галочкой. Но в любом случае спасибо за участие и за статью :)
Присоединяюсь к голосам за продолжение про overlay.
Проблема как раз в том, что для моего сценария нужно чтобы была возможно иметь одинаковые ip.
Есть разрабатываемая (встраиваемая) система из нескольких узлов, у неё внутри относительно жёстко вшитые ip. Хотелось иметь возможность запускать для тестирования несколько таких систем на одном тестовом стенде.
Сейчас для этого используется vagrant+virtualbox. Хотелось двинуть в сторону docker со всеми его плюшками.
Но вот застряли. И не совсем ясно куда «копать». Возможно ли это принципиально с docker или нет.
Может ли тут помочь Open vSwitch + vlan-ы?
Можно ли в docker сделать изолированную виртуальную сеть между группой контейнеров как в VirtualBox?
Т.е. чтобы можно было запустить две и более таких групп контейнеров с одинаковыми ip, и соответственно
эти сети друг-другу бы не мешали.
Да. Согласен. Значит всё-таки решение задачи ложных или повторных срабатываний таймера остаётся разработчику. Что в целом тоже нормально…
Надёжный код, должен подразумевать обработку и таких ситуаций.
P.S. Даже std::condition_variable могут ложно просыпаться, чего уж… :)
>> К сожалению, я не понял идею такого API :(
Ну, в целом Вы ответили, что всё уже реализовано )
Идея была добавить поддержку ID в самом API SO, чтобы каждому разработчику не приходилось это делать самостоятельно. Например как ещё один параметр (не обязательный)
so_5::timer_id_t timer = so_5::send_periodic<msg,TYPEID>(*this,
std::chrono::milliseconds(250),
std::chrono::milliseconds::zero(),
myID // <-- здесь передаём свой ID, который потом придёт к нам в обработчике
);
...
А проблема неточности таймеров, это да. Надёжный способ, требует сложной реализации. Я просто считал, что [T-d1, T+d2] входит в документированную погрешность, которую нужно учитывать. Разве что, думал, что по таймерам есть гарантия «сработает НЕ РАНЬШЕ заданного времени»(т.е. доставка будет только в момент >=T). При этом, конечно остаётся проблема отмены таймера, когда сообщение уже в очереди, но не обработано. Но с другой стороны, если гарантировано помещение в очередь для >=T, то значит отмена таймера (в момент >=T) фактически происходит когда таймер уже сработал и честно ждёт обработки в очереди.
Так может сделать встроенную возможность (на уровне SO) задавать таймерам идентификаторы (при формировании таймера)? И соответственно, возможность запустить, перезапустить или остановить таймер с указанным ID (в качестве ID выступает просто число, а разработчик сам решает как он их назначает и различает).
Тогда для данного случая, можно было бы не заботится о том, что такой таймер уже есть, т.к. при начале обработки очередного сообщения достаточно было бы «перезапустить» таймер с определённым ID. Если такого в очереди ещё не было, он появляется. Если уже есть, начинает отсчёт заново. Если перешли в состояние st_wait_perform, отключаем таймер.
А если он таки сработал (вызван обработчик), значит действительно «зависли в обработке».
С одной стороны, это снижает некоторую универсальность механизмов работы с сообщениями, т.к. выделяет отдельное понятие таймеры со своим API. С другой стороны, я так понял всё-равно для работы с таймерами, уже есть свой отдельный API.
Частично ответил ниже…
Но в целом, XML был выбран по историческим причинам (с ним уже давно велась работа во всех проектах), поэтому тянуть в проект ещё один формат было излишне. А поскольку велосипед «внутренний» то и «заказа» на другой формат пока не поступало :)
>> Требовать от пользователя писать код тестов на XML — это довольно-таки жестоко.
:) На самом деле (на практике) писать xml не составляет труда, особенно когда у Вас уже будут наработанные шаблоны. Но и писать сценарий в виде xml не обязательно. Это вопрос решаемый.
Либо пишется свой «плеер», либо вариант конвертера из своего формата в xml-ку.
У меня даже была проба второго варианта Упрощённый синтаксис
Думаю после прочтения второй части статьи будет более полная картина.
P.S. Robot Framework обязательно поизучаю. Интересно…
Возможно тогда Вам будет интересно взглянуть на libuniset2.
Тут как раз немного обратная ситуация. Нету графического движка и IDE, но цель та же — ,
чисто C++ная библиотека для создания АСУ.
Нет, в данном случае, "около 12000" — имеется ввиду, все датчики используемые в проекте. Т.е. это число включает в себя, не только то, что получается от ModbusSlave устройств, но и от других систем с которыми ведётся взаимодействие, а также, датчики которые необходимы для внутреннего функционирования алгоритмов. Поэтому ModbusSlave устройства в данном случае — вполне обычные, с разным количеством регистров (от 20 до 80).
что имеется ввиду под 'синхронизация состояния всех датчиков'?
В давней статье были приведены "типичные структуры системы на базе uniset". Смысл в том, что на каждом контроллере запускается своя "SharedMemory" в которой "зарегистрированы" ВСЕ датчики (со всех узлов в сети). Т.е. алгоритмы запущенные на том или ином контроллере всегда имеют доступ ко всем датчикам в системе, независимо от того, где эти датчики находятся. Поэтому стоит задача синхронизировать состояние всех SM между собой. Этим занимаются процессы сетевого обмена (могут быть разные протоколы), запускаемые на каждом узле. Их задача, посылать в сеть информацию которая формируется на данном узле (взять из SM послать в сеть) и принимать информацию от других узлов (процессов обмена), сохраняя её в SM. В результате, с задержкой на сетевой обмен, на каждом узле SM содержит всю актуальную информацию по всей системе. Это и называется в данном случае "синхронизация состояния всех датчиков". Т.е. обеспечение того, чтобы на всех узлах SM содержала одинаковое, актуальное текущее состояние датчиков. При этом по сути уже не важно где запускать алгоритм управления (в целом они даже могу динамически мигрировать с узла на узел если надо), потому-что на любом узле "всё есть".
Вам главное понять, что ansible и make не взаимоисключающие вещи )
Нет. Это универсальная система, не привязанная к языкам. Есть совершенно разные проекты, которые собираются при помощи make. Триада «configure && make && make install» это очень древняя вещь ) Но т.к. make действительно уже старенький, новые проекты уже строят на чём-то более современном… cmake в частности.
>> Скажите, как можно сделать проверку выполнения цели в make?
Ну может я не совсем понимаю Вашу задачу. make — более рассчитан на присутствие или отсутствие файлов, атрибуты их изменения. Соответственно ваши «цели» должны что-то такое «производить» в виде файлов, чтобы можно было понять
что уже всё есть. Ну например пусть будет проверка установлен ли паке mypack в системе
В этом примере при команде make all пакет установится только первый раз,
т.к. в случае успеха будет создан файл mypack.dep, то при повторном make, эта команда не будет исполнена. Как-то так (я не очень большой специалист в make).
P.S. Это примитивный пример, make позволяет делать более сложные и иерархичные вещи. Его цель «управление зависимостями» сборки.
Конечно в плане проверки «установлен ли пакет»… надо самому правило написать,
но make более масштабная вещь, в каком-то смысле это не его уровень.
Для автоматизации развёртывания это как раз ansible со товарищи…
Так что Вы зря про «точно нет»…
P.S. Просто он наиболее близок к bash, как я понял Вам это удобно. Все цели
это по сути bash команды.
Присоединяюсь к голосам за продолжение про overlay.
Есть разрабатываемая (встраиваемая) система из нескольких узлов, у неё внутри относительно жёстко вшитые ip. Хотелось иметь возможность запускать для тестирования несколько таких систем на одном тестовом стенде.
Сейчас для этого используется vagrant+virtualbox. Хотелось двинуть в сторону docker со всеми его плюшками.
Но вот застряли. И не совсем ясно куда «копать». Возможно ли это принципиально с docker или нет.
Может ли тут помочь Open vSwitch + vlan-ы?
Т.е. чтобы можно было запустить две и более таких групп контейнеров с одинаковыми ip, и соответственно
эти сети друг-другу бы не мешали.
Можно хотя бы сюда зайти http://www.softcraft.ru/auto/switch/aptech/
Ну или совсем кратко: https://ru.wikipedia.org/wiki/Switch-технология
Надёжный код, должен подразумевать обработку и таких ситуаций.
P.S. Даже std::condition_variable могут ложно просыпаться, чего уж… :)
Ну, в целом Вы ответили, что всё уже реализовано )
Идея была добавить поддержку ID в самом API SO, чтобы каждому разработчику не приходилось это делать самостоятельно. Например как ещё один параметр (не обязательный)
А проблема неточности таймеров, это да. Надёжный способ, требует сложной реализации. Я просто считал, что [T-d1, T+d2] входит в документированную погрешность, которую нужно учитывать. Разве что, думал, что по таймерам есть гарантия «сработает НЕ РАНЬШЕ заданного времени»(т.е. доставка будет только в момент >=T). При этом, конечно остаётся проблема отмены таймера, когда сообщение уже в очереди, но не обработано. Но с другой стороны, если гарантировано помещение в очередь для >=T, то значит отмена таймера (в момент >=T) фактически происходит когда таймер уже сработал и честно ждёт обработки в очереди.
Тогда для данного случая, можно было бы не заботится о том, что такой таймер уже есть, т.к. при начале обработки очередного сообщения достаточно было бы «перезапустить» таймер с определённым ID. Если такого в очереди ещё не было, он появляется. Если уже есть, начинает отсчёт заново. Если перешли в состояние st_wait_perform, отключаем таймер.
А если он таки сработал (вызван обработчик), значит действительно «зависли в обработке».
С одной стороны, это снижает некоторую универсальность механизмов работы с сообщениями, т.к. выделяет отдельное понятие таймеры со своим API. С другой стороны, я так понял всё-равно для работы с таймерами, уже есть свой отдельный API.
Но в целом, XML был выбран по историческим причинам (с ним уже давно велась работа во всех проектах), поэтому тянуть в проект ещё один формат было излишне. А поскольку велосипед «внутренний» то и «заказа» на другой формат пока не поступало :)
:) На самом деле (на практике) писать xml не составляет труда, особенно когда у Вас уже будут наработанные шаблоны. Но и писать сценарий в виде xml не обязательно. Это вопрос решаемый.
Либо пишется свой «плеер», либо вариант конвертера из своего формата в xml-ку.
У меня даже была проба второго варианта Упрощённый синтаксис
Думаю после прочтения второй части статьи будет более полная картина.
P.S. Robot Framework обязательно поизучаю. Интересно…
Тут как раз немного обратная ситуация. Нету графического движка и IDE, но цель та же — ,
чисто C++ная библиотека для создания АСУ.
Нет, в данном случае, "около 12000" — имеется ввиду, все датчики используемые в проекте. Т.е. это число включает в себя, не только то, что получается от ModbusSlave устройств, но и от других систем с которыми ведётся взаимодействие, а также, датчики которые необходимы для внутреннего функционирования алгоритмов. Поэтому ModbusSlave устройства в данном случае — вполне обычные, с разным количеством регистров (от 20 до 80).
В давней статье были приведены "типичные структуры системы на базе uniset". Смысл в том, что на каждом контроллере запускается своя "SharedMemory" в которой "зарегистрированы" ВСЕ датчики (со всех узлов в сети). Т.е. алгоритмы запущенные на том или ином контроллере всегда имеют доступ ко всем датчикам в системе, независимо от того, где эти датчики находятся. Поэтому стоит задача синхронизировать состояние всех SM между собой. Этим занимаются процессы сетевого обмена (могут быть разные протоколы), запускаемые на каждом узле. Их задача, посылать в сеть информацию которая формируется на данном узле (взять из SM послать в сеть) и принимать информацию от других узлов (процессов обмена), сохраняя её в SM. В результате, с задержкой на сетевой обмен, на каждом узле SM содержит всю актуальную информацию по всей системе. Это и называется в данном случае "синхронизация состояния всех датчиков". Т.е. обеспечение того, чтобы на всех узлах SM содержала одинаковое, актуальное текущее состояние датчиков. При этом по сути уже не важно где запускать алгоритм управления (в целом они даже могу динамически мигрировать с узла на узел если надо), потому-что на любом узле "всё есть".