debug mode for Prorealtime
- This topic has 15 replies, 4 voices, and was last updated 1 year ago by
.
-
see all the variables that have been created
I do it by using GRAPH function and then zooming in on a trade / a few bars.
I set up Indicators using the variable value in my strategy and display these Indicators individually under the Price chart and Positions and GRAPH output.
‘Cursor Details’ mode is very useful for this analysis work as it shows actual values for each bar and variable values etc.
I don’t do it often as I find it laborious and very time-consuming.
PeterSt is something of an expert in this fine art! He has spent 1,000’s of hours analysing trade entries and exits etc.
2 users thanked author for this post.
Thank you, GraHal.
Zero, here you have an example. The screenshot below only shows one set of Graphing variables. The screenshot is quite large, so open it in a new browser window to see it all. Especially for you this is Forex.
1234567Once Grph1 = 1 // 08-03-2022,PS. Graphing Group.Once Grph8 = 0 // 09-06-2022,PS. For All (!) entry opportunities.Once Grph9 = 0 // 16-11-2022,PS, Shows OnMarket (debug) data.Once Grph10 = 0 // 16-11-2022,PS, Shows peaks at News hours.Once Grph11 = 0 // 16-11-2022,PS. Shows Entry data. 04-12-2022,PS, But is useless so far.Once Grph12 = 0 // 23-12-2022,PS. Shows Position Management data - Interventions.Once Grph13 = 0 // 11-03-2023,PS. Shows RSI and Band data.Get inspired by the above. 🙂
And by the below ?2 users thanked author for this post.
A debug window is planned, I have seen some drafts, but I don’t know when it’s gonna be released.
1 user thanked author for this post.
Could you please be more clear? My problem is with the programming, I’ve already programmed in PHP, CSS, SQL, AJAX ..etc before, it’s an object oriented programming and we always have a database in which we can store the information we need and ask for it and fetch it on a table when we need it, But in this type of programming, the fact that you can’t see the variables that you’ve created before and that are stored or not, I’m having a bit of trouble, I think it’s because I’m getting old 😅
Hahaha , no … you are too young. If you would have been too old you would have known procedural** languages, like PRT is.
**): The kind of opposite of object-oriented languages, which latter became mainstream since the 90’s somewhere, but existed a few decades earlier already. Anyway, you would be 50 years old or so, which is by far not too old yet to learn a few more things.But you are right, programming in this “per bar” environment is something one needs to adapt to. And as a matter of fact it is so different that I applied a few first steps to incorporate the principle of “per bar” in the ERP environment (Enterprise Resource Planning – those huge software packages). Think of total net revenue per hour or per minute and such. If the software is sufficiently real-time, this can be done (think like all activities done by scanning (scanners)). I created this included real “candles”.
Per bar
The most essential thing to understand is that your program code (the complete code) is called by the higher level PRT server software, once per bar (= candle). In more detail this is : once per bar indeed (as per the definition of the chart) but also once per the set TimeFrame in the program code. Thus, bar is 1 minute, but TimeFrame for a piece of code can be 5 minutes, and that piece of code is only executed once per 5 minutes.
Well, that is all.
Sort of.The by far major lacking feature in the PRT language is not a debugger, but a means to make it structured. Thus make routines you finish and which work for once and for all (an object in the OO languages) and be done with them and not be bothered by them ever more. Note : this only gets profound really, when you start your xth Strategy and copy from something else, change appropriate pieces and discover that your changes should also be applied in the source you copied from. This is totally unmanageable and with that undoable. The editor is a piece of sh*t from ancient history and the single reason that nothing serious can be made ever, within the PRT language. But, this combines with the need for “structured” means, because without this latter, the code becomes too large to oversee. Combine this with the lack of a decent search means and there you get lost + annoyed.
N.b.: Yes, I use another editor to overcome this crucial issue.So your code is called per bar, which means : at the end/close of the previous bar or shall I say “in” the current bar. Yes, that is better to understand. So your code executes in the currently building bar and is applied when the next bar opens. Thus, place a Market order in your code, and this order is handed to the broker when the next bar opens. Assumed the order will be filled, it is thus filled when this next bar opens, and you can see this per the little triangle which will be positioned at the opening price of the bar (when readily filled). For such a triangle, see the 1st screenshot below (which is not about a market order), where you see the blue triangle for the forward(back)test, and the green one invisible right under it because the real time (live) green one falls on quite the same (price) position (it sits under the blue one). In the 2nd screenshot I zoomed out a little and you see my graphing going along with reality, BUT this is updated once per (1 minute) bar only. This is a good thing (once per 1 minute = once per bar in this case) because this is exactly when the variables we set (given a value). Thus this shows exactly what is happening. The green line in this case (also see the earlier large screenshot) shows the profit. Not that I need to see the profit, but if I make a trailing system, I must be able to see that working as intended. So again see the earlier large screenshot and the blue trailing line. Without that, making a trailing system is impossible. Oh, we could copy from Nicolas or Roberto’s code examples, but you would not be able to see whether it ever works or not. Hence the one million questions in this forum because people can’t understand what is happening.
Ah, that was your problem.
The blue little peak in the bottom pane, shows in this case the three bars the system has to Enter which goes by Limit order. Well, you see that this worked out, but the blue peak could have been there without “position” because the order was not filled (read : and/or the set price was not reached).
Debug data (you ask for) us virtually not something I personally ever use. This is because it is too static or else – for this environment !- would depict too much hassle to step through all what’s to be observed. Mind you, this is per this one bar where things went wrong in your (my) opinion and it would take a 100 years to sort tout things. I have no time for that. Not here and not in my other lives. However, I use log files all over the place. They continuously run along and when something seems amiss, I observe the log files, which of course are date/time denoted. Yes, that is crucial, and no, within PRT this is not possible.
Back to the graphing – with that you can do all. Well, for a happy few that is, because 100% of people minus myself, would attest that reality will not show the same as forward(back)test does. Indeed it takes a lot to get this right and maybe my codes are 1000s of lines because of this only. But it really can be done, see the screenshots for the example. But funny : once you have this under control and arrived there because of the explicit goal to do *that*, you’ll have your backtesting working as decent as reality will be. Think a bit about that.
Advise for now : don’t do anything else but get acquainted with this graphing. Create a Limit order and draw a line at the price you do that (the I think yellow-ish line in the large screenshot). Next, check whether indeed the limit order was filled (just per backtest) and whether the line went right through the heart of the little triangle. OK, see the 3rd screenshot below, where I show the green line, which is a (pending) Stop order. You see it going right through the heart of the triangle indeed. But you also see that the green triangle is at another place. Here, within that again one minute bar, reality was a little different from(my) theory, which is related to no real market being present for backtest. Please notice : this 3rd screenshot is from backtest and not from forward test. This should not matter much, but depending on what PRT does with historical data, it may matter slightly. In general though, for 1 minute bars any backtest will fall over historical reality. Meaning : if I show the past via backtest, the live occurrences are there just the same and they almost always match the backtest (again). … I am not sure whether I explained this clearly, but this is about first doing everything in Live (or Demo) and then with the same code you apply a backtest upon the history Live ran over. Now all should still match.
When you have this all set (then 100% minus 2 people will attest that they can do it) you can start making your strategies. Unless you can not program/code as such. But you can …Meanwhile my little code started the trailing phase. See 4th screenshot. Now is this fun or is it !
1 user thanked author for this post.
LOL – that makes my day. 🙂 🙂
Maybe don’t put your tablet on your keyboard because all sorts of unexpected orders may occur. Next you startle so much that the coffee plus the water go into your keyboard and the macbook goes blank, the orders still there. But OK, you will be left with the smiley on your tablet feeling young forever with less money (or not !).
2 users thanked author for this post.
Find exclusive trading pro-tools on 
