PLEditor failings
PLEditor failings
I really don't understand how anyone can put up with the horrendous bugs in the PLEditor. For example, I'm getting frustrated about the bug in the undo feature. Often when I undo a series of previous modifications, it goes back too far and undoes only part of a modification. It throws me off track and it distracts me off my train of thought. It's getting to the point I'll copy the code and edit in some other editing facility. vim might be a good alternative as it has similar context sensitive syntax to color the text according to user defined rules. However, I shouldn't have to resort to this in the first place! It's so annoying!
Yes, that's true. However, it sometimes has a mind of its own and does a partial undo of the previous one.It seems that you have to click undo twice to get one undo. I have never had to undo past that.
Start with a new indicator with the following text:
Code: Select all
inputs: Price( Close ), Length( 14 ), PctDn( -2 ) ;
condition1 = RateOfChange( Price, Length ) <= PctDn ;
if condition1 then
begin
PlotPaintBar( High, Low, "%Decr" ) ;
Alert ;
end
else
NoPlot( 1 ) ;
Next add "print ("test1");" after the "begin" statement. Now we have:
Code: Select all
inputs: Price( Close ), Length( 14 ), PctDn( -2 ) ;
condition1 = RateOfChange( Price, Length ) <= PctDn ;
if condition1 then
begin
print ("test1");
PlotPaintBar( High, Low, "%Decr" ) ;
Alert ;
end
else
NoPlot( 1 ) ;
Code: Select all
inputs: Price( Close ), Length( 14 ), PctDn( -2 ) ;
condition1 = RateOfChange( Price, Length ) <= PctDn ;
if condition1 then
begin
print ("test1");
PlotPaintBar( High, Low, "%Decr" ) ;
Alert ;
end
else
NoPlot( 1 ) ;
print ("test2");
Now do an undo using ctrl+z. We end up with:
Code: Select all
inputs: Price( Close ), Length( 14 ), PctDn( -2 ) ;
condition1 = RateOfChange( Price, Length ) <= PctDn ;
if condition1 then
begin
print ("test1");
PlotPaintBar( High, Low, "%Decr" ) ;
Alert ;
end
else
NoPlot( 1 ) ;
p
Note there's still the letter "p" remaining. Now do another ctrl+z thinking it will just remove the letter "p". Instead we get:
Code: Select all
inputs: Price( Close ), Length( 14 ), PctDn( -2 ) ;
condition1 = RateOfChange( Price, Length ) <= PctDn ;
if condition1 then
begin
PlotPaintBar( High, Low, "%Decr" ) ;
Alert ;
end
else
NoPlot( 1 ) ;
I think you answered it at the end. I do use it but try not to. I do a lot of complete exports of all studies fairly often to protect myself (and retain probably the last 100 of them over a month probably). I would say every 30 minutes of work I do it. They all have a date, time, 2 character machine code and comment in the file name. They are retained on three machines just incase one blows up. That transfer occurs 2 times a day. Exporting all studies makes it fast. Having said all that currently I do not have huge amounts of programming on my plate (my strategies are done and most of the programming is done). Also more than 50% of it is in my database program which does not have these problems. So less need to use undo.
Very very frequent saves of all my work is a long standing habit I have had since I have had many hard drive failures, power supply failures. One computer caught on fire. I take my work to the safety deposit box every few months too.
Very very frequent saves of all my work is a long standing habit I have had since I have had many hard drive failures, power supply failures. One computer caught on fire. I take my work to the safety deposit box every few months too.
I do soemthing very similar. I have three external hard drives and a couple of USB sticks for my backups. I encrypt a batch of them every so often and remotely store them on another site. I also do a lot of my development in another language as I use a lot of dll's. I suppose that's why I get so annoyed when I do some editing in PLEditor. Some would say I'm spoilt using another editor that doesn't have the undo problem. I disagree. I've yet to come across any application that has this kind of bug. So, I still say it's not acceptable to have such a significant failing in the editor of a supposedly professional application. The only conclusion I can come to for it not being fixed a long time ago is that MC does not have a large enough audience. I refuse to believe such a failing is being tolerated by lots of developers. If this bug was in MS Word, users would have stopped using it many years ago and moved to some other word processor.I do a lot of complete exports of all studies fairly often to protect myself....
My question is this. What is the standard for when to save? I think it is actually every single key stroke? Also how far back? I have never tested it in any app.
I think this all has to do with young software priorities with a company that is not as rich as MS for obvious reasons. Numerous other concerns get higher priority (fix bugs with ticks missed or strange bars, execute studies on seconds as well as ticks, touchups in the replay feature, other issues I am not even aware of since I do not use them, much later maybe a debug mode with break points, maybe later revision control, etc). I would rather see these fixed first personally. Things are better. MC 6.0 never bombs where as MC 2.1.999.999 bombed every other week. It is all relative and I am sure in 5 or so years these lower priorty things will get fixed.
I think this all has to do with young software priorities with a company that is not as rich as MS for obvious reasons. Numerous other concerns get higher priority (fix bugs with ticks missed or strange bars, execute studies on seconds as well as ticks, touchups in the replay feature, other issues I am not even aware of since I do not use them, much later maybe a debug mode with break points, maybe later revision control, etc). I would rather see these fixed first personally. Things are better. MC 6.0 never bombs where as MC 2.1.999.999 bombed every other week. It is all relative and I am sure in 5 or so years these lower priorty things will get fixed.
Well, one obvious solution is to undo only complete words or lines, not partial words as it's does sometimes. I agree there are higher priority issues. If MC is not meant to be a development environment for serious programmers then so be it. We can put up with the failings. As I said, I don't use it much so it's not a huge issue - just an annoying one. If I were using PLEditor to do lots of code work, I would quickly go mad and go somewhere else.My question is this. What is the standard for when to save? I think it is actually every single key stroke? Also how far back? I have never tested it in any app.
That's not a sensible approach to try and encourage MC to gain maximum expose. In the case of a serious custom developer, PLEditor is the driver's seat of the whole package, and the charting front end is the view port. If I was going to spend a lot of time developing code in PLEditor, I would give it up in short order and turn to another editor or to another trading system. PLEditor is fine for sparse editing but I thought that contradicts where MC is heading - to become a leading automated trading tool. If the aim is just for charting using standard indicators then it's a leader already. To become a leader in providing a good interactive development environment there's a lot of issues to be solved first before it can even come close to reaching that goal. Something as basic as a working edit undo is just as important as many other required features, such as version control.Programming your approach to trading is not infinite. Eventually it will be 99% done (maybe even 100%) and you will not care much about the editor. The funny part is maybe it will be fixed by then.
For me I guess it is different. I prefer to disgard programming all together and just trade (after 25+ years of programming it is boring these days). My trading system rules are 99% done (I would say 100% but that is pushing it probably). Changes are simple database changes which I memorize now anyway (my database programm times my recall speed for me and the goal is 1 second per criteria for each trading situation). My programs only need cleanup changes, speedup changes and minor cosmetic changes and I am in no rush for that. Now if I was to program for other traders that would be different for sure. It will never happen.
I'm glad you've reached your potential. That's something any trader would love to achieve in their lifetime. I'm not there yet. Neither are most other traders, which is why the development environment has a lot of failings and should be fixed.For me I guess it is different. I prefer to disgard programming all together and just trade (after 25+ years of programming it is boring these days).
Last edited by janus on 03 Mar 2010, edited 1 time in total.
- TJ
- Posts: 7752
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2228 times
Revised short version. In a tough business where 99% fail (make that 999 in 1000 fail), if one is not there yet then one must prioritize their efforts for trading success and avoid distractions that will not help much. We all know that but sometimes we have to catch ourselves and stop ourselves from getting distracted. I have gotten distracted here. We all need to ask this very important question of ourselves every single day. Do direct this at the topic, I do not think this issue is the most important for TSS success and especially for my success as a trader. However this is a judgement call each trader has to make for themselves.
Last edited by bowlesj3 on 04 Mar 2010, edited 11 times in total.
Interesting story but it doesn't help MC to make their development environment much better for those who want to develop their own studies. I'll probably continue to develop new studies for some time to come. One thing I am sure of. If I need to develop complex studies I will be doing it either in a dll or on another platform.
First of all there is no such thing as a perfect editor. That would be a computer that read my thoughts and translated them to a computer language that I would not even need know. All I ask is a basic editor with the simple editing functions working. As for one that provides debugging aids that you describe, I couldn't agree with you more. I too have wasted many hours tracking bugs with crude print statements. I then formed my own break point function to print my variables of interest when a specific date and time is hit. Not much better than a simple print but at least it did make it a little quicker for me to trace some bugs. I'm still amazed to see the lack of useful run time errors. For example, when an array bound is exceeded, it doesn't tell me which array and where. How crude. Lots of time wasted there trying to find out which array was the problem and in what function. I can list several other failings but I think you know them. I must admit I'm a little spoilt as I've used various excellent programming tools in my earlier days of programming, although all I ask is the basics to work (eg, undo) and some decent run time error notifications. I'm saying this not so much for myself anymore as I'm working around it using dll's developed in another IDE, but for all the other users, both existing and future to make MC a much better platform. But if MC is not interested in listening to such ideas then it's not my problem; it's theirs.I have not problem with a perfect editor. The sooner the better and it is good for TSS to do that (like right now) if they can swing it. However If I think back about time I lost due to MC or EL or Editor failings, most of it was time waisted finding bugs due to just having a print statement for debugging rather than slow editor. So I think a perfect debugger (for me at least) would have got me through the programming much faster.
- Bruce DeVault
- Posts: 438
- Joined: 19 Jan 2010
- Location: Washington DC
- Been thanked: 2 times
- Contact:
I don't think when specific technical issues with the editor are posted it's generally helpful to lapse into "not everything can be programmed" etc. etc. which is a much different subject - specific reported problems with the tools should be addressed whenever reasonably possible as that helps everyone.
There can be no doubt that PL editor is still a pretty basic tool and has a long way to go - take a look at TS's new TS Development Environment in 8.8 for an example, much less Visual Studio which is pretty much the standard for how full IDEs should be well designed.
There can be no doubt that PL editor is still a pretty basic tool and has a long way to go - take a look at TS's new TS Development Environment in 8.8 for an example, much less Visual Studio which is pretty much the standard for how full IDEs should be well designed.