Судьба SearchItems()?

[Arech]

Привет!

Думал вот, как обеспечить выдирание всех обезличенных сделок по инструменту с начала сессии (OnAllTrades() ведь передаёт только новые сделки, пришедшие в данный момент, поэтому если подключился позже, то более старое с утра надо вытаскивать отдельно)... Решил, что из всего родного апи SearchItems() выглядит наиболее подходящей, однако оказалось, что она не реализована во фреймворке.

Можно поинтересоваться, что стало причиной, что функция не реализована? Что можно использовать вместо неё для решения задачи?

Предположу, что это может быть связано с проблемой с указанием колбека? Не пробовали функцию колбека регистрировать с самого начала загрузки модуля через static struct luaL_reg ls_lib[] и передавать её название в качестве параметра?

[elelel]

Точно не помню, но вроде финальной причиной, помимо интерфейса функции, почему я не стал ее доделывать, было то что оно получается медленней, чем сначала выкачать все имеющиеся данные в свой нормальный дата-сторадж (синхронизация), а потом использовать OnAllTrades для обновления новыми событиями. Поиск, фильтрацию и так далее проводить уже по своему нормальному дата стораджу. То же, кстати касается работы с графиками. Операции над свечами через родные функции я также дописал из-за того что было время и просили, иметь дело с ними дороже, чем иметь дело с данными и рисовать свечи самому. И с рисованием gui таблиц, тоже, стоит дважды подумать, чем пользоваться как-либо серьезно их функциями. Если мы выходим в C++, в реальном продакшене проще и качественнее по результату рассматривать Quik как источник данных и получатель сайдэффект команд (выставлять заявки, например), остальное писать без использования склеек с Lua.

[Arech]

Ага, понятно, спасибо, ценная инфа.

сначала выкачать все имеющиеся данные в свой нормальный дата-сторадж (синхронизация)

А вот как это сделать? Неужели по одному элементу через GetItem()?

[elelel]

В первый запуск да, или, если была пауза или другое подозрение на пропуск за период. Инкрементально перебирать по индексу в рейндже индекса элемента таблицы. Далее - по ивентам коллбеков обновлять, если этот тип таблицы поддерживает обновление по коллбекам.

[Arech]

Хм... охужэтотквик.... понятно, спасибо. зы: Думаю попробовать проапгрейдить кое-какие моменты реализации luacpp/qlua. Если тесты покажут полезность, могу запулить в общий реестр. Какие-то особенные требования к пулл риквестам есть?

[elelel]

Главное требование - чтоб оно имело смысл :)

[Arech]

рационале будет, ну а дальше уж Ваша рука-владыка) Ок. добро.

[Arech]

Думаю попробовать проапгрейдить кое-какие моменты реализации luacpp/qlua. Если тесты покажут полезность, могу запулить в общий реестр.

Пока существенного отличия от бейслайна не увидел, так что тут пока ничего.

Хотел ещё вот о чём Вашего мнения спросить - а что-нибудь известно о том, можно ли вызывать функции квика (ну, ту же GetItem() для таблицы всех обезличенных сделок) из других (не созданных квиком) потоков? (не тех, в которых работают все колбеки On*() и не того, в который выносится main(), а созданных самостоятельно через условный ::CreateThread() ?) Если квик использует какой-нить thread local storage для каждого из своих потоков, это хорошо если приведёт сразу к падению, а не к недиагностируемым косякам...

[elelel]

Нельзя; также я не нашел стопроцентно безопасных способов синхронизации с потоками квика кроме:

• Использования lock-free структур при копировании в данные своего треда (см. пример с логингом сделок)
• Использования предиката функций поиска квика для исполнения своего кода под родным локом CriticalSection (см. https://github.com/elelel/qluacpp/blob/master/src/qlua/extended/quik_thread_safe.hpp)

[Arech]

Ооого... Вот это я вовремя поинтересовался. Про локфришную очередь в логгинге видел, да, но думал, это по соображениям перфоманса сделано... Спасибо больше за ценные уточнения. Копаю вюндерквик дальше :grin: зы: на удивление, remote debugger из msvc2015 даже коннектится удалённо, даёт ставить бряки в длл, и на первый взгляд вполне даже работает...