mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline OP
Hoopy frood
OP Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Here's the deal. Code could be much more intuitive if event triggered script processes made its identifiers global within the process of the script

Example:
Code:
alias somealias { echo -a $nick }
on *:TEXT:*:# { somealias }


Currently, mIRC will not be able to parse the $nick in somealias and will return null. But it would be nice if all identifiers generated by an event process were set and maintained globally through the entire script process, so that any concurrent function calls would be able to use the identifiers without having to pass them as parameters (which can be ugly and become confusing)

One extremely useful application for this is the recently introduced SIGNAL, which doesn't really get much attention from scripters- and I think one of the main reasons is that it's so confusing to use, since everything you need has to be passed to the signal before you can use it.

Consider the following, first as it currently is, and next with global $identifiers in a script process
Code:
on *:TEXT:*:#:/signal TEST $nick $fulladdress # $1-
on *:SIGNAL:TEST: { echo -a $1 / $2 said $4- on $3 }
 
- or -
 
on *:TEXT:*:#:/signal TEST $1-
on *:SIGNAL:TEST: { echo -a $nick / $fulladdress said $1- on # }


The first one is clearly much harder to debug, as well as maintain: if you wanted to add another $identifier, say... $wildsite, to the signal, you'd have to not only add it to the signal event, but pass it to the signal as well, and change all the parameters in the signal, because everything will be pushed up by 1 (its now $5- for text)

The second one on the other hand is clear and concise. Though i did bring up one issue in the example itself, which is the handling of $1-. MY answer to that would be, $1- (and $1 and $2, $1-2, etc respectively) would be a special case that mIRC would _not_ make global, and would have to be passed to the signal.

There are many other practical uses to this, don't think it would be _too_ hard to implement either. It would sure make me love signals a whole lot more.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Aug 2003
Posts: 1,831
I
Hoopy frood
Offline
Hoopy frood
I
Joined: Aug 2003
Posts: 1,831
Quote:
Currently, mIRC will not be able to parse the $nick in somealias and will return null.

Uh no, mIRC does handle the $chan $nick $address $fulladdress $site etc identifiers, Just not the text itself, and not through a /signal.
Code:
alias somealias { echo -a $nick $fulladdress said $1- on #  }
on *:TEXT:*:# { somealias $1- }

Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
lori has already mentioned that $nick etc are maintained within called aliases, which is a help and a hinderence, a help in that you dont need to pass the value, a hinderence in that if debugging you cant call the alias manually as the $identifer well be $null. So in fact I often do pass all the values I want even if they well appear when called from an event, this way i can fake them during a debugging session.

Quote:
on *:TEXT:*:#:/signal TEST $nick $fulladdress # $1-
on *:SIGNAL:TEST: { echo -a $1 / $2 said $4- on $3 }

The first one is clearly much harder to debug, as well as maintain: if you wanted to add another $identifier, say... $wildsite, to the signal, you'd have to not only add it to the signal event, but pass it to the signal as well, and change all the parameters in the signal, because everything will be pushed up by 1 (its now $5- for text)


Pretty easy to fix

on *:TEXT:*:#:/signal TEST $wildsite $nick $fulladdress # $1-
on *:SIGNAL:TEST: {
var %wildsite = $1 | ; or what ever you want to do with $1 being $wildsite
tokenize 32 $2-
echo -a $1 / $2 said $4- on $3
}

Joined: Oct 2003
Posts: 3,918
A
argv0 Offline OP
Hoopy frood
OP Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Quote:

Pretty easy to fix


That isnt a 'fix', that's a workaround. The point of the suggestion is so that $identifiers would NOT have to be passed through the signal, and I clearly stated that in the original post.

I did not know about aliases carrying over $nick/etc (Iori), but my main concern is the ON SIGNAL event

currently $nick in an on signal is equivalent to $me, which shouldn't be the desired effect of $nick within a signal. If anything, it should be $null. (Saying that $me triggered the event is not a fair thing to say, since signals can only be triggered by $me anyway)

I'll restate my suggestion again, in case you didn't catch it the first time:

It would be nice if mirc's builtin event identifiers ($nick # $chan $wildtsite, etc.) were passed to ON SIGNAL just like they are currently passed to aliases when called from an event


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
Quote:
That isnt a 'fix', that's a workaround.


No its is a fix, it was said as a fix in direct quote of " and change all the parameters in the signal, because everything will be pushed up by 1 (its now $5- for text) ", It Would fix that problem, they well not be pushed up by one after it.


Quote:
The point of the suggestion is so that $identifiers would NOT have to be passed through the signal, and I clearly stated that in the original post.

I did not know about aliases carrying over $nick/etc (Iori), but my main concern is the ON SIGNAL event


You started your post with "Here's the deal. Code could be much more intuitive if event triggered script processes made its identifiers global within the process of the script" (which was invalid as this is the current behavour) then later said "One extremely useful application for this is the recently introduced SIGNAL". That hardly means that having them appear in signals was the point of your suggestion, also actually as you showed it (the signal) was outside the scope of your idea of making them appear globally within the event script, as the signal you showed does not occur sometime after the completion of the event (this may or maynot be directly following it).

Quote:
currently $nick in an on signal is equivalent to $me, which shouldn't be the desired effect of $nick within a signal. If anything, it should be $null. (Saying that $me triggered the event is not a fair thing to say, since signals can only be triggered by $me anyway)


Sounds fair to me, in keeping with who triggered the script it was you.

Quote:
I'll restate my suggestion again, in case you didn't catch it the first time:

It would be nice if mirc's builtin event identifiers ($nick # $chan $wildtsite, etc.) were passed to ON SIGNAL just like they are currently passed to aliases when called from an event


No need to be snakie with the "you didnt catch it" since you didnt make it clear.

I actually think your suggestion is a very good one.
Why not pass Identifiers that normally dont exist unless in a event, I see no reason not to, but as to how easy or hard that might be with the current event processing system, which i assume is some kind of queue system. I wouldnt know.
Also since $nick is currently evaluated to $me in a signal, it might cause a few current scripts to fail, but i doubt very many, and scripters have always had to deal with adjustments in mirc between versions.

Joined: Feb 2005
Posts: 681
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Feb 2005
Posts: 681
Quote:
it might cause a few current scripts to fail, but i doubt very many, and
scripters have always had to deal with adjustments in mirc between
versions.


True we have always had to deal with changes, but
that should in no way even be a factor when considering
changes IMO.

Last edited by mIRCManiac; 23/02/05 01:19 PM.
Joined: Oct 2004
Posts: 72
C
Babel fish
Offline
Babel fish
C
Joined: Oct 2004
Posts: 72
I don't think this is a very good suggestion. You all seem to forget that catching events is a real-time process. For instance, lets say you want to analyse lines of text, so you create an on TEXT event and an alias:

on *:TEXT:*:#: {
dosomething
}
alias dosomething {
if (xyz isin $1-) { /msg $nick Don't say that again }
.. other code..
}

Now, suppose there is more code, quite complex code, which can take some time to process. While processing, another guy types a line in the room and your on TEXT event calls "dosomething" again. At that time, the contents of $nick and $1- will change, while your script could still be processing the previous textline. This is why you have to pass parameters.

Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
First of all, it's not a suggestion: mirc already works the way argv0 suggested (he just hadn't noticed).

Second, the scenario you described can never happen because mirc can do one thing at a time (via a single thread). So, it can't receive a new message and process it while a previous routine that uses $nick is still running. If a message arrives when mirc is running a script, it is put "on hold" and isn't processed until mirc's finished with that script.


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Joined: Oct 2004
Posts: 72
C
Babel fish
Offline
Babel fish
C
Joined: Oct 2004
Posts: 72
Hmm, you're right, I always thought mirc was multi-threaded. And now I'm wondering whether it would be a good idea to make it so??

Joined: Feb 2005
Posts: 681
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Feb 2005
Posts: 681
Quote:
wondering whether it would be a good idea to make it so??

Yes.

Joined: Oct 2003
Posts: 3,918
A
argv0 Offline OP
Hoopy frood
OP Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Quote:
Quote:
wondering whether it would be a good idea to make it so??

Yes.


No.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Feb 2005
Posts: 681
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Feb 2005
Posts: 681
Quote:
Quote:
Quote:
wondering whether it would be a good idea to make it so??

Yes.


No.

Yes.

Joined: Dec 2002
Posts: 208
H
Fjord artisan
Offline
Fjord artisan
H
Joined: Dec 2002
Posts: 208
Quote:
Quote:
Quote:
Quote:
wondering whether it would be a good idea to make it so??

Yes.


No.

Yes.

Maybe.


If I knew now what I will know then... maybe things will have been different...
Joined: Feb 2005
Posts: 681
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Feb 2005
Posts: 681
Quote:
Quote:
Quote:
Quote:
[quote]wondering whether it would be a good idea to make it so??

Yes.


No.

Yes.

Maybe. [/quote]
Maybe > No smile

Last edited by mIRCManiac; 27/02/05 11:31 PM.
Joined: Feb 2004
Posts: 201
J
Jae Offline
Fjord artisan
Offline
Fjord artisan
J
Joined: Feb 2004
Posts: 201
Errr... you guys are crazy...
Back to topic... it'd be interesting to have a way to pass on identifiers to the SIGNAL event.
when doing /signal
somehow add in when u can set the identifier for that signal..
say
/signal [-n] <name> SET $nick $nick; SET $something %variable; PARAM $5-
on *:SIGNAL:<name>:{
$something would return what %varliable passed to it.
}

Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
there is its called $1-

Joined: Feb 2004
Posts: 201
J
Jae Offline
Fjord artisan
Offline
Fjord artisan
J
Joined: Feb 2004
Posts: 201
I believe the idea is to make information more accessable
If you had to use $1 $2 etc to refer to someone's nick, fulladdress

Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
I cant see the purpose of what your saying, if your writting a script to go off on a signal you should know what its passing the signal when its triggered, admitedly if you could set a series of "definable" variables it might make the script more readable, and you would not have to worry about someone failing to pass all of them and thus causing the data to be in the wrong $x position as you would with $1-, but I dont really see the idea of creating a whole new passing scheme (refering to the ability to set $identifiers) as warrented. If you wanted to pass values like that script them in using (1) ...
set %<signalname>.nick blah
set %<signalname>.something etc etc
or (2) ...
alias <signalname>.nick { if ($isid && !$0) { return $iif($var(%<signalname>.nick,0),%<signalname>.nick,$me) } else { set %<signalname>.nick $1- } }
alias <signalname>.something { if ($isid && !$0) { return $iif($var(%<signalname>.something,0),%<signalname>.something,hardcoded setting here) } else { set %<signalname>.nick $1- } }
and (1) and (2) the signal script ends with " /unset %<signalname>.* "

But i just dont see the purpose, you can simply pass all needed values using $1- either by value if they arent to long or by refrence passing in the correct $x the name of a variable that contains the parameter which is good for single parameters that may have spaces in like filenames, (i do this in normal alias calls if i have too as well)

Joined: Feb 2004
Posts: 201
J
Jae Offline
Fjord artisan
Offline
Fjord artisan
J
Joined: Feb 2004
Posts: 201
Or even:

Code:
 /signal [-n] &lt;name&gt; nick,something $nick , %something %variable $1 $2 etc...

on *:SIGNAL:&lt;name&gt;:{
;As you have nick,something ... %something becomes $nick.. %varliable becomes $something and $1 @ etc as 'asis'
;Meaning there is no script breakage. plus a simple way of setting things to be passed on. Using much less code and fiddling.
;Also save passing everything seperately..
} 

Joined: Oct 2003
Posts: 3,918
A
argv0 Offline OP
Hoopy frood
OP Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Quote:

But i just dont see the purpose, you can simply pass all needed values using $1- either by value if they arent to long or by refrence passing in the correct $x the name of a variable that contains the parameter which is good for single parameters that may have spaces in like filenames, (i do this in normal alias calls if i have too as well)


I forgot about this thread but i was going over the threads and i saw your post

the purpose of such a feature is to allow signals to store more metadata in their code and be easier to read. More importantly, It ALSO allows a specific signal to serve ONLY ONE purpose rather than any arbitrary one.

For instance, if i wanted a SIGNAL event to use the globalized $nick identifier ONLY if it exists, otherwise the event should exit. This means I am limiting my SIGNAL to being called from events with the $nick identifier supplied. Using $1- _might_ work, but then a user or a script could manually /signal SIG test, which is not wanted. The ability to use $nick in a situation like this guarantees the validity of the data being passed to the signal/alias.

It basically makes code clearer and sometimes avoids the need to error check .. in SIGNAL events.. that's why it's useful


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"

Link Copied to Clipboard