|
Title: Re[2]: [amibroker] Re: Run time debugging for includes
Tomasz,
to simplify things for everyone. Would it be possible to provide a tools->customize menu for the editor? just like we have in the main AB window?
If that would be possible then we could write our own Editor plug-ins for PrettyFy, includes, load functions, etc.) and everybody would be happy :-)
BUT, if you could PLEASE, if at all possible allow the tool menu to call afl functions so that we can write all our own Editor plug-ins in afl. i.e., make the feature useful for all AB users, not just profession programmers.
Best regards,
herman
Thursday, February 12, 2009, 6:52:43 AM, you wrote:
> Hello,
> One little explanation why implementing the suggestion would make AFL much slower.
> If "one function per one file" paradigm was used, it would mean
> extra 48+13 = 61 microsonds overhead for EACH function because
> that is the overhead of file open and file close operation. File access is not "cheap" operation.
> That is order of magnitude (10x) higher than overhead of existing
> user-defined function call (which takes less than 6 microseconds).
> Of course that difference applies on one use of given funciton in
> one AFL file, and fopen/fclose overhead would play less role
> with 100 calls of the same function, but many functions
> are actually called once or twice per AFL so the overhead
> of proposed solution is completely prohibitive.
> Best regards,
> Tomasz Janeczko
> amibroker.com
> ----- Original Message -----
> From: "Tomasz Janeczko" <groups@xxxxxxxxxxxxx>
> To: <amibroker@xxxxxxxxxxxxxxx>
> Sent: Thursday, February 12, 2009 10:23 AM
> Subject: Re: [amibroker] Re: Run time debugging for includes
>> Hello,
>> Sorry but this suggestion does not make any sense plus
>> it does not bring any benefit to already existing USER DEFINED FUNCTIONS feature.
>> The #includes are STANDARD in C and C++ language.
>> Similar constructs (like "import") exits in Java and other languages.
>> And it is so for purpose
>> Code MUST be included ANYWAY.
>> Specifying WHAT to include allows MORE EFFICIENT execution.
>> There is simply **ZERO** difference between putting all your FUNCTIONS into one include
>> file, placing single #include <all.afl> on top of your formula
>> and calling functions as usual.
>> User defined functions (ALREADY EXITSITNG FEATURE) allows ALL
>> that was suggested below. READ THIS:
>> http://www.amibroker.com/guide/a_userfunctions.html
>> Implementing your suggestion would do just ONE thing save you only from typing 18 letters (#include <all.afl>)
>> and would make program A LOT SLOWER because AmiBroker would
>> need to look and parse hundreds of files searching for "where the user decided
>> to put his functions" .
>> Best regards,
>> Tomasz Janeczko
>> amibroker.com
>> ----- Original Message -----
>> From: "Listsub" <listsub1@xxxxxxxxxxxxxxxxxxxxxxx>
>> To: <amibroker@xxxxxxxxxxxxxxx>
>> Sent: Thursday, February 12, 2009 2:38 AM
>> Subject: Re: [amibroker] Re: Run time debugging for includes
>>> 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 ****
>>> 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 ****
>> 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 ****
> 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
> <*> 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/
__._,_.___
**** 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
*********************************
![]()
__,_._,___
|