Pull to refresh

Comments 54

Есть в планах выпуск Community Edition, хотя бы с урезанным функционалом, но с поддержкой дебаггера?

Пока нет. Не очень понятно, что и как урезать.
Например, выкинуть поддержку юнит-тестов, фреймворков (типа Qt), embedded- и удаленную разработку, поддержку экзотических систем сборки, ядра CUDA, шейдеры OpenGL/OpenCL/HLSL (если вы будете некоторые фичи из ReSharper C++ втаскивать в CLion), всякие штуки для enterprise-разработки типа консоли БД, динамические анализаторы, в т.ч. code coverage и valgrind.

Т.е. оставить базовый функционал, приблизительно как это было сделано в IntelliJ IDEA Community Edition: умный редактор кода, поиск/навигация, анализ кода на лету, локальный запуск и дебаг, поддержка GNU Make и CMake, документация Doxygen, SVN/git/..., поддержка плагинов.
Из парсера довольно сложны вырезать поддержку всяких штук типа CUDA. И вообще языковой движок – это практически основная наша работа. Да и то, что вы перечисляете для community, выглядит как довольно большой пласт функционала. Так или иначе, мы думали о такой возможности, но пока что решили, что не планируем выделять Community версию.
Планируется ли поддержка Meson?
CLion — первый продукт от JetBrains, который меня разочаровал. Настолько медленно работает с Qt, что пришлось вернуться к VS.
Да, я прочитал все ваши советы по ускорению работы: добавил памяти, отключил лишнюю инспекцию. Но автокомплит, как и подсветка имеют просто чудовищный отклик: напечатать какую-нибудь переменную с типом получается быстрее, чем получить ее.
А вот так сейчас проходит установка вашей новой версии:
image

Процесс не заканчивающийся уже добрых 25 минут. Взяли пример у Microsoft и решили тестировать продукт на кошках пользователях? Пришлось убивать руками.
И зачем вы в новой установке включили по умолчанию свой шрифт, а не выбранный пользователем? Он с ним работал, если бы этот шрифт мешал, он выбрал бы другой, это очевидно. Поломали плагины. Процесс обновления плагинов просто висит, приложение зафризилось. Но какая, однако, бодрая статья. Пока висит ваше приложение, пожалуй, еще раз перечитаю, мне же больше делать нечего теперь. (завершаю через диспетчер второй раз за утро).
Давайте, все же попробуем открыть проект, чтобы показать, что я имею ввиду под словом
ЧУДОВИЩНО:


на 21 секунде я вызываю автокомлит. Он не вызовется даже после того, как это минутное видео зальется на сервер. Наверное, это очень сложная и очень редко используемая функция IDE, поэтому на нее не стоит обращать внимание. Хотя ваши коллеги из PhpStorm почему-то с ней справились и даже на сложных фреймворках все выпадает во вполне себе бодром режиме.
Ваш продукт — сырой. Вот, что я могу вынести в качестве заключения. Мой проект крошечный по сути, использует один из самых известных C++ фрейморков в мире. И я не могу с ним работать в вашей среде.
И нет, не железо виновато. На всех трех используемых мной в работе машинах стоят ssd и не менее 8 GB RAM, core i5. И на самой быстрой из них автокомплит someFunction() начиная с первых двух символов названия класса получится примерно за 5-7 секунд.
Смешно, но средой разработки приобретенной за деньги у JetBrains я пишу совсем простенькие обучающие с++ вещи из нескольких классов (и в них автокомплит работает на ура) и редактирую CMakeList, а коммерческое приложение, которое дает мне хлеб (и позволяет продлять подписку на JetBrains) приходится разрабатывать на плохом с т.зр. реализации функциональности как среды, но вполне переваривающим мой проект Visual Studio.
Хочется спросить компанию JetBrains: извините, а вы можете просто сделать приложение работающим, без бодрых рапортов, но хорошо отлаженным и протестированным?
P.S. я не мазохист, если что. Расширил подписку, которая у меня была только на одну IDE из-за ударной работы ваших коллег из команды DataGrip, и поскольку перешел на плюсы. Не думал, что вы меня так подведете с одним из флагманских продуктов.
Мне искренне жаль, что у вас такой опыт с CLion. Так, конечно, не должно быть. Давайте посмотрим по порядку

1. Проблемы с медленным апдейтом, кажется, я уже видела. Это что-то именно в Toolbox вроде. Сейчас уточню у их саппорта, видели ли они такое на 2020.1 билдах. Без него патч накатывается вроде довольно бодро.

2. Про плагины — а без Toolbox они тоже долго висят и не обновляются? Можно тогда хотя бы idea.log попросить?

3. Про шрифт. Мы меняли дефолты. Вот тут объясняли, как это устроено и почему меняли. Если пользователь выбрал какой-то кастомный шрифт, переключения не должно было произойти, но кажется, какие-то проблемы все же с этим есть. Приносим свои извенения, если это и ваш случай.

4. Ну и наконец про автодополнение. Вообще судя по видео, там вообще код не порезолвился. Покраска дефолтовая. Надо бы посмотреть, что там произошло. Можете как-то пингануть в саппорте или в трекере нас? Нам скорее всего нужны какие-то логи, как минимум, чтобы поизучать.
«Код не прорезолвился», это, кстати, еще одна из проблем. Я понимаю когда он индексируется первый раз. И не понимаю, когда я загрузку системы получаю практически через каждое открытие проекта. Вот, полюбуйтесь,
переоткрыл ТОЛЬКО ЧТО закрытый проект
image
— это нормально по вашему?
А вот примеры автозаполнения с предыдущего «прорезолвенного» состояния (подсвечены методы и члены класса):
с методом класса-родителя
image

и никаким вовсе, хотя вот же он:
image

Относительно вашего предложения «пингануть» в саппорте. В данный момент я испытываю самые гнусные подозрения, что компания JetBrains подвержена согласно моей теории той же самой энтропии, что подвержены любые крупные IT компании, ломающие свои собственные продукты. И поэтому никакого особого смысла в сотрудничестве с такой компанией не будет. Обращу ваше внимание, что даже ваше предложение является делегирующим. Не "спасибо за описание, я создал(-а) тикет вот тут, вы можете его дополнить?", а "пинганите нас". Разница очевидна?
Уверен, что проблема не в том, пингану я вас или не пингану (спойлер: пингану), а проблема как раз в подходе к разработке, когда на транспаранте смеющиеся лица, а под капотом страх, боль и разочарование от компании, продукты которой постоянно советуешь использовать (спойлер: вчера был последний раз, после того как увидел вот эту «оду», понял, что ваша звезда закатывается и выбор продукта для разработки опять будет ситуативным, без бренда).
Я предложила написать в саппорт, потому что ситуация не нормальная, явно что-то идет не так в вашем случае, вероятно баги на нашей стороне. И мы бы очень хотели как минимум разобраться, а в идеале и постараться побыстрее поправить. Но по скриншотам, к сожалению, мы еще не научились догадываться до сути проблем. Довольно много зависит от окружения, тулчейна, настроек. Бывает еще, что падает clangd-движок и тоже к таким проблемам с парсингом приводит, но опять же это видно по логам, но не по видео. Мы обязательно заведем проблемы в трекере (и конечно с радостью сделаем это сами), как только разберемся соб-но, в чем проблема. Поэтому если не сложно, напишите на clion-support@jetbrains.com. Наши саппорт инженеры очень отзывчивы и всегда на связи с командой. Так что постараются посмотреть на запрос в ближайшее время.

(и да, повторной индексации на уже проиндексированном проекте происходить в штатной ситуации не должно, но что-то я подозреваю, что что-то там идет совсем не по плану)

Зря кстати. Тех поддержка вполне себе ОК.


C Qt-ными проектами сейчас грустновато немного. У меня CLion банально не может найти autogenerated файлы (типа uic_XXX.h). CPP-17487


На сравнительно небольших проектах/халтурках всё таки летает.


Но с чем-то тяжелым IDE таки начинает резко тормозить. По моим ощущениями тормоза пропорциональны количеству GTest-based кода. В моём случае это частично решилось хоткеем на 'killall clangd'… И частичным переключением в vim :)

Про Qt хедеры — а они находятся, если собрать проект и потом перезагрузить CMake?

Про тормоза, я понимаю недовольства. Мы действительно знаем про многие перфоманс проблемы. И над ними много работаем. Что-то исправляется как раз таки переходом на Clang, где-то требуеются большие архитектурные изменения или вообще принципиально новые подходы, но это тоже в процессе. Мы много пробуем, не все ест-но выходит в релиз. Вот за последние полгода мы несколько раз пробовали LightPSI, такая модель кода, которая будет не совсем корректной, но очень быстрой. Хотели ее построить и подпихивать платформе для тяжелых операций. Пока не вышло. Но у нас еще есть идеи в запасе) stay tuned!

Спасибо. Да. Получается что если сначала собрать всё (чтобы эти ui_ файлы появились), и потом перезагруить CMake проект (Tools -> CMake -> Reload CMake project), то таки со второго раза начинает находить. Но при этом если в такой файл перейти, то сверху в плашечке отображает "This file doesn't belong to any project target, code insight features might not work properly".


А вот с Clang интересно. У меня такое ощущение что из-за Clang тормозов только добавляется. Такое ощущение что IDE много где синхронно ждет чего-то от clangd и из-за этого зависает. C тем же включеным ClangFormat много где даже текст нормально вводить нельзя. Вот, например, в CPP-16887 я специально видео записал...


Сейчас у меня вообще выключен "Use navigation via clangd".

Это сообщение означает, что с точки зрения CMake как проекта, хедеры не входят в проект. CLion считает, что файл в проекти 1) если CMake про это сообщает или 2) если файл включен черезе include в файле, который в проекте.

Так а смысл этот файл генерировать если он не в проекте? Он как минимум через #include используется. Это воспроизводится на том же примере с CPP-17487.


GIF-ка

image

Это очень странно. Давайте мы глянем внимательно и ответим вам уже в тикете.
Clang как раз наоборот отвязан от EDT (UI потока), потому что это вообще отдельный процесс. И там по идее никаких таких ожиданий не должно быть. Другое дело, что Clang бывает крешится, мы такое изводим, но новые креши регулярно случаются с обновлением LLVM репозитория.

Фриз CPP-16887 кажется не с Clang связан. Смотрим.

В целом, мы не рекомендуем отключать наш движок на основе Clangd. Даже не смотря на креши, он, там где используется, показывает результаты не хуже, а зачастую лучше старого движка. А тормоза случаются, как правило, на стыках. И их надо, безусловно, нам править.
По поводу GTest. Если есть подозрение, что тормоза идут от тестовой подсистемы (вроде там все эффективно индексируется в фоне, но мир неидеален, могут быть баги, которые мы пропустили) — его можно подтвердить или опровергнуть отключением плагина поддержки GTests/BoostTest/Catch. Отдельно каждого или всех скопом. Расскажите потом, помогло ли! Может станет понятно, куда копать дальше
А вот так сейчас проходит установка вашей новой версии:
Процесс не заканчивающийся уже добрых 25 минут.

Он может и больше часа провисеть. Ставить лучше отдельным инсталлятором, а не через Toolbox.
Toolbox это bloatware в чистом виде.

Команде Toolbox очень бы хотелось логи получить, когда такое случается. На Windows они живут в \Users\\AppData\Local\JetBrains\Toolbox\logs. Отправить их можно на toolbox-support@jetbrains.com
Во многом отличная IDE, но не хватает мелочей, что приходится сидеть в двух IDE под window:
1. запуск в отдельном окне, а не вывод в окно clion. не все можно вывести в консоль.
2. при сборке и тестировании библиотек/плагинов нет возможности запустить стороннее приложение. да и перенаправить при сборке место куда положить бинарник нельзя. Да, тут можно накрутить cmake скрипт, но на постоянку не удобно
Спасибо. Попробую ответить по пунктам:
  1. Первое — это видимо вот этот реквест. На Windows есть с этим проблемы. Еще коллеги подсказали вот такую опцию для MinGW случая.
  2. Запуск стороннего приложения в рамках конфигурации? Можно указать любой executable в run configuration. И это как раз частый случай для библиотек и пр. А чтобы перенаправить бинарник можно использовать CMake параметр -DCMAKE_RUNTIME_OUTPUT_DIRECTORY=...
1. да, речь про этот реквест. очень ждемс
2. нашел, да, можно запустить. Но приложение так же консольное -)) и смотр пункт 1.
А тулчейн какой используется? Там просто есть большие проблемы с тем, чтобы это сделать. Не уверена, что быстро можем.
обновился, все хорошо, кажется даже лучше стало резолвить линки
В 2020.1 было несколько исправлений, связанных с symlinks, если вы про них.
Странный график IDE на ICPC. Очень удивлен что нет QtCreator'а в списке IDE. Местатми он даже лучше чем CLion

Интересно было бы узнать, будут ли подвижки в удалённой разработке? Тот функционал который есть очень куцый и с глюками (по крайней мере если CLion на Windows а разработка на Linux), есть открытые тикеты по этим глюкам но что-то воз и ныне там — и уже больше года.

План, безусловно, есть на дальнейшее развитие. И какие-то вещи в работе. Но предметнее чтобы обсудить, подскажите, пожалуйста, какие именно проблемы беспокоят. Можно сразу кинуть тикетами в меня, я посмотрю, какое состояние и планы.

Самая большая проблема — это невозможность работать с удалённым (remote) кодом напрямую, без локального маппинга, несмотря на то что есть функция "Edit remote file".


К сожалению, я не могу вспомнить тикет на эту тему, давно уже это было, но проблема всё ещё есть.


Локальный же маппинг (включая "in place") обладает как минимум одним существенным недостатком — нарушаются имеющиеся ACL (как обычные, так и POSIX), вплоть до того что каждое редактирование скрипта (т.е. выполняемого файла) сбрасывает "x" бит. Впрочем, справедливости ради, это проблема всех IDE (Idea/Rider/etc), не только CLion.


На самом деле, полноценная функция типа "Open remote project" с прозрачной работой с чем-то вдали по ssh/sftp (с сохранением всех атрибутов и ACL, кешированием всего что дорого каждый раз таскать etc) была бы просто супер, но что-то дело так и не пошло дальше обсуждений.

Локальный же маппинг (включая "in place") обладает как минимум одним существенным недостатком — нарушаются имеющиеся ACL (как обычные, так и POSIX), вплоть до того что каждое редактирование скрипта (т.е. выполняемого файла) сбрасывает "x" бит. Впрочем, справедливости ради, это проблема всех IDE (Idea/Rider/etc), не только CLion.

"Settings/Preferences | Appearance & Behavior | System Settings | Synchronization | Use "safe write" (save changes to a temporary file first" — попробуйте отключить эту опцию если она включена.

Тикет — CPP-15986. Штука действительно классная и будет очень востребована, но это довольно сложная задачка. И пока мы только обсудумываем варианты, как к ней вообще подступиться. Конкретный планов или естимейтов пока нет.


У нас есть галочка preserve permissions, но она имеет смысл только на Unix. Починить слетающие permissions на той же Windows пока не понятно как.

Улучшенное автодополнение — это, мягко говоря, громко сказано. Оно действительно какое-то время назад изменилось, но не вполне в лучшую сторону. Теперь оно очень любит подсказывать всякие длинные и безумные штуки, часто начинающиеся с нескольких подчеркиваний. Особенно это видно, когда хочется вызвать метод find у std::string: тогда автодополнение любезно предложит простыню довольно специфичных методов find_first_not_of.
А беду с областями видимости переменных так и не починили. Например, на просьбу в следующем коде переименовать счетчик последнего цикла с 'i' на 'j' Clion уже пять лет исправно отвечает: «Local variable 'j' already exists in the scope».

for (int i = 0; i < n; i++)
	for (int j = 0; j < n; j++);

for (int i = 0; i < n; i++)
	for (int i = 0; i < n; i++);

У меня вот на 2020.1 для s.find первыми идут find варианты. Может, от тулчейна как-то зависит. Спрошу коллег, которые делают clang-based автодополнение. А вы не уточните какая платформа и какой тулчейн используется?

Про области видимости — да, это, конечно, косяк. Попробую узнать, почему он затерялось с поля видимости. Спасибо за пинг.
Debian, все дефолтное. Я только что перепроверил, и действительно, первый вариант find, а потом find_first_not_of. Похоже, мой косяк, и это относилось к предпоследней версии, а сейчас уже все хорошо (и даже vector автодополняется без лишних круглых скобочек). Если так, то прошу прощения. Еще одна гипотеза состоит в том, что это может не проявляться на небольших файлах, где все автодополнение работает быстро (а там, насколько я помню, работает два разных автодополнения, одно побыстрее и одно получше), но ее я сейчас проверить не могу.
Ну, в 2020.1 действительно поменялось поведение автодополнения. Раньше мы объединяли результаты от старого языкового движка и от Clang-а. И там были проблемы с приоритетами. В 2020.1 мы довели автодополнение на Clang до ума, пофиксили кучу проблем, и по умолчанию включили режим, где работает только один провайдер — Clang.
UFO just landed and posted this here
Так там большая часть уже скоро сама подъедет, вместе с Clang-ом, во всех базовых вещах вроде автодополнения, подсветки, локальной навигации, анализы. Так что нам остается только писать что-то более умное, в рефакторингах, специфических анализах, и прочем. Соб-но, concepts уже есть с прошлого релиза, например. А что именно интересует? Расскажите, какие возможности бы хотелось иметь в первую очередь?
UFO just landed and posted this here

А Вы когда концепты пробовали, случаем не имели Clangd выключенным? Проверьте, пожалуйста, в настройках. Если будет красный код при включенном Clangd, заведите пожалуйста багу в трекере.


Про анализы идея здравая. Мы в целом, о чем-то таком думали, но пока переключились на другие задачи. Мы обсудим, вдруг кто-то из ребят захочет сделать такую "киллер-фичу" )

Хорошие новости, что вы продолжаете радовать нас новыми релизами! Жду с нетерпением хотя бы базовой поддержки Qt/QML. Но… мне тоже пришлось откатиться на 2019-ю версию :( Что-то с производительностью явно пошло не туда. Элементарная прокрутка в редакторе — слайдшоу, даже после того, как все проиндексировалось и ноут наконец-то затих. Не знаю как (и нужно ли?) оформить на это баг, потому что «формально» все окей, а по факту… вот.
Для QML есть плагин, не пробовали?

Производительность, если не сложно, порепортите пожалуйста. Если фриз — то thread dump, если просто медленно — CPU snapshot. Мы поизучаем. Заранее спасибо.
Спасибо. Обновился. Такое чувство что сменили шрифты. Привыкну))
После обновления ругнулся что плагин «CLion CUDA Run Patcher» что не совместим — ну и ладно, все равно не заметил от него пользы.
«Красный» в CUDA файлах действительно пропал — это радует))

Мне наверно эти 5 лет понадобились чтобы переехать на CLion, до этого каждые полгода пробовал, постоянно чего то сильно не хватало.
Но о чем мечтал так и нет: полной клиент серверной работы — исходники парсит на сервере, клиент отображает удаленно. Возможно это слишком сложно.

А вот по мелочи:

Настроено deployment по ssh на удаленный сервер, настроен mapping папки локальной bin (тут складываются готовые бинарники после компиляции) в папку bin на удаленном сервере. Вроде хорошо все: если в дереве проекта открыть папку bin, выбрать нужный бинарник, правой кнопкой и Upload to serv — то файл улетает на сервер, о чем появляется запись в логах. Но есть в настройках настройка Automatic Upload (always). Как мне казалось, что после локального обновления бинарников (из за перекомпиляции) в папке bin, будет автоматом загрузка их на сервер, но это функциональность не работает, приходится каждый раз мышкой тыкать Upload to serv на каждом файле. Может я не так понял назначение этой фичи? (система везде CentoOS 7)

Ест ОЗУ конечно CLion не мало, на больших проектах, на 2 ГБ выделенных ему отказался работать, пришлось поднять квоту до 4. Ну наверное за удобство надо платить ресурсами))

Шрифт по идее должен был поменяться только дефолтный (на наш новый JetBrains Mono), но были замечены ситуации, когда кастомный пользовательский шрифт тоже изменялся. Приносим извинения, если это так.


CUDA диалект теперь и правда поддерживается нативно. Красного кода быть не должно больше.


Но о чем мечтал так и нет: полной клиент серверной работы — исходники парсит на сервере, клиент отображает удаленно.

Да, сейчас и правда другой режим. С исходным кодом работа на машине клиента, а запуск и отладка происходят на удаленной машине. Но то, о чем вы говорите, такое мы тоже активно сейчас обсуждаем и пробуем как-то подступиться к задаче. Не только в CLion, в рамках всех наших IDE в целом. Изучаем подходы.


Про deployment по ssh, отвечу чуть-чуть позже. Уточню детали у коллег.

Шрифт по идее должен был поменяться только дефолтный (на наш новый JetBrains Mono)

Да, стоял дефолтный, он и поменялся.

Но то, о чем вы говорите, такое мы тоже активно сейчас обсуждаем и пробуем как-то подступиться к задаче. Не только в CLion, в рамках всех наших IDE в целом. Изучаем подходы.

Думаю это будет прорывная вещь, я такого нигде не видел в IDE (только в некоторых специфических HPC программах), можно было бы вести комфортную разработку с моего любимого старенького макбука например, при этом отлаживая код на разных архитектурах и ОС. А так пришлось завести отдельно машину под CentOS x86_64, а для архитектуры POWER8+ вообще в полу ручном режиме приходится.

Про шрифт тогда так и задумывалось. Надеемся, что он вам понравится. Если же нет, всегда можно поменять в настройках.

Про deployment по ssh. Можете, пожалуйста, проверить, что у вас не включена галочка в Build, Execution, Deployment | Deployment | Options | Skip external Changes?

Вау! Спасибо огромное!!! все работает! Счастья теперь на весь день)
А кто занимается разработкой плагина для Rust? Есть информация когда будет поддерживаться дебагер от Microsoft компилятора? Иногда попадаются зависимости которые не собираются из коробки под другой компилятор в windows. Таким образом приходится выбирать, либо искать другую зависимость либо прощай дебаг.
Для сведения Visual Studio Code работает с Microsoft компилятором для Rust.

Ребята, которые отвечают за Rust плагин, говорят, что они про такой запрос знают. И даже пытались завести наш LLDB для MS тулчейна, который для C++ у нас на Windows, для Rust чтобы заработал. Вот по образу и подобию как раз этого расширения — https://github.com/vadimcn/vscode-lldb. Но пока не получилось.

Спасибо за развитие проекта! В целом всё работает, хоть и со своими особенностями. Планируется ли поддержка GDB более старых версий, например 7.0.1? (использую на удаленной машине)

Честно сказать, сильно сомневаюсь. И GDB, и LLDB проекты доовльно активные, развиваются, улучшаются. И поддерживать старые версии становится очень накладно, да и зачастую там случаются проблемы, которые в рамках старых версий никак не обойти. Поэтому мы стараемся держать широкий, но все же не слишком, дапазон поддерживаемых версий. Поэтому сейчас для GDB диапазон 7.8.x-8.3.x

Sign up to leave a comment.