Обычно нет. Такое обычно только на перешитых в ST-LINK v2-1. И вообще, конечно, если кто-то увидит это комментарий — не мучайтесь вы с этим ST-LINK, перешивайтесь вот прямо сразу в J-LINK. Настолько, блин, проще. Дрова под любой системой — просто работают, GDB Server — тоже просто работает, не косячит, USART для отладки не нужен, потому что RTT. До кучи еще и пачка утилит полезных, которые тоже — внезапно, просто работают. Я уже не говорю о скорости заливки прошивки — то, что st-link лил секунд 30, j-link вливает тупо за пару-тройку секунд.
О, тогда я знаю, в чем ваша боль. Значит по шагам:
1. Если у вас DFU определяется через DFuse utility, значит у вас стоит STMовский драйвер, который не будет работать с dfu-util. И наоборот — если вы поставите драйвер, который будет работать с dfu-util, у вас DFuse не будет видеть устройства. В обоих случаях девайс будет в Device Manager на Windows.
2. Если надо использовать DFuse, то без шансов — dfu-util при этом работать не будет.
3. Если надо использовать dfu-util, то надо удалить и устройство, и его драйвер из Device Manager, а потом сделать так, как говорят вот тут, то есть накатить драйвер через Zadig. После этого dfu-util начнет видеть устройство и работать, проверено.
Нет, потому что у нас разные идеологии кэширования. Мы кэшируем при открытии проекта и инкрементально добиваем кэш во время изменений кода. Это занимает больше времени на старте, но избавляет от отвалившейся подсветки и действий project-wide потом. Xcode индексирует при открытии проекта, а потом добивает кэш во время сборки. Кэш у него проще, времени при открытии требует меньше, но регулярно отваливается при редактировании кода, потому что инкрементальная достройка кэшей в ряде случаев = досборка проекта, что тяжелее.
А это IDEA-185409 и такое надо делать для всех IDE в платформе (первоначальный запрос — OC-3203, но на деле это не только для нас). Тут правда сразу же встает проблема с пределом роста иерархии настроек подсветки — у нас их сильно больше.
Например, можно добавить этот уровень, к нему можно добавить разбиение каждого из кодовых символов на декларацию/использование (сейчас так сделано для для функций и методов), и каждый из этих уровней потребует приличного оверхеда на реализацию для каждой из IDE. Баланс не очень понятен, хотя и то, и другое полезно — переусложнять тоже не хочется.
Последний комментарий там год назад. Появился он до того, как мы реализовали одно исправление, которое полностью убрало необходимость сборки под девайс. Что характерно, уже год там новых комментариев не появляется.
Далее, я вот прямо сейчас взял несколько немаленьких проектов, в произвольном месте написал о несуществующем и через некоторое время подчеркивание появилось. Если я возьму минимальный проект, будет то же самое. Немедленно эти ошибки появиться не смогут — они появляются с той скоростью, с которой их показывает SourceKit.
У вас правый верхний угол (индикатор анализа кода) что отображает на момент «нет посветки»? Если серый «глаз» — значит, аннотатор все еще отрабатывает. Если что-либо другое и при этом ошибки не отобразались — надо конкретно смотреть в саппорте.
Я надеялся что проблема будет решена в стабильной версии, но сильно лучше не стало.
И кстати да, я просто отмечу этот тезис. С ним сталкиваешься часто.
Протестировать все нельзя. Заметить все нельзя. Проекты разные. Зависимости разные. Все разное.
В общем, не надо ждать — даже неформализованную проблему лучше репортить сразу. Лучше мы потратим время, чтобы понять, что все в порядке или скажем, что мы это исправим, чем что-либо не заметим.
Жаль что я не могу помочь больше. Я все логи и что еще запрашивали прикреплял.
За это спасибо, вижу по тикетам еще за версию 2017.2. То замедление мы все-таки тестировали и вроде бы как раз в 2019.2 поправили. А вот по этому тикету помочь как раз можете — пара снэпшотов (один на 2019.2, другой на 2019.1.2) при открытии одного и того же файла сильно помогли бы.
Я бы сказал что вас срочно надо заниматься обтимизацией, не дожидаясь последнего релиза в году.
Здесь вы меня неверно поняли. «Целиком» посвятить — это значит, что работы не будет идти даже над какими-то совсем двухчасовыми мелочами. Это значит совсем целиком. В остальное время работа по оптимизации идет непрерывно. Третий релиз лучше подходит для того, чтобы работать над этим еще больше потому, что первый стабильно короткий, а второй стабильно появляется во время очередной беты Xcode, когда — как и всегда — приходится отрабатывать случившееся в ней.
Вот свеже открытый проект после индексации:
Вот тут бы не с Xcode сравнивать (это занятие несколько бесполезное, если мы урежем кэши до функционала Xcode, то взлетать они будут быстрее, чем в нем), а с AppCode предыдущей версии. Банально — снэпшот на 2019.1, снэпшот на 2019.2.
Или вот:
Дженерики. С дженериками все еще проблемы, правим по ходу, но тут либо дженерики, либо работа над быстродействием. Слишком много времени уйдет, хочется сначала ускорить все.
Сразу — имеется в виду до конца индексации. Действия типа Run All Tests in Project у нас нет. Но сейчас по крайней мере можно выбрать тестовую конфигурацию запуска и нажать Run — и он сработает.
Улучшения будут. Следующий релиз 2019.3 будет целиком посвещен работе над быстродействием. Это уже становится хорошей традицией — поступать так с последним релизом в году, но в этот раз работать будем еще более плотно. Скорее всего, с одной стороны, эта работа растянется на пару релизов, с другой стороны к сходимости придет ряд задач, над которыми мы уже около года работаем.
Что нужно от каждого, кто видит этот комментарий:
Нам можно и нужно писать в трекер, даже если не вполне понятно, в чем проблема. Мы поможем разобраться. Лучше конечно, при любой проблеме с быстродействием / фризах, сразу же прикладывать целиком папку с логами (Help | Show Log in Finder) и снимать CPU снэпшоты
Если удобнее через support — надо писать в support
Если удобнее писать в Slack — есть открытые каналы AppCode в Slack CocoaHeads (#jetbrains) и RxSwift (#appcode-users)
Если есть команда, у которой есть трудности по адаптации AppCode — надо писать мне на stanislav.dombrovsky at jetbrains.com и просить сделать демку / вместе посмотреть проблемы. Это нормальная и обычная практика для нас.
Если есть возможность и желание дать доступ к своему громадному проекту, чтобы мы могли на нем поотлаживаться — необходимо писать на эту же почту. Да, я в курсе про NDA, но для начала неплохо бы запустить процесс и вместе посмотреть — что мы можем там сделать. Польза будем всем — мы сможем продиагностировать проблемы, которые есть у других с большой вероятностью, компания в итоге получит ускорение работы.
Речь о нашем собственном парсере и resolve engine, который является расширением модели IntelliJ. Они у нас свои, потому что SourceKit нужных нам возможностей не дает. Я вот тут достаточно подробно рассказывал, почему. Основное там — нет нормальных кэшей. Без кэшей ни одно сложное преобразование, работающее в контексте проекта или workspace невозможно. Ни одно из сторонних решений эту задачу пока не решило.
SourceKit мы используем для показа ошибок/предупреждений и чтобы получить часть преобразований кода, которые он дает (fix-it), то есть по сути как линтер.
В будущем, посмотрим, к чему приведет движение CLion к clang и возможно, переиспользуем тот же подход для части задач.
Это касается как разницы между кол-вом в Swift относительно Objective-C так в целом между AppCode и ReSharper например.
Ну, если коротко, то рук не хватает и мы постоянно ищем разработчиков. К слову, их количество неуклонно растет.
Если более подробно, то нельзя сравнивать Swift и какой-либо другой язык. Для начала, не существует просто Swift. Есть связка Swift + Objective-C/C++, mixed code. Либо это библиотеки, либо еще крайне многое. В итоге мы тут решаем задачу, которую ни один другой продукт JetBrains не решает — делаем кроссязыковое взаимодействие не в виде приятного бонуса, а как часть функциональности, без которой IDE просто бесполезна. Любой C-подобный язык сразу же вызывает рост сложности реализации любой фичи, потому что нельзя так просто взять и распарсить код с текстовыми подстановками в виде #define. То есть на самом деле — это крайне непростая задача, и делать ее крайне долго, когда речь идет о рефакторингах, работающих в контексте всего проекта. С локальными проще, и их мы понемногу реализуем.
Идем дальше. Раз в год выходит Xcode. Выход Xcode — это сразу же поддержка изменений в нем, о которых не знает никто. Поэтому часть времени всегда уходит на это. Допустим, с Xcode 8 пару раз сменился формат, в котором хранится документация кода. Один раз полностью изменился, большой кусок пришлось переписывать, а казалось бы, просто документацию отобразить. Тот же ReSharper работает с API плагинов, там ситуация, по-моему более предсказуема.
Смотрим дальше. Есть проблемы в поддержке языка, и в этом смысле мало кому нужны новые фичи, пока имеющееся работает хорошо не всегда. Кроме того, любой рефакторинг завязан на то, насколько корректно работает движок по анализу кода. Плохо работает движок — рефакторинг не гарантирует корректности, в итоге он никому не нужен. Поэтому у нас пока основной фокус на поддержку языка и так будет до тех пор, пока не добьем до состояния, когда действительно будет иметь смысл взяться за рефакторинги.
Еще — по сути весь предыдущий год мы сместили фокус с «примерно пополам исправления и фичи, но фич чуть больше» в сторону «максимум исправлений по самым больным вопросам, а фичи если останется время». Потому что быстродействие и корректность важнее. Почти каждое из реализованных крупных исправлений заметно не сразу, но решает проблемы «по площадям», и среднее время реализации — где-то от полугода. Плюс изменения настолько масштабные, что война с регрессиями тоже отнимает приличное время.
Ну и с фичами если смотреть, тут всегда приходится выбирать. Вот есть Code Coverage, который мы точно можем сделать хорошо. Его используют вообще все. Важнее ли он, допустим, Inline-рефакторинга? С точки зрения пользователей — важнее, это четко видно по трекеру.
Понимаю, что теоретически можно это самому написать, поэтому был бы рад ссылочкам с чего начать)
Я бы рекомендовал попробовать для начала запустить вот этот плагин, а потом творчески переосмыслить это руководство. Плагин хорош, чтобы освоиться с простейшими принципами написания плагинов, руководство хорошо, чтобы копать глубже. К слову, там все не так сложно, как кажется.
1. Если у вас DFU определяется через DFuse utility, значит у вас стоит STMовский драйвер, который не будет работать с dfu-util. И наоборот — если вы поставите драйвер, который будет работать с dfu-util, у вас DFuse не будет видеть устройства. В обоих случаях девайс будет в Device Manager на Windows.
2. Если надо использовать DFuse, то без шансов — dfu-util при этом работать не будет.
3. Если надо использовать dfu-util, то надо удалить и устройство, и его драйвер из Device Manager, а потом сделать так, как говорят вот тут, то есть накатить драйвер через Zadig. После этого dfu-util начнет видеть устройство и работать, проверено.
По логике быть не должно, разве что код-анализу надо пройти для этого. Конкретный пример бы.
Тут пока не можем воспроизвести. Не повторяется так, как описывает отрепортивший.
Например, можно добавить этот уровень, к нему можно добавить разбиение каждого из кодовых символов на декларацию/использование (сейчас так сделано для для функций и методов), и каждый из этих уровней потребует приличного оверхеда на реализацию для каждой из IDE. Баланс не очень понятен, хотя и то, и другое полезно — переусложнять тоже не хочется.
Всем, у кого та же проблема — начиная с 2019.2 имеет смысл делать тикет, прикладывая результат запуска Find Action | Run Swift IDE Report.
Далее, я вот прямо сейчас взял несколько немаленьких проектов, в произвольном месте написал о несуществующем и через некоторое время подчеркивание появилось. Если я возьму минимальный проект, будет то же самое. Немедленно эти ошибки появиться не смогут — они появляются с той скоростью, с которой их показывает SourceKit.
У вас правый верхний угол (индикатор анализа кода) что отображает на момент «нет посветки»? Если серый «глаз» — значит, аннотатор все еще отрабатывает. Если что-либо другое и при этом ошибки не отобразались — надо конкретно смотреть в саппорте.
Это OC-16720, которую мы никак не можем отловить. Понять бы все-таки шаги, по которым у вас воспроизводится…
И кстати да, я просто отмечу этот тезис. С ним сталкиваешься часто.
Протестировать все нельзя. Заметить все нельзя. Проекты разные. Зависимости разные. Все разное.
В общем, не надо ждать — даже неформализованную проблему лучше репортить сразу. Лучше мы потратим время, чтобы понять, что все в порядке или скажем, что мы это исправим, чем что-либо не заметим.
За это спасибо, вижу по тикетам еще за версию 2017.2. То замедление мы все-таки тестировали и вроде бы как раз в 2019.2 поправили. А вот по этому тикету помочь как раз можете — пара снэпшотов (один на 2019.2, другой на 2019.1.2) при открытии одного и того же файла сильно помогли бы.
Здесь вы меня неверно поняли. «Целиком» посвятить — это значит, что работы не будет идти даже над какими-то совсем двухчасовыми мелочами. Это значит совсем целиком. В остальное время работа по оптимизации идет непрерывно. Третий релиз лучше подходит для того, чтобы работать над этим еще больше потому, что первый стабильно короткий, а второй стабильно появляется во время очередной беты Xcode, когда — как и всегда — приходится отрабатывать случившееся в ней.
Вот тут бы не с Xcode сравнивать (это занятие несколько бесполезное, если мы урежем кэши до функционала Xcode, то взлетать они будут быстрее, чем в нем), а с AppCode предыдущей версии. Банально — снэпшот на 2019.1, снэпшот на 2019.2.
Дженерики. С дженериками все еще проблемы, правим по ходу, но тут либо дженерики, либо работа над быстродействием. Слишком много времени уйдет, хочется сначала ускорить все.
Что нужно от каждого, кто видит этот комментарий:
#jetbrains) и RxSwift (#appcode-users)SourceKit мы используем для показа ошибок/предупреждений и чтобы получить часть преобразований кода, которые он дает (fix-it), то есть по сути как линтер.
В будущем, посмотрим, к чему приведет движение CLion к clang и возможно, переиспользуем тот же подход для части задач.
Ну, если коротко, то рук не хватает и мы постоянно ищем разработчиков. К слову, их количество неуклонно растет.
Если более подробно, то нельзя сравнивать Swift и какой-либо другой язык. Для начала, не существует просто Swift. Есть связка Swift + Objective-C/C++, mixed code. Либо это библиотеки, либо еще крайне многое. В итоге мы тут решаем задачу, которую ни один другой продукт JetBrains не решает — делаем кроссязыковое взаимодействие не в виде приятного бонуса, а как часть функциональности, без которой IDE просто бесполезна. Любой C-подобный язык сразу же вызывает рост сложности реализации любой фичи, потому что нельзя так просто взять и распарсить код с текстовыми подстановками в виде #define. То есть на самом деле — это крайне непростая задача, и делать ее крайне долго, когда речь идет о рефакторингах, работающих в контексте всего проекта. С локальными проще, и их мы понемногу реализуем.
Идем дальше. Раз в год выходит Xcode. Выход Xcode — это сразу же поддержка изменений в нем, о которых не знает никто. Поэтому часть времени всегда уходит на это. Допустим, с Xcode 8 пару раз сменился формат, в котором хранится документация кода. Один раз полностью изменился, большой кусок пришлось переписывать, а казалось бы, просто документацию отобразить. Тот же ReSharper работает с API плагинов, там ситуация, по-моему более предсказуема.
Смотрим дальше. Есть проблемы в поддержке языка, и в этом смысле мало кому нужны новые фичи, пока имеющееся работает хорошо не всегда. Кроме того, любой рефакторинг завязан на то, насколько корректно работает движок по анализу кода. Плохо работает движок — рефакторинг не гарантирует корректности, в итоге он никому не нужен. Поэтому у нас пока основной фокус на поддержку языка и так будет до тех пор, пока не добьем до состояния, когда действительно будет иметь смысл взяться за рефакторинги.
Еще — по сути весь предыдущий год мы сместили фокус с «примерно пополам исправления и фичи, но фич чуть больше» в сторону «максимум исправлений по самым больным вопросам, а фичи если останется время». Потому что быстродействие и корректность важнее. Почти каждое из реализованных крупных исправлений заметно не сразу, но решает проблемы «по площадям», и среднее время реализации — где-то от полугода. Плюс изменения настолько масштабные, что война с регрессиями тоже отнимает приличное время.
Ну и с фичами если смотреть, тут всегда приходится выбирать. Вот есть Code Coverage, который мы точно можем сделать хорошо. Его используют вообще все. Важнее ли он, допустим, Inline-рефакторинга? С точки зрения пользователей — важнее, это четко видно по трекеру.
Я бы рекомендовал попробовать для начала запустить вот этот плагин, а потом творчески переосмыслить это руководство. Плагин хорош, чтобы освоиться с простейшими принципами написания плагинов, руководство хорошо, чтобы копать глубже. К слову, там все не так сложно, как кажется.