Erreurs, bugs, questions - page 651

 
mql5:
Non, ce n'est pas seulement le problème d'un terminal 32 bits. Mais la solution pour le terminal 32 bits est prête pour aujourd'hui alors que dans le terminal 64 bits il y a toujours une limitation de la pile à 256Kb.
Mais si le programmeur ne spécifie pas manuellement la taille de pile nécessaire à l'aide d'une propriété, l'EX5 dans le terminal fonctionnera avec la taille de pile par défaut (256 Ko).

A propos de la grande taille.
Chaque déclaration de variable à l'intérieur d'une fonction (à l'exception des variables statiques) alloue de l'espace sur la pile, et l'allocation d'espace sur la pile pour les variables locales se produit à chaque appel.

Par conséquent, si une fonction possède 64Kb de variables locales, l'espace de la pile est suffisant pour 3 appels, et le débordement de la pile se produit à 4 appels (car une partie de la pile est utilisée pour les besoins internes du terminal). Par conséquent, s'il est nécessaire d'avoir de grandes données locales, il est préférable d'utiliser la mémoire dynamique : lorsque vous entrez dans la fonction, la mémoire pour les besoins locaux est allouée dans le système (new, ArrayResize) et lorsque vous quittez la fonction, la mémoire est supprimée (delete, ArrayFree).

Merci pour cette explication détaillée. Mais ce n'est absolument pas mon problème. Je vais essayer d'écrire un Expert Advisor de test pour détecter cette erreur, puisque la fonction où les jambes poussent est déjà trouvée et qu'il n'y a pas de tels volumes (64Kb - 256Kb). J'enverrai un expert au Service Desk avec la fonction de problème la nuit alors.

 

Une autre question (et une demande d'explication dans l'aide) sur le fonctionnement de la même fonction(CLBufferWrite()).

Si j'écris des informations directement depuis le tampon de l'indicateur avec l'indicateur ArrayIsSeries activé (==true), dans quel sens le tableau d'entrée sera-t-il lu ?

Je soupçonne que le drapeau sera ignoré, et d'ailleurs il n'est pas clair à partir de quel endroit il sera lu ? Le décalage sera-t-il compté à partir de l'extrémité physique du tableau ou à partir du début du tableau ?

Bien sûr, je vais souffler sur l'eau au cas où (je vais travailler avec ArrayIsSeries== false), mais quand même ?

 
La fonctionnalité de travail avec le tampon OpenCL est actuellement incomplète et sera ajoutée/décrite.
offset - ces fonctions sont en réalité des décalages en octets depuis le début du tampon OpenCL et le tableau passé dans la fonction sera copié à partir de l'élément zéro sans tenir compte de l'indicateur ArrayIsSeries.
 
mql5:
1) Actuellement, la fonctionnalité de travail avec le tampon OpenCL n'est pas complète et sera ajoutée/mise à jour.
2. offset - ces fonctions sont en fait un offset en octets à partir du début du tampon OpenCL tandis qu'un tableau passé dans la fonction sera copié à partir de l'élément zéro sans tenir compte de l'indicateur ArrayIsSeries.

1. Je m'en doutais un peu... :)

Il n'y a donc aucun moyen d'écrire directement à partir du tampon de l'indicateur dans les parties (pour l'instant).

Une bonne idée est, bien sûr, de rendre les positions de départ mobiles dans la source et le récepteur. Comme ici :

int  ArrayCopy(
   void  dst_array[],       // куда копируем
   void  src_array[],       // откуда копируем
   int   dst_start=0,       // с какого индекса пишем в приемник
   int   src_start=0,       // с какого индекса копируем из источника
   int   cnt=WHOLE_ARRAY    // сколько элементов
   );

En ce qui concerne l'indexation (direction et unités (octets/éléments)), veuillez être plus attentif dans l'aide. :)))

--

Merci pour la réponse, j'apprécie vraiment vos efforts pour améliorer la fonctionnalité.

Je me réjouis d'attendre patiemment la suite du banquet. En attendant, je vais devoir danser sur le fil du rasoir. :)

 

Build 597 x64, vient d'être installé.

2012.02.23 21:43:24 OpenCLTest (EURUSD,M30) Erreur SaveBitmapToFile lors de l'ouverture de 'Mandelbrot.bmp'.
2012.02.23 21:43:13 OpenCLTest (EURUSD,M30) Erreur SaveBitmapToFile lors de l'ouverture de 'Mandelbrot.bmp'.
2012.02.23 21:43:12 OpenCLTest (EURUSD,M30) Erreur SaveBitmapToFile lors de l'ouverture de 'Mandelbrot.bmp'.
2012.02.23 21:43:10 OpenCLTest (EURUSD,M30) Erreur SaveBitmapToFile lors de l'ouverture de 'Mandelbrot.bmp'.
2012.02.23 21:43:09 OpenCLTest (EURUSD,M30) Erreur SaveBitmapToFile lors de l'ouverture de 'Mandelbrot.bmp'.
2012.02.23 21:43:08 OpenCLTest (EURUSD,M30) Erreur SaveBitmapToFile lors de l'ouverture de 'Mandelbrot.bmp'.
2012.02.23 21:43:07 OpenCLTest (EURUSD,M30) Erreur SaveBitmapToFile lors de l'ouverture de 'Mandelbrot.bmp'.
2012.02.23 21:43:06 OpenCLTest (EURUSD,M30) Erreur SaveBitmapToFile lors de l'ouverture de 'Mandelbrot.bmp'.

Cela ne s'est jamais produit auparavant.

// Win7 x64

 
MetaDriver:

Build 597 x64, vient d'être installé.

Ce n'était pas comme ça avant.

// Win7 x64.

Essayez de recompiler l'exemple. Je l'ai vérifié - il fonctionne pour moi.
 
Renat:
Essayez de recompiler l'exemple. Je l'ai vérifié - il fonctionne pour moi.

Je l'ai déjà recompilé une centaine de fois. Je vais redémarrer.

 
MetaDriver:

... Je vais redémarrer.

Non, ça n'a pas aidé.

Renat:

...... J'ai vérifié - ça marche pour moi.

Ça marche pour moi aussi, mais tous les dix ou quarante cycles, j'ai droit aux mêmes conneries :

2012.02.23 23 16:44 OpenCLTest (EURUSD,M30) Erreur de SaveBitmapToFile lors de l'ouverture de 'Mandelbrot.bmp'.
2012.02.23 23 16:16:43 OpenCLTest (EURUSD,M30) Erreur SaveBitmapToFile lors de l'ouverture de 'Mandelbrot.bmp'.
2012.02.23 23 16:16:42 OpenCLTest (EURUSD,M30) Erreur SaveBitmapToFile lors de l'ouverture de 'Mandelbrot.bmp'.
2012.02.23 23 16:16:36 OpenCLTest (EURUSD,M30) Erreur SaveBitmapToFile lors de l'ouverture de 'Mandelbrot.bmp'.
 
MetaDriver:

Non, ça n'a pas aidé.

Ça marche aussi pour moi, mais tous les dix ou quarante cycles, j'ai cette merde :

Également découvert.

Cela est dû au fait que le fichier spécifié est traité par deux threads différents sans synchronisation et que, parfois, le fichier est verrouillé :

  1. le fil de script écrase le fichier 10 fois par seconde (dépend de la vitesse de la carte)
  2. Le graphique recharge l'image dans son propre fil à la demande du script.

Comme l'exemple avec l'image a été fait uniquement pour démontrer le principe du travail avec OpenCL, ce n'est pas un problème.

Документация по MQL5: Файловые операции / FileMove
Документация по MQL5: Файловые операции / FileMove
  • www.mql5.com
Файловые операции / FileMove - Документация по MQL5
 
Renat:

Comme l'exemple avec l'image n'a été fait que pour démontrer le principe du travail avec OpenCL, ce n'est pas un problème.

Je suis d'accord. De toute façon, il est temps de faire un transfert directement dans le tampon de l'objet GraphLabel. :)