|
|
Joined: May 2003
Posts: 18
Pikka bird
|
OP
Pikka bird
Joined: May 2003
Posts: 18 |
When mirc encounters a command that is neither built-in nor user-defined alias, it forwards the command to the IRC server. This can be problem if the script author didn't really mean to do a server command, instead the command was a result of a typo, careless use of pipe, or unhandled return value from a call to an indentifier:
fi (%a == %b) echo -a The variables are equivalent
echo -s MS-DOS Syntax: dir /s /b | find ".mp3"
$upper(TeXt)
...
FI Unknown command
FIND Unknown command
TEXT Unknown command
The server sends an error message, but there isn't much good debugging info in that message. The messages can also be delayd by lag for several seconds. Finding the source of the error can therefore be very hard. I propose that mirc introduces a pragma that alters this "forward unknown commands to server" behaviour. The pragma is put on the first line of the script and it affects all code in that file. To run a network command from the script the author then *MUST* prefix the command with some special char (eg. @):
@nickserv identify %mypassword
If the command is not prefixed with '@' AND it's not a valid alias in mirc, an error message with debugging info is shown:
nickserv identify %mypassword
...
* /nickserv: undefined alias (line 3, script.mrc)
--Script.mrc--
pragma explicit-network
alias test {
fi (%a == %b) /echo -a The variables are equivalent
; produces * /fi: undefined alias (line 4, script.mrc)
echo -s Dos Syntax: dir /s /b | find ".mp3"
; produces * /find: undefined alias (line 7, script.mrc)
$upper(TeXt)
; produces * /text: undefined alias (line 10, script.mrc)
@nickserv identify %mypassword
; processed by the IRC server
}
--Script.mrc--
Since the pragma affects only that one file, existing scripts will continue to work normally. However, prefixing should be allowed even when the pragma is not in effect. This because a script may call an identifier from another script that returns a prefixed network command:
--Myscript.mrc--
pragma explicit-network
alias getNickservCommand {
if ($network == SOMEnet) return @nickserve identify $nick
else return @nickserv identify
}
--Myscript.mrc--
--Yourscript.mrc--
alias identify {
$getNickservCommand %mypassword
}
--Yourscript.mrc--
Must not be an error!
|
|
|
|
|
Joined: Feb 2003
Posts: 309
Fjord artisan
|
|
Fjord artisan
Joined: Feb 2003
Posts: 309 |
perhaps the use of "redirect to alias" would be a useful addon as well; and could facilitate error handling in mirc script just a little better.
|
|
|
|
|
Joined: Dec 2002
Posts: 2,809
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 2,809 |
Nice idea, bad implementation. You've just managed to break every script in existence, since none of them currently use this @ prefix and therefore none of them will send the command to the server. A better idea is to reverse what you said, if it is prefixed with an @ it is NOT sent to the server. This maintains backwards compatibility with scripts, which I think here is very important because as I said, this won't break 1-2 scripts, this will break nearly all scripts. Everything ranging from a simple alias j { join $1- } to the most complex scripts.
|
|
|
|
|
Joined: Dec 2002
Posts: 117
Vogon poet
|
|
Vogon poet
Joined: Dec 2002
Posts: 117 |
I think the way kinnu proposed it is better:
All scripts currently in existance will work just the same way
Scripts with some special option(maybe set with a special first line) will produce an error whenever a command is used in that script file that is not a valid mIRC command and not an alias.
For sending things directly to the server you can use /raw, so there is no need for a new prefix to complicate things.
Although it might come in handy, I don't think it would be very usefull, since you usually know in which part of your code an error would be (the part you just made). And a search for "fi" would make finding it rather easy.
$input(Me like stars, You too?)
|
|
|
|
|
Joined: Dec 2002
Posts: 2,809
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 2,809 |
Err yeah, I misread what he said about the pragma required part. However that still isn't a good solution imho. In other languages, the good thing about a pragma is they can't be turned on/off on demand. Meaning a pragma does not affect an entire file, it affects part of a file.
pragma someoption on
;this is affected by the pragma
pragma someoption off
;this is not affected by the pragma
In most instances, this feature will be used only for debugging. Once your code is ready to release, everything that this pragma would protect should already be fixed. Meaning if you typed "incv" instead of "inc" that should be corrected before you release the script. Therefore, this seems only useful if you can really limit it. Meaning most of the time you're probably only going to want to "error check" one alias at a time, not an entire file. So it's better if you can limit it to one alias, or maybe even just one line of code.
|
|
|
|
|
Joined: May 2003
Posts: 18
Pikka bird
|
|
OP
Pikka bird
Joined: May 2003
Posts: 18 |
pragma someoption on
;this is affected by the pragma
pragma someoption off
;this is not affected by the pragma
This is fine by me too. I was mostly thinking of simplicity of implementation when I suggested that the pragma be made to affect the entire file. In most instances, this feature will be used only for debugging. Once your code is ready to release, everything that this pragma would protect should already be fixed. I think that is a rather naive way of looking at things. It is just a fact of life that you can't test every possible input, and that even with carefull design you still make mistakes. Most shipping softaware, be it coded in C, Java or mircscript, have bugs that normal everyday users run into. There are mirc scripts that exceed 15 KLOC, you can expect some pretty complex interactions in such beasts. Having the abilty to use various kinds of voluntary "extra" error checks could make a real difference in debugging large scripts. Another usefull pragma could be one that limits the use global variables (think "use strict" of perl), but that is an issue for whole another feature request.
|
|
|
|
|
Joined: Dec 2002
Posts: 2,809
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 2,809 |
Yes bugs will exist in any program, but those types of bugs are generally "logical" errors, not syntax errors. Meaning if you have "aeay" instead of "away" it should be pretty clear, even in the most basic tests, that your away system doesn't work.
|
|
|
|
|
Joined: May 2003
Posts: 18
Pikka bird
|
|
OP
Pikka bird
Joined: May 2003
Posts: 18 |
True enough, it's not a high percentage of bugs that occur "in the wild". Of cource having more informative error messages even while you're in the middle of developing/testing is never a bad thing. But if this is difficult to implement or high-risk, or if there just isn't popular demand (I'm a developer too so I know you don't do something just because one guy think it's neat, that leads to... Perl6 (Hi Larry!)  ) then sure, it's not that big of deal for me either.
|
|
|
|
|
Joined: Dec 2002
Posts: 2,809
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 2,809 |
Well I like the idea of a pragma system, it opens up new possibilities. It would give the possibility to allow mIRC to roll out new features without jeopardizing backwards compatibility. Like a while ago someone suggested allowing true recursion in aliases. But this will break backwards compatibility, something as simple as:
pragma recursive-aliases on
Would solve that issue immediately. The idea of pragmas in general sounds nice to me, and specifically this token could be useful for debugging. I don't know how many times I've incorrectly spelled "inc" while writing a script and then I got flooded because each time my infinite while() loop went through it would send the command to the server.
|
|
|
|
|
Joined: Dec 2002
Posts: 117
Vogon poet
|
|
Vogon poet
Joined: Dec 2002
Posts: 117 |
Maybe the group system could be expanded?
something like
#groupname <options>
;code affected by <options>
#groupname end
;code not affected by <options>
where options is something like
[ on | off ] [noserver] [recursion] [connected] [appactive]
on or [/b]off[/b] turn the group on or off
noserver doesn't send non-mIRC commands/aliases to server
recursion allows recursion (looks better then alias recurse $1-)
connected only enables group when connected to server (so you don't have to check [/i]$server[/i] everytime)
appactive only enables group when mIRC has focus
maybe even an if option:
#groupname if(condition)
only enable group if condition is not $false,$null or 0
$input(Me like stars, You too?)
|
|
|
|
|
Joined: Feb 2003
Posts: 810
Hoopy frood
|
|
Hoopy frood
Joined: Feb 2003
Posts: 810 |
I like these ideas, especially the idea of expanding #groups to accommodate pragmas. I prefer this being supported instead of a "pragma" definition, method or a new block type, because #groups are already there and IMHO it's better to use them instead of adding something new.
But then, using #groups, it wouldn't be possible to define pragmas from inside of an existing block of code. I can't see if this would be needed, though, as I can't find many possibilities at the moment, since I'm new to the usage of pragmas.
* cold edits his posts 24/7
|
|
|
|
|
