Erreurs, bugs, questions - page 2556
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
C'est vraiment quelque chose d'horrible. Il faudrait en savoir beaucoup sur les perversions pour envelopper le retour dans une macro :) Comment traiter un tel code alors... Nous devrions au moins rendre le nom de la macro plus descriptif - TRY_OR_RETURN, etc.
)))
J'ai vu à quoi ça ressemble et je ne l'utilise pas, je l'écris à l'ancienne if(!myfunc()) return ; dans OnTick() - le code est plein de ifs ... Il a l'air plutôt mignon et drôle aussi ))))
Forum sur le trading, les systèmes de trading automatisé et les tests de stratégies de trading
Nouvelle version de MetaTrader 5 build 2085 : Intégration avec Python et améliorations massives dans le testeur de stratégie
Andrey Barinov, 2019.09.06 06:25
Pouvez-vous encore expliquer pourquoi il y a un avertissement dans ce code maintenant ?
Les méthodes ont des signatures différentes...
Forum sur le trading, les systèmes de trading automatisé et les tests de stratégies de trading
Nouvelle version de MetaTrader 5 build 2085 : Intégration avec Python et améliorations massives dans le testeur de stratégie
Andrey Barinov, 2019.09.06 06:11
typename() cassé dans la build 2136
S'il vous plaît, réparez-le.
Cet indicateur fait planter le système.
Et avec le changement de résolution d'écran et avec des pixels clignotants et le redémarrage nécessaire de l'ordinateur.
De plus, si vous n'appelez pas la fonction apparemment inoffensive Crash(), vous ne vous écraserez pas.
Reproduit comme suit :
J'ai eu ce crash à chaque fois que je l'ai fait ( 6-8 fois)
Il ne s'est pas planté sur LTSC, l'erreur suivante dans le journal : MemoryException 4424265936 bytes not available, 0 heapmin result
Oui, le crash est très dur. Mieux vaut ne pas prendre de risques.
C'est une question de mémoire, bien sûr.
Si vous nettoyez la mémoire comme ceci :
il ne se plante pas non plus. Au moins, ça ne m'est pas arrivé.
Mais lorsque le TF est modifié, les tableaux doivent être automatiquement nettoyés!
Et je ne comprends pas ce que la fonction Crash() a à faire sans elle, car elle ne lit que les informations sur les indicateurs.
Peut-être que l'exécution de cette fonction ralentit OnDeinit lors du changement de TF et c'est pourquoi MT5 n'a pas le temps de vider la mémoire.
Nous avons des problèmes avec OnDeinit asynchrone depuis longtemps. Ce n'est pas bon ! Le système ne doit pas se planter à cause de l'asynchronisme...
Pourquoi lorsque vous faites défiler le graphique avec des indicateurs, le processeur charge le noyau à 100% ?
Après tout, les indicateurs ont été calculés et dessinés, selon l'idée, seule la charge de la mémoire devrait être.
Pourquoi lorsque vous faites défiler le graphique avec des indicateurs, le processeur charge le cœur à 100% ?
Après tout, les indicateurs sont calculés et dessinés, selon l'idée, seule la charge de la mémoire devrait l'être.
La charge du CPU lors du rendu des graphiques dépend directement des performances de la carte graphique.
Sur les vieux ordinateurs portables dotés de cartes faibles ou sur les serveurs dépourvus de cartes/pilotes vidéo, il y aura inévitablement un pic instantané mais bref de la charge du processeur.
Et le processeur lui-même doit être plus puissant afin d'absorber les demandes accrues sans laisser de trace.La charge du processeur lors du rendu des graphiques est directement liée aux performances de la carte vidéo.
Sur les vieux ordinateurs portables dotés de cartes faibles ou sur les serveurs dépourvus de cartes/pilotes vidéo, il y aura inévitablement une augmentation immédiate mais brève de la charge du processeur.
Et le processeur lui-même doit être plus puissant pour absorber les demandes accrues sans laisser de trace.Je parle du processeur FX-8350 et d'une carte graphique Radeon HD 7950. Je n'ai pas l'impression que la carte vidéo soit chargée par MT5.
Oui, s'écraser est très difficile. Mieux vaut ne pas prendre de risques.
C'est une question de mémoire, bien sûr.
Si vous nettoyez la mémoire avec l'aide de vos mains comme celles-ci :
alors le crash ne se produit pas non plus. Au moins, ça ne m'est pas arrivé.
Mais lorsque le TF est modifié, les tableaux doivent être automatiquement nettoyés !
Je ne comprends pas, pourquoi devrions-nous nous occuper de la fonction Crash() si elle ne le fait pas, car elle ne lit que les informations sur les indicateurs.
Peut-être que l'exécution de cette fonction ralentit OnDeinit lors du changement de TF, et donc MT5 n'a pas le temps de vider la mémoire.
Il y a des problèmes avec la fonction asynchrone OnDeinit depuis longtemps. Ce n'est pas bon ! Le système ne doit pas tomber en panne à cause de l'asynchronisme.
1) vous devez tronquer l'esturgeon avec INT_MAX(2 bn) ici :
nous allons régler cela de notre côté aussi.
2) Toute la mémoire doit être gérée de manière très stricte, pas de GC ici.
3) la réinitialisation des indicateurs lors d'un changement d'horizon temporel est chaude sans réinitialisation physique à partir de zéro, donc vous devez libérer de la mémoire par vous-même. surtout les ressources au niveau global
4) utiliser la POO, cela vous donnera au moins la possibilité de décrire et de contrôler correctement les ressources.