I find this little utility almost indispensible when tweaking different versions of my AFL's, and it's free to boot!
http://download.cnet.com/Files-Compare-Tool/3000-2248_4-10315688.html ----- Original Message ----- From: James To: [email protected] Sent: Wednesday, June 17, 2009 10:16 PM Subject: Re: [amibroker] Re: A question of style Speaking of cleaning up files, is there a way to compare two AFL files and have the editor show you the differences? Sometimes I get going so fast with different variations and I am putting a v1, v2, v3 etc. at the end of the file name, then sometime later I come back to that idea and it can be difficult to find what exactly I was doing. A program to automatically compare two files would be useful. James ------------------------------------------------------------------------------ From: brian_z111 <[email protected]> To: [email protected] Sent: Wednesday, June 17, 2009 6:04:41 PM Subject: [amibroker] Re: A question of style A lot of the heavy hitters collect and archive code from this forum etc and manage their snippets via third party software .... I assume they cut/copy and paste snippets as required e.g. Herman and others use Infoselect. --- In amibro...@yahoogrou ps.com, "brian_z111" <brian_z111@ ...> wrote: > > So far I haven't had the need for long algorithms, or a lot of them, but I have found that maintaining AFL files lacks a few tools. > > Admittedly I am a messy worker and only saved by the fact that I don't archive other peoples code and don't archive all of my own forever. > > Up until now I have just relied on creating folder hierarchies and using the P_XYZ convention, etc, to delineate which files are primarily written as an indicator or scan etc. > > On top of that I have experimented with creating templates, with some all purpose code pre-written in them, but not as an #include. > > #includes seems like one of the 'logical' options .... the algorithmic traders seem to go down that path. > > I imagine that this also requires some ongoing management and possibly the need to remember what is in each #include template, as well as tracking versions, adding deleting new stuff as required .... I am generally opposed to continually adding tasks to my computer maintenance list. > > I am not sure if there are any execution implications that flow on from always loading up, at preprocessing, if you aren't going to use most of what is loaded (seems to be massive overkill). > > > > Three things seem to be lacking from my perspective: > > - finding the file you want from amongst a large number of files/folders ... AB needs the ability to search amongst the AFL files to find the file that has certain code in it > > > - custom auto complete (like an excel macro that we assign to a key). > > One solution might be to use another editor, to get the benefit of search and customcomplete, but then any useful features in the AFLEditor will be lost and new maintenance issues created. > > For me the only two features of the AFLEditor I would miss are syntax checking and synchronisation between the current edit and the charts (I use apply indicator and watch the indicator to see how my code changes change the plot quite a bit ... if it wasn't for that basic need I would change editors). > > > --- In amibro...@yahoogrou ps.com, "ics4mer" <ics4mer@> wrote: > > > > > > Hi all, > > > > Just wondering how people out there are organising their > > AFL code between plots, backtests, explorations etc. > > > > Lets say I have 5 indicators which each require 50 lines > > of code to draw a plot, in other words too large to > > maintain in separate AFL files. > > > > Lets say I also want them all in a single exploration. > > > > So logically it seems that I should place each indicator > > into an include file and include that into each of the AFL > > "types" so I'd have "include <myTA_Tool.h> " in my b_backtest, > > e_exploration, and p_plot files? > > > > Just wondering how everybody else is handling this? > > > > RZ > > >
