This is something that should be really easy to implement if you desire to do it.
Would you please add a feature to auto-save your c# strategy before running any backtest? In my strategy, I'm writing diagnostics to the Debug Log. After the strategy completes and click that tab, the program will "not respond" if I write too many lines. If literally waited for hours to it to complete and never does.
Would you please add a feature to auto-save your c# strategy before running any backtest? In my strategy, I'm writing diagnostics to the Debug Log. After the strategy completes and click that tab, the program will "not respond" if I write too many lines. If literally waited for hours to it to complete and never does.
Rename
And why would anyone want to overwrite an old strategy that is functional with one that hasn't even been tested yet? What will happen is you'll end up with a modified strategy that doesn't work in place of the original strategy that was somewhat functional.
I always test out any changes I make to a strategy before saving it.
I don't understand. Why on earth would you be saving that many debug lines? (I wouldn't want to look through that many debug lines.) I would troubleshoot the strategy graphically as much as possible to locate the problem quickly; annotate the Chart with program-flow events if you have to. If you must use debug lines (like for testing lexical manipulations), I would use debug lines as sparingly as possible. Work smart, not hard. That approach makes programming (and debugging) fun.
I always test out any changes I make to a strategy before saving it.
QUOTE:
After the strategy completes and click that tab, the program will "not respond" if I write too many lines. I've literally waited for hours ...
I don't understand. Why on earth would you be saving that many debug lines? (I wouldn't want to look through that many debug lines.) I would troubleshoot the strategy graphically as much as possible to locate the problem quickly; annotate the Chart with program-flow events if you have to. If you must use debug lines (like for testing lexical manipulations), I would use debug lines as sparingly as possible. Work smart, not hard. That approach makes programming (and debugging) fun.
Fully agree with @superticker.
You're advised to troubleshoot the underperforming strategy code (or simply not put the program to its knees) first rather than submitting (what was) a feature request. 🤷♂️
WAS: Auto-save C# Strategy before running backtest
IS: Writing too many lines to Debug Log makes WL not respond
You're advised to troubleshoot the underperforming strategy code (or simply not put the program to its knees) first rather than submitting (what was) a feature request. 🤷♂️
WAS: Auto-save C# Strategy before running backtest
IS: Writing too many lines to Debug Log makes WL not respond
I read your posts and appreciate your responses. And I respectively agree with your comments, but not completely. And I don't like putting in diagnostics unless I absolutely need it. I made a mistake and put in diags that created a large amount. Your program should be able to handle diagnostics to the Debug Log, whether small or large. It doesn't handle large. The program crashes. On a side note, when developing using Visual Studio (which I've used for 28+ years), it ALWAYS saves your code before building. Why can't WL8 do the same?
We’ll add a task in our dev queue to improve handling of large debug logging.
Thanks Glitch.
The issue is the WPF control we were using (RichTextBox). After changing it to the same Editor control we're using in the C# editor the load time in my tests decreased from 1.5 minutes to 0ms :)
Your Response
Post
Edit Post
Login is required