Erreurs, bugs, questions - page 932

 
notused:

Les agents à distance abandonnent régulièrement (plusieurs fois par semaine) depuis plusieurs mois, faute de place :

ou

et les logs de l'agent sont soit propres soit :

et il y a en fait beaucoup d'espace :

Apparaît lors du test de quelque chose de lourd (je veux dire, une vue multiple de 10 outils sur une période d'un an ou deux). Il semble qu'à un moment donné, l'agent veuille créer un mégafichier (bien qu'il n'y ait pas d'impression ou de travail avec des fichiers dans l'EA). Dans l'ensemble, il est devenu très difficile de travailler...

Comptage : un an d'historique de tics (tous les tics en mode M1) nécessite environ 3 Go d'espace disque pour les fichiers temporaires (surveillez le dossier "...\tester\Agent-0.0.0.0-xxxxx\temp", lorsqu'un travail lourd est en cours). Multiplier par le nombre d'agents. 17 Gb sont déjà sur le point d'être atteints (et si vous avez 8 agents, vous les avez dépassés).

Drôle de nom pour un conseiller expert. ;)

PS.Le testeur (743) s'embourbe dans des limites sans nom...

 

Aidez-nous, s'il vous plaît. Pourquoi ne trouve-t-il pas la transaction (erreur 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());
  }
}

Liste des terminaux :

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:

Faites le calcul : un an d'historique de tics (avec tous les tics sur M1) nécessite environ 3 Go d'espace disque pour les fichiers temporaires (surveillez le dossier "...\tester\Agent-0.0.0.0-xxxxx\temp" lorsque vous avez un travail lourd). Multiplier par le nombre d'agents. 17 Gb sont déjà sur le point d'être atteints (et si vous avez 8 agents, vous les avez dépassés).

Drôle de nom pour un conseiller expert. ;)

Merci ! Je n'aurais pas pu deviner que 16 Go ne seraient pas suffisants. Je vais transférer les agents sur un autre disque - 650 Go devraient suffire.

J'ai l'habitude de voir cela aussi - surtout quand mon ordinateur est occupé. Mais dernièrement, lorsque l'ordinateur est chargé, un seul test exécuté tue le terminal (ce n'est pas à cause du manque d'espace - le terminal est situé là où il y a 650 Go d'espace libre). Mais si tu tues tous les processus possibles, tout va bien.
 
voix_kas:

Aidez-nous, s'il vous plaît. Pourquoi ne trouve-t-il pas de transaction (erreur 4755) ?

Il peut y avoir un problème avec HistoryDealSelect si le code a été testé dans le testeur de stratégie.

lien


 
sion:

Il peut y avoir un problème avec HistoryDealSelect si le code a été testé dans le testeur de stratégie.

ping


Si j'utilise une construction avec HistorySelect(), tout fonctionne bien.

Cela ne fonctionne pas avec OnTradeTransaction. Cet événement se produit probablement avant que les informations relatives à la transaction ne soient placées dans une base de données. Malgré l'indication explicite dans la documentation :

TRADE_TRANSACTION_DEAL_ADD -ajout d'une transaction à l'historique. Elle est effectuée à la suite de l'exécution d'un ordre ou d'une opération de solde de compte.

 
voix_kas:

Si j'utilise HistorySelect(), tout fonctionne bien.

OnTradeTransaction ne fonctionne pas. Cet événement se produit probablement avant que les informations relatives à la transaction ne soient stockées dans une base de données. Malgré l'indication explicite dans la documentation :

TRADE_TRANSACTION_DEAL_ADD -ajout d'une transaction à l'historique. Il est fait suite à l'exécution d'un ordre ou à la réalisation d'une transaction dans le solde du compte.

Ici nous avons testé que cela fonctionnait à travers HistorySelect(), la même demande à travers HistoryDealSelect échoue déjà. Sur cet exemple, la vitesse de placement dans la base de données n'a eu aucun effet.

Donc dans le testeur de stratégie, vous vérifiez ? Sur le réel, très probablement, cela fonctionnera bien.

 
sion:

Ici nous avons testé, cela a fonctionné à travers HistorySelect(), la même demande à travers HistoryDealSelect échoue déjà. Dans cet exemple, la vitesse de placement dans la base de données n'a eu aucun effet.

Donc dans le testeur de stratégie, vous vérifiez ? En réalité, il est probable que cela fonctionne bien.

Je confirme, ce code avec le castellate comme HistorySelect() fonctionne bien:

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());
  }
}

Il reste à attendre que le développeur corrige ce bug évident.

 
Oui, je vérifie dans le testeur de stratégie. Il n'y a pas de problème en temps réel.
 
voix_kas:
Oui, je vérifie dans le testeur de stratégie. Aucun problème en temps réel.
Tintz. Ça pourrait être utile, et rien n'a probablement changé non plus.
 
sion:
Yountz. Cela peut s'avérer utile, probablement que rien n'a changé non plus.

Quoi qu'il en soit, j'ai trouvé une solution de contournement pour mon besoin. SansOnTradeTransaction.

Il y a une question supplémentaire concernant la fonctionHistoryDealGetTicket().

La documentation indique qu'elle renvoie le numéro de ticket de la transaction. Cependant, les cas de retour d'erreur ne sont pas décrits explicitement, par exemple, la valeur retournée doit-elle être vérifiée pour ">0" ?

De même avec HistoryOrderGetTicket(). Cependant, ce dernier exemple contient la vérification de la valeur positive retournée.

Une recherche sur le forum montre que les gens vérifient la valeur de retour tant dans le cas d'une commande que dans le cas d'une transaction.

Il est fort probable qu'une telle vérification doive être effectuée dans le cas, par exemple, d'une demande de transaction dont le numéro d'ordre est supérieur à HistoryDealTotal()-1. Mais je suis reconnaissant aux développeurs pour la clarté de la documentation sur le langage MQL5.