Лучше mercurial и bitbucket. На него легче перебираться с svn. Хотя главное здесь не то — на googlecode неудобно вести совместную разработку: bug tracker куда как хуже конкурентов, даже bug tracker’а github; нет pull request’ов (впрочем с svn они невозможны); нет многих возможностей вроде annotate, автоматического создания архивов с исходниками (если человеку неохота ставить subversion), показа изменений бок о бок, и т.д.
Описание есть здесь, искать «Character Attributes (SGR)», последний абзац. Кстати, у меня наверху опечатка: должно быть «38 вместо 48», конечно.
Там написано, что это ISO-8613-3. И ещё там написано, что xterm не поддерживает 24‐битный цвет, вместо этого используя ближайший из 256‐цветной палитры (что интересно — человек, давший эту ссылку также пропустил сей факт). Эксперимент показал, что это утверждение верно, но konsole при той же последовательности выдаёт реальный 24‐битный цвет, а не приближение. Теперь мне надо искать какой‐то ещё терминал. Сейчас установлю ещё 13 терминалов и потом скажу, кто ещё поддерживает 24‐битный цвет.
Интересно, а xterm 24-bit color будет? Xterm позволяет указывать 24‐битный цвет в виде последовательностей \e[48;2;{R};{G};{B}m (фон, цвет текста — 48 вместо 38) (все цифры — десятичные, от нуля до 255).
Я сейчас пилю vim для поддержки 24‐битного цвета и хотелось бы видеть эти цвета в качестве фактического стандарта. Известно, что, по крайней мере, konsole также поддерживает эти цвета.
А как проверялось с import calendar каждый раз (и зачем вообще оно проверялось)? Просто Python кэширует модули и последующие подключения производятся из словаря. С reload(calendar) (python 2)/from imp import reload; reload(calendar) картина будет совсем другой, хотя что именно следует использовать зависит от того, зачем это вообще проверялось, может надо до кучи ещё и зависимости перезагружать.
Кстати, сам модуль использует year % 4 == 0 and (year % 100 != 0 or year % 400 == 0).
При чём тут поиск? Когда вы нажимаете c<C-p> с этими настройками вы получаете что‐то вроде cat file | grep …: то есть, строку, начинающуюся на c из истории. cуже набрана. Также вы получаете не строку, содержащую c. И не строку, совпадающую с шаблоном. И не что‐то ещё.
Кроме того, в каком терминале у вас работает <C-S-r>? Терминалы вообще обычно посылают одну и ту же последовательность и для того, и для другого.
Разве <C-r> — не поиск по‐умолчанию? А как работает <C-S-r> я вообще не представляю: в xterm это то же, что и <C-r> (во всяком случае, с настройками по‐умолчанию). В urxvt тоже. В konsole (yakuake) это вообще клавиатурное сочетание, закрывающее вкладку (правда, не факт, что стандартное).
В таких случаях отправляют текст в какой‐нибудь pastebin. Ни в коем случае не делают снимок MessageBox: с ним нельзя нормально работать. Никто не скажет, должен ли быть результат именно таким, потому что это слишком сложно проверить.
По‐моему, вы вообще единственный, кому здесь пришло в голову использовать какой‐либо GUI для вывода результатов.
Haskell, по‐видимости, имеет формат "word" "word1". Не проверял.
Ещё одно свидетельство, что результаты автором не проверялись: решение на Haskell делает все буквы маленькими перед тем, как начать их обрабатывать. Остальные так не делают.
Что?! Формат [word, word2, word3] или ['word', 'word2', 'word3'], конечно, не является идеалом (если надо сравнивать их между собой, то удобнее просто
word
word1
word2
: то, что можно скормить sort, а затем diff). Но это дело исправляется двумя заменами на sed. Сделать такое со снимком окна, да ещё и пожатом (habrastorage оставляет только 800px по ширине), гораздо сложнее.
У меня, кстати, есть сильное подозрение, что результаты реально не проверялись за исключением беглого просмотра: скрипт на perl выдаёт очевидную чушь, потому и отмечен как неправильный, остальные выдают несортированный список, да ещё и в разных форматах. Если бы результаты проверялись полностью, автор наверняка бы выбрал более удобный формат представления.
Интересно, как вы представляете себе проверку результата при использовании данного снимка окна? Точнее, процедуру проверки я представляю, а вот человека, желающего ей заняться — нет.
Кстати, ни одно из представленных решений не выдаст такого результата, все пишут в stdout. Это вообще как получено?
import sys
import re
from collections import defaultdict
n = int(sys.argv[1])
fname = sys.argv[2]
d = defaultdict(int)
regex = re.compile(r'\w+')
with open(fname, 'rb') as f:
for line in f:
for match in regex.finditer(line):
d[match.group()] += 1
print '\n'.join((k for k, v in d.iteritems() if v == n))
Моё: 0,65s user 0,01s system 99% cpu 0,663 total
test3: 0,37s user 0,02s system 97% cpu 0,401 total
Интересно, а почему в разделе «Специальные устройства воспроизведения» нет ни слова про возможность использования обычного ПК? Производители эту возможность как‐то специально зарезали?
Согласен. Предпочитаю emacs с кучей заимствований из vim (не из vi режима), включая <C-r>+/<C-r>*, <C-o>+некоторые операторы. Теперь жалею, что такого нет в самом vim (командный режим там на редкость убог по сравнению с zsh, но не с bash).
У меня пускает more. Причём даже на /dev/null, который имеет нулевой размер. В документации это описано как «shows the contents of file on standard output, with paging if that is a terminal.», ни слова о том, какая программа делает paging или как это настроить.
Вводить меньше всего на одну клавишу («Shift»+«<» vs «c», «a», «t»). Проще настроить alias, особенно учитывая, что в dvorak «a» единственная находится под левой рукой (то есть имеем оптимальную последовательность правая‐левая‐правая, причём две клавиши в основном ряду, в отличие от Shift и <).
Там написано, что это ISO-8613-3. И ещё там написано, что xterm не поддерживает 24‐битный цвет, вместо этого используя ближайший из 256‐цветной палитры (что интересно — человек, давший эту ссылку также пропустил сей факт). Эксперимент показал, что это утверждение верно, но konsole при той же последовательности выдаёт реальный 24‐битный цвет, а не приближение. Теперь мне надо искать какой‐то ещё терминал. Сейчас установлю ещё 13 терминалов и потом скажу, кто ещё поддерживает 24‐битный цвет.
\e[48;2;{R};{G};{B}m(фон, цвет текста — 48 вместо 38) (все цифры — десятичные, от нуля до 255).Я сейчас пилю vim для поддержки 24‐битного цвета и хотелось бы видеть эти цвета в качестве фактического стандарта. Известно, что, по крайней мере, konsole также поддерживает эти цвета.
import calendarкаждый раз (и зачем вообще оно проверялось)? Просто Python кэширует модули и последующие подключения производятся из словаря. Сreload(calendar)(python 2)/from imp import reload; reload(calendar)картина будет совсем другой, хотя что именно следует использовать зависит от того, зачем это вообще проверялось, может надо до кучи ещё и зависимости перезагружать.Кстати, сам модуль использует
year % 4 == 0 and (year % 100 != 0 or year % 400 == 0).c<C-p>с этими настройками вы получаете что‐то вродеcat file | grep …: то есть, строку, начинающуюся наcиз истории.cуже набрана. Также вы получаете не строку, содержащую c. И не строку, совпадающую с шаблоном. И не что‐то ещё.Кроме того, в каком терминале у вас работает
<C-S-r>? Терминалы вообще обычно посылают одну и ту же последовательность и для того, и для другого.<C-r>— не поиск по‐умолчанию? А как работает<C-S-r>я вообще не представляю: в xterm это то же, что и<C-r>(во всяком случае, с настройками по‐умолчанию). В urxvt тоже. В konsole (yakuake) это вообще клавиатурное сочетание, закрывающее вкладку (правда, не факт, что стандартное).По‐моему, вы вообще единственный, кому здесь пришло в голову использовать какой‐либо GUI для вывода результатов.
Это не ответ. Здесь все показывают сам скрипт.
"word" "word1". Не проверял.Ещё одно свидетельство, что результаты автором не проверялись: решение на Haskell делает все буквы маленькими перед тем, как начать их обрабатывать. Остальные так не делают.
[word, word2, word3]или['word', 'word2', 'word3'], конечно, не является идеалом (если надо сравнивать их между собой, то удобнее просто: то, что можно скормитьsort, а затем diff). Но это дело исправляется двумя заменами на sed. Сделать такое со снимком окна, да ещё и пожатом (habrastorage оставляет только 800px по ширине), гораздо сложнее.У меня, кстати, есть сильное подозрение, что результаты реально не проверялись за исключением беглого просмотра: скрипт на perl выдаёт очевидную чушь, потому и отмечен как неправильный, остальные выдают несортированный список, да ещё и в разных форматах. Если бы результаты проверялись полностью, автор наверняка бы выбрал более удобный формат представления.
Кстати, ни одно из представленных решений не выдаст такого результата, все пишут в stdout. Это вообще как получено?
rxvt-unicode — нет.
<C-r>+/<C-r>*,<C-o>+некоторые операторы. Теперь жалею, что такого нет в самом vim (командный режим там на редкость убог по сравнению с zsh, но не с bash).<C-n>/<C-p>получите абсолютно то же самое в bash. Стрелки — зло.Второе же существенно.