|
PureBytes Links
Trading Reference Links
|
Somewhere, both K & R are spinning in their chairs right now :-)
--- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@xxx> 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_z111@xxx>
> To: <amibroker@xxxxxxxxxxxxxxx>
> 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 amibroker@xxxxxxxxxxxxxxx, 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: <amibroker@xxxxxxxxxxxxxxx>
> >> > 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: <amibroker@xxxxxxxxxxxxxxx>
> >> >>> 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
> >
> >
> >
>
------------------------------------
**** 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
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|