current compile cancel etc.

It is too bad that the current compile can not be cancelled immediately and also with no risk to the database of studies.

At the same time it would be handy if this was done such that what I describe below could be done.

Lets say I am compiling LargeStudyX. It is compiling away and at the same time because it is compiling to a work area the old version of LargeStudyX is still running (completely unaware that there is a compile in process). Now if the compile of LargeStudyX failed then the running of the old version of LargeStudyX is left alone and it just continues to run. However if the compile of LargeStudyX does work then it is moved in to replace the old version of LargeStudyX. Again at the same time the existing database of studies is only changed if the compile actually works. Therefore when a study is loaded in and changed it is copied to a temp workarea and it does not get written back to the main database until it compiles clean (or maybe not written back until we decide we are done with it).

More thought needs to go into this I figure but it is a start. I am just wondering why a true professional environment was not created for EL. You know what I mean. Test run libraries, production run libraries, link libraries, test link libraries, etc. In this situation cancelling a compile immediately is not a big deal. For that matter cancelling a link is not a big deal either.

I agree, I noted the same deficiencies...

I think I understand what you're going for here, but the key issue would become that then you have a running study you don't have the source code to. Imagine trying to figure out why it did whatever it did, without any reference point for what the source to the study is? It's not so bad if we're talking 5 minutes later, but what if you make a change, try to compile, the compile fails, and it keeps running the old one, then you come back 6 months later and try to pick up where you left off but you have no idea what it used to be like before the change...

I'm not opposed to what you're suggesting, but think if it's going to save the "last known good" compiled copy, it has to also save the "last known good" source to go with it.

I think the main problem I am concerned about is just starting a compile on a large study and immediately realizing there is one more change to make but you have to wait for the large study to complete its compile before you can stop it to make that change. My 3000 line study takes about 3 minutes to compile on my big machine and sometimes 6 minutes on the notebook. I am not sure why but it does (maybe it is the functions called, not sure).

The idea above is pretty simple. The idea below would have to be thought out by TSS and the traders involved. That is why I said that. It will be new to most here I figure. But here is how it works in a true professional programming environment.

In a professional enviornment you have a test system and production system (for every system area). Programs are given the same name as the testing of changes start. There is a test source library and a production source library as well as a test link library and a production link library. Linking is when the functions are linked into the program after the main compile runs okay. Program changes can take weeks before they are moved over to production. Sets of program changes can take months before they are ready for a move to production. The production must not be interupted in any way shape or form until all testing is complete. In the EL environment the only way to do this is to have a workspace copy that is running the same studies basically but renamed. That is much harder than a true professional environment setup. If may have been set up in a non profressional environment because most traders are not full time profressional programmers working in a large program environment where you have many 1,000s of programs written many programmers. Also in a true professional environment there is a revision control system to control the source code for each program. You know what is running in production using dates and times. You can go back in the revision system to get any change that has occured (they have comments associated with them). Actually a good revision control system can compare revisions and find the differences.

Of course it makes sense in a large complex development project to have a "test environment" and a "production environment" - but, you're trying to do them both in a single running instance of MultiCharts, while in your scenario of a big project things getting "moved to production a few weeks later" this would almost certainly not be the case of everything in a single running program and this is why your analogy breaks down. What you need is a second copy of MultiCharts, likely on a second machine, to recreate the scenario you've described, unless you want MultiCharts to create a complete duplicate set of indicators with compiled and source code as I've described above as another option.

In short, you're editing a live running program in your production environment - something that in your example above they would never do.

I am all for revision control, but that is rather a different subject, and not something that has traditionally been in EasyLanguage editors, although it's a fair subject for future suggestion. Most of the folks I know who've done version tracking of large EL projects have done so by pasting the code out of the EL editor and into their tracking environment e.g. visual studio, source safe, cvs, etc. to commit the changes. While I think it's a reasonable suggestion to add version control to PL editor, it's not related to the issue you're describing above. I've posted a separate thread about this specifically at http://forum.tssupport.com/viewtopic.php?t=7178.

I get exactly what you are saying Bruce. This is where the thinking it out comes into play. I was thinking in terms of having a split in the studies library mainly (test and production). The idea is the user can at least get a clean compile and make the decision that they are done before they decide to have the studies running on the chart stop showing the indicators. It could be that they are holding a position a long time and want to watch it but not constantly and at the same time they want to get some work done on one of the studies to be put in at night (or completed later at night). My suggestion would allow that. As it stands now as soon as that compile starts the study running in MC is shut off and the word "verifying" appears in the status field. In my suggestion this word in the status field woud change to "reloading" at the point that the user feels that the study is ready to move to production. At that point the revision control system would tell the user that this is the version that is now in production.

I don't care how TSS swings this idea but it is not a bad idea. At present I get this impression that if the user was to cancel a compile they just started it would currupt the library. I am saying they need to fix this weakness and I really do not care how they swing it.

Maybe a good idea would be that the user can decide if the current compile is to compile to a work area first before interupting the study running in production at the moment (the best of both worlds is what I am suggesting).

Maybe I'm not thinking much about the compile times because I've never noticed it taking that long. I'll try compiling an artificially long program and see if I can get it to take more than a few seconds.

It looks like a 3250 line test case here takes 15 seconds to compile. It never really occurred to me to try to interrupt it.

Yes the length of compile is one issue but I am also referring to the user wanting to start some changes that are going to take them a week to complete. Yes they could rename it and bring it in later. I do that now but it is a fair bit of work to go back and clean it up (worse for me since I keep moving stuff back and forth from the main machine to the notebook). What I am suggesting is that the user could select a version from the version control system and say this is the one I want to run in production now and that "verifying" status would be "reloading" and it would tell the user what version from the version control system was currently running in production. It would all sync up and keep it crystal clear to the user exactly what was going on. So the revision control system could show the user that the version they are working on is not the one running in production and it could show then that the one running in production is maybe 2 or 3 back even. Maybe it could be as simple as (5 of 7) meaning version 5 is in production now and there are a total of 7 version in the library. If the user tried to move an uncompiled version into production it would stop them.

Yes I have a fast machine and for some reason this one study seems to take a long time. I would have to disect it to figure it out. It also seems to run fast some times and slow other times. It has always been that way.

Anyway I had better get back to this tonight.

I don't think just having some version number that's "in production" and everything else is still being edited would be enough to make it possible to have a production and test environment on one single MultiCharts installation (which I'm still not sure is a good idea, but, it never hurts to have the option...). You would need a way to test the code beyond just that it compiles, and that's why in the thread I referenced above I suggested that this be on the actual format dialog of the indicator itself.

It looks like a 3250 line test case here takes 15 seconds to compile. It never really occurred to me to try to interrupt it.

This same 3250 line test case compiles on the new TS 8.8 in 3 seconds. TS Support could definitely do some improving of the compile times it would seem, although this is not really a critical issue compared to actual functionality in the platform.

Yes I will post my next idea for the revision control to your new thread.