Хорошее замечание. Тоже об этом думал. Но давайе по порядку…
У GDB нет REPL, это скорее консоль для исполнения уже встроенных команд и откомпилированных команд программы. Может интерпретровать простые констуркции С но и только.
Проблематично вызывать ф-ции из программы, а допустим иницилизировать структуры и классы и передавать их в аргументы это будет жуткая боль.
Скрипты и расширения на python отчасти спасают, но всеравно читаемость и масштабируемость будет хромать.
Во второй части будет наглядный пример, как все довольно просто работать будет. В этой статье мы всего лишь готовим инструмент для этого.
Можно и так, но тут считай сравнивать теплое с мягким.
Потому как предназначения разные. Виртуальные машины / интерпретаторы на МК, могут исполнять скрипты автономно и вполне могут использоваться в продакшене. Но там мы упираемся в ограничение ресурсов МК, необходимость портирования вирутальной машины / интерпретатора, а так же еще написание библиотек переферии.
В моем подходе программы/скрипты не могут исполняться автономно, но нам доступны все ресурсы нашего хостового ПК, все виды библиотек и все виды языков программирования. При этом при использовании С/С++ можно использовать стандартные библиотеки от производителя для работы с переферией.
Было бы интересно, если приведете в статье какие-нить нетривиальные примеры.
Потому что в статьях про property based testing обычно рассматривается банальщина с числами и строками.
Да видел, что перевод. Это немного риторическое высказывание было)
и поэтому что-либо типа инструмента PIN не подходит для наших целей.
вот здесь автор как раз упомянул его, но дальше, к сожалению не стал сравнивать.
Хотя на самом деле правильно производительность мерить, не менее простая задача.
P.S. скоро как раз будет статья про Pintool.
Очень интересную задачу рассмотрели. Жалко только с Pintool не сравнили производительность. Мне почему то кажется что оверхед не такой большой получится. Причем скорее всего на большом проекте прием с llvm будет проигрывать в памяти, за счет раздувания программы из-за вставок.
У GDB нет REPL, это скорее консоль для исполнения уже встроенных команд и откомпилированных команд программы. Может интерпретровать простые констуркции С но и только.
Проблематично вызывать ф-ции из программы, а допустим иницилизировать структуры и классы и передавать их в аргументы это будет жуткая боль.
Скрипты и расширения на python отчасти спасают, но всеравно читаемость и масштабируемость будет хромать.
Во второй части будет наглядный пример, как все довольно просто работать будет. В этой статье мы всего лишь готовим инструмент для этого.
Потому как предназначения разные. Виртуальные машины / интерпретаторы на МК, могут исполнять скрипты автономно и вполне могут использоваться в продакшене. Но там мы упираемся в ограничение ресурсов МК, необходимость портирования вирутальной машины / интерпретатора, а так же еще написание библиотек переферии.
В моем подходе программы/скрипты не могут исполняться автономно, но нам доступны все ресурсы нашего хостового ПК, все виды библиотек и все виды языков программирования. При этом при использовании С/С++ можно использовать стандартные библиотеки от производителя для работы с переферией.
И это при том что для модуля нижняя -25 °C
но и сам модуль по верхней границе в +85 °C не влезает, не говоря уже о каком-то запасе.
Но вот вибрация и температура, это под большим вопросом.
А можно пруф где сказано что он удовлетворяет хотя бы температурам. На сайте не нашел подтверждения этому.
Потому что в статьях про property based testing обычно рассматривается банальщина с числами и строками.
вот здесь автор как раз упомянул его, но дальше, к сожалению не стал сравнивать.
Хотя на самом деле правильно производительность мерить, не менее простая задача.
P.S. скоро как раз будет статья про Pintool.
На OpenWrt или Raspberry?
Обычную Windows ПК использовать как ПЛК?