Владимир (Все сообщения пользователя)

Артем, Не стоит, сударь, не стоит. Вы для меня не авторитет, Вы для меня НИКТО. А что Lua есть глючное убожество, говорится в доброй половине моих комментариев на этом форуме ДОКАЗАТЕЛЬНО говорится, а не голословно "один из хороших языков".

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

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

А я как раз знаю язык в полной мере. ВСЁ, что я хотел написать, я написал с его помощью, ВСЁ, для чего он предназначен, реализовал. Куда ещё "полнее мера"? А уж сравнивать такое убожество, как Lua хотя бы со станком с ЧПУ и вообще смешно. Хуже языка мне пока что не попадалось!

Артем, Ну, если "программа с миллионами свечек в обработке", то это у точно бездарь писал! Гарантия 146%!

Артем, Ответьте на вопрос! Есть такие? Нет? Тогда ИМЕННО Я И ЕСТЬ "эксперт в Lua"! Я на нём ПОЛНОСТЬЮ реализовал всё, что я хотел. Алгоритм давно уже торгует лучше меня, а недавно я признал его безоговорочное превосходство, я больше не хочу "путаться у него под ногами". Вот и сегодня он приподнял мой портфель на полпроцента. Наверное, до конца сессии ещё чт-нибудь наковыряет. Что мне ещё желать? НА КОЙ мне читать инструкцию? Мне больше НЕЧЕГО оттуда почерпнуть!

На ассемблере Z80 не писал никогда (писал н трёх других ассемблерах). Равно как и н Прологе. На Фортране последний раз писал лет 30-40 назад. На C - да, "эксперт". Но не на С++.

Артем, Да вот как раз я-то язык знаю. Я чуть ли не единственный на этом форуме, кто написал скрипт на девственно чистом Lua. Есть ещё такие? Поднимите руки! Нет? Тогда НЕ ВАМ что-то мне говорить о знании языка.  

Артем,Да мне СРАТЬ. что там в головожопу создателям этой "документации" вдарило. Строка - это то, что я сказал! Была, есть и будет.

Артем, На заборе тоже много чего написано. Если составлять описание здешних глюков, наверное, многотомник получится - и хоть что-нибудь было бы описано! А читать про строки, да еще "целиком и полностью"... Строка - это непрерывная последовательность элементов (например, байтов), оканчивающаяся терминатором. Точка. О ЧЁМ здесь вообще можно читать? КАКИМ ОБРАЗОМ чтение всей этой бредятины может поднять "ваши познания и умения находятся на уровне повыше плинтуса"? Из любого дерьма, из любой элементарщины проблему сделают...

Nikolay Полистал. Не увидел вообще ничего, заслуживающего внимания. Я что-то пропутил?

TGB, А каким боком здесь Владимир? По какому "поводу скорости вывода жду комментария Владимира"? Откуда ему знать?  

Но, раз просят, комментирую... вот,глаз зацепился за "table.sort(s)" - у Владимира свой собственный сортир, супер-пупер-эффективный.

А ещё глаз зацепился за "это ~5000 строк" - у Владимира весь скрипт 736 строк - это со всеми комментариями и пустыми строками (37738 байт). А "по поводу скорости" 20 млсек - это очень мало: Владимир оперирует секундами или ещё более медленными интервалами.  

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

Передаётся же строка, господа! А потому пришпилив первыми одним-двумя символами ID скрипта, мы получим гарантированную уникальность при любом их количестве (если гарантирована их уникальность для одного скрипта).

Артем, Мало, что ли? Когда я пользовался датчиками случайных чисел, они всегда у меня были 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 просто не нарадуюсь!

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

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

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

Nikolay, Я понимаю. Просто я предполагал, что ключи юзеровских  транзакций уж как-нибудь не повторятся за сеанс при задании таким способом (я его откуда-то списал, из какого-то примера). А сегодня как посмотрел...

А как "нормальные люди" задают ID транзакции? В принципе, можно бы присобачить системное время или просто нумеровать их у себя как 1, 2, 3, 4,... А "уникальность между скриптами" меня не волнует - у меня один скрипт - есть, был и будет. Точнее, две его копии на двух Квиках.

Nikolay, И ничему не доверяю. Просто трудоёмкость разбирательства в чужом коде соизмерима с разработкой аналогичного продукта с нуля. А иногда и выше.

я вот сейчас отлаживаю свой алгоритм снятия заявок. Там и так чёрт ногу сломит, но ещё и напоролся на дополнительную чертовщину: у меня ID транзакции с самого начала задавалось как:
A.TRANS_ID=tostring(math.random(1,9999));
Я это дело никогда даже и не проверял - работает и работает. А сейчас мне нужно по нему в некоторых случаях определять ID заявки в таблице orders,так я вывел отладочную печать, гляжу, а там TRANS_ID=13. Второй раз запускаю - опять 13.У второго брокера на другом Квике сработала - опять 13! То ли лыжи не едут...    

Nikolay,  А  как раз слабо себе могу представить разработчика, использующего библиотеки С исходными кодами.  

Вячеслав, Смотрю: OnTrade и getItem('orders', ...) Всё остальное поганой метлой!

Сдались вам эти транзакции... и так тут всякого барахла понапихано, и почти всё глючное. Чем больше туда напихать, тем больше вероятность, что где-нибудь что-нибудь да гробанётся. Я сейчас мечтаю лишь об одном: чтобы версии софта менять перестали. Тогда хоть приспособиться можно.

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

Дождался! Убийство окна, таблицы и создание новой таблицы восстанавливает-таки нормальный текст в ячейках! Ура, товарищи! Как можно написать подобную "математику"...  

УФ! Кажется, я разобрался, как наиболее оптимально отслеживать заявки. Я уже говорил, что не хотелось бы связываться ни с прерываниями, ни с ковырянием по таблицам (по крайней мере, без крайней необходимости). В результате пришлось использовать и то, и другое, хотя и по минимуму: единственным прерыванием осталось OnTrade, единственной таблицей - Orders. Функциональность должна остаться неизменной: обеспечить возможность надёжной торговли в режиме "кентавра" (торговать может и сам скрипт, и пользователь).

Структуру паспорта я несколько упростил: теперь это просто массив сделок с тремя полями
[i]["Orders"][j][0] - ID заявки в торговой системе
[i]["Orders"][j][1] - ID сделки
[i]["Orders"][j][2] - количество лотов в заявке (остаток для незакрытых заявок), где i - ID тикера, j - ID сделки (натуральное число), а нулевая строка этой таблицы предназначена для самого паспорта сделок/заявок:
[i]["Orders"][0][0] - размер массива сделок (число строк, оно же ID последней строки)
[i]["Orders"][0][1] - значение счётчика прерываний по таймеру, после которого можно снимать заявки (снимаются сразу все незакрытые)
[i]["Orders"][0][2] - не используется

Работа алгоритма:

1. При подаче заявки по какому-либо тикеру через скрипт мы формируем транзакцию и подаём заявку "по ненадёжному протоколу" - никаких OnTransReply или OnOrder, контролируем только возвращаемое значение sendTransaction (функция должна возвращать пустую строку). Если так оно и есть, заносим новую строку в таблицу сделок тикера, заполняя её следующим образом:
[i]["Orders"][j][0] - ID транзакции (ID заявки пока неизвестен)
[i]["Orders"][j][1] - 0 (сделок пока нет)
[i]["Orders"][j][2] - количество лотов в заявке (продажа или покупка - неважно, это нам знать не обязательно).
Разумеется, поправляем (инкрементируем) поле [i]["Orders"][0][0], а в [i]["Orders"][0][1] добавляем C+10 - текущее значение счётчика прерываний по таймеру (у меня это 15-секундные тики, так что снимать заявки можно будет через 2.5 минуты - за это время гарантированно должны придти все "лишние" прерывания OnTrade).

2. По приходу прерывания OnTrade в цикле по сделкам ищем совпадение "ID заявки + ID сделки", при совпадении игнорируем это прерывание. При такой организации мы отловим все повторные OnTrade, даже если они будут приходить "крест-накрест собачьим шагом".

3. Если в том же цикле нарываемся на совпадение ID транзакции с полем ID заявки при нулевом поле "ID сделки" (дополнительный контроль), то это первая сделка по нашей заявке: перебиваем туда реальные ID заявки и ID сделки, а из поля "количество лотов" вычитаем то, что нам пришло под "qty" (что при покупке, что при продаже), то есть там остаётся число ещё не реализованных по заявке лотов. Насколько я понимаю, то же значение должно быть и в пришедшем поле balance, но на него у меня особой надежды нет, так что я просто в том же цикле забираю значение поля [i]["Orders"][j][2] (количество оставшихся лотов по заявке) из тех строк, у которых поле [i]["Orders"][j][0] совпало с ID заявки (сделки заносятся последовательно, так что значение на выходе получим верное).

4. Если мы нашли хотя бы одну строку с кодом этой заявки, остаток лотов не может быть нулевым (в противном случае, заявка была бы исполнена, и нового OnTrade придти не могло). Заносим новую строку в таблицу (поправляя количество строк и значение счётчика) записывая туда ID заявки и ID сделки, а в поле "количество" найденное значение остатка минус пришедшее значение qty.

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

6. Если в обработчике прерываний по таймеру значение счётчика превышено, пришло время снимать заявки (все сразу). Идём в цикле по сделкам тикера и смотрим: остаток нулевой - убиваем строку (кажется, для этого достаточно присвоить [i]["Orders"][j]=nil). Если нет, а "выше" есть строка с тем же номером заявки, делаем то же самое. Если это последняя строка, а номер заявки совпал, значит, это частично исполненная заявка, которую нужно убивать через KILL_ORDER с последующим удалением строки и правкой количества денег и лотов.

7. А вот (самое неприятное) если номер заявки не совпадает, значит, там сидит номер транзакции на заявку, по которой так и не пришло ни одного прерывания. Здесь-то и приходится лезть в таблицу orders, ловить там строку с нужным trans_id, смотреть по флагам, не снял ли её юзер и, если нет, убивать заявку по тамошнему order_num и снова корректировать деньги и лоты.

Ох, чую, неделю придётся отлаживать эту хрень!

Блин, вынес создание таблицы из main в отдельную функцию, а в обработчик повесил на Enter DestroyTable+CreateWindow+SetWindowPos. Теперь снова ждать, пока эта скотина обнулится. Если уж И ЭТО не поможет...

Оба-на! Не помогло и разнесение по разным циклам - опять эта сволочь обнулилась...  

Suxov, Я понял, но я до этой ветки даже не подозревал о существовании ALT+B и ALT+L. Я когда-то тоже хотел убрать и заголовок, и номера строк, но с тех пор передумал: заголовок я приспособил под строку статуса, а номера строк в разных режимах выдачи говорят о текущем количестве тикеров в моём портфеле либо о том, сколько тикеров требуют в данный момент моего внимания, либо... короче говоря, и то, и другое несёт полезную информацию. Что до закрепления - у меня окно как создаётся при запуске на вкладке "робот", так там и сидит до конца сеанса - и закреплять ничего не надо.  

Egor Zaytsev, Нет, не могу согласиться: при чём здесь вообще GDI? Или, по крайней мере, какое мне дело до GDI? И почему раньше никаких проблем с "ресурсами GDI" не было? Графики у меня нет, и кроме двух таблиц, созданных с помощью AllocTable (одна эта, другая для контекстного меню) тоже ничего нет. Вчера я разнёс обращения к Квику на прорисовку таблицы и подачу транзакций ему же по разным циклам - пока всё работает. Но и вчера до определённого момента тоже всё работало, а потом раз пять таблица обнулялась, причём смена режима (Clear) не помогала (DestroyTable + AllocTable не пробовал).

Anton, Ну это смотря у кого. У меня так ничего не уносят. Вернее, уносили последний раз где-то месяца полтора назад.  

Евгений, А ввод такой: не надо анализировать флаги сделки вообще! Я поступаю именно так. Правда, если сделка "левая" (юзер дал заявку в обход скрипта), то нужно посмотреть хотя бы направление сделки. Да и то, видимо, есть другие способы это узнать.

Anton, А если был бы спред на 100000 контрактов, значит, брокер этот неплох и имеет право на "дивиденды". И тоже, по сути, никому не мешает. Вот, предположим, есть успешный трейдер: большинство его сделок приносят прибыль, позволяющей ему иметь, скажем,100% годовых. Да хоть 20%! И что, он станет заниматься подобной "суходрочкой"? Да ни в жисть!

Лично я уважаю профессионализм. Или. как говорил Мигель де Унамуно: "я предпочитаю человека умного, но плохого глупому, но хорошему". Гениально!

Anton, Ну как же? Флаги там какие-то нормальные правильно установить не могут - народ беспокоится В конце концов, брокеры сами могут быть клиентами биржи, причём вип-клиентами. И биржа может быть своим клиентом. Ну и пущай себе урывают свои кусочки счастья - лишь бы со своей основной работой нормально справлялись.

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

Anton, Да хрен бы с ними! Что с них взять, с убогих, коли мозгофф нет? Только когда закончат свою мышиную возню, шоб данные давали не глючные...

Suxov, Это не первый столбец, это минус первый. Рисуется сам, паскуда. и убрать его, по-видимому, нельзя. Нулевой столбец нулевой длины - делается, использую.
AddColumn(T,0,"",true,QTABLE_STRING_TYPE,0);
Про  ALT+B и ALT+L до сих пор не слышал, но проверил - это работает и для программно созданных окон.

Разнёс я на всякий пожарный прорисовку таблицы и принятие решений по разным циклам. Теперь пока таблица полностью не прорисована, не может быть никаких никаких заявок, а когда идут заявки, не может быть никаких изменений в таблице. Вроде, работает. Хотя она и раньше "вроде, работала".  

Артем, Так эта Ваша прыгающая хрень... как её... прыгающий логотип - это не только не велосипед - это даже не программирование! И в моё время "веб-программисты" вообще программистами не считались. Равно как и HTML языком. А плодящиеся как тараканы языки, браузеры, СУБД или те же ОС - это, простите, ЧТО? Велосипед на велосипеде! Скажу больше: "на современной аппаратуре" вообще ничем другим и не занимаются! А эти ваши "видеоигры" - это простите, ЧТО? Игры по пальцам можно пересчитать: от Тетриса Алексе Пажитнова до Цивилизации Сида Мейера. Всё остальное - велосипеды, велосипеды, велосипеды... в глазах рябит! Причём качество всё время катастрофически падает: помню, когда-то на несчастных 80486 по сети в Doom рубились - никаких проблем! А современное говно вообще отказывается работать без туевой хучи гигабайт и гигагерц. Так что велосипеды нынешние и самокатами-то назвать трудно.  

Артем, Я согласен: "использовать ассемблер ничуть не тяжелее пхп",   Что до остального - вы не пишете программу, а собираете её из кубиков, написанных дядей Васей. Ассемблер тоже позволяет вызывать библиотечные утилиты.

Наш "Мираж" был и в графическом варианте (тогда это было EGA 640*350*16. Мышка, выпадающие менюшки, плавное движение фигур, хелп... 35 килобайт всё удовольствие. Ну и рейтинг гроссмейстерский (максимально 2436, в Гааге получили).

Артем, Я эту нехитрую истину понял много лет назад, когда работала ещё старушка БЭМ со смешными по сравнению с любым телефоном возможностями, на которой крутились многодневные задачи, да ещё десятка полтора юзеров сидело в дисплейном классе за мониторами. А в соседнем зале стояла какая-то (не помню номера) ЕС ЭВМ, у которой память и быстродействие были на порядок больше. И там за четырьмя терминалами сидели очень грустные юзеры, у которых постоянно бесследно пропадали задачи.

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

TGB, Ни в одной букве! Наша шахматная программа, например, была написана на чистейшем ассемблере. Точнее, последовательно на трёх ассемблерах: БЭСМ, PDP и Интел - переписать её на С у нас так руки и не дошли. А робот слишком примитивная задача, которую можно реализовать даже на Lua. А вот в действительно СЛОЖНЫХ случаях не хватает даже возможностей С (там нет меток в массивах, инициализации неоднородных массивов и ещё кое-чего). Все остальные языки слабее С (который называют даже машинно-независимым ассемблером), и реализация сложных вещей на них чрезвычайно трудоёмка, если вообще возможна.

Артем, Именно! Но потом сообразил, что для того, чтобы многократно впаривать лохам одно и то же дерьмо, нужно, чтобы сама операционка все ресурсы и отжирала. Результат - самый богатый человек планеты (был).

Артем, Это развращает.. Высокие возможности железа стимулируют разработку убогого софта. Когда-то давно я был на одном докладе от Интел, где они рекламировали свой новый процессор на 3 ГГц (ни о каких ядрах тогда ещ и речи не было). После доклада я подошёл к докладчику и спросил: "Вот НАФИГА такая скорость на персональном компьютере"? Он начал что-то говорить про высококачественную графику, но чувствовалось, что он и сам не знает, что с этой мощностью делать. Но прошли годы, и...

Да, кстати: свечи лично я считаю сам, на чистом Lua, и мне вполне хватает ресурсов! Зачем вам "много свечек"? Как говорил незабвенный Владимир Ильич, "лучше меньше, да лучше".  

Артем, Нет, не зря. Необходимая функциональность для Квика ничтожна, и даже такой убогий язык, как Lua с его встроенными возможности, полностью позволяет реализовать эту функциональность. Собственно, я её уже реализовал. Если бы ещё не эти дурацкие глюки...

Артем, Вы здесь недавно. Я, в общем, тоже, но я ещё несколько месяцев назад писал, что мне СТЫДНО писать компенсаторную заглушку на ситуацию, когда на одно событие приходит целая колода прерываний. Несколько месяцев преодолевал рвотные позывы, на днях написал. Ошибка эта не исправляется ГОДАМИ, несмотря на многократные указывания на неё разных юзеров. Более того: И НЕ СОБИРАЕТСЯ исправляться. Так что у меня на разработчиков надежды почти нет. С этим глюком мне тоже тошно разбираться: он неприличный, и может быть объяснён либо неряшливостью, либо низкой квалификацией - неизвестно, что хуже. Разве что какой-нибудь Антон снова подскажет какую-нибудь идею, как это было с потерей управления... Кстати, я пользуюсь чистейшим Lua, и более ничем, и я НЕ МОГУ "обогнуть в своём коде" ни SetColor, ни SetCell - это разработчики представили для работы с таблицами, и больше здесь ничего нет. А сторонними библиотеками я не пользуюсь, и пользоваться не собираюсь.

Артем, Да ужжж...когда-то мы делали шахматный компьютер, так там было 16 КИЛОбайт ПЗУ и 4К ОЗУ. Это и на шахматную программу, и на дебютный справочник, и на какую-то пародию на операционку. Плюс процессор 4.7 МГц российского производства. И это убожество. с обрезанной по самые уши оценочной функцией однажды умудрилось официально выполнить норму КМС. А теперь "32 гигабайта должно быть вполне адекватно".  

Артем, Вы, лично Вы способны предложить ХОТЬ ОНУ гипотезу такого поведения[Y/N]? КАКИЕ ИМЕННО "данные" Вы хотите получить и ЧЕМ ИМЕННО они Вам помогут?

Артем, Блин, НА КОЙ мне этим онанизмом заниматься? Я ПОЛЬЗОВАТЕЛЬ этого софта, а не разработчик! И, как я говорил ещё в первом посте, поскольку у меня в разных местах используется разный цвет текста и фона, то хоть в одной ячейке должно быть хоть что-то видно! А раз нет, либо она ВНУТРИ своей функции вдруг устанавливает цвет текста равный цвету фона (а не наоборот, кстати) либо вообще не прорисовывает текст. Tertium non datur!

Артем, Где "там"? В моём коде? НЕТ у меня никаких "других источников"!

Блин, да откуда мне знать "в каких именно ситуациях ошибка возникает"?! я и спрашиваю у техподдержки хотя бы гипотезу, как можно умудриться получить такое? Лично у меня просто фантазии не хватает!

TGB, Совершенно верно: "все можно сделать и на ассемблере". А кое-что можно сделать ТОЛЬКО на ассемблере. А потому именно на нём и можно предельно быстро и качественно разрабатывать любые приложения. В общем случае, быстрее, чем на любом другом языке.

Специфичность использования OS_Quesha состоит в том, что она изначально предполагает "работу в среде программного комплекса QUIK". А задачи. которые решаются в Квике по определению не требуют ни "нескольких ядер в ЦП компьютера", ни параллельных вычислений, ни какого-либо "расхода ресурсов ПК".

Артем, Ну не таким же образом! Если я задаю "k=0xFFFFFF;l=0;" то что, я на следующем шаге должен проверять, что они разные? И так все 11 раз (именно столько у меня SetColor на вывод таблицы)? Да если ХОТЬ РАЗ они будут равны, язык НЕМЕДЛЕННО нужно отправлять на помойку!

Артем, Сударь, я 40 лет программистом, причём, главным образом, системщик - уж мне ли не знать, что "в программировании может быть"?

О, Господи! Простите, но Ваш "изменённый код" - это детский сад. И я не собираюсь как-то извращаться, чтобы ловить всякие глюки В ЧУЖОМ софте! У меня просто в голове не укладывается: как можно изуродовать софт, чтобы он вытворял ТАКОЕ? Как можно изуродовать софт, чтобы на одно событие он выдавал кучу прерываний? Как можно изуродовать софт, чтобы он не успевал за юзером отслеживать его нажатия на клавиши? Как можно изуродовать софт, чтобы чуть ли не еженедельно выпускался очередной костыль по имени "версия 11.22.33.44"? Скрипт мой, слава Богу, пока что и так работает, даже с такой изуродованной таблицей. Боюсь, ненадолго...

Во, блин! Опять, сволочь, обнулилась! Подслушивает, что ли?  

Egor Zaytsev, Да хотя бы гипотезу: ЧТО ИМЕННО В ПРИНЦИПЕ может происходить чтобы давать ТАКОЙ эффект? Ведь в SetColor и цвет фона, и цвет текста задаются обязательными аргументами!

Боевой скрипт я вам, разумеется, не дам - там серьёзные алгоритмы принятия решений, а не кака-то несчастная визуализация. А любой другой "огрызок" не даст никаких гарантий локализации ошибки, которая проявляется в одном случае из тысячи. Попробуёте поймать эффект у себя - я уже говорил, что при обрыве связей в таблице заявок строки пропадают, хотя интуитивно кажется, что здесь не эта, а другая ошибка в софте.

Артем, Вот именно, что "работа с именно этми функциями и может быть проблематичной". Она уже приводила к потере управления при останове скрипта по OnStop (Антон когда-то здорово помог в локализации этой ошибки). И я абсолютно убеждён, "на чьей стороне ошибка" - НЕ МОЖЕТ мой код приводить к таким эффектам! НЕ МОЖЕТ!

Ха-ха-ха! Да я прямо перед вызовом ЗАДАЮ "идентичный цвет фона и текста"! Фрагмент кода прорисовки таблицы:

Egor Zaytsev, Так он возникает раз в сто лет! На прошлой версии скрипта я вообще такого не видел, хотя код прорисовки таблицы, насколько  помню, не изменился ни в одной букве. Сегодня вот тоже скрипт работает на двух разных брокерах - и пока что всё тип-топ, хотя сделки уже были и там, и там. Более-менее заметное изменение кода состоит в том, что у меня теперь таблица "перебивается" чаще. Дело в том, что у меня раз в 15 секунд может измениться набор строк в таблице. Вначале я пытался удалять ненужные строки с помощью DeleteRow и вставлять новые с помощью InsertRow, но там возникали разные разные глюки, вроде пустых строк - я когда-то это описывал (кстати, этот эффект проявляется в таблице заявок в Квике даже при ручной торговле: после обрыва связи часть строк могут оказаться пустыми, и помогает только перезапуск Квика). Хотя не помню - возможно, даже он не помогает.

Затем я переделал скрипт без использования DeleteRow: новые строки вставлялись по InsertRow нормально, а при необходимости удаления ненужных строк я просто перебивал таблицу заново (Clear + InsertRow) - эта технология работала как часы.

Неприятность же состояла в том, что во входном файле тикеры у меня сгруппированы по классам и по алфавиту, а после вставки строк там получалась каша (новые строки ведь добавлялись в конец таблицы), поэтому я решил перебивать таблицу при любом изменении набора входящих в неё строк. Вот тут-то и начались подобные "эффекты". Поскольку код с очисткой и перебивкой таблицы остался также без изменений, единственное, что изменилось - это частота перебивки: она стала заметно выше и, следовательно, увеличилась вероятность столкнуться с транзакцией при прорисовке таблицы. Что именно здесь происходит - я не понимаю, но если в момент прорисовки отправляется транзакция, таблица обнуляется (не всегда, а очень редко). В момент перебивки таблицы отправка заявок невозможна (они в разных функциях), а вот при заполнении таблицы значениями (SetCell, SetColor) - возможно (и то, и другое происходит в одном и том же цикле по тикерам). Была бы ошибка устойчивой, я бы попробовал разнести эти процессы по разным циклам, но проявляется она РЕДКО.