Erros, bugs, perguntas - página 932

 
notused:

Os agentes remotos têm vindo a abandonar regularmente (algumas vezes por semana) durante vários meses devido à falta de espaço:

ou

e os registos dos agentes estão limpos ou limpos:

e, na verdade, há muito espaço:

Aparece ao testar algo pesado (quer dizer, uma multiview de 10 ferramentas durante um período de um ano ou dois). Parece que a dada altura o agente quer criar uma megafila (embora não haja impressões ou trabalho com ficheiros na EA). Em suma, tornou-se realmente difícil de trabalhar

Contagem: um ano de histórico de ticks (todos os ticks no modo M1) requer aproximadamente 3Gb de espaço em disco para ficheiros temporários (observe a pasta "...\tester\Agent-0.0.0.0-xxxxx\temp", quando um trabalho pesado está a decorrer). Multiplicar pelo número de agentes. 17 Gb já está à beira da morte (e se tiver 8 agentes, já ultrapassou isso).

Nome engraçado para um Consultor Especialista. ;)

Otestador PS.(743) fica atolado por limites anónimos.

 

Ajuda, por favor. Porque não encontra o ofício (erro 4755)?

void OnTradeTransaction(const MqlTradeTransaction& trans,
                        const MqlTradeRequest& request,
                        const MqlTradeResult& result) {
  if ((trans.type == TRADE_TRANSACTION_DEAL_ADD) && (trans.symbol == _Symbol)) {
    if (HistoryDealSelect(trans.deal)) {
      long DealMagic;
      if (HistoryDealGetInteger(trans.deal, DEAL_MAGIC, DealMagic)) {
        //
      }
      else Print("HistoryDealGetInteger(" + (string)trans.deal + ", DEAL_MAGIC, DealMagic) = false! GetLastError() = ", GetLastError());
    }
    else Print("HistoryDealSelect(" + (string)trans.deal + ") = false! GetLastError() = ", GetLastError());
  }
}

Listagem de terminais:

2013.02.07 10:31:52   instant sell 0.01 EURUSD at 1.35354 (1.35354 / 1.35364 / 1.35354)
2013.02.07 10:31:52   deal #1028 sell 0.01 EURUSD at 1.35354 done (based on order #1028)
2013.02.07 10:31:52   deal performed [#1028 sell 0.01 EURUSD at 1.35354]
2013.02.07 10:31:52   order performed sell 0.01 at 1.35354 [#1028 sell 0.01 EURUSD at 1.35354]
2013.02.07 10:31:52   HistoryDealGetInteger(1028, DEAL_MAGIC, DealMagic) = false! GetLastError() = 4755
 
Ashes:

Faça as contas: um ano de história de carrapatos (com todos os carrapatos no M1) requer cerca de 3Gb de espaço em disco para ficheiros temporários (veja a pasta "...\tester\Agent-0.0.0.0-xxxxx\temp" quando conseguir um trabalho pesado). Multiplicar pelo número de agentes. 17 Gb já está à beira da morte (e se tiver 8 agentes, já ultrapassou isso).

Nome engraçado para um Consultor Especialista. ;)

Obrigado! Não poderia ter adivinhado que 16GB poderiam não ser suficientes. Transferirá agentes para outra unidade - 650GB, espera-se que seja suficiente.

Eu também costumava ver isto - especialmente quando o meu computador está ocupado. Mas ultimamente, quando o computador é carregado, um único teste apenas mata o terminal (não é por falta de espaço - o terminal está localizado onde há 650 GB de espaço livre). Mas se se matar todos os processos possíveis - tudo corre bem.
 
voix_kas:

Ajuda, por favor. Porque não encontra uma profissão (erro 4755)?

Pode haver um problema com o HistoryDealSelect se o código tiver sido testado no testador de estratégias.

ligação


 
sion:

Pode haver um problema com o HistoryDealSelect se o código tiver sido testado no testador de estratégias.

ping


Se eu utilizar uma construção com HistorySelect(), tudo funciona bem.

Não funciona com a OnTradeTransaction. Este evento provavelmente ocorre antes de se colocar informação sobre o comércio em alguma base de dados. Apesar da indicação explícita na documentação:

TRADE_TRANSACTION_DEAL_ADDD -adição de um comércio à história. É executado como resultado da execução de ordens ou de transacções de saldos de contas.

 
voix_kas:

Se eu usar HistorySelect(), tudo funciona bem.

A OnTradeTransaction não funciona. Provavelmente, este evento ocorre antes de a informação sobre a transacção ser armazenada em alguma base de dados. Apesar da indicação explícita na documentação:

TRADE_TRANSACTION_DEAL_ADDD -adição de um comércio à história. É feito como resultado da execução de uma ordem ou da realização de uma transacção no saldo da conta.

Aqui testámo-lo através de HistorySelect(), o mesmo pedido através de HistoryDealSelect já falha. Neste exemplo, a rapidez de colocação na base de dados não teve qualquer efeito.

Então, no testador de estratégias, verifica? Sobre o real, o mais provável é que funcione bem.

 
sion:

Aqui testamos, funcionou através de HistorySelect(), o mesmo pedido através de HistoryDealSelect já falha. Neste exemplo, a rapidez de colocação na base de dados não teve qualquer efeito.

Então, no testador de estratégias, verifica? No real, é provável que funcione bem.

Confirmo, este código com castelado como HistorySelect() funciona bem:

void OnTradeTransaction(const MqlTradeTransaction& trans,
                        const MqlTradeRequest& request,
                        const MqlTradeResult& result) {
  if ((trans.type == TRADE_TRANSACTION_DEAL_ADD) && (trans.symbol == _Symbol)) {
    if (HistorySelect(0, TimeTradeServer())) {
      for (int i = 0; i < HistoryDealsTotal(); i++) {
        ulong Ticket = HistoryDealGetTicket(i);
        if (trans.deal == HistoryDealGetInteger(Ticket, DEAL_ORDER)) {
          Print(HistoryDealGetInteger(Ticket, DEAL_MAGIC));
          break;
        }
      }
    }
    else Log("HistorySelect(0, TimeTradeServer() = false! GetLastError() = ", GetLastError());
  }
}

Resta esperar quando o revelador corrigirá o erro óbvio.

 
Sim, verifico no testador de estratégias. Não há problema em tempo real.
 
voix_kas:
Sim, verifico no testador de estratégias. Não há problema em tempo real.
Tintz. Pode vir a ser útil, provavelmente também nada mudou.
 
sion:
Yountz. Pode vir a ser útil, provavelmente também nada mudou.

De qualquer modo, encontrei uma solução para as minhas necessidades. Sem aOnTradeTransaction.

Há uma questão adicional relativa à funçãoHistoryDealGetTicket().

A documentação diz que devolve o número do bilhete da transacção. No entanto, os casos de erro devolvidos não são descritos explicitamente, por exemplo, o valor devolvido deve ser verificado para ">0"?

Da mesma forma com HistoryOrderGetTicket(). No entanto, este último exemplo contém a verificação do valor positivo devolvido.

Uma pesquisa no fórum mostra que as pessoas verificam o valor de retorno tanto no caso de uma encomenda como no caso de uma transacção.

Muito provavelmente, tal verificação deve ser feita no caso, por exemplo, de um pedido de transacção com um número de encomenda superior ao HistoryDealTotal()-1. Mas fiquei grato aos criadores pela clareza na documentação para a linguagem MQL5.

Razão: