|
Joined: Apr 2004
Posts: 218
Fjord artisan
|
OP
Fjord artisan
Joined: Apr 2004
Posts: 218 |
My suggestion is a new improved /debug for mIRC. It seems that /debug can become rather useles sometimes when applyed to scripting certain things and could be improved to help with script editting, among other things.
I suggest more things to shown in the /debug command such as executed aliases, any /command ran, and/or a way to show mIRC internal commands? Not for sure how to explain it it just seems that mIRC's /debug command is becoming old and mostly not useful when trying to figure out why a certain large script (with many commands) isn't functioning properly?
Maybe a switch to only show events, commands, signals from certain script files, alias files. Perhaps a new switch to debug any command with matching text. "/debug @window [match text]"
I know the current /debug filter has an option to send the lines thru a specified identifier before being displayed, but the current mIRC /debug only works for server messages. I hope the it will be expanded to just more than server messages for those are only useful in a limited area. Expanding the /debug to more would (IMO) be appreciated to the people who are having trouble finding errors, to those who are looking to improve efficiency of a script by eliminating redundent commands.
Any other thoughts or suggestion would be appreciated if you read this.
Live to Dream & Dream for Life
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
/debug is far from useless as it is, it was only ever intended to be able to monitor messages coming from/going to the IRC server.
I think it's a good idea to extend it though.
|
|
|
|
Joined: Dec 2002
Posts: 580
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 580 |
There are additional error handling abilities in mIRC... Add something like this to the end of all the aliases and events you want to debug... Then script a DEBUG signal to handle the errors... Or write your own script that uses :error, $error, and /reseterror. (See: /help $error)
goto end
:error
.signal -n DEBUG $+($script, $chr(160), $scriptline, $chr(160), $error, $chr(160), $1-)
:end You could also write a script that universially monitors all primary events, or you could extract the one I wrote for mJavaIRC. Although it would probably never happen, my only debug suggestion would be an internal mIRC ability to take an mIRC script and construct a flow chart from the source. Also the ability to use /throwerror to generate an error that propogrates back to the calling aliases.
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
Fjord artisan
Joined: Apr 2003
Posts: 342 |
Ummm... debugging and error handling are two seperate things. And at the moment error handleing sucks with mIRC. But you should write your own debugger.
Basically rather than using a /debug command with filters, you specify what you want be shown while the /debug is active.
Of course you have to do this yourself. But it's really easy... that is for a basic debugger. This is all you need really...
alias /DEBUGMSG { if %isdebug { echo -a DEBUG - $1- } }
Then you simply place /debugmsg <string> in places where you'd like to see debug messages. You would then simply need to set %isdebug to 1 or 0 to toggle the displaying of debugstrings.
This is a REAL simple debugger. I myself wrote a complex debugger that allows limited filtering, line colors, etc. The problem is I think it uses some custom identifiers and i don't wanna replace those identifiers with the equivelent instructions cuz i am just too lazy. No one would use it if I posted it anyhow so why bother.
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
Joined: Jul 2003
Posts: 655
Fjord artisan
|
Fjord artisan
Joined: Jul 2003
Posts: 655 |
I believe the suggestion is for extented internal debugging to include non send/recieve server messages. Without the need to shove random code into your scripts, or in the case of a bug fixer / tester, into another script that you are unfamiliar with. Your suggestion is basically a manual debugging method, no different than how everybody currently does it already.
I think somebody suggested in this thread already, something similar to a local debug binded to a specific alias or event. ie /debug ALIASNAME that would track the use of the alias and/or allow 'simulation' of the alias with dummy data (user input)... would show the extended logic path taken through the alias (messages in debug window like ALIASNAME: VAR %X IS NOW VALUE, ALIASNAME: IFMATCH FALSE, JUMPING TO ELSEIF/ELSE/END, or similar)
I generally like the suggestion, however i dont believe its a simple feature to implement, so i wouldnt hold my breath for this being added any time soon.
"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
|
|
|
|
Joined: Dec 2002
Posts: 580
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 580 |
Ummm... debugging and error handling are two seperate things. Really? Why would you need to use debug, if there are no errors in a script (or mIRC)??? My cousin is different from me, but we are both still related.
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Really? Why would you need to use debug, if there are no errors in a script (or mIRC)??? MeStinkBAD was right, you are wrong. Error handling is very different from debugging. In fact, "error handling" doesn't imply that your script has bugs in it at all. Error handling has to do with how fault tolerant your script is.. ie. what it does when it reads bad input. not all errors are bugs. Some are expected.. expected to be handled.. error handled.. (get it?) Anyway, this is all off topic: /debug could just be seen as a bad alias name, it's not meant to help you "DEBUG" your scripts, nor does it imply your script has bugs in it. It's just meant to see verbose information going in and out of the irc connection; that's all. It's generally used to CREATE scripts (usually for RAW events), not debug them. Debugging is done completely differently in mIRC.. check out my debugging tutorial if you want some general debugging guidelines. If it makes you feel better, I would suggest renaming /debug to something that doesn't give the misconception that it's meant for "script debugging" (there are already ways to do that, see link above), of course it really doesn't matter that much, and if you read the /help /debug, it would clarify.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Dec 2002
Posts: 580
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 580 |
MeStinkBAD was right, you are wrong. Error handling is very different from debugging. In fact, "error handling" doesn't imply that your script has bugs in it at all. Let me see if I can explain this to you... Programmers use error handling to catch errors, so script can be written so that those errors don't occur often or at all (sounds like debugging to me). Well now, on the other side, I am wondering why I'm not catching raw events with numeric X (was a case of this in 6.21), so I use /debug to see if that numeric is even being sent from the server. Since in both cases I was trying to find out why something didn't work, I was debugging. Plain and simple. Anyway, this is all off topic: /debug could just be seen as a bad alias name, it's not meant to help you "DEBUG" your scripts, nor does it imply your script has bugs in it. It's just meant to see verbose information going in and out of the irc connection; that's all. It's generally used to CREATE scripts (usually for RAW events), not debug them. Debugging is done completely differently in mIRC.. check out my debugging tutorial if you want some general debugging guidelines. I agree /debug should be called /dump or something else more specific, it doesn't negate the fact that it is often used to debug. Even when creating scripts this could be considered debugging, because if you knew what parameters a raw numeric were going to be, you wouldn't need to use /debug. Thanks for the writting your guide (many mIRC script don't use :error), but I doubt it would teach me somthing I didn't know already. As you can see from our registration dates, I've been doing this longer than you have. This is of course not including the 10 years of programming experience I had before I joined the forums.
|
|
|
|
Joined: Dec 2002
Posts: 109
Vogon poet
|
Vogon poet
Joined: Dec 2002
Posts: 109 |
Let me see if I can explain this to you... Programmers use error handling to catch errors, so script can be written so that those errors don't occur often or at all (sounds like debugging to me). No, you've missed the point. As already explained, error handling is part of a script's usual behaviour. Sometimes it will receive input which it likes, then perform a function accordingly. This is its usual behaviour. But every good program/script also has code to ensure that it doesn't break in certain situations. For example, if you had an ON TEXT trigger that performed mathematical division on numbers written in a channel, you'd want to make sure that if a number written was 0 (zero), you don't try to divide by it as that would cause an unhandled error. In languages like Java it will throw an uncaught runtime exception and your program will crash. In some C++ situations the program will also crash. The code to do this is Error Handling code ... but this has nothing to do with whether or not the code itself is correct. If your script wasn't working, you'd debug all your code... not only the bit for correct behaviour, but for the error handling code too. Don't mistake 'error' for 'bug'. Well now, on the other side, I am wondering why I'm not catching raw events with numeric X (was a case of this in 6.21), so I use /debug to see if that numeric is even being sent from the server. Since in both cases I was trying to find out why something didn't work, I was debugging. Plain and simple. In this case, yes. /debug has uses as a tool during script creation. However it isn't a tool to debug your scripts. It is a tool to view network traffic which can nonetheless be used to debug your scripts. There IS a difference. (Rather like a hammer is a tool to secure nails into wood... but I still use a hammer to crack open a coconut.) Thanks for the writting your guide (many mIRC script don't use :error), but I doubt it would teach me somthing I didn't know already. As you can see from our registration dates, I've been doing this longer than you have. This is of course not including the 10 years of programming experience I had before I joined the forums. No need for the bragging. Aside from anything, moaning about how much 'experience' you have is all well and good .. except you've revealed that you don't know what error handling is.
<Ingo> I can't uninstall it, there seems to be some kind of "Uninstall Shield"
|
|
|
|
Joined: Dec 2002
Posts: 580
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 580 |
No, you've missed the point. As already explained, error handling is part of a script's usual behaviour. If you are saying it's usual to monitor unusual behavior, then I agree with you. Errors should not usually occur. If the reason an error occurs is known, it should have a checking "method" written to prevent the error from occurring. I am through with the definition fight. I've stated my definition, if you don't like it, provide online sources that prove me wrong, if trying to convincing me is so important. But don't plan on me responding anymore to this thread. BTW, here is my proof, here and here. To summarize the definition links... Dictionary.com definition of debugging 1. to detect and remove defects or errors from. 3. Computers. to detect and remove errors from (a computer program). WordNet definition for error 2. inadvertent incorrectness 6. (computer science) the occurrence of an incorrect result produced by a computer
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
The point tomalak16 and argv0 are trying to make is that just because an error is generated does not mean it is a bug - provided the error is handled. And likewise just because some code is bugged does not mean it will generate an error. The try/catch method is a legitimate and often practical method of writing valid, bug-free code. As someone who seems to code in Java I would expect you'd be very familiar with that practice. Although not quite as sophisticated, the :error method can be used to trap and handle unforeseeable problems in mIRC script. That isn't debugging.
Now to try and get back on track with the original suggestion: A full blow-by-blow of each and every command and event and identifier's behaviour as it happens wouldn't be much good in most cases. You'd just have 100,000 lines of data and no idea where to start. What would make sense is the ability to make mIRC display a complete traceback of the commands called that lead to an error being generated. Beyond that though, all you really need to do with debugging is to add echo's (or use the -s switch in some newer commands) in key places in your code so you can accurately track where the code is going. This is more useful than something dumping all command flow at once because you only get data on the relevant parts of code.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
Joined: Dec 2002
Posts: 580
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 580 |
Notice it's called try/catch/throw and not checkerror/error/senderror, my only point is an "error" is never planned. If these verbs (try/catch/throw) were applied to a noun the best choice would be "control", not "error". Calling this mechanism error handling is a misnomer, since it has broader uses. Even the definition of exception (below), precludes it from being an error, since it's advertent. An unhandled exception would be inadvertent (an error). Dictionary.com definition of exception: 2. something excepted; an instance or case not conforming to the general rule. mIRC can call it error handling because it lacks a throw, and thus all ":errors" are actually errors (inadvertent). OK, this is my last post to this thread...
Last edited by NaquadaServ; 20/04/07 08:58 PM.
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
You seem to be arguing about the semantics of the terms being used. It really doesn't matter whether it's called error handling, exception handling, or anything else. It's all doing the same thing - which is not merely debugging.
Off the top of my head I can't think of any situation in mIRC in which error handling code isn't triggered by an actual error. Errors are neither good or bad, it's what you do with them that counts. For instance trying to write to a file that is in use by another application is an error, however as long as my code catches that error and either does something else or reports to the user that it cannot complete the requested task it isn't a bug and isn't a bad thing.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
|