brian_z111 said : *** ..../ 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? /... ***
I can't imagine that such a software comes from a brain alone... Finally, AB gives an inferiority complex for a special price ! :) brian_z111 a écrit : > > > 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] <mailto:amibroker%40yahoogroups.com>, > 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] <mailto:amibroker%40yahoogroups.com>> > > > 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] <mailto:amibroker%40yahoogroups.com>> > > >>> 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 > > >>>> > > >>>> > > >> > > > >
