> If you understand the simple elegance of the AFL > execution process, you would see that this is just wrong.
That is a view that I would like to see; "the simple elegance of AFL execution process". What is the path to that vantage point? 1) I presume a prior knowledge of how computers work is required (machine language, compiler, what a processor does etc)? 2) Within AB ... go to the developers kit? I am up to the part where Wiki told me arrays are contiguous in memory and that sounds like a good thing .... now I need to know where I can find out how AFL execution works (specifically array processing). Anyone care to show me the starting line? --- In [email protected], Dennis Brown <se...@...> wrote: > > John, > > You are only making the case that proper organization is the > responsibility of the programmer. Programming is a sharp sword. You > can slice up your problems with it, or you can cut yourself. It is > all in the technique. And yes, I also need to be reminded of what I > wrote last month and why. > > My include statements in the main program are not one-liners. There > is a comment block at the start of each include file that documents > what is in there -- like a table of contents. I paste that whole > block into my main program. That way I have the top level > documentation of what is included -- usually a list of functions with > parameter names and a short description of why to call it. If I > search for a function, it will come across the definition in the > include comments. Each function in a file has its own comment block. > Though I don't make a point of documenting every little change or bug > fix, I do note the last change date on each one. > > Outside of a major block of inline code, blocks of functions are what > I think of as AFL language extensions. So I might have one include > called FP_UtilityFunctions.afl that adds a dozen useful general > purpose stand alone functions to AFL independent of trading program > specifics. > > On the other hand, I have FlexibleParam_Buttons.afl that adds many new > functions that specifically support on-chart button arrays. It has a > lot of functions and many of them call each other and must be > compatible as a set. It would be pure insanity to figure out how the > whole set worked without being able to see all the code and comments > together in the same file. > > Then I have an include called FP_BtnBarInfo.afl that implements a > specific button/table of bar information -- a bar inspector. It is > not a function, but inline code that includes parameter definitions, > layer mouse click claim code, and a procedure called DrawBarInfo() > that draws the buttons on the screen with Gfx commands. That has to > be called later in reverse order of of all the buttons because there > are no Z layers for Gfx commands, or else it would be part of the > inline code. > > I would suggest that your proposal would actually make things more > obscure from my point of view if I tried to use it as you are > suggesting. Then there is the problem of the compiler. It is not > really a compiler to any greater sense than most interpreters have. > It is not multi-pass for resolving references. The preprocessor is as > close to a compiler pass as it has, and it only looks at a few > specific commands like #include. It would have to be able to parse > the whole syntax to look for functions that are undefined, try to find > them in a file, add them to a special buffer that is always executed > initially as part of the AFL pass. This would be a lot of pain for > little gain. If you understand the simple elegance of the AFL > execution process, you would see that this is just wrong. > > I am quite happy with the general concept of include files as opposed > to external functions. As I have pointed out, I lends the perfect > level of modularity to my programming. It also helps with revision > control that I only have one AFL trading program -- with a thousand > parameters. If I had many different trading programs, then I would > likely add a version number to the include file names for non- backward > compatible revisions, and leave the old ones alone. > > Keep the blade away from you own arms and legs. ;-) > > Best regards, > Dennis > > > On Feb 12, 2009, at 6:18 PM, Listsub wrote: > > > Dennis, > > > > Interestingly I started out with same view as yourself regarding > > grouping related functions into one include file. Although it went > > against my past experience it was appealing because it seemed a > > quicker path to the business of developing and testing trading > > systems. Over time I found this approach did not work well for me > > and I switched to one per file. Reasons it didn't work? > > > > I found tracking code changes awkward. For example I knew a function > > group had been changed but which function within it and why? > > Keeping track of dependencies. > > Forgetting which functions were in which files - my age;-) > > Putting the wrong includes in programs - often redundant - age > > again ;-) > > Silly stuff like what group shall I put this function in - I ended > > up with 3 big files called Misc1, Misc2, Misc3! > > > > As you say working with large numbers of files is a challenge. A > > good Editor, version control and well organised folders help. > > > > Thanks for your ideas. > > John > > > > > > ----- Original Message ----- > > From: "Dennis Brown" <se...@...> > > To: <[email protected]> > > Sent: Thursday, February 12, 2009 2:58 AM > > Subject: Re: [amibroker] Re: Run time debugging for includes > > > > > >> John, > >> > >> Although I would not take advantage of some of what you are > >> suggesting, still you make some good points, and you got me thinking > >> about things that I could use. > >> > >> I would prefer to have a group of related functions in an include > >> file, rather than just one function per file. That way with one > >> include file I get a whole new functional set that are edited > >> together > >> to stay compatible version wise. Otherwise my 40 files would > >> become a > >> confusing 200+ files. Too much for me! There is a fine line between > >> not enough modularity and too much modularity. If I do want the > >> modularity, then the include can be written to follow the rules of a > >> function that you describe for scope. > >> > >> Right now, the include path names are constants because they are > >> preprocessed. I would like to have preprocess commands to set an > >> override default path for includes folder. That way one definition > >> in > >> the main code before the include could override the default include > >> folder path. One easy edit to get a new set, or reorganized to a > >> subfolder. > >> > >> #IncludeFolderPathOverride = "path" or <path> to relocate to a > >> relative subfolder > >> #Include <FilePath> > >> #IncludeFolderPathRestore > >> > >> The override is really a push, and the restore is a pop for multiple > >> levels. That way you could substitute a new path for just a portion > >> of the includes that you are testing without hard coding a fixed path > >> for each one. > >> > >> Your point #4 below is also an interesting one and could be applied > >> to > >> the include file path. > >> > >> Best regards, > >> Dennis > >> > >> > >> On Feb 11, 2009, at 8:38 PM, Listsub wrote: > >> > >>> As noted debugging AB with includes is not easy . The nature of AFL > >>> makes it quick and easy to write/test simple stuff but as complexity > >>> grows debugging any sizeable AFL project can be quite tricky, > >>> particularly if running RT as there is a lot going on. > >>> > >>> "Modular" programming is only catered for in AB by Includes (which > >>> is just a soure code copy preprocessor). The AB program structure > >>> model is therefore basically just one big chunck of code - which is > >>> why (unless you are very careful what you code inside Inlcudes) you > >>> can get some very hard to find problems (the problems can even > >>> change or disappear depending on the roder of Includes). > >>> > >>> IMO improving AFL to support procedure/function calls to external > >>> files would be a big plus to enabling better modular program design. > >>> Specifically:- > >>> > >>> a =xyx(p1,p2) would call the external proc/func "xyz" (unless xyz > >>> is defined in current source file). > >>> > >>> The benefits as I see them:- > >>> > >>> 1. #Inlcudes are no longer required for procs/fucntions.Compiler > >>> would pull them from library specified via preferences. No more > >>> searching for which Include file is that function in, which version > >>> of that was I using .. etc. > >>> > >>> 2. External functions matched by filename. i.e one function name = > >>> one filename, no ambiguity, easily portable. > >>> > >>> 3. External files are closed boxes - can only receive/pass data via > >>> parameters, return value or global variables. Everything else inside > >>> file is local. No interference bewteen files. > >>> > >>> 4. Faster code development/maint. For example if we have the > >>> facility in Preferences to define multiple paths to external proc/ > >>> func library it becomes easy to test out changes without having to > >>> resort to all the usual suffixing fillenames, changing calls etc. > >>> i.e. > >>> > >>> path1=AB_Function_Library_Test > >>> path2=AB_Function_LIbrary_Live > >>> > >>> So to test out a mod just copy the function file to the Test > >>> library, make the changes and test. Compiler searches paths in order > >>> specified so anything with matching name in Test takes precedence > >>> over same name in Live. > >>> > >>> 5. Easier debugging? ;-) > >>> > >>> John > >>> > >>> > >>> ----- Original Message ----- > >>> From: "jtoth100" <jtoth...@...> > >>> To: <[email protected]> > >>> Sent: Wednesday, February 11, 2009 2:26 PM > >>> Subject: [amibroker] Re: Run time debugging for includes > >>> > >>> > >>>> Hi all, > >>>> > >>>> debugging includes is not easy and handy in any script language. So > >>>> instead of making the GUI to reduce clicks my suggestion would be > >>>> to > >>>> reduce possible error cases. > >>>> > >>>> Most errors come from undefined/uninitialized variables. If AFL > >>>> language would have an "OPTION" to require definition of all > >>>> variables then most common errors could be vanished. > >>>> Visual Basic 6.0 never was my favorite language and environment. It > >>>> was for average Joe to do basic level programming. It did not > >>>> require > >>>> declaring variable just like AFL or any script language. But I > >>>> had to > >>>> use it years ago. At that time all serious developer started each > >>>> module in VB with "Option Explicit On". This caused an error at > >>>> parse/compile time if a variable was not defined explicitly but was > >>>> referenced anywhere in the code. > >>>> > >>>> How would it help? > >>>> Most probles come from just creating variables by assigning a value > >>>> to an "identifier". However if you misstype an "identifier" or code > >>>> execute in a code path where variable does not get > >>>> defined/initialized you get an error. The worst thing is that these > >>>> errors are hidden until the rearly executed code path is executed > >>>> (typical runtime error). If definition of variables are required > >>>> even > >>>> these code paths are checked for proper variable usage. > >>>> > >>>> This should be an option for advanced users which is turned on on > >>>> purpose. So all code out there could run with no change. > >>>> > >>>> Variable assignment and definition could be merged to one statement > >>>> like in any modern language (e.g.: var x = 0.5;) This way > >>>> declaration > >>>> is required and initialization can be done as well. > >>>> > >>>> I know it does not guaranty that all runtime error are gone. But > >>>> with > >>>> disciplined coding most can be avoided and the need for debugging > >>>> is > >>>> vastly reduced. > >>>> > >>>> So I would not go for GUI change request but to improve AFL as a > >>>> script language. > >>>> > >>>> Regards, > >>>> > >>>> Y > >>>> > >>>> > >> >
