mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Dec 2002
Posts: 208
H
Hrung Offline OP
Fjord artisan
OP Offline
Fjord artisan
H
Joined: Dec 2002
Posts: 208
I don't know that this would count as a bug as such, but I can't seem to get /tokenize to give an error message... Even using /tokenize with no parameters at all just skips on to the next command. Examples:

tokenize
tokenize a b c
tokenize 32

None of the above commands give any kind of error. I can see the "tokenize 32" not erroring, in case the user is tokenizing from a $null %var, but the other two should give insufficient/invalid parameters. Can make it kind of difficult to debug if you don't notice something small like that.


If I knew now what I will know then... maybe things will have been different...
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Well it doesn't error because it does perform an action: it makes $1- equal $null. I don't see how it really confuses anyone, I mean what would they expect to be happening with /tokenize without parameters assuming they understood the command's purpose.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Dec 2002
Posts: 208
H
Hrung Offline OP
Fjord artisan
OP Offline
Fjord artisan
H
Joined: Dec 2002
Posts: 208
The point is that it is easy to forget something simple, such as the C parameter to /tokenize, and without any kind of error message telling you that you messed it up, you could end up just sitting there scratching your head and wondering why $1- keeps coming out $null. The C parameter should be required for mirc to continue with that command. I don't know about anyone else, but when I'm debugging code, I find that error messages make it easier to locate errors -- that's kind of what they're there for. But for a command to produce no error when it is obviously being used incorrectly (C is not optional as far as getting it to actually work is concerned) is just plain wrong, hence the bug report.

The person that brought this bug to my attention forgot the C parameter, which is a simple mistake that anyone can make. Also, if a user is passing a %variable or $identifier (maybe a misspelling of $asc(C)?) it might take a while to figure out what went wrong where a simple "* /tokenize: invalid parameters" would tell them right off where they should be looking.

Last edited by Hrung; 01/02/05 08:38 PM.

If I knew now what I will know then... maybe things will have been different...
Joined: Feb 2004
Posts: 2,019
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2004
Posts: 2,019
I second that.


Gone.
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
I see your second and i raise you a third


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
Quote:
Well it doesn't error because it does perform an action: it makes $1- equal $null. I don't see how it really confuses anyone, I mean what would they expect to be happening with /tokenize without parameters assuming they understood the command's purpose.


Yes yes yes, i totally agree and on those grounds I propose that all commands do not error, and the code continues to run (runaway i thinks might be a better word) regardless of what commands have failed, let it be on the coders head to find even the smallest of bugs in 1000's of lines of code i say!

Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Yes, the case of /tokenize <non-numeric> ... should be an error, but /tokenize alone should not because it is a valid command which performs a potentially useful function. Yes, that function could also be performed by /tokenize <any-number> $null, but the fact is that it works both ways so why change it? It's not like someone can easily forget both parameters for /tokenize is it?


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
My point was/is that the command doesn't fail if /tokenize is used without parameters. Missing both parameters for a command isn't 'the smallest of bugs' or even a small bug, it's a glaring oversight.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
That's wrong, any possible oversight is a wrong oversight. A script should not continue processing if errant code is run. Thats the point of the error messages- otherwise there are plenty of commands in mIRC that halt processing when theres no 'serious' error.

Let me illustrate the 'theres no such thing as a glaring error' syndrome:

1. Lost in code...where's waldo?

alias x { var %i, %x, %y, %n = $len($$1) | while (%i < %m) { inc %i | %x = $calc(5 + ($sqrt($$1 + $$3 / $floor($$1 + 2 / (18 + 555 * $$2))) | tokenize | %y = $base($abs($calc(%x + 5 + ($sqrt($$1 + $$3))), 10, 2, $left($$1,-1)) } | return %y }


You can blame the terrible coding style all you want, but the point is mIRC should tell the scripter what went wrong, or he might never find that needle in the haystack

or even...

2. Ignorance to the ways of mIRC
Code:
ON *:TEXT:!help:# { 
  msg $nick HELP INFO | tokenize | parameters: &lt;delim&gt; &lt;text&gt;
  msg $nick Description: tokenizes text based on a delimiter
}

A scripter might not be aware of the | used as a command delimiter. Sure, its his fault, but that should not justify mIRC not telling the scripter how to fix his error.


By the way, don't try to argue these examples- They're just examples. In fact, these examples should be considered simple cases of what can be a much more complex situation (a one line alias thats triple the size, a longer on text event, etc) The point stands.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Oct 2003
Posts: 96
J
Babel fish
Offline
Babel fish
J
Joined: Oct 2003
Posts: 96
You just nullified 3 variables at the beginning of that alias.
Many times I have done the same with /tokenize .. I don't
think it's a bug at all, if so, then the way you just used
/var is a bug as well .. it does the same thing with
no error.

Edit: But then again, if this is changed it woulnd't bother
me at all if I had to start using /tokenize [C] to get the
same effect.

Last edited by JoeDaddy; 02/02/05 03:05 PM.
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
5.91 versions.txt:
Quote:
33./tokenize now correctly resets all $N to $null if no parameters
are specified.

It is intentional and I agree: /tokenize without params is a quick way to empty all $N's. I don't care whether /tokenize <invalid params> should give an error or not but /tokenize alone should not.


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Joined: Oct 2003
Posts: 96
J
Babel fish
Offline
Babel fish
J
Joined: Oct 2003
Posts: 96
heh good one .. I didn't remember that .. I still
don't, but at least that proves it was intentional
and behaves exactly as it should smile

Last edited by JoeDaddy; 02/02/05 03:28 PM.
Joined: Dec 2002
Posts: 208
H
Hrung Offline OP
Fjord artisan
OP Offline
Fjord artisan
H
Joined: Dec 2002
Posts: 208
So it behaves the way it was designed in that respect, but I can't think of a reason why someone would want to reset $1- to $null.. If you want $null, why not just use $null? Is there any possible advantage to it? If anyone has an idea, I really would like to know...


If I knew now what I will know then... maybe things will have been different...
Joined: Nov 2003
Posts: 2,327
T
Hoopy frood
Offline
Hoopy frood
T
Joined: Nov 2003
Posts: 2,327
Some people use that feature in loops, for example:

Code:
alias test {
  tokenize 32 1 2 3
  while ($0) { 
    echo -a $1-
    ;The following line will give an error if this feature is removed from mIRC.
    tokenize 32 $2-
  }
}


New username: hixxy
Joined: Dec 2002
Posts: 208
H
Hrung Offline OP
Fjord artisan
OP Offline
Fjord artisan
H
Joined: Dec 2002
Posts: 208
That is an interesting example, and I can see doing that, but it still uses the C parameter to /tokenize. I'm talking about using /tokenize with no parameters. The only thing it could do is clear out $1-, which seems pretty much useless to me.


If I knew now what I will know then... maybe things will have been different...
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
But, as I keep trying to explain, using /tokenize with no parameters is not errant code, it's a valid use of the command. My point about it not being a small error is that it's not something that you can do without thinking. You might get the parameters mixed up or even forget one, but you can't forget both parameters for the command.

If it's ignorance of the ways of mIRC, well that's hardly within mIRC's capability to second guess everything the scripter does.

eg.
Code:
ON *:TEXT:!help:# { 
  msg $nick HELP INFO | tokenize | parameters: &lt;delim&gt; &lt;text&gt;
  msg $nick Description: tokenizes text based on a delimiter
}

* Error: You may or may not have meant to create an event hook. 'on ...' creates an event hook in mIRC script.
* Error: You may or may not have meant to trigger the command 'msg $nick HELP INFO'. Newlines delimit commands in mIRC script.
* Error: You may or may not have meant to trigger the command 'tokenize'. Pipes delimit commands in mIRC script
* Error: You may or may not have meant to trigger the command 'parameters: <delim> <text>'. Pipes delimit commands in mIRC script
* Error: You may or may not have meant to trigger the command 'msg $nick Description: tokenizes text based on a delimiter'. Newlines delimit commands in mIRC script
* Error: You may or may not have meant to end the 'on TEXT' command block. Braces surround command blocks in mIRC script.


My point is hopefully obvious. At some point an error is going to be undetectable from genuine code. Error messages provide a way of finding, well, errors. They're not there to perform an on-the-fly scripting tutorial or give a running commentary on the state of the script. /tokenize without any parameters is a valid command, and as qwerty showed it is intentional.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Oct 2003
Posts: 96
J
Babel fish
Offline
Babel fish
J
Joined: Oct 2003
Posts: 96
lol .. hey look, it's ms word

Joined: Dec 2003
Posts: 261
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Dec 2003
Posts: 261
I just want to say that every command should return error if it can not execute. Example /unload command... /unload -rs c:\program files\blabla doesn't give any kind of error message... and I just forgot to put " before and after the filename...

Joined: Oct 2003
Posts: 96
J
Babel fish
Offline
Babel fish
J
Joined: Oct 2003
Posts: 96
Quote:
every command should return error if it can not execute

/tokenize by itself does execute and is intended
behavior .. proven by qwerty above from versions.txt.

Edit: I just became a member .. huhuh I said mmmember

Last edited by JoeDaddy; 02/02/05 10:40 PM.
Joined: Dec 2003
Posts: 261
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Dec 2003
Posts: 261
Read my post carefully
Quote:
every command should return error if it can not execute

And I gave an example of command that does not do that...


velicha dusha moja Gospoda

Link Copied to Clipboard