Средства разработки многопоточных скриптов в QUIK.

Целую страницу постов а-ля "нинужно, кг/ам" нафлудили. Вам нинужно, а кому-то может интересно будет. Та же is-odd.js как ни абсурдно имеет астрономическую популярность (справедливости ради, широта языка не распологает к инлайн-исполнению таких вещей).


Вопрос к автору: какой такой сценарий в контексте брокерского торгового терминала предпологает "некоммерческое" использование?

Создаешь с помощью вашего фреймворка робота который будет торговать и зарабатывать деньги - тут налицо коммерческое использование. Логически, любая утилита для торгового терминала по-умолчанию будет использоваться коммерчески так как у торгового терминала есть только коммерческий функционал.

qlua.dll без исходников предлагается

qlua.dll - это библиотека, неотъемлемая от терминала. Так что ее можно считать частью среды исполнения.
Я же говорю о библиотеках реализующие часть функциональности, которую можно реализовать самому. Предпочтение будет всегда тем, которые имеют открытый код.

Владимир, как угодно. Можете доверять чужим рукам.

Если id  транзакции предполагается в дальнейшем использовать как ключ, то необходимо обеспечить его уникальность. Хоть рандомизация и повышает вероятность уникальности, но не обеспечивает ее в полной мере.
Чаще всего используют производные от unix-time как ключ транзакции. Но при этом надо еще подумать об уникальности между скриптами, т.к. вероятность отправки транзакции двумя скриптами одновременно есть.

  Робота вы можете создать и использовать его сами для зарабатывания денег, но не можете зарабатывать на торговле самими роботами.

TGB, Это не проблема: результаты у меня по выходу записываются в файл, а по запуску читаются, так что можно этот счётчик сбрасывать и потом читать - прямо как оператор Lua через loadstring. Я так и делаю для сумм свободной налички по валютам, номера счёта, кода клиента и ещё для чего-то. Только ведь это стандартнейшая операция! Это же делают все без исключения! Неужели нет чего-то без сохранения? Примерно такого, чего я ожидал от math.random. По-нормальному это вообще должно бы быть возвращаемое значение, как с файлом или диспетчером памяти: возвращаем дескриптор - и всё!

Игорь М, Угу, сенькс Я бы и использовал, но первым напоролся на random, и уж такой подлянки я от него, конечно, не ожидал.  

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

Артем, Мало, что ли? Когда я пользовался датчиками случайных чисел, они всегда у меня были 16-разрядными (правда, алгоритм генератора был "совершенный" - два алгоритма генерации псевдослучайной последовательности в случайные моменты времени перещёлкивались друг на друга). А иногда требуется как раз "случайность без случайности" - например, когда я генерил графы для задачи коммивояжёра (с равномерным распределением и с иерархической кластеризацией), то во втором случае у меня была чистая случайность, а вот в первом последовательность "начиналась каждый раз с одного и того же числа", то есть каждый граф большего объёма содержал в начале любой из меньших. Генерил графы от 3 до 123456789 узлов,, проверял - НИ ОДНОГО повтора координат! А здесь что? Обеспечить уникальность транзакций за одну несчастную сессию? У меня их несколько десятков. Ну, сотен - курам на смех! И самое главное - почему обеспечение уникальности идентификаторов транзакций ложится на юзера? Ведь для Квика это просто порядковый номер строки в его таблице - даже искать ничего не надо! Так не проще ли сделать ID=sendTransaction, а в случае неудачи возвращать 0? И волки целы, и овцы сыты.

BlaZed, Во, блин! Что ещё за dt? И что лучше, dt или os.time?

Ага, понятно. Не, я, скорее всего, буду счётчик инициализировать на старте системным временем, а потом инкрементировать и по выходу не сохранять. В общем, так, как подсказал Игорь.

Посмотрел я сейчас на свой код в плане того, чем я пользуюсь из предоставленных возможностей. Картина такая:

1. Файловые операции (open, close, write) - претензий нет. Ну, вместо read сидит какой-то F:lines(), но работает. Не видел, правда, seek, но я его и не искал, он мне не нужен. getScriptPath тоже работает.

2. Работа со строками (find, sub) - претензий нет. Особенно хорош string.format - благо, передран один в один из sprintf.

3. Прерывания (коллбеки). Использую только OnStop и OnTrade как минимально необходимые. Глючат оба: у первого иногда пропадает управление, у второго прерывания приходят пачками. И то и другое вылечил, пользуюсь. Кстати, у меня четверть, если не треть всего кода написана именно для компенсации разных глюков именно поэтому я пользуюсь чистым Lua и крайне неохотно включаю любые "библиотечные" возможности.

4. Работа с окнами (AllocTable, AddColumn, Clear, CreateWindow, DestroyTable, InsertRow, SetCell, SetColor, SetTableNotificationCallback, SetWindowCaption, SetWindowPos). Глючат все (именно обращение к ним в OnStop вызывает потерю управления). Охренел в своё время от необходимости вызова этих функций именно в определённой последовательности, иначе "просто не работает". Вылечил, пользуюсь, терпимо. DeleteRow вообще выкинул нафиг, а редко встречающееся полное исчезновение текста в ячейках таблице лечу по клавише Enter.

5. Преобразование типов (tonumber, tostring) - претензий нет. Но за динамическую типизацию, замену операций булевой алгебры на убожество типа bit.band руки-ноги бы повыдёргивал разработчиком! А уж за убийство типа integer... ТАКОГО маразма я ещё не встречал ни в одном языке - Lua первый!

6. Работа с таблицами (getItem, getNumberOf, getParamEx). Коряво, но работать можно. Первыми двумя пока ещё не пользовался - они нужны только для снятия заявок, для работы только с таблицей "orders", чтобы не использовать глючного OnOrders.

7. Библиотеки. math.random приказал долго жить (вместо него, видимо, появится os.time), а math.floor использую в функции обрезки концевых нулей после запятой (идею подсказали на этом форуме). Убей, не понимаю, что он делает, но работает прекрасно!

8. Стандартные конструкции: с message вопросов нет (alert - он и в Африке alert), sleep используется обычным образом в main (150 мс - при этом задержки реакции на мышку и клаву почти незаметны), а на работу (отсутствующей в описании языка) loadstring просто не нарадуюсь!

Общая оценка: удовлетворительно.  

Вопрос уникальности транзакции обычно возникает в свете поиска ответа на транзакцию и установленного ордера по ней, сделок.
Обычно делают номер как unix_time + mcs*1000. Также скрипт пишет в поле brokerref свой уникальный комментарий. Или, как выше написали, есть некая добавка от номера скрипта.
Я предпочитаю brokerref, т.к. он идет сквозным образом от транзакции в ордер и сделки.

Вместе это дает уникальность при дальнейшем использовании номера и brokerref.

Я уникальность обеспечиваю фиксированием момента времени включения скрипта, а не совершения транзакции. А уже дальше, если в скрипте есть сделка, то как обычно, к полученному случайному числу +1.

Не думаю, что у Вас получится в один и тот же момент включить несколько скриптов.
os.time() у всех будет разный, а соответственно math.randomseed(os.time()) и ....

Если робот работает в личной инстанции QUIK то можно взять Process ID из операционной системы, нормализировать по длине, и к нему спереди приклеивать порядковый номер транзакий и т.п. Альтернативно, можно брать адрес его функции main - для разных роботов (из разных файлов) он будет разный.

Делать ставку на то что маловероятное событие НИКОГДА не произойдёт - плохая тактика. Владимир уже на своем опыте об этом знает.

BlaZed, Но ведь Артём говорил про теоретическую возможность. У меня скрипт, возможно, никогда не выдавал более 100 транзакций за сутки, но теоретически он способен за один вызов полуторасекундного обработчика послать заявки на покупку или продажу ПО ВСЕМ тикерам, за которыми он следит, а таковых у него сейчас более тысячи. Конечно, вероятность подобного почти равна нулю, но всё же только почти.  

И по теме (описание интерфейсных функций OS_Quesha):
 5.3 Создание последовательности ключей
Последовательность ключей это функция, при обращении к которой выдаются значения некото-
рого типа, уникальные в некотором контексте их использования. Дополнительным требованием
(кроме уникальности значений), в некоторых случаях использования таких функций, может быть
необходимость формирования их значений по определенным правилам.
В качестве примера использования последовательности можно привести создание идентифи-
каторов заявок при их выставлении в QUIKе с помощью функции sendTransaction.
1. Запрос последовательности ключей (number):
Cl_LuaGL ()
Результат функции: number - глобальный ключ системы формата: <Номер запус-
ка/перезапуска системы >(старшие, оставшиеся разряды, начиная с 6-го )<Счетчик запросов
ключей после запуска/перезапуска системы>(6 десятичных разрядов)
Эта функция при обращении из любого потока (функции скрипта), выдает значение отличное от всех ранее ее вы-
данных (независимо того, были запуски или перезапуски системы).

Комментариев обсуждения функции cоздания последовательности ключей я насчитал более двадцати. Это одна из самых простых функций из списка API  OS_Quesha, оглавление описания которого в документации приводится ниже.
1. Вывод сообщений.
2. Работа со временем.
3. Создание последовательностей ключей.
4. Создание среды функционирования разрабатываемого робота.
5. Взаимодействие потоков.
6. Обеспечение явной синхронизации потоков.
7. Работа с таймерными событиями.
8. Работа с контрольными точками.
9. Работа с фоновыми заданиями.
10. Обеспечение отладки функций и взаимодействия потоков.
11. Разное.
   Примером простой (классическая задача на рекурсию), но, наверное, полезной функции из раздела 10 является универсальная функция печати переменных dump_str. Она может быть использована в тексте программ для вывода любых переменных (и таблиц произвольной вложенности) Lua.
  Ниже приводится код функции, которую можно использовать автономно (может быть кому то окажется полезной):


 В диалоге OS_Quesha, в процессе ее работы, функцию dump_str можно вызвать в любой момент для любой глобальной переменной скрипта с тем,  чтобы распечатать ее с выдачей в журнал отладки. Например, у меня контекст Lua (переменная _G) выводится (это ~5000 строк) за 20 млсек (по поводу скорости вывода жду комментария Владимира ).

Это довольно распространенный вариант на просторах. Вы попробуйте им вывести Класс или таблицы с перекрестными ссылками.

В этом проблема. Кеширования ссылок нет.

Снимаю замечание. Не увидел изначально переменную seen. Обычно этот вариант не содержит ее.

  В том как я предложил вам собирать строку профита нет. Профит есть при использовании специальной быстрой C-функции сборки строки из массива строк (тоже из API, но С-пакета, который пришлось бы устанавливать).
  Если собирать без профита, то при выполнении операции  <строка1> = <строка1> .. <добавляемая строка>  в Lua всякий раз выполняется отказ от предыдущей памяти <строка1> и запрашивается новая память под новое значение <строка1>.  В быстрой C-функции сборки строки на C++ реализована эффективная динамическая строка, в которую последовательно добавляются <добавляемые строки> вообще без описанной мною в предыдущем предложении нагрузки на автоматическое управление памятью.

торОпитесь....

 Спасибо за нетривиальные примеры для тестирования.

local str = ""    
for k,v in next, dump_tbl ({ [ {"xx","yy"} ] =5}, " ", 0) do str = str .. v end РЕЗУЛЬТАТЫ теста (в квадратных скобках индексы таблиц)
MessageDlg ( 1, 1, "Скрипт", " Результат: \n" .. str)                                             Результат: [table: 0F4ED2F0] (number) = 5
-------
str = ""    
for k,v in next, dump_tbl ({"a\0b"}, " ", 0) do   str = str .. v  end
MessageDlg ( 1, 1, "Скрипт", " Результат: \n" .. str)                                             Результат: [1] (string) = a
MessageDlg ( 1, 1, "Скрипт", " Результат: \n" .. "a\0b")                                        Результат:  a   ---
message ("a\0b")                                                                                                Результат:  a
-------
str = ""    
for k,v in next, dump_tbl ({math.huge}, " ", 0) do   str = str .. v  end
MessageDlg ( 1, 1, "Скрипт", " Результат: \n" .. str)                                             Результат: [1] (number) = 1.#INF
message (tostring(math.huge))                                                                            Результат: 1.#INF
-----------------------------------------------------------------------------------------
 Я ошибок не нашел. Где они?

 Согласен. Пользоваться не стесняюсь. Сайт хороший.