|
PureBytes Links
Trading Reference Links
|
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 ****
> This group is for the discussion between users only.
> This is *NOT* technical support channel.
>
> *********************
> TO GET TECHNICAL SUPPORT from AmiBroker please send an e-mail directly to
> SUPPORT {at} amibroker.com
> *********************
>
> For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> http://www.amibroker.com/devlog/
>
> For other support material please check also:
> http://www.amibroker.com/support.html
>
> *********************************
> 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/
|