mIRC Home    About    Download    Register    News    Help

Print Thread
$chr(32) - fix this old bug please #191540 11/12/07 06:56 AM
Joined: Dec 2007
Posts: 5
N
nimper2000 Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
N
Joined: Dec 2007
Posts: 5
Let's take this script here:

Code:
alias bugz {
  var %a = 1
  while ($mid($1-,%a,1)) {
    echo -a $v1
  }
}

The input:
/bugz why does mirc have bugs?

The output:
w
h
y
* /echo: insufficient parameters


This script will halt whenever it reaches a space, also known as $chr(32), because there is a very old bug where mirc thinks that $chr(32) is a null character.

However:

Code:
alias bugz {
  var %a = 1,%b
  while ($mid($1-,%a,1)) {
    %b = $v1
    if (!%b) { echo -a This should show up for every space the script encounters }
  }
}


will not echo anything, because %b is filled with $chr(32).

There needs to be consistency. This is a long-standing issue, and it forces scripters to make tedious workarounds that should not be necessary.


Re: $chr(32) - fix this old bug please [Re: nimper2000] #191543 11/12/07 07:24 AM
Joined: Dec 2002
Posts: 3,138
C
Collective Offline
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 3,138
This is not a bug and is consistent with the way all commands are parsed in mIRC.

See the mIRC Internals Wiki.

Re: $chr(32) - fix this old bug please [Re: Collective] #191544 11/12/07 07:42 AM
Joined: Dec 2007
Posts: 5
N
nimper2000 Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
N
Joined: Dec 2007
Posts: 5
Don't tell me it isn't a bug. If a space can fill a variable but it can't be displayed from that variable, that's a bug.

Re: $chr(32) - fix this old bug please [Re: nimper2000] #191545 11/12/07 07:45 AM
Joined: Dec 2002
Posts: 3,138
C
Collective Offline
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 3,138
It doesn't work for the same reason typing /echo -a[color:red]<space><space>[/color] doesn't work. That isn't a bug and neither is this. It is intended behaviour, even if it's not desirable to you.

This is an effect of how mIRC parses commands, and it's that simple parsing that makes mIRC a very easy language to learn. Various feature suggestions (hint: that's the right forum) have been made, including a command prefix that would preserve spaces in some way. I suggest you search and add your support to one.

Re: $chr(32) - fix this old bug please [Re: nimper2000] #191547 11/12/07 08:52 AM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Quote:

Don't tell me it isn't a bug.

It's not a bug. There, I told you.

mIRC uses space as a delimiter for commands, so multiple spaces will always be ignored when evaluating a line of code unless you pass it to mIRC indirectly. It's not that mIRC can't "display" spaces from a variable, it's that mIRC will parse the spaces from the variable and then handle them the way it handles all spaces parsed in a line of code. Those spaces actually *are* passed through the scripting pipeline, but only up to the point where your echo command is evaluated, at which point they are destroyed just like Collective described.

Example:

- The line /echo -a %myvar would turn into "/echo -a MY <space><space> VALUE" after variable interpolation.

- Once executed and tokenized, the arguments would be passed into the "echo" command with $1 = "-a", $2 = "MY", $3 = "VALUE".. meaning $1- = "-a MY VALUE". This is why your spaces seem to disappear, because after interpolation they are no longer "data", they are delimiters in mIRC's syntax.

- This goes for all /commands where tokenization happens for $chr(32). Note that this is why you can preserve spaces (better) using $identifiers, because the tokenize character there is $chr(44).

- This is why $len($str($chr(32),5)) == 5, because it doesn't pass through any /commands which use space tokenization. This proves that mIRC does not destroy your spaces, but uses them as token delimiters in the parsing stage. This proves that this is an inherent syntax rule and cannot be a bug.

Dislike this functionality all you want, but at least have the maturity (and intelligence) to understand that this is a basis of mIRC's syntax and parser and an inherent part of the language, good, bad, or neither.



- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: $chr(32) - fix this old bug please [Re: argv0] #191566 11/12/07 08:55 PM
Joined: Dec 2007
Posts: 5
N
nimper2000 Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
N
Joined: Dec 2007
Posts: 5
So it's not a bug, it's a "feature". Got it.

Re: $chr(32) - fix this old bug please [Re: nimper2000] #191567 11/12/07 09:06 PM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
If it makes you feel better, Tcl works the same way-- the only difference is that Tcl has other mechanisms to preserve spaces (and other data that may be parsed as syntax rather than data) that mIRC does not. Fault mIRC for an incomplete solution, but not for the current implementation being buggy.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: $chr(32) - fix this old bug please [Re: argv0] #191571 11/12/07 10:10 PM
Joined: Dec 2007
Posts: 5
N
nimper2000 Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
N
Joined: Dec 2007
Posts: 5
Well, I did figure out a way around the problem, and that is to use /tokenize.


Re: $chr(32) - fix this old bug please [Re: nimper2000] #191575 11/12/07 11:09 PM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Well in your specific example you can solve the problem by simply writing a *proper* if conditional:

Code:
while ($mid($1-,%i,1) != $null) { 
...
inc %i
}


because an empty string, $null, $false and 0 are all equivalent in an if condition (when evaluated alone), meaning spaces isn't the only character your original code would fail on-- "0" would be another.. and that is really not a bug.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: $chr(32) - fix this old bug please [Re: argv0] #191577 12/12/07 03:27 AM
Joined: Dec 2002
Posts: 503
B
Bekar Offline
Fjord artisan
Offline
Fjord artisan
B
Joined: Dec 2002
Posts: 503
The problem isn't with the 'while', it's with the 'echo'.

mIRC when it encounters an error, stops..

So when it encounters the echo of a 'space', mIRC fails out.

So, using this would stop the errors:

Code:
var %i = 1
while ($mid($1-, %i, 1)) {
  if ($v1 != $chr(32)) {
    echo -a $v1
  }
  inc %i
}

OR

Code:
var %i = 1
while ($mid($1-, %i, 1)) {
  echo -a Val: $v1
  inc %i
}

Re: $chr(32) - fix this old bug please [Re: Bekar] #191616 12/12/07 09:57 PM
Joined: Dec 2007
Posts: 4
S
snadrik Offline
Self-satisified door
Offline
Self-satisified door
S
Joined: Dec 2007
Posts: 4
if its for your own personal script, you could alway replace $chr(32) with $chr(3) $+ 0,0 or something?

Re: $chr(32) - fix this old bug please [Re: Bekar] #191625 12/12/07 11:07 PM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
@Bekar:
That while will still fail if $mid($1-, %i, 1) == 0

The proper way is to explicitly test != $null, or check that %i <= $len($1-).. Then you can make sure you're not echoing nothing


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: $chr(32) - fix this old bug please [Re: argv0] #191632 13/12/07 12:29 AM
Joined: Dec 2002
Posts: 503
B
Bekar Offline
Fjord artisan
Offline
Fjord artisan
B
Joined: Dec 2002
Posts: 503
Yeah, true :P

Re: $chr(32) - fix this old bug please [Re: nimper2000] #191795 15/12/07 11:21 PM
Joined: Mar 2006
Posts: 22
R
rehinged Offline
Ameglian cow
Offline
Ameglian cow
R
Joined: Mar 2006
Posts: 22
Originally Posted By: nimper2000
Let's take this script here:

Code:
alias bugz {
  var %a = 1
  while ($mid($1-,%a,1)) {
    echo -a $v1
  }
}

The input:
/bugz why does mirc have bugs?

The output:
w
h
y
* /echo: insufficient parameters



No one noticed the missing "inc"? ^_^;

And in any case, here's the even easier solution.

Code:

alias bugz {
  var %a = 1
  while ($mid($1-,%a,1) != $null) {
    e $v1
    inc %a
  }
}

alias e {
  !echo -a $+(,$1-)
}

The input:
/bugz why does mirc have bugs?

The output:
w
h
y

d
o
e
s

m
i
r
c

h
a
v
e

0

b
u
g
s
?


$mid is sampling directly from the byte-string you have passed it, which is not influenced by tokenization as has been erroneously stated (or perhaps implied) above. So, $chr(32) has not been "stripped", there. Zero would still negate the original loop condition, though.

$chr(32) is being stripped, instead, at internal tokenization of the echo command. So, I have prefixed the string with $chr(15) in alias e. That's directly written as CTRL+O in most any mIRC text field (editor, editboxes, etc.). It's a non-printed character which acts to delimit and force display of consecutive whitespace, here.

Re: $chr(32) - fix this old bug please [Re: rehinged] #191810 16/12/07 06:47 AM
Joined: Mar 2006
Posts: 22
R
rehinged Offline
Ameglian cow
Offline
Ameglian cow
R
Joined: Mar 2006
Posts: 22
^-: Above, in the code example, the input was, of course:
Code:
The input:
/bugz why does mirc have 0 bugs?


Which was a joke, by the way. ^_^;

Originally Posted By: "rehinged"

...which acts to delimit and force display of consecutive whitespace, here.


I should replace that with: "...which, here, allows the parsed echo command to have invisible content, making blank lines printable." Because, clearly, there's a non-tokenized character there, and it's one which, by it's nature, has no print value. It's better than $chr(160), which actually does get filled with visible characters in some fonts.

I have also used it before to preserve consecutive whitespace in echo lines, though it is more difficult to catch before mIRC tokenizes the string somewhere in its travels.

When you find the spot to use it, it usually goes something like:

Code:
$replace($1-, , ,,)


So, there you're replacing [space] with [^o][space][^o], and ending up with [^o][space][^o][^o][space][^o][^o][space][^o], which the end obviously turns into [^o][space][^o][space][^o][space][^o].

Last edited by rehinged; 16/12/07 06:52 AM.