Construit plus haut que 660, encombrant le disque dur avec des fichiers journaux et ralentissant la vitesse d'optimisation. - page 3

Nouveau commentaire
 

Le répertoire du fichier journal est toujours présent dans le répertoire /tester, il se peut simplement que le vôtre soit dans le dossier UserData puisque j'utilise MT4 en mode /portable.

Oui, vous pouvez lancer le testeur via la ligne de commande, mais cela ne sert à rien, la journalisation est faite en interne au programme depuis la version 670, il n'y a aucun moyen de la désactiver par une ligne de commande.

Rediriger la sortie vers NUL n'a rien à voir avec la journalisation interne. Tout ce que votre idée ferait, c'est de rediriger la sortie d'une boîte d'invite de commande vers nul (c'est-à-dire la sortie texte réelle). Pour une application avec une interface graphique comme MT4, cela ne fait absolument rien.

 

Encore plus de plaisir avec les bûches !



 

hmm - un de mes frères a mis à jour la b765 - peut-être que cette version a perdu cette 'fonctionnalité' ?

Utiliser un script powershell qui supprime immédiatement tous les fichiers journaux de votre dossier dans le temps ?

PAS TESTE ! !

$path = "C:\Program Files\MetaTrader\tester\logs"   #  correct path?
while($true) {                                      #  endless loop switch off manually!!
    $files = Get-ChildItem -Path $path |  Where-Object {-not $_.PsIsContainer -and $_.name -like "*.log"}
    foreach ($file in $files) {                     #  Folder are excluded
       Remove-Item $file.FullName -Force -ErrorAction SilentlyContinue  
    }
    Start-Sleep -s 60                               #  sleep 60 seconds 
}
 
OK, je vais vérifier B765. Comme indiqué, les fichiers journaux sont verrouillés par metatrader.exe pendant son exécution, vous ne pouvez pas les supprimer sans fermer le terminal au préalable, ce qui annulerait l'optimisation actuelle.
 

C'est pourquoi :

Remove-Item $file.FullName -ErrorAction SilentlyContinue  

Les fichiers qui n'ont pas pu être supprimés sont "silencieusement [...]" contournés et supprimés la fois suivante.

Je pense que vous pouvez enlever -Force (c'est ce que j'ai fait).

 
Mais "la prochaine fois" est trop tard car cela signifierait après un redémarrage du terminal (une fois les fichiers déverrouillés), auquel cas le disque dur serait déjà plein (ce qui est mon véritable problème). "Force" ne fonctionne pas non plus, j'ai essayé, mais comme je l'ai dit, les fichiers sont verrouillés par Metatrader jusqu'à ce que le terminal soit éteint et votre script échoue donc.
 

NON ! la prochaine fois, ce sera après le sommeil de 60 secondes ! Ne l'ai-je pas écrit ?

Chaque minute, le script recherche les journaux à supprimer !

Comme - à mon avis - un test ne bloque qu'un seul fichier journal, le fichier créé précédemment peut être supprimé - mais essayez vous-même.

Je ne peux pas car je n'ai rien à optimiser en ce moment...

 
mt4user2000:

Que voulez-vous dire ? Les journaux dont je parle enregistrent chaque SL qui s'est produit pendant l'optimisation pour chaque passage de l'optimisation. Je les ai déjà postés, alors qu'est-ce qui doit être interprété différemment dans ceux-ci ? Ils montrent clairement ce qu'ils enregistrent et ce n'est pas du tout le problème, le problème est QU'ils enregistrent alors qu'ils ne devraient pas le faire pendant l'optimisation car cela encombre le disque dur.

Vous ne lisez pas les messages des autres.

J'ai posté mes logs à partir desquels vous pouvez voir que j'utilise le stoploss et que le stoploss est déclenché par le système. J'ai également indiqué sous quels builds j'ai fait des tests.
Mais vous posez les mêmes questions auxquelles j'ai déjà répondu.

Et dans le même temps, vous publiez de grands logs ne contenant aucune information.

mt4user2000:

Et puis-je vous suggérer d'apprendre à TROUVER des logs ? Pendant X posts, vous me dites "non, il n'y a rien d'enregistré" dans les builds 670 et 745 et maintenant, tout d'un coup, vous dites qu'il y a des enregistrements sur votre système aussi ? LOL

Je t'ai déjà dit que ce comportement est déclenché d'une manière ou d'une autre et qu'il faut évidemment un autre facteur que l'optimisation génétique pour le montrer.

Mais il est plus facile et pratique d'écrire LOL LOL que de lire et d'essayer de comprendre.

Aussi, quel est votre problème ? Supprimez le SL et sortez des transactions avec OrderClose().

Par votre écriture, il est évident que vous êtes conscient que MQ ne se soucie pas de ce bug ou de tout autre bug mineur.

 

graziani,

Ce n'est pas la solution la plus appropriée, mais vous pouvez essayer d'empêcher metatrader.exe d'écrire dans le répertoire de log en modifiant les ACL du répertoire de log.

Attention : ne le faites que si vous savez ce que vous faites.

salutations

 

graziani : désolé, je ne commenterai pas davantage vos messages.

gooly : oui je vois ce que tu veux dire, mais il ne peut toujours pas supprimer les fichiers journaux, ils sont verrouillés et cela ne fonctionne donc pas. Essayez vous-même.

ics-mq4 : c'est quelque chose que j'ai essayé aussi et cela fonctionne, mais cela ralentit l'optimisation d'un facteur 10 malheureusement. C'est probablement parce que Metatrader est bombardé d'erreurs car il ne peut pas écrire dans le répertoire et essaie à nouveau plusieurs fois avant d'abandonner. Une autre astuce consiste à supprimer le répertoire "logs" et à créer un fichier du même nom, auquel cas Metatrader ne peut plus créer le répertoire "logs". Mais la même chose se produit dans ce cas, un fort ralentissement de l'optimisation.

1234
Nouveau commentaire
Raison: