Comments 139
Что теперь будет с Consulo?
Думаю, что суть в том, что в VS нелья отключить встроенный анализатор кода. Потому в 32-битной VS сейчас тупят и Resharper и Roslyn. Видимо JetBrains не договорились с MS, вот и решили строить свой лунапарк. Собственно, давно пора, а то я уже не знаю какой компьютер нужно купить, чтобы не видеть
Два сетапа:
I5 Second Gen, SSD, 16GB мозгов.
I7 Second Gen, SSD, 16GB мозгов.
Проект на обычном hdd. Кеш решарпера на SSD и студия там же.
Такое обычно при работе с git Только, когда между брэнчами переключаюсь и то редко.
Обычно запущено около 3 студий.
Хотя в 15 конечно потормознутее стало :( Плюс она темы портит.
I5 Second Gen, SSD, 16GB мозгов.
I7 Second Gen, SSD, 16GB мозгов.
Проект на обычном hdd. Кеш решарпера на SSD и студия там же.
Такое обычно при работе с git Только, когда между брэнчами переключаюсь и то редко.
Обычно запущено около 3 студий.
Хотя в 15 конечно потормознутее стало :( Плюс она темы портит.
Подозреваю, что немного не так. Из-за тупления решарпера и рослина в студии пришлось выносить решарпер в отдельный процесс. А если выносить решарпер в отдельный процесс, что бы за компанию не прикрепить его практически на халяву к собственной идее? На винде конкурировать со студией идея не может: всякие UWP и прочий зоопарк проектов идея поддерживать не будет, впрочем при зоопарке немелкомягких технологий и очень ограниченном использовании мелкомягких какая-то небольшая конкуренция может быть. Это всё имеет смысл для линукса, где кроме монодевелопа и игрушек типа атома ничего нет, но на линуксе и студии, собственно, нет. Так что ссоры с МС и даже поводов для неё я не вижу. Джетбрейнс пытается занять пустую нишу, по сути.
Вы бы почитали что авторы пишут. Отдельный процесс решарпера там потому что IDE на Java. Они не захотели портировать решарпер на Java. Поэтому отдельный процесс и обмен с помощью бинарного протокола.
Вы бы почитали, что авторы в других статьях пишут. ;) У них дотнетовый решарпер в VS 2015 умирает под нагрузкой до такой степени, что они сами им пользоваться не могут. Невозможность использования решарпера на больших проектах в VS 2015 — согласитесь, гораздо более серьёзная проблема для джетбрейнс, чем возможность писать консольные приложения на шарпе под линуксом в крутой IDE. :) И все эти «оптимальные бинарные протоколы» тоже произрастают из проблем с ресурсами в VS.
Вы уверены, что в VS 2015 умирает Решарпер? Умирает студия изза недостатка свободной памяти, которую очень хорошо выжирает «новый модный» Roslyn. Изза этого начинает работать Blocking GC, который тормозит UI поток студии. Решарпер тоже поедает память, хотя и не сильно много, но по крайней мере в нем нет кода подобного while (freemem < 300 * 1024 * 1024) { GC.Collect(); Thread.Sleep(100); }, а в студии есть.
Rider (работающий на решарпере), открывает солюшен ~300 проектов примерно в 2 раза быстрее, чем это делает студия. И во время открытия можно без проблем тайпить в документе в отличие от студии.
Для интереса, найдите солюшен в 300-400 проектов, откройте его в VS2015 и попробуйте найти наследников какого-либо часто наследуемого класса (с колвом наследников от 50), после этого студию с ее «инновационным» рослином придется убить
Rider (работающий на решарпере), открывает солюшен ~300 проектов примерно в 2 раза быстрее, чем это делает студия. И во время открытия можно без проблем тайпить в документе в отличие от студии.
Для интереса, найдите солюшен в 300-400 проектов, откройте его в VS2015 и попробуйте найти наследников какого-либо часто наследуемого класса (с колвом наследников от 50), после этого студию с ее «инновационным» рослином придется убить
Извините, но вы не правы.
Извините, но я разрабатываю решарпер около 3 лет и профилировал студию вместе с ним не одну сотню раз и знаю, о чем говорю. И сейчас я разрабатываю Райдер и тоже знаю, о чем говорю, сравнивая скорость работы студии и решарпера на одинаковых проектах. Решарпер далеко не идеален, но в студии гораздо более серьезные факапы, которые никто не собирается фиксить и на которые мы никак не можем повлиять, даже имея прямой контакт с разработчиками студии, слишком много бюрократии у MS. Я всего лишь пытаюсь возразить, что тормоза в студии с включенным решарпером далеко не всегда по вине самого решарпера, а по вине нехватки памяти в 32битном процессе. Если вам хорошо на Рослине, удалите решарпер и живите на рослине, однако на 300 проектах, рослин помирает и без решарпера. А если пользователь привык к решарперу, то выкат VS2015 вставляет ему большие палки в колеса изза невозможности отключить рослин и жить только с решарпером.
А я больше лет пользуюсь решарпером, и знаю, где тормозит решарпер, а где студия. И с вашей компанией я это обсуждал много раз, но отчаялся и теперь перехожу с решарпера на более эффективные инструменты.
Например, какие?
Чужой список. Заменить я не смог разве что R# Build.
А можно подробнее про вашу проблему, которую вы много обсуждали с нашей компанией. Действительно интересно.
Отвечу отдельно по всем:
1) RSRP-448070 «Find Usages» speed depends on how common the name of searched item is
Да, это действительно так, множество файлов поиска зависит от того, какой идентификатор ищется. Т.е. если идентификатор Type встречается в 1000 файлах, то действительно поиск пройдет по всем этим файлам (конечно, если эти файлы достижимы по проектным зависимостям).
Я сейчас специально провел эксперимент, сделал поиск идентификатора Language, который встречается десятки тысяч раз в нашем проекте, с помощью решарпера и с помощью студийного поиска (который видимо уже на рослине):
а) Рослин — 1мин 3секунды, потребление памяти возросло на 800мб, блокирует на все время поиска окно студии
б) Решарпер — 28 секунд, потребление памяти возросло на 150мб, ищет асинхронно, можете делать параллельно, что угодно
Что же вам удобнее?
2)RSRP-447915 Opening «Add New Item» on a folder spins 1 CPU core 100%
Вам показали стектрейс, в котором явно видно, что факап студии. Да он возникает изза нехватки памяти, но это один из тех кусков кода, где в цикле вызывается GC.Collect(). (и такой кусок не один в студийном коде)
Как нам с этим бороться? да, мы пытаемся экономить память, но судя по всему, только мы этим и занимаемся
Кстати сам натыкался на этот факап много раз
3) RSRP-446534 «Find code dependent on module» freezes main VS window
Вероятно наш продолб, отрицать не буду. Просто редко использую эту фичу, сам не натыкался
4)RSRP-447853 Opening R# IntelliSense is a CPU-bound operation that does not scale with project size
Не отрицаю, что проблема есть, но сам не смог воспроизвести. Комплишен поднимается всегда. R# 10.0.2
5)RSRP-447916 Pasting anything into ascx/aspx files hangs VS for 20 seconds
Вроде бы вы вместе разобрались, что это баг не решарпера, и вопроизводится без решарпера вообще.
Т.е. из тех 5 перформанс проблем, что вы зарепортили, действительно наших — две, и по обеим из них вроде бы вы даже получили ответы.
1) RSRP-448070 «Find Usages» speed depends on how common the name of searched item is
Да, это действительно так, множество файлов поиска зависит от того, какой идентификатор ищется. Т.е. если идентификатор Type встречается в 1000 файлах, то действительно поиск пройдет по всем этим файлам (конечно, если эти файлы достижимы по проектным зависимостям).
Я сейчас специально провел эксперимент, сделал поиск идентификатора Language, который встречается десятки тысяч раз в нашем проекте, с помощью решарпера и с помощью студийного поиска (который видимо уже на рослине):
а) Рослин — 1мин 3секунды, потребление памяти возросло на 800мб, блокирует на все время поиска окно студии
б) Решарпер — 28 секунд, потребление памяти возросло на 150мб, ищет асинхронно, можете делать параллельно, что угодно
Что же вам удобнее?
2)RSRP-447915 Opening «Add New Item» on a folder spins 1 CPU core 100%
Вам показали стектрейс, в котором явно видно, что факап студии. Да он возникает изза нехватки памяти, но это один из тех кусков кода, где в цикле вызывается GC.Collect(). (и такой кусок не один в студийном коде)
Как нам с этим бороться? да, мы пытаемся экономить память, но судя по всему, только мы этим и занимаемся
Кстати сам натыкался на этот факап много раз
3) RSRP-446534 «Find code dependent on module» freezes main VS window
Вероятно наш продолб, отрицать не буду. Просто редко использую эту фичу, сам не натыкался
4)RSRP-447853 Opening R# IntelliSense is a CPU-bound operation that does not scale with project size
Не отрицаю, что проблема есть, но сам не смог воспроизвести. Комплишен поднимается всегда. R# 10.0.2
5)RSRP-447916 Pasting anything into ascx/aspx files hangs VS for 20 seconds
Вроде бы вы вместе разобрались, что это баг не решарпера, и вопроизводится без решарпера вообще.
Т.е. из тех 5 перформанс проблем, что вы зарепортили, действительно наших — две, и по обеим из них вроде бы вы даже получили ответы.
Опять двадцать пять.
Все 4 открытых кейса мне кажутся именно проблемами решарпера, а не студии.
Вот вы говорите, что вам памяти не хватает. Вместе с или около выхода Rider же будет релиз out-of-process R#? Давайте поспорим, что не станет out-of-process R# и/или Rider быстрее, даже если ему дать, скажем, 10 ГБ памяти? Если оно будет хотя бы сравнимо по скорости с VS 2015 (или какая там будет на тот момент), то я куплю/продлю персональную лицензию и всерьёз рассмотрю возможность поддержки R# и/или Rider в компании. (Дополнительное требование для Rider — чтобы это была настоящая замена VS без очевидных шоустопперов, с поддержкой MSBuild, с возможностью удалённого дебага, интеграцией с git, поддержкой веб-языков хотя бы без on-save компиляторов и большинством фич R#)
Потому что ну вот не верю я, что все ваши проблемы связаны с нехваткой памяти. Как-то же CodeLens умудряется влезать в 275 мегабайтов памяти (пусть и в отдельном процессе) и при этом мгновенно искать референсы по всему солюшену.
Что же вам удобнее?В кейсе написано, что у меня R# медленнее раз в 100-1000. Про асинхронность тоже не совсем правда — CodeLens полностью асинхронный, а поиск решарпера заметно больше тормозит студию, потому что использует в 4 раза больше потоков, и периодически самоотменяется («Find Usages has been canceled» или что-такое). Может быть под поиском рослином вы что-то другое имеете ввиду, о чём я не знаю?
Вам показали стектрейс, в котором явно видно, что факап студии. Да он возникает изза нехватки памяти, но это один из тех кусков кода, где в цикле вызывается GC.Collect(). (и такой кусок не один в студийном коде)Потребление памяти 1 ГБ и растёт, а не уменьшается. Без решарпера не повторяется.
но сам не смог воспроизвестиТам есть видео.
Все 4 открытых кейса мне кажутся именно проблемами решарпера, а не студии.
Вот вы говорите, что вам памяти не хватает. Вместе с или около выхода Rider же будет релиз out-of-process R#? Давайте поспорим, что не станет out-of-process R# и/или Rider быстрее, даже если ему дать, скажем, 10 ГБ памяти? Если оно будет хотя бы сравнимо по скорости с VS 2015 (или какая там будет на тот момент), то я куплю/продлю персональную лицензию и всерьёз рассмотрю возможность поддержки R# и/или Rider в компании. (Дополнительное требование для Rider — чтобы это была настоящая замена VS без очевидных шоустопперов, с поддержкой MSBuild, с возможностью удалённого дебага, интеграцией с git, поддержкой веб-языков хотя бы без on-save компиляторов и большинством фич R#)
Потому что ну вот не верю я, что все ваши проблемы связаны с нехваткой памяти. Как-то же CodeLens умудряется влезать в 275 мегабайтов памяти (пусть и в отдельном процессе) и при этом мгновенно искать референсы по всему солюшену.
В кейсе написано, что у меня R# медленнее раз в 100-1000. Про асинхронность тоже не совсем правда — CodeLens полностью асинхронный, а поиск решарпера заметно больше тормозит студию, потому что использует в 4 раза больше потоков, и периодически самоотменяется («Find Usages has been canceled» или что-такое). Может быть под поиском рослином вы что-то другое имеете ввиду, о чём я не знаю?
Я подождал 3.5 минуты для того, чтобы codelens показал мне кол-во ссылок на проперти Language. Это на машине core i7, 32gb ram. Впечатляющая производительность. Особенно если мне нужно найти референсы 5-10 раз подряд на разные символы. А в предыдущем комменте я говорил про экшн студии Find all references.
Потребление памяти 1 ГБ и растёт, а не уменьшается. Без решарпера не повторяется.
Так что из этого? Тормоза то, которые вы видите, порождаются от GC.Collect()
Потому что ну вот не верю я, что все ваши проблемы связаны с нехваткой памяти. Как-то же CodeLens умудряется влезать в 275 мегабайтов памяти (пусть и в отдельном процессе) и при этом мгновенно искать референсы по всему солюшену.
см. выше
Если оно будет хотя бы сравнимо по скорости с VS 2015 (или какая там будет на тот момент), то я куплю/продлю персональную лицензию и всерьёз рассмотрю возможность поддержки R# и/или Rider в компании
оно быстрее студии уже на данный момент
Я ни разу вас не уговариваю уйти со студии. Если вам хорошо разрабатывать в студии, то это отлично. Просто не стоит в каждом фризе студии винить решарпер, есть куча причин по которым оно может тормозить, но, я заметил, пошла такая мода, в случае любого подвисания студии все стрелки переводить на «тормозной убогий решарпер»
Я ни разу вас не уговариваю уйти со студии. Если вам хорошо разрабатывать в студии, то это отлично. Просто не стоит в каждом фризе студии винить решарпер, есть куча причин по которым оно может тормозить, но, я заметил, пошла такая мода, в случае любого подвисания студии все стрелки переводить на «тормозной убогий решарпер»А какой реакции вы ожидаете, когда без решарпера всё летает?
оно быстрее студии уже на данный моментОК, ждём
По-моему, это просто называется «вместе не уместились», и искать крайнего — бесполезное занятие.
Ну а сравнивать оптимизации решарпера и рослина, учитывая, сколько каждому из них лет — это неспортивно.
Ну а сравнивать оптимизации решарпера и рослина, учитывая, сколько каждому из них лет — это неспортивно.
Microsoft на захотели сделать галку для отключения рослина. Так что крайний тут очевиден.
А с чего им это делать вдруг?
Ну я даже не знаю. Может быть, потому, что по разным оценкам от 10% до 20% пользователей студии используют решарпер?
И теперь наверняка начнет падать, потому что рослин много чего умеет сам. Крайний в любом случае решарпер. Продукт свой МС вольна делать так, как захочет. Хочется улучить анализ кода своими силами — их право, пользователи только в выигрыше. Ведь основная часть аудитории таки решарпером не пользуется.
Я так понимаю, на этот рослин в студии много чего завязано, и будет завязано ещё больше. Разные расширения от него зависят. Предлагаете мелкомягким реализовывать фичи в двух версиях: через рослин и через решарпер? Вы фантазёр.
Предлагается предоставлять опцию отключить рослин и все фичи, зависящие от него. Редактировать документ можно и без рослина. Подчеркну — это только для тех, кому роднее фичи решарпера. Однако, такой опции никто не предоставил.
Не знаю, как конкретно сейчас реализовано, но могу предположить, что дизайнеры форм для WPF и WinForms, окошко с иерархией классов, всякие выпадающие списки с членами и ещё 100500 вещей могут зависеть от рослина. Не зависят сейчас — будут зависеть в будущем.
А теперь берём и отрубаем рослин. Отрубать все зависящие фичи? Вы уверены, что вы на это согласитесь?
А теперь берём и отрубаем рослин. Отрубать все зависящие фичи? Вы уверены, что вы на это согласитесь?
И вряд ли предоставит. Студия это не конструктор для сообщества. Это самодостаточный продукт. Рослин всяко внедрен в систему настолько, что отключить просто так его не получится. А делать это ради решарпера… Пусть решарпер вот и крутится, он плагин. Не может — его проблема. Делайте свою IDE. Мне понятна сторона разработчика плагина, что ему все мешает, но это абсурд.
Угу. поэтому, видимо, вынесение решарпера в отдельный процесс решит проблему с кончающейся памятью? Я, если что, тоже работаю с решарпером на большом проекте (около 100 проектов в солюшне). И основная проблема там в недостатке памяти.
ну если еще плагинчик для Vala (с поддержкой GTK) под линуксовую версию напишут, то цены джетбрейнсу действительно не будет
Раньше Visual Studio была самой лучше IDE для C#, сейчас в игру вступают JetBrains с их опытом… Это будет интересно)
с опытом из более правильного мира Java, вы хотели сказать
Ну зачем же вот так, сразу…
Наверное это будет неожиданно. Но у JetBrains есть опыт разработки IDE для Python, Ruby, PHP, JS и С++. И многие из них являются, практически, стандартами индустрии.
Интересно что ответят представили JetBtrains о целевой аудитории.
Все-таки студия это огромный комбайн который может очень много чего, а не только редактор кода.
Все-таки студия это огромный комбайн который может очень много чего, а не только редактор кода.
Ну так и Москва не за день строилась. Главное, что есть шаг. А ещё главнее, что это шаги от JetBrains, потому что кто-кто, а они умеют пилить продукты.
Там проблема не в функционале самой студии, а в функционале тучи дополнений под неё разного рода.
Подтянутся в течении пары лет, если мс не изменит темп врыва в опенсурс, не?
Кто подтянется? Авторы дополнений? Писать дополнения под платную IDE от JB при бесплатной-то студии?
Ну сегодня платная, завтра условно-бесплатная. Студия-то тоже изначально платный продукт был (или мы express считаем бесплатной и достаточной?)
Там ещё проблема в том, что дополнения должны работать под JVM. Для дотнетной IDE, да.
Бесплатная версия Visual Studio сейчас называется Community. Она бесплатна для индивидуальных разработчиков и не сильно отличается от Professional версии, за исключением поддержки TFS.
Да. Community, но она равна Professional по функционалу.
www.visualstudio.com/ru-ru/products/compare-visual-studio-2015-products-vs.aspx
www.visualstudio.com/ru-ru/products/compare-visual-studio-2015-products-vs.aspx
У меня TFS в VS 2015 Community работает, несмотря на написанное на сайте.
Community бесплатна для Indy и небольших команд
UFO just landed and posted this here
… да и не под каждой виндой-то (вин 10 х64)…
Слышали когда-нибудь поговорку: «на заборе тоже написано, а там дрова лежат»? :)
Что не так со студией под вин 10 х64? Установлены студии 2012, 2013, 2015, все работает как должно работать.
Карма -3 подсказывает мне что мой фидбек никому не нужен, забейте.
А логика подсказывает, что о большинства студия на заявленных системах работает. И Если бы вы начали не с наезда, а с проблемы с которой столкнулись лично вы, то, вероятно, вам бы помогли. Но выбор ваш…
Как это плюнуть, с неудовольствием наблюдаю -5.
По сути — не устанавливается. Пробовал и на апгрейженой с вин7 и на чистой вин 10 про и на чистой вин 10 хоум (как она там)… Не может скачать файлы какие-то, а если скачивает — не ставит. В обоих случаях — установщик просто висит не подавая признаков жизни.
По сути — не устанавливается. Пробовал и на апгрейженой с вин7 и на чистой вин 10 про и на чистой вин 10 хоум (как она там)… Не может скачать файлы какие-то, а если скачивает — не ставит. В обоих случаях — установщик просто висит не подавая признаков жизни.
У меня такая же проблема была. Решилось запуском с ключом тихой установки.
Грешу почему-то на видеодрайвер новый для амд.
Грешу почему-то на видеодрайвер новый для амд.
Я пробовал на разных компах (ноут и комп) и при этом натрёх разных видеокартах (нвидия, амд, интел), в разных местах (разный интернет), также — как уже писал — на разных виндах. Думаю что проблема всё таки не на моей стороне…
Пруф, что VS2015 работает на Windows 7. У меня она установлена на двух машинах — всё поставилось без нареканий. Может быть, вы ставите на необновлённую систему? На Windows 7 как минимум должен стоять Service Pack 1.
лог сетапа смотрели?
У меня была проблема с зависанием во время установки. Решилось открытием таскбара и убиванием процесса, который завешивал сетап — решение.
Я приведу пример WPF редактора. Он вам точно нужен? Точно? Когда он вообще последний раз правильно формочку отрисовывал? Воот. Но если серьезно, да, будут дизайнеры и технологические стеки которые с начала не будут поддержаны т.к. это тяжело и нужны большие усилия.
Все время, что им пользовался, вроде правильно отрисовывал, по крайней мере в 12-13 студиях. Мне точно нужен, но мне и студии хватает. Потребности в сторонней IDE для этого нет и вряд ли будет. Тем более для WPF, который до сих пор только Windows. В любом случае на Windows потеснить студию вряд ли получится ни в ближайшем, ни далеком будущем. А вот на linux/mac в свете движения .Net туда будет очень здорово видеть что-то полноценное.
WPF технологически устарел, но вот что-то новое, тот же Perspex, видеть из коробки в Rider было бы очень круто.
WPF технологически устарел
Странное умозаключение. Посмотрел примеры Perspex и его paml — практически копия xaml. Ну да ладно, WPF в любом случае никуда не денется с позиции основного инструмента UI приложений на Windows. По крайней мере, пока MS стоят за ним и поставляют в комплекте. Они как раз вновь подтвердили, что WPF — это тот самый и единственный выбор на Windows платформе.
тот же Perspex, видеть из коробки в Rider было бы очень круто.Perspex-овский дизайнер, мы, вероятно, будем таки выносить в полностью автономный процесс вместе с текстовым редактором paml. Это как позволит редактировать .paml с предпросмотром и автодополнением без какой-либо IDE, так и существенно облегчит его встраивание в разные IDE (MonoDevelop, SharpDevelop, Rider, ну и та хреновина, которую сейчас на самом Perspex-е делают).
Говорить же о технологическом превосходстве перспекса над WPF пока достаточно рано и немного смешно — у нас даже VirtualizingPanel ещё нет.
Если вопрос ко мне, то да, WPF редактором пользовался, довольно много, глобальных проблем не возникало. На мой взгляд, для desktop разработчика штука нужная.
И снова Java, на которой на некоторые шрифты без слёз и не взглянуть?
Они именно поэтому таскают с собой свою патченую java.
Сами посудите:
Это патченая java? VS 2015 / WebStorm 11.0.1
Заголовок спойлера
Мне хочется плакать, когда я вижу кернинг наподобие того что справа.
Это патченая java? VS 2015 / WebStorm 11.0.1
UFO just landed and posted this here
Для monospace шрифтов вроде бы нет понятия «кернинг», а другими в редакторе кода и не пользуюсь. Рендеринг глифов справа вроде бы вполне нормальный.
Такое ощущение, что вы типограф, а не разработчик :) Я на первой картинке вообще разницы почти не вижу.
Хак удаляет хинтинг, к кернинг по идее не затрагивается. Видимо сглаживание тоже влияет косвенно на кернинг. Но, повторюсь, для monospace понятия кернинг нет, ширина позиций фиксированная.
P.S. на Linux, всё по умолчанию шрифт выглядит так:
https://habrastorage.org/files/5ef/a5f/f2c/5efa5ff2cfff4159b18619e76c4f86a6.png
java — jre8-openjdk
P.S. на Linux, всё по умолчанию шрифт выглядит так:
https://habrastorage.org/files/5ef/a5f/f2c/5efa5ff2cfff4159b18619e76c4f86a6.png
java — jre8-openjdk
У вас одно условие лишнее в коде.
Это первая попавшаяся копипаста :)
По мне, так от качества обоих шрифтов глаза текут немного.
IDEA 15, правда под маком. Но тут со шрифтами всё просто отлично.
а я вижу мыло. Возможно все дело в монике, конечно…
Даже с патченной java от jetbrains, сглаживание шрифтов на маке достаточно сильно отличается от нативного. Но все равно намного лучше, чем сглаживание в Java 8 от Oracle (в коробочной Java 1.6 сглаживание хорошее, но иде моргает и тормозит немного)
Кстати, вот пришло время оффтопа. Этой проблеме лет 10, если не больше. Про неё все знают, все плюются. По сети гуляют патчи, так что, кому не страшно повторить квест со сборкой OpenJDK, таки собирают его пропатченный и радуются шрифтам. Там и проблема-то в том, что настройки хинтинга жёстко прибиты гвоздями и не читаются из системных конфигов. Так почему разработчики OpenJDK до сих пор не исправят проблему (дело пары десятков строк кода) или хотя бы не примут патч в основную кодовую базу? ИМХО, стыд.
There are no plans for F# right now.
Ну, как всегда…
Я помню JB не так давно утверждали, что конкурировать со студией им не резон, им такой комбайн не потянуть.
Видимо, просто обкатывают out-of-process ReSharper
Видимо, просто обкатывают out-of-process ReSharper
А конкретно вот тут утверждали: www.youtube.com/watch?v=mUKg6RwUd_Q
После того, как МС пообещали нормальную кроссплатформенность для дотнета и начали делать VS Code, стало очевидно, что JetBrains долго тупить не будут.
Каждый раз запуская Xamarin Studio я очень жалел что нет альтернативы от JetBrains или хотя бы плагина к Xamarin Studio c фишками Resharper-а. Сейчас очень много кода пишу на этой платформе и порой пишу на маке. Очень надеюсь что когда нибудь будет полноценная поддержка Xamarin. За такой продукт заплатил бы с удовольствием, несмотря на наличие бесплатного Xamarin Studio.
Xamarin CEO:
Congratulations to JetBrains on the launch of @JetBrainsRider! We're looking forward to supporting it at Xamarin.
— Nat Friedman (@natfriedman) 13 января 2016
Эх, ну какая кросс-платформенность без ондроеда, а я уж было поверил заголовку…
Это супер новость, два дня назад я узнал что ASP 5 добавили в Xamarin, а теперь такой подарок от JetBrains!!!
Надеюсь будет возможность попасть в закрытый бета тест, и можно будет не включать Parallels…
Надеюсь будет возможность попасть в закрытый бета тест, и можно будет не включать Parallels…
Не в обиду JetBrains, но вы ребята сильно распыляетесь. Понятное дело, что разные люди занимаются проектами, но Clion развивается ну очень медленно.
Это вообще две никак не связанные команды. И вряд ли развитие Project Rider как-то повлияет на CLion, ну разве что в положительном плане, так как, очевидно, будут какие-то фиксы в платформе.
А что лично Вам не хватает в CLion?
А что лично Вам не хватает в CLion?
с11, makefiles и кучу других вещей.
Я уже на трекере голосовал, но по-моему на эти голоса особо то и не смотрят.
Я уже на трекере голосовал, но по-моему на эти голоса особо то и не смотрят.
Смотрим, еще как. Но как раз таки именно поэтому пока другие задачи в приоритете (Python, attach to process, variadic templates).
Makefile — тут вообще своя история, мы ее пытались в посте отразить. Если кратко, чтобы добавить еще одну систему сборки/проектную модель, нам надо закончить с важными проблемами по CMake, иначе эти проблемы просто «переползут» в общий интерфейс, через который будет работать и CMake, и Makefiles. Именно это сейчас и пытаемся сделать. Потом начнем смотреть в сторону уже конкретно Makefiles.
Makefile — тут вообще своя история, мы ее пытались в посте отразить. Если кратко, чтобы добавить еще одну систему сборки/проектную модель, нам надо закончить с важными проблемами по CMake, иначе эти проблемы просто «переползут» в общий интерфейс, через который будет работать и CMake, и Makefiles. Именно это сейчас и пытаемся сделать. Потом начнем смотреть в сторону уже конкретно Makefiles.
Возможно, вы удивитесь, я когда столкнулся с проблемой того, что CLion работает очень медленно на больших файлах, пошел искать другую IDE для C/C++ и остановился на… NetBeans! Она каким-то образом умудряется вполне сносно работать при любом размере файла, что было очень важно для того проекта, над которым я работал. Также NetBeans не прибивает проект гвоздями к cmake, что тоже в моем случае был плюс.
Что Вы подразумеваете под быстро работать? Изначальный парсинг проекта? Думаю да, NetBeans может делать его быстрее. Ему и не надо столько информации о проекте, сколько собирает CLion. Тайпинг? За последнее время в CLion решили много проблем на эту тему, стоит попробовать последние билды и зарепортить нам проблемы, если они все еще есть.
Нет, скорость индексации лично меня не волновала — проект был небольшой, но состоял из пары файлов, один из них был 5000 строк. Скорость ввода текста была неудовлетворительной — большую часть времени IDE вводила текст где-нибудь через секунду после нажатия. «Живой рефакторинг» тоже работал супер-медленно, когда я хотел переименовать макрос, который встречается 100 раз в одном файле — я ждал около минуты, пока IDE «отпустит». Я пробовал версии 1.0 и 1.1beta, на обоих версиях Java (1.6 и 1.8), разницы не заметил. Это было месяца 3-4 назад, возможно что-то и изменилось с тех пор, конечно. Я думаю, с CLion проблема в том, что иде пытается «честно» работать с макросами и дефайнами, и на больших файлах это приводит к очень медленной работе. Не уверен, что при выбранном подходе вообще вам удастся получить хорошую производительность, к сожалению.
В целом можно попробовать а) увеличить память, ну или хотя бы для начала включить индикатор памяти в настройках и проверить, сколько ее используется б) снять логи и CPU snapshot с меделенным тайпингом (инструкцию можно найти здесь) и засабмитить нам в саппорт. Тормозящий тайпинг — это проблема, с который мы активно боремся. Сейчас вроде таких явных «историй» не особо знаем, так что если вдруг попробуете опять и встретите, присылайте данные — будем разбираться.
Попробовал EAP, определенно выглядит получше, чем раньше, спасибо! Впрочем, переименование константы, которая встречается в файле много раз, всё ещё заставляет IDE задуматься очень конкретно.
А можете закинуть лог + snapshot в трекер? Вдруг мы там что-то интересное найдем)
По моему скромному мнению, в Linux CLion лучшая IDE, (именно IDE), но для быстрой работы — конечно очень нужен SSD.
Правда CMake и правда странная вещь, сколько он нервов попортил, что кажется быстрее и проще было написать разные Makefiles под разные ОСи и забыть про них, чем решать проблемы почему cmake не видит директорий или не линкует библиотеки (в Windows, в Linux таких проблем почти нет), но это уже не проблема CLion.
Правда CMake и правда странная вещь, сколько он нервов попортил, что кажется быстрее и проще было написать разные Makefiles под разные ОСи и забыть про них, чем решать проблемы почему cmake не видит директорий или не линкует библиотеки (в Windows, в Linux таких проблем почти нет), но это уже не проблема CLion.
Надеюсь как с IDEA будет и коммюнити и интерпрайз версии. Так же даешь поддержку F# и долой vb.net!
Я, например, вообще надеялся, что уж если Jetbrains сделают .NET IDE, то наконец-то будут нормальные рефакторинги для F#, а тут «no plans for F# right now»
Есть старый проект FSharper. Активность в нём показывает, как сильно миру нужна поддержка F#.
активность в нём показывает всего лишь, как сильно jetbrains нужна поддержка F#. а вот насколько она нужна миру показывает VisualFSharpPowerTools
Sign up to leave a comment.
Кроссплатформенный IDE для .NET/C# от JetBrains