1.Скорее нет - удалили код, и опцию конфига (X86_USE_3DNOW) которая позваляла этот код компилировать и делать частью ядра. Хотите на новом ядре этот код? думаю прийдется делать backport .
2. быстрее быть может и нет , но сборка и поддержка фичи которая нужна 0.5% пользователей это боль для остальных 99.5% , IMHO
Привет El Primo с задворок Машрабы! Дохлый интернет это полбеды (на WE ~ 20/5 Mbit/s download/upload) . Блокируют основные популярные VPN протоколы. С этого года сюда и добавился Wireguard , поэтому если комуто нуже быстрый интернет , то это не о Дахабе.
Интересно : можно ли притянуть за уши добавление обьектов на OSM в своем городе к деятельности связанной со шпионажем или разбазариванием гос-тайны? Понимаю что нет, но как показывают последние годы - есть сомнения.
По поводу IDE и всего такого - готов "сьесть", тк. всетаки вопрос вкуса и предпочтений. К примеру в своей работе я так и не сдружился с QtCreator, хотя обьективно среда отличная - там есть почти все из коробки. Но нет ) Уже лучше VS, а в идеале CLion (на С++ лабаю).
Но вот по поводу С++14/20 прошу прощения что заела пластинка: что там такого концептуально нового на фоне С++11 из того что может быть реально использовано на микроконтроллере?
Если взять все теже шаблоны, то все это уже было в C++11 Extern templates Template aliases Variadic templates Local types as template arguments
Что там в 14/20 такого, без чего не обойтись на контроллере ? Constraints and concepts ? Да ладноооо! =)
Я позволил себе оговорку-лазейку, написав что "субьективно". С C++14/20 все хорошо, по моему субьективному мнению, но на десктопе. В принципе моя формулировка "не использовать С++14/20" на микроконтроллере схожа с мыслью "ограничивать себя". Ну какие там C++14/20 если, поправьте меня, даже std::thread, packaged_task,future/promise не реализованы на stm32 ? А это, на минуточку, C++11 . А как там move semantics ? Не использовать C++14/20 на микроконтроллере также укладывается в концепцию "развиваться и обучаться".
мне больше по душе переставить один блок лего в центр «крыши». Не так надежно как вовсе убрать блок, но определенно лучше чем если опора находится в углу.
Ну мы же тут обсуждаем язык не с точки зрения простоты самого языка, а с точки пригодности для начинающего.
Ассемблер общее название для группы разных мнемонических языков, для разных платформ с разными подходами к IO и т.д.
Разработчики на C известны тем, что кропотливо создают упорядоченный, чистый код
Самое любимое место в этой статье ♡ А если серьезно то проблемы с памятью в неуправляемой среде это чуть ли не треть всех проблем. Утечки, затирки и т.д.
На начальном этапе это лишь оттолкнет. На мой взгляд для начала хуже C только ассемблер.
Ну тут очень поверхностный ответ: нужен кросстулчейн, и rootfs той платформы для которой происходит сборка.
В rootfs должны быть не только .h файлы для соответсвующих либ, но и pkgconfig/*.pc файлы зависимостей. Плюс для configure должен быть соответсвующий файл
Использование GPU для eglfs бэкэнда контролируется во время сборки Qt, через configure
./configure… -eglfs -opengl es2…
Во время сборки используются заголовочные файлы и .so от вендора, где включено аппратаное ускорение.
Но надо понимать что для eglfs ускорение используется очень ограниченно. Большинство графических примитивов отрисовываются в software режиме, но на EGL плоскости. И ускорение в основном касается блитта и копирования части графической поверхности.
eglfs(fs — full screen) — в этом режиме работы бэкэнд отрисовки Qt рисует прямиком во framebuffer. Родительский виджет (root) занимает всю видимую область экрана.
Концептуально отличается от linuxfb тем что имеется минимальное аппаратное ускорение
при блитте поверхностей.
Таким образом сначала надо сконфигруировать framebuffer, а затем через переменную окружения указать активный «qpa»
Информации на самом деле достаточно. К примеру вот здесь неплохо описано:
Немножко в теме: все эти медиацентры малоэффективны до тех пор пока нет поддержки аппаратного декодирования видео. Большинство приставок на software decoder'e не вывезут даже h.264 в FullHD, не говоря уже о 4k hevc/h.265.
К примеру тут упоминали X96 max+: на Android все это есть (аппаратное ускорение) для AMLogic S905x3 чипа. Есть сборки Armbian для этой приставки, но туда еще не завезли ускорение на уровне драйверов.
PS: Кстати на Android X96 max+ есть изкоробки KODI mediacenter. Лично мне нравятся приставки Infomir.
Соглашусь с популярным мнением что препроцессор это не часть языка, и если есть возможность избегать макросов то лучше это сделать.
«Колбаса» начинается когда макрос генерирует макросы которые разворачиваются в другие макроссы, будто это эффективный инструмент для кодогенерации.
Чисто субьективно: IntelliSense плачет, я плачу, люди которые читаю код после меня тоже страдают — зачем это все? Чтобы «красиво» написать все в 2 строки, а не в 4 понятно?
По правде говоря думая о Ragel я представлял в уме BNF, нежели стандартные регулярки. Не могу понять пока уместно ли говорить о DFA/NFA в контексте Ragel. Задумался, пошел читать Википедию.
Отличная статья, отличные слайды и отличное чувство юмора (нам нравится одна и таже шутка) — спасибо! Таки да статью не читал, но о̶с̶у̶ж̶д̶а̶ю̶ одобряю!
1.Скорее нет - удалили код, и опцию конфига (X86_USE_3DNOW) которая позваляла этот код компилировать и делать частью ядра. Хотите на новом ядре этот код? думаю прийдется делать backport .
2. быстрее быть может и нет , но сборка и поддержка фичи которая нужна 0.5% пользователей это боль для остальных 99.5% , IMHO
Привет El Primo с задворок Машрабы! Дохлый интернет это полбеды (на WE ~ 20/5 Mbit/s download/upload) . Блокируют основные популярные VPN протоколы. С этого года сюда и добавился Wireguard , поэтому если комуто нуже быстрый интернет , то это не о Дахабе.
Интересно : можно ли притянуть за уши добавление обьектов на OSM в своем городе к деятельности связанной со шпионажем или разбазариванием гос-тайны? Понимаю что нет, но как показывают последние годы - есть сомнения.
По поводу IDE и всего такого - готов "сьесть", тк. всетаки вопрос вкуса и предпочтений. К примеру в своей работе я так и не сдружился с QtCreator, хотя обьективно среда отличная - там есть почти все из коробки. Но нет ) Уже лучше VS, а в идеале CLion (на С++ лабаю).
Но вот по поводу С++14/20 прошу прощения что заела пластинка: что там такого концептуально нового на фоне С++11 из того что может быть реально использовано на микроконтроллере?
Если взять все теже шаблоны, то все это уже было в C++11
Extern templates
Template aliases
Variadic templates
Local types as template arguments
Что там в 14/20 такого, без чего не обойтись на контроллере ?
Constraints and concepts ? Да ладноооо! =)
Я позволил себе оговорку-лазейку, написав что "субьективно".
С C++14/20 все хорошо, по моему субьективному мнению, но на десктопе.
В принципе моя формулировка "не использовать С++14/20" на микроконтроллере схожа с мыслью "ограничивать себя". Ну какие там C++14/20 если, поправьте меня, даже std::thread, packaged_task,future/promise не реализованы на stm32 ? А это, на минуточку, C++11 .
А как там move semantics ?
Не использовать C++14/20 на микроконтроллере также укладывается в концепцию "развиваться и обучаться".
Сам фанбой Jetbrains и в частности CLion, но С++14/20 для микроконтроллера как-то перебор, субьективно так. Да и так ли плоха родная IDE ?
У меня скепсис главным образом не изза формы хранения, а высокой вероятности утечки данных ввиду низкой культуры безопасности персональных данных.
Ассемблер общее название для группы разных мнемонических языков, для разных платформ с разными подходами к IO и т.д.
Самое любимое место в этой статье ♡ А если серьезно то проблемы с памятью в неуправляемой среде это чуть ли не треть всех проблем. Утечки, затирки и т.д.
На начальном этапе это лишь оттолкнет. На мой взгляд для начала хуже C только ассемблер.
В rootfs должны быть не только .h файлы для соответсвующих либ, но и pkgconfig/*.pc файлы зависимостей. Плюс для configure должен быть соответсвующий файл
Вот к примеру сниппет для сборки
./configure… -eglfs -opengl es2…
Во время сборки используются заголовочные файлы и .so от вендора, где включено аппратаное ускорение.
Но надо понимать что для eglfs ускорение используется очень ограниченно. Большинство графических примитивов отрисовываются в software режиме, но на EGL плоскости. И ускорение в основном касается блитта и копирования части графической поверхности.
Концептуально отличается от linuxfb тем что имеется минимальное аппаратное ускорение
при блитте поверхностей.
Таким образом сначала надо сконфигруировать framebuffer, а затем через переменную окружения указать активный «qpa»
Информации на самом деле достаточно. К примеру вот здесь неплохо описано:
doc.qt.io/qt-5/embedded-linux.html
К примеру тут упоминали X96 max+: на Android все это есть (аппаратное ускорение) для AMLogic S905x3 чипа. Есть сборки Armbian для этой приставки, но туда еще не завезли ускорение на уровне драйверов.
PS: Кстати на Android X96 max+ есть изкоробки KODI mediacenter. Лично мне нравятся приставки Infomir.
«Колбаса» начинается когда макрос генерирует макросы которые разворачиваются в другие макроссы, будто это эффективный инструмент для кодогенерации.
Чисто субьективно: IntelliSense плачет, я плачу, люди которые читаю код после меня тоже страдают — зачем это все? Чтобы «красиво» написать все в 2 строки, а не в 4 понятно?