I could not say it better and agree 100%. Best regards, Tomasz Janeczko amibroker.com ----- Original Message ----- From: "Dennis Brown" <[email protected]> To: <[email protected]> Sent: Friday, February 13, 2009 3:10 AM Subject: Re: [amibroker] Re: Run time debugging for includes
> 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" <[email protected]> >> 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" <[email protected]> >>>> 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 >>>>> >>>>> >>> > > > ------------------------------------ > > **** IMPORTANT PLEASE READ **** > This group is for the discussion between users only. > This is *NOT* technical support channel. > > TO GET TECHNICAL SUPPORT send an e-mail directly to > SUPPORT {at} amibroker.com > > TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at > http://www.amibroker.com/feedback/ > (submissions sent via other channels won't be considered) > > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG: > http://www.amibroker.com/devlog/ > > Yahoo! Groups Links > > >
