|
|
|||||||
http://www.scriptlogic.com/kixtart/ |
||||||||
|
|
|||||||
Ruuds latest information about this release candidate quote:Take also a close look at http://www.scriptlogic.com/KiXtart/DevReport.asp page. greetings. [ 30 May 2002, 15:18: Message edited by: MCA ] |
||||||||
|
|
|||||||
I especially like the Explicit and NoVarsInStrings options. We should make those two default for every script since it will cut down on script debugging and provide cleaner code. |
||||||||
|
|
|||||||
Having already admitted to being a huge "VarsInStrings" fan myself, Im going to go out on a limb here and suggest that using vars in strings is actually "faster" than specifing "NoVarsInStrings" and doing the string math seperately ... anyone ? -Shawn Jens, Im just stirring the pot [ 30 May 2002, 16:44: Message edited by: Shawn ] |
||||||||
|
|
|||||||
I too, am guilty as charged. Does this include macros in strings? Use "H:" "\\server\@UserID$$" |
||||||||
|
|
|||||||
Dear Les, Just try it. greetings. |
||||||||
|
|
|||||||
Perhaps misunderstood. Not a question of RC2 but rather of Shawn's comment. Old way: Use "H:" "\\server\@UserID$$" New way? Use "H:" "\\server\"+@UserID+"$$" |
||||||||
|
|
|||||||
Les, Jens, yeah I was wondering about that too. I would have guessed that macros would have been included in this, but I just tried a test script here, and even if one specifies "NoVarsInStrings", macros DO still get expanded inside strings. guess they're special. Getting back to the "faster" thingy, I was running some benchmarks here and found that specifying $vars in strings is actually about 30% to 50% faster than doing the string math (say over about 50,000 iterations). However, that may be because of all that "special", "funky" code that Ruud had to put into Kixtart on day-one, to handle these strings. Code that Ruud has previously mentioned, he would like to "strip out" of Kixtart, if he could. So maybe we're not comparing apples-to-apples here. Plus, more to Jen's point, we haven't mentioned any gains associated with maintainability and readability when using NoVarsInStrings. -Shawn [ 30 May 2002, 17:39: Message edited by: Shawn ] |
||||||||
|
|
|||||||
Macros-inside-strings are indeed not affected by the 'NoVarsInStrings' option. I'm working on a separate 'NoMacrosInStrings' option, but it won't make it into 4.10. There are a couple more options like these that I may add in the future. Eventually, I hope to add 1 'global' option (e.g.: 'PureSyntax') that would enable/disable all options at once. Cheers, Ruud |
||||||||
|
|
|||||||
Dear Ruud, Great job and great ideas. Thanks, greetings. |
||||||||
|
|
|||||||
Cool, I can then label my scripts as 'Pure KiXtart Inside' and even get a decal for it |
||||||||
|
|
|||||||
Well, if there is one thing I've learned here over the years, and at the risk of sounding like I'm sucking-up to the big guy: "In Ruud We Trust" Actually, since your just "thinking" about this new option setting, how about something like: $= setoption("strict","on") and that would enable all these stricter language settings at once ... anyways, cheers to you as well. -Shawn |
||||||||
|
|
|||||||
If strict=on would mean bypassing some of the 'liberties' that we use in our (my) sloppy coding, to give us the benefit of faster execution... I'm all for that. But considering the power and overall ease of Kix, even sloppy coding will ever be considered bloatware... Even if Ruud works for MS (do you think he could give a class to the guys writing Office?) |
||||||||
|
|
|||||||
I propose that negative option be applied. Otherwise, the default is still "legacy on" and so it'll be around forever. $_= SetOption("Legacy","on") ;off by default |
||||||||
|
|
|||||||
Rad, agreed, it was because Kixtart was light-weight, free-format and syntactically liberal and forgiving, that first attracted me to her in the first place. And that has kept me interested over the years ... Kixtart was and still is, a pure joy to work with. -Shawn |
||||||||
|
|
|||||||
Ok.. I'll tell you what. You guys work with WSH VB script for a few days trying to do the same things you do here with KiXtart, and I think you will soon see why we love KiXtart so much. In WSH VB Script you get (function, expression, compile, etc...) errors ALL the time. Quite a pain in the but to work with it compared to KiXtart. Sorry guys. I LOVE THE SLOPPY CODE If KiX goes the way of WSH, I might as well use WSH. |
||||||||
|
|
|||||||
Amen to that Doc ! For the casual developer, VBS can be the most frustrating, want-to-just-chuck-it-out-the-window kinda language ! My Grandmother used to have a term for this, she would have classified VBS as "Persnickity" !!! ... KiXtart is definitely not "Persnickity" On another note, I've decided to start using this NoVarsInString option, is this how its done ? break on $option = "NoVarsInStrings" $setting = "on" $= setoption("$option","$setting") exit 1 -Shawn [ 31 May 2002, 02:30: Message edited by: Shawn ] |
||||||||
|
|
|||||||
Shawn, Are you being a wise guy? tsk tsk tsk |
||||||||
|
|
|||||||
yeah les - i'm just fun'n - isn't it amazing how a guy can get so worked-up and passionate over a scripting language ? -Shawn |
||||||||
|
|
|||||||
Know what you mean. Kinda torn between the "loose, sloppy, whatever" coding of KiX and more "strict, rigid" format of the other languages EH!. Most of us like rules. Even if just to see how far we can bend them. I can see Ruud's side on this. Having to keep all this legacy support in must take some effort and must make additions more convoluted. To Ron's comment, at the end of the day, it's not the strictness of the code but rather the functionality (or lack thereof) that will make (break) KiX in the end. Well... that and the 'pointy-haired Suits ' making the decisions. |
||||||||
|
|
|||||||
Ok Les, As long as you still love us. pointy hair? I have none, but around here most of the pointy haired ones are the Asian kids like my step son. hehehe |
||||||||
|
|
|||||||
DOC, Please don't tell me you crawled out of the trenches and put on a suit. I once worked for a pointy-haired boss that thought that "motivational screensavers" would be a good way to raise morale (and productivity) at a call centre. After I begrudgingly installed them, at some expense I might add, productivity fell way down. The sudden realization that "screensavers only work when others don't " weighed like an uncomfortable silence. Sometimes there's no pleasure in proving oneself right. |
||||||||
|
|
|||||||
I put on a suit once (I think) No, I'm a peon worker Have to report to my boss who is 3,000 miles away. Weird how that works. LES Don't tell me you're a TREE CHOPPER... Where's a good Environmentalist when you need one. [ 31 May 2002, 04:01: Message edited by: NTDOC ] |
||||||||
|
|
|||||||
One thing to keep in mind with this release... The KX16.DLL and KX32.DLL do need to get upgraded with the W9x Clients as there is a version change with this release. - Kent |
||||||||
|
|
|||||||
if you are still running win9x, then you deserve all the headaches you get from trying to run/upgrade to other things. You should have win9x, office97, IE5, and whatever work apps you require. no more of this upgrading stuff for those Pentium machines. |
||||||||
|
|
|||||||
Dear Radimus, Indeed it isn't always necessary to upgrade to a newer release, but the major thing in previous release was the introduction of - user defined functions - COM technology This release introduces - different kind of variable types f.e. the REAL ones. greetings. |
||||||||
|
|
|||||||
2 cents on KX32 and kx16.DLL: updating is optional, but if you do, you must update both. Ruud |
||||||||
|
|
|||||||
Ruud, If Updating is optional, do I miss functionality if I use the 3.60 dll's??? |
||||||||
|
|
|||||||
All the new KX32.DLL does is ensure that KX16.DLL will be loaded from the same directory as where KX32.DLL was found. This makes it possible to run (for testing-purposes) multiple versions of KiXtart side-by-side and also prevents problems when 'rogue' copies of KX16.DLL are present on a system. Otherwise, no new functionality was added. Regards, Ruud |