Отладка QUIK 8.11

Страницы: 1 2 След.
RSS
Отладка QUIK 8.11
 
Новая версия терминала QUIK 8.11 для отладки.

ftp://ftp.quik.ru/public/updates/8.11/quik_8.11.0_upd.zip

Изменений очень много.
 
Цитата
_sk_ написал:
Изменений очень много.
Можно где-то список изменений прочесть?
 
В частности, появилась Lua 5.4.1, исправлены ошибки, на которые Anton указывал, и прочее. Кто может -- потестируйте.

Полный список внутри архива в папке UpdateDocs.
 
Цитата
_sk_ написал:
Кто может -- потестируйте.
Не, вряд ли. На этом форуме люди не любят кому-то помогать. В соседней ветке простейший вопрос задал - никто не ответил.
 
а релиз 8.10 где???)))) или его только ВТБ брокер получил и распространял.
 
Не скажите, много кто помогает.
 
Цитата
Андрей написал:
а релиз 8.10 где???)))) или его только ВТБ брокер получил и распространял.
Уже не важно.
 
Цитата
_sk_ написал:
Не скажите, много кто помогает.
Ага. Можете оценить эту толпу: https://forum.quik.ru/forum10/topic6052/
 
А зачем перешли на lua 5.4.1? Опять библиотеки перекомпилировать, скрипты перекомпилировать.
Что такого важного увидели в этом релизе, что надо было переходить. При этом, что текущий релиз 5.4.2.
 
Цитата
Nikolay написал:
А зачем перешли на lua 5.4.1? Опять библиотеки перекомпилировать, скрипты перекомпилировать.
Что такого важного увидели в этом релизе, что надо было переходить. При этом, что текущий релиз 5.4.2.
Скачайте новый квик почитайте что обновили, вот ответ:

Поддержана Lua версии 5.4.1, использование которой должно устранить многие проблемы с
исполнением скриптов. При этом версия 5.3.5 продолжает поддерживаться и остаётся версией по
умолчанию. Ранее собранные скрипты должны быть пересобраны под новую версию LUA, то же
самое касается внешних библиотек, если они используются. В основные настройки рабочего места
QUIK добавлен раздел «Lua скрипты».
 
Хотелось бы уточнить у тех. поддержки про новую версию 8.11:

1) Зачем остался в дистрибутиве (в обновлении) файл lua5.1.dll  ? как он функционирует?!
Вроде его планировали убрать.

2) В списке исправленных недоработок есть несколько пунктов про Lua (пункты 10, 11, 12, 13)
Подразумевается, что указанные в них проблемы исправятся только при использовании Lua 5.4 ? или для Lua 5.3 они исправлены тоже?
 
Цитата
swerg написал:
Хотелось бы уточнить у тех. поддержки про новую версию 8.11:

1) Зачем остался в дистрибутиве (в обновлении) файл lua5.1.dll  ? как он функционирует?!
Вроде его планировали убрать.

2) В списке исправленных недоработок есть несколько пунктов про Lua (пункты 10, 11, 12, 13)
Подразумевается, что указанные в них проблемы исправятся только при использовании Lua 5.4 ? или для Lua 5.3 они исправлены тоже?
1. Поддерживаю, не понятно для какой именно версии lua исправлены ошибки, перечисленные в списке обновлений.
2. Выбор версии Lua будет Вами поддерживаться и дальше или с какой-то версии вы перейдете строго на Lua 5.4.1?
3. Почему не 5.4.2?
 
По данной ссылке корректно будет работать компилятор?

https://sourceforge.net/projects/luabinaries/files/5.4.0/Tools%20Executables/lua-5.4.0_Win64_bin.zip...
 
В новом квике 8.11 не сохраняется checkbox "Получать обезличенные сделки с момента подключения", если нажать его и в этом же окне сохранить. Но сохраняется если перейти в другое окно и там нажать сохранить.
(Настройки клиентского места-Программа-Получение данных-Обезличенные сделки)
 
Цитата
swerg написал:
2) В списке исправленных недоработок есть несколько пунктов про Lua (пункты 10, 11, 12, 13)Подразумевается, что указанные в них проблемы исправятся только при использовании Lua 5.4 ? или для Lua 5.3 они исправлены тоже?
Значицо, что мы видим по некоторым из этих пунктов.

1. С lua_checkstack (п.11) вроде все порешали, натыкали везде и вроде везде с правильным размером. Считаем вопрос закрытым. Работать будет во всех версиях, это уже над луа находится.

2. С SEH-исключениями (п.12) пока могу сказать только про 5.3. Видно, что старались, но, кажется, забыли флаг /EHa компилятору поставить, поэтому транслятор в lua53.dll теперь есть, но не срабатывает при исключении, исключение таки долетает до qlua.dll и ловится уже там старым транслятором и старой ловушкой, которые, к счастью, пока не убрали. Так что тут еще надо допиливать.

В целом, беглым взглядом глядя, по луа работа большая проделана.

P.S. Для сотрудников арки и внешних желающих поковырять исключения предлагаю простой комплект - длл, генерирующая разные виды исключений (+сорцы), и скриптик к ней. Раскомментируем в скрипте по строчечке и смотрим, как квик соответствующее исключение вылавливает. В арке могут также поставить бряк на новый транслятор и убедиться, что никогда он не выполняется.
 
Lua 5.3.5 в QUIK 8.11 в этом тесте падает с ошибкой
Цитата
Critical error ACCESS_VIOLATION in script
Про Lua 5.4.1 пока сказать ничего могу.
Надо делать так, как надо. А как не надо - делать не надо.
 
После этой ошибки при закрытии QUIK (крестиком) с остановленными скриптами - падение с дампом
Надо делать так, как надо. А как не надо - делать не надо.
 

 Новая версия  QUIK 8.11.0.66 (QLua 5.3) продолжает «падать» ( CQ02750791, CQ02779753, CQ02787899. CQ02802279) (CQ02809006)

  Могу прислать поддержке дампы.  Но с помощью посланной 15.08.20 вам мною моей программы, вы можете получать этих дампов столько, сколько захочете.
Кроме того, наблюдается утечка памяти.  На всякий случай ссылка на мою программу: https://cloud.mail.ru/public/5iZb/2NSAPmJem
 Вопрос к поддержке:
    1) ответьте, пожалуйста, зачем устраиваются скачки с новыми версиями Lua (очередная 5.4)? Какие проблемы при этом решаются?
    2) есть ли понимание у разработчиков QUIK, что при существующей архитектуре обработки событий в QLua, уборка мусора в нем должна быть потокобезопасной?

 
Вопрос к разработчикам, как понять в Lua Api в какой версии lua запущен скрипт и к какой версии библиотеки подключаться?
 
Обе версии библиотеки lua53.dll и lua54.dll находятся в памяти. Как понять в каком окружении запущен скрипт?
 
Цитата
Александр написал:
Как понять в каком окружении запущен скрипт?

 В кнопке запуска скриптов есть список, в котором можно указать версию Lua/
 
Цитата
Александр написал:
Как понять в каком окружении запущен скрипт?
_VERSION
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Цитата
Александр написал:
Как понять в каком окружении запущен скрипт?
_VERSION
При чем здесь _VERSION, я использую Lua Api? При загрузке у меня есть только LuaState и мне нужно подключиться к нужной dll (lua53.dll или lua54.dll), при этом обе dll загружены в память.
 
Цитата
TGB написал:
Цитата
Александр написал:
Как понять в каком окружении запущен скрипт?

 В кнопке запуска скриптов есть список, в котором можно указать версию Lua/
Как мне сделать на lua api?
 
Вопрос получается следующим, как в luaopen_Название определить в какой версии запустился скрипт?
 
Цитата
Александр написал:
При чем здесь _VERSION, я использую Lua Api?

При том, что вы можете прочитать значение глобальной переменной _VERSION.

Ну а дальше уже из серии "Давай я погуглю за тебя". Ну ок, мне тоже пригодится, так что 1:1.

1) lua_version(lua_State *L)
2) void luaL_checkversion_  -- вызывает luaL_error(), если версия не та, что требуется.
 
Цитата
swerg написал:
Цитата
Александр написал:
При чем здесь _VERSION, я использую Lua Api?

При том, что вы можете прочитать значение глобальной переменной _VERSION.

Ну а дальше уже из серии "Давай я погуглю за тебя". Ну ок, мне тоже пригодится, так что 1:1.

1) lua_version(lua_State *L)
2) void luaL_checkversion_  -- вызывает luaL_error(), если версия не та, что требуется.
Чтобы использовать lua_version надо загрузить нужную dll. Возникает вопрос какую версию dll брать?
В луа 5.4 lua_version просто возращает версию луа 504 не зависимо от того, для какой версии LuaState.
Но в целом можно попробовать пошаманить с этим делом.
 
Цитата
TGB написал:
есть ли понимание у разработчиков QUIK, что при существующей архитектуре обработки событий в QLua, уборка мусора в нем должна быть потокобезопасной?

Мне казалось, что заданный вопрос простой и для разработчиков QUIK понятный. Но так как ответа до сих пор нет, то я этот вопрос сформулирую более детально.

   Текущая архитектура обработки событий в QLua (на 15.12.20), насколько я себе представляю, схематически следующая.  
  Для обработки всех скриптов пользователя создается один служебный поток (под потоком здесь и далее понимается поток Windows).  В этом потоке выполняется запуск всех скриптов пользователя, а также запуск колбеков всех выполняемых скриптов. Кроме того, в этом же служебном потоке будут созданы (при запросе из скриптов пользователя) пользовательские таблицы, а так же будут выполняются функции обслуживания всех таких таблиц (что, вообще то, является ошибкой, и, по-хорошему, это следовало бы отделить от обработки колбеков событий фондового рынка).
  При запуске каждого пользовательского скрипта в отдельном, в основном lua_State создается с помощью функции lua_newthread стек(State) сопрограммы и уже на нем запускается, в отдельном потоке, пользовательская функция скрипта main. Таким образом, исполнение функции main, по ее локальным объектам, пространственно отделено от основного lua_State.
 Отработка колбеков всех запущенных скриптов пользователя выполняется следующим образом.
 При возникновении события служебный поток запускает последовательно соответствующие событию колбеки выполняющихся скриптов. Колбеки выполняются в основных lua_State скриптов. При этом работают пользовательские потоки (main на стеках сопрограмм) всех выполняющихся скриптов. Таким образом, получается, что в скриптах пользователя могут работать два потока. Это поток пользователя (main) и служебный поток обработки колбека пользователя.
 Хотя локальные объекты потоков main пространственно отделены от основных lua_State скриптов и при работе с ними, в этих потоках синхронизация не требуется, но общим для работающего потока main и служебного потока, обрабатывающего его колбек, являются информационные структуры управления автоматической памятью QLua. Поэтому это управление должно быть потокобезопасным, то есть обеспечивать корректную работу нескольких потоков. Известно, что нативные версии Lua однопоточные. Управление автоматической памятью в них тоже однопоточное. Поэтому при внедрении версий Lua в QUIK требуется, наверное, много чего, но, как минимум, необходима переработка автоматического управления памятью с целью обеспечения ее потокобезопасности. И это сложная задача.
---------------------------
 Моя программа, на которой «падает» QUIK, тестирует автоматическую память QLua. Похоже, что эта память реализована некорректно, а значит в любых скриптах, в произвольные моменты времени могут возникать ошибки. Так как мой тест специально создает очень большую нагрузку на управление автоматической памятью, то ошибки возникают в течении 2-3 минут. При обычной работе эти ошибки возникают реже и могут проявляться в разных местах.
 
 Вопросы к поддержке:
1) что из выше написанного мною неправильно?
2) есть ли понимание у разработчиков QUIK, что при существующей архитектуре обработки событий в QLua, уборка мусора в нем должна быть потокобезопасной?
 
TGB, чем вас не устраивает отдельная ветка обсуждения ваших проблем? зачем вы в каждой ветке обсуждаете свою проблему, притом что эта проблема никак не связана с темой ветки?
Это так, замечание на будущее.

Цитата
TGB  Для обработки всех скриптов пользователя создается один служебный поток (под потоком здесь и далее понимается поток Windows).

В Windows есть понятие "основной поток приложения". В нем и происходит все то, что вы называете "в служебном".
Здесь есть картинка https://quik2dde.ru/viewtopic.php?id=16
(замечу что картинку эту ARQA стырила и включила в свою документацию, предварительно формально перерисовав, не спросив ни разрешения, ни даже хотя бы не сказав "спасибо")

Цитата
TGB Известно, что нативные версии Lua однопоточные. Управление автоматической памятью в них тоже однопоточное. Поэтому при внедрении версий Lua в QUIK требуется, наверное, много чего, но, как минимум, необходима переработка автоматического управления памятью с целью обеспечения ее потокобезопасности. И это сложная задача.

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

Цитата
TGB Моя программа, на которой «падает» QUIK, тестирует автоматическую память QLua. Похоже, что эта память реализована некорректно, а значит в любых скриптах, в произвольные моменты времени могут возникать ошибки. Так как мой тест специально создает очень большую нагрузку на управление автоматической памятью, то ошибки возникают в течении 2-3 минут. При обычной работе эти ошибки возникают реже и могут проявляться в разных местах.

Я не смотрел вашу программу, однако могу предложить другое объяснение: ваша программа портит память процесса QUIK, после чего он падает. Или подгружаемые вами DLL содержат потоконебезопасный код, из-за которого опять же QUIK падает.
Если бы на самом деле управление внутренними хранилищами QUIK было столь потоконебезопасным, то падали бы и обычные скрипты, которые могут нагрузить "автоматческую память" ничуть не хуже.
Всё же согласитесь, какого-то тотально-массового падения скриптов QLua явно не наблюдается.

Надеюсь, ответ на вопрос 2) вы теперь сами знаете?
 
Цитата
Чтобы использовать lua_version надо загрузить нужную dll. Возникает вопрос какую версию dll брать?

Вы не сделаете динамическую загрузку DLL нужной версии.
Во-первых потому, что нет интерфейса для понимания того, на какой Lua-стек вам передали указатель, а во вторых потому, что вполне вероятно (но это надо дотошно проверять), что отдельные интерфейсные структуры в 5.3 и 5.4 версиях - разные. И в этом случае вы просто не сможете сделать бинарно совместимые версии dll.
Вот и остаётся нам максимум - это проверить, что dll собрана под ту версию Lua, для которой она собрана.
Фиговую какашку нам подсунули разработчки QUIK, да. Ведь фактически нельзя теперь просто положить dll в каталог с QUIK и использовать её спокойно, ведь в зависимости от версии Lua, заданной для скрипта, dll либо поедет, либо не поедет.... Да ужж...

Цитата
В луа 5.4 lua_version просто возращает версию луа 504 не зависимо от того, для какой версии LuaState.

Эту фразу не понял.
Если вы скомпилировали вашу библиотеку (или динамически подгрузили) lua54.dll - то она вам и вернёт всегда 504 из lua_version. Т.к. эта функция просто возвращает вкомпилированную константу (см. исходники), на LuaState она не смотрит.
 
Цитата
swerg написал:
Цитата
Александр написал:
При чем здесь _VERSION, я использую Lua Api?

При том, что вы можете прочитать значение глобальной переменной _VERSION.

Ну а дальше уже из серии "Давай я погуглю за тебя". Ну ок, мне тоже пригодится, так что 1:1.

1) lua_version(lua_State *L)
2) void luaL_checkversion_  -- вызывает luaL_error(), если версия не та, что требуется.
Не подходит, т. к. в Lua 5.4 lua_version просто возвращает номер версии, а при передаче в luastate от Lua 5.4 в функцию lua_version от Lua 5.3 происходит ACCESS_VIOLATION.
Еще варианты?
 
Цитата
swerg написал:
Цитата
Чтобы использовать lua_version надо загрузить нужную dll. Возникает вопрос какую версию dll брать?

Вы не сделаете динамическую загрузку DLL нужной версии.
Во-первых потому, что нет интерфейса для понимания того, на какой Lua-стек вам передали указатель, а во вторых потому, что вполне вероятно (но это надо дотошно проверять), что отдельные интерфейсные структуры в 5.3 и 5.4 версиях - разные. И в этом случае вы просто не сможете сделать бинарно совместимые версии dll.
Вот и остаётся нам максимум - это проверить, что dll собрана под ту версию Lua, для которой она собрана.
Фиговую какашку нам подсунули разработчки QUIK, да. Ведь фактически нельзя теперь просто положить dll в каталог с QUIK и использовать её спокойно, ведь в зависимости от версии Lua, заданной для скрипта, dll либо поедет, либо не поедет.... Да ужж...

Цитата
В луа 5.4 lua_version просто возращает версию луа 504 не зависимо от того, для какой версии LuaState.

Эту фразу не понял.
Если вы скомпилировали вашу библиотеку (или динамически подгрузили) lua54.dll - то она вам и вернёт всегда 504 из lua_version. Т.к. эта функция просто возвращает вкомпилированную константу (см. исходники), на LuaState она не смотрит.
Я динамически подгружаю нужную luaxx.dll в зависимости от версии квика. У меня библиотека на все версии луа.
 
Цитата
swerg написал:
Я не смотрел вашу программу, однако могу предложить другое объяснение: ваша программа портит память процесса QUIK, после чего он падает. Или подгружаемые вами DLL содержат потоконебезопасный код, из-за которого опять же QUIK падает.Если бы на самом деле управление внутренними хранилищами QUIK было столь потоконебезопасным, то падали бы и обычные скрипты, которые могут нагрузить "автоматческую память" ничуть не хуже.
А как вы объясните, что точно эта же программа в QUIK версиях 8.4... без проблем работает без перезапусков  неделями??
Если сомневаетесь, то можете поэкспериментировать. Коды и для версии 8.4.. выложены по ранее указанной мною ссылки.

Цитата
swerg написал:
Если бы на самом деле управление внутренними хранилищами QUIK было столь потоконебезопасным, то падали бы и обычные скрипты, которые могут нагрузить "автоматческую память" ничуть не хуже.Всё же согласитесь, какого-то тотально-массового падения скриптов QLua явно не наблюдается.
 Вы не смотрели мою программу, но голословно утверждаете: обычные скрипты могут нагрузить "автоматческую память" ничуть не хуже.

Цитата
swerg написал:
зачем вы в каждой ветке обсуждаете свою проблему, притом что эта проблема никак не связана с темой ветки?
 Вы гарантируете, что в управлении автоматической памятью QLua 5.3 нет ошибок синхронизации?
А если есть такие ошибки, то в любых скриптах, в произвольные моменты времени могут возникать различные ошибки. И тогда это не моя, а общая проблема неустойчивости QUIK и, наверное, это не запрещено обсуждать и в данной ветке.  Кстати, как решать мои проблемы меня учить не надо.

Цитата
swerg написал:
полностью решённая в исходниках Lua. Там просто можно включить режим сборки "многопоточный". Ну так, если совсем упрощённо.Так что всё "от производителя".
 Вы внимательно изучили исходники, например, Lua 5.3.5??
Интересно, где вы там нашли, что при включении режима сборки "многопоточный" будет реализована потокобезопасная сборка мусора?
 
Надеюсь, на то, что я написал, вам понятно.
 
Цитата
АлександрНе подходит, т. к. в Lua 5.4 lua_version просто возвращает номер версии, а при передаче в luastate от Lua 5.4 в функцию lua_version от Lua 5.3 происходит ACCESS_VIOLATION.

А, ну и славно, вот и проверили, бинарно не совместимы версии.

Цитата
АлександрЕще варианты?

Я немного не понял: я вам чем-то обязан, что вы позволяете себе писать именно так?
Я писал выше, вариант один: две разные dll для разных версий Lua.
Как их загружать в скрипт при условии, что пользователь может выбрать одну из версий Lua - не знаю.
Видимо раскладывать dll разных версий Lua по разным папкам и с путями в скрипте играться в зависимости __VERSION, или имена разные давать dll для разных версий Lua и опять же подгружать нужную библу.
 
Цитата
swerg написал:
Цитата
АлександрНе подходит, т. к. в Lua 5.4 lua_version просто возвращает номер версии, а при передаче в luastate от Lua 5.4 в функцию lua_version от Lua 5.3 происходит ACCESS_VIOLATION.

А, ну и славно, вот и проверили, бинарно не совместимы версии.

Цитата
АлександрЕще варианты?

Я немного не понял: я вам чем-то обязан, что вы позволяете себе писать именно так?
Я писал выше, вариант один: две разные dll для разных версий Lua.
Как их загружать в скрипт при условии, что пользователь может выбрать одну из версий Lua - не знаю.
Видимо раскладывать dll разных версий Lua по разным папкам и с путями в скрипте играться в зависимости __VERSION, или имена разные давать dll для разных версий Lua и опять же подгружать нужную библу.
Вы мне ничего не должны. Странно, что вы так на этот вопрос отреагировали.
Это скорее вопрос к разработчикам. Нагородили кашу, пусть разбирают. Я уже поддержку lua53 и lua54 реализовал. Сейчас осталось понять какую версию lua dll подсовывать.
Все это не решает вопрос, потому что не понятно, какую версию луа брать.
 
В общем накостылил, но вроде бы проблему решил.
Но вопрос остался, хотелось бы услышать комментарии разработчиков. :lol:  
 
Цитата
Александр написал:
Не подходит, т. к. в Lua 5.4 lua_version просто возвращает номер версии, а при передаче в luastate от Lua 5.4 в функцию lua_version от Lua 5.3 происходит ACCESS_VIOLATION.Еще варианты?
Еще вариант - не передавать в lua_version указатель на стейт, а передавать NULL, это защитит от акцесс виолейшена (как?). В этом случае 5.3 вернет указатель на статический номер версии, а 5.4 вернет число с номером версии. Далее исходим из факта, что указатель никак не может быть меньше 64 килобайт, винда из этого тоже всегда исходит, так что безопасно. Значит, ежли получили меньшее число - это напрямую номер версии, а если большее - это указатель на номер версии, разыменовываем и получаем сам номер. Костыльное решение, конечно, но рабочее.
 
Выше глупость написал, конечно, мы и так знаем, из какой длл lua_version дернули. Но вот хотел проверить на практике и узрел очень интересную штуковину. Тксть внимание на экран. Запускаем скрипт, грузящий нашу длл, через "запустить в луа 5.3.5", смотрим, какой стейт нам дали

Теперь запускаем через "запустить в луа 5.4.1", смотрим, какой стейт нам дали

Это изыск дизайна или это лютый косяк?
 
Цитата
Anton написал:
Это изыск дизайна или это лютый косяк?
Отбой, это скорее всего была память выделена на том же месте. Если первый стейт удерживать живым, второй будет другой уже.
 
Anton,Я изучил структуры lua_State для луа 5.3 и 5.4 и они различны. Если поле status <> 0, то это lua5.3, иначе lua5.4.
 
Получилось что-то такое, но не уверен, что верно:
Код
function FindLuaLibrary(LuaState: lua_State) : Boolean;
type
  TLua_version_52 = function (L : lua_State) : Plua_Number; cdecl;
  TLua_version_54 = function (L : lua_State) : lua_Number; cdecl;

  PLuaState = ^TLuaState;
  TLuaState = record
    next: Pointer;
    tt: Byte;
    marked: Byte;
    case byte of
      53: (
        nci53: Word;
      );
      54: (
        status: byte;
        allowhook: byte;
        nci54: Word;
      );
  end;

  function IsModuleLoaded(const ModuleName : String; var Handle : THandle) : Boolean;
  begin
    Handle := GetModuleHandle(PChar(ModuleName));
    Result := Handle > 0;
  end;

var Handle53 : THandle;
    Handle54 : THandle;
    version52: TLua_version_52;
    version54: TLua_version_54;
begin
  Result := IsModuleLoaded(LuaLibName53, Handle53) and
            IsModuleLoaded(LuaLibName54, Handle54);
  if not Result then
    Exit;
  try
    if PLuaState(LuaState)^.status <> 0 then begin
      //Проверим версию для lua5.3
      version52 := GetProcAddress(Handle53, 'lua_version');
      Result := (@version52 <> nil) and (version52(LuaState)^ = LUA_VERSION_NUM_53);
      if Result then
        LuaLibName := LuaLibName53;
    end
    else begin
      //Проверим версию для Lua5.4
      version54 := GetProcAddress(Handle54, 'lua_version');
      Result := (@version54 <> nil) and (version54(LuaState) = LUA_VERSION_NUM_54);
      if Result then
        LuaLibName := LuaLibName54;
    end;
  except
    Result := False;
  end;
end;

 
Добрый день!
Столкнулся с проблемой:
на lua 5.3 пользовался такой конструкцией в модулях: module(..., package.seeall)
на lua 5.4.1  - убрали module и package.seeall
как проще выйти из ситуации?
 
Цитата
Александр написал:
Я изучил структуры lua_State для луа 5.3 и 5.4 и они различны. Если поле status <> 0, то это lua5.3, иначе lua5.4.
Тоже в эту сторону смотрел, показалось ненадежным. Там есть еще одно интересное место, если уже привязываться к версии и немного хачить: к стейту прицеплена юзердата, сам квик по ней версию и определяет (несколько запутанным способом, я не понял, как именно). Получить можно с помощью экспортируемой luaI_getextraspace или (раз уж хачить) просто как ((char *)pstate) - 8, оно во всех версиях луа одинаково. А уж дальше порыться там.
 
Цитата
Максим написал:
Добрый день!
Столкнулся с проблемой:
на lua 5.3 пользовался такой конструкцией в модулях: module(..., package.seeall)
на lua 5.4.1  - убрали module и package.seeall
как проще выйти из ситуации?
module(..., package.seeall) - это старый способ. Ссылка.
 
Цитата
Игорь М написал:
Цитата
Максим написал:
Добрый день!
Столкнулся с проблемой:
на lua 5.3 пользовался такой конструкцией в модулях: module(..., package.seeall)
на lua 5.4.1  - убрали module и package.seeall
как проще выйти из ситуации?
 module(..., package.seeall) - это старый способ.  Ссылка .
Благодарю!
 
Цитата
Александр В луа 5.4 lua_version просто возращает версию луа 504 не зависимо от того, для какой версии LuaState.
Но в целом можно попробовать пошаманить с этим делом.

Ниже вы приводите результаты ваших исследований, за них вам спасибо.

Засада с этим красивым автоматическим определением будет вот где. (предположим что в принципе оно у нас заработало и нам повезло - бинарно интерфейсы совпали)
Если пользователь запустит одновременно два скрипта, использующих такую волшебную библиотеку - ему явно не повезёт.
Потому что указатели на функции в Lua53.dll / Lua54.dll вы явно храните в глобальных переменных, т.е. в каждый момент времени в них фактически указатели на какую-то одну версию Lua.
И даже если разнести указатели в 2 разные структуры по версиям Lua - то придётся в начало каждой интерфейсной функции вставлять хитрую проверку версии переданного стека, а потом еще хитро переключаться на соответствующую версию структуры указателей на функции Lua-API в рамках этой функции, вызванной внутри библиотеки....
Как-то это уже слишком, по-моему.
 
Цитата
swerg написал:
Если пользователь запустит одновременно два скрипта,
Уточнение: запустит два скрипта, указав в них разную версию Lua.
 
Цитата
Anton написал:
Цитата
Александр написал:
Я изучил структуры lua_State для луа 5.3 и 5.4 и они различны. Если поле status <> 0, то это lua5.3, иначе lua5.4.
Тоже в эту сторону смотрел, показалось ненадежным. Там есть еще одно интересное место, если уже привязываться к версии и немного хачить: к стейту прицеплена юзердата, сам квик по ней версию и определяет (несколько запутанным способом, я не понял, как именно). Получить можно с помощью экспортируемой luaI_getextraspace или (раз уж хачить) просто как ((char *)pstate) - 8, оно во всех версиях луа одинаково. А уж дальше порыться там.
Этот способ подходит только для определения версии 5.3 или 5.4. С луа 5.1 status = 0. Поэтому чисто ограничился этим.
lua_getextraspace - опять же надо загружать какую-то из этих DLL, а вот LuaState разный для разных версий.
 
Цитата
swerg написал:
Цитата
Александр В луа 5.4 lua_version просто возращает версию луа 504 не зависимо от того, для какой версии LuaState.
Но в целом можно попробовать пошаманить с этим делом.

Ниже вы приводите результаты ваших исследований, за них вам спасибо.

Засада с этим красивым автоматическим определением будет вот где. (предположим что в принципе оно у нас заработало и нам повезло - бинарно интерфейсы совпали)
Если пользователь запустит одновременно два скрипта, использующих такую волшебную библиотеку - ему явно не повезёт.
Потому что указатели на функции в Lua53.dll / Lua54.dll вы явно храните в глобальных переменных, т.е. в каждый момент времени в них фактически указатели на какую-то одну версию Lua.
И даже если разнести указатели в 2 разные структуры по версиям Lua - то придётся в начало каждой интерфейсной функции вставлять хитрую проверку версии переданного стека, а потом еще хитро переключаться на соответствующую версию структуры указателей на функции Lua-API в рамках этой функции, вызванной внутри библиотеки....
Как-то это уже слишком, по-моему.
Я вас не понял. LuaState разный для версии Lua53 и Lua54, поэтому можно определить хаком версию луа. Я делаю такую проверку, если определяю, что у меня Lua53.dll и Lua54.dll одновременно находятся в памяти.
У меня разные скрипты работают одновременно с разными версиями Lua. В целом способ рабочий, пока другого решения нет. Ждем ответа разработчиков.
 
Попробую написать подробнее.
Напишу как я вижу структуру волшебной библиотеки. Возможно у вас устроено совсем не так, а как-то иначе и указанной проблемы нет, и вы поделитесь вашей структурой.
Все "исходные коды" ниже - условны, без соблюдения всех нюансов синтаксиса, чисто для иллюстрации структуры программы.

Код
var
   // глобальные переменные, куда будут загружены адреса функций Lua API
   lua_pushstring_addr;
   lua_pushnumber_addr;
   luaL_checkinteger_addr;
   luaL_checkstring_addr;
   .... и т.д. ....

function LoadLua53()
begin
   h := LoadLibrary('Lua53.dll');
   lua_pushstring_addr := GetProcAddress(h, 'lua_pushstring');
   luaL_checkstring_addr := GetProcAddress(h, 'luaL_checkstring');
....
end;

function LoadLua54()
begin
   h := LoadLibrary('Lua54.dll');
   lua_pushstring_addr := GetProcAddress(h, 'lua_pushstring');
   luaL_checkstring_addr := GetProcAddress(h, 'luaL_checkstring');
....
end;

function luaopen_XXX(L: Plua_State)
begin
   if (ХитраяПроверка(L) = Lua54) then
      LoadLua54();
   else
      LoadLua53();

... далее обычный код для luaopen_XXX, ссылки на нужную версию Lua подгружены ...
   luaL_newlib(L, ls_lib);
... и т.д. ...
end;


После чего все реализации функций нашей библиотеки пишем обычным образом (без. доп проверок на версию Lua!)

тогда получится так:
- скрипт 1 выполняется в Lua53, загрузил нашу библиотеку.
Все адреса в глоб. переменных у нас указывают на Lua5.3 и все хорошо.

- скрипт 1 продолжает работать и запустили скрипт 2, для которого указана Lua54.
Наша библиотека это определила (необходимость загрузки Lua54), в глоб переменные загрузила адреса из Lua54.dll
И второй скрипт работает корректно.
Но первый-то скрипт уже будет ходить совсем "не туда"!

Чтобы это исправить - мы должны иметь две полных структуры адресов Lua-API функций для разных версий Lua и вставлять проверку в каждую функцию библиотеку, доступную для Lua-скрипта, переключаясь на адреса нужной версии Lua для каждой интерфейсной функции нашей библиотеки....
Или у вас так и сделано?
Страницы: 1 2 След.
Читают тему
Наверх