|
PureBytes Links
Trading Reference Links
|
> 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@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>
> > 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>
> >>> 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/
|