Forums Bug Reports if $me == $nick

Using the script found in this post, I retested.

Turns out, you lose.

Results in mIRC v6.14:

Omitting both ( ) and { } is demonstrably faster, but it is also much harder to avoid ambiguity. Thus, these results show that the forms to use, in fastest-to-slowest order, are as follows:

Get your facts straight before setting yourself up as some sort of expert. The fall from the heights hurts more from that distance than down here where us coders live. Also, bear in mind that these statistics need to be retested with each new version because they do change sometimes; it's always best to check yourself before making such a fool of yourself, though we all do it occasionally.

Your post covers me completely, not much else to say here

it was you and online that got me into scripting like that, it looks a lot neater imo

Well in that case, it must be depending on something else

I also tested mine for 1000000 and got

1º time is 44672
2º time is 43719

From your example i run some tests and i found that you where right!

I was intrigued with the results and analysed your code so i tried.

So, lets now change the > to == in the if condition

* IF speed test: 100,000 iterations per test
-() -{} single 3719
+() -{} single 3422
-() +{} single 4546
+() +{} single 4594
-() +{} multi 4719
+() +{} multi 4812

so was i making a fool of myself?

Seems that no one loses, we all won since we learned a bit more today.

sore loser

Try to see some of my work 1º then think if you should call me loser...

* tidy_trax wonders why barely anyone on the internet can take a joke.

lol, tontito can

Your results varied from mine after you switched from a completely unambiguous a > b to the very ambiguous a == b. This is the ambiguity caveat I mentioned, not a change in the speed in which the parser handles IF conditions themselves. Consider the following condition (formatted to be completely unambiguous in every way):

if (%a == 0 join #me) { myalias }

Removing the () or the { } can certainly cause unexpected results. If %a happens to equal 0, then you will try to join #me with a key of myalias, rather than checking to see if %a contains the string "0 join #me" and then executing myalias. By the same token, if %a happens to contain the string "0 join #me", then you will execute myalias. (This assumes mIRC will parse it correctly at all, something I would very much NOT like to ask it to do in my coding.)

Don't expect me to be surprised that it takes the parser longer to figure out where the condition ends and the command begins when you switch the test case condition to something ambiguous, such as == or isin. However, now we're no longer testing the relative speed of JUST the if condition parser, we're also testing how long it takes mIRC to parse ambiguous lines, as well. So, obviously, when you have qualified your condition with ( ), the parser will KNOW where to stop. And notice that this only affects the -() -{} test. The rest will be relatively unaffected, since they are all already qualified anyway.

interesting,
i just think it is strange to see that mirc parses ambiguous lines faster than an unambiguous one, and, as we noticed it takes a lot less millis in the 100,000 iterations.

btw, how can i put a transparent backgoung in my pic with paint?
maybe i can only do it with photoshop...

It doesn't, as your results show.

your right , now i confused me

(general reply): Oddly, I get completely different results from you all.

//var %n = 10000, %ticks = $ticks | WHILE %n { dec %n | if 1 == 1 . } | echo -a * 1 == 1 . results: $calc($ticks - %ticks) ms

//var %n = 10000, %ticks = $ticks | WHILE %n { dec %n | if (1 == 1) . } | echo -a * (1 == 1) . results: $calc($ticks - %ticks) ms

//var %n = 10000, %ticks = $ticks | WHILE %n { dec %n | if 1 == 1 { . } } | echo -a * 1 == 1 [[ . ]] results: $calc($ticks - %ticks) ms

//var %n = 10000, %ticks = $ticks | WHILE %n { dec %n | if (1 == 1) { . } } | echo -a * (1 == 1) [[ . ]] results: $calc($ticks - %ticks) ms
_____

* 1 == 1 . results: 6496 ms
* 1 == 1 . results: 6955 ms
* 1 == 1 . results: 6549 ms

* (1 == 1) . results: 6652 ms
* (1 == 1) . results: 6525 ms
* (1 == 1) . results: 6984 ms

* 1 == 1 [ . ] results: 7108 ms
* 1 == 1 [ . ] results: 7123 ms
* 1 == 1 [ . ] results: 7094 ms

* (1 == 1) [ . ] results: 7347 ms
* (1 == 1) [ . ] results: 7033 ms
* (1 == 1) [ . ] results: 7174 ms

- Raccoon

It probably depends on the cpu type, what is yours?
mine is intel p4 2.8

If you can provide a short alias/script that reproduces the problem, ie. that works under 6.12 and doesn't work under 6.14, I should be able to determine the cause of the problem. Scripts should function equally well under both versions.

The main writer of this script Mr-Rdk informs me he has sent you an email with a script in it for testing out. But i will get a snippet as well and post here.

on 10:JOIN:# {
;Load Channel Parameters from File
if ($me == $nick) {
LoadChanSettingsFile $chan

if (%RemSpam. [ $+ [ $chan ] ] == ON) || (%RemSpam.all == ON) {
.timerscanspammers $+ $chan 1 40 { .scanspammers $chan }
}

echo 4 $chan 5«4Rdk©5» Updating IAL for $chan
set %Supress. $+ $chan ON
who $chan
.auser 98 $nick
}

=====

That is a snippet of code that falls over when using 6.14

I would need a self-contained bug report script that reproduces a specific, described problem. It should be possible to copy the bug report script into mIRC and to run it to see if it reproduces the problem you are describing.

In your snippet that is not possible because the code makes references to external aliases, identifiers, variables, etc. which I do not have.

The author of the script would need to use debugging code in his/her script, eg. using /echo to display values, in order to pinpoint the bug, and then submit a bug report that states what the bug is and how to reproduce it.

The main scripter has informed me he has all ready done so. So i shall leave things till somethings comes from that.

Thankyou for taking the time to reply to this post.