|
PureBytes Links
Trading Reference Links
|
I could not say it better and agree 100%.
Best regards,
Tomasz Janeczko
amibroker.com
----- Original Message -----
From: "Dennis Brown" <see3d@xxxxxxxxxxx>
To: <amibroker@xxxxxxxxxxxxxxx>
Sent: Friday, February 13, 2009 3:10 AM
Subject: Re: [amibroker] Re: Run time debugging for includes
> 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@xxxxxxxxxxx>
>> 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@xxxxxxxxxxx>
>>>> 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/
|