|
PureBytes Links
Trading Reference Links
|
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 amibroker@xxxxxxxxxxxxxxx <mailto:amibroker%40yahoogroups.com>,
> Dennis Brown <see3d@xxx> 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@xxx>
> > > To: <amibroker@xxxxxxxxxxxxxxx <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" <jtoth100@xxx>
> > >>> To: <amibroker@xxxxxxxxxxxxxxx <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
> > >>>>
> > >>>>
> > >>
> >
>
>
------------------------------------
**** 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/
|