Forums Bug Reports Making a Bug Report

Before the Bug Report:
If you are not using the latest release of mIRC download and install it. Earlier version are no longer supported though most versions are backwards compatible with it's perdesessors. The bug you are reporting might already be fixed in a later version.

If running on a windows 64bit machine, try running your mIRC in 32bit compatibility mode. Khaled does not support mIRC on wine under *nix, though occasionally he will modify the source to fix bugs in wine.

Unload all scripts and dlls, close all COMs and sockets, turn off all timers and restart mIRC. Make a simple example script that reproduces the bug. If you are unable to reproduce the bug then most likely it was one of the things mentioned above causing the error. If it is. One by one reload the scripts until you find the one causing issues



The Bug Report:
First thing, tell us what this outputs:

Explain to us the bug in detail, the current outcome, and the expected outcome. Give the example code that reproduces the bug and tell where and what is going wrong using comments(;this is a comment). If need be, link to a small picture(using the img tag) to show what is wrong.

DO NOT use external links. This includes links to the example script(use the script tags) images(use the img tag) or videos.
DO NOT POST A LINK TO SOMETHING THAT HAS TO BE DOWNLOADED
DO NOT bump an old thread unless there is something you can add to it. All bug reports are read by Khaled though he won't respone to them all. if the bug has been reported bumping it will not get it fixed any faster
DO NOT get angry if Khaled does not reply to your bug report. He reads each and every post in the bug-reports forum but hardly ever replies unless he needs more information from the user, or has fixed the specified bug for the next version.
DO NOT argue with a member if you are told the bug you are reporting is intentional.

Ok, so I've added some more to it, and changed some things. So if one of the mods would delete this post and replace the first post with what's below I'd appreciate it. Maybe make it a sticky since there has been some confusion about bug reports here lately:




Before the Bug Report:
If you are not using the latest release of mIRC download and install it. Earlier versions are no longer supported though most versions are backwards compatible with it's predecessors. The bug you are reporting might already be fixed in a later version.

If running on a windows 64bit machine, try running your mIRC in 32bit compatibility mode. mIRC is wrote as a 32bit application which may cause errors under a 64bit machine.

Khaled does not support mIRC on WINE, though occasionally he will modify the source to fix bugs for wine. mIRC was wrote as a win32 application, and with wine still unfinished the bug your are reporting is more likely a problem with WINE than with mIRC.

Unload all scripts and dlls, close all COMs and sockets, turn off all timers and restart mIRC. The 'bug' may very likely be a script malfunction. Afterwards, try to make a simple example script that reproduces the bug. If you are unable to reproduce the bug then most likely it was one of the things mentioned above causing the error. If it is a script issue, one by one, reload the scripts until you find the one causing issues.



The Bug Report: BE VERY CLEAR AND DESCRIPTIVE ABOUT THE BUG
First thing, tell us what this outputs:The reason is this command tells us the operating system you are using, what version of mIRC you are using, if your mIRC.exe is currupt, and the number of scripts/dlls/coms/sockets/timers that you have loaded/running. This information is vital in finding exactly what is causing the bug and speeds in getting it fixed.

Explain to us the bug in detail; what causes it, when it's caused, how to reproduce it, the current behavior of the bug, and the behavior you expect.
Give the example code that reproduces the bug and tell where and what is going wrong in the code using comments(;this is a comment). If need be, link to a small picture(using the img tag) to show what is wrong.



The Bug Report Don'ts:
DO NOT link to external pages or downloads; this includes links to the example script(use the script tags), images(use the img tag), and/or videos. Khaled shouldn't have to run all over the internet trying to figure out what your bug report is about.

DO NOT bump an old thread unless there is something you can add to it and don't get angry if Khaled does not reply to your thread. All bug reports are read by Khaled though he hardly responds unless he needs more information about the bug or to say that it has been fixed in the next version to be released. If the bug has been reported bumping it will not get it fixed any faster, nor will getting upset over it.

DO NOT argue with other members about your bug or the information you have given or been given. For one thing, those that read and respond to bug reports generally know what they are talking, and for the other, only khaled knows the entirety of mIRC and it's workings. Khaled reads all posts on all bug reports and he shouldn't have to go through the annoyance of sifting out petty bickering when figuring out what is going on for/with the user's mIRC.

A few notes:

1. Please don't suggest that users run in 32 bit compat mode. Khaled needs to know if there are bugs w/64bit compatibility, therefore users should report their environments. There should NOT be any 64bit issues in mIRC. If so, they need to be fixed immediately. The fact that mIRC is a 32bit app does not mean it does not support 64bit environments. AFAIK Khaled does support 64bit environments, and pretty much every OS install is 64bit these days, so it would be silly of him not to. Compiling a 64bit app is a whole different story, though-- a 32bit exe file does not mean it is not 64bit compatible.

2. Ditto for wine. Users should report their original environments. You kind of answered (& contradicted) this one yourself: "occasionally he will modify the source to fix bugs for wine"; therefore, Khaled does support WINE. Users should not be discouraged from reporting potential major compat issues with wine. Khaled *might* need to fix them. In some cases, they are not necessarily wine issues, but the only way we can know is if the users report these issues. I would suggest rewording that paragraph to still explicitly encourage wine users to post bugs-- just realize that their bugs may in fact be wine bugs (I think this is what you were trying to get across, it just comes across more as "don't report bugs if you use WINE" to me).

3) Finally, this might seem quite contrary to some previous discussions, but I wouldn't necessarily tell users "NOT" to argue with members so prominently. Again, I understand what you're trying to get at, but IMO it's not proper to make it seem as though members are *always* right. If the user has a point, they should voice their concerns-- we shouldn't stifle disagreement just because "members know better". As a sidenote, it's fairly unclear who "members" are-- is a user with 300 posts considered a "member"? What about 30? This seems arbitrary, and new users will likely be unaware of who is experienced and who is not. Maybe this should be worded a little less strongly (instead of "DO NOT", a simple "try not to" would suffice)

Thank you for posting this, though.

As another addition, we should recommend that users read this very popular article on posting effective bug reports. That document should serve as a basis to fill in any of the standard bug report etiquette that people should attempt to follow regardless of the application they are reporting a bug for.

You are right about about one and two. I wasn't stating them to discourage users. Was just giving information about it. I know that most OS these days are 64bit, and was just stating that mIRC might run better in compat mode. And if this stops the bug[which should be reported even so] the information would be helpful when submitting a bug report.

And with wine, I wasn't trying to discourage a user from posting a report, was just telling them that it is as much of a possibility to be a bug in WINE as it is to be a bug in mIRC.

There's a difference between discussion and arguing. I'm not saying don't discuss and give point of views, but there's a distinct line between "this is what I think about your issue" and "this is what I think about you".

A member is anyone that is registered. I'm not saying we are always right[that's humanly impossible], but those that do reply to bug reports generally know how mIRC *should* act and react.

I think instead of using "other members", maybe just "others" so there is no confusion over what or who a member is.

I definitely like the idea of a sticky explaining how to submit bug reports. Maybe this thread should be to allow everyone to offer input and get a final explanation set up and then create a new topic that is locked/stickied once everyone agrees that is has everything necessary and is completely clear. Just a thought.

In the end, the biggest points I'd personally like to see included in any bug report are:

* Subject should be at least somewhat descriptive of the problem to make it easier to find later. That doesn't mean to write an essay on the subject line, but put something that at least lets someone browsing the forum be able to have at least a general idea of what the post is about before opening it. This makes it much easier when trying to find a specific bug report on the forum. And don't put anything in the subject line that is not related to the bug.
* OS/mIRC versions, scripts loaded, etc. This can most easily be given using the //echo line provided in the first post here.
* Detailed description of the problem. It doesn't have to be a really large description, but should include all relevant information. What is the bug? Why do you think it's a bug? From your testing, have you found anything out about the bug such as what exactly is causing it or even what is definitely not causing it? And so on. If it's relevant, include it.
* When possible, an example input followed by what you are getting as output AND what you are expecting for the output.
* If you understand why you're getting the output, but think something needs changed because you think the output should be something else, then also include WHY you think it should be changed.
* Any example code (stripped down to only what is required to produce the bug). Stripped down means not to include anything that isn't related, or if you do include it, be very clear in the post that it's not related to the bug.
* If you feel it is useful, include an image (using the forum's image tags) showing what is going on. However, the image should never be used as a description. It should only be used as an additional example.

Most of that's already been mentioned in one way or another and the link provided by argv0 mentioned the information as well. I just wanted to provide what I think are the most important things in a bug report.

As to a final version to sticky, I think we want to try to have it as short as possible while still being clear and including everything we want included. People ignore anything that's too long (like some of my posts ). Also, I think we should try to make it sound a little more "friendly". Just like with being too long, if there are a lot of DO NOT's in bold, people are less likely to read it.

It's $sock(0) not $socket(0).

actually it's $sock(*, 0)