Forums Scripts & Popups case sensitive

Hi,

I was wondering if there is any way to get me a script like this: in a channel someone says Chandler was here today and another one says chandler was here yesterday...

i have this:
[code]
on *:TEXT:*Chandler*was*seen*:#: msg #mychan $strip($1-)
[code]
But then he displays both messages and i want only the one with capital C... Can i make it case sensitive?

You can't in the matchtext itself but you can with an if statement. Example:

Perhaps a good feature suggestion would be a prefix for events that makes the matchtext case sensitive. ISWMCS has already been suggested.

pssst: close your code tag...

You must use the "isincs"

Example :

on *:TEXT:*Chandler*was*seen*:#: {
if $1 isincs Chandler { msg #mychan $strip($1-) }
}

on *:TEXT:*Chandler*was*seen*:#: {
if ( Chandler isincs $1- ) { msg #mychan $strip($1-) }
}

/help /if
Using brackets speeds up processing. If an alias uses too few brackets then the statement might be ambiguous and the alias will take longer to parse, might be parsed incorrectly, or might not be parsed at all.

if (v1 operator v2) { commands }
isincs string v1 is in string v2 (case sensitive)

This is a common misinterpretation of the help file. In reality, tests show otherwise:
if something { command }
proves faster than
if (something) { command }

thnx guys

What tests are you referring to? I have not seen any such tests, nor can I reproduce your results with my own tests.

These tests ... and sorry for stalking

Thats not exactly scientific benchmarks. How do you ensure that the CPU is in the same state each time? Meaning maybe when /if3 is executed there is nothing else going on in the CPU, where as when /if1 is executing, your anti-virus program is in the process of running an automated scan of all your files. Thats why benchmark programs cost several hundreds of not several thousands of dollars, because it isn't as simple as using a timer and counting which takes longer.

How do you ensure that the CPU is in the same state each time? Meaning maybe when /if3 is executed there is nothing else going on in the CPU, where as when /if1 is executing, your anti-virus program is in the process of running
I can't believe you're so narrow-minded. What makes you think I ran the benchmark only once? If you run this benchmark 100 times and all 100 times /if3 is faster than /if1, don't you think it's safe to assume that /if3 is actually faster? Even with 10 random runs of each alias, are you aware of the probability of the CPU doing something heavy during ALL 10 runs of /if1, while being idle during ALL 10 runs of /if3? It's 0.1%.
Let me quote myself from the post linked by Online: Run these aliases and their modified equivalents with a false condition a few times (not just once each) .... I guess you didn't notice that.


Thats why benchmark programs cost several hundreds of not several thousands of dollars, because it isn't as simple as using a timer and counting which takes longer.
Has it ever occured to you that those programs benchmark 'slightly' different things?

Generalizing, rationalizing and assuming things are obviously your favourite habits (you've been doing it forever on these boards), but they get tiring rather quickly.

I have a benchmark program that compares two implementations of the C sprintf() function, that seems pretty similar to what you are doing here. The code for this test is hundreds of times more complex than your benchmarking utility. I also have a utility called testregex which compares different implementations of C regexp functions, the program to do this is several KBs in size. But anyway just to disprove your argument, how many times do you use if (1 == 1) in your scripts? I never have. More likely is if (%var == 1) or if (%var == %var2) or if ($someident(%var,para2,para3) != $null). Those are realworld examples, what you have proven has no relevance, because no one would ever use if (1 == 1) in a script, it always evaluates to true, there is NEVER a reason to use that. For the moment I won't dispute the fact that if (1 == 1) has results similar to what your benchmark shows, but my question is so what? If you use if (1 == 1) in your script then you are correct in saying which method is best, but does that tell me which of these:
if ($mid($1-,%i,1) == $chr(%d) || %i > 5) { haltdef }
if $mid($1-,%i,1) == $chr(%d) || %i > 5 { haltdef }
if $mid($1-,%i,1) == $chr(%d) || %i > 5 haltdef
is faster? It certainly does not, because your benchmark makes no attempt to test complex and realworld examples, it provides a test of if (1 == 1) which will never be used by anyone. Therefore it makes the results of your test irrelevant since they only apply to a fictitious scenario.

It seems that you don't understand anything about how mirc works and how to make a proper benchmark in mirc. The reason I used (1 == 1) and not some more complex statement is so to reduce the 'noise' in that benchmark. Yes, I consider whatever is in the parentheses 'noise' because it doesn't affect the process we want to benchmark: apparently, mirc parses the /if parameters, separating the delimiters (parentheses)* from the actual statement and THEN evaluates the statement, evaluating any identifiers/vars and doing the actual comparison. I won't bother proving that to you, but it can be proven with simple scripting tests.

But you want to use that benchmark with variables/idents anyway? Go ahead, just replace "1 == 2" with "%a" (or "%a == 2"), assuming you have set the local var %a to 1 or something before the loop starts. I've done that and the results were no different in quality: the ()-less version was faster.

I wonder (or rather not) what else you'll come up with.


* When mirc sees an opening parentheses "(" it assumes that a () pair was used, so it strips ( and ) and evaluates the expression inside them, otherwise it treats the entire string as the expression itself.

Well all my benchmarks (even using the exact code you created) show different results. I get the results:
if1: 3725
if2: 3616
if3: 3034

if1 is if (1 == 1) { haltdef }
if2 is if 1 == 1 { haltdef }
if3 is if (1 == 1) haltdef

So from that test it is clear that the () version is faster, so if you are saying your results show that the one without () are faster, it would prove my argument that your tests are flawed. I have done the test about 50 times now, and each time if3 comes out being the fastest.

Earth to codemastr, earth to codemastr. I already said in my post from ms.org (which I wonder if you bothered to read in its entirety) that the order (from slowest to fastest) is this:
if (1 == 1) { haltdef }
if 1 == 1 { haltdef }
if (1 == 1) haltdef

But the question in this thread was between
if (1 == 1) { haltdef }
and
if 1 == 1 { haltdef }
ie, to see whether the ()-less version is faster than the one with (). To answer this question we must first make sure that EVERYTHING ELSE in the script is the same. This includes the { } for the command part: it seems that
if (something) command
is faster than
if something { command }
just because the presence of {}'s slow down the script to a higher degree than the absense of the ()'s speeds it up. But when the {}'s are there in both cases (ie a common factor), the difference between () and non-() becomes apparent. This the essence of benchmarks: when measuring the perfomance of something it is vital that all other things are kept exactly the same.
The equivalent non-{} case of the question at hand would be to compare
if (something) command
with
if something command
but in many cases the 2nd format fails, because there are too few delimeters. Whenever this works though, I'm sure that the ()-less version is faster as well. Conclusion: whenever it is possible to omit the ()'s and assuming that {}'s are either present or absent in both versions, the ()-less version is faster.

Whatever, I chose to ignore your findings, and instead accept the word of the man who wrote the script engine and knows exactly how it functions. Something tells me Khaled knows a bit more about the internals of mIRC than you do.

Oh and I did read your post on mircscripts.org, and if I were commenting on what you said there I would have posted my reply there, but I wasn't I was replying to what you said here which is not the same as what you said there.