mIRC Home    About    Download    Register    News    Help

Print Thread
Signal identifiers, $eval(blah, -N), mode parsing #84987 02/06/04 04:14 PM
Joined: Dec 2002
Posts: 2,962
S
starbucks_mafia Offline OP
Hoopy frood
OP Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Just a few miscellaneous feature suggestions:


  • The ability to provide identifiers for a signal event. Perhaps via a switch that takes a numeric parameter of the number of identifier->value pairs that are being given.
    i.e.
    /signal -i3 uop [color:red]nick starbucks_mafia chan #moo unick arnie regular-parameters[/color]
    would give the signal event uop the predefined identifiers $nick, $chan, and $unick.

    Edit: Now that I think about it the method I've suggested would mean that the identifier values couldn't contain spaces. This could be fixed by supporting double quotes, or it could simply be accepted as a limitation. Or someone could think of a better method for how to provide the identifiers than the one I've given, although I can't think of any other way it could be done that wouldn't be extremely messy.
  • Allow $eval() to take a negative value for the second parameter, $eval(blah, -2) -> $eval(blah, -1) -> $eval(blah, 0) -> blah (for those who think this can be done with $[color:red]!eval(blah, 0)[/color], it's not quite the same thing).
  • An identifier for mode related events (specifically RAWMODE) that returns the sign, character, and parameter (if present) for each mode.
    Right now the only thing resembling this is $mode(), which as far as I know only works with the few specific modes it has properties for (op, deop, owner, ban, etc.). What I'm suggesting is something like that, but which works with all modes and is generally more informative. Something like: $pmode(N) with the properties .sign returning + or -, .char returning the mode character, and .parm returning any parameter it has. It could even be extended so far as to take $pmode(<mode-character>, N).

Before anyone points this out: I'm already aware that identifiers aren't necessary for signals, that negative evaluation can be achieved with gratuitous use of $!identifiers, and that the modes can be parsed using a script.

Last edited by starbucks_mafia; 02/06/04 04:25 PM.

Spelling mistakes, grammatical errors, and stupid comments are intentional.
Re: Signal identifiers, $eval(blah, -N), mode parsing #84988 02/06/04 09:06 PM
Joined: Dec 2002
Posts: 1,922
O
Online Offline
Hoopy frood
Offline
Hoopy frood
O
Joined: Dec 2002
Posts: 1,922
In the meantime you can achieve 'negative evaluation' with a couple of !'s.

For example, type $[color:red]!!!eval(blah,0)[/color] in your mIRC editbox and keep hitting TAB until it evaluates to blah

laugh

Re: Signal identifiers, $eval(blah, -N), mode parsing #84989 02/06/04 10:59 PM
Joined: Jan 2003
Posts: 2,523
Q
qwerty Offline
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
I'd definitely like to see $pmode().


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Re: Signal identifiers, $eval(blah, -N), mode pars #84990 03/06/04 02:07 PM
Joined: Sep 2003
Posts: 70
M
madewokherd Offline
Babel fish
Offline
Babel fish
M
Joined: Sep 2003
Posts: 70
So, what's wrong with $!eval ?

Re: Signal identifiers, $eval(blah, -N), mode pars #84991 03/06/04 02:33 PM
Joined: Dec 2002
Posts: 2,962
S
starbucks_mafia Offline OP
Hoopy frood
OP Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Because if you do $!eval() then the non-evaluation of the first parameter behaviour that makes $eval() useful is lost.

ie.
timer 1 1 $eval(echo -a my name is $mnick aka $anick , -1) would (hypothetically) result in my name is $mnick aka $anick being echoed.
However if you use timer 1 1 $!eval(echo -a my name is $mnick aka $anick , 0) then you will see that because $eval() is no longer being evaluated $mnick and $anick are now being evaluated and you get my name is MyMainNick aka MyAwayNick. So, to make up for that you have to use !'s against every identifier inside $eval() aswell, leading to timer 1 1 $!eval(echo -a my name is $!mnick aka $!anick , 0) - completely defeating the point of using $eval().


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Re: Signal identifiers, $eval(blah, -N), mode pars #84992 03/06/04 11:51 PM
Joined: Apr 2003
Posts: 701
K
Kelder Offline
Hoopy frood
Offline
Hoopy frood
K
Joined: Apr 2003
Posts: 701
There's something strange indeed:
//echo $!calc($calc(5)) echoes $calc($calc(5))
//echo $!calc($calc(5) + $calc(5)) echoes $calc($calc(5) + 5
//echo $!calc($+($calc(5),$chr(32),+,$chr(32),$calc(5)) echoes $calc($+($calc(5),$chr(32),+,$chr(32),$calc(5))

Seems like a ! only stops parsing until the next space...

Re: Signal identifiers, $eval(blah, -N), mode pars #84993 04/06/04 12:03 AM
Joined: Dec 2002
Posts: 2,962
S
starbucks_mafia Offline OP
Hoopy frood
OP Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
It simply means that the identifier in which it is placed in will be treated as text - so identifiers which have special abilities (such as $eval()) no longer have them since as far as the parser is concerned they're just plain text.

With //echo $!calc($calc(5) + $calc(5)) the difference between the two $calc()'s isn't that that ! stops evaluation up to the space, it's that the first $calc() is now adjoining the text $!calc( (remember it's just text now, not the name and opening parenthesis of an identifier), and so the first $calc() isn't evaluated because as far as mIRC is conerned it's no different than if you typed //echo -a moo($calc(5). When it comes to using $!identifier(), spacing is everything, which is why it would be preferable to have a $eval() which can have negative evaluation so that I don't have to use $!identifier() combined with unusual spacing in complex peices of code.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Re: Signal identifiers, $eval(blah, -N), mode pars #84994 04/06/04 12:56 AM
Joined: Jan 2003
Posts: 2,523
Q
qwerty Offline
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
$eval(..,-N) is certainly a valid suggestion, for the reasons you explained. The workaround I've used whenever I've needed such a thing (which would be a couple of times) was something like this:
//set -u1 %a $eval(echo -a my name is $mnick aka $anick,0) | .timer 1 0 % $+ a
This can be easily made to work like -N too: by adding a ! in $+, it becomes equivalent to $eval(...,-2); with a second ! it's like -3 etc:
//set -u1 %a $eval(echo -a my name is $mnick aka $anick,0) | .timer 1 0 .timer 1 0 .timer 1 0 % $!!+ a

If I worked with /scon instead of /timer I'd use a local variable %a, making it cleaner.

For long time intervals, when a global variable could be an unsafe place to store the command into, one could use a custom identifier:
alias blah return $eval(echo -a my name is $mnick aka $anick,0)
//.timer 1 10 $!blah


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com