#58 Python port

[Anonymous]

Originally created by: LRN1...@gmail.com
Originally owned by: LRN1...@gmail.com

Собственно, альфа-версия доступна здесь - https://gitorious.org/lopyfb2tools
В аттаче - собранный экстэншн (на Gitorious - только сырцы, без полноценного Питона на данный момент не собираются, т.к. в Питоне из-под LO/OOo нет инструментов для локализации).

Ждать ответа от sloth'а ( с.м. обсуждение на http://code.google.com/p/ooofbtools/issues/detail?id=54 ) не стал, поставил LGPLv3.

[Anonymous]

Originally posted by: dik...@gmail.com

Молодец. Проверь только валидацию готового файла - выдается сообщение "необработанный эксепшн в валидаторе схемы..."  и т.д. - на валидном fb2-файле.

[Anonymous]

Originally posted by: LRN1...@gmail.com

Какой эксэпшн-то? Пиши подробно. Любой эксепшн помимо XsvalError (тысячи их!) считается "необработанным".
Ну, или документ дай, из которого делал fb2 (запускать валидатор на готовом fb2 вручную сейчас нельзя, значит ты валидировал fb2, созданный из odt).

Кстати, надо бы сделать набор тэстов. Я использовал example-1 и example-2, но вряд ли они покрывают весь спектр возможных ошибок в процессе конвертации. И использовал я везде настройки по дефолту (в частности - функции парсинга врезок НЕ как структур практически не проверены в работе).

[Anonymous]

Originally posted by: dik...@gmail.com

Конечно, не здесь надо обсуждать твой порт, но все же - напишу. Файл, который я конвертировал LOPyFB2Tools - очень маленький - Сноски.odt - я на нем отлаживаю экспорт с помощью OOoFBTools разных видов сносок. Прогони - сам увидишь эксепш.
Теперь о другом. Я прогнал твоим LOPyFB2Tools книгу на 264 стр. - без структуры (Уровни, стихи и т.д.) - просто текст и обложка. У LOPyFB2Tools анализ занял 3,5 мин. У OOoFBTool - 2 мин 32 сек. Но дальше стадии анализа LOPyFB2Tools не прошел - наглухо завис на этапе Создания файла - устал ждать, закрыл Редактор. В Диспетчере задач (на Винде) остался висеть uno.exe, который блокировал "заготовку" fb2-файла книги...
1. Проверь на большой книге у себя.
2. Не пойму, в чем преимущество проги на Питоне (LOPyFB2Tools ) по сравнению со StarBaisic`ом - оба - интерпретаторы, и скорость экспорта у OOoFBTools намного выше.

[Anonymous]

Originally posted by: dik...@gmail.com

Вот скрин ошибки валидации.
И еще - то, что я писал выше - когда прога зависла, пришлось сносить Writer. Потом, при новом запуске Writer`а LOPyFB2Tools ни как не реагирует, приходится LOPyFB2Tools удалять (с руганью Writer) и устанавливать заново... Может эта инфа поможет тебе в отладке.

[Anonymous]

Originally posted by: yegor.ch...@fbtools.org

А где лучше обсуждать? Создать отдельную группу?
К слову, шрифты под юникс и виндовс слегка отличаются. На моём компе с виндовс многие сообщения обрезаны и строчки наезжают одна на другую.

[Anonymous]

Originally posted by: dik...@gmail.com

Даже и не знаю, как лучше. Когда я писал тебе, что "не здесь надо обсуждать твой порт" - у меня в голове сидел твой вопрос лицензии, поэтому и подумал, что в ветке о лицензии порт лучше не обсуждать. Спутал.

[Anonymous]

Originally posted by: LRN1...@gmail.com

Сконвертировал Сноски.odt у себя - сконвертировался успешно, валидатор ошибок не выдал.
Какая у тебя версия OpenOffice/LibreOffice? Операционная система?
Попробуй вскрыть экстэншн, открыть pythonpath/LOPyFB2Tools.py и сделать enable_debugging = True, потом перепаковать и установить. При включённом дебаггинге будет при каждом запуске конвертера открываться окно с логом (знаю, кривота, но под виндой к stdout/stderr OpenOffice'а подсосаться не удаётся) - возможно там будут более подробные сообщения об ошибках. Если там тоже ничего особого не наблюдается, то я выложу версию с более подробными сообщениями об ошибках.

Если Writer зависает - это скорее всего проблема не валидации, а вообще экстэншна и Питона.
Вообще, меня немного настораживает сообщение о существовании uno.exe. Потому что у меня (LibreOffice 3.3.2) его не наблюдается, Питон работает прямо внутри soffice.bin, в отдельном треде.

Скорость работы выше на очень больших файлах. Есть у меня один файл в 2146 страниц, на нём анализ у LOPyFB2Tools идёт на порядок быстрее, чем у OOoFBTools. А на стадии создания файла OOoFBTools вообще падает.

Впрочем, я не утверждаю, что скорость работы на мелких файлах нельзя улучшить, оптимизацией я занимался по минимуму, есть надежда на улучшения.
Я вчерне попрофилировал его вчера, вот результаты для example-1:
Без таблиц и картинок - 0.5 секунды
С таблицами - 1.5 секунды
С таблицами и картинками - ~5 секунд
Но example-1 он вообще такой особый - с кучей таблиц и картинок, собственно текста там мало. Есть, чем заняться.

Кстати, у него ещё и память течёт. Я заметил это на первоначальном варианте About'а, который был с фоновой картинкой (нет, картинку я впоследствии убрал по другой причине) - там уносило чуть ли не по пол-мегабайта за раз. Тоже есть над чем подумать.

[Anonymous]

Originally posted by: LRN1...@gmail.com

Вот та же альфа-версия, только debugging включён. Печатает по-прежнему мало информации, но по крайней мере эксэпшны можно будет увидеть в подробностях.
Ещё прилагаю версию с включённым профайлингом. Профайлинг довольно примитивный, через декораторы, но на безрыбье и кастрюля - соловей.
В заключении - то же самое, но без дебаггинга и профайлинга.

Пробовал запускать под OOo 3.3.0 - работает исправно (но зато увидел тот uno.exe, о котором ты говорил; видимо запуск экстэншнов внутри soffice.bin - это либо особенность LO, либо новая фича, которой в 3.3.0 пока нет).

Скинь мне на почту файл, на котором у тебя вешался конвертер.

И вот ещё что, я сделал грубый (+- 500ms) замер времени между нажатием на OK и появлением диалога с результатом конверсии example-1 с помощью -plain версии - для OOo 3.3 и для LO 3.3.2. Вот результаты:
OOo 3.3 - 11216.000080108643ms
LO 3.3.2 - 5542.999982833862ms
Собственно, 5500 для LO - это те самые ~5 секунд, о которых я говорил в предыдущем посте.

[Anonymous]

Originally posted by: dik...@gmail.com

Ты молодец. Когда доведешь до ума прогу - хорошая вешь будет...

[Anonymous]

Originally posted by: dik...@gmail.com

Файл скину завтра на работе.

[Anonymous]

Originally posted by: dik...@gmail.com

У меня стоит OOo3.3.1. На LO не пробовал - может твой порт там работает быстрее, чем на Ooo

[Anonymous]

Originally posted by: dik...@gmail.com

Да, если не трудно - скинь мне на почту тот большой файл, на котором OOoFBTools падал при создании fb2 - хочу погонять под отладчиком.

[Anonymous]

Originally posted by: LRN1...@gmail.com

Три версии, с исправленным About'ом. Я отказался от статической разметки, сделал динамическую, растягивается по тексту. Но текст должен изначально быть разбит переносами строки, иначе диалог растянется по нему эдак до 2000x600. Но это в основном касается локализаторов. Русскую локализацию я обновил соответствующим образом.

[Anonymous]

Originally posted by: LRN1...@gmail.com

Да, ещё одна вещь. В LOPyFB2Tools жанры в тексте книги (которые отформатированы служебными стилями) пишутся в виде кодов (типа comp_soft или ref_genre). Это связано с тем, что если писать жанр по имени, то он не будет читаться в другой локали (ибо имена жанров зависят от локали).
Как вариант, можно выделить названия жанров во что-нибудь отдельное и шаманить с translation(), чтобы загружать названия жанров для всех языков разом, и сверять текст из книги уже с этим списком.
Но это, конечно, много копать придётся. Проще оставить жанр в тексте в виде кода. Ну, и в конвертэр можно добавить фичу для отображения кодов жанров (сейчас показываются всегда только названия, код сохраняется под шапкой). А если говорить о наборе инструментов (которых в LOPyFB2Tools пока нет), то можно сделать инструмент для вставки кода жанра по имени.

[Anonymous]

Originally posted by: dik...@gmail.com

Оставить просто код жанра - это все-таки не есть хорошо для пользователя - не упомнишь все коды. Я в свое время массу времени потратил для того, чтобы выбор жанра был удобнее...

[Anonymous]

Originally posted by: LRN1...@gmail.com

Сделал более подробный профайлинг. Взял 99-страничный отрывок из большой книги (удалил оттуда таблицу, которая была в начале - остался только текст, заголовки и по-моему одна поэма). Замерил, сколько времени работает Document_parser(). Работает ~900ms.
Начал комментировать в нём разные куски кода.
Выяснилось, что ~300ms тратится суммарно на Delete_line_break() (взял на заметку, возможно если не использовать регулярные выражения, то будет чуток быстрее) и Inline_all_parser()
Ещё ~300ms тратится на логику (обработка разных типов секций - хотя самих секций нет, есть только проверка на тип секции, все секции на самом деле оказываются Text) и обработку нумерованных списков.
И наконец, когда я убрал оттуда всё и оставил вот это:

def Document_parser (self, settings):
  text = self.model.getText ()
  for paragraph in Enumeration_iterate (text.createEnumeration ()):
    for section in Enumeration_iterate (paragraph.createEnumeration ()):
      continue

Я получил ~300ms в остатке. То есть перебор (без обработки!) содержимого документа по параграфам занимает 1/3 времени относительно перебора с обработкой.
Пробовал отказаться от враппера Enumeration_iterate(), результат ощутимо не изменился.
Из этого я сделал вывод о том, что Document_parser() дальнейшей оптимизации не подлежит (разве что изменится алгоритм работы). То есть парсинг простого текста (без всего) работает близко к своему теоретическому пределу.

Медленная обработка 264-страничного текста, который ты упоминал, скорее всего является отражением замедления (в два раза), которое я обнаружил в OOo по сравнению с LO (см. предыдущие посты). Ну, и ещё у тебя процессор медленнее моего, причём значительно - у меня этот документ скорее всего секунды за 3 обработается, а не за 2 с половиной минуты. Хотя не, там же ещё запись в файл...
А вот сохранение одной картинки (обложки) вполне может также всё обломать - в нынешней реализации обработка некоторых картинок серьёзно замедляет работу.

[Anonymous]

Originally posted by: dik...@gmail.com

Да, мой процессор сегодня только в антикварном магазине найти можно :). Пробовал потр на работе а там - допотопные машины.

[Anonymous]

Originally posted by: LRN1...@gmail.com

Новая серия экстэншнов. Валидатор теперь работает параллельным процессом (разница только в том, что он не вешает soffice, и его можно убить по желанию), можно запускать валидацию для уже существующих файлов. Исправлена пара багов.

Перевод давно не обновлял. Пока руки не доходят. Поэтому не уверен, есть ли ещё баги в переводе (строки, которые не просто не переведены, а вообще не заключены в _g ())ю

[Anonymous]

Originally posted by: LRN1...@gmail.com

Пробовал запускать под другим юзером, у которого стандартные права (NT 6.1.7601, юзер только что создан со стандартными правами) - всё работало исправно. Так что дело не в админских привилегиях (хотя не исключено, что более жестокие относительно стандартных политики могут негативно отражаться на работе).

Заодно выяснил, что quickstarter считается при перезапуске OpenOffice. Поэтому надо выключать его в том числе, когда перезапускаешь OO после установки экстэншна (а перезапускать надо - иначе будет медленно работать). Надо будет как-то это отразить в документации.

[Anonymous]

Originally posted by: dik...@gmail.com

Молодец!

[Anonymous]

Originally posted by: LRN1...@gmail.com

Добавил перевод множественных чисел (пока только в одном месте - кол-во экспортированных картинок).

Теперь make.py использует только GNU gettext. pygettext.py, как оказалось, не поддерживал множественные числа (либо я не догадался, как ею воспользоваться, наверное keyword неправильно указывал - при использовании xgettext я на те же грабли сначала наступил). Добавил соответствующий аргумент, чтобы легче было указывать местонахождение gettext. Поскольку GNU gettext теперь обязателен, make.py также самостоятельно обновляет все найденные .po-файлы из en_US.po.

Добавил строк для перевода. Обновил русский перевод и добавил его в репозиторий.

Сделал тэг 1_0_0_beta_1

Как обычно, три варианта в аттаче.

/me пошёл искать beta-тэстеров

Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low OpSys-All Milestone-Release1.0 Performance Usability
Owner: LRN1...@gmail.com
Status: Fixed

[Anonymous]

Originally posted by: LRN1...@gmail.com

Добавил загружалку шаблона стилей (шаблон есть в репозитории в под-директории misc, это тот же самый шаблон, который поставляется в архиве с OOoFBTools). Обновил русский перевод. Сделал тэг 1_0_0_beta_2.

[Anonymous]

Originally posted by: LRN1...@gmail.com

Исправил несколько багов связанных с работой под *nix (тэстировал под Debian Sid). Сделал тэг 1_0_0_beta_3.

[Anonymous]

Originally posted by: LRN1...@gmail.com

Х-м-м...сделал вставлялку языков и жанров (служебные стили). Пока не закоммитил. В процессе работы над ней возник вопрос: а почему, собственно, не все поля информ.диалога можно задать с помощью служебных стилей?
Мне в LOPyFB2Tools проще сделать функцию, которая записывает всё записывабельное содержимое информ.дерева (т.е. исключая ID, дату создания FB2, и название ПО, наверное) с разметкой служебными стилями в документ, чем делать для этого отдельный диалог, как это реализовано в OOoFBTools.

[Anonymous]

Originally posted by: LRN1...@gmail.com

Сменил статус на "работа идёт".

Status: Started