mIRC Homepage
Posted By: darkarrow cap on characters - 04/02/11 09:03 PM
There is cap on how much you can use with /set and /tokenize or at least those are the ones im having trouble with that won't work so I am asking that the length limit be lifted so that the script that I have will work. Thanks
Posted By: RusselB Re: cap on characters - 04/02/11 11:57 PM
One option if the variable length limit, which is what I think you are actually referring to, can be overridden by using binary rather than normal variables. See /help Binary Files

Additionally, you might ask for suggestions in the Scripts & Pop-ups section regarding other methods that could make your script work with the current limitations and without using binary variables.
Posted By: darkarrow Re: cap on characters - 05/02/11 02:41 AM
I have tried learning binary variables and have had no luck so far but maybe I will try and see if others have alternatives to the binary variables. Thanks
Posted By: hixxy Re: cap on characters - 05/02/11 10:31 AM
If you're struggling to learn binvars, these Binary Variable Identifiers by Jaytea might help. Read the comments at the top because they work slightly differently to mIRC's own string identifiers.
Posted By: Riamus2 Re: cap on characters - 06/02/11 08:36 PM
Binary variables are different from normal variables, but they are not too difficult to use once you learn how they work. Unless you want to read in only part of the text into a variable and loop around that way (not a good idea, usually), then binary variables are the way to go.

Also, keep in mind that newer versions of mIRC have a much higher variable length available than older versions. So if you're using something like 6.2, then you should consider upgrading. Currently, you have around 4000 characters to work with in normal variables, which is usually plenty.
Posted By: FroggieDaFrog Re: cap on characters - 07/02/11 04:04 AM
Posted By: RusselB Re: cap on characters - 07/02/11 05:35 AM
I believe, but am not positive, that the variable length (4141 by your post) includes the number of characters in the variable name, thus a longer variable name wouldn't be able to hold the same number of characters as a short variable name.

If that is correct, then about 4000 is a more realistic number to use than 4141.

I've somewhat confirmed this.
//set %a $str(a,4144) works
//set %a $str(a,4145) returns * /set: line too long
//set %RusselKennethBairstow $str(a,4124) works
//set %RusselKennethBairstow $str(a,4125) returns * /set: line too long

Obviously, to me at least, the longer variable name has a direct affect on the number of characters that can be stored.
Looking at my examples, it seems that the maximum length could be calculated as 4145 - variable name length
Posted By: jaytea Re: cap on characters - 07/02/11 06:39 AM
whenever someone asks me "what is the maximum variable length?" i always tell them they're asking the wrong question :P the length of a variable's value is ultimately constrained by a few other fundamental limits:

  • the length limit of a single command. this is imposed before and after evaluation of code, and you'll see this as "* /command: line too long". this is thrown when the command exceeds 4,151 characters.
  • the length limit of an identifier's return value. if an identifier tries to return more than 4,150 characters, you'll typically see "* Line too long: $ident"
  • a little more subtle but also relevant: the length limit of a argument to an identifier. you can pass a LOT of data to your custom identifiers if you so wish, //noop $myalias($str(a, 4096), $str(b, 4096), $str(c, 4096), $str(d, 4096)) is 32kb for example (each character occupying 2 bytes in UTF-16).

    it's unlikely that you've come across a piece of code that breaches this limit since the majority of length limit errors come from attempting to exceed the other 2, but you can see it with //noop $len( [ $str(a, 4150) b ] ) which produces "* Evaluation error: $len".

    normally, the arguments to identifiers are evaluated without error but truncated at the token (identifier, variable or word) that causes the value to exceed 4,151 characters. this is why //echo -a $len($str(a, 4000) $str(b, 4000)) produces '4000' rather than yielding an error.

putting these facts together, we can now attempt to create a variable of maximum permissible length by using $regsub() to implicitly assign to it:

//var %max | noop $regsub( , , $str(a, 4149) b, %max) | echo -a $len(%max) - $asc($mid(%max, -1))

due to some extra internal details that we can only speculate about, the length of %a turns out to be 4,150 instead of 4,151 (the 'b' gets truncated). anyway, this appears to be the maximum.
Posted By: Tomao Re: cap on characters - 07/02/11 07:40 AM
The length is a close estimate but not necessarily precise, isn't it?
Posted By: jaytea Re: cap on characters - 07/02/11 08:57 AM
Originally Posted By: Tomao
The length is a close estimate but not necessarily precise, isn't it?

which one, that 4,150 at the end there? i tried to be as precise as possible, 4,150 characters is the exact upper bound on the length of any variable's value.
Posted By: Riamus2 Re: cap on characters - 07/02/11 11:11 AM
I'm not sure that anyone was asking for a specific max size. That's why I just left it at around 4000 as that is enough to give a person a general idea of the size you have to work with. laugh
Posted By: Corey_ Re: cap on characters - 03/03/11 02:23 PM
For what it's worth, I'd also really like to see this limit raised or eliminated altogether. I'm going to try to figure out how to replace the tokenize command with binary variables, but I can't see why the limit is there in the first place.
Posted By: Riamus2 Re: cap on characters - 03/03/11 02:41 PM
I don't know the reason for the current limit on variable size instead of something larger, but it's not unusual to have some kind of limit. For example, until the newest version of Excel, there was a 255 character limit for cells if you wanted to use the cells in a calculation or other type of formula. Now, that limit has been greatly increased, but there is still a limit. The limit may have to do with the amount of memory variables use, but I'm not sure about that.

In any case, ~4000 characters is plenty for almost everything you'd need in mIRC. The only real exception is when dealing with very poorly formatted websites. And that's where binary variables are useful. Binary variables work very well and can be used when the ~4000 limit isn't enough. Or, just use a better website. I know that I will generally avoid a website that is formatted really badly (in code or on the visible site itself). If they can't code it well, then I don't trust the data or information to be much better than the coding.

Perhaps that limit can be raised again, but I really am not sure that it's necessary. You can do anything you need to do with binary variables, so there isn't a real lack of functionality; You just need to use different commands.
Posted By: Corey_ Re: cap on characters - 03/03/11 02:47 PM
I'm dealing with huge directory listings, and being able to tokenize them would save me a lot of work with binary variables. I get that having some sort of upper bound is necessary, but 4000 characters isn't a lot when each subdirectory name can be 50+ characters long.

I'm not trying to twist anybody's arm, I just think it would be a quick change to mIRC that would really benefit at least one person.
Posted By: Riamus2 Re: cap on characters - 03/03/11 02:53 PM
Tokenize directories???? There are far more efficient ways to deal with directories no matter what you are trying to accomplish with them. If you would like an example, feel free to explain what you're trying to do.
Posted By: Corey_ Re: cap on characters - 03/03/11 02:56 PM
Basically just grab a directory listing every 10 seconds to figure out if any new folders have been created since the last check.

This is what I've written:
alias dirmon {
  ;set up variables, create a list of folders
  var %dirB, %i = 1
  noop $finddir(C:\Temp\,*,0,1,set %dirB $addtok(%dirB,$1-,127))

  ;loop through all the tokens in dirB, see if they exist in dirA
  while (%i <= $numtok(%dirB,127)) {
    if ( $findtok(%dirA,$gettok(%dirB,%i,127),0,127) == 0 ) {
      echo new folder found: $gettok(%dirB,%i,127)
    inc %i

  ;write dirB overtop of dirA for the next run
  set %dirA %dirB
Posted By: Riamus2 Re: cap on characters - 03/03/11 03:13 PM
First, you'd save a lot of time by checking total directories (unless you're removing them as well as adding them).

if ($finddir(c:\temp\,*,0,1) != %LastTotalDirs) { ; do whatever only if true }

You can, of course, remove the 1 if you want to also check total subdirs.

EDIT: Nevermind that. I just noticed that it would then be using $finddir twice, which doesn't really help.

Second, for what you are doing, a hash table is probably the most efficient option.

alias dirmon {
  noop $finddir(C:\Temp\,*,0,1,CheckDir $1-)
alias CheckDir {
  if (!$hget(Directories)) { hmake Directories 50 }
  var %dir = $replace($1-,$chr(32),_)
  if (!$hget(Directories,%dir).item) {
    hadd Directories %dir
    echo new folder found: $1-

* If you are also removing directories, then you'll want to set up a removal from the hash table as well as just adding them the way I did here.
Posted By: Corey_ Re: cap on characters - 03/03/11 03:19 PM
Interesting... I'll go read up on how hash tables work. Thanks, Riamus2! (Directories do get removed from the folder, I just didn't write any code to look for that as I don't need to run anything when it happens.)
Posted By: Riamus2 Re: cap on characters - 03/03/11 03:22 PM
That's good. The removal check would be more work to set up. smile

I haven't tested what I posted as I'm at work, but it should work. Hash tables are very useful for any large amount of data that is accessed frequently. They are also very easy to work with for most things that you might want to use them for and are very fast.

If you didn't see my edit above, take a look at that before getting too far into what I said. I realized something after posting the original post. smile
© mIRC Discussion Forums