Т.е. есть программа на Qt/C++ и мы хотим её протестировать.
Нам нужно понажимать кнопки, повызывать менюшки и т.д. и мы хотим написать
эти сценарии тестирования на интерпретируемом языке, допутим мы выбираем питон.
Во-первых нужно всроить интерпретатор питона в C++ программу,
Во-вторых нужно проделать все то что описано в статье.
Т.е. нужно проделать дополнительуню работу по сравнению с тем, что уже сделано,
в чем будет выгода от использования PyQt и причем здесь pytest который для unit тестов?
А можете пояснить для новичка в Go, почему если нужна скорость не проверяли gccgo, насколько он усокряет код, а также не использовали встроенный в него
профилирофшик (gprof)?
Нет, альфа версия Qt Monkey появилась в 2008 году, тогда Qе Webdriver не было в opensource, а может не было вообще (судя по первому коммиту в 2013).
Надо будет посмотреть.
Однако, во всем этом есть одно больше но — QtScript объявлен deprecated начиная с Qt 5.5 Работать оно конечно еще будет, но сколько времени не очень понятно.
Ведь в gcc (начиная с 4.9) можно указывать флаги оптимизации и target опции для куска исходного кода
с помощью `pragma`, а также можно указывать эти флаги для каждой функции отедльно, например так `static void calculate_sse(float *data, float scale, int size ) __attribute__ ((__target__ («no-avx»)));`
подробности можно найти здесь:
Linux, правда конечно от boost spirit другого сложно ожидать в плане времени компиляции.
>но там было дело далеко не в заголовках и вовсе не факт, что модули сделали бы компиляцию заметно >быстрее
>всё это метопрограммирование — тяжёлая задача для компилятора
Не согласен, да время компиляции одного объектного файла модули не изменят,
но мы же говорим о сборке проекта целиком и вот тут как раз модули помогут,
т.к.
>всё это метопрограммирование — тяжёлая задача для компилятора
и поэтому решать ее несколько раз это полный бред.
Решил один раз загрузив CPU на 100% и отъев несколько гигабайт RAM, так закэшируй результат.
Те же 10 секунд превращаются в 2 секунды, когда засунешь boost includes в отдельный header
файл и превратишь его в precompiled.
>Подключил ccache и сборка сильно не беспокоит, а вот stack trace для ARM, x86, x86-64 мне куда полезнее.
И как помогает ccache разработчику? Человеку, который отвечает за дистрибутив да, но современные
системы сборки и так собирают только измененные файлы, или имеется ввиду распределенный для нескольких разработчиков ccache или случай сборки сильно различающихся веток одного проекта?
При этом также следует учесть, что даже перекомпиляция одного файла используещего буст (без precompiled header) вполне может 10 секунд занимать на не слабом железе (i7/16 GB RAM/SSD),
конечно кэширование объектный файлов (ccache)
и распределение сборки по кластеру (distcc) в какой-то мере спасают положение, но не до конца.
У каждого из них есть свои недостатки, кэширование слабо поможет если изменение вызывает перекомпиляцию
нескольких файлов, а dictcc не вариант если расходы на передачу input/output компилятора по сети сравнимы
с временем компиляции.
>stack trace для ARM, x86, x86-64 мне куда полезнее
ИМХО, stacktrace вполне можно реализовать в виде общего интерфейса плюс реализация
для каждого компилятора/runtime, конечно удобно было иметь это в std::, но проблема решается,
а вот для времени компиляции одни костыли, проблему даже на 50% не решающие.
ИМХО, у людей работающих долго над чем-то, что не взлетает обычно
хорошо прокачено искуство объяснять как все сложно, но при этом
свежий вгляд от тех кто не испугался бывает им очень полезен.
>Вам может приглянуться эта библиотечка.
У меня уже есть решение основанное на парсинге с помощью libclang определения структур и
генерации метаинформации для работы с полями стуктуры в runtime.
ИМХО конечно, но в вашей библиотеке ведь даже название поля нельзя получить? Для сериализации
в json/xml это важно.
И почему среди кучи разных сугубо специфических вещей не упоминается
то, что вызывает раздражение у каждого C++ программиста каждый божий день?
А именно — скорость компиляции. Бедный компилятор снова и снова парсит мегабайты
исходников. При этом существующие полуавтоматические решения для использования precompiled headers
вызывают еще большее раздражение, особенно в кросплатформенных проектах.
И главное и proposal есть для модулей, но конечно не в c++17, ведь сферические функции важнее.
Может стоит все-таки за модули побороться, а stack trace подождет?
>доступ к полям структур по индексу и базовая рефлексия.
Вот за это плюс один, использовать парсер C++ или дублировать код для рефлексии
по-моему через чур.
1)Про «новое» API. Под новым API подрузумевается splice,vmsplice,openat,name_to_handle_at,open_by_handle_at и т.д. С примерами, почему без этого API жить было больше нельзя, и насколько программы с его использованием могут стать быстрее.
2)Про оптимальные стратегии использования API Linux для конкретных примеров, например что стоит использовать для передачи маленького файла по сети, что для больших файлов, как наиболее быстро работать с тысячими соединений и т.д. на примере каких-нибудь nginx, haproxy.
Т.е. ценно на мой взгляд не сбор справочника всех доступных функций, а когда и как предполагается использовать эти функции для решения конкретных задач.
Планирутеся ли включить поддержку LDAP, хотя бы в виде плагина,
в «mainline»? На мой взгляд довольно востребованная возможность — авторизация через LDAP, а существующий сторонний плагин довольно неудобно деплоить.
а может и третью функцию добавите, типа `right_answer(word, answer)`
будет вызываться после test(word) и давать обратную связь алгоритму, чтобы он доплнительно обучался во время теста?
Я думаю здесь стоит упоминуть garbage collection которую сделали/делают в blink (движке chrome): www.chromium.org/blink/blink-gc
Как я понимаю в основном это решение проблемы того, что C++ объекты отображаются в язык со сборкой мусора — javascript и поэтому хорошо бы этому сборщику мусора помочь со стороный C++.
А зачем он вообще нужен (не важно в виде готовой железки или ПО)? Что помешает провайдеру организовать специально для «Ревизора» имитацию работы «железного занавеса»? Правильнее было бы договориться с Microsoft, чтобы «Ревизор» пришел в виде обновления на случайные компьютеры по всей стране. Здесь и деньги можно отмыть на разработке сервиса «Ревизор» для Windows и действительно мониторить как работают провайдеры.
Т.е. есть программа на Qt/C++ и мы хотим её протестировать.
Нам нужно понажимать кнопки, повызывать менюшки и т.д. и мы хотим написать
эти сценарии тестирования на интерпретируемом языке, допутим мы выбираем питон.
Во-первых нужно всроить интерпретатор питона в C++ программу,
Во-вторых нужно проделать все то что описано в статье.
Т.е. нужно проделать дополнительуню работу по сравнению с тем, что уже сделано,
в чем будет выгода от использования PyQt и причем здесь pytest который для unit тестов?
А можете пояснить что вы имеете ввиду, т.к. вообще не вижу как Py*что-то может помочь в данном вопросе?
А можете пояснить для новичка в Go, почему если нужна скорость не проверяли
gccgo, насколько он усокряет код, а также не использовали встроенный в негопрофилирофшик (gprof)?
А можно поподробнее почему нужен zhparser и как он решает проблему тормозов?
Может стоит написать новым для себя, а то C++, Verilog и VHDL появились примерно в одно
время ~ 1980-1985
Нет, альфа версия Qt Monkey появилась в 2008 году, тогда Qе Webdriver не было в opensource, а может не было вообще (судя по первому коммиту в 2013).
Надо будет посмотреть.
Будет работать до Qt 6.x. См. qt-script-deprecated-what-is-replacement.
На смену разработчики Qt предлагают QJSEngine, но т.к. у меня основные проекты на Qt 4.x, я не спешу пока что либо менять.
Ведь в gcc (начиная с 4.9) можно указывать флаги оптимизации и target опции для куска исходного кода
с помощью `pragma`, а также можно указывать эти флаги для каждой функции отедльно, например так `static void calculate_sse(float *data, float scale, int size ) __attribute__ ((__target__ («no-avx»)));`
подробности можно найти здесь:
gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Function-Attributes.html#Function-Attributes
gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Function-Specific-Option-Pragmas.html
можно также просто как glibc делать — в нем есть всякие memcpy_avx каждый собран в отдельном единице трансляции.
Linux, правда конечно от boost spirit другого сложно ожидать в плане времени компиляции.
>но там было дело далеко не в заголовках и вовсе не факт, что модули сделали бы компиляцию заметно >быстрее
>всё это метопрограммирование — тяжёлая задача для компилятора
Не согласен, да время компиляции одного объектного файла модули не изменят,
но мы же говорим о сборке проекта целиком и вот тут как раз модули помогут,
т.к.
>всё это метопрограммирование — тяжёлая задача для компилятора
и поэтому решать ее несколько раз это полный бред.
Решил один раз загрузив CPU на 100% и отъев несколько гигабайт RAM, так закэшируй результат.
Те же 10 секунд превращаются в 2 секунды, когда засунешь boost includes в отдельный header
файл и превратишь его в precompiled.
И как помогает ccache разработчику? Человеку, который отвечает за дистрибутив да, но современные
системы сборки и так собирают только измененные файлы, или имеется ввиду распределенный для нескольких разработчиков ccache или случай сборки сильно различающихся веток одного проекта?
При этом также следует учесть, что даже перекомпиляция одного файла используещего буст (без precompiled header) вполне может 10 секунд занимать на не слабом железе (i7/16 GB RAM/SSD),
конечно кэширование объектный файлов (ccache)
и распределение сборки по кластеру (distcc) в какой-то мере спасают положение, но не до конца.
У каждого из них есть свои недостатки, кэширование слабо поможет если изменение вызывает перекомпиляцию
нескольких файлов, а dictcc не вариант если расходы на передачу input/output компилятора по сети сравнимы
с временем компиляции.
>stack trace для ARM, x86, x86-64 мне куда полезнее
ИМХО, stacktrace вполне можно реализовать в виде общего интерфейса плюс реализация
для каждого компилятора/runtime, конечно удобно было иметь это в std::, но проблема решается,
а вот для времени компиляции одни костыли, проблему даже на 50% не решающие.
> экспериментальная поддержка
Если их == модули, то есть и даже не в одном:
http://clang.llvm.org/docs/Modules.html
https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-modules-in-vs-2015-update-1/
>Поторопить тут никого не получится.
ИМХО, у людей работающих долго над чем-то, что не взлетает обычно
хорошо прокачено искуство объяснять как все сложно, но при этом
свежий вгляд от тех кто не испугался бывает им очень полезен.
>Вам может приглянуться эта библиотечка.
У меня уже есть решение основанное на парсинге с помощью libclang определения структур и
генерации метаинформации для работы с полями стуктуры в runtime.
ИМХО конечно, но в вашей библиотеке ведь даже название поля нельзя получить? Для сериализации
в json/xml это важно.
>стандартизация плоских контейнеров
>класс для вывода stack trace
И почему среди кучи разных сугубо специфических вещей не упоминается
то, что вызывает раздражение у каждого C++ программиста каждый божий день?
А именно — скорость компиляции. Бедный компилятор снова и снова парсит мегабайты
исходников. При этом существующие полуавтоматические решения для использования precompiled headers
вызывают еще большее раздражение, особенно в кросплатформенных проектах.
И главное и proposal есть для модулей, но конечно не в c++17, ведь сферические функции важнее.
Может стоит все-таки за модули побороться, а stack trace подождет?
>доступ к полям структур по индексу и базовая рефлексия.
Вот за это плюс один, использовать парсер C++ или дублировать код для рефлексии
по-моему через чур.
1)Про «новое» API. Под новым API подрузумевается splice,vmsplice,openat,name_to_handle_at,open_by_handle_at и т.д. С примерами, почему без этого API жить было больше нельзя, и насколько программы с его использованием могут стать быстрее.
2)Про оптимальные стратегии использования API Linux для конкретных примеров, например что стоит использовать для передачи маленького файла по сети, что для больших файлов, как наиболее быстро работать с тысячими соединений и т.д. на примере каких-нибудь nginx, haproxy.
Т.е. ценно на мой взгляд не сбор справочника всех доступных функций, а когда и как предполагается использовать эти функции для решения конкретных задач.
в «mainline»? На мой взгляд довольно востребованная возможность — авторизация через LDAP, а существующий сторонний плагин довольно неудобно деплоить.
будет вызываться после test(word) и давать обратную связь алгоритму, чтобы он доплнительно обучался во время теста?
Как я понимаю в основном это решение проблемы того, что C++ объекты отображаются в язык со сборкой мусора — javascript и поэтому хорошо бы этому сборщику мусора помочь со стороный C++.