Отладка QUIK 8.13

TGB, А разве что-либо где-либо когда-либо бывало  реализовано корректно?   Здесь всё-таки операции с деньгами, и мне казалось, что уж здесь-то должна быть высочайшая надёжность. А оказалось, я стал опасаться ЛЮБЫХ изменений. Не бывает таких ситуаций, чтобы нельзя было сделать ещё хуже.

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

  Вы до сих пор не поняли, что важная задача решена. Почитайте эту ветку начиная с начала ни чего не пропуская. Возможно у вас что-то проясниться. Если нет, задайте мне вопрос и я вам разъясню.

TGB, судя по всему не было.

https://forum.quik.ru/messages/forum10/message54811/topic5823/#message54811

TGB, прочитал логи изменений на обоих языках, ничего про такого рода ошибки не увидел.

TGB, между официальной документацией и "мне так кажется" от рандома в интернете, выбор несложный.

  Здравствуйте!
В комментарии 50 собраны оба предложения. Просьба их рассмотреть.
Если у вас будут вопросы, то постараюсь на них ответить.

Артем, Сударь, Вы решительно надоели своей назойливой тупостью. С Вами разговаривать не о чем, Ваша "квалификация" многократно подтверждена здесь Вами же. Так что НЕ ВАМ определять "весомость аргументов"! Нижайшая просьба: заткнитесь по-хорошему, а?  

TGB, изестный интернетный феномен - когда кто-то несет чушь, люди хотят такое недоразумение исправить. Когда предъявляют исходники или дизассемблер или хотя бы логически жёсткую цепочку, тогда есть разговор. Когда говорят "ну у меня вот в моем игрушечном стенде все работает" и удобно игнорируют то что у других людей проблемы никуда не делись - это чушь. Впрочем вы товарищ скатываетесь в такой же уровень самоуверенной шизофазии как Владимир так что вас тоже скоро буду игнорировать наотрез. Если вдруг забыли, напоминаю что по вашему-же умозаключению мои навыки и/или познания гораздо превосходят ваши.

  Вы что, шуток не понимаете?  

TGB, Какие шутки с такими комплексами? Вот, например:

Легко наверное жить когда уровень ЧСВ еще выше чем уровень IQ. Когда нейронный робот запустится, я с вами поделюсь данными о монетарной производительности.

TGB, добрый день!

Оба пожелания зарегистрированы, мы постараемся их рассмотреть. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожеланий в будущих версиях ПО.
Каких-либо сроков назвать не можем. Как будет результат анализа пожеланий, мы сообщим Вам в данной теме.

Roman Azarov, если будете это реализовывать, то предлагаю сделать возможным задавать не только отдельно функции, но и библиотеку целиком, например math.

3) Предложение3. Дать скриптеру возможность самостоятельно устанавливать/снимать блокировку в любом месте пользовательского кода, если такое возможно.

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

* любая функция QUIK
* любая функция Lua (все библиотечные функции + pairs, next, getmetatable и т.п.)
* любая функция из внешней DLL
* любая операция со строковым результатом
* любая операция по созданию новых объектов

  Согласен.  Интерфейс должен быть полным, обеспечивающим все необходимые операции пользователя, но максимально простым и ясным. Он должен минимизировать ошибки пользователя и облегчать сопровождение QUIK разработчиком.

Артем, Лапуль, Вы ещё и по интерфейсам спец?    Информирую Вас, что я ЛИЧНО могу предложить интерфейс, как минимум, вдвое легче существующего, что только бездарям  тупорылым нынешний интерфейс может показаться "минимальным, слишком скудным и с неполным покрытием", им ВСЕГДА чего-то не хватает, им ВСЕГДА хочется что-то "расширять и углублять". В результате ЛЮБОЙ софт засирается так, что знаменитые Авгиевы конюшни выглядят на этом фоне чуть ли не благоухающим садом! Лапуль, у меня за плечами ДЕСЯТКИ диалоговых программных комплексов! А Вы разработали хоть один, умник? Какой тут, в задницу, могёт быть "функционал"? И Вам ли вообще говорить о функционале? Напоминаю, что я на этом форуме единственный, кто пишет на чистом Lua и я УЖЕ написал всё, что изначально планировал. У меня УЖЕ РЕАЛИЗОВАН весь этот грёбаный "функционал", да ещё такой, какой Вам с таким подходом не написать НИКОГДА! На данный момент это 16 (прописью: ШЕСТНАДЦАТЬ!) функций, включая main и все коллбеки, общим весом 18968 байт. И работает, падла! И КАК работает!  

Артем, А Вы, сударь, чем здесь всё это время занимаетесь? Неужто мешки ворочаете?

Ещё до Вашего появления здесь я предлагал обсудить как интерфейс Lua-программиста, так и организацию диалога (также на Lua) для конечного пользователя. Тогда эти предложения благополучно издохли. Уже потом я получил более убедительные сигналы, что задачи у разработчиков софта и их клиентов диаметрально противоположные: вторым нужна стабильно работающая версия, а первым - бесконечный выпуск всё новых версий. Ну, а на повизгивания распальцованных неучей чего-то там "в студию" мне много лет пилювать с высокой колокольни.

Артем, Лапуль, покопайтесь в моих давних сообщениях, если интересно - мне лень ковыряться по "запросам" очередного распальцованного неуча. И я, в отличие от некоторых, отвечаю ЗА ВСЕ свои слова!  

swerg, А в чём Вы кайф понимаете, лапуль? В тяфтяфках из подворотни? У головожопых только две версии для "оправдания" своего поведения: "медицинская" и (гораздо более тупая и, соответственно, более популярная) версия "ржача". Вы, как вижу, перешли во вторую? Мы ведь давно с Вами во всём определились, а Вы всё никак не успокоитесь. Я понимаю: морды битые, отыграться хочется, но добавлять-то зачем? Вы же ЗНАЕТЕ, что по делу возразить ничего не можете - остаются тяфтяфки. Ладно, повожу малёк носом по нашим предыдущим разговорам, когда Вы еще " понимали кайф мазаться об говно":

Скрытый текст

Скрытый текст 04.10.2020 19:42:05 swerg, Я уже дважды вопрошал в этой ветке: "КАК ИМЕННО Вы будете контролировать актуальность данных даже на ИДЕАЛЬНОМ API? Не знаете? А что же тогда докопались до разработчиков?"  НЕ МОЖЕТ быть такого способа! НЕ МОЖЕТ! В ПРИНЦИПЕ не может! Скрытый текст 27.10.2020 11:08:32 swerg, Вот он я "такой программист". 40 лет вхожу внутрь блоков if, и горя не знаю  Программы бывают чуть посложнее, чем a=b+c; Скрытый текст Скрытый текст 27.10.2020 12:14:23 swerg, Так программы ПО ФУНКЦИОНАЛУ СВОЕМУ бывают посложнее!  Не только торговые погремушки. Скажу больше: без входа внутрь блоков if или внутрь циклов goto И В САМОМ ДЕЛЕ нафиг не нужен. В частности, вот это убожество: кто его использует - поднимите руки! Скрытый текст Скрытый текст 28.10.2020 10:38:37 swerg, Врать - нехорошо   Это насчёт "не читает". Что до другого тезиса, так я давным-давно... Скрытый текст Скрытый текст 30.10.2020 22:51:55 swerg, Чушь. Кто именно и с какого бодуна вдруг станет "брать скрипт" и, тем более, "начнёт него дергать колбеки по мере поступления событий". Как этот "кто-то" вообще узнает, что нужно делать? Как узнает, где там "колбеки"? По фиксированным именам? Кто вообще сказал, что скрипт запрашивает колбеки? Может, они ему нафиг не нужны. Скрытый текст Скрытый текст 31.10.2020 12:35:26 swerg, Может, хватит, господа?  Сначала один нёс какую-то клиническую ахинею про "роботов и всякие прочие глупости", да ещё с гнутыми пальцами вроде "вы даже понимаете суть вопроса". Получил щелчок по носу - теперь чего-то шипит про "троллей". Потом второй начал пальцы гнуть на тему API в том же ключе: "По-моему вы ничего не понимаете", да про int-float ("Как бы по мягче сказать, что вы не разбираетесь в теме. Повторю в квике 7, lua 5.1 - в нем не числа хранятся типом double, соответственно нельзя хранить int64"), да про "не надо путать стек процессора и стек Lua - это разные стеки. Вам бы документацию почитать и хорошенько разобраться в луа", да про "выучи английский", да про "умение читать документацию и гуглить", после чего вообще забился в истерике. Потом третий понёс пургу про "монстров фондового рынка", и тоже с гнутыми пальцами: "Вы еще далеки от понимания реальности фондовых рынков" и совсем уж клинический бред с ещё большей распальцовкой: "вот некоторые из аксиом, которые надо усвоить и научится программировать", затем бред про мантиссы ("для справки: Разрядность мантиссы в 64 битном вещественном числе составляет 52 бита, что  позволяет точно отобразить лишь 16 разрядное десятичное целое число, а не  18 квинтиллионов, как наивно полагает Владимир"), затем про "это VM а не интерпретатор", и тоже с истерикой: " в языках и виртуальных машинах вы ноль без палочки"... я прям утомился этому неучу по носу щёлкать!  Потом Вы. Ваша квалификация несколько выше, но стиль тот же, вплоть до прямой лжи: "Как уже всем известно, документацию Владимир не читает". А причина-то в другом - просто я с раннего детства не перевариваю распальцованных дураков и редко спускаю им их "поучения". А "вопрос, который давно Вас заботит", выеденного яйца не стоит, ибо main есть ВСЕГДА! Поймите же, наконец, простую вещь: ЛЮБОЙ интерпретатор ОБЯЗАН знать, когда и с какого места нужно начинать интерпретировать представленный код, когда и в каком месте нужно прекратить это делать. И лучший способ это сделать - создать утилиту с согласованным именем: тот самый main. Эта технология была разработана ещё в прошлом тысячелетии - тогда на планете Земля ещё водились программисты. И на Ваш вопрос: "А если скрипт сам захотел остановиться - откуда OnStop возьмётся?!" ответ уже давался: сбрасывайте этот дурацкий флаг isRun НЕ ТОЛЬКО в OnStop, а в любом другом месте, где он "захотел остановиться". Или воткните в этот дурацкий цикл НЕ ТОЛЬКО sleep, но и хоть сотню конструкций if blah-blah-blah then break;end; P.S. На всякий случай только что проверил оба способа - всё прекрасно работает. Скрытый текст Скрытый текст 05.11.2020 09:21:18 swerg, А при чём тут "визуальные элементы"? На этом форуме ещё несколько лет назад говорилось, что подготовка таблицы и прорисовка таблицы - это РАЗНЫЕ вещи, и давались предложения к разработчикам (проигнорированные) разделить эти вещи. Какое отношение к "визуальным элементам" имеет AllocTable? Или AddColumn? Или даже SetTableNotificationCallback, равно как и SetColor? Вот CreateWindow - имеет. Ну, SetCell, пожалуй, имеет (да и то спорный вопрос). Скрытый текст Скрытый текст 03.12.2020 11:14:35 swerg, Я уже просил (не помню, Вас или нет): не надо врать! Это про "не читает документацию". А как передаются параметры в Lua, мне АБСОЛЮТНО до лампады - я не разработчик языка, я просто пользователь. Просто ЕСЛИ они передаются не ссылкой, а самой таблицей значений, ТО это есть идиотизм. Идиотизм тех, кто ПИШЕТ эту самую "документацию". Скрытый текст Скрытый текст 12.01.2021 20:02:53 swerg, Я, милок, уже пару раз здесь говорил, что с раннего детства терпеть не могу распальцованных дураков и редко спускаю им их "поучения".  А моя некомпетентность привела к тому, что мой скрипт уже с месяц как полностью рабочий, и в последние дни я занимаюсь тончайшей шлифовкой алгоритма. Точнее, занимался - последние два дня я просто любуюсь его работой, и только за сегодня он уже принёс мне 1.6% прибыли, а ещё не вечер! Надеюсь, к концу дня будет 2%. Впрочем, неважно. И ему НАСРАТЬ на бесконечно меняющиеся версии софта - он [пока что] прекрасно уживается с любыми. Осталось разве что убрать кретинизм с "1 заявка - 1 лот", и больше я вообще от него ничего не хочу. Так что НЕ СОВЕТУЮ разным умникам "отвечать на мой идиотизм" - чревато. Вот подобные "отвлечённые" тяфтяфки - это сколько угодно. В частности, в этой самой ветке: чтение таблицы состояния счёта СКРИПТОМ есть алгоритмический идиотизм. Не его это собачье дело! Точка. Так что клоуна в зеркале поищите. Скрытый текст Скрытый текст 24.03.2021 21:11:36 swerg, Ну хватит тяфтяфкать, милок! За слова свои отвечать квалификации не хватает - понимаю, но тогда уж приличнее помолчать. Скрытый текст Скрытый текст 25.03.2021 07:25:29 swerg,Чо, лапуль, аж в истерике бьёмся? Это можно, только вот корчить из себя крутого программера в моём присутствии - это уже чревато. Скрытый текст Скрытый текст 25.03.2021 07:30:27 swerg, Это место, лапуль, никогда никому не показывалось, так что брехать про "говорилось" не следует.  Ну да ладно, не трону - припадок пройдёт, и визжащая баба базарная тихонечко заткнётся. Справка для особо одарённых: ...

Для справки: это Артем визжащий дурак, вроде Вас, а вот TGB как раз вполне профессионален, и уступает (по моим оценкам) на этом форуме разве что Антону. А Вы наблюдайте - вдруг поможет? Тяфтяфкать только не советую. Впрочем, дело Ваше.

Мой предыдущий комментарий это ответ swerg.

1. Более 20 суток не проявляются ошибки синхронизации (смотрите историю исправления этой ошибки в этой ветке) реализации многопотоковости QLua (обусловленной реализо-ванной  разработчиками QUIK архитектуры обработки колбеков). Это, совершенно не значит, что нет ошибок в API взаимодействия скриптов пользователя с QUIK.
2. Есть  предложения, по которым мы ждем ответа от поддержки (их пока два, как я думаю полезных):
1) предложение по исправлению критической ситуации (зависания QUIK на длинных фрагментов байт-кодов «чистых» Lua, без обращения к C-функциям);
2) предложение (не устраняющего критической ситуации, но обеспечивающее эффективность выполнения длинных фрагментов кода QLua с частым обращением к «коротким» C-функциям).
3. Приходится наблюдать интенсивные обсуждения проблем обработки колбеков.
   Есть, как мне кажется, хороший документ разработчика QUIK: «Использование Lua в Ра-бочем месте QUIK.pdf». Наверное, его можно было написать лучше, но даже, в том виде, как он есть, если тот, кто его внимательно прочитает и поймет, может избавиться от многих проблем обработки колбеков.

Старатель,
В мой огород камушек, что ли? Динамическая типизация есть идеологический кретинизм, вне зависимости от умения с этим кретинизмом справляться (очень точное слово, кстати), и место ему на помойке, и только там!

В остальном я согласен с TGB: На мой взгляд, существуют 4 уровня программирования:
1. Аппаратный - его модули зависят от платформы, набора команд процессора и т.п.
2. Системный - тот, который и выполняет, собственно, всю работу, обращаясь при необходимости к объектам аппаратного уровня.
3. Прикладной - вся остальная часть кода разрабатываемого программного обеспечения, за исключением
4. Инструментальный - фактически подмножество прикладного и отличается от него лишь разными требованиями к квалификации программиста.

Так вот: доступ к утилитам первых двух уровней (ядро программного обеспечения) должен быть только у сотрудников арки, ибо они рассчитаны на программиста высокой квалификации, и неправильное использование этого инструментария может привести к серьёзным ошибкам (порча памяти, некорректная обработка прерываний и т.п.) - это внутреннее, интимное дело Квика, и нельзя позволять пользователям или их утилитам "лезть туда своими грязными лапами". А вот объекты прикладного уровня имеют "защиту от дурака" и, следовательно, не предъявляют особых требований к квалификации программиста. Использование инструментального уровня не поощряется, и допустимо лишь при создании компонентов, критичных к скорости выполнения, нестандартной обработке данных и т.п. То есть это уровень для квалифицированных прикладников (или для считающих себя таковыми).

В идеале должно бы быть примерно так...

А вот и подтверждение этому из разных веток:
1) Опять ошибка получения кол-ва ордеров скриптом: https://forum.quik.ru/forum10/topic6503/ ;
2) [BUG] getFuturesHolding: ошибка в работе: https://forum.quik.ru/forum10/topic6526/ .
  Ошибки, описанные в упомянутых выше ветках, скорее всего, ошибки синхронизации функций API QLua. И ошибки такого вида, возможно, имеются и в других функциях API.
  Вообще, все функции API работы с QUIK из QLua должны быть потокобезопасными  из-за того, что к ним могут обращаться из нескольких одновременно запущенных скриптов (работающих в разных потоках). Причем, объекты синхронизации в таких функциях должны локализоваться в месте, общем для всех скриптов, и это место точно не global_State и тем более не lua_State. На месте разработчиков QUIK, я бы создал общий для всех скриптов пользователя массив, в котором для каждой функции API QLua выделил элемент хранения объекта синхронизации при работе с этой функцией.

Об областях синхронизации.
  Область синхронизации программы это та часть области видимости переменных программы, для которых предполагается обеспечить атомарность (! всей совокупности этих переменных как единого целого) при многопоточной обработки данных.
  Распространенной ошибкой синхронизации в параллельном программировании является неправильное определение области синхронизации. Для эффективности синхронизации ее область должна быть минимальнонеобходимой (однозначно определяющей результат программы), обеспечивающей корректность работы программы. Если область синхронизации программы содержит в себе минимальнонеобходимую, то все будет работать корректно (но не вполне эффективно). Если же область синхронизации не включает в себя минимальноне-обходимую, то это ошибка программы. Поэтому при разработках, в тех случаях, когда не очевидна минимальнонеобходимая область синхронизации, обычно первоначально область синхронизации выбирается с «запасом». Далее эта область, в процессе развития проекта, может быть «сужена», с целью повышения эффективности синхронизации, до минимальнонеобходимой.