mIRC Home    About    Download    Register    News    Help

Print Thread
my feature suggestions #158170 01/09/06 06:33 PM
Joined: Aug 2006
Posts: 26
D
Dromedary Offline OP
Ameglian cow
OP Offline
Ameglian cow
D
Joined: Aug 2006
Posts: 26
i have multiple feature suggestions, so i'm just consolidating them into one post. i've been mirc scripting for multiple years, so i feel these are well thought out. so if you feel something may already be available, look again and make sure you haven't misunderstood the specific nature of my feature request. thanks

1) /set or /var -long. in c you can have "long" variables, which basically means they allocate more memory to that specific one. i know most of you probably know this, but that was for the newbs. why binary variables are not acceptable is their difficulty to use in many situations. they also still cause line too long errors. i realize it would be in a word challenging to write everything in mirc to support it, so my suggestion is to allow "var -long" and allow "right", "left", "len", and "gettok" to work on long variables. this would allow us to have enough text manipulation freedom that we could use normal variables for the remainder of the script. -- of course, remember, these types of variables would have a length limit as well, but just not as small as the current ones. i don't know how variables in mirc are stored, so i don't know the exact length possible.

(continuation) /sockread -long for being able to read a socket into a long variable. again, remember that long variables would [likely] not be compatible with everything, so people would need to use /sockread -long with care.

2) i already suggested this before, just adding it for the sake of being all-inclusive. it would be nice to be able to use $1(text goes here) as a shorter form of gettok. it would assume the token type is either 32, or the token type which was specified via the /tokenize command.

3) alias -r. recursion has been intentionally removed from mirc for a while now, and for the right reasons. it's not normally a good idea to have an alias call itself, especially if used in the wrong hands. on the other hand though, recursion is a very powerful tool. it can sometimes be the only way to efficiently perform tasks. adding the flag -r would just simply allow recursion. for the newbs: recursion is when a program executes itself. for example /alias test { echo -a Testing Recursion | test }. the sample script would execute "echo -a Testing recursion" and then just execute itself, which would echo testing recursion and then call itself again, etc... indefinitely. of course, in the example it's quite useless, but in more advanced functions the ability to use recursion can be an excellent tool.

4) /sleep. if any code in mirc calls /sleep, it should allow other parts of mirc to continue like normal, but "sleep" the current execution stack X amount of time (usually represented in milliseconds). this would allow certain aliases and functions to be called without using 100% cpu. some may argue that we have whilefix.dll that works perfectly, and that's quite true, however, whilefix does not call the true sleep command, so even though you can function like normal with a large while loop going on, it is always going to take 100% cpu. some tasks do not require 100% cpu, and are just nice to have on the occasion. timers, also, do not have the same power over script execution that a sleep command would (though one may argue that they can be used in order to overcome this problem, i will agree, but usually not easily).

5) stack tracing for debugging. i am 99% sure that's improper terminology, but basically this is what i'm looking for:

on *:text:!test*:#channel: {
test1 $2-
}
alias test1 {
test2 $1-
}
alias test2 {
test3 $1-
}
alias test3 {
echo -a $stack
}

that would return something to the effect of:

on *:text:!test*:#channel: <--- test1 <--- test2 <--- test3

i've never written an interpreted language, but i would imagine this data would have to be known to process it properly anyway, so it may be an easy implementation. the stack would be very much so an excellent feature when aliases call aliases that call aliases. it can become very tedious manually back tracing it.

6) /strictcharacters (on/off). perhaps make this an option in mirc.ini, settable in an advanced section of the mirc options. basically, what i want to do is able to turn strict characters on or off in mirc. right now, mirc's behavior would be like strictcharacters being off. as some of us know, in programming languages such as C/C++, no 2 characters are treated differently. the same can be said for many programming languages, even interpreted ones. strings in mirc, however, are not all treated alike. many times mirc will remove leading and trailing spaces, or will sometimes [namely, in the echo command] remove repeated whitespace. a non-breaking space is not always the right answer (especially since in some fonts it actually does not even show up as a space). being able to toggle strict spacing on or off, or get its current status. this will allow for coders who want to implement the new feature to be able to do it without ruining pre-existing scripts. also, while enabled, it might not be too bad of an idea to make the token identifiers such as gettok, numtok, etc. work on a much more specific level. therefore, something that looks like test [3 spaces] test would have the first 32 delimited token as test, the second as null, the third as null, the 4th as null, and the 5th as test. this type of behavior is usually not desired, so it might even be a better idea to make new identifier names, or props to the existing identifiers to act in this way [regardless of the status of the 'strictcharacters' setting].

thanks for reading my suggestions. like i said, each of them are things i've thought about for a long time, so please don't discount this as some guy got a spur of the moment idea and rushed to the feature suggestion board to get it down before he forgot what it was. i know i'm gonna get flamed, but hey, every mirc scripter should have a high tolerance for flames :P

edited: some dumb typo's and such

Re: my feature suggestions #158171 01/09/06 10:25 PM
Joined: Sep 2003
Posts: 4,230
D
DaveC Offline
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
1) While I wouldnt mind longer var's at all, I have a feeling the limit is within some other functionality of mirc, rather than some limit Khaled just thought up one day. So there maybe some difficulties in implementing this at all (and maybe not)

2) I didnt even understand what you suggested here, maybe an example would have helped.

3) Sounds good, currently i just call a second alias that calls the first one, a bit sucky but hey what can ya do.

4) This sounds good, but again, im not sure how workable it might be, From what i have seen there are some limitations of reentry of code in mirc, such as how you cant use $input in an event, even using it in a timer has problems as it seems to halt the execution of other timers untill the one the input is in completes, i have resorted to signals to solve this. Now I assume doing a /Sleep may have the same problematic results (again tho who knows)

5) Oh my but this would be nice

6) nice idea but i think it would take a fundermential rewrite of the scripting engine some how frown

Re: my feature suggestions #158172 02/09/06 05:26 AM
Joined: Oct 2004
Posts: 73
M
Mardeg Offline
Babel fish
Offline
Babel fish
M
Joined: Oct 2004
Posts: 73
5) This would be useful for Design By Contract abstract scripting methods too.

Re: my feature suggestions #158173 02/09/06 06:04 AM
Joined: Aug 2006
Posts: 26
D
Dromedary Offline OP
Ameglian cow
OP Offline
Ameglian cow
D
Joined: Aug 2006
Posts: 26
Quote:
1) While I wouldnt mind longer var's at all, I have a feeling the limit is within some other functionality of mirc, rather than some limit Khaled just thought up one day. So there maybe some difficulties in implementing this at all (and maybe not)


i agree, and thought that might be true as well. that's why i suggested maybe only allowing certain key aliases to be compatible with the new long variables. this would give us a way to use them without having khaled have to rewrite every alias mirc comes with [or, atleast, that's what my goal was]

Quote:
2) I didnt even understand what you suggested here, maybe an example would have helped.


sorry about the ambiguity. basically, assume 32 in this example represents the number which was specified with the tokenize command. $1(text goes here) would return text. $2(text goes here) would return goes $2-3(text goes here) would return goes here, you get the idea. the token delimiter, as i stated before, uses either the default of 32, or whatever the person specified in the last /tokenize command.

Quote:
3) Sounds good, currently i just call a second alias that calls the first one, a bit sucky but hey what can ya do.


yea, same. it's not all that bad, but i did recently run into a situation where that proved to be unsuccessful for me (i can't remember the specifics, but basically it had to do with a timer needing to call recursion, so i couldn't use $!alias to be called in the second alias being called by the timer because the timer re-evaluated aliases with $!)

Quote:
4) This sounds good, but again, im not sure how workable it might be, From what i have seen there are some limitations of reentry of code in mirc, such as how you cant use $input in an event, even using it in a timer has problems as it seems to halt the execution of other timers untill the one the input is in completes, i have resorted to signals to solve this. Now I assume doing a /Sleep may have the same problematic results (again tho who knows)


i do kindof agree, but with the script snippets that have been made that do this fairly successfully through dll's and such, it seems this might be possible in mirc without too much work *shrugs*

Quote:
6) nice idea but i think it would take a fundermential rewrite of the scripting engine some how frown


if that's true, it would still be nice to see a couple of new aliases/props to handle strings in this way (like $gettok,$numtok,$right,$left etc basically aliases that deal specifically with string manipulation.)

Re: my feature suggestions #158174 03/09/06 01:54 AM
Joined: Sep 2003
Posts: 4,230
D
DaveC Offline
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
Quote:
>>2) I didnt even understand what you suggested here, maybe an example would have helped.

sorry about the ambiguity. basically, assume 32 in this example represents the number which was specified with the tokenize command. $1(text goes here) would return text. $2(text goes here) would return goes $2-3(text goes here) would return goes here, you get the idea. the token delimiter, as i stated before, uses either the default of 32, or whatever the person specified in the last /tokenize command.


oh ok that makes it clearer, unfortunitely $n identiofiers can have text attached to the end of them already, so doing this is likely to break existing scripts.
ex: //tokenize 32 a b c d | echo -a $2(x y z)
b(x y z)

Quote:
>>3) Sounds good, currently i just call a second alias that calls the first one, a bit sucky but hey what can ya do.

yea, same. it's not all that bad, but i did recently run into a situation where that proved to be unsuccessful for me (i can't remember the specifics, but basically it had to do with a timer needing to call recursion, so i couldn't use $!alias to be called in the second alias being called by the timer because the timer re-evaluated aliases with $!)


?!?!? u actually called an alias !name ?
ex ALIAS !NAME { ... } ?!?!?!?

Re: my feature suggestions #158175 04/09/06 07:51 PM
Joined: Aug 2006
Posts: 26
D
Dromedary Offline OP
Ameglian cow
OP Offline
Ameglian cow
D
Joined: Aug 2006
Posts: 26
Quote:
Quote:
>>2) I didnt even understand what you suggested here, maybe an example would have helped.

sorry about the ambiguity. basically, assume 32 in this example represents the number which was specified with the tokenize command. $1(text goes here) would return text. $2(text goes here) would return goes $2-3(text goes here) would return goes here, you get the idea. the token delimiter, as i stated before, uses either the default of 32, or whatever the person specified in the last /tokenize command.


oh ok that makes it clearer, unfortunitely $n identiofiers can have text attached to the end of them already, so doing this is likely to break existing scripts.
ex: //tokenize 32 a b c d | echo -a $2(x y z)
b(x y z)

Quote:
>>3) Sounds good, currently i just call a second alias that calls the first one, a bit sucky but hey what can ya do.

yea, same. it's not all that bad, but i did recently run into a situation where that proved to be unsuccessful for me (i can't remember the specifics, but basically it had to do with a timer needing to call recursion, so i couldn't use $!alias to be called in the second alias being called by the timer because the timer re-evaluated aliases with $!)


?!?!? u actually called an alias !name ?
ex ALIAS !NAME { ... } ?!?!?!?


no no, i'll try to explain [argh, i lost my first typed-up reply, so this may be lacking quality]. i deleted the script so i can't remember exactly what it was. basically, this is how it went:

Code:
alias test {
  echo -a $1-
  cmd $!test($1-)
}
alias cmd {
  noop $($1-,2)
}


alright, the previous code might work pretty decently. however, the problem came when i tried to call $test with a timer through command. if you were to call from within the test alias ".timer 1 10 cmd some crap $!test(craphere)" it would in theory work, however, the timer command itself 'knows' $! prefix for commands, and uses that to evaluate that at the time of the script. so if i do $!test($1-) inside of a timer, $1- will be null when the timer re-evals what $1- is. it was no big deal to just seperate aliases when i was writing the script or i would have tried $chr(whatever) $+ test and seen if that would work. either way, it was an annoyance at the time and explains how a lack of recursion just further causes problems with scripts that require recursion.

Re: my feature suggestions #158176 04/09/06 08:02 PM
Joined: Sep 2003
Posts: 4,230
D
DaveC Offline
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
I see what u mean now, I never worried about that, i was more concerned about the call/recursion depth limit of 1000. So i might not have been quite right about what i said, the second alias didnt actually call the first to do the work again, it was the first alais a second time, so when it called it called the 1st again

Code:
alias blah1 {
  ...code...
  if (whatever) { blah2 parameters }
}
alias blah2 {
  ...code...
  if (whatever) { blah1 parameters }
}


As said above mirc has a depth limit of 1000, so this enabled me to drive twice as deep as doing alias blah2 { blah1 $1- }

From memory the one i had to use this on was a quicksort routine where i couldnt use the filter sorts becuase of a sliding position of the sorted data on the line.
Even then in the end i replaced it sweeping the file and creating an index into it woth the relevent data and a linenumber to the orginal, and just filtered that frown

Last edited by DaveC; 04/09/06 08:05 PM.