|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
OP
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
I found a really weird behavior in timer: alias testtimer {
echo -a $ticks
timertest $+ $ticks -ho 1 0 testtimer
} /testtimer: 18443063 - * Timer test18443063 activated - 18443079 - * Timer test18443079 activated - * Timer test18443063 halted so it seems that the second time /timer is called here, the alias isn't finishing (we don't see the * Timer testX halted) however: alias testtimer {
echo -a $ticks
timertest $+ $ticks -ho 1 0 testtimer
echo -a $ticks
} Works as expected (control+break will help here) Now: alias testtimer {
echo -a $ticks
.timertest $+ $ticks -ho 1 0 testtimer
} Also works as expected.
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
Joined: May 2004
Posts: 11
Pikka bird
|
Pikka bird
Joined: May 2004
Posts: 11 |
alias testtimer {
echo -a $ticks
timertest $+ $ticks -ho 1 0 testtimer
} works for me 151583593
* Timer test151583593 activated
151583608
* Timer test151583608 activated
* Timer test151583593 halted
151583624
* Timer test151583624 activated
* Timer test151583608 halted
151583639
* Timer test151583639 activated
* Timer test151583624 halted
151583655
* Timer test151583655 activated
* Timer test151583639 halted
151583671
* Timer test151583671 activated
* Timer test151583655 halted
151583686
* Timer test151583686 activated
* Timer test151583671 halted
151583702
* Timer test151583702 activated
* Timer test151583686 halted
151583717
* Timer test151583717 activated
* Timer test151583702 halted
151583733
* Timer test151583733 activated
* Timer test151583717 halted
151583749
* Timer test151583749 activated
* Timer test151583733 halted
151583764
* Timer test151583764 activated
* Timer test151583749 halted
151583780
|
|
|
|
Joined: Apr 2010
Posts: 969
Hoopy frood
|
Hoopy frood
Joined: Apr 2010
Posts: 969 |
I don't think it's ticks causing the issue, it's the -h switch. Due to it's behavoir using ".timer -h ... editbox -an 'stuff'" from an on input will cause you to get stuck in an infiniate loop. Even if u have vars/checks making sure the oninput wasn't triggered from the timer.
|
|
|
|
Joined: May 2004
Posts: 11
Pikka bird
|
Pikka bird
Joined: May 2004
Posts: 11 |
err. on input? I don't see that. in OP's script. I don't know why he isn't seeing the timer output. I checked it on mine and get the expected response
Edit: in testing this script for another purpose, I've discovered that it does halt, rather arbitrarily, after a bit, without notification. the test timer is still in the active timers list, and hasn't expired, even though it's a 1ms timer. I'm thinking it's a timer initialization bug
Last edited by Dreadnought; 05/07/11 05:02 PM.
|
|
|
|
Joined: Apr 2010
Posts: 969
Hoopy frood
|
Hoopy frood
Joined: Apr 2010
Posts: 969 |
My response was in reply to so it seems that the second time /timer is called here, the alias isn't finishing This should only trigger once, when shift+enter is pressed, but it continues to trigger repeatedly. This DOESN'T happen with the -m switch on *:INPUT:*:{
if ($mouse.key == 4) { .timereb -h 1 1 editbox -an $1- | halt }
} It's as though the On Input isn't finished, so $mouse.key isn't reset yet.
Last edited by FroggieDaFrog; 05/07/11 05:04 PM.
|
|
|
|
Joined: May 2004
Posts: 11
Pikka bird
|
Pikka bird
Joined: May 2004
Posts: 11 |
maybe. but that's not the problem Wims was talking about; you should create a new topic for that, and not hijack this one.
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Keep in mind that a -h timer (high resolution) could trigger out of order, or within the same $ticks as the last timer call. The high res timer has a resolution much higher than ticks (weird huh?)-- ticks are only accurate to ~10-15ms, whereas a high-res timer is accurate to 1-2ms I believe. Anyway, if $ticks is the same when a new timer fires, your older timer won't fire, possibly causing a race condition and not triggering the command either.
In short, you shouldn't rely on $ticks to seed a high-res timer. Removing "$+ $ticks" and letting mIRC generate its own timer names seems to work just fine for me. Even if there is no race condition, you won't want to seed with $ticks, so you should remove it.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Apr 2010
Posts: 969
Hoopy frood
|
Hoopy frood
Joined: Apr 2010
Posts: 969 |
I was only validating Wims' assumption that the alias being called seemed to not have finished when the timer is called again and with that assumption, I thought I should elaborate.
Though, you are correct, and I will create a new thread, though I think the issue I mentioned, and wims' not seeing the timer halted message are of the same issue with /timer -h.
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
OP
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
Edit: in testing this script for another purpose, I've discovered that it does halt, rather arbitrarily, after a bit, without notification. the test timer is still in the active timers list, and hasn't expired, even though it's a 1ms timer. I'm thinking it's a timer initialization bug This is the bug I'm reporting
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Then it would be wiser to explain this when you write up your initial bug report. In other words, please don't write "works as expected" unless you've explained what your expectation is. Until now, everybody has been wasting their time discussing irrelevant details because you hadn't provided the right information. This isn't the first time, either. Please make sure your bug reports are more detailed.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
OP
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
Then it would be wiser to explain this Sorry but I did explain, with my words, what I think is a bug and I gave a code to reproduce it. What kind of information were you waiting for if it's not my description of the problem and the code ? There's no "my expectation" regarding timer, everyone have the same expectation because the behavior is described in the help file, there's only one expectation posssible. Not sure who wasted their time here if not only you, and me now. This isn't the first time, either. Please make sure your bug reports are more detailed. You are wrong imo, everytime I make a bug report, I try to be as clear as possible by giving each detail I know about the bug, it's not necessarly my problem if people don't get the bug too, but I'll make sure to give more details in the future
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Sorry but I did explain, with my words, what I think is a bug and I gave a code to reproduce it. I'm not going to attempt to have a pointless meta-conversation about how your bug report was inadequate. Perhaps you should just heed my advice and acknowledge that there was enormous confusion in this thread about what you were reporting. The fact that the other two posters in this thread had no idea what you were reporting is a pretty good indicator that something is wrong. Unless you're of the belief that you can't be wrong, and everyone else is an idiot, I think you should be a little less defensive. There's no "my expectation" regarding timer Yes, there is. It's not sufficient to assume that your expectation matches that of the help file, especially since the help file does not describe anything regarding the topic you're reporting, so the help file point is quite irrelevant. More importantly, your expectation may not be what the help file describes (in this case we might say that this is not per spec, but in some cases the help file may be wrong too-- you would point that out). We need to know this-- it wouldn't be the first time a bug was mistakenly posted because the user had an expectation that did not match up with the specification. In a few of those cases, we discovered that the specification itself might be wrong (and the user was right after all). When reporting a bug you need to tell others what result you got, but more importantly, what result you were expecting. I don't see any mention of the actual bug you were reporting, ie., the fact that "the test timer is still in the active timers list", and you made no mention of this in the reproduction steps, nor did you ask anyone to check this; IOW you made no mention that you were expecting the timer to disappear. That might seem fairly obvious, but the lack of this information in your reproduction steps as well means that nobody was expecting this information to be relevant-- you're lucky that Dreadnought accidentally caught this. It's not in the bug subject line either. Nobody knew this was related until you had to point it out a few days later. This doesn't seem wrong to you? You are wrong imo, everytime I make a bug report, I try to be as clear as possible by giving each detail I know about the bug This is not an opinionated assertion. The forums have a search feature, you can look up your past posts for real evidence. Two feature suggestions come up: this and this (the latter of which I still don't even understand, and I guess by the lack of responses, others don't either). I even recall one situation where you were asked outright to better explain your report-- but the forums don't seem to go back far enough. There is good information on how to write a proper bug report. I highly suggest you read this article completely so you understand what people expect of you when you report a bug. There is a fair bit of valuable information there, you should follow it to avoid future confusion and wasted time.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
argv0 is correct that some of your reports/suggestions really could use more details so they are easier to understand. His two examples are very good examples of what he is talking about. When suggesting a feature, you don't want to just say "this doesn't exist, but should." That doesn't provide anywhere near enough information. Some people may be able to figure out what you mean based on their own experiences, but others may not. In order to make it a useful suggestion, you need to provide details about what you are talking about. What is the suggestion? What syntax (if applicable) are you suggesting? What is an example input and with that input, what are you expecting as an output? Why do you think it's important to add? There are other things you could also include depending on what the suggestion is. For your timer one, I'm assuming you mean that you want to be able to do //echo -a $timer(test*,0) and get a count of all timers matching that wildcard matchtext and replace 0 with N to get the timer that for that number. But you don't say that. You don't give an example like the //echo example I just gave. You did give an example of syntax, but that doesn't help if you don't explain what you want the output to be with that syntax. You also don't give any reason why you think it would be worth adding. That part is optional, but a suggestion is more likely to be considered if Khaled thinks the reason you give is a good one than if no reason is given and he doesn't think of any good reason to add it. Bug reports are similar in that having a clear explanation of the bug, what the input and output are and what you think the output should have been, and any details that may be relevant. Step by step ways to reproduce are great if possible. Pictures are sometimes helpful, but are the least important and should never be used in place of a written explanation. And with this report, your first post doesn't clearly say what you think the problem is. Ok, I understand that the timer appears to not show the text saying that it's completed, but nothing about the timer staying active. You also don't mention anything you did to try and determine what the cause is. Is it the timer? Is it -h? Is it because you used Ctrl-Break? Is it $ticks as your subject seems to suggest? Is it something else? Can you reproduce it only with the short script you included, or can you reproduce it even without the timer or else without -h? Things like that, which you may have already looked into, would be useful information. If you already checked and verified that it's related to something specific and you include that information, then it saves people a lot of time trying to figure that out for themselves. Whatever you do, never assume someone knows what you are talking about. Explain it in detail. Many times, I have had to ask people to clarify what they are talking about because they assumed I knew what was in their mind. For example, someone could ask me, "Did you fix the problem?" and I may have been dealing with multiple problems and have no idea what one they are talking about. They assume I know because in their mind, they are thinking of the specific problem. But I'm no mind reader and so I need specifics. Or people will bring up something that was discussed an hour or more ago without pointing out that they are talking about that previous discussion. Again, without information, it can leave the listener unsure what you're talking about even though it's perfectly clear to you. In any case, I think part of the problem with understanding is a minor language barrier. Your English is good and in most cases, it's easily understood, but there are times in your posts where something you say doesn't really make sense. I understand the difficulties in using other languages and there really isn't anything you can do to get better besides continue using the language, but it is something to keep in mind if someone doesn't understand what you're saying. It may just be that you need to try saying it in a different way. Very often, rewording something makes all the difference. Like I said, your English is good with only a few issues that come up; this is just informational to maybe give you an idea into why someone might have difficulty understanding something. And keep in mind that any minor language issue may be minor to someone who understands the language really well, but may be very major issue for someone who doesn't know the language well. And, just to fix a spelling mistake I've seen you make a few times that makes me do a double take and might confuse others... "propriety" should be "property". ![smile smile](/images/graemlins/mirc/smile.gif)
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Jul 2011
Posts: 3
Self-satisified door
|
Self-satisified door
Joined: Jul 2011
Posts: 3 |
The fact that the other two posters in this thread had no idea what you were reporting is a pretty good indicator that something is wrong. ^ Wow, I read it and I understood it fine. And so did the other people Argv0. the test timer is still in the active timers list, and hasn't expired, even though it's a 1ms timer. I'm thinking it's a timer initialization bug ^ The guy was agreeing.. stating that he got the same thing but explaining what can easily be read from Wims's post by the fact that he said it doesn't halt. If it doesn't halt, then it is obviously still active, is it not? FroggieDaFrog also clearly understood it. If you thought they didn't, then it is only you who failed to understand and follow what was being said. Don't start calling other people inadequate and telling them they should add more detail when you're the only one that doesn't understand it. Perhaps run the code and see for yourself? The fact that you attempted to justify your complaint by stating that the other two people who DID understand it didn't suggests that you're either a clueless or just out to start an argument. Unless you're of the belief that you can't be wrong, and everyone else is an idiot, I think you should be a little less defensive. ^ Putting words in his mouth so you can make another statement to try and put him down... It certainly looks like you're not trying to help anyone here. Besides, he wasn't being defensive, he was saying exactly what he had done. I don't see any mention of the actual bug you were reporting, ie., the fact that "the test timer is still in the active timers list", and you made no mention of this in the reproduction steps, nor did you ask anyone to check this Obviously if a timer doesn't halt, it is still active; you're just picking hairs. That being said, the bug he reported is obvious... the timer doesn't halt. Anyone with a brain stem can get that from his post. He pasted the code he used to get the result.. that is the reproduction steps.. you can't honestly say you didn't see it there. Lastly, why would he need to ask anyone? For all you know he did before posting it, you're assuming what you want to be the case - a very bad habit. But of course, you don't expect a personal invitation to execute it yourself do you? I mean, if you're this interested in it, surely you'd just copy/paste and execute it yourself? And as for the 'expectation' toot, he clearly meant 'the author's intended result'. I certainly had no problem grasping what it meant, because of course having seen the code, I knew what it should do. If you don't understand the language, how are you justified in criticizing that aspect of it. Picking hairs and deliberately trying to put someone down with flawed reasoning and ignorance. You're clearly just being malicious which isn't helping anybody. Yes that is an unexpected result Wims. You didn't have to point it out but you did so that it might be noted and ammended. I for one am not going to write an essay to discredit you for not going into the depth expected by an employer. Pointing out a bug as a USER of a program is not to be compared with someone who's reporting a bug for their profession.
Last edited by TJAR; 08/07/11 09:59 PM.
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
Considering you're new here, maybe you should leave off arguing with the regulars. Let's see now... Original post: The *alias* isn't finishing. Subject states timer AND $ticks. No mention about the timer not finishing or that $ticks has nothing to do with the problem. Reply 1: It works (obviously doesn't understand the problem) Reply 2: I think it's something else that relates to an infinite loop situation in on input. Again, although noting the timer switch, nothing regarding a timer that isn't stopped. So again, not clearly understanding the problem. Reply 3: Confusion about reply 2. Edited to note that he finally figured out what should have been noted in the original post. Edit was over 53 hours after the first reply and, as he stated, it was while trying to do something else. That's a lot of wasted time. So, sorry to say, but it took 3 replies and an edit totaling over 53 hours before someone found out what Wims was saying. That sounds like confusion to me. Part of the confusion most likely results in Wims including $ticks, which had nothing to do with the problem. If you submit an example of the problem, it should be only what relates to the problem. Extra things in it just cause confusion unless you are very clear in pointing out that those extra things are not related (which wasn't done). In addition, the quoted output isn't necessarily clear. It could just as easily be showing that the timer order is not what he expects (which can sometimes happen because the timers are not perfect in mIRC). Before you start fighting, you should make sure you have your facts straight. If you understood it clearly, fine. Obviously others did not until they worked on it long enough. In any case, there is absolutely no reason why the bug report couldn't have stated quite clearly what the bug was so that it did not take so long to find out what was being reported. Step down from your high horse and stop arguing in your very first post here. Also, all bug reporting should be done thoroughly. It has nothing to do with whether you are a user or that's your job. Posting incomplete or misleading bug reports lead to a lot of wasted time and in many cases, the bugs do not get fixed until someone else who DOES write a detailed report comes along and reports it. If you want it fixed, then learn to submit quality bug reports. Complaining that it's too much work (or whatever your reason for not doing so) doesn't help anyone. Btw, it's funny that you claim to be superior in your understanding of what people say and then you quote argv0 as saying that the timer still being active was not listed in the reproduction steps and then you turn around and comment about how the reproduction steps were there. If you pay attention to what was written, argv0 clearly knows that the reproduction steps were there. He didn't say they weren't. He said that the steps do not mention the timer still being active. So if you are so good at understanding things, why'd you miss something that is really quite obvious? It's always easier to understand something after someone points out the solution than to try and figure it out yourself. Nice to jump in and argue after you already know the solution based on what others wrote and then claim that you knew all along.
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Jul 2011
Posts: 3
Self-satisified door
|
Self-satisified door
Joined: Jul 2011
Posts: 3 |
Original post: The *alias* isn't finishing. Subject states timer AND $ticks. No mention about the timer not finishing or that $ticks has nothing to do with the problem. Ok, it is clear that the timer didn't finish. He showed the output, yes? That shows that $ticks was not echoed after the second timer started. Since the command /testtimer would result in $ticks being echoed and it wasn't, and that the timer is still active - meaning it hasn't executed - is proof enough that the timer didn't finish. The data is there, just not in the form you're looking for. That's not a fault of the poster's, but a fault of yours. Attempting to validate your statement against the quoted evidence in the way you did - stating that 'it could be showing' - is flawed reasoning. You should be looking at what it does show, not what it could but doesn't show. True, he did not state $ticks has nothing to do with it, and there should be a decent amount of quality to the report to warrant looking into. However, if it was one's intention to waste time, they could just as easily edit something up, yes? There is clearly an unexpected result shown there. It is no less credible than a massive detailed report. Believe it or not, there are a lot of people out there who like nothing more than to waste people's time, and they will do so by attempting to be as convincing as possible. Now that we've established that there is clearly an issue; when presented with a bug, you would first test it to see the result for yourself just to be sure, regardless of the quality of the report, yes? And that testing would be done thoroughly by the reviewer, regardless of the evidence provided. $ticks would be found to not be the problem. Even if Wims had stated that, it would be tested and concluded just the same. I understand some people's need to have everything done to perfection: listing all the content that the reviewer will both have to consider and will know they will have to consider anyway. In a lot of cases - this one included - it is a waste of time. Alright. "Funny that I claim to be superior in my understanding" - Since I made no such claim, I can do nothing but take that as a compliment; although I don't consider myself to be superior to anyone I communicate with over the internet since you can never really know them. I read that post again and you're right, I admit I miss read that part about the reproduction steps. My bad, and apologies to argv0. However, that says nothing for my understanding unless you judge it by what I miss read it as because it was miss read, not correctly read and failed interpretation. The rest is all true, and trying to discredit my post because it is my first on this forum is flawed. Such an accusation suggests that no one knows anything -about- what is posted on a forum unless they've been around on the forum for a good length of time. That is tantamount to suggesting that you need to be an active poster on a forum to be able to learn anything, which is obviously not true. And if you meant to say that being on here longer means you have a better understanding, that is of course also absurd because not every post is as old as your registration date, and you can gain understanding in more ways than reading forum posts. It is often - not always - easier to understand something when someone else provides you with the solution, rather than try to work it out yourself. Now, I assume you mean 'understood' not 'knew the solution' because obviously the solution hasn't been posted, we're just interpreting the problem. Stating that I only understand because of what others wrote for no other reason than the fact that I posted after them is again, flawed reasoning. Admittedly I did create this account to reply a few hours after reading most of the posts, but you cannot say with any certainty that I did not understand the problem after simply reading the first post. I already claimed to have done so, but of course you have no way of knowing whether that is true or false. It's an assumption of the worst of someone which only reflects badly on you.
Last edited by TJAR; 09/07/11 12:00 AM.
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
Yep. ![smile smile](/images/graemlins/mirc/smile.gif)
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Jul 2011
Posts: 3
Self-satisified door
|
Self-satisified door
Joined: Jul 2011
Posts: 3 |
Replying to arguments against what you've said seems to be something you'd do, argv0. I don't know whether you can't be bothered to do so now, or whether you've got nothing reasonable or constructive to say in response. Obviously I'd be inclined the believe the latter since that was perhaps my secondary goal in this.
I've actually defined you as a troll with my descriptions. Putting a name to my descriptions and then calling me it isn't very clever, nor does it help anyone. But regardless, you might feel justified in saying it? It is possible for someone to believe something absurd beyond reasonable doubt. Interpretations depend on perception, which is different in everyone. You may use that to claim that I'm stating that I too could be incorrect, which would be a valid statement. I don't believe I am incorrect, however, much like you probably don't believe your posts to be malicious.
Anyhow, I've said all I needed to say in those two posts. You're free to have the last word now if you wish. Flame me if you like; I won't reply - nothing you say will disprove anything I've already said, so there's no need.
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
OP
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
I'm not going to attempt to have a pointless meta-conversation about how your bug report was inadequate. Perhaps you should just heed my advice and acknowledge that there was enormous confusion in this thread about what you were reporting. The fact that the other two posters in this thread had no idea what you were reporting is a pretty good indicator that something is wrong. Unless you're of the belief that you can't be wrong, and everyone else is an idiot, I think you should be a little less defensive. Really I'm not on the defensive, I simply don't think there is enormous confusion in my bug report or feature request, it's not always necessary to give all details, it's a good idea but it's not required. Also you assumed that fact, your assumption are not a pretty good indicator of anything I can be wrong and everyone else isn't an idiot, that part wasn't relevant, it just looks like a personal attack It's not sufficient to assume that your expectation matches that of the help file I talked about the help file because nothing in it say that you cannot call an alias with a -h timer, implying only one expectation is possible: the timer call the alias which call the timer again etc. When reporting a bug you need to tell others what result you got, but more importantly, what result you were expecting. I don't see any mention of the actual bug you were reporting, ie., the fact that "the test timer is still in the active timers list", and you made no mention of this in the reproduction steps, nor did you ask anyone to check this; I did tell what results I get and I just said why I didn't talk about what I was expecting and what is the bug. That might seem fairly obvious again, yes it is imo and that explains why I didn't give full details but the lack of this information in your reproduction steps as well means that nobody was expecting this information to be relevant-- you're lucky that Dreadnought accidentally caught this. It's not in the bug subject line either. Nobody knew this was related until you had to point it out a few days later. This doesn't seem wrong to you? It is wrong indeed, the thing is that you are blaming my lack of informations while I'm saying that it's not because people don't get it that my lack of information is the problem, and I still maintain that version, I even wonder what he thought was the bug at first. I also would like to say that you did get it correctly and that since your first reply. The subject line is supposed to be a general title, I didn't know what to put there to be honnest, because I didn't know (still true) what was the problem, I just reported it and put the words timer and ticks because it's what the code is using. This is not an opinionated assertion. The forums have a search feature, you can look up your past posts for real evidence. Well, sorry to defend my point when someone is telling me I don't know how to write a proper bug report and that my posts are generally unclear. I looked at the two links, I still think both are self-explanatory when you know what it is about. $dialog().ontop would reflect if -o has been used with /dialog $timer(wildcard*,N1) would return the Nth timer whose name matches the expression. Now I think I know how to write a proper bug report, but maybe in the future when you don't understand something you could just ask the person to be clearer instead of acting like that
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
OP
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
You are basically repeating what has been said: yes I could be more precise in my post, it's always possible, not always needed. Whatever you do, never assume someone knows what you are talking about. Explain it in detail. Many times, I have had to ask people to clarify what they are talking about because they assumed I knew what was in their mind. For example, someone could ask me, "Did you fix the problem?" and I may have been dealing with multiple problems and have no idea what one they are talking about. They assume I know because in their mind, they are thinking of the specific problem. But I'm no mind reader and so I need specifics. Or people will bring up something that was discussed an hour or more ago without pointing out that they are talking about that previous discussion. Again, without information, it can leave the listener unsure what you're talking about even though it's perfectly clear to you. This is precisely why I don't include full details, my suggestion or my bug report must be clear for Khaled, I don't need to assume he knows what I'm talking about. Now when helping someone on the script & popups section here or on irc, I always include full detail because the person that must understand what I'm saying isn't Khaled and don't have the same knowledge regarding mIRC. I don't think language is a barrier, I already got bugs fixed years ago, and my english was much worse than that. I actually spend time when posting here, trying to be as clear as possible.
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
Joined: Feb 2006
Posts: 546
Fjord artisan
|
Fjord artisan
Joined: Feb 2006
Posts: 546 |
Anyway, if $ticks is the same when a new timer fires, your older timer won't fire, possibly causing a race condition there may be some sort of race condition involved, since this only happens with low delays, but it doesn't seem to be the only problem. $ticks is perhaps a little misleading there; letting mIRC assign a name or using $rand(1, 1000000) instead, and we can see the problem is just as easily reproducible. in fact, giving the timer a constant name is the only case where i didn't observe the bug. Removing "$+ $ticks" and letting mIRC generate its own timer names seems to work just fine for me. did you remove 'test' too? :P to reproduce: remove the complete timer name, make sure there are no timers active, and run the test. the second step is important, and probably why Wims wasn't able to reproduce the issue after the first trial of the alias: that one timer that failed to execute was still considered active.
"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
I looked at the two links, I still think both are self-explanatory when you know what it is about. $dialog().ontop would reflect if -o has been used with /dialog $timer(wildcard*,N1) would return the Nth timer whose name matches the expression. This discussion has really gone too far already and you are welcome to take the advice on improving posts or to ignore it. But just to be clear on this one point of yours... if you had said both of those things in your feature requests, then the requests would be much more clear. It's never a bad idea to add more information than necessary (if it's relevant) instead of potentially leaving not enough information. Also, argv0 and others do ask people to be more clear all the time. He did that here as well, but instead of just saying "What?", he gave some information on HOW to be more clear. Like I said, you can choose to ignore it or you can take the advice and learn from it so you can improve future posts and reduce the confusion and time spent on figuring them out. Complaining about someone giving you advice on improving something doesn't really make much sense. And just because people aren't constantly replying with "What?" doesn't mean they always understand. A lot of people will see something that doesn't make sense to them and instead of replying, they just ignore the thread entirely figuring someone else who can figure it out will respond. When you have a post that gets no replies for a long time, there's a good chance that's what is happening. Either way, I'm done replying about this. There's nothing more to offer you if you don't want the suggestions. If you are willing to take the advice, then understand that the advice is there to help you improve and not to criticize you. Take what you can from it and move on rather than arguing about it.
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Dec 2002
Posts: 5,473
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,473 |
Thanks for the comments everyone, I will be looking into this issue.
|
|
|
|
Joined: Dec 2002
Posts: 5,473
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,473 |
Thanks this has been fixed for the next version.
|
|
|
|
|