|
Joined: Dec 2002
Posts: 254
Fjord artisan
|
OP
Fjord artisan
Joined: Dec 2002
Posts: 254 |
Lets say we want to return the actual number of the token found with $matchtok or $wildtok. In order to do so, currently you have to use $findtok along with your $matchtok/wildtok like this example here:
$findtok(a b c d,$matchtok(a b c d,c,1,32),32)
To me, this looks ugly and seems like a wasteful step just to retrieve a number. I think if $matchtok and $wildtok both had a prefix like .num to return the token number of the string the match is found in would make for much cleaner looking code, and mIRC wouldn't have to iterate through the same string twice. (string being in this example "a b c d").
|
|
|
|
Joined: Jul 2008
Posts: 236
Fjord artisan
|
Fjord artisan
Joined: Jul 2008
Posts: 236 |
$findtok(text,token,N,C) If you specify zero for N, it returns the total number of matching tokens. $matchtok(tokens,string,N,C) If you specify zero for N, it returns the total number of matching tokens. $wildtok(tokens,wildstring,N,C) If you specify zero for N, it returns the total number of matching tokens. Intelligence test: please learn to read/research the /help file more accurately.
Last edited by s00p; 11/01/10 11:06 AM.
|
|
|
|
Joined: Nov 2006
Posts: 1,559
Hoopy frood
|
Hoopy frood
Joined: Nov 2006
Posts: 1,559 |
Etiquette advice: read suggestions carefully before ranting. The OP isn't asking for the total number of matches. He rather wants to get the "actual token number" aka positition of the first match (without nesting in a findtok). Another example: //var %t = abc def bcd cde | echo -a First token containing "cd": $findtok(%t,$matchtok(%t,cd,1,32),32)
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Ironic, but please learn to read/research the OP's post and problem statement more accurately.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Jul 2008
Posts: 236
Fjord artisan
|
Fjord artisan
Joined: Jul 2008
Posts: 236 |
Heh, I apologise. What I read, and what is actually there sound very similar but mean completely different things (eg. just add an 's' and you get what I was responding to). Having failed at my first attempt to understand the problem, what is it you're trying to solve? Though I can think of uses for such a modification, I can't actually think of any instance where I would prefer them over other solutions because in one case (where you're just looking for a token) I'd already have the token from $findtok or $matchtok, and in the other case (where I may be dynamically storing user IDs in a %var and recalling information using $read and a corresponding line number) variables would potentially limit my solution. Having said that, even having this solution likely wouldn't stop mIRC from scanning through the string, looking for a token #x if/when you later call $gettok. It's a moot attempt at optimisation that regular expressions already provide, among other things.
alias regex_example {
var %tokstr = a b c d
var %regex = /([^ ]+)(?:[ ]+)?/g
var %toknum = $regsubex(%tokstr,%regex,$iif(\t == c,\n))
}
Last edited by s00p; 11/01/10 03:09 PM.
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
I see the point of the OP and agree it would look better to have a way to do it without nesting. However, there are many situations where we have to do the same kind of thing with other commands (such as $gettok). I really don't see changing all of those to make them work without nesting. It just doesn't seem worth it to me and I don't think it would be any more efficient... it would just be a cosmetic thing.
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Jan 2003
Posts: 2,523
Hoopy frood
|
Hoopy frood
Joined: Jan 2003
Posts: 2,523 |
Agreed, I've wished for such a feature many times. It's not critical but would be very convenient for me.
/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
|
|
|
|
Joined: Nov 2006
Posts: 1,559
Hoopy frood
|
Hoopy frood
Joined: Nov 2006
Posts: 1,559 |
To me, the OPs suggestion has a point. So far, there are many MSL identifiers, switches and properties that serve convenience only - I can think of several situations where this one could be of use. Though, like Riamus2, I don't think it's a "high priority" thingie. Given that the case may already be solved with $findtok($match/wildtok()) and the OP is looking for a cleaner/shorter implementation only (which might well increase performance), a regsubex looks ludicrous in terms of readability, script size and performance.
Why do you assume he wants to $gettok thereafter? He is using $findtok for the very end of finding not the token itslf, but its position in the string. Maybe he needs the value itself, or wants to $instok after the match, or $reptok/$remtok a $wildtok match, or what have you...
|
|
|
|
Joined: Dec 2002
Posts: 254
Fjord artisan
|
OP
Fjord artisan
Joined: Dec 2002
Posts: 254 |
ok heres my situation, taken from the IRC RFC:
3.3 CHANMODES
o CHANMODES=A,B,C,D
The CHANMODES token specifies the modes that may be set on a channel.
These modes are split into four categories, as follows:
o Type A: Modes that add or remove an address to or from a list.
These modes always take a parameter when sent by the server to a
client; when sent by a client, they may be specified without a
parameter, which requests the server to display the current
contents of the corresponding list on the channel to the client.
o Type B: Modes that change a setting on the channel. These modes
always take a parameter.
o Type C: Modes that change a setting on the channel. These modes
take a parameter only when set; the parameter is absent when the
mode is removed both in the client's and server's MODE command.
o Type D: Modes that change a setting on the channel. These modes
never take a parameter.
so from this data, we can conclude if the mode is in list 1-2 it always requires a parameter, if its in list 3 it only requires a parameter if setting, not unsetting, and list 4 never needs parameters. So by finding which token number the mode contains we can parse the rawmode with something like this:
parsemodes {
var %x = 1 , %y = 1 , %sign
while ($mid($1,%x,1)) {
var %v1 = $v1 , %pos = $findtok($chanmodes,$matchtokcs($chanmodes,%v1,1,44),44)
if (!%pos) { %sign = %v1 }
else {
if (%pos isnum 1-2) || ((%pos = 3) && (%sign = +)) {
inc %y
echo -a $+(%sign,%v1) $eval($+($,%y),2)
}
else { echo -a $+(%sign,%v1) }
}
inc %x
}
}
so on Webchat, $chanmodes = bouv,k,lOMN,cdejimnpqrstzAJLRU if we got a rawmode like this: +d-e+j-i+boul-kc *!*@* nick1 nick2 3 key we can get a finalized result like this: +d -e +j -i +b *!*@* +o nick1 +u nick2 +l 3 -k key -c
|
|
|
|
Joined: Jul 2008
Posts: 236
Fjord artisan
|
Fjord artisan
Joined: Jul 2008
Posts: 236 |
... a regsubex looks ludicrous in terms of ...performance Actually, I don't see how $regsubex would be much less performant than the solution suggested. What's wrong with regular expressions? I believe what he currently has there "looks ludicruous in terms of readability, script size and performance". ... which might well increase performance.. versus what? something like this, which probably "looks ludicruous in terms of ...performance"?
on 1:START: {
var %x = 1
while ($gettok($chanmodes,%x,44) != $null) {
var %y = 1
while ($mid($v1,%y,1) != $null) {
hadd -m $server $v1 %x
inc %y
}
inc %x
}
}
alias parsemodes {
var %x = 1, %sign
bset -t &chanmodes 1 $1
tokenize 32 $2-
while ($bvar(&chanmodes,%x).text != $null) {
var %c = $v1, %num = $hget($server,$v1)
if (!%num) { %sign = %c }
else {
if (%num isnum 1-2 || (%num == 3 && %sign = +)) {
echo -a $+(%sign,%c) $1
tokenize 32 $2-
}
else { echo -a $+(%sign,%c) }
}
inc %x
}
bunset &chanmodes
}
He is using $findtok for the very end of finding not the token itslf, but its position in the string. I don't quite think $poscs would work for his case. There's nothing wrong with his suggestion. I just would hate to see it jeopardise (even slightly) the performance of $matchtok/$findtok/whatever in scenarios where one could not use something similar to the above example. But then again, can't expect newb scripters to want to expand their horizons past elementary algorithms using language constructs and into algorithms using objects.
Last edited by s00p; 15/01/10 08:13 AM.
|
|
|
|
Joined: Nov 2006
Posts: 1,559
Hoopy frood
|
Hoopy frood
Joined: Nov 2006
Posts: 1,559 |
Actually, I don't see how $regsubex would be much less performant than the solution suggested. What's wrong with regular expressions? Nothing's wrong with regexes. Besides that they're often not used in situations where they could perform better, and that they're used in as many situations where they don't. Your example belongs to the latter category - it will slow things down noticeably. I'm not talking about some percent, but, in this example, aprox. the factor 7: alias regex_example {
var %t = a b c d, %r = /([^ ]+)(?:[ ]+)?/g, %n = 1, %s = $ticks
while (%n <= 20000) {
noop $regsubex(%t,%r,$iif(\t == c,\n))
inc %n
}
echo -ag $calc($ticks - %s)
}
alias findtok_example {
var %t = a b c d, %n = 1, %s = $ticks
while (%n <= 20000) {
noop $findtok(%t,$matchtok(%t,c,1,32),32)
inc %n
}
echo -ag $calc($ticks - %s)
} $findtok($matchtok()) is the superior method for this case, and the OP suggested a further improvement only. That aside, do you expect average scripters to create a new expression for every new separating char (and so forth)? I don't see any use for expressions here - besides drawing the attention off the initial suggestion. What's all this defitism about? I believe what he currently has there "looks ludicruous in terms of readability, script size and performance" I try to discuss the suggestion in general, not the particular environment it descended from. Even if the given example code may be improved (like virtually every script, including thine and mine), the suggestion stands valid in itself. He is using $findtok for the very end of finding not the token itslf, but its position in the string. I don't quite think $poscs would work for his case. Nobody suggested to use it. Are you possibly mishearing on purpose? ... which might well increase performance.. versus what? something like this, which probably "looks ludicruous in terms of ...performance"? Nope, versus a nested $*tok-construction. As the initial poster demonstrated in the initial post, and to which I added another example. To reshape the particular, exemplary situation with a different approach (no $matchtok-situation at all) does not add any new facet to the discussion of the feature suggestion, sorry.
|
|
|
|
|