Про весь kde не скажу, но ktorrent явно показывает «MiB/s».
А вот в той же консоли dd показывает именно MB. Но суффикс «k» в аргументах командной строки значит 1024. Впрочем, десятичные варианты всех двоичных суффиксов тоже есть.
Там же ls, du, df могут выводить информацию с использованием обоих вариантов, но sort использует только двоичный.
Пример (и у вас и у ниже отписавшегося akzhan) не эквивалентен тому, что наверху: в Python range(n, n+k) возвращает [n, n+1, …, n+k-1]. Не […, n+k].
Ipython — просто штука, в которой иногда удобно по‐быстрому проверить работоспособность кода на Python. Ещё хорошо использовать как калькулятор. Возможность вызывать оболочку — просто приятное дополнение.
Соответственно преимущества перед bash — те же, что и у самого Python. Преимущества именно как замены /bin/bash в /etc/passwd — отсутствуют, он даже не дополняет команды из $PATH, только имена файлов.
Ничего не путаю. Я же явно сказал — git можно попросить сделать автоопределение. Похоже, немного ошибся с тем, какие команды делают такое определение по умолчанию (не вспомнил про annotate).
Покажите то же самое, изменив файл полностью. Или явно указав не просто --follow, а «-M100%» (то есть, потребуйте полное сходство). Или просто возьмите исходники git и покажите, где данная информация сохраняется.
Не видел реальных проектов с такими промежуточными изменениями. Обычно этот факт просто игнорируют, так как процент схожести достаточно высок, либо народу всё равно, так как они не знают, что проверка на переименования происходит каждый раз, когда вы запускаете нужную команду (log, diff) и то только если об этом действии попросить (или настроить соответствующий псевдоним). Только commit и merge делают это по‐умолчанию.
А git не мой, мне всегда больше нравился mercurial. В нём вы можете сделать «hg mv» и изменить всё содержимое. Только на этот раз придётся делать «hg mv» или явно запрашивать автоопределение (hg addremove --similarity), «hg log»/«hg diff» возможностью определения переименований не обладают.
Git не сохраняет информацию о переименованиях. Так что либо после рефакторинга переименованные файлы достаточно схожи, либо будьте любезны иметь промежуточное изменение, содержащее только переименование файлов и ещё одно с собственно изменением содержимого.
Интересно, когда это sed успел научиться нежадными множителями? Небольшой опыт показывает, что .*? ничем не отличается от .*. Точнее от (.*)?, за исключением сохранения текста.
В zsh можно такое устроить переопределяя accept-line widget. Тоже правда выглядит как хак, особенно вместе с функцией, которая засовывает в историю исходный текст, а не то, что будет реально выполнено. Как мне кажется, возможность работы echo abc | sudor { read def && echo $def } | read ghi можно обеспечить в обоих случаях если немного заморочиться.
2. Вообще как в git, так и в mercurial можно настроить хуки, которые отправят изменения сразу после их фиксации. И запретят фиксацию, если в центральном репозитории есть новые изменения. В отличие от псевдонимов, будет работать и в gui. Bazaar так вообще поддерживает такой режим «из коробки».
3. Никогда не видел чужих серверов, которые бы не подтормаживали в сравнении с mercurial. Правда это дело привычки — когда команда начинает работать быстрее старая версия начинает заметно тормозить, хотя на самом деле исполняется с той же скоростью.
У меня тоже проекты по большей части развиваются одним мной, но тем не менее мне зачастую нужны ветки для экспериментального кода. Работа с такими вещами в svn, по моему мнению, весьма неудобна.
Subversion создаёт слишком много точек отказа: для работы помимо самого компьютера нужны ещё как минимум сеть (как минимум две точки — от клиента и от сервера, то, что посередине обычно весьма надёжно) и сам сервер.
Кроме того, правка описания изменения неудобна и требует включения некоторых возможностей на стороне сервера, а как быть, если мне нужно поправить само изменение (что‐то забыл включить в коммит или включил что‐то не то) я не представляю (правда если использовать предложенные в п.2 хуки то в git/mercurial обе операции станут ещё более неудобными, а в mercurial на чужом сервере — вообще невозможной без полного удаления репозитория; что с bazaar — не знаю).
Ага, только я теперь не могу нормально сказать, что хочу видеть только запущенные vim, а не какой‐нибудь screen с -S vim-test. Писать шаблон, который с гарантией выберет только запущенные vim мне не хочется совершенно. Уж лучше я использую сокращения zsh чтобы сократить | grep в G: pps vim G foo. Или просто выберу глазами, гарантированно не получив в числе прочего вывода мусор с vim в аргументах или безумно длинные строчки (люблю открывать все файлы проекта сразу, всё равно vim реально их грузит в память только при необходимости) (ps обрезает строчки, если вывод осуществляется на терминал, pgrep нет).
В имени файла могут быть одинарные кавычки. Причём даже на Windows. Правится одной строчкой, но делать этого не надо: взаимодействие с Vim всегда весьма медленно. Поэтому надо не использовать цикл, а собрать всё в один большой список:
Не делайте так никогда. Есть VIM::Eval("expand('<sfile>:h')"), нужное именно для этого. Ни у меня, ни у огромного числа пользователей pathogen, vundle и vim-addon-manager нет ни малейшего желания помещать ваше дополнение в $HOME/.vim. Кроме того, зачем зря трудить Vim, чтобы он просматривал каталог plugin/cmake-project, в котором для него ничего нет, если можно отправить всё это дело в perl/cmakeproject.pm?
Знаю. Абсолютно бесполезная для меня вещь: во‐первых, мне не нужно и абсолютно не радует использование шаблонов (особенно, требующих по‐умолчанию только частичного совпадения). Во‐вторых, pgrep не пишет аргументы. Нафига мне знать, какие 15 PID соответствуют Vim, если завис и надо прибить только один? Аргументы, с которым я запустил зависший известны, но не номер pty (к тому же, часто не уникальный), не PID (зачем бы мне иначе ps -C?), не SID (что это вообще такое? впрочем не отвечайте, сам нашёл. Проблема та же, что и с терминалом) и не куча других неуникальных параметров.
Там есть поддержка OpenID, анонимные вопросы («user\d+» со слабо отличимым от нуля рейтингом — это они) и возможность связывать аккаунты на множестве сайтов в один (как правило, происходит автоматически). Stackexchange — это просто название проекта, в рамках которого развивается stackoverflow и ещё куча подобных сайтов на том же движке.
Нет, но это показатель того, насколько хорошо устроен редактор. У Vim отличный UI и множество дополнений, из‐за чего (особенно первого) я его и использую, но VimL и архитектура очень далеки от идеальных. Про VimL вы можете почитать мою статью, а архитектура — это общее впечатление от того, что вы
не видите C API, для улучшения интерфейсов с другими языками зачастую приходится экспортировать существующую static функцию или выделять существующий код в отдельную функцию. Единственная документация — комментарии и их далеко не всегда достаточно;
видите отсутствие нормального поддержки клавиатурных сочетаний. Обсуждениям на эту тему уже невесть сколько лет, но у Брама нет времени, а у остальных, видимо, пороха на такую задачу;
видите множество запросов вида «а как сделать подсветку строки там где нет символов/подсветить N’ю колонку» Второе уже решено, но если бы вместо :syn было внятное C API, используемое первой, и соответствующие функции на Python/…, то вопрос бы не требовал создания целой новой настройки;
видите до сих пор не исправленные неровности в скрытии символов вроде некрасивой табуляции, невозможности получить видимую позицию курсора, необходимости нажимать l/h столько раз, сколько символов сокрыто, …;
видите вопросы «а почему я не могу сделать nnoremap d smth, не получая задержку при вводе d»
, то у вас остаётся впечатление, что с архитектурой что‐то не то.
Собственно, VimL, система подсветки и система ввода — то, что нуждается в улучшениях, причём второе можно сделать без нарушения обратной совместимости, третье тоже (хотя если вы попросите меня это сделать или дождётесь пока сам созрею, то часть обратной совместимости будет намеренно нарушена, могу объяснить какая и почему). Вместо первого лучше иметь C API с доступом ко всем возможностям редактора и соответствующие интерфейсы: для того, чтобы всё использование VimL сводилось к чему‐то вроде
. Впрочем это не отменит того, что я считаю необходимым сделать VM для VimL, но это имеет мало смысла без потери малой части обратной совместимости: скажите, как Vim может воспринять вторую строку в следующем коде:
execute variable
nnoremap a b
? Я знаю как минимум три варианта. Если запретить незавершённые блоки :if/:for/:try/:while/:function и принудительно завершать :append/:insert по окончании :execute то всё сведётся к двум вариантам (никак и как создание привязки) и при том возможно будет построить синтаксическое дерево.
У меня основной используемой программой является редактор, но всё же потеря других настроек (zsh, Opera, mplayer, mercurial) была бы весьма неприятной. Особенно zsh и Opera, остальное легко восстановить.
Впрочем, в случае Opera одним репозиторием дело не ограничивается — так как я с самого начала рассматривал возможность сделать его публичным при необходимости, то пароли есть только в резервных копиях.
Изкоробочное решение не может обладать универсальностью: я не хочу иметь один способ восстановления для IDEVim, другой для zsh, третий для браузера. Вопрос здесь в том, как хранятся эти самые настройки? Не трогал файлы IDE, но с firefox, насколько мне известно, простое копирование файлов в другое место легко может и не пройти. Легко получить различия двух разных версий sqlite базы данных, в которой он и хранит настройки, точно не выйдет (правда, мне это почти никогда не нужно).
И ещё — пакетный менеджер там действительно увидев несоответствие между списком дополнений и тем, что реально установлено, начнёт установку недостающих частей? Или придётся заталкивать туда и сами дополнения? VAM, в частности, удобен тем, что если я использую свой vimrc на arm нетбуке, то он загрузит и скомпилирует Command-T. Писать дополнительный код для его компиляции или иметь репозиторий с бинарниками с неправильной архитектурой не требуется.
У редактора или IDE его и так нет. Он есть у меня, и там хранятся все настройки, не только редактора. Кроме того, странно, что вы не слышали: на github 20 449 репозиториев, названных «dotfiles». Значительное количество подобных репозиториев названо по‐другому (у меня — config, но на bitbucket и скрытый).
И это разве сложно? Как раз удобно — хранить настройки в репозитории, чтобы при переустановке ОС/покупке нового компьютера/… не начинать с нуля.
Если также сохранить и /etc (+ аналог /var/lib/portage/world из Gentoo со списком установленных пакетов) (и сделать резервные копии всего из $HOME, что не вошло в репозиторий с настройками), то у вас будет вся информация, необходимая для восстановления системы или отката при неверно выполненной настройке.
Получается, дополнения надо ставить и туда, и туда. Но у меня список дополнений описан в vimrc и для того, чтобы их поставить надо выполнить всего четыре действия:
Клонировать репозиторий с настройками.
Создать в нужном месте символические ссылки.
Клонировать vim-addon-manager.
Запустить Vim.
Vim-addon-manager далее затем сам установит всё, что нужно. Причём первый и третий шаги можно объединить с помощью submodules (я так не сделал, потому что VAM у меня установлен пакетным менеджером) либо поместив в vimrc код, который делает третий шаг (код можно просто скопировать из документации). Конечно, нужен по крайней мере git, но он нужен и с IDE.
А вот в той же консоли dd показывает именно MB. Но суффикс «k» в аргументах командной строки значит 1024. Впрочем, десятичные варианты всех двоичных суффиксов тоже есть.
Там же ls, du, df могут выводить информацию с использованием обоих вариантов, но sort использует только двоичный.
range(n, n+k)возвращает[n, n+1, …, n+k-1]. Не[…, n+k].Ipython — просто штука, в которой иногда удобно по‐быстрому проверить работоспособность кода на Python. Ещё хорошо использовать как калькулятор. Возможность вызывать оболочку — просто приятное дополнение.
Соответственно преимущества перед bash — те же, что и у самого Python. Преимущества именно как замены /bin/bash в /etc/passwd — отсутствуют, он даже не дополняет команды из $PATH, только имена файлов.
Покажите то же самое, изменив файл полностью. Или явно указав не просто --follow, а «-M100%» (то есть, потребуйте полное сходство). Или просто возьмите исходники git и покажите, где данная информация сохраняется.
А git не мой, мне всегда больше нравился mercurial. В нём вы можете сделать «hg mv» и изменить всё содержимое. Только на этот раз придётся делать «hg mv» или явно запрашивать автоопределение (hg addremove --similarity), «hg log»/«hg diff» возможностью определения переименований не обладают.
Так что дело ещё и в VCS.
.*?ничем не отличается от.*. Точнее от(.*)?, за исключением сохранения текста.В zsh можно такое устроить переопределяя accept-line widget. Тоже правда выглядит как хак, особенно вместе с функцией, которая засовывает в историю исходный текст, а не то, что будет реально выполнено. Как мне кажется, возможность работы
echo abc | sudor { read def && echo $def } | read ghiможно обеспечить в обоих случаях если немного заморочиться.3. Никогда не видел чужих серверов, которые бы не подтормаживали в сравнении с mercurial. Правда это дело привычки — когда команда начинает работать быстрее старая версия начинает заметно тормозить, хотя на самом деле исполняется с той же скоростью.
У меня тоже проекты по большей части развиваются одним мной, но тем не менее мне зачастую нужны ветки для экспериментального кода. Работа с такими вещами в svn, по моему мнению, весьма неудобна.
Subversion создаёт слишком много точек отказа: для работы помимо самого компьютера нужны ещё как минимум сеть (как минимум две точки — от клиента и от сервера, то, что посередине обычно весьма надёжно) и сам сервер.
Кроме того, правка описания изменения неудобна и требует включения некоторых возможностей на стороне сервера, а как быть, если мне нужно поправить само изменение (что‐то забыл включить в коммит или включил что‐то не то) я не представляю (правда если использовать предложенные в п.2 хуки то в git/mercurial обе операции станут ещё более неудобными, а в mercurial на чужом сервере — вообще невозможной без полного удаления репозитория; что с bazaar — не знаю).
-S vim-test. Писать шаблон, который с гарантией выберет только запущенные vim мне не хочется совершенно. Уж лучше я использую сокращения zsh чтобы сократить| grepвG:pps vim G foo. Или просто выберу глазами, гарантированно не получив в числе прочего вывода мусор с vim в аргументах или безумно длинные строчки (люблю открывать все файлы проекта сразу, всё равно vim реально их грузит в память только при необходимости) (ps обрезает строчки, если вывод осуществляется на терминал, pgrep нет).В имени файла могут быть одинарные кавычки. Причём даже на Windows. Правится одной строчкой, но делать этого не надо: взаимодействие с Vim всегда весьма медленно. Поэтому надо не использовать цикл, а собрать всё в один большой список:
VIM::Eval("expand('<sfile>:h')"), нужное именно для этого. Ни у меня, ни у огромного числа пользователей pathogen, vundle и vim-addon-manager нет ни малейшего желания помещать ваше дополнение в $HOME/.vim. Кроме того, зачем зря трудить Vim, чтобы он просматривал каталог plugin/cmake-project, в котором для него ничего нет, если можно отправить всё это дело в perl/cmakeproject.pm?ps -C?), не SID (что это вообще такое? впрочем не отвечайте, сам нашёл. Проблема та же, что и с терминалом) и не куча других неуникальных параметров.kill, еслиkillallнеприменим и что я редактирую в Vim’ах (с прибиванием лишнего).ps ax | grep? Гораздо проще и надёжнее использовать[[ "$(ps -C vmplayer -o args=)" == *user01* ]](bash/zsh) или эквивалент с grep.- не видите C API, для улучшения интерфейсов с другими языками зачастую приходится экспортировать существующую static функцию или выделять существующий код в отдельную функцию. Единственная документация — комментарии и их далеко не всегда достаточно;
- видите отсутствие нормального поддержки клавиатурных сочетаний. Обсуждениям на эту тему уже невесть сколько лет, но у Брама нет времени, а у остальных, видимо, пороха на такую задачу;
- видите множество запросов вида «а как сделать подсветку строки там где нет символов/подсветить N’ю колонку» Второе уже решено, но если бы вместо :syn было внятное C API, используемое первой, и соответствующие функции на Python/…, то вопрос бы не требовал создания целой новой настройки;
- видите до сих пор не исправленные неровности в скрытии символов вроде некрасивой табуляции, невозможности получить видимую позицию курсора, необходимости нажимать l/h столько раз, сколько символов сокрыто, …;
- видите вопросы «а почему я не могу сделать
, то у вас остаётся впечатление, что с архитектурой что‐то не то.nnoremap d smth, не получая задержку при вводе d»Собственно, VimL, система подсветки и система ввода — то, что нуждается в улучшениях, причём второе можно сделать без нарушения обратной совместимости, третье тоже (хотя если вы попросите меня это сделать или дождётесь пока сам созрею, то часть обратной совместимости будет намеренно нарушена, могу объяснить какая и почему). Вместо первого лучше иметь C API с доступом ко всем возможностям редактора и соответствующие интерфейсы: для того, чтобы всё использование VimL сводилось к чему‐то вроде
. Впрочем это не отменит того, что я считаю необходимым сделать VM для VimL, но это имеет мало смысла без потери малой части обратной совместимости: скажите, как Vim может воспринять вторую строку в следующем коде:
? Я знаю как минимум три варианта. Если запретить незавершённые блоки :if/:for/:try/:while/:function и принудительно завершать :append/:insert по окончании :execute то всё сведётся к двум вариантам (никак и как создание привязки) и при том возможно будет построить синтаксическое дерево.
Впрочем, в случае Opera одним репозиторием дело не ограничивается — так как я с самого начала рассматривал возможность сделать его публичным при необходимости, то пароли есть только в резервных копиях.
IDEVim, другой для zsh, третий для браузера. Вопрос здесь в том, как хранятся эти самые настройки? Не трогал файлы IDE, но с firefox, насколько мне известно, простое копирование файлов в другое место легко может и не пройти. Легко получить различия двух разных версий sqlite базы данных, в которой он и хранит настройки, точно не выйдет (правда, мне это почти никогда не нужно).И ещё — пакетный менеджер там действительно увидев несоответствие между списком дополнений и тем, что реально установлено, начнёт установку недостающих частей? Или придётся заталкивать туда и сами дополнения? VAM, в частности, удобен тем, что если я использую свой vimrc на arm нетбуке, то он загрузит и скомпилирует Command-T. Писать дополнительный код для его компиляции или иметь репозиторий с бинарниками с неправильной архитектурой не требуется.
И это разве сложно? Как раз удобно — хранить настройки в репозитории, чтобы при переустановке ОС/покупке нового компьютера/… не начинать с нуля.
Если также сохранить и /etc (+ аналог /var/lib/portage/world из Gentoo со списком установленных пакетов) (и сделать резервные копии всего из $HOME, что не вошло в репозиторий с настройками), то у вас будет вся информация, необходимая для восстановления системы или отката при неверно выполненной настройке.
Vim-addon-manager далее затем сам установит всё, что нужно. Причём первый и третий шаги можно объединить с помощью submodules (я так не сделал, потому что VAM у меня установлен пакетным менеджером) либо поместив в vimrc код, который делает третий шаг (код можно просто скопировать из документации). Конечно, нужен по крайней мере git, но он нужен и с IDE.