• AppCode 2020.1: улучшения быстродействия, автодополнение до конца индексации, генерация документации и многое другое
    0
    Скажите, для генерации комментариев есть какие-то ограничения? У меня часто не работает.

    По логике быть не должно, разве что код-анализу надо пройти для этого. Конкретный пример бы.

    баг youtrack.jetbrains.com/issue/OC-19718

    Тут пока не можем воспроизвести. Не повторяется так, как описывает отрепортивший.
  • AppCode 2020.1: улучшения быстродействия, автодополнение до конца индексации, генерация документации и многое другое
    +1
    Нет, потому что у нас разные идеологии кэширования. Мы кэшируем при открытии проекта и инкрементально добиваем кэш во время изменений кода. Это занимает больше времени на старте, но избавляет от отвалившейся подсветки и действий project-wide потом. Xcode индексирует при открытии проекта, а потом добивает кэш во время сборки. Кэш у него проще, времени при открытии требует меньше, но регулярно отваливается при редактировании кода, потому что инкрементальная достройка кэшей в ряде случаев = досборка проекта, что тяжелее.
  • AppCode 2019.3: работает быстрее, лучше понимает Swift, знает про Mac Catalyst, удобно отображает сообщения сборки
    0
    А это IDEA-185409 и такое надо делать для всех IDE в платформе (первоначальный запрос — OC-3203, но на деле это не только для нас). Тут правда сразу же встает проблема с пределом роста иерархии настроек подсветки — у нас их сильно больше.

    Например, можно добавить этот уровень, к нему можно добавить разбиение каждого из кодовых символов на декларацию/использование (сейчас так сделано для для функций и методов), и каждый из этих уровней потребует приличного оверхеда на реализацию для каждой из IDE. Баланс не очень понятен, хотя и то, и другое полезно — переусложнять тоже не хочется.
  • AppCode 2019.3: работает быстрее, лучше понимает Swift, знает про Mac Catalyst, удобно отображает сообщения сборки
    0
    Проблемы видим, важность понимаем — в 2020.1 будем анализировать, как правильно поддержать. Там немало, так что в самом 2020.1 не выдадим к сожалению.
  • AppCode 2019.2: Swift 5.1, анализ покрытия кода тестами, отображение дизассемблированного кода и другое
    0
    Обсудили — в итоге это OC-18996.

    Всем, у кого та же проблема — начиная с 2019.2 имеет смысл делать тикет, прикладывая результат запуска Find Action | Run Swift IDE Report.
  • AppCode 2019.2: Swift 5.1, анализ покрытия кода тестами, отображение дизассемблированного кода и другое
    0
    Последний комментарий там год назад. Появился он до того, как мы реализовали одно исправление, которое полностью убрало необходимость сборки под девайс. Что характерно, уже год там новых комментариев не появляется.

    Далее, я вот прямо сейчас взял несколько немаленьких проектов, в произвольном месте написал о несуществующем и через некоторое время подчеркивание появилось. Если я возьму минимальный проект, будет то же самое. Немедленно эти ошибки появиться не смогут — они появляются с той скоростью, с которой их показывает SourceKit.

    У вас правый верхний угол (индикатор анализа кода) что отображает на момент «нет посветки»? Если серый «глаз» — значит, аннотатор все еще отрабатывает. Если что-либо другое и при этом ошибки не отобразались — надо конкретно смотреть в саппорте.
  • AppCode 2019.2: Swift 5.1, анализ покрытия кода тестами, отображение дизассемблированного кода и другое
    0
    Сейчас такие символы должны подчеркиваться красным после того, как отработает SourceKit-аннотатор. У вас так не происходит?
  • AppCode 2019.2: Swift 5.1, анализ покрытия кода тестами, отображение дизассемблированного кода и другое
    0
    Вдруг откуда не возьмись:
    www.dropbox.com/s/o2ztuse7znrjkmc/Screenshot%202019-08-02%20at%2015.03.07.png?dl=0


    Это OC-16720, которую мы никак не можем отловить. Понять бы все-таки шаги, по которым у вас воспроизводится…
  • AppCode 2019.2: Swift 5.1, анализ покрытия кода тестами, отображение дизассемблированного кода и другое
    0
    Я надеялся что проблема будет решена в стабильной версии, но сильно лучше не стало.

    И кстати да, я просто отмечу этот тезис. С ним сталкиваешься часто.
    Протестировать все нельзя. Заметить все нельзя. Проекты разные. Зависимости разные. Все разное.

    В общем, не надо ждать — даже неформализованную проблему лучше репортить сразу. Лучше мы потратим время, чтобы понять, что все в порядке или скажем, что мы это исправим, чем что-либо не заметим.
  • AppCode 2019.2: Swift 5.1, анализ покрытия кода тестами, отображение дизассемблированного кода и другое
    0
    Жаль что я не могу помочь больше. Я все логи и что еще запрашивали прикреплял.

    За это спасибо, вижу по тикетам еще за версию 2017.2. То замедление мы все-таки тестировали и вроде бы как раз в 2019.2 поправили. А вот по этому тикету помочь как раз можете — пара снэпшотов (один на 2019.2, другой на 2019.1.2) при открытии одного и того же файла сильно помогли бы.

    Я бы сказал что вас срочно надо заниматься обтимизацией, не дожидаясь последнего релиза в году.

    Здесь вы меня неверно поняли. «Целиком» посвятить — это значит, что работы не будет идти даже над какими-то совсем двухчасовыми мелочами. Это значит совсем целиком. В остальное время работа по оптимизации идет непрерывно. Третий релиз лучше подходит для того, чтобы работать над этим еще больше потому, что первый стабильно короткий, а второй стабильно появляется во время очередной беты Xcode, когда — как и всегда — приходится отрабатывать случившееся в ней.

    Вот свеже открытый проект после индексации:

    Вот тут бы не с Xcode сравнивать (это занятие несколько бесполезное, если мы урежем кэши до функционала Xcode, то взлетать они будут быстрее, чем в нем), а с AppCode предыдущей версии. Банально — снэпшот на 2019.1, снэпшот на 2019.2.

    Или вот:

    Дженерики. С дженериками все еще проблемы, правим по ходу, но тут либо дженерики, либо работа над быстродействием. Слишком много времени уйдет, хочется сначала ускорить все.
  • AppCode 2019.2: Swift 5.1, анализ покрытия кода тестами, отображение дизассемблированного кода и другое
    0
    На самом деле сравнивали, причем постоянно. Репорты про замедление видим — почему, пока не ясно.
  • AppCode 2019.2: Swift 5.1, анализ покрытия кода тестами, отображение дизассемблированного кода и другое
    0
    Сразу — имеется в виду до конца индексации. Действия типа Run All Tests in Project у нас нет. Но сейчас по крайней мере можно выбрать тестовую конфигурацию запуска и нажать Run — и он сработает.
  • AppCode 2019.2: Swift 5.1, анализ покрытия кода тестами, отображение дизассемблированного кода и другое
    +2
    Улучшения будут. Следующий релиз 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, но для начала неплохо бы запустить процесс и вместе посмотреть — что мы можем там сделать. Польза будем всем — мы сможем продиагностировать проблемы, которые есть у других с большой вероятностью, компания в итоге получит ускорение работы.
  • AppCode 2019.1: Swift 5, улучшенная работа подсветки, навигации и автодополнения, перемещение выражений и многое другое
    +1
    Речь о нашем собственном парсере и resolve engine, который является расширением модели IntelliJ. Они у нас свои, потому что SourceKit нужных нам возможностей не дает. Я вот тут достаточно подробно рассказывал, почему. Основное там — нет нормальных кэшей. Без кэшей ни одно сложное преобразование, работающее в контексте проекта или workspace невозможно. Ни одно из сторонних решений эту задачу пока не решило.

    SourceKit мы используем для показа ошибок/предупреждений и чтобы получить часть преобразований кода, которые он дает (fix-it), то есть по сути как линтер.

    В будущем, посмотрим, к чему приведет движение CLion к clang и возможно, переиспользуем тот же подход для части задач.
  • AppCode 2019.1: Swift 5, улучшенная работа подсветки, навигации и автодополнения, перемещение выражений и многое другое
    0
    Промахнулся веткой, ответил ниже.
  • AppCode 2019.1: Swift 5, улучшенная работа подсветки, навигации и автодополнения, перемещение выражений и многое другое
    0
    Это касается как разницы между кол-вом в 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-рефакторинга? С точки зрения пользователей — важнее, это четко видно по трекеру.

    Понимаю, что теоретически можно это самому написать, поэтому был бы рад ссылочкам с чего начать)

    Я бы рекомендовал попробовать для начала запустить вот этот плагин, а потом творчески переосмыслить это руководство. Плагин хорош, чтобы освоиться с простейшими принципами написания плагинов, руководство хорошо, чтобы копать глубже. К слову, там все не так сложно, как кажется.
  • AppCode 2019.1: Swift 5, улучшенная работа подсветки, навигации и автодополнения, перемещение выражений и многое другое
    0
    в итоге убрал галочки на smart и base completion

    Галочки там стоят на «Automatically insert single suggestion», так что оно влиять на скорость никак не может. Даже если показалось, что что-то изменилось — это не так. По быстродействию автодополнения — проблема известная, будем отсматривать.
    Буквально на днях заметил странную штуку, сборка в AppCode намного дольше чем на Xcode.
    то есть полная сборка + запуск

    Так все таки только сборка, или сборка плюс запуск занимают больше времени? Это два разных процесса, причины замедления там тоже принципиально разные. Чтобы нормально понять — нужны измерения после ⌥F9 в AppCode (Build) и ⌘B в Xcode, с предварительно очищенной DerivedData.
    довольно часто после изменения кода (например изменить имя приватной функции, добавить дополнительный параметр в функцию) всё перестает работать секунд на 10-20

    У вас в этот момент код подсвечивается, в правом верхнем углу отображается серый «глаз»? Если код не подсветился и глаз отображается — значит, идет перепарсинг и перерезолв, пока не окрасится код — остальное тоже не отработает. Тут бы снэпшот надо.
    Еще замечаю (любая версия IDE), что бывают выражения, которые программа с другом вывозит.

    И тут тоже бы надо снэпшот.
    Тут всегда даже подсветка не работает, я уже не говорю, что не может вывести тип. Такое часто когда тип объекта object из другого модуля.

    А вот тут бы тестовый проект, потому что крайне трудно воспроизвести то, о чем вы говорите. Если брать минимальный пример типа:

    class MyObject {
        var innerObject: String?
    }
    
    class Test {
        var array: Array<MyObject>?
        func test() {
            var t = Test()
            guard let obj = t.array?.first?.innerObject?.count else {
               
            }
        }
    }
    


    то здесь все подсвечивается. Поэтому проблема не в chaining, как таковом, а, скорее всего, в сочетании generics в ваших объектах. Понять точно было бы полезно.
    Уже не помню, но вроде компишен дженериков тоже очень плохо работает

    По дженерикам, к сожалению, еще надо пройтись по площадям. Пока не прошлись.
  • AppCode 2019.1: Swift 5, улучшенная работа подсветки, навигации и автодополнения, перемещение выражений и многое другое
    0
    OC-18316 пока не исправили, но в 2019.2 будем работать над скоростью автодополнения целенаправленно. Про компиляцию бы подробнее посмотреть. У нас с Xcode разные DerivedData, если переключаетесь и билдите то там, то там, то вполне может быть.
  • AppCode 2019.1: Swift 5, улучшенная работа подсветки, навигации и автодополнения, перемещение выражений и многое другое
    0
    Лог сборки можете переслать в личку? В окне Messages слева есть кнопка «Show build log».
  • AppCode 2019.1: Swift 5, улучшенная работа подсветки, навигации и автодополнения, перемещение выражений и многое другое
    0
    Инструмент-то есть, просто всегда хочется попробовать более простой вариант перед сбором всех логов. В общем, нужно содержимое директории, открывающейся по Help | Show Log in Finder целиком — включая все поддиректории. Там должны быть дампы после фризов, попробуем разобраться. Лучше всего их — сразу в трекер.
  • AppCode 2019.1: Swift 5, улучшенная работа подсветки, навигации и автодополнения, перемещение выражений и многое другое
    0
    Серьёзно… Просто попытался воспроизвести первую гифку — и аппкод зависает намертво.

    Давайте понимать, почему так случилось. Виснет — значит «фриз» или прогресс какой-нибудь крутится долго? Подсветка файла прошла? Сколько памяти у IDE, не забита ли (Preferences | Appearance & Behavior | Appearance | внизу в Window Options — Show Memory Indicator → OK)? Если там все 2GB забиты, надо дать больше через правку Xmx в Help | Edit Custom VM Options.
  • AppCode 2019.1: Swift 5, улучшенная работа подсветки, навигации и автодополнения, перемещение выражений и многое другое
    0
    del
  • Что нового в AppCode 2018.3
    +1
    Про associatedType еще раз проверил в чистом проекте и поведение отличное от Xcode.

    За пример спасибо, завели OC-18148. Что-то не доделали в резолве, поэтому так.
    — Про Xmx проверил показывает 1700 из 4000 (выставлено у меня в 4096).
    — По rx будут примеры, сейчас с ходу не могу найти.

    Давайте вот как. Надо снять CPU snapshot и в процессе его снятия повторить раз 5-6 медленное автодополнение. Это даст понять, где просадка. Ссылку на CPU snapshot надо отправить в наш саппорт (через Submit Request) вместе с ссылкой на переписку здесь. Уже там лучше обсудить проблемы по Rx — так сможем решить скорее.
  • Что нового в AppCode 2018.3
    0
    пишешь 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
    0

    И все-таки нужно чуть побольше информации. Вот мы отсмотрели их тестовый проект, на первый взгляд криминала нет (AppCode 2018.2). Можете форкнуть проект и просто там, где есть проблемы, поставить короткий комментарий? Или хотя бы участок кода нужен, пока непонятно, куда копать.

  • Что нового в AppCode 2018.2
    0
    Логи лучше выслать сейчас — там с большой вероятностью осталось что-то полезное.
  • Что нового в AppCode 2018.2
    0

    Спасибо! Про ваш комментарий — есть вот такая проблема, мы ее очень долго нормально не можем воспроизвести. Переиндексация должна происходить, но не происходит. Что бы помогло нам:


    1. Help → Show Log in Finder → отправить всю папку на stanislav.dombrovsky@jetbrains.com (мне). Либо приттачить в тикет выше с видимостью на appcode-developers


    2. Описать (либо по email, либо в тикете), как в точности действия происходят до возникновения красного кода (только ли это переключений бранчей или, допустим, установка pods, удаление pods, что-либо еще). Кажется, мы не реагируем на какое-то действие, на которое должны.



    Если сможем воспроизвести — это очень сильно поможет, давно хотим решить.

  • Что нового в AppCode 2018.2
    0
    Тут как:

    1. Скоро Go to Class/Symbol/File/Search Everywhere/Find action будут объединены в одно окно.

    2. Шорткаты надо учить, как правило они довольно логично выстроены группами. В этом смысле для начала стоит освоить основные группы по генерации / рефакторингам / возможностями редактора. Да, придется потратить время. Но грубо говоря, это X, который потом сэкономит 10X. Допустим, даже элементарное выделение через Expand/Shrink Selection существенно упрощает жизнь. В целом, это верно для любого инструмента разработки.

    3. Активное использование Find Action сильно упрощает их изучение. Можно еще поставить что-нибудь вроде Key Promoter X.
  • Что нового в AppCode 2018.2
    0
    Поподробнее бы понять, с проектом, где и что отвалилось. У меня на тестовых проектах комплит работал нормально. Опять же, встает вопрос — какая версия Xcode / AppCode.
  • Что нового в AppCode 2018.2
    0
  • Что нового в AppCode 2018.2
    0
    Это есть в планах. Но так как за время с написания черновика произошли секретные улучшения, о которых говорить нельзя, требуется переработка :).

    А что не получилось завести конкретно? По идее, Xcode-проект для Vapor мы нормально обрабатываем.
  • В День дружбы — скидка 50% на все IDE JetBrains для наших друзей
    0
    Вы может быт не поверите, но был кейс где хкод делал ренейм, а аппкод ни в какую не соглашаться даже показать пункт меню в той же ситуации где нужен был ренейм. Сейчас я конечно же вспомню что и как это было, но задача не была решена в вашем платном продукте.

    Охотно верю. Только частности не меняют общего, ничего не доказывают и не опровергают.


    Видимо когда соберете 20 лайков в трекере за баг о том что все плохо.

    Нет, не так. Проблем много, а ресуры ограничены, приоритетизация должна быть. Все исправить нельзя — правим наиболее критичное, и не столько по vote, сколько по еще куче источников.


    Смотрите, вам кажется что пользователь должен вам доказывать и показывать чуть ли не по шагам что и как у него не работает? вам повезло что большая часть вашей аудитории в состоянии это сделать и дальше больше, но чет не кажется вам немного наглым продавать продукт и не решать проблемы?

    Так не нужно доказывать. В то, что есть проблема, мы верим сразу. Вопрос в том, что без снэпшотов и логов ее решить нельзя. И так в любом продукте, это обычная ситуация.


    давай просто проект на гитхаб и будем там всем миром пытаться его чинить) чего уж там.

    Доступ к проектам — это отдельная история. В ряде случаев такой доступ помогает решить проблемы, над которыми команда работает месяцами и которые невозможно отследить даже по билдам с полной трассировкой. В целом, это идеальный вариант, на который, к сожалению, ряд компаний не соглашается.


    вы можете хоть каждый день писать по новому парсеру/лексеру для языка, но толку от этого нет, если наиболее востребованные функции страдают. Ну и нет какой-то инфы — мол мы чиним вот это или мы забили болт на починку потому что у нас нет такой проблемы.

    Важно понимать, что без нашего парсера и лексера этих наиболее востребованных функций (и всех других) не было бы в принципе. Как минимум потому, что до момента выкладки Swift в открытый доступ его необходимо было поддерживать. А как максимум потому, что без него реализация ряда функций в принципе невозможна.


    Про то, где не ответили — давайте уже по email, поднимем тикеты и переитерируем. Если не ответили — заранее приношу извинения, изредка такое случается, будем оперативнее.

  • В День дружбы — скидка 50% на все IDE JetBrains для наших друзей
    –1
    Ответил на email, и кажется что проще продолжать там.
  • В День дружбы — скидка 50% на все IDE JetBrains для наших друзей
    0

    В последнем билде нет исправлений ни для одной проблемы со скоростью автодополнения. Ваш случай — как и я говорил выше — подлежит анализу в трекере. И повторюсь — без CPU snapshot на вашем проекте его невозможно корректно проанализировать.

  • В День дружбы — скидка 50% на все IDE JetBrains для наших друзей
    0
    курсоры и темы это все нужно вам для красивых скриншотов и статей на хабре

    Мы не используем 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 и с удовольствием научимся работать лучше и быстрее, люди нам всегда нужны :)

  • В День дружбы — скидка 50% на все IDE JetBrains для наших друзей
    –1
    он теперь стабильно позади

    Здесь было бы бесчеловечно не пошутить о темной теме и multiple cursors в Xcode 10, но я не буду. Давайте поймем — что вы конкретно имеете в виду под "позади".


    А постоянные тормоза и пролаги сделали его почти непригодным для работы на средними по размеру проектами на свифте.

    Значит, что-то мы упускаем — но тут опять надо бы понять, что подразумеваем под "тормозами". На открытии проекта в 2018.2 нашли пару регрессий, в RC2 должны быть поправлены — пробовали? Если что-то другое — давайте проитерируем в слэке Рамблера по снэпшотам / проектам, чтобы мы на своей стороне смогли воспроизвести. Или просто пишите на stanislav.dombrovsky@jetbrains.com — попробуем понять, что не так.

  • Что нового в AppCode 2018.1
    0
    Есть ли в планах вынести проверки IDE в инспектор?

    Например поддержка атрибутов, или же просто их эволюцию с «availability» -> «available», или же "_versioned" -> «usableFromInline» и "_inlineable" -> «inlinable»

    Это парсерная ошибка, планов выносить парсерные ошибки в настройки с возможностью их отключения нет. Слишком сложно, слишком много времени, в целом — порочная практика, потому что проблемы начнут замалчиваться, а не решаться в итоге. Плюс частые изменения версии Swift.

    Сейчас подобные изменений аттрибутов мы поддерживаем в зависимости от версии. Как только реализуем в очередном апдейте — начнут корректно обрабатываться как старые, так и новые в зависимости от версии Swift. Конкретно по этим — уже сделано, но пока еще не появилось в обновлениях.
    И второй вопрос — будут ли расширяться возможности Code Style

    В следующей версии скорее всего нет, но это не значит, что если задача окажется простой и на нее не появится времени, она не будет сделана по ходу. Заводите тикет, пусть ребята посмотрят, если окажется просто — сделают.

    Но вот что в одном из будущих релизов мы к форматированию обязательно вернемся, в очередной раз серьезно его доработав — это точно, там еще много хорошего можно сделать.
  • Релиз CLion 2017.3: существенные улучшения поддержки C++, интеграция с Valgrind Memcheck и Boost.Test и многое другое
    0

    Скачайте File Watchers плагин, настройте там clang-format и будет он срабатывать на сохранение.

  • AppCode 2017.1: улучшенная поддержка Swift, новые возможности кодогенерации и многое другое
    0
    Говорят — говорят — им не хватает только command-line интерфейса, в который можно прокинуть лицензионный ключ, чтобы быть интегрированными в AppCode примерно так же, как они интегрировались в Xcode.

    Менюшку, пункты меню легко можно сделать через External tools, потом повесить нужные шорткаты, никаких плагинов не надо даже.
  • AppCode 2017.1: улучшенная поддержка Swift, новые возможности кодогенерации и многое другое
    0
    Похоже, проблема вот тут. Будем править, спасибо!