Erreurs, bugs, questions - page 906
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
Lorsque vous devenez programmeur, vous devez comprendre que c'est vous qui commencez à consommer des ressources avec vos demandes. Le fait d'appeler des fonctions coûteuses ne signifie en aucun cas que vous pouvez vous déconnecter de la question de savoir "comment les ressources sont réellement gérées".
Le meilleur moyen est de poster le code complet ici dans le forum et la zone problématique sera immédiatement détectée. Si vous ne pouvez pas le faire ici, vous pouvez le faire dans le Service Desk (le code sera supprimé après les contrôles).
ps : nous n'avons jamais de problèmes lorsque le système d'exploitation nous dit qu'il n'y a pas assez de mémoire et nous ne blâmons jamais Microsoft pour cela.
Tout de même, je vais écrire ce dont je me suis abstenu auparavant.
Oui, je suis conscient qu'il existe des sociétés qui cherchent à forcer la vente de produits et à augmenter leurs profits par tous les moyens. Il existe des conspirations de cartels, par exemple. Et Microsoft, qui est réputé pour ses changements cycliques de programmes visant à ralentir son système d'exploitation qui souffre depuis longtemps (ce qui pourrait bien être vrai), est presque constamment en état de collusion avec les géants du matériel qui rêvent aussi de se tordre les mains en se dépêchant de vendre aux consommateurs de Windows leur nouveau matériel coûteux pour remplacer l'ancien et parfaitement utilisable qui n'a pas encore vécu sur les plates-formes Unix ou un vieux Windows.
Le MQ ne m'a jamais donné l'impression qu'il voulait me lier avec une aiguille de fer et me laisser sans sous-vêtements. MT4 et MT5 ont toujours fait preuve d'une réactivité et d'une convivialité décentes au fil des ans, notamment par rapport à ces applications .NET Framework relativement récentes, omniprésentes et peu maniables. Il n'y a donc rien de mal à cela, et c'est ce que j'aimerais voir à l'avenir. Il est important de disposer d'informations complètes sur les nouvelles constructions et d'informations complémentaires sur les modifications des exigences minimales, etc., afin que nous sachions à quoi nous préparer mentalement, intellectuellement et financièrement.
Et en passant, concernant les accusations des développeurs dépendants envers les développeurs primaires : Microsoft ne force personne à mettre à jour sans alternative. Vous ne pouvez pas désactiver les mises à jour automatiques pour une raison quelconque. Donc.
Je vais tout de même écrire ce que je me suis abstenu d'écrire plus tôt.
Vous n'auriez pas passé plus de 5 minutes à créer une application de service-desk. Et peut-être auriez-vous reçu une réponse définitive dès le lendemain.
Mais vous préférez discuter avec Renat d'une conspiration de Microsoft contre les utilisateurs.
Ne dites pas après cela que vous avez vraiment un problème ;)
après une mise à jour tranquille vers la dernière version, les agents supprimés ont commencé à tomber :
Quelqu'un envoie les mauvaises données. Avant cela, les agents se plantaient discrètement (sans que vous le remarquiez) à cause de la division par 0. Cette division par 0 ne devrait pas exister en principe, donc nous n'avions pas de contrôle correspondant. Cette personne n'est peut-être pas un intrus, nous attendons donc une demande de sa part au bureau de service. Nous n'avons pas été en mesure de reproduire cette erreur nous-mêmes.
UPD
J'ai soudain vu la ligne de journal
Cela montre que votre agent a bien été utilisé comme agent distant. Vous connaissez donc la source du problème. J'aimerais parler à Servicedesk.
Quel est le
2012.12.19 21:33:50 Core 01 2004.04.02 20:15:00 Violation d'accès en écriture à 0x000000000009
Montré pendant le backtest de la stratégie.
Quel est le
2012.12.19 21:33:50 Core 01 2004.04.02 20:15:00 Violation d'accès en écriture sur 0x000000000009
Montré pendant le backtest de la stratégie.
Erreur dans l'envoi d'un message à servicedesk
Renat, eh bien, j'ai toujours des problèmes avec la version 32 bits, mais pour la première fois j'ai eu la chance de tester le code sur la version x64 de MT5. Et voici ce que j'ai découvert...
Il n'y a pas eu ces erreurs que la version 32 bits du terminal produisait, mais il y a eu des problèmes avec le dessin initial incomplet (c'est-à-dire avant que je ne passe manuellement à d'autres horizons temporels) des présentations graphiques et le décalage occasionnel des points de liaison de certains objets par rapport aux extrema ainsi que le décalage des séries graphiques d'un indicateur auxiliaire. Jusqu'au dernier moment, je préparais un discours enflammé pour ServiceDesk, mais après une douzaine de lancements du terminal (incluant même plusieurs redémarrages complets de l'ordinateur), tout s'est miraculeusement stabilisé. Je ne sais pas et ne peux même pas deviner la logique de tout cela, mais mon impression est que pendant ces dizaines de redémarrages, le terminal a semblé "s'accélérer" et s'est finalement "adapté" à l'OS et/ou à l'indicateur du terminal. Oui, cela semble mystique, mais logiquement il ne devrait pas en être ainsi : le seul "ajustement" est le chargement complet de l'historique, la mise en cache des périodes utilisées, le réglage manuel fin des options du terminal et... Cela semble être tout. Mais tout cela a été fait au premier démarrage, et les exécutions terminales suivantes n'ont pas différé de la deuxième dans leurs états (le dernier téléchargement de l'historique et l'ajout de drapeaux de nouvelles au graphique ne sont pas pertinents, nous ne les prenons donc pas en compte).
Je suis encore un peu confus, je suppose que les problèmes vont se manifester de manière semi-inattendue et que je m'en occuperai, mais ce n'est pas encore pour tout de suite, en attendant - optimisation du code prévue. S'il est intéressant de tester le code pour vous seul, faites-le moi savoir avant que je ne disparaisse à nouveau.
Regardez dans le catalogue historique et voyez des centaines de mégaoctets de données historiques.
Par "miraculeusement stabilisé", vous voulez dire que toute l'histoire a été gonflée ? Il faut s'y attendre - l'histoire est gonflée par la nécessité et cela peut prendre du temps.
Regardez dans le catalogue historique et voyez des centaines de mégaoctets de données historiques.
C'est le contraire qui est vrai. Sous le contrôle visuel personnel tout l'historique est téléchargé au premier démarrage, à la fin du téléchargement il est vérifié avec la touche Home en allant au début de 1994 sur M1. Ensuite, je contourne manuellement les horizons temporels que j'utilise fréquemment, ainsi que ceux qui sont pertinents pour l'indicateur multitemporel, j'attends leur formation et je recharge le terminal. C'est tout.
D'autres petits téléchargements de nouvelles données d'historique n'ont pas d'effet principal, c'est-à-dire que théoriquement, le terminal peut être considéré comme "stabilisé" après le chargement complet de l'historique à la fin de la première exécution ou, pour plus de fiabilité, au tout début de la deuxième exécution, lorsqu'il est garanti que les chronologies non générées par M1 se sont installées sur le disque dur. Mais cela reste théorique. Pour une raison quelconque, tout s'est arrangé (je parle du bon fonctionnement de l'indicateur) à peu près au dixième redémarrage, bien que, je le souligne, l'histoire principale était déjà chargée au premier, et les suivants ne devraient pas pouvoir faire le temps en principe... Je dirais même au contraire : plus l'histoire prend de l'ampleur d'une manche à l'autre, plus le risque est grand que l'indicateur ne l'avale pas à une manche donnée et échoue, mais en fait c'était l'inverse : plus ça allait loin, plus ça marchait).
Il existe donc peut-être des processus cachés et non évidents pour l'utilisateur du terminal ou de la combinaison MT5 + OS, qui optimisent l'application dans l'environnement d'exploitation, non pas immédiatement, mais après quelques ajustements. Je ne modifie pas mon propre code source pendant une longue période, en ce qui concerne sa compilation - seulement au premier lancement d'un MT5 nouvellement installé (dont la construction est toujours la même dans cette étude). Il n'y a pas eu d'ajustements après le premier passage. Toute cette situation mystérieuse m'a rappelé le menu"Démarrer" de Windows, où les applications fréquemment appelées étaient disponibles en premier (le système d'exploitation recueillait des statistiques, mais cela prenait du temps et un certain nombre d'appels aux mêmes programmes). Ou encore, la défragmentation des fichiers du disque optimise l'accès au disque et permet aux applications de fonctionner plus rapidement, ce qui revient au même.
Je ne suis pas enclin à croire que vous avez implémenté quelque chose de similaire dans MT5, sinon soit vous l'avez signalé vous-même, soit vous auriez été surpris à poser des questions à ce sujet sur le forum depuis longtemps. Ce n'est donc qu'une hypothèse non confirmée basée sur l'expérience.