//set %fileSize $file(abc.txt).size | //write abc.txt text | //echo -a $calc($file(abc.txt).size - %fileSize)
and I got
8.
when I tried 2 make it again- I got 6.
the file wasn't ending with $crlf on the 1st time so mIRC added this $crlf at the begining and at the end- so I got 8. this has nothing to do with the OS.
I was suggesting to add -n switch couz I didn't know it already in use (I am using older version of mIRC which don't have it).
The last statement is a bit of a hint at things, u shouldnt ask for improvements unless your using the latest version, using -n infact does prevent a /write from appending a $crlf from the front and end. Only the text being written is appened to the file.
the suggestion from
multi threading also remains. I mean preventing from mIRC to freeze on any long operation. I am not talking about processing events- but about preforming what written in this operation...
here is an example:
$file(abc.dat).size is bigger than 1.5 Gb.
alias slowAlias {
var %i = 0
while (%i < $file(abc.dat).size) {
inc %i
bread abc.dat %i 1 &abc
bwrite abc.txt -1 -1 $chr($hget(assChar,$bvar(&abc,1)))
if ($right(%i,5) == 20000) echo -a now on $round($calc(%i / $file(abc.dat).size),1) $+ $chr(37) char $bytes(%i)
}
}
when I run /slowAlias from the command line- mIRC displays few lines with "now on..." and then freezes. after few minutes it returns to life and displays all the other messages.
it shouldn't b that way.
Well thats is an incredibly slow alias, I assume it was written like that to make it slow, but assuming that is how it must performed, one byte at a time from the front of the file to the end.
Then some cleverer coding well make it not freeze mirc at all.
alias slowAlias2 {
.timerslowAlias2.timer $file(abc.dat).size 0 slowAlias2.timer $file(abc.dat).size
}
alias slowAlias2.timer {
var %i = $calc($1 - $timer(slowAlias2.timer).reps)
bread abc.dat %i 1 &abc
bwrite abc.txt -1 -1 $chr($hget(assChar,$bvar(&abc,1)))
if ($right(%i,5) == 20000) echo -a now on $round($calc(%i / $1),1) $+ $chr(37) char $bytes(%i)
}
}
actually I didn't tried this alias- but that what would happen if I'd try.Tthe suggestion was to implement kind of multithreading but any other solution would b good also.
Multithreading while it would be great, also creates a huge stack of its own problems,
Lets say a bot offered a command
!send filename the file is then mime encoded zipped up and dispatched (why a bot would do this is not relevent its an example)
on *:text:!send *:#{
if $send($nick) { msg $nick your already getting a file piggy! }
else {
...
while loop to { encode original file to a temp.file }
some zipup dlll that takes a few seconds as well
...
dcc send $nick temp.file
}
}
Now if the system was multithread, some user might go
!send blah.avi
!send gogo.exe
!send fred.gif
!send bill.bin
Since each of them would get a thread running the alias before the 1st alias would send the file, the alias would not know of other temp.files being prepeared for sending, so the user would have slipped 4 requests in (or more)
That of course is a simple matter to deal with using flag falls, but was to show how a multithreaded enviroment produces a whole new set of conditions a coder must watch for.
The Best i could think of to make it compatable with current mirc scripts is to have a alias -m aliasname option that means please run this alias in its own thread, then its on the head of the scripter to deal with all the multi thread collisions problems that might arise.
