Цитата была переврана сознательно — теперь она звучит двусмысленно. (На самом деле я ее именно так запомнил (неправильно); при написании поста полез проверять, и убедился, что неправ, но решил, что у меня лучше.)
Вообще ребенок достаточно хорошо понимает это (про потенциальный вред здоровью и про то, что надо вначале уроки сделать). И вообще дети нынче пошли на удивление умные и развитые во всех местах. Но (уж не знаю в чем причина, пусть психологи объясняют) они могут поступать заведомо иррационально (то есть осознавая свою неправоту), причем по многу раз в одной и той же ситуации. Терпеливый воспитатель постоянно должен напоминать одно и то же. Я же совсем не терпеливый, пусть лучше робот напоминает.
По факту сейчас так и происходит — не запрет, а контроль (несовершенный, но пока почти достаточный). Мне стало неудобно тратить психические ресурсы на воздействия, хочется хотя бы часть автоматизировать.
> Возможно, они добавили эти опции, чтобы нельзя было сказать, что они просто украли код у AT&T
Наверно причина всё-таки в том, чтобы удовлетворить GNU-стилю опций для консольных команд (длинные опции начинаются с двух минусов, однобуквенные — с одной, обязательно наличие --help и --version).
Если же в этой фразе была шутка автора поста, то она тонка и зачетна. ;)
Я, по правде сказать, самим гитхабом и не пользовался (как участник какого-либо проекта). Пользуюсь своим сервером с зоопарком репозиториев. ;)
На самом деле, когда я предлагал «выложить на гитхаб», имел в виду просто поместить в какой-либо публичный репозиторий, даже не обязательно git (хотя сам уже давно не пользуюсь ни subversion, ни, тем более, CVS — только git'ом).
> Как я понял, гитхаб нужен для двух вещей:…
К вышеуказанным пунктам можно добавить хранение истории комитов, а также возможность заинтересованным (но непроверенным) людям удобно делать свои ветки и форки. Да, слово «гитхаб» здесь можно заменить на более общее «любой публичный репозиторий». Если у вас есть предпочтение (или умение) использовать не гит, а, например, mercury или subversion, то лучше пользоваться ими; только придется найти соответствующий сервер или завести свой.
> Тогда как лучше отконфигурить репозиторий?
Это можно по ходу менять по мере надобности, сейчас вроде можно оставить всё по умолчанию.
Насчет ssh-ключей. Протокол ssh — один из общих методов доступа к git-серверу. Сам по себе ssh-протокол универсален (запуск программ (прежде всего shell) на удаленной машине) и имеет два основных способа доступа к серверу: пароль и ключ (обычно RSA). Насколько я понял, конкретно в github доступ по паролю отключен (это просто настройка сервера), но есть логин/пароль для доступа на веб-сервер, которые совершенно ортогональны. Что касается ssh-ключа, то его как раз лучше делать БЕЗ passphrase (почему-то принято говорить, что у ключа не password, а passphrase): одна из функций ключа (помимо большей криптозащиты) — снятие необходимости каждый раз набирать пароль при доступе с доверенного компа. Passphrase нужна лишь на случай взлома вашего компа и кражи с него секретной части ключа. В данном случае это не очень осмысленно, поскольку снявши голову (домашний комп) по волосам (логин на гитхабе) не плачут.
Да, я только что зарегистрировался на гитхабе с логином janatem. Чтоб было.
Да и какое там SDK — всего лишь (почему-то закрытая) единственная библа inkview. А весь набор инструментов состоит из gcc для arm, который не обязательно брать из ихнего SDK.
> будет диапазон ААА-БББ с парой тысяч, а диапазон ЕЕЕ-ННН — вообще пустой.
По построению в каждой пачке будет одинаковое количество элементов. То есть может случиться так, что создадутся ААА-ААВ и ААГ-ЯЯЯ, но в каждой из них будет (примерно) поровну.
Ну ладно, может такая тулза и не очень целесообразна. Просто я пока не изучил этих калибрей прочие программы-каталогизации. Возможно, какая-нибудь из них меня удовлетворит.
А я уже завелся и скачал SDK для покетбука. ;) Правда, всё равно нет возможность достаточно времени этому уделять…
Ну даже двойной проход не проблема — машина-то железная. ;) И БД — это громко сказано. Так, ассоциативный массивчик (в языке, насколько я понял, такой тип встроен, так?).
Можно даже внешний вызов сделать, чтоб количество посчитать:
find . -name '*.fb2'
Правда, это вроде не особо помогает, потому что небходимо выковырять имена из файлов.
Берем всё множество строк (авторов), сортируем. Пусть их N штук. Далее, берем параметр q — желаемое количество детей у каждой вершины (макс количество элементов в каждой директории), находим такое n, что
q^(n-1) < N <= q^n
Это будет глубина дерева. Впрочем, для алгоритма ее не нужно вычислять, само получится. Собственно, сам алгоритм:
Берем пачку из первых N/q строк — они все будут помещаться в первую директорию (возможно, вложенно). Нужно найти правильное имя этой директории. Делается это так: берем несколько первых букв первого автора и несколько первых букв последнего в пачке (сколько именно — потом станет ясно), слепляем их через тире — имя готово. Далее, создаем директорию с таким именем и заходим в нее (на самом деле, конечно, лучше отделить создание файлов от вычислений); рекурсивно вызываем алгоритм, передав ему первую пачку строк в качестве всего множества.
Затем выполняем то же самое со второй пачкой — строки с номерами от N/q до 2N/q-1. И т.д. до последней пачки.
Теперь о том, сколько первых букв имени выбирать. Главное — чтобы префикс данной длины различался у последней строки данной пачки и первой строки следующей. Можно также дополнительно потребовать, чтобы на всём уровне все такие длины были одинаковыми — так будет красивее.
Так, я нашел один из плохих файлов (хотя он не единственный). Ломаются обе версии xmlp_data2struct_old() и xmlp_data2struct(). На хороших файлах больше 100МБ вроде не отъедалось, а на этом жрется вся память.
Что-то не соображу, как лучше файл передать. (Он был в сборке «Русская классика» с диска, прилагаемого к устройству; его md5sum: 0f3730e48d5db8bd5163c2bb94f21906 Lohvitskaya_Oborotni.55375.fb2 .)
Да, я об интерфейсе самого устройства: если содержимое директории будет занимать несколько страниц, то нужно будет нажимать несколько раз кнопку PgDn, чтобы найти нужное, а он каждый раз перерисовывает экран и тормозит. А вот бродить вверх-вниз на одной странице — гораздо более быстрая операция. Глобальный вопрос в том, чтобы минимизировать полное время поиска нужного файла. Вроде бы очевидно, что для этого нужно иметь на каждом уровне примерно одинаковое число веток, и вопрос лишь в том, сколько именно: если больше, то надо листать страницы, если меньше — будет глубже дерево. Причем глубина растет логарифмически, поэтому, возможно, выгоднее сделать столько веток, чтобы умещалось на одной странице.
Про гитхаб: операция помещения туда почти ничего не стоит (если, разумеется, человек вообще владеет git'ом). А польза от «как описание и пример реализации идеи» уже стоит того.
2. Да, было бы круто. Только хорошо бы сразу сделать генерацию многоуровневого дерева, тогда вроде бы нужен единственный параметр — максимальное количество детей у каждой вершины. Должно быть равно количеству строк на экране; хотя я уже засомневался — может удобней лишний раз нажать PgDn, чем иметь лишний уровень?
Кстати, как насчет того, чтобы выложить, например, в гитхаб?
1. По правде сказать, я и помыслить себе не могу, чтобы возник баг из-за имени директории. С другой стороны я уже сталкивался с чем-то таким: закомитил в репозиторий файл aux.tcl, а потом коллеги не могли его выкачать из-за того, что в винде имя файла aux соответствует устройству.
2. С использованием cp1251 во внутренней кухне я вижу только одну проблему: некоторые алфавиты (арабский, иврит, может быть даже украинский) в нее не умещаются, поэтому либо сломается внутренний вызов конвертера, либо на выходе будут неадекватные символы.
3. Я примерно так и сделал — поковырялся в get_splitten_dirs(), чтобы убрать трехбукрвенные директории. Естественно, построение префиксного дерева требует более серьезного рефакторинга.
4. Попозже (в нерабочее время) я повторю процедуру, чтобы найти конкретно проблемные файлы (а то я их уже потер). Сейчас могу сказать, что проблемы возникли с той библиотекой, что была на устройстве (или на прилагаемом диске) при покупке. Возможно, я что-то переносил, но скорее всего изначально были директории library/{Зарубежная Классика, Русская Классика}, и в обеих были плохие файлы.
Объяснение, что это из-за регвыров — вполне логичное.
Про образ раздела сделаю.
Исходники были не последние, а, скорее всего, первые.
Я отметил в тексте, что если ситуация меняется, то следует признать, что ребенок стал достаточно взрослым, и не пытаться мешать ему.
Наверно причина всё-таки в том, чтобы удовлетворить GNU-стилю опций для консольных команд (длинные опции начинаются с двух минусов, однобуквенные — с одной, обязательно наличие --help и --version).
Если же в этой фразе была шутка автора поста, то она тонка и зачетна. ;)
На самом деле, когда я предлагал «выложить на гитхаб», имел в виду просто поместить в какой-либо публичный репозиторий, даже не обязательно git (хотя сам уже давно не пользуюсь ни subversion, ни, тем более, CVS — только git'ом).
> Как я понял, гитхаб нужен для двух вещей:…
К вышеуказанным пунктам можно добавить хранение истории комитов, а также возможность заинтересованным (но непроверенным) людям удобно делать свои ветки и форки. Да, слово «гитхаб» здесь можно заменить на более общее «любой публичный репозиторий». Если у вас есть предпочтение (или умение) использовать не гит, а, например, mercury или subversion, то лучше пользоваться ими; только придется найти соответствующий сервер или завести свой.
> Тогда как лучше отконфигурить репозиторий?
Это можно по ходу менять по мере надобности, сейчас вроде можно оставить всё по умолчанию.
Насчет ssh-ключей. Протокол ssh — один из общих методов доступа к git-серверу. Сам по себе ssh-протокол универсален (запуск программ (прежде всего shell) на удаленной машине) и имеет два основных способа доступа к серверу: пароль и ключ (обычно RSA). Насколько я понял, конкретно в github доступ по паролю отключен (это просто настройка сервера), но есть логин/пароль для доступа на веб-сервер, которые совершенно ортогональны. Что касается ssh-ключа, то его как раз лучше делать БЕЗ passphrase (почему-то принято говорить, что у ключа не password, а passphrase): одна из функций ключа (помимо большей криптозащиты) — снятие необходимости каждый раз набирать пароль при доступе с доверенного компа. Passphrase нужна лишь на случай взлома вашего компа и кражи с него секретной части ключа. В данном случае это не очень осмысленно, поскольку снявши голову (домашний комп) по волосам (логин на гитхабе) не плачут.
Да, я только что зарегистрировался на гитхабе с логином janatem. Чтоб было.
Собственно, API этой библы и нужно вкуривать.
По построению в каждой пачке будет одинаковое количество элементов. То есть может случиться так, что создадутся ААА-ААВ и ААГ-ЯЯЯ, но в каждой из них будет (примерно) поровну.
Ну ладно, может такая тулза и не очень целесообразна. Просто я пока не изучил этих калибрей прочие программы-каталогизации. Возможно, какая-нибудь из них меня удовлетворит.
А я уже завелся и скачал SDK для покетбука. ;) Правда, всё равно нет возможность достаточно времени этому уделять…
Можно даже внешний вызов сделать, чтоб количество посчитать:
find . -name '*.fb2'Правда, это вроде не особо помогает, потому что небходимо выковырять имена из файлов.
Берем всё множество строк (авторов), сортируем. Пусть их N штук. Далее, берем параметр q — желаемое количество детей у каждой вершины (макс количество элементов в каждой директории), находим такое n, что
q^(n-1) < N <= q^nЭто будет глубина дерева. Впрочем, для алгоритма ее не нужно вычислять, само получится. Собственно, сам алгоритм:
Берем пачку из первых N/q строк — они все будут помещаться в первую директорию (возможно, вложенно). Нужно найти правильное имя этой директории. Делается это так: берем несколько первых букв первого автора и несколько первых букв последнего в пачке (сколько именно — потом станет ясно), слепляем их через тире — имя готово. Далее, создаем директорию с таким именем и заходим в нее (на самом деле, конечно, лучше отделить создание файлов от вычислений); рекурсивно вызываем алгоритм, передав ему первую пачку строк в качестве всего множества.
Затем выполняем то же самое со второй пачкой — строки с номерами от N/q до 2N/q-1. И т.д. до последней пачки.
Теперь о том, сколько первых букв имени выбирать. Главное — чтобы префикс данной длины различался у последней строки данной пачки и первой строки следующей. Можно также дополнительно потребовать, чтобы на всём уровне все такие длины были одинаковыми — так будет красивее.
Что-то не соображу, как лучше файл передать. (Он был в сборке «Русская классика» с диска, прилагаемого к устройству; его md5sum: 0f3730e48d5db8bd5163c2bb94f21906 Lohvitskaya_Oborotni.55375.fb2 .)
Про гитхаб: операция помещения туда почти ничего не стоит (если, разумеется, человек вообще владеет git'ом). А польза от «как описание и пример реализации идеи» уже стоит того.
Кстати, как насчет того, чтобы выложить, например, в гитхаб?
2. С использованием cp1251 во внутренней кухне я вижу только одну проблему: некоторые алфавиты (арабский, иврит, может быть даже украинский) в нее не умещаются, поэтому либо сломается внутренний вызов конвертера, либо на выходе будут неадекватные символы.
3. Я примерно так и сделал — поковырялся в get_splitten_dirs(), чтобы убрать трехбукрвенные директории. Естественно, построение префиксного дерева требует более серьезного рефакторинга.
4. Попозже (в нерабочее время) я повторю процедуру, чтобы найти конкретно проблемные файлы (а то я их уже потер). Сейчас могу сказать, что проблемы возникли с той библиотекой, что была на устройстве (или на прилагаемом диске) при покупке. Возможно, я что-то переносил, но скорее всего изначально были директории library/{Зарубежная Классика, Русская Классика}, и в обеих были плохие файлы.
Объяснение, что это из-за регвыров — вполне логичное.
Про образ раздела сделаю.
Исходники были не последние, а, скорее всего, первые.
PS. Нет, я не слоупок. Просто был readonly и не мог оставлять нормальные комментарии.