Page 2 of 2 <12
Topic Options
#159819 - 2006-08-22 12:05 AM Re: Erroneous Macro Results
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
syntax error is a error and then it's obvious for it to throw an error.
not sure why you would want it to misbehave like it now does...

and if the current behavior is not confusing, I don't know what is.
as currently, one needs to re-read the whole script to find mistyped macro without even knowing that he has one.

there is no excuse to leave it like it is.

Top
#159820 - 2006-08-22 12:10 AM Re: Erroneous Macro Results
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
Invalid macros inside strings regardless of SetOption() should simply be taken as literal text. It is unreasonable to expect KiX to determine invalid macros embedded within strings, period. So that leaves only macros outside of strings which should IMHO throw an error. In my opinion, KiX is too forgiving on unquoted (space or non-quote character delimited) strings but that argument is for another day.
Top
#159821 - 2006-08-22 09:05 AM Re: Erroneous Macro Results
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
Quote:

Invalid macros inside strings regardless of SetOption() should simply be taken as literal text. It is unreasonable to expect KiX to determine invalid macros embedded within strings, period.




As I said in an earlier post, KiXtart already determines invalid macros embedded in strings, "period". So how can you possibly consider that unreasonable?

Top
#159822 - 2006-08-22 10:22 AM Re: Erroneous Macro Results
Lonkero Administrator Offline
KiX Master Guru
*****

Registered: 2001-06-05
Posts: 22346
Loc: OK
lol.
Top
#159823 - 2006-08-22 11:53 AM Re: Erroneous Macro Results
Witto Offline
MM club member
*****

Registered: 2004-09-29
Posts: 1828
Loc: Belgium
I think, what Jooel and Les want, is that something between quotes, starting with an @-sign, but definitely no macro, just is a part of a string. Only existing macros in strings should be recognised. This is of course when NoMacrosInStrings is Off.
I do understand that point of view. Maybe it would be better than it works now. But why is KiXtart so forgiving p.e. for
Code:

Break On
+Blablabla


And should it not help recognising a mistyped macro between quotes?
Once again, as long as NoMacrosInStrings is Off.

Top
#159824 - 2006-08-22 01:55 PM Re: Erroneous Macro Results
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
Quote:

I think, what Jooel and Les want, is that something between quotes, starting with an @-sign, but definitely no macro, just is a part of a string.




I understand that, but why bring the handling of invalid macros down to the lowest common denominator? If the processing is to be changed why not take the opportunity to change it so that macros both inside and outside strings will generate an error if they are mistyped?

Consider this bit of code:
Code:
$sMailAddress="helpdesk@service.acme.com"



This is a coding error. If the "@" symbol is intended to be present in the string it should be doubled up "helpdesk@@service.acme.com" - that is the KiXtart syntax.

If the parser is changed to ignore the error then this code will work. But what happens in KiXtart release 4.xx when Ruud introduces the new @SERVICE macro to indicate when a script is running as a service? Oops. It would be better if the programmer had been notified the very first time he tested the script that the string contained an invalid macro. He would have doubled up the "@" and there would be no chance of a namespace clash in the future.

Quote:

But why is KiXtart so forgiving




Backwards compatibility. When KiXtart first appeared it was a fairly simple beast designed to replace BATch files so the syntax was designed to be simple and accomodating. If the parser was made more pedantic now it would break too many existing scripts. Personally I'd be happy with a "Strict" option which disallows some of the easy-coder things like bare strings, multi-line strings and so-on.

Top
#159825 - 2006-08-22 03:19 PM Re: Erroneous Macro Results
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
Well... if there is a single @ within quotes and the chars that follow do not represent a valid macro, KiX should just eat the @ and treat the rest as text if NoMacrosInStrings is OFF. If NoMacrosInStrings is ON, then the @ is part of the string but in either case there should be no validation of the macro and no error thrown. Now outside of quotes with proper concatenation, that is another story.

I agree with the "Strict" principle but it should be on by default and sloppy coders should have to explicitly turn it off. That is how most of the SetOption() switches should be, most strict by default.

Top
#159826 - 2006-08-22 03:48 PM Re: Erroneous Macro Results
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
I guess I'm missing something. Why do you think that KiXtart should not throw an error on a coding error? With NoMacrosInStrings off a single @ in a string is an introduction to a macro. If you're using it for anything else you've made a typo. As I've demonstrated in the somewhat contrived example in the previous post doing anything other than raising an exception is creating the potential for failures in the future.

The only possible problem that I can imagine that erroring on invalid macros might cause is if anyone has added code to check for macro support, something like:
Code:
If "@FOO" = "<unknown:FOO"
"Sorry, your version of KiXtart does not support the @@FOO macro - please upgrade" ?
Exit 1
EndIf


Top
#159827 - 2006-08-22 04:34 PM Re: Erroneous Macro Results
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
I guess what I am saying is that if you want good error checking, you should be forced to use "Strict" coding, meaning concatenation and no embedding crap in strings. If old school embedding is used them old school forgiving code (as in no error thrown) should accompany it.

It's like the old addage... Good, Fast, Cheap... pick any two.

Top
#159828 - 2006-08-22 04:44 PM Re: Erroneous Macro Results
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
Ok, but what is the down-side to throwing an error for an invalid macro name? I can't see one.

The script is going to fail either way, but throwing an error is far easier to diagnose than a script which continues to run but does something odd.

Considering the majority of macros-in-strings scripters are likely to be newbies and Shawn I think that something that's in your face saying "you've typed something wrong here" is much more preferable.

Top
#159829 - 2006-08-22 04:54 PM Re: Erroneous Macro Results
Shawn Administrator Offline
Administrator
*****

Registered: 1999-08-13
Posts: 8611
roflmao...
Top
#159830 - 2006-08-22 05:02 PM Re: Erroneous Macro Results
Shawn Administrator Offline
Administrator
*****

Registered: 1999-08-13
Posts: 8611
You guys should be very proud of me ... I am getting better ... check-out this script bit:

Re: Map drive by user id.

-Shawn

Top
#159831 - 2006-08-22 10:08 PM Re: Erroneous Macro Results
Les Offline
KiX Master
*****

Registered: 2001-06-11
Posts: 12734
Loc: fortfrances.on.ca
LOL
He uses concatenation on a "temporary" marker line to be used to debug and then throw away.

I was going to reprimand him for going off topic in the beta forum but he's as cute as a lamb and I couldn't bring myself to do it.

Just shoot him, damnit... shoot him!

Top
#159832 - 2006-09-30 07:40 AM Re: Erroneous Macro Results
Allen Administrator Offline
KiX Supporter
*****

Registered: 2003-04-19
Posts: 4548
Loc: USA
I'm not sure how practical this is... but here is a stab at making the script exit on a macro error... Maybe in Version 5 there will be no macros as they are now but are accessed through a Macro(Lookup) function.

Code:
break on
$=setoption("Novarsinstrings","on")


? macro("KIX")
? macro("err")




function macro($name)
dim $ms,$,$colors
$ms=setoption("NoMacrosinstrings","off")
$=execute("$" + "macro='@@" + $name + "'")
if instr($macro,"<unknown:")
$colors=split(@color,"/")
color $colors[0]+ / $colors[1]
"ERROR : Unknown Macro [" + $name + "]" + "!"
color $colors[0] / $colors[1]
quit
endif
$ms=setoption("NoMacrosinstrings",$ms)
endfunction


Produces:
Code:
 
4.52
ERROR : Unknown Macro [err]!


Top
#159833 - 2006-10-02 09:21 AM Re: Erroneous Macro Results
Richard H. Administrator Offline
Administrator
*****

Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
That would be better as "Quit nn" where nn is an appropriate error code.

KiXtart uses error "1" (Incorrect function.) for an unknown command which would be fine.

Top
Page 2 of 2 <12


Moderator:  ShaneEP, Arend_, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart 
Hop to:
Shout Box

Who's Online
0 registered and 208 anonymous users online.
Newest Members
Timothy, Jojo67, MaikSimon, kvn317, kixtarts2025
17874 Registered Users

Generated in 0.069 seconds in which 0.025 seconds were spent on a total of 13 queries. Zlib compression enabled.