Всегда - пожалуйста

Я написал свое предположение, почему раньше скрипты работали. У меня не стоит еще новая версия QUIK 8.5 и я не могу сказать точно, что именно изменилось, но общую причину я написал. Она состоит в том, что Lua может иногда корректно автоматически преобразовывать данные при сравнении в один тип. Ключевое слово "иногда".

Очень часто я чувствую себя также. Но меня спасает некоторая цитата:

Я уже встречал в сети посты о том, что и tostring у Lua 5.3 работает по-другому и нулей после точек много добавляется и т.д. и т.п. В общем, в похождении по этим граблям одиночества не наблюдается.

Стас пишет:

    Если коротко, то я имел в виду, что функция OnTransReply(trans_reply) в таблице trans_reply поле trans_id с 6 июля имеет тип number.

    А еще на прошлой неделе было вроде string

    Я прав или что-то напутал?

Здравствуйте, уважаемый Стас. Я заглянул в справочник по функции OnTransReply от ноября 2018 года, там числится поле

    Параметр        Тип            Описание
    trans_id        NUMBER        Пользовательский идентификатор транзакции

То есть, он всегда был числом типа NUMBER. Однако, при отправке транзакции функцией sendTransaction поле ["TRANS_ID"] должно быть числом, но типа STRING, иначе транзакция не будет принята сервером.

Может, Ваша история связана именно с этой особенностью...

Lua, иногда, может автоматически преобразовывать типы строки-числа при сравнении, но даже сам автор этого языка Роберту Иерузалимски пишет, что это было плохой идеей и не рекомендует пользоваться этим свойством языка, а всегда явно приводить типы к единому.

Здравствуйте, уважаемый pessimist.
Спасибо Вам за анализ и разъяснения.
Если тип trans_id всегда был NUMBER, то у меня нет другого объяснения, кроме как: "Я где-то напортачил, но не знаю где"
Почему у меня раньше корректно сравнивались числовое и строковое значение, а потом вдруг перестали.
Вроде ничего в этих местах не трогал.
Чувствую себя идиотом. 
Зря только людей беспокоил своей писаниной.:|

Если коротко, то я имел в виду, что функция OnTransReply(trans_reply) в таблице trans_reply поле trans_id с 6 июля имеет тип number.

А еще на прошлой неделе было вроде string

Я прав или что-то напутал?

Здравствуйте, уважаемый Стас. Я заглянул в справочник по функции OnTransReply от ноября 2018 года, там числится поле

То есть, он всегда был числом типа NUMBER. Однако, при отправке транзакции функцией sendTransaction поле ["TRANS_ID"] должно быть числом, но типа STRING, иначе транзакция не будет принята сервером.

Может, Ваша история связана именно с этой особенностью...

Lua, иногда, может автоматически преобразовывать типы строки-числа при сравнении, но даже сам автор этого языка Роберту Иерузалимски пишет, что это было плохой идеей и не рекомендует пользоваться этим свойством языка, а всегда явно приводить типы к единому.

Из опыта - лучше оба номера транзакции привести к типу NUMBER, потому, что при преобразовании в строку числа 695980319 - можно неожиданно получить что-то вроде "695980319.0000000" и это будут разные строки.
Все дело в том, что число может быть в QLUA представлено как STRING в поле одной таблицы и как NUMBER в поле другой.

А при сравнении чисел в типе NUMBER, даже если одно из них будет как 695980319, а второе 695980319.0000000 - QLUA поймет, что это один и тот же номер.

Такие случаи имеют место быть, когда лень заглядывать в справочник по функциям QLUA

То есть, если выполнить код в общем виде:

String_Number = "2"
Number_String = tostring(2.00000)

message(tostring(String_Number == Number_String))

Все получится и функция message выведет результат true

Но в QLUA можно запутаться, например, получая какое-либо значение из таблиц. В качестве примера возможной запутки приведу получение номинала ОФЗ из таблицы "Текущие торги". В поле номинал значение хранится так: "1000.0000".
Привычным значение номинала является 1000 рублей, а не 1000.0000 рублей.

Пример немного надуман, но я полагаю, что он даст немного наглядности той мысли, которую я пытаюсь выразить в этом сообщении.

ParamRequest("TQOB", "SU26205RMFS3", "SEC_FACE_VALUE")
Nominal = getParamEx2("TQOB", "SU26205RMFS3", "SEC_FACE_VALUE").param_value

Out_1 = "Приводим номинал к типу STRING : "..tostring(tostring(Nominal) == tostring(1000)).."\n"
Out_2 = "Приводим номинал к типу NUMBER : "..tostring(tonumber(Nominal) == tonumber(1000))
Out = Out_1..Out_2

message(Out)

При выполнении этого кода - первое сравнение tostring(Nominal) == tostring(1000) даст результат false, а второе tonumber(Nominal) == tonumber(1000) даст результат true

А еще на прошлой неделе было вроде string

Я прав или что-то напутал?

Перешел в 6й Квик.       
Один черт не работает.       

Запоминаю номера транзакций в таблицу sdelki в поле sdelki[j].sell_tr_number.       
Потом:       

function OnTransReply(trans_reply)        

    local t_id = trans_reply.trans_id    


    for j=1,#sdelki do    
        if sdelki[j].sell_tr_number==t_id then
                                     
                            --*****     действия    
        else        

        
        end        
    end        
end

выдает OnTransReply sdelki[7].buy_tr_number=695980319~=t_id=695980319       

Не признает равными номера.

Преобразовал в сравнении обе стороны в строки - заработало.

trans_reply.trans_id теперь имеет тип number

Раньше работало, видать был тип string

если сам квик 6 не отрубится, то, скорее всего, да.

Сделки на срочке прекрасно снимаются в шестом квике, как и прежде.

Зря я истерично все выходные в панике бегал по кругу, обхватив голову руками.))

На срочке всегда номера заявок и сделок были 64-х битные. Ничего завтра особенного не случится.

Хочешь сказать, что завтра робот, торгующий на срочке, написанный на lua и работающий в квике 6.*, будет работать как и прежде?

Я так понял, послезавтра на Мосбирже запустят систему с 19-значными номерами заявок и сделок на срочке?
Вчера чуть ни в 22-00 услышал об этом и в панике, истерично))) начал пытаться запускать что-то на последнем Квике 8,6+

Ибо нашел у себя в коде робота функции сравнения номеров заявок и понял, что на старом квике не прокатит.

Нашел следующие трудности:

1. Luacom не пашет. Использовал всего лишь как средство для диалога.
Типа реакция на щелчке по клетке таблицы: Сделать то-то? Да или нет?
Пока не понял как обойти.

2. Ругалось на номера транзакций при выставлении заяввки, откуда-то взялось дробное значение.
Поставил округление.

3. Ругалось на цену фьючерса при выставлении заявки, откуда-то взялось дробное значение.
Поставил округление.

4. Ошибка непонятного происхождения в старом ЛУА, которую я обошел когда-то заглушкой, перестала быть ошибкой и моя заглушка стала ошибкой в новом ЛУА).Поставил доппроверку, теперь работает и там и там.(Писал ранее.)

Вроде заработало, пока вижу еще мелочи с преобразованными в строку датами и временем, которые я вывожу в заголовок таблицы робота и в файлы csv, где я сохраняю данные, но это пока терпит.

С мандражом)) жду понедельника, ибо дотянул, похоже, до последнего.

В папке библиотеки и 5.1 и 5.3

Как бы библиотека про 5.1 лежит, но что она там делает- сами квиковцы не могут внятно ответить.
Так что по факту только одна Lua версии 5.3 присутствует в QUIK 8.5, 8.6 и далее.

Формально синтаксис языка не изменился.
Но есть некоторые нюансы, волшебно почти ни у кого не завелось, надо то тут, то там править нюансы.

Сразу остановился на ошибке.
Я начал смотреть и вспомнил, как отлаживал это место когда-то давно.
Никак не мог понять почему скрипт выдает ошибку в этом месте на Lua 5.1, ведь ее быть не должно.
В конце концов тупо поставил заглушку, которая устраняла непонятное действие.

Так на 5.3 стало выдавать ошибку на заглушке, без нее ошибка перестала выдаваться. ))

Но это был вспомогательный софт.
Теперь надо пробовать что-то со сделками. ((