Не всегда исполняется require в начале скрипта

Страницы: 1
RSS
Не всегда исполняется require в начале скрипта
 
Не знаю что служит причиной, но сталкиваюсь с тем, что при перезапуске скрипта  require как бы работает в холостую. Не исполняя код модуля. Как будто кто-то до этого уже загрузил этот модуль (хотя package.loaded его не содержит до require, получает после). Но это же самое начало скрипта, а другие скрипты не должны на него влиять. Это вроде как разные "машины". Может как-то ошибочно остается "полуподгруженным" от предыдущего запуска этого же скрипта?
Лечится перезапуском всего квика.
 
Т.е. запуск require не исполняет код модуля как новый, а берет какой то слепок его прошлого исполнения откуда-то. Но, повторю, это начало скрипта. Все должно быть как первый раз.
 
Что такое "код модуля"?
Какая конкретно функция в DLL не выполняется при выполнении нового скрипта?
 
Цитата
swerg написал:
Что такое "код модуля"?
Какая конкретно функция в DLL не выполняется при выполнении нового скрипта?
речь не о dll, а о require другого lua скрипта. Его код не выполняется. Хотя определенные в нем ф-ции подгружаются. Не все Если он переопределял глобальную системную ф-цию, то это уже слетает. Поэтому и говорю, вместо запуска кода подключаемого модуля берется какой-то кеш от прошлого его запуска.  
 
Предлагаю просто вот это вот "переопределял глобальную системную ф-цию" вынести в отдельную функцию в модуле, а не в общем коде.
И добавить вызов этой функции в вашем скрипте после require

Вообще ваше исходное сообщение очень путанное. лучше бы вы описали последовательность действий, приводящих в ошибке. Как я понял - при повторном запуске того же самого скрипта не не работает переопределение глобальных функций, описанное в подгружаемом через require модуле.
 
Цитата
swerg написал:
Предлагаю просто вот это вот "переопределял глобальную системную ф-цию" вынести в отдельную функцию в модуле, а не в общем коде.
И добавить вызов этой функции в вашем скрипте после require

Вообще ваше исходное сообщение очень путанное. лучше бы вы описали последовательность действий, приводящих в ошибке. Как я понял - при повторном запуске того же самого скрипта не не работает переопределение глобальных функций, описанное в подгружаемом через require модуле.
Я описал ситуацию на простом примере. Да, общий код модуля не исполняется. Можно в нем написать message('hello') и это не будет напечатано. Но, как сказал, не всегда. Не знаю что приводит к проблеме. Обычно каждый перезапуск макроса корректен - будет напечатано hello. А потом перестает. Проблема есть.
 
Пару раз словил странное явление:
Есть скрипт использующий библиотеки.
Был запущен один, который использовал библиотеку, расположенную в одной из папок отладки.
Потом был запущен другой скрипт, использующий ту же библиотеку (то же имя), но уже из рабочей папки.

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

Перезапуск терминала решил проблему.

Так что про кэш мысли возникали.
 
Нет, вы не описали "простой случай". Вы написали свои фантазии про неввполняющийся require. После и вовсе пустились в какие-то фантащийные рассуждения о причинах.
Описывать же следует только факты. Т.е. последовательность ваших действий и наблюдаемые эффекты.
Просто рекомендация для будущих сообщений
 
Спасибо, учить меня не надо.
Да, я сразу даю разработчикам видимые вероятные наводки. Что-то переоптимизировали с загрузкой модулей.
Добавлю еще, что переход перманентен - после него все скрипты, загружающие данный модуль, не исполняют его.
 
Цитата
Андрей написал:
Спасибо, учить меня не надо.
Да, я сразу даю разработчикам видимые вероятные наводки. Что-то переоптимизировали с загрузкой модулей.
Добавлю еще, что переход перманентен - после него все скрипты, загружающие данный модуль, не исполняют его.
андрей.

ошибка где то у вас, даже не сомневайтесь.

если нужна помощь - делайте минимальный пример, где эффект есть и выкладывайте. Но скорее всего в процессе этого вы сами найдете свою ошибку
 
Цитата
s_mike@rambler.ru написал:
Цитата
Андрей написал:
Спасибо, учить меня не надо.
Да, я сразу даю разработчикам видимые вероятные наводки. Что-то переоптимизировали с загрузкой модулей.
Добавлю еще, что переход перманентен - после него все скрипты, загружающие данный модуль, не исполняют его.
андрей.

ошибка где то у вас, даже не сомневайтесь.

если нужна помощь - делайте минимальный пример, где эффект есть и выкладывайте. Но скорее всего в процессе этого вы сами найдете свою ошибку
С чего это така яуверенность? ) Смотрите. Если в квике ошибки нет, то запуски скриптов не должны иметь side effects на последующие запуски. А я вижу, что все скрипты остановлены и запуск приводит к такой проблеме. Как вы можете это объяснить, если в квике нет ошибки? И нет смысла говорить о простом примере, т.к. у меня самого он не воспроизведет проблему на свежем запуске квика. А каким примером привести квик в такое проблемное состояние я, конечно, не знаю. Поэтому надо копать с другой стороны - чтобы разработчики посмотрели у себя, почему вообще возможны такие side effects с подгрузкой модулей. Какое-то там кеширование. Потому я и дал такую наводку сразу.
 
Цитата
Андрей написал:
side effects
точно есть, была даже ошибка с вызовом __gc объектов при повторном запуске прибитого скрипта, ее исправили. Вот, кстати, этот момент в репорте не освещен, скрипт штатно завершился или был прибит квиком (в т.ч. по истечении таймаута на завершение после нажатия "остановить", что не всегда можно заметить невооруженным глазом).
 
Цитата
Андрей написал:
Цитата
   s_mike@rambler.ru написал:
 
Цитата
Андрей  написал:
Спасибо, учить меня не надо.
Да, я сразу даю разработчикам видимые вероятные наводки. Что-то переоптимизировали с загрузкой модулей.
Добавлю еще, что переход перманентен - после него все скрипты, загружающие данный модуль, не исполняют его.
 андрей.

ошибка где то у вас, даже не сомневайтесь.

если нужна помощь - делайте минимальный пример, где эффект есть и выкладывайте. Но скорее всего в процессе этого вы сами найдете свою ошибку
С чего это така яуверенность? ) Смотрите. Если в квике ошибки нет, то запуски скриптов не должны иметь side effects на последующие запуски. А я вижу, что все скрипты остановлены и запуск приводит к такой проблеме. Как вы можете это объяснить, если в квике нет ошибки? И нет смысла говорить о простом примере, т.к. у меня самого он не воспроизведет проблему на свежем запуске квика. А каким примером привести квик в такое проблемное состояние я, конечно, не знаю. Поэтому надо копать с другой стороны - чтобы разработчики посмотрели у себя, почему вообще возможны такие side effects с подгрузкой модулей. Какое-то там кеширование. Потому я и дал такую наводку сразу.
вариантов просто миллион

вот вам один, при котором require может выполняться, а может не выполняться и никаких сообщений вы не получите

function f()
a=math.random(0,1)   -- выдает 0 или 1
if a==1 then b= 1 end
x = 5 > a
require "чегойта"
end

pcall(f)
 
function f()
a=math.random(0,1)   -- выдает 0 или 1
if a==1 then b= 1 end
x = 5 > b                              -- вот так должно быть. b или число или nil. ошибка исполнения при nil
require "чегойта"
end

pcall(f)
 
Цитата
Anton написал:
Цитата
Андрей написал:
side effects
точно есть, была даже ошибка с вызовом __gc объектов при повторном запуске прибитого скрипта, ее исправили. Вот, кстати, этот момент в репорте не освещен, скрипт штатно завершился или был прибит квиком (в т.ч. по истечении таймаута на завершение после нажатия "остановить", что не всегда можно заметить невооруженным глазом).
Это действительно может быть связано с вылетом терминала. Пару раз именно рядом происходило.
Я же после нашего такого плотного обсуждения lua_share, написал свою библиотеку общей памяти на с++ ) Между терминалами, но без отдельного сервера. С синхронизацией на уровне отдельных объектов. Подпиской на их изменения в общей памяти, локированием.. С многопоточностью, в т.ч. возможностью из скрипта запускать выполнение lua-ф-ции в отдельном потоке (в этом же луа стейте).. Всё как хотел ) Но вот, иногда во время сильной интенсивности на бирже терминал слетает. Однако, это лишь помогает нам понять, что ошибка в нем все же есть. И нет, в этом скрипте я не использовал свою многопоточность. Все же, хочется дождаться ответа разработчиков насчет кеширования подключаемых модулей не внутри одного lua инстанса, а между разными скриптами и их повторными запусками.
 
У меня с помощью этой библиотеки скрипт одного терминала, где глубина стакана только 20, максимально оперативно запрашивает стакан в другом терминале, где он 50 )  
 
Цитата
Андрей написал:
после нашего такого плотного обсуждения lua_share
Боюсь, это было обсуждение с автором lua_share, который не я. Он тут тоже бывает (иногда?) под другим ником, даже как-то спорили о чем-то.
Страницы: 1
Читают тему (гостей: 1)
Наверх