MultiCharts: Trading Software for Automated Trading and Backtesting

For the last two days my PLEditor (version 2.0, file version 1.6.966.24865) is very unstable; when I'm not using it for a while it freezes and consumes up a lot of resources (see task manager picture).

The signals which I have open in de editor are already compiled so the editor has 'nothing' to do for me.

I cannot reproduce it with a fixed numer of actions, but it happens several times a day now.

Can I do something to prevent this?

Rob.

Hi Rob,

Could you please give us at least some information on what you do before PLEditor freezes and begins to consume a lot of memory? We need as much information as possible to reproduce the problem.

Regards.

Hi Marina,

That's a fast response. Thank you! I'm not sure which action I did before the PLEditor freezes. I'm doing mainly strategy development.

That is changing signal code by interpreting the corresponding charts and than run a lot of optimizes on the signal parameters and change again the code. 'The status of the signal in MC is a lot of times verifying'.

Just at this moment the PLEditor freezes again, I had to stop its process. It look likes it happens more than yesterday. Maybe I'm more productive today .

I will try to reprocuce the error; I know it's very important to find the responsible piece of code for it.

Regards,
Rob.

Hi Marina,

Maybe this can help you with the problem. When PLEditor is unstable and I want to reboot my machine. MC ask me to save a changed 'workspace' which I don't made: MCActiveX1. See screenshot.

Regards,
Rob.

Hi Rob,

We'll keep monitoring the PLEditor's behaviour and I will keep you posted on the results.

Regards.

Marina,

I can now reproduce this behaviour of the PLEditor:

Take a symbol with lots of bars (N); make a strategy (signal) which have a print statement for every bar; optimize this strategy with lots of simulations (M).

The output window of the PLEditor will be filled with the output of the print statementS (N * M) and I think that these enormous prints let the PLEditor become unstable.

With regards,
Rob

Rob,
The program is not designed to handle such large amount of printing. You should comment out the print statement when you want to optimize.

Rob,
The program is not designed to handle such large amount of printing. You should comment out the print statement when you want to optimize.

Andrew,

It's good to provide the users with the facts as they are known, and so thanks for being upfront about the current situation and suggesting a workaround.

That said, I would consider this unacceptable as a permanent situation in a professional platform.

This is just the sort of "instability" that I've suggested needs to be remedied sooner rather than later.

The program has a print statement, the program has an optimizer. The program should not crash or become unstable when they are used together.

Of course, the demands on the machine would be very high in this situation, and things might slow down, you might not be able to process incoming tick streams in realtime, etc. This is all understood.

However, just saying, "Oh, it crashes when you do that!" is not a response that people trying to build a trading business are going to find acceptable in their primary platform.

Every strategy or technique is a candidate for having many print statements in it, for debugging purposes if no other. Generally these will be switched OFF when not debugging, but failure to do so should not cause a crash or cripple the program operation in general.

I disagree. You should be guided by a common sense when you use a program or other stuff.
You will crash or damage any system if you push it to its limits.
It is true for Windows programming or for any system.
We can't make a document for each problem situation user can possibly make.
Will you find a notice in your car that you will get your engine blown if your revs are 8000 for 30 minute?