Т.е. - первые три аргумента в функцию будут передаваться строчными, четвертый - число, MSVStudio 2107 лупит мне ошибки: с 1 по 4ую строки - слишком мало аргументов в вызове функции, в чем ошибка? Вроде все по вашему примеру...
Там же форум, можно спросить не отходя от кассы ;)
В luaL_checklstring() третьим параметром передайте nullptr
Анатолий написал: Привет, слушай выручи пожалуйста - можешь помочь скомпилить библиотечку https://github.com/jmckaskill/luaffi я бился бился ничего не получилось, все по мануалу автора делал неполучается
Там надо аккуратно разобраться с bat-файлом. В нём указаны абсолютные пути до lib-файлов и до lua.exe (на диск Z:) Эти пути надо просто поправить на свои. Кроме того, часть h-файлов генерируется тут же при сборке через lua-скрипты, опять же надо разобраться и все настроить, чтобы генерация отрабатывала (запускалась Lua.exe) и сделать.
Может вы лучше напишете какие API функции вам нужны? вот честное слово - не верю я в магию "функции в любой dll можно вызвать из lua через эту библиотеку". Где-нибудь да обязательно вылезет проблема, которую замучаешься разгребать.
ЗЫ Модераторы, выделите, плиз, сообщения про luaffi в отдельную тему. А то каша получается тут.
swerg написал: Я не вижу что там сейчас на картинке за код и ошибки.Приведите их здесь, пожалуйста. И полный ваш код.
Если кликнуть по картинке она увеличится, вроде на ней все разборчиво видно Вот полный код:
Код
// Hm512.cpp: определяет экспортированные функции для приложения DLL.
//
#define LUA_LIB
#define LUA_BUILD_AS_DLL
//
// Пример простой библиотеки на C++ для вызова ее из LUA
// http://quik2dde.ru/viewtopic.php?id=18
//
#include "stdafx.h"
#include <windows.h>
#include <process.h>
#include <hmac_sha512.hpp>
// в случае вызова функций из LUA-кода во внешней DLL
// необходимо определить эти константы до подключения заголовочных файлов LUA
extern "C" {
#include <lauxlib.h>
#include <lua.h>
#include <lualib.h>
#include <luaconf.h>
}
BOOL APIENTRY Hm512(HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
static int forLua_Hmacsha512(lua_State *L) {
const std::size_t l = 0;
std::string secret = luaL_checklstring(L, 1, l);
std::string params = luaL_checklstring(L, 2, l);
HMAC_SHA512 hmac_sha512(secret, params);
std::string d = hmac_sha512.hex_digest();
// помещаем в стек результат умножения
lua_pushstring(L, d.c_str());
return(1); // эта функция возвращает одно значение
}
// регистрация реализованных в dll функций, чтобы они стали "видимы" для LUA Hmacsha512
static struct luaL_reg ls_lib[] = {
{ "Hm512", forLua_Hmacsha512 },
{ NULL, NULL }
};
extern "C" LUALIB_API int luaopen_Hm512(lua_State *L) {
luaL_openlib(L, "Hm512", ls_lib, 0);
return 0;
}
Вот еще раз картинка, ошибки как раз в строках с номерами на картинках, все делал один в один с вашего образца, правда у вас там функция вызываемая из луа должна возвратить число, а мне надо строку текста, поэтому функцию возвращающую текст взял из примера на 1ой странице - https://quikluacsharp.ru/qlua-c-cpp-csharp/konnektor-dll-quik-qlua-lua-c/, нехватает еще знаний в Си конечно, учу...
swerg написал: Там надо аккуратно разобраться с bat-файлом.В нём указаны абсолютные пути до lib-файлов и до lua.exe (на диск Z:)Эти пути надо просто поправить на свои.Кроме того, часть h-файлов генерируется тут же при сборке через lua-скрипты, опять же надо разобраться и все настроить, чтобы генерация отрабатывала (запускалась Lua.exe) и сделать.
Пути есс-но правил все пути, это же очевидно, к папке с Zerobranestudio - c:\ZeroBraneStudio\bin\ к примеру, правил и lua.exe на lua52.exe в разделе
закидывал и соответствующие lib'ы в c:\ZeroBraneStudio\bin\ отсюда https://sourceforge.net/projects/luabinaries/files/ т.к. в комплекте с zerobrane они не идут, ( но может надо было не только либы а и все остальное - exe и dll? )
Все равно не компилится, тут уже надо копать глубоко Лучше уж сразу эту библиотеку себе скомпилить потом разберусь какие именно функции мне понадобятся, эта же библиотека встроена в LuaJit - т.е. если запускать луа-скрипты через луаджит то эту либу можно require'ить без проблем, но хочется иметь её отдельно
Если кому еще необходимо. Я бился над сборкой socket и ssl под x64. Вроде собрал, но как-то нестабильно оно работало. В итоге нашел готовые сборки, более стабильно работающие. А вот lCurl пока не удалось собрать под x64.
Nikolay написал: бился над сборкой socket и ssl под x64. Вроде собрал, но как-то нестабильно оно работало
У меня в ZerobraneStudio вообще не заработали твои бибилиотечки, зеробран ругается: C:\distr\ZeroBraneStudio\bin\lua53.exe: error loading module 'ssl.core' from file 'C:\distr\ZeroBraneStudio\bin/clibs53/ssl.dll': %1 ( Какие-то кракозябры) Win32.
Nikolay написал: Если кому еще необходимо. Я бился над сборкой socket и ssl под x64. Вроде собрал
Незаработали они у меня потому что собрал ты их строго под Луа 5.1, может будешь так добр что соберешь все это еще и под Луа 5.3?
А зачем под Lua 5.3? В Квике 5.1. Все это только ради Квика и собиралось. В этом весь смысл. Если под 5.3 и для сторонних скриптов, то, кажется, сборки есть готовые под 5.3.
Естественно что для 5.3 это уже не для квика надо, ненашел пока SSL 64 битного для луа 5.3, тебе же не трудно просто перекомпилить по 64 бита с луёвыми сорсами от 5.3 если у тебя уже проект готовый есть
Добрый день. Нет случаем у кого-нибудь Lua Sqlite3? пробую собрать проект в VS2017. исходники с lua.sqlite.org. убрал варнинги. поставил Lua 5.1.5 vc15 (другого не нашел поновее). остались ошибки типа "ссылка на неразрешенный внешний символ" в куче мест. видимо не подходит Lua.
пробовал с LuaRock, но со всеми плясками компилирует только x86, а не 64
Eldar написал: Добрый день. Нет случаем у кого-нибудь Lua Sqlite3? пробую собрать проект в VS2017. исходники с lua.sqlite.org. убрал варнинги. поставил Lua 5.1.5 vc15 (другого не нашел поновее). остались ошибки типа "ссылка на неразрешенный внешний символ" в куче мест. видимо не подходит Lua.
пробовал с LuaRock, но со всеми плясками компилирует только x86, а не 64
Мне удавалось скомпилить 64 и на luarock и в VS. Даже запускалось все в quik, но работало 1 минуту и падало вместе с куиком. Сами исходники написаны без учета особенностей 64 битной системы.
Пришлось на Lua написать небольшую библиотеку работы с текстовыми файлами как с таблицами.
Eldar написал: Добрый день. Нет случаем у кого-нибудь Lua Sqlite3? пробую собрать проект в VS2017. исходники с lua.sqlite.org. убрал варнинги. поставил Lua 5.1.5 vc15 (другого не нашел поновее). остались ошибки типа "ссылка на неразрешенный внешний символ" в куче мест. видимо не подходит Lua.
пробовал с LuaRock, но со всеми плясками компилирует только x86, а не 64
Eldar написал: Добрый день. Нет случаем у кого-нибудь Lua Sqlite3? пробую собрать проект в VS2017. исходники с lua.sqlite.org. убрал варнинги. поставил Lua 5.1.5 vc15 (другого не нашел поновее). остались ошибки типа "ссылка на неразрешенный внешний символ" в куче мест. видимо не подходит Lua.
пробовал с LuaRock, но со всеми плясками компилирует только x86, а не 64
Мне удавалось скомпилить 64 и на luarock и в VS. Даже запускалось все в quik, но работало 1 минуту и падало вместе с куиком. Сами исходники написаны без учета особенностей 64 битной системы.
Пришлось на Lua написать небольшую библиотеку работы с текстовыми файлами как с таблицами.
текст не вариант. мне тогда проще на ODBC переделать, либо на Mysql. все же с sqlite3 проще.
Меня попросили собрать luaCom для Квик 8. Собрал. Но тесты показывают, что Квик 8.0-8.4 падает, плюс что-то с кодировкой символов. Очень похоже на то, что было с luasql(ODBC).
Nikolay написал: плюс что-то с кодировкой символов
А чем компилировали? Нынче по стандарту сишные-плюсовые файлы должны быть в utf-8, соответственно gcc, например, строки так и воспринимает, а под квик надо в 1251. По-хорошему в utf-16 надо конечно, но тут луа со своими однобайтовыми строками выбора не оставляет.
Кстати говоря, когда приложение падает без дампа и без сообщения, тупо оп и нету, это обычно повреждение стека. С учетом, что без длл квик не падает, можно поглядеть на наличие/отсутствие __stdcall у чего-нибудь в либе. Это если отбросить уже совсем очевидные вещи типа бесконечной рекурсии и убитого стека "небезопасной" строковой функцией (а в либе ворнинги о них выключены, то есть по-видимому используются только так).
Nikolay написал: плюс что-то с кодировкой символов.
Таки дело не в бобине, взгляните в сорцы, файл tUtil.cpp, строки 111, 128, 171, 175. Возможно, список неполный.
Компилировал VS через nmake. Я не смотрел в код. Надо посмотреть значит, да. Правда то же, скомпилированное под Квик 7, работает, а у него utf тоже нет.
Nikolay написал: Я не смотрел в код. Надо посмотреть значит, да.
Заодно и в мейкфайл посмотрите, там кое-что генерируется из луа с помощью luac, получается *.lo, а потом с помощью bin2c из него получается *.loh. Так вот в мастере luacom5.lo уже лежит готовый. Очевидно, мейкфайл его пропустит (оставит как есть), а как есть он, сдается мне, 32-битный.
Nikolay написал: Я не смотрел в код. Надо посмотреть значит, да.
Заодно и в мейкфайл посмотрите, там кое-что генерируется из луа с помощью luac, получается *.lo, а потом с помощью bin2c из него получается *.loh. Так вот в мастере luacom5.lo уже лежит готовый. Очевидно, мейкфайл его пропустит (оставит как есть), а как есть он, сдается мне, 32-битный.
Это как раза было поправлено. Иначе ошибки линковки.
Впрочем, можете квик не насиловать, она даже под консольным луа падает на тестовом скрипте из поставки, откуда очевидно, что дело не в квике. Доходит вот докуда
Скрытый текст
Дальше мне рыть лень, это уже работа какая-то получается )
Nikolay написал: Если кому еще необходимо. Я бился над сборкой socket и ssl под x64. Вроде собрал, но как-то нестабильно оно работало. В итоге нашел готовые сборки, более стабильно работающие. А вот lCurl пока не удалось собрать под x64.
Пытаюсь подцепить socket к скрипту устанавливал библиотеку через luarocks, не заработало и ругается на разрядность Попытался использовать библиотеки по ссылке выше, пишет ошибку
Код
error loading module 'socket.core' from file 'C:\Lua\lua_socket_ssl\clibs_x64\socket\core.dll':
The specified module could not be found.
Код
error loading module 'socket.core' from file 'C:\Lua\lua_socket_ssl\clibs_x86\socket\core.dll':
%1 is not a valid Win32 application.
Замучился уже, как сокеты прикрутить к последней версии Quik? Хочу нормальный обмен данными сделать с внешними приложениями, а тут такая подстава Можно, конечно, написать библиотеку на С которая будет в свою очередь работать с сокетами и прочим, но надеюсь что обойдется
После многих часов мучений удалось все завести заработали модули luasocket и luasec работают https запросы
1) Выяснил, что когда собираются модули, то они линкуются к имени библиотеки, т.е. если собрать с линковкой к библиотеке lua51.dll то модуль не будет работать с библиотекой lua5.1.dll Это важно при сборке каких-либо пакетов из исходников, необходимо правильно указывать к какой библиотеке линковаться Quik использует lua5.1.dll, поэтому, там где есть линковка к библиотеке lua, то нужно проверить имя Если возникает ошибка The specified module could not be found. То нужно проверить что тот модуль собран с правильной линковкой
2.5) Перекинул библиотеки из "C:\OpenSSL-Win64-src\lib\VC" libcrypto64MD.lib и libssl64MD.lib в папку "C:\OpenSSL-Win64-src\bin" заменил в именах 64 на 32, это требуется для сборки luasec
2.6) Через командную строку Visual Studio x64 установил пакеты luascoket и luasec luarocks install luasocket luarocks install luasec OPENSSL_DIR=C:\OpenSSL-Win64-src
MikhaZz написал: Выяснил, что когда собираются модули, то они линкуются к имени библиотеки
Цитата
MikhaZz написал: Для линковки использовал эти библиотеки
На самом деле для линковки сама по себе длл вообще не нужна. Нужна соответствующая .lib, а в ней по сути только имя длл и секция EXPORTS без конкретных адресов. Поэтому у вас прокатывает фокус: линкуете с длл из луа, а в рантайме подгружается длл из квика. Можете сами посмотреть дампбином, адреса функций в них разные, а оно работает. Но лучше выдрать все же .lib из квиковской длл и линковать с ней.
Дальше все содержимое архивов скидывается в папку luarocks и уже все нормально собирается из командной строки Visual Studio x64 Т.е. можно исключить этап сборки lua из исходников
MikhaZz написал: Выяснил, что когда собираются модули, то они линкуются к имени библиотеки
Цитата
MikhaZz написал: Для линковки использовал эти библиотеки
На самом деле для линковки сама по себе длл вообще не нужна. Нужна соответствующая .lib, а в ней по сути только имя длл и секция EXPORTS без конкретных адресов. Поэтому у вас прокатывает фокус: линкуете с длл из луа, а в рантайме подгружается длл из квика. Можете сами посмотреть дампбином, адреса функций в них разные , а оно работает. Но лучше выдрать все же .lib из квиковской длл и линковать с ней.
Да, я понимаю что данные о том куда линковать в .lib содержатся, но не подумал о том чтобы по простому там имя подправить Я ни где нормальной инструкции не мог найти как заставить это все дело работать, пришлось разбираться Думаю, там где-то более хитрые зависимости есть, поэтому лучше брать правильные .lib файлы Самое главное, что меня смутило, это то что пробовал разные готовые сборки под х64, а они все равно не работали! Вываливалась ошибка "The specified module could not be found." Потом только дошло что проблема линковки и надо все пересобирать так, чтобы библиотеки модулей были прилинкованы к правильным библиотекам До кучи в пакетах luarocks уже готовые конфиги, по простому не изменить, из-за этого пришлось тоже повозиться
Еще пожелание В справке которая идет в комплекте в описании функции PrintDbgStr нет никакой информации о том куда осуществляется вывод, приходится дополнительно искать, хотя будь эта информация в справке, было бы сэкономлено много времени По хорошему, можно DebugView в папку с Quik положить или хотя бы ссылку на нее в справке
MikhaZz написал: но не подумал о том чтобы по простому там имя подправить
Там имя в каждом экспорте дублируется, руками править тяжко, проще заново сгенерировать .lib из переименованной длл. Пишете простой батничек
Код
@echo off
setlocal enabledelayedexpansion
for /f "tokens=1-4" %%1 in ('dumpbin /exports %1') do (
set /a ordinal=%%1 2>nul
set /a hint=0x%%2 2>nul
set /a rva=0x%%3 2>nul
if !ordinal! equ %%1 if !hint! equ 0x%%2 if !rva! equ 0x%%3 set exports=!exports! /export:%%4
)
for /f %%i in ("%1") do set dllpath=%%~dpni
start lib /out:%dllpath%.lib /machine:x64 /def: %exports%
и запускаете под visual studio command prompt (x64) с именем нужной либы. Генерируется .lib и .exp, второй можно сразу в корзину бросать.
Цитата
MikhaZz написал: лучше брать правильные .lib файлы
Конечно желательно. Вон тут недавно вопрос был про длл от стокшарпа, глянул в нее, а она к qlua.dll прилинкована. А этого нельзя делать, только к lua5.1.dll. В свое время написал небольшой хост, тксть недоквик для бедных, чтобы свои длл туда грузить и гонять под отладчиком, так вот если его линковать с квиковской qlua.dll, хост не завершается нормально, висит чего-то ждет, а с квиковской же lua5.1.dll все нормально. При том, что вторая таки подгружает первую и еще несколько квиковских длл.
Anton написал: Впрочем, можете квик не насиловать, она даже под консольным луа падает на тестовом скрипте из поставки, откуда очевидно, что дело не в квике. Доходит вот докуда Скрытый текст
Дальше мне рыть лень, это уже работа какая-то получается )
Да, увидел. Уже подумалось, что проще консольную программку написать, чем библиотеки насиловать. У меня почта так отпраляется и читается. Надежней.
MikhaZz написал: Еще пожелание В справке которая идет в комплекте в описании функции PrintDbgStr нет никакой информации о том куда осуществляется вывод, приходится дополнительно искать, хотя будь эта информация в справке, было бы сэкономлено много времени По хорошему, можно DebugView в папку с Quik положить или хотя бы ссылку на нее в справке
Здравствуйте!
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
С вашими архивами и вашим примером выдает ошибку "error loading module 'ssl.core' from file 'C:\Lua\systree\lib\lua\5.1\ssl.dll': Не найден указанный модуль" Путь правильный... В чем может быть проблема? Ткните носом плиз)))
Пытаюсь постепенно переходить на 64bit QUIK )) Имеется сложный фреймворк, связка lua с .dll , памяти занимает много, но выделение памяти контролируется.
Ранее .dll под 32bit компилировал в VS2013, работало всё на последней 32bit версии QUIK на слабом ноуте с 4ГБ памяти с процессором Intel (так же всё работало и на выделенном сервере)
Под 64bit компилируется на VS2017, версия QUIK 8.3.2.4 , работает на достаточно мощном ноуте, 12ГБ памяти, но с процессором AMD.
32bit вариант мог работать неделями, не закрывая квик, и работало зараз по 5-6 роботов, проблем не было совершенно.
64bit запустил одного робота, работает около часа, потом QUIK внезапно слетает, даже приблизительную причину аварийной остановки определить невозможно, т.к. не остаётся ни дампов , ни каких-то записей в моём логгере, т.е. причина останова, по всей видимости, очень серьёзная.
Вопрос1: была у кого-нибудь такая ситуация?
Вопрос2: может это быть как-то связано с особенностями процессоров AMD?
Когда программа (любая) падает мгновенно и без каких-то сообщений, даже под отладчиком, - была конечно, обычно это повреждение стека тем или иным способом. Конкретно по ситуации (переход с 32 на 64) я б первым делом включил все ворнинги в компиляторе и посмотрел, где происходит урезание 64 бит до 32 и где signed/unsigned mismatch в сравнениях, скорей всего откуда-то оттуда ноги растут. Смотрите сами: первые часы все нормально, потом что-то дорастает до 64 бит, не лезет в 32 и крэш. Про AMD я б в последнюю очередь думал.
Александр Волфовиц написал: Пытаюсь постепенно переходить на 64bit QUIK )) Имеется сложный фреймворк, связка lua с .dll , памяти занимает много, но выделение памяти контролируется.
Ранее .dll под 32bit компилировал в VS2013, работало всё на последней 32bit версии QUIK на слабом ноуте с 4ГБ памяти с процессором Intel (так же всё работало и на выделенном сервере)
Под 64bit компилируется на VS2017, версия QUIK 8.3.2.4 , работает на достаточно мощном ноуте, 12ГБ памяти, но с процессором AMD.
32bit вариант мог работать неделями, не закрывая квик, и работало зараз по 5-6 роботов, проблем не было совершенно.
64bit запустил одного робота, работает около часа, потом QUIK внезапно слетает, даже приблизительную причину аварийной остановки определить невозможно, т.к. не остаётся ни дампов , ни каких-то записей в моём логгере, т.е. причина останова, по всей видимости, очень серьёзная.
Вопрос1: была у кого-нибудь такая ситуация?
Вопрос2: может это быть как-то связано с особенностями процессоров AMD?
Я еще для 8.0 версии собирал ODBC драйвер. Падал почти сразу. Но... После общения с тех. поддержкой ARQA я попробовал записать дамп падения. Мне прислали утилиту, дающую возможность снять дамп при работе Квика - ForDump.
Так вот дальше стало все интерснее, при запуске этой утилиты Квик не падал. Без нее падает. Т.е. дамп не сделать - не падает ведь. А без утилиты дампа нет. Т.е. на лицо некая особенность обмена через стек при запущенной утилите.
Похоже без оптимизации библиотек под Квик x64 не обойтись.
Nikolay написал: Так вот дальше стало все интерснее, при запуске этой утилиты Квик не падал. Без нее падает.
А вот такое поведение характерно для косяков в межпоточном взаимодействии. То же самое вид сбоку: под отладчиком не падает, а без него падает. Более конкретно какой-то поток что-то выдергивает из-под носа у другого потока, отладчик/дампер все замедляет и ошибки нет.
Anton написал: где происходит урезание 64 бит до 32 и где signed/unsigned mismatch в сравнениях, скорей всего откуда-то оттуда ноги растут
unsigned переменных нет вообще, код написан очень просто. Я просто взял проект из VS2013, поместил в VS2017, открыл, пофиксил все ворнинги, на которые ругалась новая версия VS, переключил выход с 32bit на 64bit - и всё!
Т.е., отлично работающий код, с многократно пофиксиными багами на периоде 3,5 года, просто перекомпилирован на новую битность - и не работает!