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

Nikolay, Что-то я не понял: разве здесь целые есть? Я привожу к шагу цены похожим способом, но несколько "ракообразно": v=tonumber(string.format("%1.0f",v/step))*step;

Daniil Pozdnyakov, Добрый день, Даниил.

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

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

Никаких деталей запуска, никаких настроек - скрипт на голом Lua, к версии языка и версии Квика, как правило, равнодушен - работает на всём, что попадалось под руку.

_sk_, Для меня несомненно, что:
1. Запуск сразу несколько скриптов - это ЖУТКИЕ тормоза!
2. Прорисовка таблиц - относительно дешёвая операция (особенно, если её выполнять не чаще, чем раз в секунду).
3. Никакими коллбеками, кроме OnStop и OnTrade не пользуюсь и, соответственно, ни малейших претензий к
SetCell и/или SetColor не имею.

Anton, Тогда уж в 100 * 0.112 / 0.018=622, т.е. в 6 раз.  

Daniil Pozdnyakov,  Да, "через определённое время корректной работы функции GetDepoEx, функция начинает выводить нулевое значение". Причём после перезапуска скрипта она уже сразу начинает выводить нули. Значение параметра "Текущий остаток" может быть самым разным (у меня порядка сотни тикеров в портфелях двух брокеров), при этом в "Позиции по инструментам" и "Состоянии счёта" значения верные.

Фрагмент кода:Версии терминала от 8.7.1.3 до 9.1.3.11

Написал не так давно процедуру сверки портфелей (своего и со стороны брокера). Данные получаю через getDepoEx, параметр currentbal (насколько я понимаю, ничего другого для получения этой информации не существует). Функция простая, заработала с первого тыка, несколько рассогласований поймала, но сегодня вдруг перестала работать, причём сразу у двух моих брокеров. Вернее, не сразу, а часа через два один после другого. Звонки брокерам помогли понять разве что ни один из них ни разу не слышал о подобных вещах, один посоветовал написать им на 911, но честно предупредил, что без гарантии, а второй... посоветовал обратиться сюда. Ладно, обращаюсь.

Господа разработчики! Если у вас не получилось считать данные от брокера, возвращайте хотя бы nil, а не 0! А то мой скрипт видит рассогласование портфелей и вырубает тикер из торгов, то есть после ТАКОГО поведения он вырубает ВСЕ тикеры до единого! Господа, несоответствие данных в портфеле брокера и моём - это ОДНА ситуация (ради выявления которой я и написал эту утилиту), а то, что вы оказались не способны считать данные от брокера - это ДРУГАЯ ситуация (из-за проявления которой я и отрубил эту утилиту). Давайте как-то сведём это дело к ПЕРВОМУ варианту.

AndyWise, А как к ней ещё относиться? Я уже не раз здесь говорил, что классические мат.ожидание и дисперсия в миллион раз информативнее всей этой "японской" лабуды. А если Вас "напрягает только возможный перезаказ данных, когда вываливается история", то тикеров у Вас под контролем вряд ли больше десятка. А если их будет несколько сотен (как у меня), тогда и увидите, "в чём жопа".  

Nikolay, Ответ: целесообразно.

1. За получение цены сделки внутри бара полагается расстрел на месте.
2. Коллбеки при работе со свечами нужны ТОЛЬКО для того, чтобы даже не "узнавать, что пришёл новый бар", а получить его сразу по приходу (аналогичная задача у коллбека OnTrade).
3. За расчёт свечей на клиенте по ТОС см. пункт первый.
4. Заменить эту японскую гадость на нормальные свечи, которые имеют только ОДНО значение, рассчитываемое из тиков по формуле:
V=(N1*P1+N2*P2+...+Ni*Pi)/(N1+N2+...+Ni)
В этом случае сюда органично впишутся и объёмы, повышая достоверность информации, а не замыливая её.
5. Всё это я описал для случая нормальной организации, а то, что есть, лучше всего отправить оптом на помойку.

AndyWise, Только тот вариант получения данных приемлем, который описал я!

А нафига Вам Мин/Макс за 1сек? Что Вы с ними делать будете? Их уже нет, поезд ушёл! Вам могли бы пригодиться разве что BID и OFFER, но даже их, возможно, уже нет! Пока Ваш скрипт отправит заявку в Квик, тот брокеру, а брокер бирже, ситуация со стаканом может 100500 раз измениться. А иголки я с недавнего времени стал ловить, но только в полуторасекундном прерывании, а ведь они бывают и часовые, и дневные, и недельные. Просто более тяжёлые иголки скрипт и сам поймает, по свечам.

Я опрашиваю getParamEx("LAST") два раза в секунду, и это очень быстрая (для Квика и Луа) операция: сотни и даже тысячи тикеров можно обслужить, особо не напрягаясь. А вот связываться с OnAllTrade или CreateDataSource - это одна Большая Жопа, причём гарантированая.

AndyWise, Ни тот, ни другой вариант неприемлем, не говоря уже о том, что при работе с Квиком тиковые данные вообще не нужны. Никому. Ибо использовать их для принятия решений практически невозможно - для этого нужно другое железо и другой софт. У меня прямо противоположная проблема: мне нужны свечи, причём тяжёлые - от 15-минутных и выше. Можно даже от часовых. Но сервис для их получения настолько ужасен, что я вообще отказался от их использования. А более лёгкие свечи, от 7.5-секундных до 64-минутных (10 таймфреймов) я считаю сам, простым опросом ТТТ (LAST) раз в полсекунды и усредняя результаты замеров. Дёшево и сердито! И я свято убеждён, что это и есть "лучшее из практики".

Anton, У МЕНЯ?! Да я ещё 20 лет назад писал в своей "персональной" ветке:

Блин! Теперь у меня ни малейших сомнений: exceptions надо давить в зародыше!
(...)
Мужики! Мне просто страшно читать о проблемах, какие при этом возникают! Да на кой нужно такое счастье? Стек - это просто LIFO. Заказал ты под него динамическую память или она из тела программы - вторично. Хип - та же память, только в профиль. Надо 5-10 стеков - пожалуйста! Надо отмотать - пожалуйста. Надо диагностику по аварийному выходу из хрен знает откуда - пожалуйста:
for (;(INT8)(*_OS).iPush >= 0; ) // если стек параметров установлен
_PopAllData (); // восстанавливаем спрятанные за Push данные
Работает, как часы. Просто до неприличия - с вашей квалификацией практически любой за пару часов напишет. Ну, "восстановит" она какие-то объекты в стеке, из которого мы уже умотали - был один мусор, будет другой. Но наши-то ТОЖЕ ВОССТАНОВИТ!
Ужас! Завязывайте вы с этими исключениями!
https://forum.ixbt.com/topic.cgi?id=40:160:61#61

Сборка мусора - это идеологически ущербная технология, аппендикс на теле программирования. Первый же вопрос: "ОТКУДА этому придурку знать, какие объекты стали ненужными?" вдребезги разбивает всю конструкцию. Уверен, что глубоко почитаемый мною Джон Маккарти и в страшном сне не мог предположить, какой ящик Пандоры он открыл в 1959 году и насколько она станет востребованной несколько десятилетий спустя: надо же засрать поцессор лишней работой! Надо же поднасрать программисту с памятью, которую он наивно считает "своей"! В результате одно криворукое стадо, не умеющее обращаться с памятью, пользуется услугами другого криворукого стада, которое эти проблемы "решает". Если программер расписывается в собственной несостоятельности при работе с памятью и полагается на эти долбаные "сборщики мусора", если он не знает, что делать при ошибках в своём же коде и полагается на эти долбаные "try…catch", если он неспособен даже определиться с типами его же собственных данных и полагается на эту долбаную "динамическую типизацию", если он добровольно соглашается на все кастрирование своих возможностей, неизбежно появляющиеся при таком подходе (работа с указателями, преобразования типов данных и т.д.), то из-под его пера может выйти ТОЛЬКО говно, столь же изобилующее ошибками, но куда более хитрыми и труднонаходимыми, с которыми уже не только он, но и никто другой не справится уже НИКОГДА! И возникающие при этом тормоза здесь чуть ли не самая малая плата за такой подход к программированию. Точнее, самая заметная - остальные глюки тоже никуда не денутся.

TGB, На месте разработчиков QUIK я бы просто запретил использование более одного скрипта на терминал. Или, по крайней мере, считал бы их полностью автономными задачами, не требующими вообще никакой синхронизации. Тачка просто летала бы! Что, собссно, она у меня сейчас и делает.  

nikolz, А что за зверь "время исполнения скрипта при текущих торгах"? Как с утра запущены у двух брокеров, так всё это время и работают.  

_sk_, О, Господи! Только я уже раз 20 советовал в разных местах: "Не пользуйтесь вы таблицами Квика - есть же таблицы Луа"! Да и с таблицами Квика что за проблемы? В моей главной обычно 20-30 тысяч ячеек, и почти все они проходят не только SetCell, но и SetColor.

Ах, "Скрипты надо запускать одновременно". Ну вот она и причина всех тормозов! А у меня "local nRow обычно порядка 1000 (и может сильно меняться, если установлены какие-то фильтры), а вот "local nCol" как раз порядка 30.

И ещё один тормоз навскидку: что, при каждом выводе таблицы она набивается InsertRow? К меня так только после изменения количества строк в ней, что происходит довольно редко (при внесении нового тикера в портфель, удалении из него или при установке/снятии каких-то фильтров).

_sk_, Не вижу ничего трудного. Даже у меня при запрете подавать заявки в Квик чаще, чем два раза в секунду (излишки отлёживаются в стеке), "тысячи сделок" могут прибежать уже через 20 минут. Да, ни одного графика, все инструменты и так в одной ТТТ - второй не существует, цветовые настройки раскрашивают таблицу по тикерам, как попугая, и ни одного открытого стакана. И нет проблем!  

_sk_, Причина здесь неоднократно называлась: Квик не обязан обеспечивать работу дурацких тестов единственная цель которых - засрать процессор до предела. Ничем не отличается от других "тестов" и "код привели, который демонстрирует проблему": там тоже создаются никому не нужные таблицы в неимоверных количествах, да ещё и замеряются какие-то несчастные микросекунды. Согласен: изучать проблемы нужно именно "с использованием реалистичных нагрузок", а не подобный маразм. И изучение это приводит к однозначному выводу: производительность Квика вполне удовлетворительная.

Конкретно в последние 2 дня при той же самой активности торгов на рынке у меня терминалы 8.7.1.3 и 8.13.3.1, где запущено ПО ОДНОМУ скрипту, прекрасно работают: несколько десятков сделок в день у каждого и никто не "отстаёт от реального времени", и это нормально! Оставьте в покое техподдержку, доставайте лучше разработчиков ваших скриптов: именно они говно, а не [только] софт Квика.

Дополню, что при этом нагрузка на процессор болтается в районе 30-40% (2 ядра по 2 ГГц).

Старатель, Там же русским языком написано:Если какому-то идиоту потребовалось 150 000 таблиц в ситуации, когда не нужно ни одной, то (мягкий) ответ моет быть только таким: "К сожалению, нам не удалось воспроизвести и понять причину описанной вами проблемы". Можно было бы и сразу послать в соответствующем направлении.

Игорь М, Это я запихивать не собираюсь - мне же нужно именно лучшее, а не всё, что попало. На кой мне "полуавтоматы с риск- мани-менеджментом, решения для проп-трейдинга, поддержка групп клиентов и т.д."? Он деньги зарабатывает лучше, чем все эти "группы", включая меня, любимого.    

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

Да, она пока что "охватывает далеко не все случаи" - новая версия должна охватить всё недостающее. Но и старая версия позволяла торговать "в режиме кентавра" - скрипт ведь знает, что сделка пришла не по его заявке, поэтому он учитывает её в своей бухгалтерии, но заявку не снимает - ему всё равно, какой там объём - он ловит только то, что реально сработало. Между прочим, в новой версии я "режим кентавра" как раз отменил. Сам я торгую через стакан дай бог раз в месяц - сервис самого скрипта даже для ручной торговли намного удобнее, но тут случилась забавная наводка: скрипт стал ловить сделки по заявкам другого скрипта, причём второй вообще работал на другой тачке. Поэтому учёт действий от "левой" торговли я ему запретил: не моё - пошли на!

Игорь М, То и имею в виду: статус заявки практически однозначно определяется информацией от сделки. Если я заказал 10 лотов, и у меня сделка на 10, то заявка исполнена. А если там, допустим, 8, то она активна, и будет исполнена, если уже в следующей сделке придут остальные 2 или две сделки по единичке. Или вообще больше ничего не придёт, заявка останется частично исполненной.

Nikolay, Лично я пользоваться OnOrder не собираюсь - хватает того, что OnTrade приходят пачками на одно событие! И в таблицу ордеров заглядываю только для снятия несработавших заявок.

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

Игорь М, Никак. А зачем они нужны? Если число лотов обнулилось, значит заявка исполнена, если нет - активна (прерывание же пришло), если в дальнейшем снимется по каким-то причинам, значит больше прерываний по ней не придёт, а когда будем снимать по таймеру, если на тот момент она будет ещё активна, получит KILL_ORDER.

nikolz, Чем Вы и занимались всё это время: "Вы не в теме, кина не видел, специально для Вас из Вики, попробую объяснить Ваши заблуждения, мой ликбеза", не говоря уже про огромное количество просто дурацких тезисов, преподносимых в качестве постулатов. И что Вы хотели? Вполне закономерно получили щелчок по носу.

Так это ИМЕННО Я "пытался высказать свое понимание и свою логику", т е дать собеседнику новую информацию, не унижая его, а разъясняя ему - ВСЕ мои тезисы я обосновываю, Вы же практически ни один: "не сложно понять" - прелесть какое обоснование! Кстати, унизить человек может только сам себя - со стороны это невозможно.

А что же Вы ТОЛЬКО СЕЙЧАС выдаёте "своё понимание"? Да и зачем мне Ваше понимание? Вы для меня совершенно не авторитет, и моё понимание совершенно другое: интерпретируемым языком был ещё самый первый Бейсик, когда никто и слыхом не слыхивал ни о каких виртуальных машинах и даже о  псевдокоде. Луа, к тому же, компилируется, т.е. переводится на ДРУГОЙ язык, который и исполняется, так что Луа есть просто кусок текста, и не более того - разве что инфа для компилятора.

Да не надо мне лапшу вешать про "достоинство таких языков" - я просил ответить, с какого бодуна ИМЕННО ЭТО говно вдруг оказалось востребованным! И цель ВМ вовсе не в том, что "виртуальная машина может быть установлена на любом железе и нет надобности под это железо переписывать пользовательские программ" - вряд ли существует в природе машина, для которой не было бы компилятора с С. Интерпретатор - это возможность программирования данными, всё остальное по сравнению с этим просто мелочь пузатая.

Опять тезисы дурацкие косяком... Моя первая персоналка имела 640К ОЗУ, 5М винт и 4.7МГц частоту. И не было НИ ЕДИНОГО случая, чтобы она не успевала отреагировать на нажатие клавиш или движение мышкой! У нынешнего же стада просто вечные "проблемы в быстродействии и объеме требуемой памяти"! Как вы умудряетесь их огребать - уму непостижимо! А уж "на микроконтроллерах" чего только ни "разворачивали" - в т.ч. при моём непосредственном участии.

Ха-ха-ха! Значит, "относительно того что и как у меня делают между собой скрипты, то тут я ТОЖЕ ошибаюсь"? А что, было что-то ещё? Я пока что вижу, что ошибаетесь только Вы, причём буквально в любом Вашем тезисе.

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

Айдар, Сдвигать, разумеется, незачем - любой бит можно проверить и без него. Например, я в OnTrade узнаю, покупка это или продажа:
if bit.band(n.flags,4)~=0 then...

А активность заявки я проверяю уже в таблице 'orders'
if bit.band(s.flags,1)~=0 then...
Это уже по таймеру, если заявка не исполнена (или частично исполнена), но всё-таки зарегистрирована (есть в таблице) и активна - значит, будем снимать через KILL_ORDER.

Игорь М, Нет, я тоже именно из OnTrade получаю информацию и о сделке, и о заявке, и о транзакции, никаких дополнительных телодвижений для этого не требуется.

Игорь М, Файл-то зачем? И другой скрипт тоже. Достаточно поставить заглушку на момент получения реальной цены и время от времени её корёжить.

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

nikolz, Продолжим...

Ха-ха-ха! А на кой мне "разбираться в исходниках (!!!) VM Lua"? Я же ПОЛЬЗОВАТЕЛЬ языка, а не РАЗРАБОТЧИК! Заняться больше нечем? К тому же, я прекрасно знаю, что при ЛЮБОЙ реализации доступ по ключу В ПРИНЦИПЕ не может быть прямым! Ибо прямой доступ есть доступ ПО УКАЗАТЕЛЮ (хотя даже такой способ адресации называется "косвенная"). Замечу, что любому дебилу понятно, что "указатель - это и есть любимое мною целое", как и то, что никаких целых в языке НЕТ. За что следует яйца пообрывать его создателям.

О, Господи! Если создатели И В САМОМ ДЕЛЕ "сортируют не строки, а их хеш", то они в очередной раз ДЕБИЛЫ! Это мой "сортир" сортирует массивы в миллионы, а иногда даже в миллиарды элементов, а здесь ЧТО Вы вообще собрались сортировать? Десяток-другой элементов пару раз в день? Да простой "пузырёк", который пишется в 5 секунд, справится с этой задачей, причём БЫСТРЕЕ, чем этот идиотизм, поскольку не требует накладных расходов. Именно им я сортирую взятки, и только после совершённых сделок по тикеру либо после переноса взяток между таймфреймами, и даже не ради самой сортировки (в 99 случаях из 100 массивы эти и так изначально отсортированы), а для объединения сделок с одинаковой ценой в одну. Кстати, вопрос: ЕСЛИ "луа сделает из имени целое число- хэш и далее для извлечения этого элемента будет использовать это целое как индекс", то КТО будет поддерживать эти индексы в актуальном состоянии? Пушкин? Так что действительно "не стоит на зеркало пенять".  

Egor Denisov, Никак. Ловля блох в стиле HFT, да ещё и на таком медленном инструменте, как Квик, ни к чему хорошему не приведёт. Максимум, что можно сделать - если у Вас УЖЕ есть заявка в нужную сторону, при таких прострелах хватать то, что есть по BID или OFFER, и только для того, чтобы зафиксировать прибыль, если она есть.

nikolz, Нет, дочитаю уж пост до конца... ну, про диалог я в прошлом сообщении всё сказал, а "задача взаимодействия робота с биржей, сервером брокера и терминалом QUIK" тоже реализована безобразно, начиная с позорнейшего факта прихода нескольких прерываний на одно событие (про свечи я просто молчу - это уже экспонат для Кунсткамеры). Буквально вчера закончил (надеюсь) отладку OnTrade в связи с изменившейся технологией торговли в новой версии скрипта, причём о таких ошибках наверняка даже не подозревает подавляющее большинство участников форума - думаю, включая лично Вас. Рассказываю:
а) Каждый таймфрейм может в любое время подать заявку на покупку или продажу.
б) Эти заявки могут быть отвергнуты скриптом (по разным причинам), исполнены путём переноса взяток между таймфреймами (если они сумеют договориться) либо попасть в стек заявок для реального исполнения. Стек организован потому, что тикеров под контролем много, таймфреймов ещё больше, почти все они почти всегда хотят поторговать (в ту или иную сторону) и при одновременной подаче нескольких заявок Квик просто захлебнётся.
в) В полусекундном обработчике одна из заявок изымается из стека и либо отвергается, либо отправляется в Квик.
г) При приходе первой сделки по этой заявке (ID заявки нам ещё не известен, контролируем по ID транзакции) мы её обрабатываем. Если заявка исполнена полностью, ставим счётчик на 15 секунд (чтобы гарантированно пришли все дубли прерывания), после чего свечной обработчик удалит паспорт заявки из стека. В противном случае продлеваем счётчик ещё на 3 минуты для последующих сделок по этой заявке.
д) При приходе прерывания с тем же ID заявки и ID сделки это дубль уже обработанного - игнорируем.
е)  При приходе прерывания с тем же ID заявки, но с другим ID сделки это новая сделка по той же заявке, заменяем ID сделки на новый и обрабатываем заявку по тому же алгоритму.
Уже само описание этой технологии говорит о том, что существующий программный интерфейс Квика сделан, мягко говоря, неудачно, но неприятности на этом только начинаются, ибо прерывания могут приходить вразнобой, хотя и очень редко, и только для тех заявок, которые реализуются в несколько сделок. Тогда, если уже после замены старого ID сделки на новый снова придёт прерывание со старым ID (одного из уже обработанных), скрипт уже не поймёт, что это именно дубль и учтёт это прерывание как новую сделку, что недопустимо. А потому приходится делать множественное поле для ID сделки, а контроль дублей производить по всем этим ID. Вчера же одна из моих заявок в 4 лота растянулась на все 4 сделки, и  прерывания по ним в количестве 12 штук пришли именно "крест-накрест собачьим шагом". Последняя версия OnTrade прекрасно расправилась с ними со всеми, и теперь я считаю эту процедуру отлаженной. А со всеми этими "программами на чистом СИ взаимодействующими с VM Lua через API C for Lua" что прикажете делать? Они же тоже практически НИЧЕГО не умеют!

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

Ладно, хватит для второй порции.

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

1) Да неужели?! Во-первых, а что такое "скриптовый язык"? Тыкаем в первую попавшуюся ссылку в Гугле - там аж "Обзор скриптовых языков программирования", и первый же раздел называется "Понятие о скриптовых языках", и первая же фраза в нём гласит:
Что такое "скриптовый язык"? Это туманный вопрос, в котором содержатся два термина - "скриптовый" (scripting) и "язык" (language), произошедшие из областей, не имеющих отношения к компьютерам. Смысл, в котором эти термины используют многие люди, расплывчат. Даже такое простое слово, как "язык", легко можно использовать неверно.
То есть, как я и предполагал, никто из вас, умники хреновы, вообще не знает, что это такое.

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

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

Честно говоря, мне жаль выбрасывать средства организации диалога в SINT – за долгие годы там накопилось немало интересных решений: горизонтальные, вертикальные, двумерные, трёхмерные, виртуальные (невидимые), неоднородные, редактируемые меню, управление курсором, горячие клавиши, виртуальные клавиши, клавиши «внутрь» и «наружу» для каскадных (Z-меню), трёхмерных или двумерных меню специального вида (XZ или YZ), организация контекстной помощи и диагностики на ошибки, автоопределение координат или палитры, работа мыши в активных и неактивных координатах меню, локальные меню блоков, синхронизация изменения данных в параллельных окнах, плавающий размер паспорта меню, возможность задания собственного «бланка» меню с указанием на нём координат элементов, переопределение объектов до прорисовки меню, до цикла ожидания события, во время ожидания, после обработки события, перед выходом из меню (одно это расширяет возможности программиста со страшной силой – можно, например, организовать меню из элементов базы данных с их подкачкой и редактированием), разгон при листании некоторых видов меню… да разве всё перечислишь!

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

БорисД, Notepad - это и есть блокнот.   Но редактор Far в 100500 раз лучше - ты видел, что он способен вытворять с объёмными логами, пока мы с тобой курили на балконе.

nikolz, Да на кой мне Вики, если я сам на нём больше года программирую? И я уже несколько раз говорил, что я чуть ли не единственный на этом форуме, кто программирует на чистом Lua, так что это ВЫ "не в теме", это У ВАС получается типа - "кина не видел, но считаю, что конфетка". Мне плевать, что там "на луа написано" и для чего его и "создавали изначально", язык - ГОВНО! Редкостное говно! Динамическая типизация, убийство типа integer, кастрированный goto... ЧАВО?! Она по сравнению с JS "отличается более мощными и гибкими конструкциями"?! Это какими ж такими? Огласите весь список, пжалста!

Не "реализация большого числа программных сущностей минимумом синтаксических средств", а эмуляция этих сущностей через жо... через механизм key-value, который с какого-то бодуна регулярно обзывают "таблицами". Вот что "Lua предназначен для пользователей, не являющихся профессиональными программистами" - верю безоговорочно: ни один программист ТАКОГО говна написать не в состоянии! Ах, да - я ведь чуть ли не сразу после появления на этом форуме писал:

29.09.2020 10:31:16
Убрать тип integer из языка, на мой взгляд, есть самая большая дурость. Ладно, бог с ним, с никому не нужным boolean - пусть будет, если нравится, но с целочисленными переменными я за долгие годы программирования (а я уже пенсионер!) работал раз в 10 чаще, чем с вещественными! Если не во все сто.

Ну вот, по Вашей ссылке, первым же предложением: "Tables in Lua are not a data structure; they are the data structure. All structures that other languages offer---arrays, records, lists, queues, sets---are represented with tables in Lua". Иными словами, никаких структур данных просто НЕТ! Печально... А уж "обоснование" и вообще курам на смех: "Хотя мы МОЖЕМ (!) реализовать массивы и списки, таблицы мощнее. Многие алгоритмы упрощаются до тривиальности с использованием таблиц". И дальше вообще издевательство: "Например, вы редко пишете поиск в Lua, потому что таблицы предлагают прямой (!!!) доступ к любому типу". Ребятки, доступ по ключу - это не прямой, а как раз КРИВОЙ доступ к данным! Даже если обозвать ключи "индексами". Уши бы надрать этому "Роберто Иерусалимскому!

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

Или, скажем, 25.03.2021 12:28:31
Какие "индексируемые таблицы" - побойтесь Бога! Мне чуть ли не с первого дня стало очевидно, что тут постоянно путают индексы и имена, что является источником многочисленных глюков - в том числе, и в основном ПО Квика (таблица заявок, я об этом не раз писал). Язык отвратителен, и только за убийство типа integer и замену его на вонючий "тип number" создателей нельзя подпускать к компу ближе, чем на километр - об этом и о многом другом я тоже писал. Как и о том, что синтаксис, про который Вы здесь соловьём заливаетесь, вообще не имеет значения - профессионалу всё равно, на каком языке писать, была бы обеспечена требуемая функциональность.

Для справки: все эти "далеко ушедшие вперёд" неучи, которыми написана заметка в Вики, на которую здесь давалась ссылка, всё-таки в курсе, что элементы строки не обязательно байты, но, судя по всему, ВААПЩЕ без понятия, что строки могут быть НЕ ТОЛЬКО текстом, что это именно АЛГОРИТМИЧЕСКОЕ понятие (и пофиг какая у них конкретная реализация): строки событий или, скажем, мультиязычные строки для них тайна за семью печатями. Или что тривиальная буферизация файловых операций даже при работе с текстовыми файлами читает и пишет, с точки зрения прикладника, именно строками, а обмен с диском при этом происходит массивами (секторами или там кластерами).

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

nikolz,
Убийственная характеристика редактору! Лучше помню только фразу Кернигана из статьи "Почему Паскаль не является моим любимым языком программирования": "Три из четырёх известных мне компиляторов с Паскаля написаны на Си".

Здесь уже советовали пользоваться блокнотом - его ещё не успели основательно изуродовать, хотя и он всё чаще норовит писать в юникоде. Лично я много лет пользуюсь встроенным редактором Far Manager и примерно столько же лет ничего лучшего просто не ищу. Он даже подсвечивает переменные, открывающие и закрывающие скобки (в т.ч. операторные), если файл имеет расширение .lua, но это мелочь. А вот то, что там макросы есть...

Anton, Да, наверное что-то в этом роде. Сейчас этот бид сменился, свечки тикают, но мой скрипт обиделся и больше не хочет его продавать (BDTX)    

Anton, А что такое "фильтр по инструменту слетел"? Мне брокер сказал, что если стоит "умный заказ", то все остальные настройки не имеют значения, я всё равно должен получать реальные данные.

Нет, цена выставлявшейся заявки тоже стояла, как вкопанная - она же и есть бид! У меня, вообще-то стоит запрет новой сделки по той же цене - она должна хоть немного шевельнуться, но этот уровень устанавливается только после совершённых сделок, а нужно, судя по всему, ещё и при снятии несработавших заявок.

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

Нет, внутри колбека не идет работа с окном - только работа с логом, то бишь вывод в файл. Ладно, будем пока считать, что марсиане прилетели, и в софте что-то сбойнуло.  

Решил поднять эту ветку, а не заводить новую.

Время от времени (очень редко, не более 10 раз за всё время торговли) я сталкивался с ситуацией: скрипт выставляет заявку, она не срабатывает, снимается по таймеру, и тут же выставляется снова по той же цене. И так несколько раз. Я никогда не обращал на это внимания (заявки обычно всё равно срабатывали, сдвинув цену на пару пунктов), но теперь, в связи с причёской новой версии, решил разобраться, раз уж снова напоролся на именно такой случай. Итак, скрипт хочет продать, причём по BID - цена его устраивает. Выставляет заявку, и... BID стоит, как вкопанный, а мой придурок ставит, снимает, ставит, снимает... вот так пять часов и простоял! Обычно у меня в таких случаях одновременно с "заявка зарегистрирована" выскакивает сразу и "удовлетворено", а здесь... что бы это могло означать?

Вчера же напоролся и вообще на очень странную штуку. Как известно, прерывания на одно событие приходят пачками (именно по этой причине я использую из коллбеков только OnTrade, как минимально необходимое и уже в нём самом давлю паразитные вызовы). Но вчера я всё обвистовал отладочной печатью: решения о подаче заявок скриптом, момент передачи их в стек заявок и вывода оттуда, занесение в стек сделок и "снятие с учёта", сами сделки (первичная она, вторичная или дубль) и все выходы на ошибки. Короче говоря, время работы этих утилит должно, по идее, резко замедлиться. Так вот, один раз (только один, больше не повторилось) я получил в логе диагностику, от которой просто глаза полезли на лоб: не закончив обработку первого коллбека, снова появилась строка диагностики о начале обработки коллбека. Если я что-нибудь в чём-нибудь понимаю, этого не может быть потому, что не может быть никогда: коллбек не может быть вызван, пока не завершено выполнение другого коллбека - тем более, этого же самого. Вопрос: может ли В ПРИНЦИПЕ такое случиться? После того, что мне довелось здесь наблюдать, я уже ни в чём не уверен.

БорисД, А что тебе дают эти точки упертости? Вроде как сигнал, что кто-то крутой закупается либо сбрасывает свои бумаги. Если он реально крутой, рынок должен пойти в противоположную сторону от той, в какую он пытается идти. А если окажется не совсем крутой, то в ту же самую. А нам куды бечь, вверх или вниз? Или вообще подождать, кто окажется круче и бежать вместе с победителем?

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

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

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

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

Aleksandr, Насколько я помню, sendTransaction возвращает не nil, а пустую строку либо строку с описанием ошибки.
Двигать заявки я никогда не двигал - с фьючерсами вообще не работал, а на акциях краем уха слышал, что такого сервиса и нет, только снять и поставить.

nikolz, А я не чайник - я профессионал. И как бы я ни матерился на Lua, у меня никогда не возникало ни малейших сомнений, что писать нужно ТОЛЬКО на нём. Проблем с производительностью, как я уже писал, у меня не было никогда - в отличие от регулярно плачущих здесь пользователей таких библиотек. Никакого "torch7" я писать не собираюсь, и даже не собираюсь выяснять, что это вообще такое. А в моей "библиотеке", целиком расположенной в коде моего единственного скрипта и уже много месяцев обеспечивающего возможность полноценной торговли... ща посчитаю... ровно 21 функция.

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

Старатель, Вы здесь главный тролль и есть. Задолбали вечным скулежом по самым смехотворным проблемам! Программировать сначала научитесь, а уже потом доставайте техподдержку своими дурацкими пожеланиями. Впрочем, и потом тоже не надо.

s_mike@rambler.ru, Причём ни одна из них не нужна, "ибо порядковый номер свечи, который даже хранить не надо, ОДНОЗНАЧНО идентифицирует её время". Курьеры, курьеры, можете представить себе, тридцать пять тысяч одних курьеров! Таблиц на несчастное время В ТЫСЯЧУ РАЗ больше, чем у меня на всё! Даже больше, чем в тысячу! При этом контроль по несчастным  "10 инструментам и 5 таймфреймам"! Какой CPU подобное издевательство выдержит? У меня вдвое больше таймфреймов, вдвое больше брокеров и в 100-200 раз больше инструментов. И процессор дохленький. И памяти два гига. И никаких проблем ни с памятью, ни с производительностью - только вот Квик всё чаще начинает виснуть "без объяснения причин", иногда - "неизвестное программное исключение", иногда "unknown hard error". Да и может ли быть иначе, если софт постоянно корёжить по заявкам таких вот деятелей?

nikolz, Не вижу ничего "прикольного". Софт перестаёт работать, причём весь. В очередной раз задаю вопрос: сделано ли ХОТЬ ЧТО-НИБУДЬ за весь XXI век в сфере программного обеспечения, что могло бы быть расценено хотя бы как "полезное"?

TGB, Во, блин - опять эта пидарасина отвисла на ровном месте (которая 8.13.3.1). Полчаса уж как висит, причём МОЛЧА! Как на таком говне работать?

TGB, Я уже говорил: моя 32-разрядная Хрюша не поддерживается, мой старенький Хром, на ней стоящий, не устраивает теперь даже сраную Яндекс-почту, и меня перестало пускать на нём даже сюда! Захожу вот (пока что) с того же компа, но под Оперой. Надолго ли?