|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
OP
Fjord artisan
Joined: Apr 2003
Posts: 342 |
I've done some testing and when using $fread and it encounters the end of file, the entire execution of the script terminates w/o warning.
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
Joined: Dec 2002
Posts: 5,493
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,493 |
Please provide a short example script that reproduces this issue.
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
OP
Fjord artisan
Joined: Apr 2003
Posts: 342 |
alias eoftest {
/timer.fclose 1 1 /fclose mirc.ini
/fopen mirc.ini mirc.ini
while (!$feof && !$ferr) {
var %line = $fread(mirc.ini)
}
/fclose mirc.ini
/timer.fclose off
} If the timer executes then the bug exists... * Note I've come up w/ this code on the fly it's not exactly tested.
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
You should maybe provide some code that you've tested and reproduces the bug, as that one works fine: * Timer .fclose activated - * fopen opened 'mirc.ini' (C:\Users\Matt\AppData\Roaming\mIRC\mirc.ini) - * fclose closed 'mirc.ini' (C:\Users\Matt\AppData\Roaming\mIRC\mirc.ini) - * Timer .fclose halted - Running the public beta.
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
OP
Fjord artisan
Joined: Apr 2003
Posts: 342 |
Please try reading from the following file as it is the file I was reading from... and try to make sure it does indeed get every line. http://db.tt/kFpHqD9
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
alias eoftest {
/timer.fclose 1 1 /fclose mirc.ini
/fopen mirc.ini sjis-0208-1997-std.txt
var %i = 0
while (!$feof && !$ferr) {
var %line = $fread(mirc.ini)
inc %i
}
echo -s ~ Line: %i || Lines: $lines(sjis-0208-1997-std.txt)
/fclose mirc.ini
/timer.fclose off
} * Timer .fclose activated - * fopen opened 'mirc.ini' (C:\Users\Matt\AppData\Roaming\mIRC\sjis-0208-1997-std.txt) - ~ Line: 9067 || Lines: 9066 - * fclose closed 'mirc.ini' (C:\Users\Matt\AppData\Roaming\mIRC\sjis-0208-1997-std.txt) - * Timer .fclose halted - Still not able to reproduce this problem. What does this return? //echo -a $os $version $md5($mircexe,2) $file($mircexe).sig $script(0) $dll(0) $com(0)
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
OP
Fjord artisan
Joined: Apr 2003
Posts: 342 |
#_DEFAULT.PROPERTIES OFF
[start]
[CONST]
SJISSPEC=$mircdir $+ sjis-0208-1997-std.txt
#_DEFAULT.PROPERTIES END
ALIAS __SJISspec { return $readini($script,CONST,SJISSPEC) }
ALIAS DEC2HEX {
var %pad = $len($base($$1,10,16))
if (2 \\ %pad) { %pad = %pad + 1 }
if ($isid) { return $base($$1,10,16,%pad) }
elseif ($1 isnum) { echo -aspe 0x $+ $base($$1,10,16,%pad) }
}
ALIAS HEX2DEC {
if ($left($1,2) == 0x) || ($left($1,2) == U+) { tokenize 32 $right($1,-2) }
if ($isid) { return $base($$1,16,10,1) }
else { echo -aspe $base($$1,16,10,1) }
}
alias import_sjis {
if ($hget(sjis)) { /.hfree sjis }
/hmake sjis 10000
/.fopen sjis $qt($__SJISspec)
while (!$fopen(sjis).eof && !$ferr) {
tokenize 09 $fread(sjis)
if ($0 > 2) { var %sjis = $1, %utfc = $2, %desc = $3- }
else { var %sjis = $1, %utfc, %desc = $2- }
if ($+($#,*) iswm %sjis) continue
if ($hex2dec(%sjis) < 128) continue
if (<doublebytes> isin %desc) { /hadd sjis $hex2dec(%sjis) <doublebytes> }
elseif (<cjk> isin %desc) { /hadd sjis $hex2dec(%sjis) $hex2dec(%utfc) $chr($hex2dec(%utfc)) }
elseif ($left(%utfc,2) == U+) { /hadd sjis $hex2dec(%sjis) $hex2dec(%utfc) $chr($hex2dec(%utfc)) }
}
:error
/fclose sjis
} Okay that is the actual (and quite embarrassingly ugly) code I wrote the demonstrated the issue... well I found the problem... has nothing to do with file handles. Of course the code works perfectly fine in 6.35. It performed identically except that it would close the handle properly. In 7.15 it would not. Something was amuck... but it was so long ago... i didn't report the issue well over a week I had discovered it because I didn't really have easy access to it. I didn't have access to it when I did report the problem. Of course I suppose file handles are working exactly as they should... The cause of the problem? I'll highlight it below... if ($isid) { return $base($$1,16,10,1) }Yeah I never actually really use $$. I mean I don't quite understand why $$ would break or halt execution. I don't know if it halts or breaks execution. I don't think it knows itself. CLearly it once simply acted as a break... now I guess it acts as a "halt" for "consistently". One would think that $$ would likely act like $!... I mean why doesn't %% behave like $$? Why doesn't %! behave like $!? Does it matter? No. But You are going to have a hard time arguing this is for constancy when I see no constancy.
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
Joined: Apr 2010
Posts: 969
Hoopy frood
|
Hoopy frood
Joined: Apr 2010
Posts: 969 |
it says in the help file and i qupte The double $$ means that this command will only be executed if a parameter is specified. I can see how it could me mis-inturpertated(SP?!) but generally, if you read the help file, the $$ and it's uses are one of the first things you use. Look at the default aliases that come with mIRC. Your argument is invalid for the %%var. How is mIRC supposed to know that the 2nd % isn't part of the variable name. I have seen many scripts use %%varname to mark the variable as a tempory variable to been cleaned up later. You CAN'T create an alias like "alias $myalias { stuff }"
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
OP
Fjord artisan
Joined: Apr 2003
Posts: 342 |
it says in the help file and i qupte The double $$ means that this command will only be executed if a parameter is specified. I can see how it could me mis-inturpertated(SP?!) but generally, if you read the help file, the $$ and it's uses are one of the first things you use. Look at the default aliases that come with mIRC. Your argument is invalid for the %%var. How is mIRC supposed to know that the 2nd % isn't part of the variable name. I have seen many scripts use %%varname to mark the variable as a tempory variable to been cleaned up later. You CAN'T create an alias like "alias $myalias { stuff }" Type "/alias $myalias { stuff }" before stating you can't possible create it...
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
Joined: Apr 2010
Posts: 969
Hoopy frood
|
Hoopy frood
Joined: Apr 2010
Posts: 969 |
alias $myalias {
echo -a $!MyAlias Triggered
return $!MyAlias Triggered
}
alias MyAliasTest {
echo -a $!MyAlias: $MyAlias
echo -a Trying /$MyAlias:
$myAlias
echo -a Trying /$$MyAlias:
$$MyAlias
echo -a $!$MyAlias: $$MyAlias
} How about before criticizing you thoroughly test code yourself. NONE return! Yes, you can add "$somealias" to your aliases section, but you can never access the alias.
Last edited by FroggieDaFrog; 12/12/10 03:49 AM.
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
$$ is used as a way to stop output if there isn't a value. It's useful when you don't want to throw an error message if some value isn't included. Of course, you can include error checking to verify that the value is there, but $$ is easier and does the same thing. A basic example is something like:
msg $chan $$?="Message"
Without the $$, it will give an error if you press cancel or ok without any text. With $$, it will simply halt the msg without throwing an error.
As far as naming identifiers, yes, you can name an identifier something like $identifier if you want to. However, it will be of limited use. You cannot call it using $identifier or $$identifier because both will point to an identifier named "identifier". $$identifier will just halt if nothing is returned. You *can* call it using $$$identifier. The limitation is that this will always halt if nothing is returned. If that's okay with whatever your script is doing, then it isn't a problem. But, if there are times with the identifier can return $null and you want the script to continue without halting, then that's not going to be possible with that naming scheme.
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Feb 2006
Posts: 546
Fjord artisan
|
Fjord artisan
Joined: Feb 2006
Posts: 546 |
The limitation is that this will always halt if nothing is returned. If that's okay with whatever your script is doing, then it isn't a problem. But, if there are times with the identifier can return $null and you want the script to continue without halting, then that's not going to be possible with that naming scheme. you can actually call it normally with $/$identifier - that / can be ~ or . or a character combination that resembles a valid command prefix such as /. or // or /!. etc. speaking of which, perhaps one day Khaled will let us overwrite internal identifiers (again?) :P oh, and you can also call it as a command in the usual way: $!identifier. but who would use this style of naming?
"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
Ah, I see. So then it's possible to name it with $ and use it "normally". I don't think it's worth doing, but it's possible.
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
OP
Fjord artisan
Joined: Apr 2003
Posts: 342 |
I need to point out that $$ did NOT halt execution in mIRC 6.2 or w/e. That's the bug. I really think that $$ causing execution to abruptly halt without any notification is really quite dangerous. you can actually call it normally with $/$identifier - that / can be ~ or . or a character combination that resembles a valid command prefix such as /. or // or /!. etc. Then why does $$ also behave this way? oh, and you can also call it as a command in the usual way: $!identifier. but who would use this style of naming? Khaled would... lol
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Since when did $$ not halt execution? That was its purpose since the construct was made.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
Yeah, I've used $$ to halt execution when something is missing for as long as I remember. I don't know when that was added, but it's been there a very long time.
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Jul 2006
Posts: 4,188
Hoopy frood
|
Hoopy frood
Joined: Jul 2006
Posts: 4,188 |
Hum, $~ident construct will only call the internal function, it will not work for custom alias
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
OP
Fjord artisan
Joined: Apr 2003
Posts: 342 |
$$ would break out of the routine in the past,like calling /return instead of halt. Now it calls /halt.
If you don't believe me go try running that code in version 6. Performs just fine.
Last edited by MeStinkBAD; 29/12/10 01:46 PM.
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
Joined: Jul 2006
Posts: 4,188
Hoopy frood
|
Hoopy frood
Joined: Jul 2006
Posts: 4,188 |
I need to point out that $$ did NOT halt execution in mIRC 6.2 or w/e. That's the bug. $$ would break out of the routine in the past,like calling /return instead of halt I tried on mIRC 6.2, $$ halt.
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
OP
Fjord artisan
Joined: Apr 2003
Posts: 342 |
Explain....
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
Since your /fopen script is large and possibly has something else causing the issue, I set up a short script to show what $$ does and ran it in both 7.17 and 6.35. The results are the same:
alias t1 {
echo -a 1
t2 $1-
echo -a 3
}
alias t2 {
echo -a 2
echo -a $$1-
}
If you use /t1 test with both versions, you get: That shows that it runs through all of the way because there is a $1. However, if you use /t1 in both versions, it only shows: This shows that it halted both aliases because of no $1 when using $$. If it was RETURN instead of HALT, then you'd see: ... where only the $$ line would be skipped. I can change those aliases around so that /t2 will RETURN $$1- and the result is the same, or so that /t2 is called as $$t2($1-) with no $$ being in /t2 at all and the result is also the same. As a comparison, here's how it would work if it doesn't HALT:
alias t1 {
echo -a 1
echo -a : $t2($1-)
echo -a 3
}
alias t2 {
if ($1) { return $1- }
}
Results for /t1: (: is used so it doesn't throw an error about echoing a null value). As you see, with RETURN, it will continue processing even if there isn't a $1. If we change that to HALT, it works like $$ does-
alias t1 {
echo -a 1
echo -a 1- $t2($1-)
echo -a 3
}
alias t2 {
if (!$1) { halt }
return $1-
}
Results for /t1: As you can see from these examples, $$ does HALT the script and associated aliases instead of using RETURN. Most likely, it's something else in the script that reacts differently between versions that is giving you the problem. $$ has acted as a HALT for as long as I can remember... I don't feel like pulling out even older versions to find out when or if it was ever different. Since your last screenshot shows a difference and you used 6.35 and 7.17, my test with those two versions that shows $$ working the same between versions should be enough to show that it's something else in your script that is working differently. However, if you or someone else wants to do the same kind of test in 6.2 or older, feel free.
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
OP
Fjord artisan
Joined: Apr 2003
Posts: 342 |
As you can see from these examples, $$ does HALT the script and associated aliases instead of using RETURN. Most likely, it's something else in the script that reacts differently between versions that is giving you the problem. $$ has acted as a HALT for as long as I can remember... I don't feel like pulling out even older versions to find out when or if it was ever different. Since your last screenshot shows a difference and you used 6.35 and 7.17, my test with those two versions that shows $$ working the same between versions should be enough to show that it's something else in your script that is working differently. However, if you or someone else wants to do the same kind of test in 6.2 or older, feel free. Yes yes okay that's good to know that $$ is next to useless. It's be slightly less useless even if it did act as /return IMO. I don't care about that though. Now explain what I'm experiencing! The script is not that large! You know... could the /debug function actually display script processing information. Why is there no way to access the trace stack? Why isn't there no profiling option? Why is the editor so poor? No language is as complicated as this one. Not one language.
Last edited by MeStinkBAD; 02/01/11 05:06 PM.
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
Joined: Jul 2006
Posts: 4,188
Hoopy frood
|
Hoopy frood
Joined: Jul 2006
Posts: 4,188 |
I can reproduce the problem, which is in fact not a problem. I used this code : #_DEFAULT.PROPERTIES OFF
[start]
[CONST]
SJISSPEC=$mircdir $+ sjis-0208-1997-std.txt
#_DEFAULT.PROPERTIES END
ALIAS __SJISspec { return $readini($script,CONST,SJISSPEC) }
ALIAS DEC2HEX {
var %pad = $len($base($$1,10,16))
if (2 \\ %pad) { %pad = %pad + 1 }
if ($isid) { return $base($$1,10,16,%pad) }
elseif ($1 isnum) { echo -aspe 0x $+ $base($$1,10,16,%pad) }
}
ALIAS HEX2DEC {
if ($left($1,2) == 0x) || ($left($1,2) == U+) { tokenize 32 $right($1,-2) }
if ($isid) { return $base($$1,16,10,1) }
else { echo -aspe $base($$1,16,10,1) }
}
alias import_sjis {
if ($hget(sjis)) hfree sjis
hmake sjis 10000
fopen sjis $qt($__SJISspec)
var %z
while (!$fopen(sjis).eof && !$ferr) {
tokenize 09 $fread(sjis)
inc -s %z
if ($0 > 2) { var %sjis = $1, %utfc = $2, %desc = $3- }
else { var %sjis = $1, %utfc, %desc = $2- }
; if ($+($#,*) iswm %sjis) continue
if ($hex2dec(%sjis) < 128) continue
echo -s %desc - %sjis - %utfc - $feof - $ferr -
if (<doublebytes> isin %desc) { /hadd sjis $hex2dec(%sjis) <doublebytes> }
elseif (<cjk> isin %desc) { /hadd sjis $hex2dec(%sjis) $hex2dec(%utfc) $chr($hex2dec(%utfc)) }
elseif ($left(%utfc,2) == U+) { /hadd sjis $hex2dec(%sjis) $hex2dec(%utfc) $chr($hex2dec(%utfc)) }
}
:error
if ($error) echo -s Error : $error
fclose sjis
} First note that there's a empty line in your big file at the end. This code will show you that in mIRC 6.35, $feof (or $fopen().feof) is 1 after $freading the last non empty line, which cause the while loop to stop. In mIRC 7.17, it correctly read the next line, which is $null and in that case mIRC halt because of a $null value and the use of $$. The commented line in the code is odd, $# doesn't exist which cause an error if you have that warning option enabled, or a line like "if (* iswm %sjis) continue"..
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
$$ is very useful. It's *not* meant for verified parameters, it's meant to verify parameters: The above alias will not run if you don't supply a parameter. This avoids an error message from the server. If you *were* to provide your own error message, you would need to use $1, not $$1. Return or halt doesn't make a difference here, since $$* isn't meant to be used in deep stacks. Halt, however, does make sense in the context of parameter verification, since you would want to halt in this situation:
/kb ialban $1 | kick # $1
/ialban mode # +b $$address($1, 2)
If $$* did /return in the above, you would still perform the kick even if you could not perform a ban, because /ialban would return, not halt the entire stack. That's usually not what you want from a kickban. Similar problems arise when you move parameter verification one alias down the stack, which is commonly done when you refactor larger scripts. Finally, stop complaining. If you don't like the language, go find one you like and use it. mIRC is not complicated-- in fact, it's ridiculously simple. "$$* will /halt if the identifier expands to $null" is a simple rule. I can name hundreds of languages that have orders of magnitude more syntax rules, keywords and semantic gotchas. Java, C++, Scala all come to mind, but it's completely irrelevant. Khaled isn't going to redesign the entirety of mIRC's scripting language just because one person got mad that his bug report wasn't actually a bug and refused to admit it was PEBKAC. If you don't understand a feature, just don't use it. That is simple.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Apr 2003
Posts: 342
Fjord artisan
|
OP
Fjord artisan
Joined: Apr 2003
Posts: 342 |
The additional line at the end of the file was the problem. Thank you. And Argv, $null is an empty string... but it's also an identifier. Take a look at this... //echo -a 1 ; $$+($$chr(32),$$str($chr(32),5)) ; | /echo -a 2 ; $null ; | /echo -a ; $$null ; Result is... I understand it's purpose... but it's behavior is inconstant. And that is because mIRC's parser is inconsistent.
Beware of MeStinkBAD! He knows more than he actually does!
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
What are you expecting the result to be?
$$ will halt the command if there whatever $$ is attached to is NULL. And $null will always be NULL, so $$null doesn't echo in the 3rd echo. That would be expected.
Invision Support #Invision on irc.irchighway.net
|
|
|
|
|
|
|
|