Все делается без шарпов на луа без проблем. -------------------------------------------------------------------------------------- Мы не ищем легких путей. Создадим себе трудности, чтобы потом искать того, кто их преодолеет для нас..
В ОБЩЕМ проблема не решена
Квиж жутко тормозит и набиваем массив
Освойте сначала луа а потом пишите на шарпе нет желания разбираться с вашей кашей.
где же каша ,вы в пару строк кода не можете разобраться поясняю
function qsfunctions.all_trades(msg) - // принимаю мессендж в нем название котировки local инструмент = msg.data .// инструмент =равен .например brx0 local count = getNumberOf("all_trades") // кол- во значений в таблице local t = {} -создаю массив for i = 1, count-1,1 do trades = getItem("all_trades", i) // получаю строку из таблицы all_trades if msg.data == "" or trades.sec_code == инструмент and trades.datetime.hour >= 10 then t[#t+1] = trades // заношу ее в массив end end msg.data = t //как только массив из all_trades заполнен // отправляю его в шарп. t = {} // очищаю массив return msg end =================== вернемся к моему вопросу, как мгновенно получить сразу таблицу обезличных сделок ?
В вашем случае никак. Передавайте записи в шарп, а не добавляйте его в отдельную таблицу. На это уходит лишнее время.
А это НЕ задание SP как числа - это всё тот же грёбаный "антиллехт"! Вот если написать: float SP=0; это было бы уже задание SP как числа! Не говоря уже про int SP=0; - о таком я и мечтать не смею!
Цитата
И наша рекомендация, на оборот, везде в индексах использовать числа, а не строки.
Блин, я ПЕРЕДАВАЛ! Ещё хуже! Только на строки надежда, ибо в Lua вообще ничего нет, кроме строк! Кстати, для интерпретатора это НОРМАЛЬНО! Между прочим, я вообще отказался передавать в таблицы Lua и числа, и строки -- язык путает ключи с индексами, а потому надежнее перебить все строки таблицы заново! Маразм? Конечно! А что делать?
слушай, хорош бредить...
Вот я же говорил, Владимир, человек не адекватный.
Владимир написал: Александр, А зачем там вообще double? Код заявки - ЦЕЛОЕ число! Эксперимент показал, что его разрядности достаточно. Какому дебилу понадобилось объединить int и float в идиотский number, да ещё и на уровне исполнения использовать именно float? Мало других способов поймать приключения на свою задницу?
Как бы по мягче сказать, что вы не разбираетесь в теме. Повторю в квике 7, lua 5.1 - в нем не числа хранятся типом double, соотвественно нельзя хранить int64. В квике начиная с 8.4 lua 5.3 - числа хранятся в int64 - все работает.
Цитата
В какую сторону копать, quik 7.6.1.1
Поняли? Я уже сомневаюсь в ваших способностях в чем-то разбираться.
Костя написал: function qsc.all_trades(msg) local sec_code1 = msg.data local count1 = getNumberOf("all_trades") local depo_limits1 = {} for i = 1, count1-1,1 do local depo_limit2 = getItem("all_trades", i) if msg.data == "" or depo_limit2.sec_code == sec_code1 and depo_limit2.datetime.hour >= 10 then table.insert(depo_limits1, depo_limit2) end end msg.data = depo_limits1 -- depo_limit2 =0 return msg end ========================= Написал такой код по образцам, он работает но очень долго
занимает от 1-мин до 10 000 скажи пожалуйста , как можно быстро получить всю таблицу обезличенных сделок не через Цикл , а весь массив уже распарсить на шарпе, как передать байты или Сразу все таблицу
например есть qscalp , у него занимает это 10 сек, как такое вообще сделать можно ? поясните пожалуйста
1. Qscalp - сделан на луа апи 2. Передача идет через FileMapping 3. Зачем создавать отдельную таблицы? Надо просто отослать строку в шарп. А лучше передавать всю таблицу в шарп, так быстрее получится. Время передачи до 2 мин., когда (> 1 млн записей) SearchItems - костыль и вам скорее не поможет, потому что вы не правильно данные отправляете.
Anton написал: Выделю в процитированном для привлечения внимания Цитатав каждый момент времени с луа работает либо мейн, либо колбек.
Хочешь сказать когда Квик в колбеке - майн стоит? Он же в отдельном потоке? Или там какая-то внутренняя кухня луа, не позволяющая одновременно двум стейтам из двух потоков работать?
Нет, в квике доступ к таблицам потокобезопасный. Соотвественно, если доступ к одной таблице может получить только один поток, другие будут ждать.
Христиан написал: Здравствуйте, хочу поставить Quik на VPS сервер чтобы работал там круглосуточно, волнует вопрос, как будет работать main() в отдельном потоке при наличии только 1 ядра? Все ли будет работать или нужно минимум 2. Поправьте если я чего-то не понимаю, спасибо
Потоки будут выполняться по очереди и не будет параллельности.
Владимир написал: Александр,Вам привести полный список всех классов и инструментов, чтобы не мучиться? :: Правда, я не собираюсь ковыряться нигде, кроме Сбера и ВТБ, да и облигации и прочее дерьмо меня не интересует - только акции. Лично я своим ПЕРВЫМ В ЖИЗНИ скриптом на Lua как раз проверил актуальность данных по классам и инструментам (при этом в Сбере из более двух сотен осталось менее одной, в в ВТБ из более полутора тысяч осталось менее полутора). Но если Вы не способны получить ДАЖЕ ЭТОГО, то стоит ли Вам вообще программировать?
У меня есть универсальный код, который получает список всех классов и инструментов. Вообще всех и в любых ситуациях. Судя по всему вам такого не сделать в принципе. И на этом заканчиваем. Вопросы, заявленные автором, актуальны.
Владимир написал: Александр,Вам привести полный список всех классов и инструментов, чтобы не мучиться? :: Правда, я не собираюсь ковыряться нигде, кроме Сбера и ВТБ, да и облигации и прочее дерьмо меня не интересует - только акции. Лично я своим ПЕРВЫМ В ЖИЗНИ скриптом на Lua как раз проверил актуальность данных по классам и инструментам (при этом в Сбере из более двух сотен осталось менее одной, в в ВТБ из более полутора тысяч осталось менее полутора). Но если Вы не способны получить ДАЖЕ ЭТОГО, то стоит ли Вам вообще программировать?
Дмитрий написал: чтобы понять, что данные актуальны их надо сравнить с другими данными, которые заведомо актуальны, а их нет, так как данные одни. Остаётся проверка по времени сервера или последней записи
Человек банально просить унифицировать все колбеки, чтобы не костылить. Чтобы было понятно, что например все символы, классы, фирмы, счета, коды клиентов и т. д. С фирмами вообще прикол, если они приходят то вызывается колбек OnFirm, а если уже загружены, то не вызывается. Один раз загрузись скрипт OnFirm вызовется, иначе нет. Коды клиентов могут быть пустыми и вообще от другого пользователя могут быть. Приколов может быть много. Собственно вот и описать схему работы прихода данных в хелпе вполне надо.
Если вы считаете что-то не алгоритмически невозможным, то это не значит, что оно так и есть. Скорее всего вы ошибаетесь.
Цитата
Владимир написал: Просто представьте, что Вы имеете ИДЕАЛЬНЫЙ язык
Вопрос не про язык, язык тут не при чем. Тут вопрос API - это вопрос разработчиков. Например, можно сделать кол-беки OnSecurity, OnClass - для получения инструментов и классов.
Цитата
Владимир написал: ОЙ, БЛИН!!! Так Вы берёте данные не их Квика, а получаете их каким-то "параллельным" способом?!
По-моему вы ничего не понимаете.
Цитата
Владимир написал: НАКОЙХЕР Вам этот "isConnected"?!
Я сам решу зачем мне isConnected. Вам объяснять не буду.
Цитата
Владимир написал: С таблицей всех сделок лично мне ВАЩЕ НИЧЕГО не понятно! На кой она нужна? Это ВАШИ сделки или НЕ Ваши? Если Ваши - храните их У СЕБЯ, а если нет - какое Вам до них дело?
Чтобы не падать при ходьбе, не надо мерить по себе. Если вы не понимаете зачем, значит вам не надо. Мне надо. Очевидно ведь. Потребности разные.
Цитата
Владимир написал: Проблема актуальности данных в терминале НЕ является насущной. Так что если вы не в теме, то лучше пройдите.
У людей бывают разные потребности. Так что если вы не видите проблему, займитесь своими делами.
Владимир написал: Александр,Простите, а вы ЧИТАЛИ, что он писал? Там нет НИ ЗВУКА про API, и даже я ему открытым текстом говорил, что НИЧТО не может обеспечить достоверность данных В ПРИНЦИПЕ! В том числе, ЛЮБАЯ утилита такой проверки! Это тупо НЕВОЗМОЖНО! Вот меня язык удовлетворяет далеко не полностью, но предъявлять претензии разработчикам, что "у косого брокера на букву Ф опять понос и посреди дня он медленно и печально начал перезагружать всю историю с 1812 года" просто нечистоплотно! ДА КАКОЕ ИХ СВИНЯЧЬЕ ДЕЛО?! Меняйте БРОКЕРА и отчепитесь от языка! Вот это будет вполне конструктивно! ::
Если приходят данные с 1812 года - то это проблема разработчиков и брокера. Язык тут не причем. Разработчик с брокером должны гарантировать, что данные в терминале являются актуальными, а если есть задержки в получении данных, то сообщить об этом.
Владимир, Вы превращаетесь с глупца с 40 летным стажем. Мы тут уже не один год пилим скрипты и просим это сделать. Из вопросов s_mike@rambler.ru вытекает, что они связаны с API терминала. Если вы это не поняли, это ваши проблемы. Уйти к другому брокеру увы не решение - терминал то квик. Вот пример, 1. при вызове isConnected - она сообщает о соединении с сервером, кол-бек OnConnected будет вызван позже. 2. символы не сразу загружаются а постепенно. И вообще много таблиц без колбеков - которые не загружаются разом, а приходят через некоторое время. 3. С лимитами не понятно. То брокер может удалить лимит и придет колбек. Такую ситуацию потестировать не возможно. 4. С таблицей всех сделок не все понятно, потому что данные по одному инструменту не всегда последовательны. 5. Проблема актуальности данных в терминале является насущной. Так что если вы не в теме, то лучше пройдите.
Владимир, Пользователь s_mike@rambler.ru не предъявляет претензий к ЯЗЫКУ. Он предъявляет претензии к API квика, которое не может обеспечить достоверность ДАННЫХ и хочет получить полную информацию об API и как при помощи данного API выяснить достоверность данных. Язык его полностью удовлетворяет. Меня тоже интересует вопрос, как правильно выяснить актуальны ли данные в терминале.
Владимир, Пользователь s_mike@rambler.ru поднял исключительно правильные и верные вопросы, на которые хочется услышать ответ. Ваши комментарии очевидно не к месту и мешают конструктивному диалогу. Я понимаю, что ответа в общем-то нет, но стремиться к этому надо.
s_mike@rambler.ru написал: добавляя в терминал язык луа, вы наверняка подразумевали , что на нем будут писаться разные роботы и прочая торгующая ерунда.
Вот у меня есть стойкое ощущение, что разработчики совсем не подозревали и не думали, что на lua буду писаться разные роботы и прочая торгующая ерунда.
Поэтому единственный способ решить ваши проблемы, это начать костылить и выносить всю логику во внешнее приложение.
Roman Azarov написал: Александр, Добрый день! Записи в Таблице Обезличенных Сделок действительно должны быть упорядочены.
Для детального анализа проблемы просим выслать архив рабочего места и скрипт, который вы используете, на почту нашей поддержки ( quiksupport@arqatech.com ).
На счет скрипта не понятно. Там у меня мой скрипт запущен, который написан на lua api? Вы его хотите?
s_mike@rambler.ru написал: обезличенные сделки отсортированы в пределах одного инструмента на уровне внутренней базы квика.
С этим и спору нет. Речь о том, что на клиентской стороне, благодаря фильтрам, флагу "получать с текущего момента" и шаловливым ручкам теоретически можно наколбасить по-другому.
Александр, а вот этим скриптиком можете экспортнуть? То же самое получится?
Код
local function save_ticks (cls, sec)
local f = io.open ( getScriptPath () .. '\ \' .. cls .. '.' .. sec .. '.' .. 'csv' , 'w' )
f:write( '<DATE>;<TIME>;<TRADENUM>;<PRICE>;<QTY>\n' )
local fmt = '%04u%02u%02u;%02u%02u%02u%03u;%u;%.6f;%u\n'
local function cmp (t)
if not t then
return nil
end
if cls = = t.class_code and sec = = t.sec_code then
local dt = t.datetime
f:write( string.format (fmt,
dt.year, dt.month, dt.day,
dt.hour, dt.min, dt.sec, dt.ms,
t.tradenum, t.price, t.qty))
end
return false
end
SearchItems ( 'all_trades' , 0 , 2000000000 , cmp)
end
function main ()
save_ticks( 'SPBFUT' , 'BRV0' )
end
Галочка нет на флаге "получать с текущего момента" Попробую сделать.
Использую для получения параметров таблицы текущих торгов функцию: getParamEx Для параметров BUYDEPO, SELLDEPO возвращается тип Long и вещественные значения = 24 074,40 и 24 641,44. Junior Quik версии 8.6.0.97. Это глюк или моя ошибка?
Александр написал: 1. В потоке обезличенных сделок: GAZP, BRV, SBER, RIZ0, SIZ0. 2. Создаю таблицу "Всех сделок" добавляю GAZP. 3. Жду загрузки 4. Удаляют из таблиц всех сделок, удаляю GAZP и добавляю BRV0 5. Жду когда загрузятся тики 6. Запускаю скрипт и получаю доступ к таблице all_trades через lua api. 7. Сначала выводятся сделки по BRV0 со временем 10:25 8. Потом идут сделки по BRV0 со временем 10:00 Получается в таблице all_trades - теряется порядок хронологии. Все остальные сделки идут верно.
никто и никогда не обещал, что в таблице обезличенных сделок будет какое то упорядочивание по времени.
единственное, на что можно полагаться с большой долей уверенности - что в пределах одного инструмента сделки будут отсортированы по возрастанию времени.
Как раз нет хронологии в пределах одного инструмента BRV0 (в примере) - а должна быть. Так полагаемся на хронологию в приделах одного инструмента. Номера сделок увеличиваются. Проблема в том, что идут номера большие, потом идут сделки с меньшими номерами. Брокер финам, версия среды 8.8.4.3
Roman Azarov, У меня там скрипты на lua api написаны. Давайте я понаблюдаю еще и возможно более точно вам скажу. Но я вам выслал на почту dumps после вылета квика. Возможно это другая проблема.
1. В потоке обезличенных сделок: GAZP, BRV, SBER, RIZ0, SIZ0. 2. Создаю таблицу "Всех сделок" добавляю GAZP. 3. Жду загрузки 4. Удаляют из таблиц всех сделок, удаляю GAZP и добавляю BRV0 5. Жду когда загрузятся тики 6. Запускаю скрипт и получаю доступ к таблице all_trades через lua api. 7. Сначала выводятся сделки по BRV0 со временем 10:25 8. Потом идут сделки по BRV0 со временем 10:00 Получается в таблице all_trades - теряется порядок хронологии. Все остальные сделки идут верно.
TGB написал: "По указанным номерам зафиксированных нами и указанных Вами инцидентов (CQ02750791, CQ02779753, CQ02787899. CQ02802279, CQ02809006) мы ведём активную работу и на момент данного ответа, вопрос о причинах утечки памяти и падения рабочего места остаётся открытым."
Там также написано: "Из перечисленных проблем: CQ02750791, CQ02779753, CQ02787899. CQ02802279, CQ02809006 открытыми остаются CQ02802279, CQ02809006, по остальным не найдены ошибки на стороне рабочего места QUIK." Подождем увидим.
Цитата
TGB написал: Почему простой тест не получится объясняется в тексте также по приведенной выше ссылке.
Да. Нативный Lua однопоточный. QLua многопоточный. Так же можете посмотреть пояснения по выше приведенной ссылке.
Честное слово. Вы написали некоторый черный ящик, который что-то там делает. Что делает не ясно? Что за тест - не ясно? Проверить правильность реализации теста мы конечно же не можем, потому что нет кода. И вы требуете, чтобы поправили ошибку и обвиняете разработчиков. Разработчики не должны разбираться в ваших тестах. Выложите исходники, а еще лучше напишите простой тестовый пример с исходниками, чтобы было понятно, что вы делаете. У меня есть чувство, что вы просто сами себе выстрелили в ногу и теперь бегаете и всем говорите, что вам очень больно. Почему то у меня ни одна программа, написанная на QLua не валится.
TGB написал: https://cloud.mail.ru/public/5iZb/2NSAPmJem - ссылка на мою тестовую программу (с кодами и инструкцией по ее запуску). Старая ссылка удалена. При запуске этой программы дампы возникают быстро (у меня в течении 5 минут), но в произвольные моменты. Эта же программа (с dll оттранслированными для Lua 5.1) непрерывно (месяцами) без проблем работает во всех версиях QUIK < 8.5. Одна из функций данной программы, которая включена сейчас по умолчанию, это тестирование автоматического управления памятью в QLua. Особенностью теста является высокая нагрузка (1500 обращений в секунду) на управление автоматической памятью QLua в условиях многопоточности. Можете также посмотреть обсуждение по ссылке https://forum.quik.ru/forum10/topic5119/?PAGEN_1=3 , начиная с комментария № 145.
Не очень понятно, что вы делаете за тест и результаты теста. Вероятно вам нужно упростить скрипт и выложить простой тестовый пример, избавившись от лишнего. Тогда станет более понятно. Изучать такой объем информации скорее всего никто не будет. Если вы хотите, чтобы быстрее исправили ошибку.
TGB написал: К сожалению, приходится наблюдать, как катастрофически падает профессионализм управленческих кадров в России, определяющих, что надо делать. ARQU вместо того, чтобы устранять ошибки версий 8.4…, улучшать функциональность, надежность и эффективность QUIK (и тут имеется широкие возможности), решила сделать маркетинговый ход и «поразить» пользователей переходом с Lua 5.1 на 5.3. Тут надо понимать, что функционально, с учетом архитектурно тесной интеграции Lua c языком C/C++, это, мягко говоря, сомнительный шаг, так как все, что не реализовано в Lua 5,1, по сравнению с Lua 5.3 (а это мало кому нужно), можно реализовать в языке C++. Кроме того, история с многочисленными проблемами реализации собственного, потокобезопасного управления автоматической памятью QLua 5.1, была, похоже, была проигнорирована. Вместо элементарной реализации в версии 8.4…. произвольной длины номеров заявок (> 19 знаков) был выбран нелегкий путь («нормальные» герои всегда идут в обход).перехода на Lua 5.3… (в котором существенно изменилось управление автоматической памятью и которое в QLua 5.3…, в отличие от Lua 5.3…, необходимо переработать так, чтобы оно было потокобезопасным). Необходимость потокобезопасности управления автоматической памятью QLua обусловлена тем, что все служебные функции обратного вызова QLua запускаются в потоке отличном от пользовательского (с именем main), но в среде (памяти) пользователя. Что мы имеем на текущий момент (12.08.20). Пользователи отлаживают, начиная с марта 2020г.все новые и новые версии (8.5…, 8.6…, 8.7…, 8.8…). Прошло уже 5 месяцев как нас кормят обещаниями стабильной новой версии QUIK. При запусках моего теста управления автоматической памятью во всех QLua версиях >= 8.5 в произвольные моменты времени, но в интервале 10 минут, возникают дампы ( все они пересланы мной в поддержку ARQU). Причем в QUIK версий < 8.5 проблем с управлением автоматической памятью QLua мной не обнаружено. Пока в версии >= 8.5 не будет реализовано корректное (пусть и не самое эффективное) потокобезопастное управление автоматической памятью версий QLua >= 8.5, QUIK будет нестабильным (надеюсь что разработчики QUIK это понимают).
Скажите а что за тесты вы выполняете? Можно эти тесты выложить, хочется тоже вопрос поисследовать.
Andrey Bezrukov написал: В приведённом Вами порядке эксперимента ни одно из условий не выполнено и OnCleanUp не вызывается.
В моем эксперементе произошло: 2. смена пользователя, которым выполняется подключение к серверу QUIK, внутри торговой сессии; Условие для OnCleanup выполнено. Я не правильно написал, в шаге 5 подключение другого пользователя. OnCleanup приходит, но таблица firms не обновляется через OnFirm.
Цитата
Andrey Bezrukov написал: Соответственно то, будет ли удалятся файл firms.dat при вызове OnCleanUp и будет ли очищаться когда-либо вообще - зависит от того, каким образом составлен Ваш скрипт.
Причем здесь мой скрипт. Если я запущу скрипт, то обновления в OnFirm придут. Если я переключусь с другим пользователем, то обновления не будут приходить, хотя для других таблиц будут (например, таблица всех сделок будет загружаться заново).
Функция обратного вызова OnFirm вызывается в том случае, если в рабочее место QUIK поступает запись о новой фирме, информации о которой ранее не было у терминала. При первом подключении рабочее место получает список фирм впервые и записывает их в файл firms.dat. Список фирм обновляется редко. Соответственно, при очередном подключении рабочее место не получает информации о новых фирмах, ввиду их отсутствия и, соответственно, OnFirm не вызывается. Но если новая фирма появится - то при запущенном скрипте вызов произойдёт.
Если происходит OnCleanup, то таблицы должны быть обнулены и данные о фирме должны быть снова записаны. В данном случае происходит событие OnCleanup, т. к. залогинился новый пользователь. Таблица firms должна быть очищена и записи обновлены в OnFirm. По-моему у вас должна быть такая логика?
На демо сервере junior quik не приходят обновления таблицы firms в колбек OnFirm при смене пользователя. 1. Запускаем скрипт. 2. Происходит подключение 1-го пользователя. 3. OnFirm - приходит. 4. Отключение 1-го пользователя. 5. Подключение 1-го пользователя. 6. OnFirm - не приходит. Это ошибка или особенность работы? Версия квика 8.2.
В общем, удаление позиций и лимитов происходит на сервере QUIK безусловно при смене даты торговой сессии с последующей их загрузкой брокером в течении дня, но кроме этого - брокер может сам в течении торгового дня удалить позицию. На сколько это распространено и практикуется ли Вашим брокером, выполняется ли это в соответствии с каким-либо конкретным расписанием - рекомендуется всё же уточнить у брокера.
Если сервер Quik удаляет лимиты при смене даты торговой сессии, то колбеки OnFuturesLimitDelete, OnMoneyLimitDelete, OnDepoLimitDelete не вызываются. Я правильно понимаю?
Прошу разъяснения при удалении лимитов из таблиц futures_client_limits, money_limits, depo_limits. Для этих таблиц есть колбеки OnFuturesLimitDelete, OnMoneyLimitDelete, OnDepoLimitDelete. Следующие вопросы: 1. Когда происходит удаление лимитов? После вечернего клиринга? 2. Последовательность удаления лимитов. Сначала удаляется из таблицы, а потом вызывается колбек или сначала вызывается колбек и после лимит удаляется из таблицы?
На демо сервере junior quik не приходит событие OnFuturesLimitChange. Таблица лимиты по фьючерсам изменяется, само событие не приходит. Это я ошибаюсь или так задумано?
Александр написал: 1. Можно ли сделать в квике режим (errorstop=true/false), чтобы luaL_error не останавливала скрипт, а выводила ошибку в окно "Ошибки выполнения скрипта" 2. Сообщения переданные в message с icon_type также отображались в окне "Ошибки выполнения скрипта"
Добрый день.
Как мы поняли Вы хотите именно сообщение в окне запуска скриптов выводит, в текущей реализации такой возможности нет. Только функция message() есть. Можем зарегистрировать пожелание на добавление функции вывода сообщений в основное окно запуска скриптов.
Александр написал: Сообщения об ошибках в этом окне более информативны.
Они дословно те же самые, что в окне сообщений, разве нет? Тут подмывает пошутить типа "а зачем вы пишете скрипты с ошибками", но я по-другому сформулирую: не первый раз вижу, что люди рассматривают ошибку в скрипте как один из допустимых путей. Это в корне неправильный подход, ошибка в скрипте - это конец, этого не должно случаться никогда, кроме как в процессе разработки. Там, где теоретически возможны ошибочные ситуации, надо или проверять возвраты функций, или использовать pcall (и в случае ошибки обязательно убеждаться, что поймали именно ожидаемую, а не что-то еще, прежде чем принять решение о продолжении выполнения), все остальное должно немедленно крэшить скрипт, потому что он неизвестно что делает. При этом есть еще направление "зачистка при ошибке", когда нам, в общем-то, все равно, какая именно ошибка случилась, наша задача сохранить консистентность внешнего по отношению к скрипту состояния, а дальше все тот же крэш. Вот с учетом всего изложенного ваш вопрос номер раз выглядит странно. А номер два - нормально, удобная фича могла бы быть.
Как раз есть проблема очистки после ошибки. Квик прибивает скрипт, в итоге после ошибки происходят утечки данных в самописных библиотеках.
Александр написал: чтобы luaL_error не останавливала скрипт
По дизайну lua_error не должна возвращать управление. Отсюда следует, что она сразу ломает (как минимум) тот блок, в котором была вызвана. Отсюда следует ответ, что продолжить выполнение с места вызова lua_error в принципе невозможно, блок уже сломан, состояние потеряно. Но вы сами можете поймать ошибку с помощью pcall и дальше уже решить, продолжать или нет.
Могу поймать, но тогда нет возможности вывести сообщение об ошибке в окно "Ошибки выполнения скрипта". Сообщения об ошибках в этом окне более информативны.