|
Title: Re[2]: [amibroker] Re: Run time debugging for includes
Actually related a related suggestion was http://www.amibroker.com/feedback/view_bug.php?bug_id=1622
best regards,
herman
Wednesday, February 11, 2009, 11:08:24 AM, you wrote:
> Y,
> It is an interesting perspective.
> I actually prefer dynamic assignment of variables the way AFL does
> it. I especially like the fact that I can detect that a variable has
> not been assigned a value at runtime and initialize it to a default or
> modify the code execution in other ways. I make extensive use of this
> feature to make life easier on the user options in my code. I have
> few errors of the type you describe, and I find them the easiest to
> debug. I am sorry to say that your proposed solution would not be
> useful to me, though it may be useful to those who program an
> interpretive language like it was a compiled language.
> The things that are hardest to debug are not the types that the
> compiler catches, but logic errors in the program that do not give the
> desired results (or actual bugs in the underlying platform).
> Syntax errors are actually the most common type resulting from typos.
> However, the compiler's error checking can get confused if for
> instance you leave off a "}" someplace. Then the error and location
> of the error reported usually has little to do with the actual typo.
> Prettify the code can sometimes help find this type of error, but it
> usually requires careful reading of the code looking for the typo. It
> is just a limitation of the C++ like syntax.
> I have been programming problem solving tools for myself (not as a
> professional programmer) for 40 years -- hey a new milestone! I have
> enjoyed working with interpretive type languages the most. They are
> the easiest to use for writing and debugging small to medium size
> programs. I have found that the easiest way to debug is to make a
> simple program, or add to a complex program while it is running! Make
> sure there is temporary visual feedback for the new stuff (great on a
> charting program). By adding and testing one change at a time, any
> errors that are flagged are not so hard to find since the area
> concerned is small. My debugging time in AFL, which used to consume
> 80% of my time has been reduced to 20% of my time.
> Included files are a great way to organize a complex program and make
> it modular for swapping out various options. I am just starting to
> use this feature (out of necessity) in my AFL programming. My concern
> and reason behind my post was to make debugging with this program
> organization as easy as it has become with the single file AFL programs.
> My feeling is that I should not have to pay a price in ease of
> debugging in order to gain the advantages of better program
> organization. My suggested ideas for solutions are simply to bring
> parity to debugging with includes in keeping with the original flavor
> of the tools provided by Tomasz.
> However, as can be seen from the replies, different people have
> different approaches to organizing and debugging AFL programs -- and
> different ideas about what would make it easier for them.
> Best regards,
> Dennis
> On Feb 11, 2009, at 9:26 AM, jtoth100 wrote:
>> 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
> <*> 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
*********************************
![]()
__,_._,___
|