It would be nice to have a command that should be followed by another command, and would allow the alias/event calling the command to keep any local variables set by the called alias.
Example (above is most likely unclear :P):
on *:text:*:*: {
keepvars getinfo $nick
if ($1 == %localvar) {
.msg $iif($chan,$chan,$nick) %response
}
}
alias -l getinfo {
if ($hget(info,$1)) {
var %localvar = $gettok($v1,1,32), %response = $gettok($v1,2-,32)
}
}
Just use /set -u (with no timer) instead of /var.
But what if a global variable is already set with the same name?
The most recent set of the variable, based on the name, takes priority.
It is (currently) not possible to have a local variable and a global variable with the same name (and I would suspect different values).
You should give your variables unique names anyway.
Making a script use variables like %title and %name is not a good idea. You should use %yourscriptname.name and %yourscriptname.title
The most recent set of the variable, based on the name, takes priority.
It is (currently) not possible to have a local variable and a global variable with the same name (and I would suspect different values).
it's possible, and you can use $var() to select which var to take the value of. although it sure is a recipe for confusion!
alias vartest {
echo -a Setting % $+ vartest.blah to 123
set %vartest.blah 123
echo -a % $+ vartest.blah: %vartest.blah
echo -a Calling vartest.a
vartest.a
echo -a % $+ vartest.blah: %vartest.blah
unset %vartest.blah
}
alias -l vartest.a {
echo -a (Called alias) Setting local var % $+ vartest.blah to 123456
var %vartest.blah = 123456
echo -a (Called alias) % $+ vartest.blah: %vartest.blah
}
You can have two (or more) variables with the same name, unlimited local and one global.
I stand corrected. Personally I prefer to use variables that are distinctive or very temporary (eg: using %a and %b as counters in a while loop).
so my question then is say on a join event I have it run through a while loop and use var %a and %b.
If someone joins while this while loop is going, will this overwrite the variables %a and %b?
I mean, I haven't had any issues, but by what is said here they would, wouldnt they?
No, they'd still have the expected values.
For one thing mIRC's scripting language is single-threaded so only one alias/event/whatever is processed at any given time, meaning if someone joins while your code is looping the join event code won't be triggered until after the loop has finished and the code block it's in has ended.
Even if mIRC scripting were multi-threaded it wouldn't make any difference (in theory) as long as they were local variables in which case they're effectively different variables for each scope in which they're used.
So it makes a queue and the 2nd join event waits for the first to finish before executing? nice to know.
Basically, though it's fast enough that you shouldn't ever notice.
I guess i personally dont see the need, whats wrong with doing something like this...
on *:text:*:*: {
var %info = $getinfo($nick)
if (!%info) return
if ($1 == $gettok(%info,1,32)) {
.msg $iif($chan,$chan,$nick) $gettok(%info,2-,32)
}
}
alias -l getinfo {
if ($hget(info,$1)) { return $v1 }
}
Good Point. I understand you were using a simple example but me in my nit pickiness would have to say.
var %info = $iif($hget(info,$nick),$ifmatch,$false)
Indeed i wasn't claiming that was the best or even easiest, just a quick edit to demonstrate my point. Personally cant think of a situation at this time where this suggestion would offer a significant improvement, then again everybody is always asking for a for or foreach function.
That was just a simple example, but what if there were multiple results?
on *:text:*:#: {
....
calling somealias...
....
}
alias -l somealias {
...lost of complex stuff here...
var %var1 = ..., %var2 = blah blah, %var3 = somthing else, %var4 = ..., %varX = ...
...
}
Then the only way to solve it would be hash tables, but it would be slower to make a hash table, and populate it with the data.
It would be nice to be able to return an array.
However set -u0 does this, but it's somewhat messy. Also, all the lenghts of the variables differ, and the number of spaces/etc they contain is also different. /tokenize wouldn't work, nor would $gettok.
Unless escaping all the spaces, pipes or whatever, or using hash tables, or global variables (which would make it really messy, and hard to read), this wouldn't be possible. Also, not all the variables would be taken from a hash table. Some of them might have been calculated or altered in some way.
You can still use gettok, you just have to place a special token between each for the return... (chr9 is a tab, but you can use any chr you like)
return $+(%var1,$chr(9),%var2,$chr(9),%varN)
var %result = $somealias()
$gettok(%result,X,9)
OR if you dont need the original $1- anymore you can use tokenize
return $+(%var1,$chr(9),%var2,$chr(9),%varN)
tokenize 9 $somealias()
I am curious why the length of the variable matters for using $gettok. You can easily find the length with $numtok or $gettok.
Anyhow, arrays being added don't bother me, but I still don't really see very much use for them. No example that has ever been given in he many threads about arrays has ever been that much better (imo) than existing methods.
With arrays, you can pass data from a alias to alias, without needing to use $gettok, hash tables, etc. Its alot simpler than using hash tables, and alot easier aswell.
Also, $gettok conflicts if there is a character in the data thats used as a deltimer.
Even if arrays are added I doubt they'll be any easier to pass between aliases than hash tables, ie. you'll still need to pass the name of the array and then the called alias will need to know that it's an array name and use $array($1,
<index>) or whatever. I don't see any reasonable way around that. The only benefit of arrays would be the possible efficiency gained in certain operations (eg. iterating over them). For your purposes right now you could still use a hash table or global variables, all you'd need to do is some name-checking to make sure the temporary variables/hashtable don't already exist, then return the temporary name(s).
on *:text:*:*: {
var %vars = $getinfo($nick)
var %local = $tempget($gettok(%vars,1,32)), %response = $tempget($gettok(%vars,2,32))
if ($1 == %local) {
.msg $iif($chan,$chan,$nick) %response
}
}
alias -l getinfo {
var %varname1 = $tempvar(get1), %varname2 = $tempvar(get2)
if ($hget(info,$1)) {
tempset %varname1 $gettok($v1,1,32)
tempset %varname2 $gettok($v1,2-,32)
}
return %varname1 %varname2
}
alias tempvar {
var %tmp = $+(%,temp.,$md5($rand(1,10000) $ticks $1))
while ($var( [ %tmp ] ,1)) %tmp = $+(%,temp.,$md5($rand(1,10000) $ticks $1))
return %tmp
}
alias tempset set -u0 $1-
alias tempget return $eval($iif($left($1,1) == %,$1,$+(%,$1)),2)Not exactly pretty but it works and it definitely won't affect other global variables.
It just uses three extra aliases, $tempvar to create a new alias name, /tempset to set the temp variable's value from it's local variable name, and $tempget to get the variable's value.
As you can probably see /tempset and $tempget are just vanity functions to clean-up the code a tiny bit.
Hash tables are very easy to use and work with once you learn them. They are quick to set up and very easy to access. I don't see how an array is really any easier. If you find hash tables difficult, then you may want to work with them a bit and learn how they are used. Then, you'll see that they are really very easy to use.
As for $gettok conflicting based on the deliminator, if you the data being used may contain certain characters, then you just use a weird character as the deliminator, such as Þ as that's rarely used in anything else. If you know for sure that it will never have a comma, then you can just stick to that. But when you're unsure, then you just set the script up to use a weird character that is unlikely to ever be used. Or, when you add text to your list that you'll use $gettok on, you can $replace the deliminator with something weird and then $replace it back later.
For example, when I need to deal with spaces, I may do something like:
alias test {
var %test = $replace($$?="Enter data",$chr(32),_)
var %test = %test $replace($$?="Enter more data",$chr(32),_)
echo -a $replace($gettok(%test,1,32),_,$chr(32))
}
That's a weird example, but it shows how you can store your data using $replace and output it using $replace if that's necessary. Still, just changing the deliminator helps.
If you can be certain a character won't appear then tokens might make sense, if not then they definitely shouldn't be used. A bug with a one in a thousand chance of happening is still a bug. There's no reason to rely on chance when there are ways that guarantee success every time.
I like having scripts that are bug-free, and don't use weird characters that have the potential for someone to abuse it.
I use hash tables, however it would be somewhat irritating to keep making a new hash table for each use.
Name the variable the nick so it wont be duplicated.
/test info1 info2 info3
alias test {
$1 = info1
$2 = info2
$3 = info3
}
Yes this is nice to do with aliases. I use this a lot, but what if $1 or $3 is data seperated by spaces? Gettok would be the best for this.
/test info1,info2,info3
alias test {
info1 = $gettok($1,1,44)
etc.
}
I sometimes create temporary hash tables named after the nickname to store a few lines of data. Then when all is finished I hfree the table.
It all depends on what you're doing. For example, if the input was a path/filename, you can just use the : as a deliminator because it cannot be used in a filename/path. It is usually easy to look at your project and determine what is going to be used and what is not going to be used. The chance that a person would use the deliminator can be easily remedied using a check if you really feel like it could be an issue.
I don't know what you mean about making a table for each use. Each use of what? Unless you free it (or close mIRC), you can use it over and over. If you're using an array, you also can use it over and over. In both cases, you have to make the table/array. In both cases, you can use it as long as it's still made. I can't see any difference in how one is more "irritating" to use. If you have a *real* example rather than just something made up that shows how one is significantly better than the other, I'd like to see it. As I've said, I have not seen any examples of what someone might actually use (not these things that say "blah blah" or whatever) that show any significant differences.