Thanks Tomasz, I never expect that you should have to answer my computer/programming questions but you are often the one who does.
Of course your answer begets my next question but I will save it until next year :-) BTW you forgot to put a Health Warning on the AB packaging; "Programming is addictive". brian --- In [email protected], "Tomasz Janeczko" <gro...@...> wrote: > > Hello, > > AFL is basically the same as C (simple, old plain C, not C++), > > but without declarations, pointers, memory allocation and all complex stuff that > people find difficult. > > Instead it adds native array operators so you write > > MyAverage = ( High + Low ) / 2; > > and it internally knows that it needs to process every element of array. > In plain C you would always need to write a loop > > int i; // declaration required in C but not in AFL > float MyAverage[ BarCount ] ; // declaration required in C but not in AFL > > for( i = 0; i < BarCount; i++ ) > { > MyAverage[ i ] = ( High[ i ] + Low[ i ] )/2; > } > > Of course the same loop works in AFL too, but array statement > is simpler, clearer or even more "elegant" as you need only one line instead of 6. > > That single addition (ability to use arrays without loops) plus > automatic memory management is the whole story, there is nothing more to > AFL as compared to C. > > Best regards, > Tomasz Janeczko > amibroker.com > ----- Original Message ----- > From: "brian_z111" <brian_z...@...> > To: <[email protected]> > Sent: Friday, February 13, 2009 11:39 AM > Subject: [amibroker] Re: Run time debugging for includes > > > >> 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 <see3d@> 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" <see3d@> > >> > 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" <jtoth100@> > >> >>> 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 > > > > > > >
