slech Silver Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору GoldenDict домашняя страница, форум, документация, скриншоты, скачать, история изменений   Актуальная версия 1.5.0: Windоws RC2-36 Qt 4.8.6 или Qt 5.6.2, последний EXE-файл: goldendict-1.5.0-RC2-50-g2fe314a(EXE only).7z. Плагин dsengine.dll для Qt 5.6-based версии на Windows XP: dsengine_5.6.1_for_XP.7z MacOSX RC2-36 (Qt 562) (рекомендуется для Mavericks & Yosemite); RC 483 (Qt 532) (рекомендуется для Mountain Lion); RC 425 (Qt 486)   GoldenDict — новая словарная программа, обладающая следующими особенностями:     Графический интерфейс на основе табов, для создания которого использована библиотека Qt; Интеграция с html-движком WebKit для корректного представления материалов в html-формате; Поддержка подключения словарей в форматах: Babylon (.BGL), StarDict (.ifo/.dict./.idx/.syn), Dictd (.index/.dict(.dz)), ABBYY Lingvo (.dsl тексты и аудиоматериалы .lsa/.dat, .lsd - только в Android), XDXF, AARD, MDX/MDD, EPWING; Система морфологии, которая находит основы слов при поиске, улучшая его результаты, а также дает рекомендации по правильному написанию слов. Используются обычные словари Hunspell/Myspell; Поддержка индексации звуковых файлов в директориях, формируя из них словари аудио-произношений; Поддержка отправки запросов в Wikipedia, Wiktionary и другие MediaWiki сайты; Режим работы в роли глобальной для всего десктопа всплывающей подсказки, позволяющий выводить информацию для выделенного или помещенного в буфер обмена слова из любого текста внешней программы; Для загрузки доступна версия, имеющая в комплекте набор англо-русско-английских словарей, словарей морфологии и примеры произношения слов на английском языке.     Программа позиционируется как функциональная замена StarDict, поддерживающая большее количество форматов файлов и более качественное их отображение. Программа умышленно не вводит собственного формата файлов, ставя вместо этого задачу наиболее полно поддержать все популярные существующие.   Официальные Early Access билды для Windоws :: для MacOSX :: для Linux. Официальные Development билды для Windоws. Официальный форум поддержки GoldenDict. Официальный баг-трэкер.   Параллельные топики: GoldenDict - New Level - Разработка новых форматов словарей для GD: DSLGD, HTMLGD; подключение речевых движков; режим закладок; варианты полнотекстового поиска.   Как сжимать словари в формат .dz для использования в GoldenDict :: DictZip 1.12.1 (latest) :: Оболочка DictUI   Ссылки на готовые сборки   Ссылки на словари для GoldenDict Всего записей: 4893 | Зарегистр. 10-11-2004 | Отправлено: 11:34 26-04-2009 | Исправлено: Maz, 11:48 23-02-2017

Abs62 Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору ramix Цитата: 1) Такое впечатление, что во время FTS-поиска GD интенсивно обращается к самим словарям, а не только FTS-индексу. Интересно, для чего и не отнимает ли это лишние ресурсы? Принцип поиска простой - сначала по индексу ищутся статьи, в которые входят все имеющиеся в запросе слова, а потом по тексту найденных статей ищется подходящее под запрос их сочетание. Словосочетаний в индексе нет, только отдельные слова и адреса статей, в которые они входят. Цитата: 2) Что значат многочисленные строки типа "Warning: Warning: no corresponding opening tag for closing tag "m2" found." или "Warning: Warning: no corresponding opening tag for closing tag "p]" found."?   Это значит ругань парсера DSL на несоответствие открывающих и закрывающих тегов в тексте статьи. В первом случае наверно тег [/m2] вместо [/m] в конце строки, а во втором надо по тексту статьи смотреть. Возможно, лишняя скобка, вроде [/p]]. ---------- 0 программистов ругал сердитый шеф Потом уволил одного, и стало их FF Всего записей: 6080 | Зарегистр. 22-10-2005 | Отправлено: 07:47 18-04-2014 | Исправлено: Abs62, 08:05 18-04-2014

Abs62 Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору BKSRU Цитата: Код действительно сырой. У меня на 50% без индекса работает быстрее - то, что проверял (есть исключения как мультитран) (речь о сжатых словарях, конечно DSL), при том, что явно не самый эффективный способ обхода, по существу двойная работа. Ну а с индексом скорость гораздо выше (собственных же результатов) на порядок (10-20 раз).   Поиск без индекса - это для мазохистов. Можете сделать лучше - сделайте, какие проблемы. Я код не прячу, сейчас последние правки лежат здесь, буде не обнаружится критичных багов, переедут в основной репозиторий. Цитата: По поводу подсветки. Особой сложности нет. Могу выслать свой код для примера, если не зазорно. Может, что поможет. Высылайте, посмотрим. А насчёт особой сложности - не обратили внимания, что в вашем варианте штатный поиск по странице умирает в мучительных судорогах? ---------- 0 программистов ругал сердитый шеф Потом уволил одного, и стало их FF Всего записей: 6080 | Зарегистр. 22-10-2005 | Отправлено: 10:23 18-04-2014

ramix Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Abs62 Цитата: Принцип поиска простой - сначала по индексу ищутся статьи, в которые входят все имеющиеся в запросе слова, а потом по тексту найденных статей ищется подходящее под запрос их сочетание. Я правильно понял, что в данной системе поиска, даже если мы ищем одно слово, то всё равно происходит обращение GD к самим словарям? (Как я заметил, обращение к словарям идет в первой половине поиска, а во второй GD там что-то внутри себя перелопачивает, интенсивно нагружая уже не диск, а процессор.)   Добавлено: А что если подсветку организовать, так сказать, штатными средствами - щелчок по заголовку карточки в окне со списком найденных автоматически запустит штатный "поиск на странице (Ctrl+F)" с автоподстановкой искомого слова и включением подсветки всех найденных результатов?   Добавлено: Цитата: В первом случае наверно тег [/m2] вместо [/m] Но тега [/m2] в DSL нет, только [/m]   Цитата: а во втором надо по тексту статьи смотреть Если бы парсер был так любезен сообщить, про какую статью и словарь идет речь...  На самом деле, ошибки с незакрытыми [/m] должны исчисляться десятками тысяч, а тут таких ошибок просто десятки. Всего записей: 968 | Зарегистр. 19-06-2006 | Отправлено: 10:55 18-04-2014 | Исправлено: ramix, 11:04 18-04-2014

Abs62 Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору ramix Цитата: Я правильно понял, что в данной системе поиска, даже если мы ищем одно слово, то всё равно происходит обращение GD к самим словарям?   Да. Цитата: (Как я заметил, обращение к словарям идет в первой половине поиска, а во второй GD там что-то внутри себя перелопачивает, интенсивно нагружая уже не диск, а процессор.)   Пополнение списка найденных заголовков, сортировка - это тоже время при тысячах слов в списке. Если функция просмотра статьи не выделила заголовок, он ищется в основном индексе по адресу статьи, опять время. И т.д. Дальше будет видно, что там можно ещё оптимизировать, а что нет. Цитата: А что если подсветку организовать, так сказать, штатными средствами - щелчок по заголовку карточки в окне со списком найденных автоматически запустит штатный "поиск на странице (Ctrl+F)" с включением подсветки всех найденных результатов? А он совсем не обязательно что-то найдёт. К примеру, полнотекстовый поиск "такая картина" с допустимым интервалом 2 слова найдёт сочетание в статье "такая замечательная картина". А штатный поиск по странице будет искать именно "такая картина" и обломается. Причём искомых словарей может быть для конкретного заголовка несколько, и в общем случае искомые словосочетания в них будут разные. ---------- 0 программистов ругал сердитый шеф Потом уволил одного, и стало их FF Всего записей: 6080 | Зарегистр. 22-10-2005 | Отправлено: 11:14 18-04-2014

Abs62 Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Но тега [/m2] в DSL нет, только [/m]   Может, просто опечатка, может, ещё что. Смотреть надо. Цитата: Если бы парсер был так любезен сообщить, про какую статью и словарь идет речь... Сейчас он просто принимает строку на вход и понятия не имеет, откуда она взялась. Надо посмотреть, что там можно сделать, чтобы конкретизировать диагностику. ---------- 0 программистов ругал сердитый шеф Потом уволил одного, и стало их FF Всего записей: 6080 | Зарегистр. 22-10-2005 | Отправлено: 11:19 18-04-2014

ramix Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Для информации: При попытке поиска очень распространенного слова (в моих условиях это было слово dictionary с итоговым кол-вом совпадений более 55 тыс.) без установки ограничения по max arts per dic, время поиска резко увеличивается (непропорционально нелинейно). Грубо говоря, если 22 тыс. совпадений находятся за 3 мин., то 55 тыс. - более чем за 30 мин.   Аналогичная картина наблюдалась при индексации МТ - если его поделить пополам, то индексация проходила довольно быстро и успешно, а если пробовать обработать целиком, то несоизмеримо долго, а порой и с вылетом в астрал.   Надо полагать, данные артефакты связаны с RAM. * * * Может, это случайность, но на время FTS-поиска у меня блокируются (именно блокируются, а не откладываются из-за занятости системы) операции копирования по шорткату Ctrl+C, а по контекстному меню работают. По окончании поиска всё восстанавливается.     Добавлено: Есть такая возможность в списке найденного ставить слова с кавычками рядом с этими же словами без кавычек - чтобы не искать нужное слово в двух разных местах?     Поясню на примере. Ищем в словаре автомашину под названием Cobra. Но мы не знаем, как автор словаря написал название этой машины в заголовке - то ли Cobra, то ли "Cobra". Из-за этого приходится смотреть в двух разных местах - в начале списка, где идут закавыченные слова, и по алфавиту на букве C.   А так, применив наше френдли-юзабилити, мы поставим оба заголовка рядом и сэкономим пару драгоценных секунд на поиске. Всего записей: 968 | Зарегистр. 19-06-2006 | Отправлено: 11:56 18-04-2014 | Исправлено: ramix, 12:02 18-04-2014

Abs62 Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору ramix Цитата: При попытке поиска очень распространенного слова (в моих условиях это было слово dictionary с итоговым кол-вом совпадений более 55 тыс.) без установки ограничения по max arts per dic, время поиска резко увеличивается (непропорционально нелинейно). Грубо говоря, если 22 тыс. совпадений находятся за 3 мин., то 55 тыс. - более чем за 30 мин.   Да, проблема больших списков. Найденные заголовки хранятся в формате "заголовок + список ссылок на словарь", поэтому по приходу новой пачки результатов сначала проводится просмотр уже имеющегося списка на предмет присутствия уже таких заголовков. Для уже имеющихся просто добавляется словарь в список ссылок, остальные добавляются к списку заголовков. После этого список сортируется. Если размер списка N элементов, время на бинарный поиск растёт как log2(N), время на сортировку как N*log2(N). Нелинейно, ясен пень, при всех стараниях. Не знаю, стоит ли ломать голову над дальнейшей оптимизацией, если в десятках тысяч итоговых результатов всё равно разобраться на мой взгляд нереально. Цитата: Может, это случайность, но на время FTS-поиска у меня блокируются (именно блокируются, а не откладываются из-за занятости системы) операции копирования по шорткату Ctrl+C, а по контекстному меню работают. По окончании поиска всё восстанавливается.   Хм. У меня не блокируются. Да и нечему там вроде блокировать.   BKSRU Меряться с вами сами знаете чем я и не думал, стар я уже для подобных вещей. Если видите где неэффективность, ткните пальцем, будем посмотреть. Я далёк от мысли, что мой код идеален. И не думайте, что всё это сделано за один вечер - ошибётесь даже не на порядок. Идеи всегда важны, только не всегда они приемлемы с моей точки зрения. С чем-то я соглашаюсь, с чем-то нет. На штатный поиск мне не наплевать. Не скажу, что используется он часто, но бывает. И полнотекстовый поиск ему не замена. Так что не стоит ломать имеющиеся фичи, если можно и без этого обойтись. За код спасибо, посмотрю. Цитата: Далее из того, что бы хотелось видеть в официальной сборке (ну раз уж дальше не имеет смысла развивать свой вариант, будем попрошайничать) - вариант перебора. Это как? ---------- 0 программистов ругал сердитый шеф Потом уволил одного, и стало их FF Всего записей: 6080 | Зарегистр. 22-10-2005 | Отправлено: 13:09 18-04-2014

ramix Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Идеи-размышления на светлое будущее (если оно будет светлым :   1) Может, стоит сделать поиск по ссылкам и пометам опциональным? С одной стороны, бывает полезным найти слова на данную тему, например, "полит." - тему политики. С другой стороны, пометы и (реже) ссылки могут сильно засорять поиск. А так, если надо, поставил птичку и веди расширенный поиск...   2) Неплохо было бы реализовать экспорт списка найденных заголовков - ищущему может понадобиться вернуться к списку и просмотреть его, проанализировать, подумать...     Добавлено: Abs62 Цитата: Не знаю, стоит ли ломать голову над дальнейшей оптимизацией, если в десятках тысяч итоговых результатов всё равно разобраться на мой взгляд нереально.   Думаю, не стоит. Кто будет искать иголку в стоге сена? Лучше где-то что-то оптимизировать в рефайнинге. Всего записей: 968 | Зарегистр. 19-06-2006 | Отправлено: 13:09 18-04-2014

Abs62 Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору ramix Цитата: Есть такая возможность в списке найденного ставить слова с кавычками рядом с этими же словами без кавычек - чтобы не искать нужное слово в двух разных местах?   Сделал. И дополнил диагностику непарных тегов в DSL. Теперь парсер должен сообщать в логе имя словаря и заголовок статьи. goldendict-1.5.0-RC-302-g362acce(EXE only).7z - 1.18 MB   BKSRU Цитата: Может поиск у вас именно так и работает, но проверить несколько затруднительно. Нет ни подсветки ни копирования результатов.   В моей сборке Enumeration работает именно так. Нет, такого режима нет и пока что не планируется. Не уверен я в его востребованности. Хотите - добавьте сами в свой в свой вариант. Вся обвязка уже есть, так что остаётся всего-навсего: - добавить значение в enum SearchMode в fulltextsearch.hh; - добавить его занесение в комбобокс ui.searchMode в конструкторе FullTextSearchDialog; - доработать напильником parseSearchString() в ftshelpers.cc (разбор строки поиска); - сунуть свой код поиска в checkArticles() там же. И будет оно работать, причём для всех типов словарей. Цитата: Т.е. в очередной раз предпочитаем недодел. Есть предложения, как это улучшить? Давайте. А я лучше пока подумаю, как подсветку впендюрить, чтобы оно работало и при этом ничего не поломалось. Цитата: Это при том, что ограничение в 4 символа великовато. Принятый волевым решением компромисс между гибкостью поиска и размерами индекса. И так на некоторых словарях индексация до полутора гиг памяти отжирает, а сам индекс за треть гига вылазит. ---------- 0 программистов ругал сердитый шеф Потом уволил одного, и стало их FF Всего записей: 6080 | Зарегистр. 22-10-2005 | Отправлено: 17:13 18-04-2014

BKSRU Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Abs62 Цитата: Нет, такого режима нет и пока что не планируется. Не уверен я в его востребованности. Хотите - добавьте сами в свой в свой вариант. Вся обвязка уже есть, так что остаётся всего-навсего: - добавить значение в enum SearchMode в fulltextsearch.hh; - добавить его занесение в комбобокс ui.searchMode в конструкторе FullTextSearchDialog; - доработать напильником parseSearchString() в ftshelpers.cc (разбор строки поиска); - сунуть свой код поиска в checkArticles() там же. И будет оно работать, причём для всех типов словарей.   Т.е. посмотрели мой код и он вполне может быть совместим при желании? На самом деле режим перебора самый востребованный и есть. Остальное баловство, хотя все они у меня присутствуют и подсвечиваются. Разве, что для энтузиастов изучающих язык годятся. Ну например найти примеры с ing-овым окончанием. Ну и я рассчитывал попытаться снабдить кое каким инструментом создателей словарей.   Цитата: А я лучше пока подумаю, как подсветку впендюрить, чтобы оно работало и при этом ничего не поломалось.   Эта часть кода навела хоть на какие мысли? На самом деле штатный поиск по карточке в таком виде не востребован. Слишком далеко он запрятан. Во внештатной работает лучше и подсвечивает как надо и все, что надо. Конечно же согласен, что конфликтов не должно быть. Но об этом не было сообщений (такова его необходимость) и я особо не обращал внимания.   Цитата: Есть предложения, как это улучшить? Давайте.   В своем коде я исключил повторное сканирование в случае: - добавления новых словарей   - если не меняется строка поиска или иные настройки.  Имеется ввиду не просто сигал об изменении строки или настроек, а с возможностью проверки, что строка действительно изменилась. Ведь пользователь может передумать. В этих случаях просто складывается результат. Это повышает комфорт и в общем то скорость поиска (по ощущениям).   Ну а на счет реальной скорости. Ну для этого мне надо будет с вашим кодом разобраться (я со своим то путаюсь через пару недель, переключаясь на разные типы работы). Сами наверное поняли (по коду) кроме железной логики опыта у меня нет. Ну а потом попытаюсь понять почему у меня раз в 10-20 считает быстрее (с индексом). Но в общем то догадываюсь. Все это в угоду веса индекса. Опять компромисс. Но так полагаю, что индекс годится и для других режимов.   Для размышления Advanced Learner's Dictionary, 8th Edition (En-En) Поиск: Have any Официальный вариант (с индексом) - 30 сек   Экспериментальный вариант (как раз режим перебора): Сжатый словарь -  12 сек Не сжатый - 6 сек С индексом - меньше секунды. Это просто к тому, что стоит или не стоит. Конечно стоит. Обход Википедии несколько минут. Разве некуда стремится?  Я не говорю, что это плохо. Вполне приличная скорость. Но разве некуда стремиться? И вы это сделаете лучше меня. Да и полагаю пока я буду пытаться разобраться, вы все равно сделаете как надо. В холостую нет желания работать.   Справедливости ради надо сказать, что например с мультилексом ситуация иная.   Всего записей: 1558 | Зарегистр. 29-01-2009 | Отправлено: 18:35 18-04-2014

Abs62 Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору BKSRU Цитата: Т.е. посмотрели мой код и он вполне может быть совместим при желании? Вставить рядом с другими такими же блок кода, который получает на вход строку и выдаёт решение да/нет - задача не самая сложная. Цитата: Эта часть кода навела хоть на какие мысли? Навела. Цитата: Ну для этого мне надо будет с вашим кодом разобраться getArticleText() в словарях (получение текста статьи из словаря) и checkArticles() (его анализ). Копайте в первую очередь здесь. Цитата: Ну а потом попытаюсь понять почему у меня раз в 10-20 считает быстрее (с индексом). Но в общем то догадываюсь. Все это в угоду веса индекса. Опять компромисс.   Отчасти индекс, если у вас оба слова проиндексированы, отчасти работа с текстом. У меня сейчас текст разбирается через тот же парсер, что и для перевода в html. Если перейти на простую вырезку тегов через регекспы, перевод DSL в текст можно ускорить, и чем больше тегов, тем сильнее это скажется. Просто парсер уже готов и вылизан, а с регекспами надо заново тестировать все неочевидные варианты. Задача на перспективу. Цитата: Но так полагаю, что индекс годится и для других режимов. Индекс годится для всех режимов - по нему производится предварительная выборка статей, что может сильно сократить объём поиска непосредствено в тексте. ---------- 0 программистов ругал сердитый шеф Потом уволил одного, и стало их FF Всего записей: 6080 | Зарегистр. 22-10-2005 | Отправлено: 19:30 18-04-2014

Abs62 Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору BKSRU Цитата: Хоть в хорошем смысле или все так плохо? Да нет, идея в целом рабочая, думаю. Только сделать всё надо аккуратно. ---------- 0 программистов ругал сердитый шеф Потом уволил одного, и стало их FF Всего записей: 6080 | Зарегистр. 22-10-2005 | Отправлено: 20:15 18-04-2014

Abs62 Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору BKSRU Если не вдаваться в технические подробности, задача индекса проста - сопоставить слову набор адресов статей, в которых оно встречается. Поэтому разделяем статью на слова, убираем дубликаты, и добавляем в общий список. Если слово в нём уже есть, просто добавляем к соответствующему ему вектору адресов адрес статьи. И так по всему словарю. При поиске извлекаем из индекса вектора адресов для каждого слова, находим их область пересечения и получаем набор адресов статей, в которых имеются все слова из запроса. А дальше уж идёт обычный поиск заданного выражения в тексте каждой найденной статьи. Цитата: Но во многих случаях от моего кода опять же останется только идея. Ну так а что делать? В большинстве случаев проще написать заново свой код, чем чужой править. Потому как логику работы своего кода изначально нутром чуешь, а в чужом долго разбираться надо, что автор подразумевал, когда писал. Прочувствовать его, как свой. Иначе чуть что тронешь, и всё кувырком идёт. Единственное, что могу посоветовать - сразу пишите так, чтобы можно было воткнуть в общий код. И настоятельно рекомендую руководствоваться принципом "не навреди", а не "да и фиг с ним, это всё равно никому не нужно было". ---------- 0 программистов ругал сердитый шеф Потом уволил одного, и стало их FF Всего записей: 6080 | Зарегистр. 22-10-2005 | Отправлено: 20:48 18-04-2014

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249

Компьютерный форум Ru.Board » Компьютеры » Программы » GoldenDict (Часть 1)

Maz (23-02-2017 11:53): GoldenDict (Часть 2)

Переход по форумам  Закладки   » Компьютеры Цифровое изображение Программы Microsoft Windows UNIX Другие OS Hardware В помощь сисадмину Прикладное программирование Игры Форумные игры   » Интернет Web-программирование В помощь вебмастеру Графика Хостинг Зацените-ка!   » Тематические Ikonboard v.2 Ikonboard v.3 Invision Board Другие форумы PHP-Nuke и другие порталы Мобила   » Общие Спорт Флейм Темы по региональным встречам Музыка и Кино Юмор Литература и Живопись   » Ru.Board Новости Помощь по форуму   » Андеграунд eBookz Варезник Раздачи и акции Мобильный варезник Андеграунд Игры и фильмы   » Специальные Тестирование