----- Original Message -----
Sent: Thursday, February 12, 2009 1:07
PM
Subject: 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/