Инструмент-то есть, просто всегда хочется попробовать более простой вариант перед сбором всех логов. В общем, нужно содержимое директории, открывающейся по Help | Show Log in Finder целиком — включая все поддиректории. Там должны быть дампы после фризов, попробуем разобраться. Лучше всего их — сразу в трекер.
Серьёзно… Просто попытался воспроизвести первую гифку — и аппкод зависает намертво.
Давайте понимать, почему так случилось. Виснет — значит «фриз» или прогресс какой-нибудь крутится долго? Подсветка файла прошла? Сколько памяти у IDE, не забита ли (Preferences | Appearance & Behavior | Appearance | внизу в Window Options — Show Memory Indicator → OK)? Если там все 2GB забиты, надо дать больше через правку Xmx в Help | Edit Custom VM Options.
Про associatedType еще раз проверил в чистом проекте и поведение отличное от Xcode.
За пример спасибо, завели OC-18148. Что-то не доделали в резолве, поэтому так.
— Про Xmx проверил показывает 1700 из 4000 (выставлено у меня в 4096).
— По rx будут примеры, сейчас с ходу не могу найти.
Давайте вот как. Надо снять CPU snapshot и в процессе его снятия повторить раз 5-6 медленное автодополнение. Это даст понять, где просадка. Ссылку на CPU snapshot надо отправить в наш саппорт (через Submit Request) вместе с ссылкой на переписку здесь. Уже там лучше обсудить проблемы по Rx — так сможем решить скорее.
пишешь let a: Str и ждешь секунд 5 чтобы он дополнил String
Есть такое чувство, что у вас стоит дефолтные 2000Mb в Xmx и их не сильно хватает на ваш проект. Пробовали смотреть, сколько памяти съедено через Preferences | Appearance & Behavior | Appearance | Windows Options | Show Memory Indicator? Если мало, надо бы увеличить Xmx через Help | Edit Custom VM Options и рестартовать IDE.
Про Rx я вообще молчу, дальше одной .map он сам вывести тип не может (да и с коллекциями также часто бывает)
Так быть не должно. По логике — где-то должна быть проблема с дженериками и надо бы пример.
Еще неверно переходит на тип associatedType у протоколов если тип в иплементаторе совпадает с именем associatedType
Либо я неправильно вас понял, либо поведение в Xcode такое же. Надо минимальный foobarbaz-пример.
И все-таки нужно чуть побольше информации. Вот мы отсмотрели их тестовый проект, на первый взгляд криминала нет (AppCode 2018.2). Можете форкнуть проект и просто там, где есть проблемы, поставить короткий комментарий? Или хотя бы участок кода нужен, пока непонятно, куда копать.
Спасибо! Про ваш комментарий — есть вот такая проблема, мы ее очень долго нормально не можем воспроизвести. Переиндексация должна происходить, но не происходит. Что бы помогло нам:
Help → Show Log in Finder → отправить всю папку на stanislav.dombrovsky@jetbrains.com (мне). Либо приттачить в тикет выше с видимостью на appcode-developers
Описать (либо по email, либо в тикете), как в точности действия происходят до возникновения красного кода (только ли это переключений бранчей или, допустим, установка pods, удаление pods, что-либо еще). Кажется, мы не реагируем на какое-то действие, на которое должны.
Если сможем воспроизвести — это очень сильно поможет, давно хотим решить.
1. Скоро Go to Class/Symbol/File/Search Everywhere/Find action будут объединены в одно окно.
2. Шорткаты надо учить, как правило они довольно логично выстроены группами. В этом смысле для начала стоит освоить основные группы по генерации / рефакторингам / возможностями редактора. Да, придется потратить время. Но грубо говоря, это X, который потом сэкономит 10X. Допустим, даже элементарное выделение через Expand/Shrink Selection существенно упрощает жизнь. В целом, это верно для любого инструмента разработки.
3. Активное использование Find Action сильно упрощает их изучение. Можно еще поставить что-нибудь вроде Key Promoter X.
Поподробнее бы понять, с проектом, где и что отвалилось. У меня на тестовых проектах комплит работал нормально. Опять же, встает вопрос — какая версия Xcode / AppCode.
Вы может быт не поверите, но был кейс где хкод делал ренейм, а аппкод ни в какую не соглашаться даже показать пункт меню в той же ситуации где нужен был ренейм. Сейчас я конечно же вспомню что и как это было, но задача не была решена в вашем платном продукте.
Охотно верю. Только частности не меняют общего, ничего не доказывают и не опровергают.
Видимо когда соберете 20 лайков в трекере за баг о том что все плохо.
Нет, не так. Проблем много, а ресуры ограничены, приоритетизация должна быть. Все исправить нельзя — правим наиболее критичное, и не столько по vote, сколько по еще куче источников.
Смотрите, вам кажется что пользователь должен вам доказывать и показывать чуть ли не по шагам что и как у него не работает? вам повезло что большая часть вашей аудитории в состоянии это сделать и дальше больше, но чет не кажется вам немного наглым продавать продукт и не решать проблемы?
Так не нужно доказывать. В то, что есть проблема, мы верим сразу. Вопрос в том, что без снэпшотов и логов ее решить нельзя. И так в любом продукте, это обычная ситуация.
давай просто проект на гитхаб и будем там всем миром пытаться его чинить) чего уж там.
Доступ к проектам — это отдельная история. В ряде случаев такой доступ помогает решить проблемы, над которыми команда работает месяцами и которые невозможно отследить даже по билдам с полной трассировкой. В целом, это идеальный вариант, на который, к сожалению, ряд компаний не соглашается.
вы можете хоть каждый день писать по новому парсеру/лексеру для языка, но толку от этого нет, если наиболее востребованные функции страдают. Ну и нет какой-то инфы — мол мы чиним вот это или мы забили болт на починку потому что у нас нет такой проблемы.
Важно понимать, что без нашего парсера и лексера этих наиболее востребованных функций (и всех других) не было бы в принципе. Как минимум потому, что до момента выкладки Swift в открытый доступ его необходимо было поддерживать. А как максимум потому, что без него реализация ряда функций в принципе невозможна.
Про то, где не ответили — давайте уже по email, поднимем тикеты и переитерируем. Если не ответили — заранее приношу извинения, изредка такое случается, будем оперативнее.
В последнем билде нет исправлений ни для одной проблемы со скоростью автодополнения. Ваш случай — как и я говорил выше — подлежит анализу в трекере. И повторюсь — без CPU snapshot на вашем проекте его невозможно корректно проанализировать.
курсоры и темы это все нужно вам для красивых скриншотов и статей на хабре
Мы не используем Xcode 10 для скриншотов в наших статьях :)
вот то чего не видно, но постоянно используется это скорость работы, поддержка свифта, рефакторинги (даже тут хкод догнал), автокомплит. все вот эти вот вещи работают криво и/или медленно
По скорости. Проблемы есть и периодически будут, как и в любом продукте. Как и в Xcode, который некоторые проекты, которые мы медленно, но можем открыть, просто не открывает и падает. Мы уже больше года работаем над некоторыми фундаментальными вещами, нужными для решения довольно масштабных проблем в resolve. И часть серьезных и крупных проблем, которые были, этими преобразованиями уже закрыты. Периодически возникают регрессии — да, но невозможно их избежать при настолько масштабных вещах.
По рефакторингам. Я обычно не сравниваю, но тут сравню — нет, не догнал. И не может догнать по корректности по той простой причине, что дерево символов в нем до сих пор отламывается при ошибках сборки. Это то, что заметно на мало-мальски крупных проектах. Далее, не догнал даже по набору фич для Objective-C/C++. Ну и по Swift — как-то тоже, я не вижу ничего похожего на тот же Extract Closure или хотя бы возможность поменять параметры местами в Extract Method. А мелочевка в виде fix-it — так она и у нас доступна.
Далее, в целом пока все эти гонки по набору фич — не приоритет. Приоритет — это корректность работы с языком и быстродействие. Чем мы постоянно и занимаемся. И это видно по каждому roadmap для каждого из релизов, которые выкладываются публично — фич в них минимум.
Репорты в твиттере оставлял, скидывал видео и прочее.
Оставляли. А я вам несколько раз отвечал по простым проблемам прямо в твиттере, а при более сложных несколько раз запрашивал CPU snapshot. Но вот тикетов, созданных вами с ними — я в трекере не вижу.
Смотрите — вам кажется, что информации, которую вы дали достаточно. Но мы не можем методом пристального взгляда на скриншот / видео решить сложную проблему. Для ее решения нужна информация — логи, дампы, снэпшоты. CPU snapshot достаточно точно дает понять, какой кусок кода вызывает просадку быстродействия, хотя и его в ряде случаев недостаточно. Но без него ни определить потенциальную причину проблему, ни тем более решить проблему — невозможно. Не факт, что она воспроизведется у нас. Скорее всего, если мы его запросили — она уже не воспроизвелась. Не факт, что у нас воспроизведется та же самая проблема, что у вас. Мы ее решим, а у вас лучше не станет.
Поэтому — как я уже и говорил не раз — если нужно решение проблемы, лучше сразу делать тикет и прикладывать к нему максимум информации. Если непонятно, какую — наши тестировщики и разработчики помогут. В трекере проще понять, что происходит, потому что там над тикетами работают владельцы конкретной предметной области и им проще и решить проблему, и определить ее причину.
Если всего этого не сделать, то будет примерно вот так:
Регулярно запускаю еап на рабочем проекте, смотрю как все медленно ворочается, выхожу(
Магии у нас нет, экстрасенсорными способностями мы к сожалению не обладаем. Если нужно решение проблемы — то давайте решать их в трекере.
Но опять таки- это хкод9 и свифт 4.1. Через пару месяцев все те же самые проблемы начнутся с хкодом 10 и свифтом 4.2.
Сначала про Xcode. Команда Xcode и Apple не уведомляет никого (и нас в том числе) об изменениях в любом билде Xcode. Эти изменения даже в LLDB нельзя отследить, потому что LLDB внутри Xcode — это немного другой LLDB. Поэтому каждый билд — это черный ящик, в котором могут возникнуть проблемы. И неважно, бета это, RC или релиз — всегда могут возникнуть проблемы, на решение которых требуется время.
Моментально мы их решить не можем. Но при этом каждый билд — каждый билд Xcode — анализируется и тестируется начиная с того дня, в который он появился. И в итоге к моменту выпуска очередной версии Xcode максимум проблем решен. Бывают проблемы вроде полностью измененного движка документации, как было в Xcode 8. Их быстро не решить — потому что объем изменений огромен, а ресурсы конечны.
Далее, про Swift 4.2. Уже несколько релизов все изменения в языке выкатываются максимально быстро — потому что делаются они заранее и каждый из новых proposals анализируется в момент появления. И говоря конкретно про Swift 4.2 — его поддержка, насколько я помню, по максимуму уже реализована, но выпущена будет тогда и только тогда, когда будет официально выпущен сам Swift 4.2. Не все, чего не видно — не существует.
Это не говоря о том, что абсолютное большинство команд никогда не переходит на новую версию Xcode немедленно. И никогда не переходило, есть определенный период на проверку и миграцию — и это я знаю по опыту.
Еще быстрее выкатывать поддержку — нет, нельзя. Но мы все равно стараемся.
А уж хваленый переход на подписку, под которым вы рассказали что уж теперь то сможете закрывать кучу багов, вместо того чтобы гнаться за фичами ради привлечения продаж
Повторюсь — если смотреть на то, что мы делаем, по-моему очевидно, что фич — минимум, и достаточно много их приходит вообще без затрат нашего времени, из платформы. Если они не делаются быстро — это значит, что их невозможно сделать быстрее. Подписка тут ни при чем.
Впрочем, если вдруг кто-то обладает тайным знанием моментального решения сложных проблем, мы его ждем в команде AppCode и с удовольствием научимся работать лучше и быстрее, люди нам всегда нужны :)
Здесь было бы бесчеловечно не пошутить о темной теме и multiple cursors в Xcode 10, но я не буду. Давайте поймем — что вы конкретно имеете в виду под "позади".
А постоянные тормоза и пролаги сделали его почти непригодным для работы на средними по размеру проектами на свифте.
Значит, что-то мы упускаем — но тут опять надо бы понять, что подразумеваем под "тормозами". На открытии проекта в 2018.2 нашли пару регрессий, в RC2 должны быть поправлены — пробовали? Если что-то другое — давайте проитерируем в слэке Рамблера по снэпшотам / проектам, чтобы мы на своей стороне смогли воспроизвести. Или просто пишите на stanislav.dombrovsky@jetbrains.com — попробуем понять, что не так.
Есть ли в планах вынести проверки IDE в инспектор?
Например поддержка атрибутов, или же просто их эволюцию с «availability» -> «available», или же "_versioned" -> «usableFromInline» и "_inlineable" -> «inlinable»
Это парсерная ошибка, планов выносить парсерные ошибки в настройки с возможностью их отключения нет. Слишком сложно, слишком много времени, в целом — порочная практика, потому что проблемы начнут замалчиваться, а не решаться в итоге. Плюс частые изменения версии Swift.
Сейчас подобные изменений аттрибутов мы поддерживаем в зависимости от версии. Как только реализуем в очередном апдейте — начнут корректно обрабатываться как старые, так и новые в зависимости от версии Swift. Конкретно по этим — уже сделано, но пока еще не появилось в обновлениях.
И второй вопрос — будут ли расширяться возможности Code Style
В следующей версии скорее всего нет, но это не значит, что если задача окажется простой и на нее не появится времени, она не будет сделана по ходу. Заводите тикет, пусть ребята посмотрят, если окажется просто — сделают.
Но вот что в одном из будущих релизов мы к форматированию обязательно вернемся, в очередной раз серьезно его доработав — это точно, там еще много хорошего можно сделать.
Давайте понимать, почему так случилось. Виснет — значит «фриз» или прогресс какой-нибудь крутится долго? Подсветка файла прошла? Сколько памяти у IDE, не забита ли (Preferences | Appearance & Behavior | Appearance | внизу в Window Options — Show Memory Indicator → OK)? Если там все 2GB забиты, надо дать больше через правку Xmx в Help | Edit Custom VM Options.
За пример спасибо, завели OC-18148. Что-то не доделали в резолве, поэтому так.
Давайте вот как. Надо снять CPU snapshot и в процессе его снятия повторить раз 5-6 медленное автодополнение. Это даст понять, где просадка. Ссылку на CPU snapshot надо отправить в наш саппорт (через Submit Request) вместе с ссылкой на переписку здесь. Уже там лучше обсудить проблемы по Rx — так сможем решить скорее.
Есть такое чувство, что у вас стоит дефолтные 2000Mb в Xmx и их не сильно хватает на ваш проект. Пробовали смотреть, сколько памяти съедено через Preferences | Appearance & Behavior | Appearance | Windows Options | Show Memory Indicator? Если мало, надо бы увеличить Xmx через Help | Edit Custom VM Options и рестартовать IDE.
Так быть не должно. По логике — где-то должна быть проблема с дженериками и надо бы пример.
Либо я неправильно вас понял, либо поведение в Xcode такое же. Надо минимальный foobarbaz-пример.
И все-таки нужно чуть побольше информации. Вот мы отсмотрели их тестовый проект, на первый взгляд криминала нет (AppCode 2018.2). Можете форкнуть проект и просто там, где есть проблемы, поставить короткий комментарий? Или хотя бы участок кода нужен, пока непонятно, куда копать.
Спасибо! Про ваш комментарий — есть вот такая проблема, мы ее очень долго нормально не можем воспроизвести. Переиндексация должна происходить, но не происходит. Что бы помогло нам:
Help → Show Log in Finder → отправить всю папку на stanislav.dombrovsky@jetbrains.com (мне). Либо приттачить в тикет выше с видимостью на
appcode-developersОписать (либо по email, либо в тикете), как в точности действия происходят до возникновения красного кода (только ли это переключений бранчей или, допустим, установка pods, удаление pods, что-либо еще). Кажется, мы не реагируем на какое-то действие, на которое должны.
Если сможем воспроизвести — это очень сильно поможет, давно хотим решить.
1. Скоро Go to Class/Symbol/File/Search Everywhere/Find action будут объединены в одно окно.
2. Шорткаты надо учить, как правило они довольно логично выстроены группами. В этом смысле для начала стоит освоить основные группы по генерации / рефакторингам / возможностями редактора. Да, придется потратить время. Но грубо говоря, это X, который потом сэкономит 10X. Допустим, даже элементарное выделение через Expand/Shrink Selection существенно упрощает жизнь. В целом, это верно для любого инструмента разработки.
3. Активное использование Find Action сильно упрощает их изучение. Можно еще поставить что-нибудь вроде Key Promoter X.
А что не получилось завести конкретно? По идее, Xcode-проект для Vapor мы нормально обрабатываем.
Охотно верю. Только частности не меняют общего, ничего не доказывают и не опровергают.
Нет, не так. Проблем много, а ресуры ограничены, приоритетизация должна быть. Все исправить нельзя — правим наиболее критичное, и не столько по vote, сколько по еще куче источников.
Так не нужно доказывать. В то, что есть проблема, мы верим сразу. Вопрос в том, что без снэпшотов и логов ее решить нельзя. И так в любом продукте, это обычная ситуация.
Доступ к проектам — это отдельная история. В ряде случаев такой доступ помогает решить проблемы, над которыми команда работает месяцами и которые невозможно отследить даже по билдам с полной трассировкой. В целом, это идеальный вариант, на который, к сожалению, ряд компаний не соглашается.
Важно понимать, что без нашего парсера и лексера этих наиболее востребованных функций (и всех других) не было бы в принципе. Как минимум потому, что до момента выкладки Swift в открытый доступ его необходимо было поддерживать. А как максимум потому, что без него реализация ряда функций в принципе невозможна.
Про то, где не ответили — давайте уже по email, поднимем тикеты и переитерируем. Если не ответили — заранее приношу извинения, изредка такое случается, будем оперативнее.
В последнем билде нет исправлений ни для одной проблемы со скоростью автодополнения. Ваш случай — как и я говорил выше — подлежит анализу в трекере. И повторюсь — без CPU snapshot на вашем проекте его невозможно корректно проанализировать.
Мы не используем Xcode 10 для скриншотов в наших статьях :)
По скорости. Проблемы есть и периодически будут, как и в любом продукте. Как и в Xcode, который некоторые проекты, которые мы медленно, но можем открыть, просто не открывает и падает. Мы уже больше года работаем над некоторыми фундаментальными вещами, нужными для решения довольно масштабных проблем в resolve. И часть серьезных и крупных проблем, которые были, этими преобразованиями уже закрыты. Периодически возникают регрессии — да, но невозможно их избежать при настолько масштабных вещах.
По рефакторингам. Я обычно не сравниваю, но тут сравню — нет, не догнал. И не может догнать по корректности по той простой причине, что дерево символов в нем до сих пор отламывается при ошибках сборки. Это то, что заметно на мало-мальски крупных проектах. Далее, не догнал даже по набору фич для Objective-C/C++. Ну и по Swift — как-то тоже, я не вижу ничего похожего на тот же Extract Closure или хотя бы возможность поменять параметры местами в Extract Method. А мелочевка в виде fix-it — так она и у нас доступна.
Далее, в целом пока все эти гонки по набору фич — не приоритет. Приоритет — это корректность работы с языком и быстродействие. Чем мы постоянно и занимаемся. И это видно по каждому roadmap для каждого из релизов, которые выкладываются публично — фич в них минимум.
Смотрите — вам кажется, что информации, которую вы дали достаточно. Но мы не можем методом пристального взгляда на скриншот / видео решить сложную проблему. Для ее решения нужна информация — логи, дампы, снэпшоты. CPU snapshot достаточно точно дает понять, какой кусок кода вызывает просадку быстродействия, хотя и его в ряде случаев недостаточно. Но без него ни определить потенциальную причину проблему, ни тем более решить проблему — невозможно. Не факт, что она воспроизведется у нас. Скорее всего, если мы его запросили — она уже не воспроизвелась. Не факт, что у нас воспроизведется та же самая проблема, что у вас. Мы ее решим, а у вас лучше не станет.
Поэтому — как я уже и говорил не раз — если нужно решение проблемы, лучше сразу делать тикет и прикладывать к нему максимум информации. Если непонятно, какую — наши тестировщики и разработчики помогут. В трекере проще понять, что происходит, потому что там над тикетами работают владельцы конкретной предметной области и им проще и решить проблему, и определить ее причину.
Если всего этого не сделать, то будет примерно вот так:
Магии у нас нет, экстрасенсорными способностями мы к сожалению не обладаем. Если нужно решение проблемы — то давайте решать их в трекере.
Сначала про Xcode. Команда Xcode и Apple не уведомляет никого (и нас в том числе) об изменениях в любом билде Xcode. Эти изменения даже в LLDB нельзя отследить, потому что LLDB внутри Xcode — это немного другой LLDB. Поэтому каждый билд — это черный ящик, в котором могут возникнуть проблемы. И неважно, бета это, RC или релиз — всегда могут возникнуть проблемы, на решение которых требуется время.
Моментально мы их решить не можем. Но при этом каждый билд — каждый билд Xcode — анализируется и тестируется начиная с того дня, в который он появился. И в итоге к моменту выпуска очередной версии Xcode максимум проблем решен. Бывают проблемы вроде полностью измененного движка документации, как было в Xcode 8. Их быстро не решить — потому что объем изменений огромен, а ресурсы конечны.
Далее, про Swift 4.2. Уже несколько релизов все изменения в языке выкатываются максимально быстро — потому что делаются они заранее и каждый из новых proposals анализируется в момент появления. И говоря конкретно про Swift 4.2 — его поддержка, насколько я помню, по максимуму уже реализована, но выпущена будет тогда и только тогда, когда будет официально выпущен сам Swift 4.2. Не все, чего не видно — не существует.
Это не говоря о том, что абсолютное большинство команд никогда не переходит на новую версию Xcode немедленно. И никогда не переходило, есть определенный период на проверку и миграцию — и это я знаю по опыту.
Еще быстрее выкатывать поддержку — нет, нельзя. Но мы все равно стараемся.
Повторюсь — если смотреть на то, что мы делаем, по-моему очевидно, что фич — минимум, и достаточно много их приходит вообще без затрат нашего времени, из платформы. Если они не делаются быстро — это значит, что их невозможно сделать быстрее. Подписка тут ни при чем.
Впрочем, если вдруг кто-то обладает тайным знанием моментального решения сложных проблем, мы его ждем в команде AppCode и с удовольствием научимся работать лучше и быстрее, люди нам всегда нужны :)
Здесь было бы бесчеловечно не пошутить о темной теме и multiple cursors в Xcode 10, но я не буду. Давайте поймем — что вы конкретно имеете в виду под "позади".
Значит, что-то мы упускаем — но тут опять надо бы понять, что подразумеваем под "тормозами". На открытии проекта в 2018.2 нашли пару регрессий, в RC2 должны быть поправлены — пробовали? Если что-то другое — давайте проитерируем в слэке Рамблера по снэпшотам / проектам, чтобы мы на своей стороне смогли воспроизвести. Или просто пишите на stanislav.dombrovsky@jetbrains.com — попробуем понять, что не так.
Это парсерная ошибка, планов выносить парсерные ошибки в настройки с возможностью их отключения нет. Слишком сложно, слишком много времени, в целом — порочная практика, потому что проблемы начнут замалчиваться, а не решаться в итоге. Плюс частые изменения версии Swift.
Сейчас подобные изменений аттрибутов мы поддерживаем в зависимости от версии. Как только реализуем в очередном апдейте — начнут корректно обрабатываться как старые, так и новые в зависимости от версии Swift. Конкретно по этим — уже сделано, но пока еще не появилось в обновлениях.
В следующей версии скорее всего нет, но это не значит, что если задача окажется простой и на нее не появится времени, она не будет сделана по ходу. Заводите тикет, пусть ребята посмотрят, если окажется просто — сделают.
Но вот что в одном из будущих релизов мы к форматированию обязательно вернемся, в очередной раз серьезно его доработав — это точно, там еще много хорошего можно сделать.
Скачайте File Watchers плагин, настройте там clang-format и будет он срабатывать на сохранение.