Ну значит не судьба. Помирайте теперь от любопытства))

Да, немного устарело. Не убираю из принципа "из песни слов не выкинешь". Что было, то было.
А по поводу работы - под другими новостями про MyLibrary посмотрите. Или тут например: https://www.opennet.ru/opennews/art.shtml?num=62437 В комментариях.

Кто вам сказал, что я не "осилил" Qt? ;) Я примерно на одном уровне знаю и API gtkmm и API Qt.

Я ходил по ссылке. И что? "Готовые пакеты в AUR" от этого не перестали быть чушью.

Ради интереса попробуйте скачать полный архив Флибусты и скормить его Calibre. Через пару лет, когда она (оно?) закончит, расскажете, что получилось. Или раньше - место на жёстком диске не бесконечное.

В целом же, если вас устраивает Calibre, то пользуйтесь ей. Я ни на чём не настаиваю.

Для начала было неплохо бы просто не лезть в CSS и не трогать цвета...

И да, афффтар, таки повзрослей. Это уже общий совет.

Только не говорите, что вместо встраиваемой базы данных вы написали свой велосипед, который эти 90 Мб на каждый запрос прочёсывает. Про 2-3-4 деревья знаете?

Это как раз основной паттерн пользователей.
Время индексации мало важно. Обновляется оно редко. Упирается в I/O. За ночь пройдет и ладненько. (можно подтюнить исключив парсинг не изменяемых по разным критериям)
В используемом мной каталогизаторе база в postgre, но действительно многим конечным пользователям она сложна, так что почему бы на 90 мегабайт не использовать что-то встраиваемое. Это копеечный объем. Но лично для себя каталогизаторы без OPDS не рассматриваю. Но альтернативы это всегда хорошо.

Не, ты лучше расскажи - где по твоему суперценному мнению в ЭТОМ надо было итераторы поюзать - и за каким они ТАМ вообще нужны?! Вот ответь хоть раз за свои слова - на кой дьявол в ЭТОМ блоке - итераторы? Там и цикл то - низачем не требуется. Автор уже и сам не знает зачем его сумеречный гений ЭТО породил :)

Глядя на весь этот код - я б сказал что это такой core dump мозга, чтоли, получился.

Да, я понял, почему ты к КА приписал Л. ;) Перечитай внимательно мой ответ на твою ту выдачу - я тебе именно про "фиксацию" и написал.

Потенциально, в Linux, можно использовать Xattrs для кэширования часто используемой (например, при поиске и фильтрации) информации. Для инвалидации кэша - дату модификации файла, сохраненную там же. Инвалидация кэша и доступ к этим данным через таблицу ФС быстрее, чем к целым файлам, не требуется их открытие, (повторное, многократное) чтение и разбор. В отличие от базы данных (с индексом) этот метод хорош тем, что нет нужды сопоставлять файлы с их отображением в индексе, нет привязки к путям, нет нужды считать хэш-суммы, ведь атрибуты уже привязаны к ноде. А базу можно использовать только при миграции данных между платформами (при ручном импорте/экспорте).

А сколько времени от этого проходит в системном вызове?

> С Питоном же помимо всего прочего, вам
> придётся тратить такты процессора на парсинг кода интерпретатором.

Вы можете найти пример программы на pygtk, которая создает просто окно и посчитать какой процент от времени запуска уходит на парсинг. К тому же, можно поставлять сразу байткод.

Вы профилировали? Нет? Почему же я в этом так уверен?
>Любая программа - это в конечном итоге набор инструкций для процессора

Зависит от алгоритма. Возьмите рам-диск, и создайте xml размером гигабайта три(можно и больше). И создайте там корневой элемент с кучей атрибутов с двойными кавычками. Замерьте скорость получения атрибута. Теперь замените двойные кавычки на одинарные, и повторите попытку. Тут уже на жёсткий диск не спишешь.

https://github.com/ProfessorNavigator/mylibrary/blob/798671597522feca1bdbb4cdb

А я разве где-то чего-то просил?)) Требовал благодарности?)) По-моему я только сделал программу, выложил код в открытый доступ и опубликовал об этом новость. Будет всё это кому-то полезным - хорошо, нет - на нет и суда нет.

Мир, неспособный переплюнуть "дерьмовое" решение, готовый грызть кактус с лопаты, уже не спасти, не жалко. А может, это не решение плохое, а экспертиза.

> Не любой софт, не в любом его состоянии стоит релизить.

Открытие исходников - это одно. А релиз софта - это другое.
Первое - это необходимое условие для коллективной разработки. Второе - соглашение и способ контроля качества. Причем, если качество кода при открытии было невысоко (код написан "на коленке"), то для его улучшения, кроме прочего, частые релизы также необходимы.

Там намного больше бревен. Большая простынка плохо структурированного кода, изобилующего трюками в control flow, декларациями по всем закоулкам, с чрезмерным размером/уровнем сложности. В общем упаси вас получить себе в тиму таких коллег.

Я вижу, что порог вхождения поднят достаточно, неспособные отсеиваются.

Советую тебе посмотреть ещё translator.c в теге v0.2.0 -- для полного разрыва всех шаблонов.

Очевидно, Турчин В.Ф. -- агент кейджиби, был заслан в США с Рефалом, научил их, что в <> может быть кот.