Suggestion: PowerLanguage Debugging

Questions about MultiCharts and user contributed studies.
User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Suggestion: PowerLanguage Debugging

Postby Bruce DeVault » 24 Feb 2010

In TS, we have the ability to use watch lists, set break points, and use strategy commentary as additional tools to debug EasyLanguage code. What would it take to have these types of features added to PowerLanguage so that debugging wasn't restricted to just the use of print statements? Also, error messages such as "division by zero" as a simple example should always be reported with a function/study/signal name and line number whenever possible, so that these types of things can be tracked down more easily in large programs.

Rick Webber
Posts: 47
Joined: 04 Jan 2008
Has thanked: 21 times
Been thanked: 3 times

Postby Rick Webber » 25 Feb 2010

This is crazy not having these features. Very, very necessary. I have to use TS to debug the code. Not good.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Postby bowlesj3 » 27 Feb 2010

How do the TS break points work? Does it cause the input of ticks into the study to step after the debugging stepping action drops out the bottom of the study allowing you to continue the debugging stepping action with the next tick? Can you actually do this during the trading day or can it be done after hours? If you can do it during the trading day after you let it run at full speed does it do a recalculate to get back on track or actually do a catch-up? I would think having this available has a fair overhead. Can you switch it off fully by having a compile for debugging and a regular compile?

It is nice when during the debugging step action you can place the cursor over any variable and see its value. Can it do this?

The most advanced debugger I have ever seen was the MicroFocus Cobol debugger (an IBM creation). It had all the watch list stuff. It could break when a variable changed and it actually worked without ever screwing up (actually it never screwed up while any feature was being used). I seem to remember it could break if a variable hit specific values = < >. You can actually write temporary traps with the MF debugger and insert them wherever you want (fairly complex fairly long temp traps without changing your normal code and when it hits the jump point it diverts to the trap then when out of the trap it just continues on with the normal code). It had a varying speed feature. You could run forward slowly at varying speeds. You can run full speed if you press zero and almost fully stopped if you press 1 with increases in speed if you press 2 up through 9. This allows you to rush up to code into a loop then slow it down gradually to a full stop. Very useful. One of the very best programmers I ever worked with did not know the debugger. She had a bug she just could not figure out. I showed her how to do that and we found the problem within about 5 minutes (after she worked on it already for about 2 days solid). What I had her do is start the code from where she felt the problem was starting but we ran it at a visiable speed. She could see that it went into a loop and exactly where that was occuring (right before her eyes). We stopped it and she found the problem immediately. Once stopped, in the Microfocus Cobol debugger you can actually step backwards up to a preset number of steps (200, 400 whatever). I don't think they had it good enough that you could see memory when tracing backwards (just the statements). However it could continue on after doing a trace back. It had everything that VBA has and much more. However VBA has probably come a long way since those days. LOL! Tomorrow TSS support. Tomorrow. I am kidding of course :D

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 27 Feb 2010

TS's debugger has breakpoints in that it can pause and examine variable values, then resume calculations. You can step through code by running to the next breakpoint, etc. It has watch windows in that you can see historical and present values for variables that have been selected in the treeview of available inputs, variables, etc. For reference, if you have TS available, check the help under "About the EasyLanguage Debugger".

The standard these days is pretty much Microsoft's Visual Studio, but because TS's debugger is focused on how these concepts apply to EasyLanguage (which has some unique considerations), it's probably the best reference point for where to begin.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Postby bowlesj3 » 27 Feb 2010

Yes EL is unique. It probably would be helpful to have a "break on Bar#" or "Break on time_s" command (including maybe a range of these so the user can debug selected ranges of bars). Then the recalculate would execute and all the ticks would come back in rather than just summarized ticks where you only get barstatus=2. It would be similar to the replay MC has now which I have used a few times to test new code off hours with the final testing during live trading.

janus
Posts: 835
Joined: 25 May 2009
Has thanked: 63 times
Been thanked: 104 times

Re: Suggestion: PowerLanguage Debugging

Postby janus » 27 Feb 2010

Yes, it's becoming too clear that PLEditor needs a complete revamp for two big reasons. One, it lacks a lot of features pointed out here. Two, it has too many bugs. Just today I lost a whole study that took me a lot of time to develop. When I opened it up it was empty. Fortunately, I had backups so I restored it. PLEditor is too primitive a development environment even compared to many free tools. It needs to be thrown away and a new one developed ASAP. I was using really good editing tools over 25 years ago on VT220 terminals that had better features than PLEditor!

User avatar
TJ
Posts: 7740
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1033 times
Been thanked: 2221 times

Re: Suggestion: PowerLanguage Debugging

Postby TJ » 27 Feb 2010

...I was using really good editing tools over 25 years ago on VT220 terminals that had better features than PLEditor!
and VMS doesn't crash either. ;-)

User avatar
Bruce DeVault
Posts: 438
Joined: 19 Jan 2010
Location: Washington DC
Been thanked: 2 times
Contact:

Postby Bruce DeVault » 28 Feb 2010

Yes EL is unique. It probably would be helpful to have a "break on Bar#" or "Break on time_s" command (including maybe a range of these so the user can debug selected ranges of bars). Then the recalculate would execute and all the ticks would come back in rather than just summarized ticks where you only get barstatus=2. It would be similar to the replay MC has now which I have used a few times to test new code off hours with the final testing during live trading.
Since in EL you always have access to the code you are debugging, it's simple then to add a line that says "if barnumber = 12345 then break;" at any time while you're testing - while it would be "nice" to have a variety of inbuilt conditions for common needs, that's actually not necessary and all we really need is the one breakpoint capability, as the user can always insert it where ever desired, including inside of a condition to handle any desired place to pause. I wouldn't want them to hold off on doing this until they could do something fancier - just a simple breakpoint capability would be helpful.

bowlesj3
Posts: 2180
Joined: 21 Jul 2007
Has thanked: 227 times
Been thanked: 429 times

Postby bowlesj3 » 28 Feb 2010

"if barnumber = 12345 then break;"
That sounds more like a stop command as I know it where as a break is external requiring no user code change (however that is splitting hairs isn't it). I do not believe in holding off ideas since it is up to TSS to decide what they can and can not afford (what they like or dislike). That to me is an assumed. I know for a fact that TSS is hungry for ideas and as long as they are not off the wall they see them as money in the bank (maybe a long ways off investment but at least a tool for portential improvement and profit). Of course there are no great ideas here. It is all really pretty standard stuff. To me this next idea is just standard stuff.

Continuing with the addition of ideas and TSS deciding what they can afford (what they like), EL could benefit from having a break with a built in popup that occurs when you apply the break. The default if you do not fill in any details is to break every time that code line is hit. However the user has the option to fill out the popup to qualify that break to be limited to 1 bar or a range of bars or range of bar times (maybe a check box for lastbaronchart and firstbaronchart). If the user can simply click on a bar to input that data that would make it easier still (just as they do with the replay now). The last idea may be a simple matter of borrowing some code. As stated before it goes without saying that this is their decision however. On the other hand it it is wise to let them know they are doing a great job and let them know that we do not expect these great things instantly (that includes respecting other priorities of course). So in that respect I agree with you Bruce.

Rick Webber
Posts: 47
Joined: 04 Jan 2008
Has thanked: 21 times
Been thanked: 3 times

Debugging

Postby Rick Webber » 09 May 2010

Any plans to get " CommentaryCL " working in MultiCharts in the near future?


Return to “MultiCharts”