Forums Bug Reports /if + %variables bug

The following will work just fine


The following will not


(Should give 2 Unknown command)

It's understandable that the if may still be trying to compare the two %b's and whatnot, but they're essentially the same code, yet the %b is treated as a command.

If you do not use proper formatting you are bound to get errors like these...

//var %a = 1,%b = 2 | if (%a < %b) { %b = 3 } | echo -a %b

Sometimes proper formatting isn't enough. If one way works, the other should as well.

Straight from the mIRC help file (/help /if):


So, I wouldn't call this a bug.

Of course it's a bug. Either the first one is a bug, or the second one is. Because the literally same command does different things. I know it says that in the help file, but that doesn't mean it shouldn't be fixed.

If you think "echo -a %b" and "%b = 3" is the same command...

Why not just use proper formatting and forget about all these "problems"?
I rather have a few brackets more and have my script work all the time instead of having a 50/50 chance of it working...

Because if you've ever done a challenge to create the smallest code, you'd feel the same way.

Edit: And yes, they are both commands.

Well I still hope Khaled will fix the more important bugs rather than working on a guessing engine for people not willing to use brackets :P

Probably it's a bug that the variable assignment isn't recognised. However your reasoning for why you can't use a workaround is silly. Smallest code competitions are possibly the stupidest things ever. Nowhere in any other form of coding is making something small at the cost of extremely low readability considered to be a good thing. Perhaps with the exception of certain Perl zealots *pauses for jeers*.

Not entirely. Smallest code challenges are quite good in showing off your skills, that's why they're challenges in the first place. And it's a VERY good way to find lots of mIRC bugs and limitations. You'd be surprised how many bugs have been found through these little challenges.

I'll have to agree, at least the way these competitions have been done so far. I really don't see the point in making the code ugly as hell and testing the parser's tolerance just to save a few bytes. Many of the submissions in such competitions don't even work in the next version of mirc because they rely on quirks, undocumented things and behaviours prone to change.

That doesnt' mean that smallest code shouldn't be part of the competition at all. Between two scripts that work equally well (which means they're equally correct, fast and stable), most people would prefer the smaller one. But smallest code being the only objective is pointless. Fastest code competitions would be much more meaningful, for one.

-General reply-

Heh, I think challenges are there to be just a little bit of fun...IRC isn't all abuse, seriousness and politics you know. Sure it tests scripter's abilities, but it's not meant to be some form of the Olympic Games, nor is it meant to be a challenge to find out who can create the best script ever...just a bit of fun for people to do if they are bored. A lot of the time, people who script say they don't know what to work on for their next project - well, whilst their thinking, they can have a go at the challenge, or other activities that various websites provide.

If there is a bug in mIRC and someone takes the time to report it, then leave Khaled to take notice of it and fix it if feasible. If workarounds are suggested, then the person who reported the bug should be thankful to the person or people that provided that workaround and use it, or put up with whatever is causing them inconvenience for the time being.

Regards,

It`s not a bug, it`s a feature:

first i argge with you small code
but you script is buggy
the are two ways to make the code

way 1:
if (%x < 10) goto next

wav 2:
if %x < 10 { goto next }


1:
//var %a = 1,%b = 2 | if (%a < %b) %b = 3 | echo -a %b
2:
//var %a = 1,%b = 2 | if %a < %b { %b = 3 } | echo -a %b

also this is not a bug you jus used the if-then-else wrong

The ( ) brackets enclose comparisons, whereas the { } brackets enclose the commands you want to be performed if a comparison is true. You must make sure that the number of ( ) and { } brackets match to make sure that the correct comparisons are made, and that the correct commands are executed.

There's nothing wrong with the way I used my if-then-else statements. They're all valid.

zack if you are right next time dont use //var %a = 1, %b = 2
just use your way //var %a = 1 %b = 2

.....

Indeed. A fastest code competition in a langauge like mIRC's also has an implicit nod towards small, clean code since typically a critical element to obtaining performance is of course to reduce the number of operations and the amount of parsing without making code ambiguous.

I think taking a relatively simple task and asking people to make the fastest code gives people a far greater chance to utilise some skill and is also far more enjoyable and practical. A good example I think was the thread in the Scripting Forum a while back with the $reverse identifier where throughout the thread we went through about half a dozen different implementations and algorithms, getting faster each time until the final solution worked out many times faster than the code that you'd traditionally see used to reverse text.

Indeed, "fastest" challenges are good in themselves, but also don't work for all instances. And even fastest challenges will make the user go beyond what's the norm and try and make the code as efficient as possible, even breaking what I wanted in my first post. Such as doing while something { } instead of while (something) { } and various other ways.

In the end, challenges are there to be... well... challenging To test what your skills can and can't do. Smallest code challenges do this, and many people like seeing how a rather large problem can fit into a 100 byte code. Because there's a lot of nice tricks you can do with mIRC Scripting, and still, a lot of limitations.

I was simply asking for one bug/limitation that works in once case, work in the other. But it seems a group of people would rather go out of their way to flame what even many of the top scripters do themselves, challenges, especially smallest code ones.

Also, I didn't ask Khaled to put this as his number one priority, I couldn't really care less if it wasn't fixed for 6 versions. I was simply reporting a bug that I found which I thought this board was for

I didn't want this to start into some big debate about the requirement for specific challenges, I was simply stating what was in my first post. This is, after all, the bug reports board, and it is indeed a bug.

This is definitely not beyond the norm, as item #140 of v5.4 versions.txt explains.


It's a forum, discussions are made and threads get a bit off-topic all the time. This is not something you can (or should) control. We know that you simply reported a bug and we also know that if you don't want to be part of the "big debate", you can happily ignore the thread (which you could have done after your first post) Oh, and I'm sure nobody's intention is to flame (although starbucks_mafia's wording was a little bit too "sincere" :tongue:), we're just discussing about related mirc subjects.

The real issue is that I shouldn't have allowed the use of if-statements without () brackets in the first place.

The programming languages I've seen require the use of brackets in if-statements, and the reason is simple: without brackets, it is often difficult for the parser to know which values in an if-statement are part of the comparison. That's why it is important, as the help file states, to use () and {} in if-statements to make it clear what you are trying to do.

I have actually considered making the parser require the use of () (just like perl and C, and {} as well) in newer versions of mIRC but that would break all existing scripts.

I, for one, am glad that you aren't making () required. I've found that if you always use {}, ()'s aren't necessary, unless of course you want to specifically alter the order of evaluation of conditions. I've found (from the countless /if statements I've written till now) that with the usage of {} only, the parser works correctly in 100% of the cases.