PLEditor unstable

Questions about MultiCharts and user contributed studies.
RS
Posts: 39
Joined: 28 Sep 2007

PLEditor unstable

Postby RS » 04 Oct 2007

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.
Attachments
task manager pleditor.jpg
(116.58 KiB) Downloaded 532 times

User avatar
Marina Pashkova
Posts: 2758
Joined: 27 Jul 2007

Postby Marina Pashkova » 04 Oct 2007

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.

RS
Posts: 39
Joined: 28 Sep 2007

Postby RS » 04 Oct 2007

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.

RS
Posts: 39
Joined: 28 Sep 2007

Postby RS » 04 Oct 2007

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.
Attachments
MCActiveX1.png
(49.97 KiB) Downloaded 525 times

User avatar
Marina Pashkova
Posts: 2758
Joined: 27 Jul 2007

Postby Marina Pashkova » 10 Oct 2007

Hi Rob,

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

Regards.

RS
Posts: 39
Joined: 28 Sep 2007

Postby RS » 05 Mar 2008

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

User avatar
Andrew Kirillov
Posts: 1589
Joined: 28 Jul 2005
Has thanked: 2 times
Been thanked: 31 times
Contact:

Postby Andrew Kirillov » 05 Mar 2008

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.

User avatar
MC_Prog
Posts: 330
Joined: 28 Feb 2007
Has thanked: 64 times
Been thanked: 35 times

Postby MC_Prog » 07 Mar 2008

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.

User avatar
Andrew Kirillov
Posts: 1589
Joined: 28 Jul 2005
Has thanked: 2 times
Been thanked: 31 times
Contact:

Postby Andrew Kirillov » 10 Mar 2008

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?


Return to “MultiCharts”