mIRC Homepage
Posted By: PhantasyX Improved /debug - 15/04/07 02:10 PM
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.
Posted By: hixxy Re: Improved /debug - 15/04/07 02:17 PM
/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.
Posted By: NaquadaServ Re: Improved /debug - 16/04/07 01:37 PM
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)

Code:
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. wink
Posted By: MeStinkBAD Re: Improved /debug - 18/04/07 04:24 AM
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.
Posted By: Om3n Re: Improved /debug - 18/04/07 08:01 AM
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.
Posted By: NaquadaServ Re: Improved /debug - 18/04/07 11:22 AM
Originally Posted By: MeStinkBAD
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)??? wink

My cousin is different from me, but we are both still related.
Posted By: argv0 Re: Improved /debug - 19/04/07 09:14 PM
Originally Posted By: NaquadaServ

Really? Why would you need to use debug, if there are no errors in a script (or mIRC)??? wink


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.
Posted By: NaquadaServ Re: Improved /debug - 20/04/07 01:25 PM
Quote:
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.

Quote:

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. smirk
Posted By: tomalak16 Re: Improved /debug - 20/04/07 05:22 PM
Originally Posted By: NaquadaServ
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'.

Originally Posted By: NaquadaServ
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.)

Originally Posted By: NaquadaServ
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. smirk


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.
Posted By: NaquadaServ Re: Improved /debug - 20/04/07 06:52 PM
Quote:
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
Posted By: starbucks_mafia Re: Improved /debug - 20/04/07 07:43 PM
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.
Posted By: NaquadaServ Re: Improved /debug - 20/04/07 08:28 PM
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... smile
Posted By: starbucks_mafia Re: Improved /debug - 20/04/07 08:45 PM
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.
© mIRC Discussion Forums