3) Swap двух строк через ctrl+shift+up/down очень часто выдаёт совершенно неожиданный результат. Я хочу просто поменять две строки местами, но, как правило, у автоформаттера на это свои планы. В результате я своппером не могу пользоваться.
Я в таких случайх использую Alt+Shift+Up/Down, это простое перемещение строк без учета семантики конструкций и без вызова форматтера. Попробуйте, может, найдёте использование этих экшнов для себя более удобным, например, в сочетании с Expand/Shrink Selection перед перемещением строк.
В качестве оптимизации да. Но поскольку оптимизации не должны изменять семантику программы, на вывод типов это не влияет. Если бы в C были constexpr-функции из C++, тогда другое дело (наверное).
Интересно, я бы тоже ожидал аналогичную оптимизацию внутри самого движка regex'ов стандартной библиотеки, но тем не менее regex вида \b(Ruby|Python|Java|J2ee)\b все равно сильно проигрывает FlashText (я использовал бенчмарк по ссылке из комментариев к оригинальной статье).
С другой стороны, если задача ограничивается поиском ключевых слов, не содержащих пробелов внутри себя, то простой regex \b\w+\b с заменой compiled_re.sub(lambda m: rep.get(m.group(0), m.group(0)), story) (заменять вообще все слова; те, что неинтересны, заменять на самих себя) ожидаемо уделывает эту библиотеку раза в 2-3:
В общем-то, можно даже извернуться и добавить поддержку замены слов с пробелами внутри. Но это не отменяет того, что отдельная библиотека, решающая эту задачу хорошо, имеет право на жизнь, конечно.
Позволю себе прорекламировать плагин C Improved на случай, если вы собираетесь писать много кода на C/C++.
Исправляет многие косяки стандартного синтаксиса, например, ломающие подсветку макросы, глюки Goto Definition вроде неспособности индексировать typedef struct, а также немного улучшает подсветку синтаксических ошибок в коде.
Через sysfs минимальный квант — 3 мсек, прямая работа с регистрами — 100 нсек.
3 мсек требуется для переключения из user space, прохождения всего стека Linux vfs и отработки драйвера sysfs (ну и на то, чтобы вернуться по стеку обратно, наверное). При прямой работе с регистрами из ядерного драйвера Linux таких накладных расходов, конечно, нет.
Сам скрипт генерации вот тут, а вызов его декларируется в модуле, который отвечает за разрешение зависимостей в рантайме. Скрипт просто генерирует Сишный код в stdout, а вывод сохраняется в файл, который уже компилируется и линкуется как обычный.
Оу, боюсь, это на целую статью потянет, в прошлой, пожалуй, только поверхностное описание. А какая именно часть вас интересует?
Вообще мы сейчас работаем над следующей инкарнацией системы сборки (пишем на Питоне, а под капотом Waf). Вот про неё, думаю, было бы круто рассказать, но пока что мы только пилим сам код. =)
Скорее всего, тоже на Гитхаб. Автоматически переносить не стали, поскольку хотим перетрясти структуру, да и вообще в порядок привести.
С переездом на Гитхаб (всего остального) вообще целая эпопея вышла, потому как мы заморочились еще и переносом всех ишью с сохранением авторства и дат. Плюс добавили к гитовой истории самые ранние коммиты, которых не было на Гугл Коде. Вики будем воссоздавать скорее всего вручную.
Наверное самый адовый ад с питоньим стеком из того, что я видел, вытворяют в Jinja2 для получения более понятных стек-трейсов при ошибках в шаблонах: github.com/mitsuhiko/jinja2/blob/master/jinja2/debug.py.
Например, название функции `_init_ugly_crap()`, уже намекает. :)
В принципе, это тоже решаемо (авторство, даты ишью и комментариев и все прочее). Правда, только в ручном режиме через поддержку Гитхаба. Переезд golang тому пример.
Оу, авто-регистрация тестов (да и вообще чего угодно) — это извечная тема для C. =)
Я не так давно описывал в комментариях к похожей статье один приём, годный в т.ч. и для регистрации тестов: тут и тут. В итоге получаем возможность писать тесты, например, вот как тут.
А, теперь понимаю, о чем вы. Да, скорее всего, это есть не во всех версиях binutils, с ходу так не могу сказать, почему мы это не использовали. Может, ещё и из-за необходимости NULL-терминированных массивов указателей.
и при этом не занимают места, потому что это просто символы линкера, а не байты в памяти. Это позволяет ещё чуть-чуть уменьшить overhead.
Указатели в нашем решении тоже не занимают байтов в памяти, это такие же символы, которые определяются через массивы нулевой длины.
Просто const уложится в .rodata, да, но у нас-то (и у вас) ещё и атрибут section. И эти секции нужно уложить в правильном порядке: указатель на голову, потом элементы, потом терминирующий элемент, если есть, и указатель на конец. Для этого нужен SORT в *(SORT(.array_spread.*.rodata)).
Вы имеете в виду, зачем нужен const? Здесь он не обязателен, поскольку мы явно указываем секцию через атрибут, но это полезно для дополнительного контроля со стороны компилятора. А куда пойдет секция, определяется в линкер-скрипте, в нашем случае мы отправляем её в .rodata.
Перенесли из-за желания сделать команды максимально стандартными, тем самым уменьшив порог вхождения. Как бонус, получили возможность собирать команды из нашей ОС на unix хостах (без изменений), наоборот — тоже получается достаточно хорошо.
Это понятно. Но, как я понимаю, относится к сигнатуре обработчика команд, а не к способу регистрации команд.
В отдаленных планах, кстати, есть отказ и от этого. То есть команда неотличима от обычного приложения с функцией main, а при сборке глобальные символы (в т.ч. main) манглятся, и команда регистрируется «как обычно».
Но даже в этом варианте добавление/удаление новой команды требует редактирования двух файлов.
Для нас это что-то вроде неизбежного зла. Любой модуль так и так требует этих двух файлов, да и забыть поправить справку к команде не такая уж беда.
Я в таких случайх использую Alt+Shift+Up/Down, это простое перемещение строк без учета семантики конструкций и без вызова форматтера. Попробуйте, может, найдёте использование этих экшнов для себя более удобным, например, в сочетании с Expand/Shrink Selection перед перемещением строк.
В качестве оптимизации да. Но поскольку оптимизации не должны изменять семантику программы, на вывод типов это не влияет. Если бы в C были constexpr-функции из C++, тогда другое дело (наверное).
Интересно, я бы тоже ожидал аналогичную оптимизацию внутри самого движка regex'ов стандартной библиотеки, но тем не менее regex вида
\b(Ruby|Python|Java|J2ee)\b
все равно сильно проигрывает FlashText (я использовал бенчмарк по ссылке из комментариев к оригинальной статье).С другой стороны, если задача ограничивается поиском ключевых слов, не содержащих пробелов внутри себя, то простой regex
\b\w+\b
с заменойcompiled_re.sub(lambda m: rep.get(m.group(0), m.group(0)), story)
(заменять вообще все слова; те, что неинтересны, заменять на самих себя) ожидаемо уделывает эту библиотеку раза в 2-3:В общем-то, можно даже извернуться и добавить поддержку замены слов с пробелами внутри. Но это не отменяет того, что отдельная библиотека, решающая эту задачу хорошо, имеет право на жизнь, конечно.
Попробуйте изменить настройку Editor → General → Editor Tabs → Tab Closing Policy на Activate most recently opened tab
Исправляет многие косяки стандартного синтаксиса, например, ломающие подсветку макросы, глюки Goto Definition вроде неспособности индексировать typedef struct, а также немного улучшает подсветку синтаксических ошибок в коде.
3 мсек требуется для переключения из user space, прохождения всего стека Linux vfs и отработки драйвера sysfs (ну и на то, чтобы вернуться по стеку обратно, наверное). При прямой работе с регистрами из ядерного драйвера Linux таких накладных расходов, конечно, нет.
Вообще мы сейчас работаем над следующей инкарнацией системы сборки (пишем на Питоне, а под капотом Waf). Вот про неё, думаю, было бы круто рассказать, но пока что мы только пилим сам код. =)
С переездом на Гитхаб (всего остального) вообще целая эпопея вышла, потому как мы заморочились еще и переносом всех ишью с сохранением авторства и дат. Плюс добавили к гитовой истории самые ранние коммиты, которых не было на Гугл Коде. Вики будем воссоздавать скорее всего вручную.
P.S. Старая статья на хабре.
Наверное самый адовый ад с питоньим стеком из того, что я видел, вытворяют в Jinja2 для получения более понятных стек-трейсов при ошибках в шаблонах: github.com/mitsuhiko/jinja2/blob/master/jinja2/debug.py.
Например, название функции `_init_ugly_crap()`, уже намекает. :)
Я не так давно описывал в комментариях к похожей статье один приём, годный в т.ч. и для регистрации тестов: тут и тут. В итоге получаем возможность писать тесты, например, вот как тут.
Указатели в нашем решении тоже не занимают байтов в памяти, это такие же символы, которые определяются через массивы нулевой длины.
Для нас это что-то вроде неизбежного зла. Любой модуль так и так требует этих двух файлов, да и забыть поправить справку к команде не такая уж беда.