Ошибки, баги, вопросы - страница 2938
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Да, я прекрасно помню: делать попытку предварительной фэйковой загрузки истории в OnInit. Не помогло ни там, ни в OnCalculate, даже в цикле с сотней повторов. Не знаю, как на самом деле, но внешне никакой обещанной подгрузки истории (хоть и с опозданием) не наблюдалось, результат до конца оставался неудовлетворительным.
Более того, были другие случаи, когда многократно возвращался ответ:
но в итоге продолжения отработки индикатора не было, в ответ была тишина.
Не нужно делать циклов с повторами.
Если это индикатор, то делайте однократный запрос нужного символа-периода в OnCalculate. Если не получилось, то return(0)
Возьмите время поступления тика нужного символа, нормализуйте это время к началу нужного периода, спрашивайте 1 последний бар нужного символа-периода и проверяйте его время. Потом спрашивайте состояние синхронизированности истории
В зависимости от тормознутости и загруженности ресурсов вашего компьютера может пройти не одна сотня OnCalculate.
Тот код, на который вы ссылаетесь - очень старый. Но он хорош для иллюстрации. Но он не годится для индикаторов, так как запросы истории из индикаторов выполняются без какого-либо ожидания (о чём в документации явно написано) и Sleep в индикаторах - бесполезен
Сервер историю отдаёт даже в выходные.
Контролируйте построение баров по времени последнего тика соответствующего символа
Если это индикатор, то делайте однократный запрос нужного символа-периода в OnCalculate. Если не получилось, то return(0)
Ну return(false) в случае неудачи — это же классика. Так и делаю. Всё бы хорошо, но проблема в том, что дальнейшие расчёты у меня завязаны на успешную загрузку истории (и эту логику не изменить), а в случае неудачи и возврата из функции расчётов они просто не осуществятся и дальнейшие графические построения не получат нужных координат, всё сползёт. Как этого избежать — пока не придумал и надежд что-то изменить тоже не предвидится. Пока что у меня так: либо вся история загружена и все таймсерии по всем ТФам построены и индикатор срабатывает почти мгновенно и без пропущенных из-за return(false) расчётов, либо части истории не хватает, код по return возвращается в функцию более высокого уровня и там в бесконечном цикле пытается запросить недостающую историю, что ни к чему не приводит. От третьего варианта — без return — и провала некоторых расчётов, из-за которых отрисовка графики получается неполноценной, я попросту отказался.
Продолжая немного сидеть в танке, всё ещё недоумеваю... Реально ли организовать беззадержечную MQL-логику индикатора для работы только с локальной историей, без необходимости докачивать недостающую и терпеть связанные с этим задержки? Или любые функции Copy... неизбежно вынуждены обращаться к серверу для докачки даже той части истории, которая мне не нужна для обработки? Проще говоря, стандартные же индикаторы моментально отрисовываются на имеющейся на ПК истории, безо всякой докачки (я прошёлся поиском по индикаторам в папке Examples — там от силы используется только CopyBuffer(), и то далеко не во всех)... или же докачка скрыта от глаз? Но тогда для чего она нужна?
Спасибо. Над Вашими рекомендациями обязательно поразмышляю — возможно, они мне пригодятся.
Несколько часов был не у компа. В это время возникла нештатная ситуация и робот стал строчит очень много принтов. В итоге забился полностью диск. А это нарушает работу Терминалов, т.к. они не могут скинуть на диск свою историю цен.
Нужно недопустить подобного забивания диска. Один вариант - запрет записи в папку. Т.е. жить без логов на диске всегда. Другой - убивать лог-файлы, когда осталось мало свободного места.
Кто-нибудь решал такую проблему.
Если это индикатор, то делайте однократный запрос нужного символа-периода в OnCalculate. Если не получилось, то return(0)
А если нужно запустить индикатор на выходных?
Только принудительный вызов ОнКалкулейт из таймера (со всеми вытекающими костылями в виде копирования массивов для передачи по ссылке)?
Реально ли организовать беззадержечную MQL-логику индикатора для работы только с локальной историей, без необходимости докачивать недостающую и терпеть связанные с этим задержки? Или любые функции Copy... неизбежно вынуждены обращаться к серверу для докачки даже той части истории, которая мне не нужна для обработки?
Можно сделать свой кэш (записывать в файлы).
Когда такое предложили мне, я, конечно, покрутил у виска, но это действительно лучше, чем ждать изменения подхода к работе с тайм-сериями от MQ.
Несколько часов был не у компа. В это время возникла нештатная ситуация и робот стал строчит очень много принтов. В итоге забился полностью диск. А это нарушает работу Терминалов, т.к. они не могут скинуть на диск свою историю цен.
Нужно недопустить подобного забивания диска. Один вариант - запрет записи в папку. Т.е. жить без логов на диске всегда. Другой - убивать лог-файлы, когда осталось мало свободного места.
Кто-нибудь решал такую проблему.
Ради интереса метнулся у себя проверить и ударил пол челюстью: 183 Гб! Это почти 4/5 от моего SSD. Образы виртуальной машины меньше занимают. Зато будет что в старости почитать...
Ради интереса метнулся у себя проверить и ударил пол челюстью: 183 Гб! Это почти 4/5 от моего SSD. Образы виртуальной машины меньше занимают. Зато будет что в старости почитать...
Print и Alert - потенциально опасные функции.
Price=0.7235200000000001С какой стати? Ошибка или надо вывод причёсывать к единому виду? Ну, положим, PrintFormat'ом или fprint'ом я причешу, но в принципе такое не является некорректным представлением числа?