mIRC Home    About    Download    Register    News    Help

Print Thread
#234714 07/11/11 11:17 PM
Joined: Jul 2006
Posts: 4,145
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
When /filtering with -k, inside the alias called, $v1 is $null.
I would expect it to be filled since $v1 is available from pretty much any scope.
Try from any editbox:
Code:
//if (1) { write -c test test | alias fv1 echo -a > $!v1 - $!1 | fv1 | filter -fk test fv1 | fv1 | alias fv1 }


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #234720 08/11/11 03:02 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
You should really not expect $v1 to be available outside of an if statement-- I think you're using the identifier outside of its intended purpose, and the behaviour is undefined.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2006
Posts: 4,145
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Well, I wasn't really looking for the behavior, but when I realized it, knowing the nature of $v1 (any condition reset it and it's not local to a scope), it looked like a bug, why would you be able to access $v1 from anywhere but here? It seems to me it has been made available outside an if statement on purpose, and if so, it would also make sense to make it available for this case imo, that's why I reported it.
Why do you call the behavior undefined? I hope it's not because you can't find it in the help file..


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #234723 08/11/11 04:05 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
No, I would call the behaviour undefined because its purpose is to report the results of the last executed if statement. Of course, the assumption would be "the last executed if statement within a script process call sequence" if not within an individual alias itself, otherwise you have a really weird scope leak that makes no practical sense to a programming language. In other words, it might be callable from anywhere, but I would expect $v1 to be reset when the call sequence / script finishes. It's undefined because sharing $v1 across script processes doesn't really make sense...

So, the following is valid because the two commands execute in the same sequence / process:

Code:
//if (1) { } | echo -a $v1


The following is not valid because the timer executes in a separate script "process" or call sequence:

Code:
//if (1) { } | .timer 1 1 echo -a $!v1


IMHO this is expected behaviour. It works like many other stateful identifiers in mIRC. The behaviour of $v1 across multiple script processes should be considered undefined.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
Wims' case is an example of two commands in the same call chain: as the echo results show, fv1 in /filter's context is called before the second instance of fv1 in the editbox command. This is different from your /timer example.

I don't know if the current behaviour of $v1 (being available anywhere in the call sequence) was ever intended but it is now well known to scripters and I agree with Wims that it should work the same in /filter's context for the sake of consistency.


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Except we're not talking about /filter'ing in the same call chain, we're talking about /filter -k, which calls back asynchronously, and therefore more akin to /timer than anything else. It would be the same expectation with any callback command (of which mIRC admittedly has few of).


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2006
Posts: 4,145
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Well, /filker -k isn't calling the alias asynchronously, /filter is more like /scid rather than /timer here, /timer isn't blocking the actual routine when executed.
Even if you call that alias a 'callback' alias, it is still called in the same chain as /filter, the same way an alias calling another alias is and it's not because others parts of mIRC use some callback alias method asynchronously that it apply here.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #234747 08/11/11 09:41 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Blocking over the entirety of /filter doesn't necessarily imply that the callbacks themselves are not async. Perhaps we're arguing about terminology so I'll restate it: the callback is using a separate call chain, and rightly so, since it is a callback. You should not expect any commands to be executed in the same call chain unless you explicitly /call them yourself. I think that's fairly reasonable.

Note that this same behaviour occurs with local event identifiers, so it's not just an issue with $v1.

Code:
alias testfilter { echo -a filtering $1- $fulladdress }
on *:TEXT:*:?:echo -a starting with $fulladdress | filter -ffk test.txt testfilter




- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2006
Posts: 4,145
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Quote:
Blocking over the entirety of /filter doesn't necessarily imply that the callbacks themselves are not async
Indeed
Quote:
Perhaps we're arguing about terminology so I'll restate it: the callback is using a separate call chain, and rightly so, since it is a callback.
I don't think we are, it seems to me that you are speculating (and maybe you are right), you introduced that idea of callback, and now you say because it's a callback it's using a seperate call chain, but as far as an user can see, filter is just an alias (you would do it in the same call chain if you were to implement a /filter with scripting) that call multiple time another alias before returning, there's no reason to expect a seperate call chain imo.
Quote:
Note that this same behaviour occurs with local event identifiers, so it's not just an issue with $v1.
Yeah, I just noticed that with $v1, sounds like you are right but it could still be a /filter -k related problem


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #234777 10/11/11 12:54 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: Wims
but as far as an user can see, filter is just an alias


Right, it is an alias. A callback is simply an alias called back from the callee. In other words:

Code:
(1) your_script ---(argument: callback_alias)--> mIRC_function
(2) callback_alias <---------------------------- mIRC_function


Any scenario where the above interaction diagram occurs is what's known as a "callback" alias.

The issue here is that mIRC makes no guarantee, neither in docs nor logically, that the callback is called "immediately", or "in the same context". There's nothing to imply that it should be called in that fashion, either, and in fact, forcing this might limit the ability of the mIRC function to do something important (like threading, etc.), which is likely why it's currently not executing in this fashion.

Another way to explain this is to say that you are passing mIRC the name of an alias, sure. But you're not telling mIRC when or how to call this function. That's why I said earlier that you should never expect an alias to be called in the same call chain unless you explicitly /call it yourself. I don't see why mIRC needs to officially guarantee that the alias is called back from the same call chain-- that is an implementation detail that should be left up to mIRC itself. If you need to pass some kind of state along, you should find a more appropriate way to do it-- frankly I don't even see why $v1 should exist outside local scope of an alias in the first place ($v1 should behave like /var IMO), but that's just a quirk of mIRC's language implementation, and I'd say you're just getting lucky in those other cases (again, my opinion here).

Note that mIRC has callbacks in other scenarios, like $comcall, my guess is you'd have the same expectation there (especially since it is entirely async.).


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2006
Posts: 4,145
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
I know what is a callback.

Regardless of being able to use $v1 (or any local $identifiers as you noted) or not, there's no reason to expect /filter to use a seperate call chain (I don't see any).
The fact that it might not be possible because of some limit is irrelevant, if it's true we will know at some point and then I will see the reason.
$dllcall and $comcall are different from this case, you cannot expect them to call the alias in the same call chain.

I don't need this behavior nor I'm expecting an alias to be called in the same call chain even though I don't call it myself, it's about consistency only.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #235213 30/11/11 06:01 AM
Joined: Apr 2003
Posts: 342
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Apr 2003
Posts: 342
I agree with Wims... argv... nice try but you argument really is full of holes. $v1 should have consistent behavior...


Beware of MeStinkBAD! He knows more than he actually does!

Link Copied to Clipboard