shmuz / luafar Goto Github PK

GCC cannot find lua5.1.dll when making helloworld.dll. It used to work only due to environment variable LIBRARY_PATH being set. Probably, this is the case for all make files that include src\luaplug.mak.

(Reported by Aidar Rakhmatullin).

Given some multibyte character X, pattern %X does not match X in the subject.
For example, pattern %│ does not match │.

(Reported by Aidar Rakhmatullin).

При запуске с текущими lfsearch-addon v1.4, lfsearch v3.0.4, luafar4editor v3.0.8, LauFin и luafar3.dll v3.0.9 вопросов нет, а с 3.0.10 соглашается запускаться только один плагин luafar4editor остальные сообщают об отсутствии нужной точки входа.. Сравнил импорты и экспорты DLL и вижу, что в 3.0.10 в таблице экспорта вызовы LF_LuaClose и LF_LuaOpen отсутствуют, но вроде и прямых их вызовов в таблицах импорта нет, системных логах пусто, записи ошибки по F3 пока так же на гипотезу не наталкивают:

LastError: 0x0000007E - Не найден указанный модуль.

С расшифровкой причины:

NTSTATUS: 0xC0000135 - {Не удалось найти компонент} Приложению не удалось запуститься, поскольку %hs не был найден. Повторная установка приложения может исправить эту проблему.

зато просмотр в Process Hacker списка загруженных модулей показывает, что при вызове luafar4editor в списке модулей есть записи:

lf4ed_e.dll, 0x67380000, 132 kB, LuaFAR for Editor, plugin for Far Manager

lua5.1.dll, 0x6e940000, 172 kB,
luafar3.dll, 0x68300000, 224 kB, LuaFAR library

а для всех двух других плагинах в списке загруженных модулей если использовать luafar3.dll версии 3.0.10 то она просто не загружается в ОЗУ, в то время как с 3.0.9 данное явление не воспроизводится, и от версии ОС не зависит - была у меня такая гипотеза, но сам же её и опроверг - явление воспроизводится под Far 3.0.2772 х86 на Windows XP SP3 и Windows 7 SP1 устойчиво, повторяемость эксперимента 100%. Да и памяти системам вроде хватает - на одной стоит 2 ГБ ОЗУ из них свободно 1,5 ГБ на второй все 4 Гб, первая "видит" все свои 2 ГБ, а вторая "скромно" 3,5 Гб из 4,0 ГБ установленных (ограничения имения дяди Стиви.:)), свободно 1,2 ГБ ОЗУ.

Потому у меня сейчас осталась гипотеза, о том, что версия 3.0.10 в каком-то смысле написана "на вырост" и пока лучше использовать 3.0.9.

Я не ошибаюсь в своих предположениях?

Хочу от всё души поблагодарить за пакет. Выручает, и не плохо. Особенно там, где обычно приходится grep использовать - под демонёнком-то он у меня привычно-штатный, а приди к друзьям с их "мягкософтом" и чеши затылок чем какую бяку что они или дети из сети приволокли и которая грозит их свадебные и прочие семейный реликвии в /dev>nul сплавить коли не заплатят сиз тёмного угла выковырнуть. Вот тут LFS не раз выручала вредителей прищучить. И редакторный пакет быстро стал для меня привычным инструментом. Нам одного только не хватает - научить комп наши мысли читать и опережать желания.:) Ну, это конечно утопия. Значит будем и дальше учить этого железного идиота хорошим манерам.:)

P.S.

Я этот "инц" написал специально чтобы люди видели что иной раз надо и "спасибо" за труд сказать. А то привыкли всякие птенцы гнезда сачкова клювики раскрыть и ждать вкусного червячка от окружающих.

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

Получил на руборде баг-репорт (http://forum.ru-board.com/topic.cgi?forum=5&topic=31718&start=2360#7 ) на свою сборку, стал смотреть в чём дело и нарвался на стенде с AMD Athlon XP (ядро Barton, система каманд i686) на код ошибки 0х1D - не поддерживаемая машинная команда. А раз Pentium E5400 связку кода LuaFar 3.0.5 + LuaSearch 3.0.2 + Luasearch-addons 1.4 + Lua4Edit 3.0.3 выполняет без ошибок, значит процессор подходит. И потому я бы в документации обязательно указал под какой ЦПУ и с каким набором команд программа откомпилирована, и если возможно, то стоит её пересобрать под систему команд i686 - это обеспечит универсальность кода и его применимость на всех эксплуатируемых сегодня системах, в т.ч. и на бюджетных машинах с интегрированными в платы ЦП VIA C3 - C7 (можем считать что у них система команд i686) благо этого добра в фирмах и госссекторе предостаточно, и лет на десять ещё точно хватит - сроки амортизации оборудования не вышли, и его просто никто не спишет под замену. Тормозом выступят ведомственные/корпоративные инструкции и деньги. Нарушил - оплати из своего кармана все убытки конторы. Просто и надёжно.:)

Пока первые мысли по следам вылета LuaSearch 3.0.4 при поиске в локальной копии SVN. Ошибка возникла на Far 3.0.2611 в API которого появилось изменение - константа CP_AUTODETECT переименована в CP_DEFAULT:

w17 12.04.2012 03:11:29 +0400 - build 2607

1. M#1773: Дадим возможность разрешать пункт AutoDetect в меню по Shift-F8
   АХТУНГ: CP_AUTODETECT переименована в CP_DEFAULT

и несмотря на предположение w17 что он считает, что сбоев быть не должно, я думаю, что сбой с NMI 0x00000005 (нарушение защиты памяти - в отладчике был виден переход в область векторов прерываний < 16k) с выдачей ошибки в OpenW после задания поисковой маски . для поиска всех вхождений CP_AUTODETECT в исходниках вызвано этим изменением, т.к. при поиске по маске *.?pp (CPP, HPP файлы) ошибка у меня не воспроизводилась. Погляжу ещё раз на более старой версии 2605 (вроде должен быть бинарник) и тогда смогу точнее сказать. А пока я думаю это стоит считать предварительным сообщение нуждающемся в уточнении и проверке. Одно сейчас могу утверждать точно - при поиске по всем файлам сбой был, при ограничении маски не было. В каталоге где я его встретил у меня только одна woking copy - Far3Colorer, в остальных наборах структур данных SVN нет, потому и возникло предположение о взаимосвязи событий. Но буду проверять.