Forums Bug Reports if $me == $nick

Amongst a fleet of so many things itd take up a lot of space to report the multiple possible bugs .. the strangets yet most fundamental one is " if $me == $nick " no longer working .. why is this ?

Also a lot of various ial stuff seems to have changed to the point where the current script i use is presently unable to function in 6.14

I was actually working up a bug report for this one, once I've narrowed it down exactly.

There was a fundimental change to parsing of IF conditions that have broken many old scripts. You should try using ()'s around your if-checks now, at least whenever possible.

I haven't exactly figured out what still works and what nolonger works just yet. Could you please paste the exact code you're using that breaks it?

[color:990000]if ($me == $nick)[/color] does work however.

- Raccoon

Sadly i all ready use that in ma coding and sadly there is i fear a lot of issues in 6.14. The script was last updated when 6.0 was released, so all coding is current, so as yet im not sure what has been changed in 6.14 but it has broken a lot of things.

maybe i his starting to force us to use the () and lets say that i agree with him.
I realy don't like to see ifs without the ()

problem im having in 6.14 is something in the scripting of the events is no longer working in 6.14 which is causing the rest of the script to fall apart. all my if statements are using the () and always have. ial being a huge thing an a big key in ma script.

interesting point, well if you need help i can help you fix that script, that way we can find from where the problem came...

The guy who wrote this script is mr-rdk an can be found on the undernet IRC network .. i know a lil about this .. but he is the main one who does the scripting im erely trying to find out what fundamental things could be causing various issues.

i never use () and my scripts are fine

Ok, but i believe it is a bad programming attitude and it takes more time to run (i benchmarked it)

I have to agree that using the () are essential.

Can khaled or anyone else tell em what variables have changed in 6.14 that arent documented ? as this si what is causing my problems and unf untill i know what variables have been changed an not mentioned i cant get this fixed.

well whenever i actually NEED to use () i will (c++), but when i don't i find it makes it look a lot neater.

If you could give an actual example of code that you're using which has caused this bug it could help a lot. Knowing which OS you're using might also be useful.

I wish i could .. but there is so much broken and not working i dont even know where to begin. A simple roll back to 6.12 and everything works perfectly .. so there is obviously quite a lot of significant changes to a lot of things that is causing a multitude of stuff ups in the script.

I don't use parentheses, and "if $me == $nick { stuff }" works just fine.
I haven't noticed anything similar not working either.

Well im not sure where to begin. But im sure it'll figure it'self out in time

Hmm, I should dig up the clone script that Julie2 said stopped working.

.. ah, here it is. Poolshark's CloneStopper2.5
She explained the error started on line 112, and after adding ()'s she was given 3 more errors and lines that she added ()'s too.

*lets others look too*

EDIT: Oh yea, it wasn't a status window error she was getting... but an infinite loop that she had to break out of. (Ctrl+Break or Ctrl+ScrlLock)

Well I didn't run the script, but I took a look at it and really there's little wonder it's having problems. Apparently whoever wrote that hates syntax with a vengeance. There are dozens of lines which will cause 'ambiguous format' error messages (ie. if %clone1 !ison $chan || %clone2 !ison $chan goto noclones) - that's not a result of errors, it's a result of bad syntax. Unfortunately the spaghetti codeness of it makes it very difficult to tell if there's a logic bug in it aswell.

At this point I'd like to clarify something (not to you; in general). if condition { commands } is perfectly acceptable by mirc and

1) doesn't generate errors
2) is faster (NOT slower, as many people seem to believe) than if (condition) { commands }

In all the scripts I've written so far, I use this syntax and I've never seen it break. Of course, in multiple conditions, () pairs may be needed to control the order of evaluation (for example if 0 && (1 || 2) ), but that's all they are necessary for.

However, things are different when you omit the { } around the commands part: if condition command can break very easily, depending on the contents of "condition" or "command". I would strongly advise against this syntax, unless one really knows what they're doing.

Well when i say that using () is faster please trust me next time...

alias super {
var %fich = $false
var %ticks = $ticks
var %i = 0

while (%i < 35000) {
if %fich == $true echo teste
inc %i
}
echo 1º time is $calc($ticks - %ticks)

%ticks = $ticks
%i = 0

while (%i < 35000) {
if (%fich == $true) echo teste
inc %i
}
echo 2º time is $calc($ticks - %ticks) 4game over i win!
}

output:
1º time is 1562
2º time is 1516 game over i win!

you can run it the times you want... it is not much faster but it is faster!!
the code looks better, faster and more professional (start training if you want to be a good programmer)

btw using {} also makes the code look better but in this case makes it slower

thanks

p.s don't put %fich = $true

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.