Errors, bugs, questions - page 651
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
No, it is not only a 32-bit terminal's problem. But the solution for the 32-bit terminal is ready for today while in the 64-bit terminal there is still a stack limitation in 256Kb.
But if the programmer does not specify the needed stack size manually using a property, the EX5 in the terminal will work with the default stack size ( 256Kb).
About the big size.
Each variable declaration inside a function (except for static variables) allocates space on the stack, and allocation of space on the stack for local variables occurs at each call.
Therefore, if a function has 64Kb local variables, stack space is enough for 3 calls nested within it, and stack overflow occurs at 4 calls (as part of the stack is used for internal needs of the terminal). Therefore, if there is a need for large local data, it is better to use dynamic memory - when you enter the function, memory for local needs is allocated in the system (new, ArrayResize) and when you exit the function, memory is deleted (delete, ArrayFree).
Thank you for the detailed explanation. But that's definitely not my problem. I will try to write a test Expert Advisor to detect this error, since the function where the legs are growing is already found and there are no such volumes (64Kb - 256Kb). I will send an expert to Service Desk with the problem function at night then.
One more question (and a request to explain it in the help) about the work of the same function(CLBufferWrite()).
If I write information directly from the indicator buffer with the ArrayIsSeries flag set (==true), in what direction the input array will be read?
I suspect that the flag will be ignored, and besides it is not clear from which place it will be read? Will the shift be counted from the array's physical end or from the beginning at all?
Of course, I'll blow on water just in case (I'll work with ArrayIsSeries== false), but still ?
offset - these functions are really offsets in bytes from the beginning of the OpenCL buffer and the array passed to the function will be copied from null item without taking into account the ArrayIsSeries flag.
1) Currently, the functionality of working with the OpenCL buffer is not complete and will be added/updated.
2. offset - these functions are actually an offset in bytes from the beginning of the OpenCL buffer while an array passed into the function will be copied from the zero element without taking into account the ArrayIsSeries flag.
1. I sort of suspected so... :)
So, there's no way to write directly from the indicator buffer in parts (for now).
A good idea is, of course, to make the starting positions movable in both the source and receiver. Like here:
int ArrayCopy(
void dst_array[], // куда копируем
void src_array[], // откуда копируем
int dst_start=0, // с какого индекса пишем в приемник
int src_start=0, // с какого индекса копируем из источника
int cnt=WHOLE_ARRAY // сколько элементов
);
With indexing (direction and units (bytes/elements)) please be more careful in the help. :)))
--
Thanks for the reply, I really appreciate your efforts to improve the functionality.
I'll look forward to patiently waiting for the banquet to continue. In the meantime, I'll have to dance on the edge of a dagger. :)
Build 597 x64, just installed.
2012.02.23 21:43:24 OpenCLTest (EURUSD,M30) SaveBitmapToFile error opening 'Mandelbrot.bmp'
2012.02.23 21:43:13 OpenCLTest (EURUSD,M30) SaveBitmapToFile error opening 'Mandelbrot.bmp'
2012.02.23 21:43:12 OpenCLTest (EURUSD,M30) SaveBitmapToFile error opening 'Mandelbrot.bmp'
2012.02.23 21:43:10 OpenCLTest (EURUSD,M30) SaveBitmapToFile error opening 'Mandelbrot.bmp'
2012.02.23 21:43:09 OpenCLTest (EURUSD,M30) SaveBitmapToFile error opening 'Mandelbrot.bmp'
2012.02.23 21:43:08 OpenCLTest (EURUSD,M30) SaveBitmapToFile error opening 'Mandelbrot.bmp'
2012.02.23 21:43:07 OpenCLTest (EURUSD,M30) SaveBitmapToFile error opening 'Mandelbrot.bmp'
2012.02.23 21:43:06 OpenCLTest (EURUSD,M30) SaveBitmapToFile error opening 'Mandelbrot.bmp'
This has never happened before.
// Win7 x64
Build 597 x64, just installed.
It wasn't like this before.// Win7 x64.
Try recompiling the example. I checked it - it works for me.
I've already recompiled it a hundred times. I'm going to reboot again.
... I'm gonna reboot again.
Nope, did not help.
Renat:
...... I checked - it works for me.
It works for me too, but every ten or forty cycles I get the same crap:
2012.02.23 23 16:16:43 OpenCLTest (EURUSD,M30) SaveBitmapToFile error opening 'Mandelbrot.bmp'
2012.02.23 23 16:16:42 OpenCLTest (EURUSD,M30) SaveBitmapToFile error opening 'Mandelbrot.bmp'
2012.02.23 23 16:16:36 OpenCLTest (EURUSD,M30) SaveBitmapToFile error opening 'Mandelbrot.bmp'
Nope, didn't help.
This works for me too, but every ten or forty cycles I get this crap:
Also discovered.
This is because the specified file is being handled in two different threads without synchronization and occasionally the file gets locked:
Since the example with the image was made only to demonstrate the principle of working with OpenCL, it is not a problem.
Since the example with the picture was made only to demonstrate the principle of working with OpenCL, it is not a problem.