Чего-то не понятно. Шума много, это да. У всех паника.
Но, например, первые две ссылки в статье — просто новости(одна в пересказе старшОго из Shipito), не несущие конкретного смысла и не имеющие юридической силы, третья ссылка уже более похожа на регулирующий документ, это которая про «подкрепив новость апдейтом документа о пересылке литиевых аккумуляторов на официальном сайте». Я там не вижу тотального запрета. Ограничения есть, местами серьезные, это да. Типа столько-то грамм лития на батарейку и на ячейку для неперезаряжаемых батарей, либо ограничения по Ватт-часам емкости батарей и ячеек для аккумуляторов.
Так же вижу требования к упаковке, исключающие короткое замыкание и разваливание посылки при обычном почтовом с ними обращении. Для девайсов со встроенной батареей упаковка должна исключать возможность самопроизвольного включения девайса при перевозке и тряске.
Ну и напоследок требование отправления с литием и литий-ионом маркировать специальными наклейками.
Но тотального запрета что-то не видно. Всякие айпады-айфоны-самсунги и прочие брендовые гаджеты в заводской упаковке априори этим требованиям соответствуют.
Я вот не пойму, то ли никто не читал сам текст документа, и поэтому все паникуют, то ли существует еще какой-то регулирующий документ, который не приведен в данной статье, и соответственно про который я не знаю?
Да. Так же там есть упоминание, что батареи должны соответствовать вот этому документу, раздел 38.3, начинается со страницы 394.
Это дает нам проблему с устройствами и батареями не крупных брендов. У крупных брендов, мне кажется, должно все соответствовать и эти соответствия, наверное, должны быть задокументированы где-то.
К сожалению, тут я не в курсе, как у американцев обстоят дела с бюрократией в этих областях. Если так же, как у нас с требованиями нотификации видов товаров, ограниченных к провозу на территорию Таможенного Союза, то тогда, конечно, все печально.
В общем, вопрос у меня такой: кто-нибудь может привести еще какие-либо документы, подтверждающие серьезные запреты на такие пересылки либо серьезные бюрократические проблемы с оформлением таких посылок со стороны Штатов?
А то видно только следствие: тотальную панику. Причину же кто-то где-то явно тщательно прячет.
P.S. Я не говорю о том, что «ребята, все нормально, не кипишуйте». Я не знаю ситуации. Просто прошу указать, где на самом деле этот запрет в явном виде находится?
Эмм… А вы не могли бы прояснить некоторые моменты?
Я не знаком с гитхабом, только приблизительно понимаю, что это. Не работаю я просто в комманде над некими шаровыми исходниками. Когда-то немного работал с какой-то древней системой контроля версий, на том мои познания и заканчиваются. В моей основной деятельности это просто не нужно.
И так, вопросы:
Какой смысл туда выкладывать этот проект? В целом? Ну в смысле… Не знаю как сказать… Для чего я это делаю и на что мне ориентироваться?
Я вот зарегистрировался, вылил вроде проект в репозиторий. Сгенерил RSA ключ с паролем, как подсказывал гайд на гитхабе. Надо было пароль? Или лучше перегенерить ключи без него?
Как я понял, гитхаб нужен для двух вещей:
1. чтобы пользователи данного скрипта могли неким унифицированным методом всегда получить свежайшие исходники, так же как получают их с других проектов на том же гитхабе.
2. давать нужным проверенным/заинтересованным людям права тоже что-то там править и дописывать.
Верно?
Тогда как лучше отконфигурить репозиторий?
Какие важные моменты нужно мне учесть, типа необходимости генерации этих SSH-паролей?
Спасибо.
Так а кто говорил о чем-то еще? Там же линукс внутри девайса. Там кроме этой либы, своей оболочки из пары программ и портов общеизвестных прог, типа fbreader, ничего особенного и нет.
Вы можете в директории /mnt/ext1/applications (/applications в флеш-памяти девайса) создавать файлы с расширением .app и содержанием типа:
#!/bin/sh
ls -laR / >/mnt/ext2/ls.txt
или
#!/bin/sh
ps ax >/mnt/ext2/ps.txt
и получить на флешке листинг файловой системы или список процессов.
или еще интереснее:
Но я не силен в этом, не знаю, как иначе исключить копирование на флешку собственно /mnt/ext1 и /mnt/ext2, кроме как первым способом.
Я таким образом пошел в магазин, взял девайс посмотреть, вставил свою флеху, запустил с нее же скрипт и слил на нее же все что было в девайсе — нужны были файлы от заводской прошивки, которую у себя я уже давно обновил, а она не публикуется для простого отката на своем же девайсе. Пришлось с магазинного экземпляра сливать. Правда оно мне не помогло в итоге, но это не важно ))
Как запускать скрипты не из папки «Приложения»(/applications)если в «Библиотеке» их не показывает, описано в моем посте в первом UPD.
С СДК еще надо сначала поковыряться и разобраться с рендером на экран, потом уж логику писать.
А так с ним не сложно, главное начальный объем азов вкурить. Ну и время конечно на это выделить )
Ассоциативные массивы-то встроены, ака хеши в перле.
Меня именно этот момент и смущает. Я ж весь функционал БД из скриптов своих убрал и выпустил для хабра такую standalone лайт-версию, работающую сходу и без всяких тяжелых обвесов.
А тут вы предлагаете… В общем, раскидывание по ренж-директориям оно-то конечно хорошо, но степень полезности меня смущает.
В моем понимании электрокнижка у любого юзера используется преимущественно 99% времени для непосредственно чтения, и хорошо если 1% времени для поиска книг. Это я про работу с локальной библиотекой, исключая мучения во встроенном браузере и игры во всякие шахматы.
Поэтому кмк текущего поиска вполне достаточно, и он довольно несложен. Лишние пару нажатий погоды не составят.
Кроме того, скриптик этот расчитан в перую очередь для огромных объемов книг, а не простеньких коллекций в пару сотен максимум. А там уже двойной проход и создание массива — это и время, и память.
Более интересным был бы алгоритм разброса и поиска по названиям книг. При чем алгоритм, не требующий предварительного получения этого списка.
Еще как вариант для новых покетбуков(новых прошивок) можно во время работы скрипта создавать и заполнять базу данных explorer.db(SQLite3), которую как раз для индексации и поиска использует новая книжная полка в новых прошивках. Соответсвенно в настройках самого устройства обновления индекса запретить.
И еще не забывайте в свой алгоритм такой момент, как анализ, сколько книжек в каком диапазоне будет. Вполне возможно, что будет диапазон ААА-БББ с парой тысяч, а диапазон ЕЕЕ-ННН — вообще пустой.
И как бы так не получилось, что с вашими "(макс количество элементов в каждой директории)" выйдет хвост из нескольких файлов, выплюнутых в соседний почти пустой диапазон, но при этом подходящих по условию к предыдущему диапазону. В общем, там столько нюансов полезет с этими диапазонами…
Поэтому если уж и делать двухпроходность, то двумя этапами: первый проход — укладываем реквизиты книжек в БД, второй проход — формируем библиотеку для устройства. В БД можно накрутить любые сортировки и вычисления.
То есть вернемся к тому, что у меня и было до создания статьи на хабр. А там уж и до своей системы каталогизированного хранения недалеко. А зачем нам еще одна программа типа Calibre или MyHomelib, да еще и без GUI? )))
>> Берем всё множество строк (авторов), сортируем.
Дык я вам о чем говорю: где ж его взять-то, это множество, при старте скрипта? Он же понятия не имеет каких у нас и сколько авторов!
Была бы БД уже заполненная — тогда без проблем. Или двойной проход скрипта нужен.
А так у меня скрипт раскладывает каждую книжку сходу сразу как распарсил — он не знает, что там в библиотеке есть еще. Даже предудущие обработанные книги не помнит, кроме порядкового номера )))
Исправлено. Мой пост обновлен(UPD4) и исходники тоже. habrahabr.ru/post/143492/
Перекачивать крайне желательно всем заинтересованным:
Была банальная ошибка копипаста, приводившая к бесконечному циклу при кривом указании жанра.
Извините, мой грубый косяк.
Скачал. У меня отрабатывает этот файл за 10 миллисекунд.
Важных ошибок нет.
Находит и правит только одну текстовую ошибку в этом абзаце(в его конце):
<p>Одна из наших дам раздобыла ее адрес и проездом через тот городок, где жила баронесса, разыскала ее местожительство, но дома не застала. Квартирная хозяйка баронессы отозвалась о ней с большим уважением. - Herr Onegin, - сказала она, - ist ein braver mann. <Господин Онегин... - превосходный человек (нем.). > </p>
Так что скорее всего проблемы растут из-за кодировок и как следствие, спотыканий парсера.
Попробуйте в файле test.php в его начале указать эту книжку и прогнать именно test.php.
Указывать вот так(найдете в файле эти строки и поймете что куда):
4. Прогнал стандартную поставку Покета 912. Отработало на виртуалке за время меньше минуты обоими способами: xmlp_data2struct_old() и xmlp_data2struct(). В первом случае в пике памяти кушал чуть более 70Мб, обычно около 50-55, во втором случае максимум около 45Мб, обычно 38-40.
Не лег в результирующие директории только «Евгений Онегин» Пушкина, да и то, только потому, что автор не был прописан в метатегах книги — только в начале самого текста поэмы(или романа в стихах, если правильнее).
Вот кстати еще одна пометка, что стоит добавить в настройки и алгоритм — что делать с файлами с кривыми метатегами, не подходящими под условия каталогизатора.
А так еще в некоторые файлы добавилось в результате несколько байт — видимо мелкие огрехи поисправляло, типа что-то(может быть даже что-то не обязательное) в HTML-коды перевело.
В общем, ошибок в лог не написало никаких, поэтому делаем вывод, что левых тегов и косяков XML-структуры не встречалось.
Может скинете мне свой набор тестовой поставки?
Там вообще только FB2 или есть epub например?
>> Глобальный вопрос в том, чтобы минимизировать полное время поиска нужного файла.
Не думаю, что это является «бутылочным горлышком». Иными словами, минимизировать конечно это хорошо, но не до фанатизма.
Я не знаю, где у вас на устройстве кнопка PgDn, у меня просто вправо-влево джойстиком гуляние по страницам. И не факт, что переместиться куда нужно можно по одной странице быстрее, чем по, скажем, трем. Можно жмакать кнопку вверх, чтобы перейти сразу вниз страницы и двигаться по списку вверх, это да, но иногда например всего одно нажатие вправо переместит вас на следующую страницу и возможно в ее начале сразу будет требуемый вам пункт.
В общем, так или иначе, если страниц приемлемое количество(3-5-7), то доп.навигация по ним не является такой уж проблемой.
Просто не забывайте, что предназначение читалки в первую очередь в чтении, а уже во вторую — в навигации. Оптимизация не всегда должна быть реализована по максимуму, скорее в копромиссах с функциональностью и универсальностью.
>> Объяснение, что это из-за регвыров — вполне логичное.
Да не очень оно и логичное. У меня регвыражения используются, чтобы отделить теги от текста между ними. То есть не так, как все обычно пытаются регвыражениями вообще все распарсить сходу. Дальше обработка в цикле последовательным перемещением по тегам, сколько текста между ними — вообще не важно.
Однако в последних версиях PHP, как я слышал, сделан большой упор в сторону передачи параметров ссылками(references), вот это может вполне сказаться на жадности к памяти. Есть атомарные функции типа strlen или substr, которые при передаче в них PHP-шного референса пытаются автоматически превратить его в независимую переменную(понятия не имею зачем), для чего им приходится создавать копию этой переменной в памяти. Из-за этого эти функции тупят и нажирают стек, особенно в больших циклах.
Вы можете самостоятельно в этом убедиться, попытавшись замерить производительность двух, на первый взгляд идентичных, циклов:
Второй цикл идентичен первому, но получает на вход референс, из-за этого работает на порядки дольше.
Хотя, опять же, я свежайший PHP нигде не ставил, возможно у него как раз с этим все в порядке, но на производительность могут влиять как раз некоторые мои трюки, разработанные именно для более старых версий PHP.
В общем, так или иначе, с референсами в PHP нужно быть очень аккуратным, ибо это совсем не одно и то же, что pointers в Си.
P.S. и так же все-таки попробуйте мой совет выше сменить главную функцию парсинга с xmlp_data2struct_old() на xmlp_data2struct(). Эта функция хоть и работает чуть дольше xmlp_data2struct_old(), но не использует strlen или substr внутри себя.
А так же можно попробовать отрубить в настройках параметр 'include_comments'. В таком случае xmlp_data2struct() будет работать даже быстрее, чем xmlp_data2struct_old(), хоть и html-комментарии превратит в html-коды.
2. Не очень понял вторую часть абзаца. Если вы о интерфейсе покета, то перейти на следующую страницу списка не проблема, проблема в том, чтобы файлов/поддиректорий в одной директории было условно не более сотни. Тогда и книжка тупить не будет долго, считывая содержимое папки, и навигация по небольшому количеству страниц списка будет приемлемой.
С гитхабом даже не думал, если чесно. Я не вижу такой выскокой «стоимости» данного скрипта, чтобы превращать его в какой-то развивающийся проект. Скорее как описание и пример реализации идеи для тех ребят, которые пишут десктопные программы-каталогизаторы, либо как доп.помощник для людей, имеющих покетбуки или совместимые с «брожением по файловой системе» аппараты.
2. Ага, могло быть такое с совсем «не нашими» языками. Я расчитывал только под англицкий и русский, потому не делал поддержки остальных. Впрочем, всякие французско-немецкие с умляутами тоже по идее должны нормально мапиться в 1251 кодировку. И украинские тоже должны нормально обрабатываться.
3. у get_splitten_dirs() в текущей реализации есть два параметра: $lcnt и $both_fld. Это второй и четвертый параметры по счету соответственно.
если установить $lcnt(количество букв) в 0, и $both_fld(оба уровня) в false(или не передавать), то в директориях типа 'Буквы А-Я/' будет сразу список авторов-жанров-серий, без промежуточных одно- и многобуквенных поддиректорий.
если $lcnt=1 и $both_fld=false, то только однобуквенный уровень.
если $lcnt>1 и $both_fld=false, то один уровень с количеством букв $lcnt.
если $lcnt>1 и $both_fld=true, то уровень с первой буквой плюс уровень с количеством букв $lcnt.
4. Будет время, погоняю на стандартной поставке, посмотрю что там к чему.
Еще может отличаться работа с регулярками под виндой и линуксом. Раньше я встречал разницу в обработке тех же точкозаменителей .*?, при чем не особо зависимо от параметров самой регулярки. Хотя во-первых давно должны были привести в порядок эти различия, во-вторых не помню, вроде это только в древнем перле под разные системы были такие различия, да и то, по сравнению обычного перла с ActivePerl под винду, и в-третьих у себя я не использовал эти спорные штуки(точку).
Еще в догонку.
Я пожалуй в ближайшие пару дней допилю скрипт, учитывая ваши замечания.
По крайней мере частично.
1. переведу все комментарии в коде на англицкий, чтобы не нужно было перекодировать.
2. допилю процедуру get_splitten_dirs(), добавлю в нее гибкую генерацию регионов типа «Аве-Арц» и выведу все ее настройки в начало скрипта.
3. добавлю опцию на предмет «выливать в UTF-8» для генерации конечных путей под линуксом.
Не уверен, что буду переводить «genres.inc» и всю внутреннюю работу сразу на UTF-8. Тут я универсального решения для работы с кодом не вижу пока. Если подскажете, буду рад. Хотя, справедливости ради, это мои личные заморочки — я привык к своему редактору для исходников, а он не поддерживает UTF-8. Наверное пора задуматься о смене редактора )))
Ну, многие вопросы могли бы и там в комментариях спросить. Но можно и здесь.
Что знаю, расскажу по-порядку.
1. Да, я знаю, что имена с точки не показываются в Покете. Была мысль сделать то же самое, но не хотелось экспериментировать с возможными вылезающими багами. Ну и, в конце концов, настройка на то и настройка, что каждый может поменять, как ему удобнее. В любом случае спасибо. Если вы подтверждаете, что это не приносит проблем, то с точки начинать имя хранилища наверное самое оно.
2. Именно поэтому я в статье и упомянул о том, что скрипт делался под винду. В моем случае предполагается, что файлы пишутся на флешку или промежуточную директорию на винте именно из-под винды, на устройстве в результате русские имена файлов/каталогов преобразуются в юникод. Так же в скрипте внутри есть рекодинг с помощью iconv(), можно поубирать либо добавить где надо автоматическое преобразование. Но есть такой момент — все приводится внутри к 1251.
3. В моей статье я указал про параметры вызова get_splitten_dirs() в основном скрипте. Именно ними можно регулировать создание доп.уровней типа «три первых буквы» и таким образом рулить глубиной вложенности. Т.к. выложенный скрипт работает без промежуточной БД, затруднительно определить заранее количество книг в том или ином разделе, и соответственно автоматом рассчитать требуемую глубину вложенности каталогов. Тут уж извините )
4. Вы можете мне в личку скинуть примеры таких файлов? Последние правки парсера были связаны с добавлением обработки html-комментариев, и полного тестирования механизма после этих правок не было. Возможно глюки связаны именно с этим. Если сбросите, я их погоняю, поправлю парсер. Еще в основном скрипте «process.php» можете попробовать заменить вызов xmlp_data2struct_old() на xmlp_data2struct(). Это два варианта парсинга. Отличаются механизмом работы с регулярками.
Кстати, в настройках массив 'tags_processing' рулит генерацией регулярок для парсера, возможно есть смысл сменить настройку 'pattern_type' на XMLP_TPS_SAFE. В таком случае будет принудительно ограничена жадность(greedy) регулярки и соседними параметрами будет четко ограничена длина имени тега и аттрибутов. то есть вместо конструкций вида [^\s\<\>]*? будут работать конструкции вида [^\s\<\>]{0,1024}, и таким образом будет работать что-то типа защиты от переполнения буффера. В вебе, кстати, лучше всегда так писать регулярки.
5. Да, флешка монтируется на /mnt/ext2, а внутренняя память на /mnt/ext1. Могли и там в комментах спросить, я бы ответил ) Я просто посчитал, что если в той статье слишком развернуто описывать работу Покета, включая описание подобных мелочей, статья будет километровая, многие не осилят. Она и так длинновата получилась )
6. Зиповка файлов предназначена именно для выкачки например всей флибусты. Текущая флибуста уже на две флешки по 32Гб минимум влезет, и это в зипах, да и то не факт, так что зипование важнее времени открытия. Но чесгря я не замечаю особой задержки между открытием fb2 файла и открытием его же в зипе. Чтение зипов обычно не особо ресурсоемкая процедура, по крайней мере по сравнению с упаковкой. В любом случае, настройка для того и вынесена — кто как хочет, так и делает )
Кстати, если проверите работу с образом диска, может в этот пост добавите потом мануал? Это очень полезно будет по моему мнению.
P.S. У вас последние мои исходники? Там в статье было пара обновлений, в конце статьи читайте разделы UPD и UPD2.
Но, например, первые две ссылки в статье — просто новости(одна в пересказе старшОго из Shipito), не несущие конкретного смысла и не имеющие юридической силы, третья ссылка уже более похожа на регулирующий документ, это которая про «подкрепив новость апдейтом документа о пересылке литиевых аккумуляторов на официальном сайте». Я там не вижу тотального запрета. Ограничения есть, местами серьезные, это да. Типа столько-то грамм лития на батарейку и на ячейку для неперезаряжаемых батарей, либо ограничения по Ватт-часам емкости батарей и ячеек для аккумуляторов.
Так же вижу требования к упаковке, исключающие короткое замыкание и разваливание посылки при обычном почтовом с ними обращении. Для девайсов со встроенной батареей упаковка должна исключать возможность самопроизвольного включения девайса при перевозке и тряске.
Ну и напоследок требование отправления с литием и литий-ионом маркировать специальными наклейками.
Но тотального запрета что-то не видно. Всякие айпады-айфоны-самсунги и прочие брендовые гаджеты в заводской упаковке априори этим требованиям соответствуют.
Я вот не пойму, то ли никто не читал сам текст документа, и поэтому все паникуют, то ли существует еще какой-то регулирующий документ, который не приведен в данной статье, и соответственно про который я не знаю?
Да. Так же там есть упоминание, что батареи должны соответствовать вот этому документу, раздел 38.3, начинается со страницы 394.
Это дает нам проблему с устройствами и батареями не крупных брендов. У крупных брендов, мне кажется, должно все соответствовать и эти соответствия, наверное, должны быть задокументированы где-то.
К сожалению, тут я не в курсе, как у американцев обстоят дела с бюрократией в этих областях. Если так же, как у нас с требованиями нотификации видов товаров, ограниченных к провозу на территорию Таможенного Союза, то тогда, конечно, все печально.
В общем, вопрос у меня такой: кто-нибудь может привести еще какие-либо документы, подтверждающие серьезные запреты на такие пересылки либо серьезные бюрократические проблемы с оформлением таких посылок со стороны Штатов?
А то видно только следствие: тотальную панику. Причину же кто-то где-то явно тщательно прячет.
P.S. Я не говорю о том, что «ребята, все нормально, не кипишуйте». Я не знаю ситуации. Просто прошу указать, где на самом деле этот запрет в явном виде находится?
Я не знаком с гитхабом, только приблизительно понимаю, что это. Не работаю я просто в комманде над некими шаровыми исходниками. Когда-то немного работал с какой-то древней системой контроля версий, на том мои познания и заканчиваются. В моей основной деятельности это просто не нужно.
И так, вопросы:
Какой смысл туда выкладывать этот проект? В целом? Ну в смысле… Не знаю как сказать… Для чего я это делаю и на что мне ориентироваться?
Я вот зарегистрировался, вылил вроде проект в репозиторий. Сгенерил RSA ключ с паролем, как подсказывал гайд на гитхабе. Надо было пароль? Или лучше перегенерить ключи без него?
Как я понял, гитхаб нужен для двух вещей:
1. чтобы пользователи данного скрипта могли неким унифицированным методом всегда получить свежайшие исходники, так же как получают их с других проектов на том же гитхабе.
2. давать нужным проверенным/заинтересованным людям права тоже что-то там править и дописывать.
Верно?
Тогда как лучше отконфигурить репозиторий?
Какие важные моменты нужно мне учесть, типа необходимости генерации этих SSH-паролей?
Спасибо.
Вы можете в директории /mnt/ext1/applications (/applications в флеш-памяти девайса) создавать файлы с расширением .app и содержанием типа:
или
и получить на флешке листинг файловой системы или список процессов.
или еще интереснее:
и вытащить все содержимое на флешку.
По идее достаточно и:
Но я не силен в этом, не знаю, как иначе исключить копирование на флешку собственно /mnt/ext1 и /mnt/ext2, кроме как первым способом.
Я таким образом пошел в магазин, взял девайс посмотреть, вставил свою флеху, запустил с нее же скрипт и слил на нее же все что было в девайсе — нужны были файлы от заводской прошивки, которую у себя я уже давно обновил, а она не публикуется для простого отката на своем же девайсе. Пришлось с магазинного экземпляра сливать. Правда оно мне не помогло в итоге, но это не важно ))
Как запускать скрипты не из папки «Приложения»(/applications)если в «Библиотеке» их не показывает, описано в моем посте в первом UPD.
А так с ним не сложно, главное начальный объем азов вкурить. Ну и время конечно на это выделить )
Меня именно этот момент и смущает. Я ж весь функционал БД из скриптов своих убрал и выпустил для хабра такую standalone лайт-версию, работающую сходу и без всяких тяжелых обвесов.
А тут вы предлагаете… В общем, раскидывание по ренж-директориям оно-то конечно хорошо, но степень полезности меня смущает.
В моем понимании электрокнижка у любого юзера используется преимущественно 99% времени для непосредственно чтения, и хорошо если 1% времени для поиска книг. Это я про работу с локальной библиотекой, исключая мучения во встроенном браузере и игры во всякие шахматы.
Поэтому кмк текущего поиска вполне достаточно, и он довольно несложен. Лишние пару нажатий погоды не составят.
Кроме того, скриптик этот расчитан в перую очередь для огромных объемов книг, а не простеньких коллекций в пару сотен максимум. А там уже двойной проход и создание массива — это и время, и память.
Более интересным был бы алгоритм разброса и поиска по названиям книг. При чем алгоритм, не требующий предварительного получения этого списка.
Еще как вариант для новых покетбуков(новых прошивок) можно во время работы скрипта создавать и заполнять базу данных explorer.db(SQLite3), которую как раз для индексации и поиска использует новая книжная полка в новых прошивках. Соответсвенно в настройках самого устройства обновления индекса запретить.
И еще не забывайте в свой алгоритм такой момент, как анализ, сколько книжек в каком диапазоне будет. Вполне возможно, что будет диапазон ААА-БББ с парой тысяч, а диапазон ЕЕЕ-ННН — вообще пустой.
И как бы так не получилось, что с вашими "(макс количество элементов в каждой директории)" выйдет хвост из нескольких файлов, выплюнутых в соседний почти пустой диапазон, но при этом подходящих по условию к предыдущему диапазону. В общем, там столько нюансов полезет с этими диапазонами…
Поэтому если уж и делать двухпроходность, то двумя этапами: первый проход — укладываем реквизиты книжек в БД, второй проход — формируем библиотеку для устройства. В БД можно накрутить любые сортировки и вычисления.
То есть вернемся к тому, что у меня и было до создания статьи на хабр. А там уж и до своей системы каталогизированного хранения недалеко. А зачем нам еще одна программа типа Calibre или MyHomelib, да еще и без GUI? )))
Дык я вам о чем говорю: где ж его взять-то, это множество, при старте скрипта? Он же понятия не имеет каких у нас и сколько авторов!
Была бы БД уже заполненная — тогда без проблем. Или двойной проход скрипта нужен.
А так у меня скрипт раскладывает каждую книжку сходу сразу как распарсил — он не знает, что там в библиотеке есть еще. Даже предудущие обработанные книги не помнит, кроме порядкового номера )))
habrahabr.ru/post/143492/
Перекачивать крайне желательно всем заинтересованным:
Была банальная ошибка копипаста, приводившая к бесконечному циклу при кривом указании жанра.
Извините, мой грубый косяк.
Важных ошибок нет.
Находит и правит только одну текстовую ошибку в этом абзаце(в его конце):
Так что скорее всего проблемы растут из-за кодировок и как следствие, спотыканий парсера.
Попробуйте в файле test.php в его начале указать эту книжку и прогнать именно test.php.
Указывать вот так(найдете в файле эти строки и поймете что куда):
Он сгенерирует 6 файлов вида «out_xxxxxxx.txt»
и один файл «test_errors.txt»
Зазипуйте и мне перешлите так же через личку. Посмотрю что там не так.
Не лег в результирующие директории только «Евгений Онегин» Пушкина, да и то, только потому, что автор не был прописан в метатегах книги — только в начале самого текста поэмы(или романа в стихах, если правильнее).
Вот кстати еще одна пометка, что стоит добавить в настройки и алгоритм — что делать с файлами с кривыми метатегами, не подходящими под условия каталогизатора.
А так еще в некоторые файлы добавилось в результате несколько байт — видимо мелкие огрехи поисправляло, типа что-то(может быть даже что-то не обязательное) в HTML-коды перевело.
В общем, ошибок в лог не написало никаких, поэтому делаем вывод, что левых тегов и косяков XML-структуры не встречалось.
Может скинете мне свой набор тестовой поставки?
Там вообще только FB2 или есть epub например?
В т.ч. и мне, когда все это дело на мак перенесу.
Не думаю, что это является «бутылочным горлышком». Иными словами, минимизировать конечно это хорошо, но не до фанатизма.
Я не знаю, где у вас на устройстве кнопка PgDn, у меня просто вправо-влево джойстиком гуляние по страницам. И не факт, что переместиться куда нужно можно по одной странице быстрее, чем по, скажем, трем. Можно жмакать кнопку вверх, чтобы перейти сразу вниз страницы и двигаться по списку вверх, это да, но иногда например всего одно нажатие вправо переместит вас на следующую страницу и возможно в ее начале сразу будет требуемый вам пункт.
В общем, так или иначе, если страниц приемлемое количество(3-5-7), то доп.навигация по ним не является такой уж проблемой.
Просто не забывайте, что предназначение читалки в первую очередь в чтении, а уже во вторую — в навигации. Оптимизация не всегда должна быть реализована по максимуму, скорее в копромиссах с функциональностью и универсальностью.
Про гитхаб еще подумаю.
Да не очень оно и логичное. У меня регвыражения используются, чтобы отделить теги от текста между ними. То есть не так, как все обычно пытаются регвыражениями вообще все распарсить сходу. Дальше обработка в цикле последовательным перемещением по тегам, сколько текста между ними — вообще не важно.
Однако в последних версиях PHP, как я слышал, сделан большой упор в сторону передачи параметров ссылками(references), вот это может вполне сказаться на жадности к памяти. Есть атомарные функции типа strlen или substr, которые при передаче в них PHP-шного референса пытаются автоматически превратить его в независимую переменную(понятия не имею зачем), для чего им приходится создавать копию этой переменной в памяти. Из-за этого эти функции тупят и нажирают стек, особенно в больших циклах.
Вы можете самостоятельно в этом убедиться, попытавшись замерить производительность двух, на первый взгляд идентичных, циклов:
Второй цикл идентичен первому, но получает на вход референс, из-за этого работает на порядки дольше.
Хотя, опять же, я свежайший PHP нигде не ставил, возможно у него как раз с этим все в порядке, но на производительность могут влиять как раз некоторые мои трюки, разработанные именно для более старых версий PHP.
В общем, так или иначе, с референсами в PHP нужно быть очень аккуратным, ибо это совсем не одно и то же, что pointers в Си.
P.S. и так же все-таки попробуйте мой совет выше сменить главную функцию парсинга с xmlp_data2struct_old() на xmlp_data2struct(). Эта функция хоть и работает чуть дольше xmlp_data2struct_old(), но не использует strlen или substr внутри себя.
А так же можно попробовать отрубить в настройках параметр 'include_comments'. В таком случае xmlp_data2struct() будет работать даже быстрее, чем xmlp_data2struct_old(), хоть и html-комментарии превратит в html-коды.
С гитхабом даже не думал, если чесно. Я не вижу такой выскокой «стоимости» данного скрипта, чтобы превращать его в какой-то развивающийся проект. Скорее как описание и пример реализации идеи для тех ребят, которые пишут десктопные программы-каталогизаторы, либо как доп.помощник для людей, имеющих покетбуки или совместимые с «брожением по файловой системе» аппараты.
3. у get_splitten_dirs() в текущей реализации есть два параметра: $lcnt и $both_fld. Это второй и четвертый параметры по счету соответственно.
если установить $lcnt(количество букв) в 0, и $both_fld(оба уровня) в false(или не передавать), то в директориях типа 'Буквы А-Я/' будет сразу список авторов-жанров-серий, без промежуточных одно- и многобуквенных поддиректорий.
если $lcnt=1 и $both_fld=false, то только однобуквенный уровень.
если $lcnt>1 и $both_fld=false, то один уровень с количеством букв $lcnt.
если $lcnt>1 и $both_fld=true, то уровень с первой буквой плюс уровень с количеством букв $lcnt.
4. Будет время, погоняю на стандартной поставке, посмотрю что там к чему.
Еще может отличаться работа с регулярками под виндой и линуксом. Раньше я встречал разницу в обработке тех же точкозаменителей .*?, при чем не особо зависимо от параметров самой регулярки. Хотя во-первых давно должны были привести в порядок эти различия, во-вторых не помню, вроде это только в древнем перле под разные системы были такие различия, да и то, по сравнению обычного перла с ActivePerl под винду, и в-третьих у себя я не использовал эти спорные штуки(точку).
Я пожалуй в ближайшие пару дней допилю скрипт, учитывая ваши замечания.
По крайней мере частично.
1. переведу все комментарии в коде на англицкий, чтобы не нужно было перекодировать.
2. допилю процедуру get_splitten_dirs(), добавлю в нее гибкую генерацию регионов типа «Аве-Арц» и выведу все ее настройки в начало скрипта.
3. добавлю опцию на предмет «выливать в UTF-8» для генерации конечных путей под линуксом.
Не уверен, что буду переводить «genres.inc» и всю внутреннюю работу сразу на UTF-8. Тут я универсального решения для работы с кодом не вижу пока. Если подскажете, буду рад. Хотя, справедливости ради, это мои личные заморочки — я привык к своему редактору для исходников, а он не поддерживает UTF-8. Наверное пора задуматься о смене редактора )))
Что знаю, расскажу по-порядку.
1. Да, я знаю, что имена с точки не показываются в Покете. Была мысль сделать то же самое, но не хотелось экспериментировать с возможными вылезающими багами. Ну и, в конце концов, настройка на то и настройка, что каждый может поменять, как ему удобнее. В любом случае спасибо. Если вы подтверждаете, что это не приносит проблем, то с точки начинать имя хранилища наверное самое оно.
2. Именно поэтому я в статье и упомянул о том, что скрипт делался под винду. В моем случае предполагается, что файлы пишутся на флешку или промежуточную директорию на винте именно из-под винды, на устройстве в результате русские имена файлов/каталогов преобразуются в юникод. Так же в скрипте внутри есть рекодинг с помощью iconv(), можно поубирать либо добавить где надо автоматическое преобразование. Но есть такой момент — все приводится внутри к 1251.
3. В моей статье я указал про параметры вызова get_splitten_dirs() в основном скрипте. Именно ними можно регулировать создание доп.уровней типа «три первых буквы» и таким образом рулить глубиной вложенности. Т.к. выложенный скрипт работает без промежуточной БД, затруднительно определить заранее количество книг в том или ином разделе, и соответственно автоматом рассчитать требуемую глубину вложенности каталогов. Тут уж извините )
4. Вы можете мне в личку скинуть примеры таких файлов? Последние правки парсера были связаны с добавлением обработки html-комментариев, и полного тестирования механизма после этих правок не было. Возможно глюки связаны именно с этим. Если сбросите, я их погоняю, поправлю парсер. Еще в основном скрипте «process.php» можете попробовать заменить вызов xmlp_data2struct_old() на xmlp_data2struct(). Это два варианта парсинга. Отличаются механизмом работы с регулярками.
Кстати, в настройках массив 'tags_processing' рулит генерацией регулярок для парсера, возможно есть смысл сменить настройку 'pattern_type' на XMLP_TPS_SAFE. В таком случае будет принудительно ограничена жадность(greedy) регулярки и соседними параметрами будет четко ограничена длина имени тега и аттрибутов. то есть вместо конструкций вида [^\s\<\>]*? будут работать конструкции вида [^\s\<\>]{0,1024}, и таким образом будет работать что-то типа защиты от переполнения буффера. В вебе, кстати, лучше всегда так писать регулярки.
5. Да, флешка монтируется на /mnt/ext2, а внутренняя память на /mnt/ext1. Могли и там в комментах спросить, я бы ответил ) Я просто посчитал, что если в той статье слишком развернуто описывать работу Покета, включая описание подобных мелочей, статья будет километровая, многие не осилят. Она и так длинновата получилась )
6. Зиповка файлов предназначена именно для выкачки например всей флибусты. Текущая флибуста уже на две флешки по 32Гб минимум влезет, и это в зипах, да и то не факт, так что зипование важнее времени открытия. Но чесгря я не замечаю особой задержки между открытием fb2 файла и открытием его же в зипе. Чтение зипов обычно не особо ресурсоемкая процедура, по крайней мере по сравнению с упаковкой. В любом случае, настройка для того и вынесена — кто как хочет, так и делает )
Кстати, если проверите работу с образом диска, может в этот пост добавите потом мануал? Это очень полезно будет по моему мнению.
P.S. У вас последние мои исходники? Там в статье было пара обновлений, в конце статьи читайте разделы UPD и UPD2.
В общем временный костыль для проблемы вроде нашли. Читайте в конце поста раздел UPD.