Oakum в Arch Linux все нормально, собираются нормально 5.11.15, 5.11.16, сейчас перешел на 5.12-rc8 все нормально пашет и собирается. Ядро, mesa у меня каждый релиз собираются в ручную т.к. видео карта у меня AMD новой серии и с каждым релизом улучшается ее поддержка. Все собирается с оптимизацией и патчами под zen2. Отклик системы значительно выше, чем дистрибутивных ядер и mesa. Вот только что собрал mesa 21.0.3 вышедшую час назад, все хорошо. Если что-то ломается, проблема скорее всего не в компиляторе, а просто компилятор собран криво. В компиляторах есть специально тесты, чтобы ничего не ломать с новым релизом.
Полумертвый дитрибутив, поддержку которого вот-вот прекратят, извращения с натягиванием совы на глобус, когда в нормальных дистрибутивах можно использовать gcc 10-11 со всеми его преимуществами и багфиксами, и поддержкой новых процессоров.
Файл использует camelSpace стиль, но не везде, придерживаться одного стиля не учили в именах переменных? Это является хорошим тоном в программировании. Обработку исключений обрабатывать в shell скриптах не учили? sips? Это же тулза из mac os, для linux кросплатформенности есть imagemagick. Одну и туже команду запускать только ради получения отдельно ширины и высоты не разумно, правильнее положить выполнение команды в переменную, и потом из нее уже извлекать. folder вы серьезно? Термин folder не применим к POSIX системам. Это чисто Windows замута!
Вот мой вариант только может еще рекурсивно обрабатывать директории. И если заменить -resize "${maxWidth}x" на -resize "${maxWidth}@" то можно делать ресайз наибольшей стороны, а не только по ширине.
#!/bin/bash
imgsDirectory="."
destDirectory="./new"
quality=75
maxWidth="2000"
if [ ! -d "${imgsDirectory}" ]; then
echo "Image directory: ${imgsDirectory} not exist!"
exit 1
fi
if [ -d "${destDirectory}" ]; then
rm -rf "${destDirectory}"
fi
# Making directory tree. Making only not empty directories.
mkdir -p "${destDirectory}"
find "${imgsDirectory}" -type d -not -empty | cut -c$((${#imgsDirectory} + 2))- | xargs -I {} mkdir -p "${destDirectory}/{}"
# Image files processing.
IFS=$'\n'
cnt=0
imageFiles=$(find "${imgsDirectory}" -type f -regextype egrep -iregex ".*\.(jpe{0,1}g|heic)$" | cut -c$((${#imgsDirectory} + 2))-)
for image in $imageFiles; do
((cnt++))
imageData=$(magick identify -quiet "${imgsDirectory}/${image}" | grep -ioP -m1 "\w+\s+[0-9]+x[0-9]+" | head -n1)
imageType=$(echo "${imageData}" | cut -f1 -d\ )
imageWidth=$(echo "${imageData}" | cut -f2 -d\ | cut -f1 -dx)
imageHeight=$(echo "${imageData}" | cut -f2 -d\ | cut -f2 -dx)
if [[ -z ${imageWidth} || -z ${imageHeight} ]]; then
echo -e "[${cnt}] Skiping image ${image} - \E[1m\E[31mBROKEN IMAGE\E[0m"
continue
fi
if echo "${imageType}" | grep -iq "heic"; then
imageName=$(echo "${image}" | sed -n "s/.\w*$/.jpg/I;p")
else
imageName=${image}
fi
if [[ "${imageWidth}" -gt "${maxWidth}" && $((imageWidth / imageHeight)) -lt 2 ]]; then
magick "${imgsDirectory}/${image}" -quiet -resize "${maxWidth}x" -quality "${quality}" "${destDirectory}/${imageName}"
touch -r "${imgsDirectory}/${image}" "${destDirectory}/${imageName}"
echo -e "[${cnt}] Resizing Image ${image} \E[1m\E[33m${imageWidth} → ${maxWidth}\E[0m - \E[1m\E[32mSUCCESS\E[0m"
fi
done
# Removing empty directories in destionation. Directories which can be contain bad image files.
find "${destDirectory}" -type d -empty -delete
echo -e "\nReplacing original images...\n"
#rsync -a "${destDirectory}/" "${imgsDirectory}"
rm -rf "${destDirectory}"
# vim:set ts=2 sw=2 et:
Речь была про mingw-w64. Под виндовс сборки сильно отстают.
У меня на arch linux уже gcc 10.3 в mingw-w64. Вообще в идеале добавить кроме пути к toolchain файлу еще возможность указать .sh или .bat файл, который может устанавливать переменные среды компиляции.
anatolix у вас там все разработчики такие отсталые и предлагают использовать не рабочие решения? C .com идет редирект на .ru! Дайте угадаю, опять же не знали…
Судя по комментариям вы там все плохо разбираетесь стеке технологий, которые используете и все в придачу поломали.
«как работает AliExpress после переноса разработки в Россию»
Очень плохо и отвратительно! Сайт сплошные тормоза!
Заходишь в личный кабинет, отметить полученные заказы, отмечаешь один, идешь отметить второй, вылетает авторизация и просит по новой залогинится, просит ввести капчу! Ладно перезайти не сложно, но когда тебе надо отметить штук 10 заказов, которые пришли консолидированными, это просто ад. Грузится сайт по секунд 10-15 каждую страницу, а чтобы отметить заказ и перейти к следующему надо загрузить 4-5 страниц, все это превращается в очень веселое приключение и разряди mission inposible. И это все на современном ryzen 9 3900x и интернете 400mb/s когда другие сайты открывает менее чем за секунду! Кстати поиск стал кривым, по запросу прямому не находит, и перестал выдавать вверху более трастовых продавцов! А я сидел думал, че это кучу глюков на сайте появилось с прошлой осени, а тут вот оно как, новые птушники разработчики… Кстати про реактивное программирование, птушники видимо не слышали, т.к. до сих пор много где используются переход на нужную страницу, вместо передачи запроса из JS.
1. mingw генерирует более быстрый код. Когда я писал быстрый аналог protobuf, то версия на mingw генерировала значительно более быстрый асинхронный многопоточный код чем MSVC. Но под виндовс сборки mingw кривоватые, устаревшие и генерировали файл в 2 раза больше. Самая последняя сборка есть в Arch Linux и с ней полноценно можно компилировать виндовые приложения. Arch Linux можно поставить в WSL, но проблема в clion была, что он вроде кроме как с убунтой нормально ни с кем не дружил, и не стандартные диструбитвы не видит. WSL приложения можно выполнять как консольные команды, если прописать пути к файлам mingw то тоже какой-то глюк был, уже не помню. Если с помощью хака запускать в WSL SSH сервер, то так же не возможна отладка на виндов и сборка в WSL. Если запускать clion под Arch Linux, то в arch linux cmake опережает поддерживаемую вами версию, у меня выходит данная версия CMAKE не поддерживается. cmake version 3.20.1 В Arch есть специальный пакет aur.archlinux.org/packages/mingw-w64-cmake который устанавливает пути и окружения для сборки в mingw, но этот cmake нельзя указать, он не поддерживается. Можно сделать хак и создать toolchain файл и загрузить его с помощью -DCMAKE_TOOLCHAIN_FILE во встроенный в clion cmake pastebin.com/qiUPnhm6, тогда можно успешно компилировать. Так как путь к toolchain файлу длинный, его не удобно вписывать в параметры, он мешает их редактировать и смотреть, поэтому есть предложение добавить соответствующее поле где можно указать путь к тулчаин, так как например указывается путь к cmake, gdb, gcc, g++ и т.д. Про путь к тулчаин вроде еще много лет писал на вашем YouTrack.
2. Сыровата поддержка, хоть вас просили добавить поддержку QT, она еще сырая.
5. VHDL если бы поддерживался и с ним было бы удобно работать, то было бы хорошо это плюс к Embedded. И было бы хорошо, если можно было бы заменить Xilinx Vitis. Как видится мне Embedded это направление, где CLion может взять себе долю рынка, особено с поддержкой MISRA. Для десктоп приложений есть QT, Visual Studio, Embarcadero, XCode с визуальным редактором и набором компонентов, к пример Embarcadero стоит значительно дороже, но там релизы более стабильные и поддержка лучше. Плагин VHDL не очень интересен, так как банально нет даже симуляции, например даже в matlab она есть.
6. Были большие надежды, что ошибался, но вот достал свою плату на h745zi-q от ST, пол дня промучался пытался открыть и создать проект проекты по разному, посмотрел документацию, но пропустил один момент, что там есть приписка 745 не поддерживается, видимо все многоядерные чипы не поддерживаются, а судя по ссылки plugins.jetbrains.com/plugin/10115-openocd--stm32cubemx-support-for-arm-embedded-development/versions/stable на модуль поддержка только в альфа режиме и не особо он развивается, ссылка с вашей документации. А ведь так хотелось, что бы можно было заменить stm32ide. В первую очередь загрузка прошивки, и удаленная отладка. Еще одним пунктом было бы хорошо иметь возможность собирать загрузочные образы, как в Xilinx Vitis. Вообще пока очень сырая поддержка.
В Rider была отписка, что все это проприетарное и макрософт не делится, поэтому поддержка проблемная. Сейчас не знаю как обстоят дела, у меня сейчас основная система для программирования Arch Linux, и под виндовс ставить тулчеин не очень охото проверерять.
Простите за резкость, я всегда прямолинеен, нравится вам или нет, но вот я нигде не слукавил и написал главные недостатки продуктов jetbtains. Надо много дорабатывать, чтобы IDE стали более самостоятельными и полноценными, а то получается поддержка Embedded в Clion хуже чем в arduion ide.
anastasiak2512 вы багрепоты не читаете? С подобной проблемой столкнулись так же пользователи IDEA. В соседней теме про idea, там несколько человек отписалось с этой проблемой.
Вас что на youtrack.jetbrains.com/issues забанили за плохую работу и отключили сортировку по дате, чтобы открыть старые открытые баги? Кучу багов WSL, mingw-w64 с WSL не поддерживался, даже QT поддерживается криво, кучу ошибок сыпет по синтаксису, часть видимо пофиксили в 2021.1. Нет профилировщика GPU, графических элементов. Cамое интересное до сих пор нет в отладчике смены отображения данных для базовых типов, мне например надо не редко смотреть к пример int в бинарном формате и 16 ричном, сейчас только можно смотреть в 10чном. При этом дамп можно смотреть в 16ричном. Не возможно заниматься системным программированием и отлаживать ядро, за исключением linux. Embedded поддержка тоже не полноценная, ни xilinx ни stm32, нормально не поддерживаются, даже нет базовой подсветки синтаксиса VHDL, все плагины для поддержки VHDL кривые, нет поддержки HLS. Самое главное IDE очень медленная, когда для embedded ide на основе eclipse просто летают. Частые баги с кэшем, часто IDEs от Jetbrains взбешиваются и пытаются сделать рехэш всего проекта. К примеру IDEA каждый раз пытается индексировать openjdk… Зачем? Расширенные индексы грузятся долго, и почему-то загружаются по новой при каждой загрузке проекта! Видимо нет хэш таблиц контрольных сумм файлов?! В Rider кучу проблем с XAML, кривая поддержка графических элементов, даже просмотр не всегда работает, не говоря про отладку и профилировку их. Xcode и Visual Studio давно все это умеют и на голову полноценнее, стабильнее. Не понятно зачем покупать ради QT Clion если есть нормальная native поддержка в Qt Creator. Нет там автодополнения, ну и х с ним… Вон KDE написан без вашей чудо IDE и ничего, развиваются, никто из разработчиков не умер. Автодополнение, рефакторинг и некоторые фишечки единственные плюсы продуктов от Jetbrains. И все это рассчитано на опенсорс, на веб или околовеб. Самый стабильный продукт из всех это IDEA, который полноценное можно использовать. Остальное работает криво, и приходится изобретать костыли, на которые уходит большем времени чем экономит автодополнение. Про серьезную разработку чего-то графического или системного можно забыть…
Про то и речь, что обман и все не как у нормальных компаний. Даже баги которые были отправлены вам 3 года назад в вашем софте были не поксены, и мне до сих пор приходят очень часто уведомления по ним! Не говоря про то, что некоторого важного функционала нет ни в rider ни в clion, и даже не предвидится, баги не фиксятся и приходится использовать visual studio, которая хотя бы дает возможность нормально программировать, а не ждать погоды от разработчиков Jetbrains.
«Напоминаем, что при покупке годовой подписки на любой продукт предоставляется резервная бессрочная лицензия.» Ага, только забыли напомнить, что обновления на бессрочную лицензию будут доступны только внутри 2021.1 релиза, а не всего 2021 мажорного релиза. Что делает покупку IDE вначале года не выгодной т.к. содержит в себе еще кучу свежих багов. И есть еще стойкое чувство при покупке, что тебя жестко наегрели, т.к. другой весь софт дает бесплатно обновления в течении мажорного релиза, и дает все обновления бесплатно на следующий мажорный релиз если он был выпущен в течении срока подписки, поэтому пожалуй стоит отказаться от покупки. Лучшие заставки были в 2019 году, последние два года, это просто вырви глаз уродство! А еще просто блевать охота от анимации при закрытии окна, когда приложение вытягивает в один из углов рандомно. Не понятно зачем суете свою кривую анимацию при закрытии и используете ее вместо системной!
Люди начинают пихать где попало и где не нужно, не понимая сам процесс происходящего и почему был принят сам стандарт… Старые технологии где-то имеют выигрыш, всегда надо четко понимать где это применимо, а где наоборот вредно… Тоже выравние по центру дива, можно сделать многими способами: через марджин, транслейт, флексбокс и у всех есть свои плюсы и минусы, и области применения…
Одними медиа запросами сыт не будешь… Сейчас довольно сложные динамически обновляемые сайты… Да и можно сократить медиа запросы и размер css, при помощи новых технологий… Читайте на здоровье https://developers.google.com/web/fundamentals/performance/rendering/
Там например есть классический пример пример flexbox против float + %. И замедление может быть еще больше в этой связке, зависит от DOM и других стилей. Но еще конечно не правильное использование новых технологий, тоже может замедлить отрисовку. Но в этом виноват только разработчик, который не читает стандарты и рекомендации.
Честно не понял, что он имел ввиду. Но если говорить про технологии, то современные технологии могут дать лучшую адаптивность и переносимость дизайна сайта с устройства на устройства, повысить интерактивность и обеспечить более комфортное чтение, что очень важно, так как рынок мобильных устройств быстро растет. Еще старые технологии могут замедлять отрисовку страницы. По этой же причине, считаю нужно разделять отдельно стили для современных устройств и делать отдельную версию сайта для совсем старых браузеров. Слава богу легаси браузеров сейчас не так много и ими можно пожертвовать, и можно использовать calc, vw, flexbox. А вот с display: grid и fr не все так гладко, поддерживают всего 70% браузеров, 1/3 рынка просто так не выкинишь, это реальное самоубийство для бизнеса… хотя сами технологии очень сладкие для разработчика…
Они зато просчитываются быстрее и шаблон быстрее рендерится чем со 100%, они нельзя называются единицами видимой области. Процентные единицы требует просчет родителя контейнера, что на сложных шаблонах с большим dom деревом замедляет отрисовку, по это же причине верстка флоатами с процентами медленее flex. На крупных ресурсах % могут замедлить довольно значительно отрисовку, особенно если это SPA и при взаоимодействии пользователя с интерфейсом могут возникнуть тормоза.
Мой плагин например все необходимые расчеты с calc делает автоматически, и дизайн адаптивный, засчет использования языка макросов
Вместо:
Надо использовать такую команду:
Про ключ -e у echo видимо тоже?
Файл использует camelSpace стиль, но не везде, придерживаться одного стиля не учили в именах переменных? Это является хорошим тоном в программировании. Обработку исключений обрабатывать в shell скриптах не учили? sips? Это же тулза из mac os, для linux кросплатформенности есть imagemagick. Одну и туже команду запускать только ради получения отдельно ширины и высоты не разумно, правильнее положить выполнение команды в переменную, и потом из нее уже извлекать. folder вы серьезно? Термин folder не применим к POSIX системам. Это чисто Windows замута!
Вот мой вариант только может еще рекурсивно обрабатывать директории. И если заменить -resize "${maxWidth}x" на -resize "${maxWidth}@" то можно делать ресайз наибольшей стороны, а не только по ширине.
У меня на arch linux уже gcc 10.3 в mingw-w64. Вообще в идеале добавить кроме пути к toolchain файлу еще возможность указать .sh или .bat файл, который может устанавливать переменные среды компиляции.
Судя по комментариям вы там все плохо разбираетесь стеке технологий, которые используете и все в придачу поломали.
Очень плохо и отвратительно! Сайт сплошные тормоза!
Заходишь в личный кабинет, отметить полученные заказы, отмечаешь один, идешь отметить второй, вылетает авторизация и просит по новой залогинится, просит ввести капчу! Ладно перезайти не сложно, но когда тебе надо отметить штук 10 заказов, которые пришли консолидированными, это просто ад. Грузится сайт по секунд 10-15 каждую страницу, а чтобы отметить заказ и перейти к следующему надо загрузить 4-5 страниц, все это превращается в очень веселое приключение и разряди mission inposible. И это все на современном ryzen 9 3900x и интернете 400mb/s когда другие сайты открывает менее чем за секунду! Кстати поиск стал кривым, по запросу прямому не находит, и перестал выдавать вверху более трастовых продавцов! А я сидел думал, че это кучу глюков на сайте появилось с прошлой осени, а тут вот оно как, новые
птушникиразработчики… Кстати про реактивное программирование,птушникивидимо не слышали, т.к. до сих пор много где используются переход на нужную страницу, вместо передачи запроса из JS.2. Сыровата поддержка, хоть вас просили добавить поддержку QT, она еще сырая.
5. VHDL если бы поддерживался и с ним было бы удобно работать, то было бы хорошо это плюс к Embedded. И было бы хорошо, если можно было бы заменить Xilinx Vitis. Как видится мне Embedded это направление, где CLion может взять себе долю рынка, особено с поддержкой MISRA. Для десктоп приложений есть QT, Visual Studio, Embarcadero, XCode с визуальным редактором и набором компонентов, к пример Embarcadero стоит значительно дороже, но там релизы более стабильные и поддержка лучше. Плагин VHDL не очень интересен, так как банально нет даже симуляции, например даже в matlab она есть.
6. Были большие надежды, что ошибался, но вот достал свою плату на h745zi-q от ST, пол дня промучался пытался открыть и создать проект проекты по разному, посмотрел документацию, но пропустил один момент, что там есть приписка 745 не поддерживается, видимо все многоядерные чипы не поддерживаются, а судя по ссылки plugins.jetbrains.com/plugin/10115-openocd--stm32cubemx-support-for-arm-embedded-development/versions/stable на модуль поддержка только в альфа режиме и не особо он развивается, ссылка с вашей документации. А ведь так хотелось, что бы можно было заменить stm32ide. В первую очередь загрузка прошивки, и удаленная отладка. Еще одним пунктом было бы хорошо иметь возможность собирать загрузочные образы, как в Xilinx Vitis. Вообще пока очень сырая поддержка.
В Rider была отписка, что все это проприетарное и макрософт не делится, поэтому поддержка проблемная. Сейчас не знаю как обстоят дела, у меня сейчас основная система для программирования Arch Linux, и под виндовс ставить тулчеин не очень охото проверерять.
Простите за резкость, я всегда прямолинеен, нравится вам или нет, но вот я нигде не слукавил и написал главные недостатки продуктов jetbtains. Надо много дорабатывать, чтобы IDE стали более самостоятельными и полноценными, а то получается поддержка Embedded в Clion хуже чем в arduion ide.
егрели, т.к. другой весь софт дает бесплатно обновления в течении мажорного релиза, и дает все обновления бесплатно на следующий мажорный релиз если он был выпущен в течении срока подписки, поэтому пожалуй стоит отказаться от покупки. Лучшие заставки были в 2019 году, последние два года, это просто вырви глаз уродство! А еще просто блевать охота от анимации при закрытии окна, когда приложение вытягивает в один из углов рандомно. Не понятно зачем суете свою кривую анимацию при закрытии и используете ее вместо системной!Там например есть классический пример пример flexbox против float + %. И замедление может быть еще больше в этой связке, зависит от DOM и других стилей. Но еще конечно не правильное использование новых технологий, тоже может замедлить отрисовку. Но в этом виноват только разработчик, который не читает стандарты и рекомендации.
Мой плагин например все необходимые расчеты с calc делает автоматически, и дизайн адаптивный, засчет использования языка макросов