Про отладчик, нам неизвестны такие проблемы в версии LLDB, которая в релизе. Там был краш, но мы его откатили, и аналогично в LLVM его недавно тоже ревертнули, но он выглядел иначе. Можете собрать логи по этой инструкции, пожалуйста, и создать тикет в трекере, приложив логи и описание проблемы?
А вот падения, как вы описываете в 2021.2, похоже на то, что откатывали мы и LLVM. В общем, давайте разбираться с текущей проблемой на 2021.3, начнем с логов.
Ну вот PlatformIO как раз довольно много шаблонов для разных микроконтроллеров предлагает. При установке плагина, появляется как дополнительный пункт в диалоге создания нового проекта. Вы не пробовали?
В целом, JetBrains Client подразумевает редактор, работающий на основе протокола JetBrains Rider’s RD (это как раз протокол, который использует наш продукт Rider для общения с бэкендом из ReSharper-а). Этот протокол оптимизирован так, чтобы тайпинг ощущался мгновенным. Умная работа с кодом происходит на стороне сервера IntelliJ IDEA и организована так, чтобы ощущалась как локальный инстанс.
Но тут, конечно, многое зависит от сети. И при каких-то больших пингах, понятно, что комплишен будет не мгновенный, и вообще будет не прямо как локально. В целом, у нас в тестировании все работает адекватно. Но при этом работа ведется и по части оптимизации latency.
Новое решение для удаленной разработки еще совсем новое) В смысле, что там пока, к сожалению, еще много разнообразных проблем. Подскажите, вы репортили те проблемы, которые наблюдаете, нам в трекер? Чтобы обратить внимание команды на них.
Шаблон для Embedded - очень расплывчатое понятие. Сейчас есть интеграция с STM32CubeMX проектами и с PlatformIO (если плагин поставить). Мы, конечно. хотели бы больше, но пока не понятно, что именно стоит сделать в первую очередь. Можете привести примеры, какие конкретно проекты еще хочется видеть?
Это хороший вопрос) Спасибо. Мы про него думали и видим, конечно, определенную сложность. Для QT можно установить официальный дистрибутив, указав в компонентах MinGW 64-bit, дальше сконфигурировать в CMake. CLion темплейты Qt проектов (console/gui) работают из коробки, если указать QT через CMAKE_PREFIX_PATH (по умолчанию MinGW 64-bit QT ставится в "C:/Qt/Qt5.12.12/5.12.12/mingw73_64"). В случаях других библиотек, там только через поиск библиотеки в CMake подключать. Но для тех, кто хочет побыстрее начать разработку в пустом окружении, бандленный mingw все равно перевешивает по удобству.
У нас, кажется, в документации все же указано, что в удаленном режиме все удаленно и запускается.
Вообще для более сложных сетапов, когда сборка и запуск на разных машинах, есть общий подход, описанный тут. По сути, в случае запуска локально, там даже проще. Есть локальная конфигурация для запуска и удаленная для сборки. А также external tool настраиваете, чтобы скачивать бинарь с удаленной машины на локальную. Вроде должно норм работать.
Я дала ссылку на корневую страницу про remote dev. Это новая технология. Старый remote dev тоже пока остается в CLion (через создание тулчейна, описание которого вы запостили). Сейчас новую технологию конкретно в CLion можно использовать только через Gateway. В Release Candidate уже работает. На днях будет релиз и мы напишем чуть подробнее тут на Хабре.
Про IDEA Vim - пинганула команду, у них, я так понимаю, какие-то варианты там есть, но четкого плана нет. Можно оставлять комментарии и пожелания в тикете, если еще не успели.
На плагин посмотрим при случае, спасибо. Комплишен и часть навигации в CLion сейчас работает через Clangd и довольно неплохо. Rename в CLion контекстно-зависимый (то есть не зацепляет символы с такими же именами в других областях видимости), его мы пока делаем на старом движке.
Вы отчасти правы - "проблема" в том, что CLion полноценно парсит и резолвит код, а редакторы вроде Neovim лишь частично. Поэтому они не могут делать, например, рефакторинги на всем проекте, просто не имеют для этого информации. А CLion собирает и обрабатывает больше информации, чтобы это все уметь. При этом, C++ язык не простой - там для корректной покраски кода (спасибо перегруженным операторам и не только) надо полностью резолв кода запускать. Мы в CLion постоянно оптимизируем наш парсинг, резолв, и все операции, чтобы отзывчивость редактора была вменяемой. Движок на основе Clangd у нас при этом сильно отличается от мастера LLVM репозитория - там множество наших оптимизаций и куча дополнительных возможностей, которые мы не апстримим. CLion, пока к сожалению, и правда на многих примерах бывает тормозит еще - мы пока не везде извели старый языковой движок, который уже решено не поддерживать далее. На Clangd еще при этом не все работает. Но я надеюсь, что наша постоянная работа в этом направлении все же не остается совсем незамеченной) А с конкретными "тормозами" лучше приходите в трекер или саппорт, посмотрим на конкретный CPU снэпшот и раскопаем конкретную проблему. Может, воркэраунд какой-то сразу подскажем.
Ребята упоминают довольно много фичей (навигация, find usages, UE reflection механизм, UE log, поддержка файлов INI & Blueprints, отладчик). Скажите, о чем конкретно было бы интересно более детально узнать?
Как только она появится в Clang, автоматом после апдейта будет и в CLion уже что-то. А может, мы и раньше что-то сделаем. Но, если честно, пока в CMake модули не завезли, не очень понятно, куда нам торопиться)
Platformio не только Ардуино поддерживает. У них обширный список плат.
Спасибо за пример с ложным анализом. Сейчас посмотрим. У меня правда только container показывается как unused.
Про отладчик, нам неизвестны такие проблемы в версии LLDB, которая в релизе. Там был краш, но мы его откатили, и аналогично в LLVM его недавно тоже ревертнули, но он выглядел иначе. Можете собрать логи по этой инструкции, пожалуйста, и создать тикет в трекере, приложив логи и описание проблемы?
А вот падения, как вы описываете в 2021.2, похоже на то, что откатывали мы и LLVM. В общем, давайте разбираться с текущей проблемой на 2021.3, начнем с логов.
Ну вот PlatformIO как раз довольно много шаблонов для разных микроконтроллеров предлагает. При установке плагина, появляется как дополнительный пункт в диалоге создания нового проекта. Вы не пробовали?
В целом, JetBrains Client подразумевает редактор, работающий на основе протокола JetBrains Rider’s RD (это как раз протокол, который использует наш продукт Rider для общения с бэкендом из ReSharper-а). Этот протокол оптимизирован так, чтобы тайпинг ощущался мгновенным. Умная работа с кодом происходит на стороне сервера IntelliJ IDEA и организована так, чтобы ощущалась как локальный инстанс.
Но тут, конечно, многое зависит от сети. И при каких-то больших пингах, понятно, что комплишен будет не мгновенный, и вообще будет не прямо как локально. В целом, у нас в тестировании все работает адекватно. Но при этом работа ведется и по части оптимизации latency.
А есть описание того, как именно сломан дебагер? Или ссылка на тикет?
Аналогично про ложные срабатывания, есть тикет или пример?
Новое решение для удаленной разработки еще совсем новое) В смысле, что там пока, к сожалению, еще много разнообразных проблем. Подскажите, вы репортили те проблемы, которые наблюдаете, нам в трекер? Чтобы обратить внимание команды на них.
Шаблон для Embedded - очень расплывчатое понятие. Сейчас есть интеграция с STM32CubeMX проектами и с PlatformIO (если плагин поставить). Мы, конечно. хотели бы больше, но пока не понятно, что именно стоит сделать в первую очередь. Можете привести примеры, какие конкретно проекты еще хочется видеть?
@Elmot может сможет что-то еще подсказать тут.
Это хороший вопрос) Спасибо. Мы про него думали и видим, конечно, определенную сложность. Для QT можно установить официальный дистрибутив, указав в компонентах MinGW 64-bit, дальше сконфигурировать в CMake. CLion темплейты Qt проектов (console/gui) работают из коробки, если указать QT через CMAKE_PREFIX_PATH (по умолчанию MinGW 64-bit QT ставится в "C:/Qt/Qt5.12.12/5.12.12/mingw73_64").
В случаях других библиотек, там только через поиск библиотеки в CMake подключать. Но для тех, кто хочет побыстрее начать разработку в пустом окружении, бандленный mingw все равно перевешивает по удобству.
У нас, кажется, в документации все же указано, что в удаленном режиме все удаленно и запускается.
Вообще для более сложных сетапов, когда сборка и запуск на разных машинах, есть общий подход, описанный тут. По сути, в случае запуска локально, там даже проще. Есть локальная конфигурация для запуска и удаленная для сборки. А также external tool настраиваете, чтобы скачивать бинарь с удаленной машины на локальную. Вроде должно норм работать.
Я дала ссылку на корневую страницу про remote dev. Это новая технология. Старый remote dev тоже пока остается в CLion (через создание тулчейна, описание которого вы запостили). Сейчас новую технологию конкретно в CLion можно использовать только через Gateway. В Release Candidate уже работает. На днях будет релиз и мы напишем чуть подробнее тут на Хабре.
Это вы читаете описание старого remote dev в CLion. А с 2021.3 есть новый, через JetBrains Gateway, смотрите по ссылке в моем сообщении
Ждать уже не надо) Можно пробовать New Remote Development в CLion (https://www.jetbrains.com/remote-development/) уже начиная c 2021.3. JetBrains Gateway уже поддерживает CLion.
Про IDEA Vim - пинганула команду, у них, я так понимаю, какие-то варианты там есть, но четкого плана нет. Можно оставлять комментарии и пожелания в тикете, если еще не успели.
На плагин посмотрим при случае, спасибо.
Комплишен и часть навигации в CLion сейчас работает через Clangd и довольно неплохо. Rename в CLion контекстно-зависимый (то есть не зацепляет символы с такими же именами в других областях видимости), его мы пока делаем на старом движке.
Вы отчасти правы - "проблема" в том, что CLion полноценно парсит и резолвит код, а редакторы вроде Neovim лишь частично. Поэтому они не могут делать, например, рефакторинги на всем проекте, просто не имеют для этого информации. А CLion собирает и обрабатывает больше информации, чтобы это все уметь.
При этом, C++ язык не простой - там для корректной покраски кода (спасибо перегруженным операторам и не только) надо полностью резолв кода запускать.
Мы в CLion постоянно оптимизируем наш парсинг, резолв, и все операции, чтобы отзывчивость редактора была вменяемой. Движок на основе Clangd у нас при этом сильно отличается от мастера LLVM репозитория - там множество наших оптимизаций и куча дополнительных возможностей, которые мы не апстримим.
CLion, пока к сожалению, и правда на многих примерах бывает тормозит еще - мы пока не везде извели старый языковой движок, который уже решено не поддерживать далее. На Clangd еще при этом не все работает. Но я надеюсь, что наша постоянная работа в этом направлении все же не остается совсем незамеченной)
А с конкретными "тормозами" лучше приходите в трекер или саппорт, посмотрим на конкретный CPU снэпшот и раскопаем конкретную проблему. Может, воркэраунд какой-то сразу подскажем.
Ребята упоминают довольно много фичей (навигация, find usages, UE reflection механизм, UE log, поддержка файлов INI & Blueprints, отладчик). Скажите, о чем конкретно было бы интересно более детально узнать?
Фишки Rider или самой игры? Про игры пока ребята не готовы много рассказать, пока она не вышла.
Мы смотрим, пока не очень понятно, чем ситуация отличается от той, где PCH нормально работают. Отпишемся, как будет больше ясности, в задаче.
Для начала лог IDE. Сложно пока попросить что-то больше. Надо разбираться
Как только она появится в Clang, автоматом после апдейта будет и в CLion уже что-то. А может, мы и раньше что-то сделаем. Но, если честно, пока в CMake модули не завезли, не очень понятно, куда нам торопиться)