OmniTrader Professional Forum
Omni Pilot Discussion
bug in OL? Am I missing something?
15 replies, 8737 viewings
|
OmniTrader Professional Forum
Omni Pilot Discussion
bug in OL? Am I missing something?
|
Last Activity 4/26/2019 10:38 PM 15 replies, 8737 viewings |
|
|
|
| Printer friendly version |
kmcintyre Veteran   Posts: 132 Joined: 9/12/2007 Location: Valley Center, CA  User Profile |
I have been pulling my hair out trying to figure out why my #signal was not working as expected. Today I pulled some of the suspect logic out into a #indicator so I could isolate and plot the output. Line 26 prints the values of sK and sK1 Line 27 performs a conditional test on sK and Sk1 Line 28 prints the results of the conditional test The conditional test on Line 27 should evaluate to false. The logic on line 28 should not execute. But it does. There are many earlier iterations where the conditional logic on line 27 worked correctly. So for some reason OL logic changes as the indicator runs. What gives? Ideas? BTW - I have had many similar hair pulling episodes. I have ended up recoding and refactoring logic until I found something that seemed to work.. None of this exudes confidence in Ol. I really hope I am missing something with my logic. Else I don't know that I can trust OL to develop and deploy anything. Thanks for looking... | ||
| Jim Dean Sage   Posts: 3433 Joined: 3/13/2006 Location: L'ville, GA User Profile |
| ||
| kmcintyre Veteran Posts: 132 Joined: 9/12/2007 Location: Valley Center, CA User Profile |
 Attached file : OL bug.png (106KB - 498 downloads) Attached file : indDeug.txt (1KB - 469 downloads) | ||
| Jim Dean Sage Posts: 3433 Joined: 3/13/2006 Location: L'ville, GA User Profile |
The correct syntax for an “if then elseif then Elseif then end if” Structure normally includes three “then”s. Try inserting them. | ||
| kmcintyre Veteran Posts: 132 Joined: 9/12/2007 Location: Valley Center, CA User Profile |
If I use line 28 - the "<=" condition the condition evaluates INCORRECTLY If I use line 29 - the "<" condition, the conditional evaluates correctly Looks like a bug to me... Barry, Angela? BTW - Line 28 does not fail every time. That would be too easy! I had to walk through the chart, bar by bar, until I found a case where the STO() should have generated a specific state, but my indicator was showing a different state. Intermittent errors like this are the worst kind to have. They only show up during runtime - sometimes. That leads to a lot of head scratching and unstable code. And if one doesn't do a LOT of test and verification, it is really easy for one to assume code is working when it really is broken. Further, it totally undermines confidence in the resultant executables. Thanks [Edited by kmcintyre on 4/25/2019 6:56 PM] Attached file : indDeug.txt (1KB - 454 downloads) Attached file : OL bug 4.png (87KB - 489 downloads) Attached file : OL bug 3.png (88KB - 488 downloads) | ||
| Jim Dean Sage Posts: 3433 Joined: 3/13/2006 Location: L'ville, GA User Profile |
If X then … Elseif Y then … Else … End if And so on. “then” is supposed to be paired with all If and Elseif on the same line. It could be that is affecting parsing &/or execution. | ||
| Jim Dean Sage Posts: 3433 Joined: 3/13/2006 Location: L'ville, GA User Profile |
| ||
| kmcintyre Veteran Posts: 132 Joined: 9/12/2007 Location: Valley Center, CA User Profile |
I added the "then" keywords (which the compiler does not require unless the if then is a single line statement). They made no difference. As to the "rounding error", the two singles being compared are 51.56672 and 40.0. Not even close to a rounding error. This is a bug in OL that needs to be fixed. Attached file : OL bug 5.png (101KB - 483 downloads) Attached file : indDeug.txt (1KB - 459 downloads) | ||
| Jim Dean Sage Posts: 3433 Joined: 3/13/2006 Location: L'ville, GA User Profile |
Also, anyone who does a lot of OL coding can learn a lot about how OL works by reviewing that file. Pay special attention to the main bar-loop. Re if/then syntax - in the past, with more complex code than this, I’ve seen anomalies appear when the “then” is left off. Remember that even though something may work properly in true VB, it doesn’t always follow that the parser handles it the same way. | ||
| Jim Dean Sage Posts: 3433 Joined: 3/13/2006 Location: L'ville, GA User Profile |
Fwiw, I’ve found that OL is pretty solid, btw - it’s been stable for about a decade - albeit with some limitations and a few odd “features”. Change “=<“ to “<=“ and change “=>” to “>=“. Click here for docs re relational operators [Edited by Jim Dean on 4/26/2019 8:08 AM] | ||
| kmcintyre Veteran Posts: 132 Joined: 9/12/2007 Location: Valley Center, CA User Profile |
I am attaching a version of indDebug that appears to be working reliably based on 2 years of indicator readings on 1 stock. I ABSOLUTELY consider this a bug in OL. The bug was not in my logic, but with the compilers incorrect parsing of the syntax. And it cost me a week. More over, it has completely eroded my confidence in any code I write in OL. Lesson learned, do not trust OL. I must spend hours verifying the execution of any code segment, regardless of how straight forward the logic appears to be. Further, the code I just spent a week on is a VERY small part of the #system I coded. Apparently I will need to unit test every logical construct within the #system to have any confidence in the combined result. I had 3 decades of experience coding everything from machine code entered directly into a DataIO PROM programmer, to assembly, to basic, pascal, c, c++. c#. Java, and many other languages on Unix, Windows, DOS, Apple, iRMX, and many other realtime operating environments. I designed and built satcom systems, turbine and reciprocating engine control systems,, medical devices, many shrink wrap software products, and multi-tier eCom business systems. I ended my career as CTO of a Fortune 500 systems integration firm. I qualify as an EXPERT witness. And in my PROFFESSIONAL opinion... THis is a bug. Further, OT is one of the most unstable and bug ridden platforms I have ever attempted to developed code on. Of course you are entitled to your opinions. And I am entitled to my frustrations... Thanks for finding a workaround... Peace, Out Attached file : indDeug.txt (1KB - 435 downloads) | ||
| Jim Dean Sage Posts: 3433 Joined: 3/13/2006 Location: L'ville, GA User Profile |
I’m glad you got your code to work. And if I’ve somehow offended you, my apologies. I was trying to help. It appears that once you corrected the relational operator syntax, that did the trick. It would have been nice if the OL parser had identified the issue for you. | ||
| kmcintyre Veteran Posts: 132 Joined: 9/12/2007 Location: Valley Center, CA User Profile |
I wanted to verify the code on several other charts. With all the DebugMsg statements, it takes a long time to process each chart. So I commented out all the DebugMsg statements... But I am still getting messages logged to the Debug pane of the IDE. Great! So I stare at the source code for quite a while. (I am legally blind so it takes a long time and I don't trust my eyes.) I still don't see anything wrong. Well, I thought, I'll search for DebugMsg and verify they are all commented out. What!?! An IDE with no Search function? Figures... So I open the indDebug.txt in Notepad and search for DebugMsg. Yes, they are all commented out. But the funny thing is, the messages in the Debug pane are not from any version of the code I have recently worked on. Yes, I recognize the messages from a much earlier iteration. Great! So I am attaching the code (again) and a png showing some of the code and Debug log. Mostly just to document that I am not making this stuff up. Afaik,. there is no code in the current source file that would generate any of the Debug log messages. Don't tell me. It is not a bug, it is a feature Feeling all warm and fuzzy about OL - fur sure. So what file to I need to delete to make sure I am executing the code I just compiled? Does this happen often? Can I ever really trust the Debug log or the plot() on the screen? Attached file : indDeug.txt (1KB - 454 downloads) Attached file : OL buf 6.png (97KB - 440 downloads) | ||
| Jim Dean Sage Posts: 3433 Joined: 3/13/2006 Location: L'ville, GA User Profile |
Delete all files in the vba\temp folder. Restart OT and all files will recompile. [Edited by Jim Dean on 4/26/2019 10:41 PM] | ||
| kmcintyre Veteran Posts: 132 Joined: 9/12/2007 Location: Valley Center, CA User Profile |
I did that before my last post, but it didn't help. Then a couple minutes ago I had an epiphany. I had the #system that started this rat hole selected in my ToDo list via a Strategy. The DebugMsgs were being generated from that #system. I disabled the Strategy and the Debug pane stopped displaying messages. So what I don't understand is why I didn't see the DebugMsgs generated by the #system when I was debugging the indDebug.txt code. Perhaps I just missed them.. What are the rules as to what ends up in the Debug pane? Also, I think I am going to try to use an external editor to write my code. This will require the IDE and the editor to have the file open concurrently. Have you tried this? Any words of wisdom? Thanks | ||
| Jim Dean Sage Posts: 3433 Joined: 3/13/2006 Location: L'ville, GA User Profile |
OT is sort of “possessive” about OL routines that are assigned to an external construct such as an active strat or sometimes a FL column. I don’t know the “rules” related to that - it’s idiosyncratic. It doesn’t have to do with the parser or compiler but rather how and where and when OT “grabs a copy” of the routine. That’s all black box to me. The issue afaik is not debugmsg statements - the same kind of “persistence” can occur without them. The practice that I follow is to either rename the OL routine to assure that what I’m using is the latest version, or limit the exposure of the routine re Strats etc so that they can be rebuilt easily during development. Generally, though, I’ve found that just being deliberate about changes, and checking them as I go to make sure they “took“, yields satisfactory results. I’d say that maybe one in every 5000 compiles or so, I see the kind of problem you are talking about. I do a *lot* of compiles. (Ie ctrl-shift-B) Re using another editor - the benefits to using the native OL editor outweigh those of an external one in my opinion. I do make a regular practice of keeping versioned backup files in a separate folder, using cut and paste. I’ve found over the 15 years or so of coding in OLang that it’s very versatile and reliable, after I’d adjusted my procedures and methodology accordingly. Of course, “pure VB.net” is another option using Visual Studio and the API. But given the frustrations you’ve already expressed with the “high level” (but limited) OLang interface, and given the complete lack of any documentation for the API (other than some dated examples), and given that N doesn’t have anyone on staff to support Q’s about it, I’d recommend that you stick with OLang. That’s the path I’ve taken and I’m very satisfied with it. [Edited by Jim Dean on 4/26/2019 10:40 PM] |
|
|
|
|
Administrator
Forum Moderator |
Registered User
Unregistered User |
 E-Mail this thread to a friend |
Toggle e-mail notification |
