1

Тема: Новая версия 8.5

Давно я не писал про новые версии, и вообще как-то упустил всё из вида.
А тут вышла версия QUIK 8.5, которая которая включает в себя новый интерпретатор Lua 5.3, где есть как само по себе много нового, так еще и все ранее собранные dll-библиотеки не работают. Надо опять всё срочно пересобирать...

Предыдущая тема про новые версии (по 7.5 включительно): https://quik2dde.ru/viewtopic.php?id=30

Постараюсь тут вести аналогичный топик про новые версии.
Вопросы, обсуждения новых версий - всё сюда.

2

Re: Новая версия 8.5

< reserved >

3

Re: Новая версия 8.5

< reserved >

4

Re: Новая версия 8.5

< reserved >

5

Re: Новая версия 8.5

не то чтобы мне обидно, но может хотя бы тогда объединить темы: https://quik2dde.ru/viewtopic.php?id=316 ?

6

Re: Новая версия 8.5

в общем, там на официальном форуме идет срач обсуждение, мое личное мнение - 8.5.1 это полное говно с недоделанной нерабочей lua настолько, что перепиливание под lua 5.3 очень затруднительно. надо ждать пока пофиксят.

7

Re: Новая версия 8.5

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

А здесь общая тема про нововведения новых версий в части языка Lua (чтобы в первых сообщениях вести лог изменений от версии к версии, чтобы было в развёрнутом виде видно что и как). Это касается не только 8.5 версии, но и последующих, заголовок темы будет обновляться.

Еще очень хотелось бы обсудить здесь что же нового в Lua 5.3 нам приготовлено, что доступно нового / полезного и т.п. Чем язык-о собственно отличается?

8

Re: Новая версия 8.5

язык? да примерно все то же.

5.1 -->5.2:
https://www.lua.org/manual/5.2/manual.html#8.1

5.2 --> 5.3:
https://www.lua.org/manual/5.3/manual.html#8.1

9 (2020-06-16 00:47:20 отредактировано Стас)

Re: Новая версия 8.5

Всем привет!

Ребята, чудной может быть вопрос:

Тут очнулся - говорят биржа переходит на 19 знаков, квики новые надо ставить, а я сидел до сих пор на 6 версии)), юзал скрипты на Lua в текстовой форме, сегодня вот поставил 8.6.0.97

В папке библиотеки и 5.1 и 5.3
И тут вопрос - если я запущу сейчас свой скрипт текстовой, он в 5.3 запустится?
Это никак не задается?

10

Re: Новая версия 8.5

Запустил старый скрипт на 8.6

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

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

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

11

Re: Новая версия 8.5

Стас пишет:

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

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

Стас пишет:

И тут вопрос - если я запущу сейчас свой скрипт текстовой, он в 5.3 запустится?

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

12 (2020-07-04 16:01:25 отредактировано Стас)

Re: Новая версия 8.5

Спасибо, swerg, за ответ.

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

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

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

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

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

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

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

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

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

13

Re: Новая версия 8.5

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

14

Re: Новая версия 8.5

toxa пишет:

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

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

15

Re: Новая версия 8.5

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

16

Re: Новая версия 8.5

Ставки приняты)

17

Re: Новая версия 8.5

toxa пишет:

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


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

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

18 (2020-07-09 17:53:24 отредактировано Стас)

Re: Новая версия 8.5

Перестало корректно сравнивать номера транзакций.       

Перешел в 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

19

Re: Новая версия 8.5

Стас, если честно - из вашего сообщения мало что понятно.
Переформулируйте, пожалуйста, в более простой и формализованный формат:
1) вот такие значения переменных
2) вот такой код - даёт такой результат
3) вот такой код - даёт вот такой результат
И вопрос по какому именно коду какой результат видится некорректным

20

Re: Новая версия 8.5

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

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

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

21 (Вчера 14:20:03 отредактировано pessimist)

Re: Новая версия 8.5

Стас пишет:

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

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

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

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

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

То есть, он всегда был числом типа 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