Erreurs, bugs, questions - page 1124
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
Bien que les deux structures aient la même taille et se copient l'une dans l'autre sans perte, nous recevons quand même un avertissement.
Donc c'est génial. Il n'est pas si difficile de faire une caste évidente. Et il n'est pas très agréable de savoir où attribuer quoi lorsque des bugs commencent à se glisser.
Copie de l'application à SR :
Version du terminal et bit
910 32 bits
Description du problème
Bonjour, chers développeurs !
Dans MQL5, un certain nombre de fonctions système telles queCopyRates,CopyTime,CopyOpen, etc. sont destinées à recevoir des données de séries temporelles.
Lorsque vous appelez l'une de ces fonctions, la série chronologique demandée est chargée en RAM dans le paramètre "Max bars in chart".
Cependant, la combinaison de facteurs tels que :
1. Historique suffisamment profond disponible sur le symbole ou entièrement chargé depuis le serveur.
2. Le paramètre "Max bars in chart" est "Unlimited".
3. Les données de la plus petite période de temps M1 sont demandées.
Une très grande quantité de mémoire est consommée.
Le problème est exacerbé par le fait que la logique du programme exécutant MQL5 (par exemple, s'il s'agit d'un Expert Advisor multi-devises ou d'un indicateur)
peut être prévu pour un accès alterné aux données de bas niveau de plusieurs symboles (par exemple, recherche unique).
En conséquence, la consommation de RAM est multipliée.
Получение данных нужного таймфрейма из промежуточных данных
Les fichiers de service dans le format HCC jouent le rôle de source de données pour construire les données de prix dans les délais demandés dans le format HC. Les données dans le format HC sont des séries temporelles qui sont préparées au maximum pour un accès rapide. Ils sont créés uniquement à la demande d'un graphique ou d'un programme mql5 dans un volume ne dépassant pas le paramètre "Max bars in charts", et sont sauvegardés pour une utilisation ultérieure dans des fichiers avec l'extension hc.
Afin d'économiser les ressources, les données de l'échéancier sont chargées et stockées dans la RAM uniquement lorsque cela est nécessaire.En cas d'absence prolongée de demandes, les données sont déchargées de la RAM et sauvegardées dans un fichier. Les données pour chaque période sont préparées indépendamment des données prêtes pour les autres périodes. Les règles de préparation et de disponibilité des données sont les mêmes pour toutes les périodes. C'est-à-dire que, malgré le fait que l'unité de stockage des données dans le format HCC est la barre des minutes, la disponibilité des données dans le format HCC ne signifie pas la disponibilité et l'accessibilité des données du format HC pour la période M1 dans le même volume.
La réception de nouvelles données du serveur entraîne la mise à jour automatique des données de prix utilisées au format HC pour toutes les périodes et le recalcul de tous les indicateurs, qui les utilisent explicitement comme données d'entrée pour le calcul.
Le timing du processus surligné en jaune sur la citation de la documentation est assez important : environ une demi-heure (d'après mes observations).
Par conséquent, toutes les séries temporelles demandées se trouvent dans la "RAM" sans aucune raison.
Si la "RAM" n'est pas en caoutchouc Et le conseiller expert/indicateur "vorace" demande de plus en plus de séries temporelles, le terminal n'a rien d'autre à faire...
sauf pour un "vidage" urgent des séries temporelles excédentaires vers le fichier (cache). Ainsi, dans cette réinitialisation d'urgence, le terminal peut réinitialiser les séries temporelles à
un "cache cassé", c'est-à-dire qu'il perdra "une bonne moitié" des données. Et la prochaine fois que l'on accède à cette série chronologique, le terminal charge ce "cache cassé" comme un cache normal.
En conséquence, le graphique du terminal affiche les séries chronologiques nécessaires avec un énorme trou dans l'historique.
Résultat attendu
Le langage MQL5 tend à économiser les ressources de l'environnement d'exécution. En voici un exemple :
1. la fonctionArrayFree
2. fonctionresourceFree
3.supprimer l' opérateur
4. Paramètre"Max bars in charts
Est-il possible d'ajouter une fonction système à la fonctionnalité du langage MQL5 qui obligerait le terminal à effectuer des opérations avec les séries chronologiques qui ne sont plus utilisées ?
S'il n'y a pas de graphique ouvert avec cette série temporelle, à la fin du timing ?
Par exemple, une fonction :
bool SeriesFlush(
string symbol_name, // имя символа
ENUM_TIMEFRAMES timeframe, // период
);
Cela permettrait :
1. ne pas s'inquiéter du débordement de la RAM.
2. ne vous inquiétez pas des "caches cassés" dont vous ne pouvez vous débarrasser qu'en supprimant manuellement les fichiers *.hc lorsque le terminal est éteint.
3. vous ne devez pas dépendre du mode binaire de votre système d'exploitation et de la taille de la mémoire vive.
4. lors du développement d'un produit logiciel, n'utilisez pas de "béquilles" qui tentent de contourner les inconvénients décrits ci-dessus.
Copie de l'application à SR :
Pouvez-vous me dire comment obtenir les données de l'indicateur avec un décalage positif ? Je suis intéressé par les données sur la barre -1 ?
Pour ce faire, vous devez connaître les paramètres de décalage pour la ligne d'indicateur qui vous intéresse. Voici un exemple tiré de l'indicateur techniqueiAlligator
Il s'agit d'une compensation, et non d'un calcul indicateur pour l'avenir.
Copie de l'application vers SD :
Version du terminal et mode binaire
910 32 bits
Description du problème
Bonjour, chers développeurs !
Une des recommandations pour améliorer la qualité du code lors de la conception de boucles avec un grand nombre d'itérations
consiste à intégrer la vérification d'un arrêt forcé d'un programme MQL5 en utilisant le système
Fonction systèmeIsStopped();
Cependant, en pratique, cette vérification ne fonctionne pas dans les indicateurs (elle fonctionne dans les scripts et les Expert Advisors).
Voici le code court de l'indicateur qui montre l'essence du problème :
Si vous essayez de supprimer cet indicateur du graphique, le processus de "calcul de l'indicateur" ne s'arrêtera pas pour autant,
alors qu'il devrait, à cause de la vérification du drapeau d'arrêt du programme.
Vous pouvez facilement le découvrir en surveillant le processus terminal.exe dans le gestionnaire de tâches. Sur un processeur quadri-cœur
c'est environ 25% de la charge du CPU. En outre, la charge terminale ne diminue pas du tout au fil du temps jusqu'à ce que la
l'arrêt du terminal. Et même après l'arrêt du terminal, le processus terminal.exe reste bloqué dans le gestionnaire. Et, c'est comme si,
qu'il est déchargé par le système d'exploitation comme "suspendu".
Résultat attendu
S'il vous plaît, réglez ce problème.
Pour ce faire, vous devez connaître les paramètres de décalage pour la ligne d'indicateur qui vous intéresse. Voici un exemple tiré de l'indicateur techniqueiAlligator
Il s'agit d'une compensation, et non du calcul de l'indicateur pour l'avenir.
J'ai un calcul du futur, mais j'utilise un décalage pour le rendre, comment puis-je calculer -1 barre à partir de l'Expert Advisor ?
Si quelqu'un en a besoin, utiliser CopyBuffer(Handle_original,0,-2,10,Data_Ind )
Exactement, j'ai un calcul dans le futur, mais pour dessiner un décalage, comment puis-je lire la barre -1 de l'Expert Advisor ?
Probablement une erreur de calcul (MT\930\32)
Je ne l'ai pas calculé moi-même, mais avec i pair -> j = -1, et le dernier i=18446744073709551615/*ULONG_MAX */-1-> pair