# KScript Editor V1.22 [now V1.22.5]



## Big Bob (May 28, 2007)

*Re: KScript Editor V1.22*

Hey that's great Nils. Does this mean I can remove the 'caveat' about not using 'compact' mode from the V1.5 SIPS manual?

However, are you sure about the probability you quoted? Assuming a good hashing function that produces a nice random distribution from a typical collection of variables, I make it about a 38% chance that 1000 variables will produce a collision. That's quite a ways from the 0.1% chance implied by your one in 1049 statement :wink: . Maybe I made a serious error in my approximation (it wouldn't be the first time :oops: ).

And, speaking of the infamous 'birthday proposition', I remember about 10 years ago or so when Radio Shack (a national consumer electronics chain in the US) peddled some software to all their retailers that required them to ask each customer for the last 4 digits of their phone number, which they then used as a 'key' into their data base. Evidentally, the programmer thought that for each local store, 10,000 keys would allow lots of customers before they would get a hit. But, of course, everytime you would go back to Radio Shack, someone else would now have your number. The store owners were astounded that there were so many collisions; evidentally their programmer had never heard of the 'Birthday Proposition' :D .

Anyway, thanks for the update.

God Bless,

Bob


----------



## Nickie Fønshauge (May 29, 2007)

*Re: KScript Editor V1.22*

Hey Nils,

thanks for the continuing development. 8) 

I sure hope this hash compacting works. The previous compacting scheme has caused me some grievance, when persistent variables got new numbers.

I suppose a collision within the new scheme would result in a "double declaration" error message in K2. Maybe the Editor's Syntax Checker could run a check on this after the compacting has been done?


----------



## kotori (May 29, 2007)

*Re: KScript Editor V1.22*

*Everyone: please download V1.22.1 which fixes the problem pointed out by Bob.*



Big Bob @ Tue May 29 said:


> Hey that's great Nils. Does this mean I can remove the 'caveat' about not using 'compact' mode from the V1.5 SIPS manual?


Hi Bob,
Yes, that's right. Naturally it will never be possible to paste a compact script on top of a non-compacted script so that is still something to take into consideration though.



> However, are you sure about the probability you quoted? Assuming a good hashing function that produces a nice random distribution from a typical collection of variables, I make it about a 38% chance that 1000 variables will produce a collision. That's quite a ways from the 0.1% chance implied by your one in 1049 statement :wink: . Maybe I made a serious error in my approximation (it wouldn't be the first time).


No, I was wrong and you are right. Actually I posted the link in hope that someone would double-check my results. The problem was that I misunderstood the "exp" button on the windows calculator and didn't have much time to fiddle with it (it seems it's only about specifying a certain power in the current base, whereas I initially thought it was the e^x called exp(x) in many programming languages), so I used the simple formulae instead and got bitten by the rounding errors. I should have antipicated that. :oops: 
Anyway, I changed the code so that each compacted variable name character contains 6 bits of information instead of 4. This brings the collision probability for 1000 variables down from 38% to 0,05%.

The Radio Shack anectote was funny :lol: 



> Anyway, thanks for the update.


Thanks for the math update :wink:

Cheers,
Nils


----------



## kotori (May 29, 2007)

*Re: KScript Editor V1.22*



Nickie Fønshauge @ Tue May 29 said:


> I suppose a collision within the new scheme would result in a "double declaration" error message in K2. Maybe the Editor's Syntax Checker could run a check on this after the compacting has been done?



Hi Nickie
A collision would generate an internal error and you would get a message when you close the editor to review the error log file. The reason I don't display a message directly is because the situation is very unlikely to occur and all other errors has an associated line of code which is not the case for collisions so it didn't fit well into the error reporting system. The important thing to note here is that you will not get a "Sucessfully compiled" message if there are any collisions, so when you do get that message you can be sure there were no problems with collisions.


----------



## Nickie Fønshauge (May 29, 2007)

*Re: KScript Editor V1.22*



kotori @ 29th May 2007 said:


> A collision would generate an internal error and you would get a message when you close the editor to review the error log file.


Hi Nils,
I never read the log file, when I get one of those error messages. They happen quite frequently. I guess I better start taking notice of the log file now, then :wink: 

It is OK, that I don't get a "Sucessfully compiled" message, but that doesn't tell me what the problem is, and it certainly doesn't tell where it is. I'd have to close the Editor to get that information, and then reopen it to deal with the problem.



kotori @ 29th May 2007 said:


> The reason I don't display a message directly is because the situation is very unlikely to occur and all other errors has an associated line of code which is not the case for collisions


Wouldn't the associated line be the second declaration of the same (hashed) variable?


----------



## kotori (May 29, 2007)

*Re: KScript Editor V1.22*

Hi Nickie,
Actually connecting the error message to the UI seemed to take less time than to argue :mrgreen: , so I did this and uploaded the updated V1.22.1 on top of the earlier one. In practice I don't think this will make much difference though since if I've done my math right this time it's not likely that anyone will experience this problem. But I guess that doing it the right way doesn't hurt.

Cheers,
Nils


----------



## Nickie Fønshauge (May 29, 2007)

*Re: KScript Editor V1.22*



kotori @ 29th May 2007 said:


> In practice I don't think this will make much difference though since if I've done my math right this time it's not likely that anyone will experience this problem. But I guess that doing it the right way doesn't hurt.


Hi Nils,
You are probably right. What I was a little bit worried about, is the scenario that I use it for a long time without running into a collision (thus getting my wits dulled (not very hard to achieve :mrgreen: )), and then someday - out of the blue - hit the nasty 0.05%. If I neither got an error message nor a "Sucessfully compiled" message, I am sure I would go "Hey, what's up? Why isn't anything happening?" and waste a lot of time, before it dawned upon me, what was going on.

Thanks for not putting my wits to the test.


----------



## Big Bob (May 29, 2007)

*Re: KScript Editor V1.22*

Hi Nils,



> Anyway, I changed the code so that each compacted variable name character contains 6 bits of information instead of 4. This brings the collision probability for 1000 variables down from 38% to 0,05%.



That's great Nils, in fact I was going to suggest something like hashing to 5 characters (including upper & lower-case letters, digits, etc. But just out of curiosity, aren't there only 63 allowable characters that can be used (ie not quite 6 bits per character)? I presume you were just simplifying your explanation. If we really had five 6-bit characters (or a 30-bit hash function) the probability of a hit would be about 0.045%, whereas with 63^5 = 992,436,543, the probability of a hit would be almost exactly 0.05% as you quoted. Or am I guessing all wrong here?

For comic relief, (assuming I've got the picture right), there is always the possibility that in the future NI might just add a new 'built-in variable having the form $XXXXX. The 'probability' of this is 'probably' quite low but, with NI, it may almost be a certainty (p -> 1.0) :D 

BTW Since the idea of compact mode is to reduce the total number of characters, have you thought about using only 4 (besides the prefix of course)? This would increase the probability of a collision to less than 3.2% (for a script with 1000 variables) but that may still be acceptable, especially with a suitable error message. After all it's not a big deal for the programmer to make a slight change to a variable name once in a while (on average once per 30 very large scripts). Just a thought.

In any case, I'm thinking of editing the V1.51 SIPS manual to say that compact mode can be used for the initial 'fresh' compilation *and *subsequent 'auto updates' provided we use V1.22.1 or higher of your editor. Is that your intention? I guess scripters that wanted to use persistent variable buffereing to let users update scripts at the source level, but didn't want to completely 'expose' their source code files in a user-friendly way, will then be able to distribute the K2-Ready source instead of the NL Source?

Thanks again Nils for this wonderful script-writing tool.

God Bless,

Bob


----------



## kotori (May 29, 2007)

*Re: KScript Editor V1.22*

Everyone:
I heeded Bob's suggestion to make the compacted names four characters long instead of five and made the compiler detect potential collisions with not only user-defined but also builtin ksp variables. *Download* V1.22.2. 
Sorry about the many changes, I think this one will be the last change to the new compaction scheme. 

Hi Bob,
It's always a joy to read your insightful comments. Yes, I simplified a bit above. It's quite annoying that the number of characters allowed in variable names is only 63 when 64 is needed. In lack of a better solution what I did was to add "__" (double underscore) as the 64th symbol. What I do for each variable name is to compute a sha-1 digest on the whole name (including the prefix) and then use the lowest 6 bits from each of the first five bytes and map these numbers to the 64 different symbols. This can all be nicely expressed in two python lines: 8) 
``*def* compress_variable_name(name): 
````symbols = tuple('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_') + ('__',)
````*return* ''.join((symbols[ord(ch) & 0x3F] for ch in sha.new(name).digest()[:5])) 

_"In any case, I'm thinking of editing the V1.51 SIPS manual to say that compact mode can be used for the initial 'fresh' compilation and subsequent 'auto updates' provided we use V1.22.1 or higher of your editor.
Is that your intention?"_
Yep, that's exactly the purpose of this update (ie. to make persistance easier, not to make manuals out-of-date o ). 

Cheers,
Nils


----------



## Big Bob (May 29, 2007)

*Re: KScript Editor V1.22*

Hi Nils,

I really didn't expect you were going to change anything because of my humble comments but, I'm glad you did :wink: . The scheme you have settled on 'Works for Me' as they say :D . Your double underscore character is very clever 8) I should never have thought of using it because I would have wrongly assumed there would problems with ambiguity. But after thinking about it a while, since you never have to do a reverse conversion, there shouldn't be any problem. Of course one 'terrible' side effect is that with 1000 variables, on the order of 15 or 16 extra characters will be used :lol: .

I guess another way of getting sort of a 'free' 64th character would be to use one of the 64 codes as 'null'. For example if the 6 bits were 000000 then you could generate 'no character'. This would have the advantage of generating some shorter names (but never *longer* than 4 characters). Of course this scheme suffers from the fact that there would be one chance in about 16 million that all 4 characters might be nulls. In that case the compacted name would be reduced to $ by itself (or %) so your editor would have to detect this and perhaps treat it as a collision. The other potential problem here would be built-in variables such as %CC but, presently I think that's the only one that's less than 5 characters. BTW I'm just thinking out loud here not suggesting any more changes.

Python must be a pretty 'spiffy' language, but then I'm easily impressed by anything higher-level than machine code :lol: (I say that because I spent so many miserable hours programming embedded apps using the 'toggle-switch' method, that I was just thrilled when I could get my hands on something like a symbolic cross-assembler :roll: . On the other hand, look how much more we can get done with the right tools, no?

Have a great day my friend,

God Bless,

Bob


----------



## Dynamitec (May 29, 2007)

*Re: KScript Editor V1.22*

Hi Nils!

I just wanted to let you know that this is a really great update! This is one of the most useful new features the last time. 

I hope i have more time for the forum when finished with my guitar library. :? I don't have much time at moment since i'm working on other projects as well.

Thank you very much for the great work!

=o


----------



## kotori (May 30, 2007)

*Re: KScript Editor V1.22*

@Bob:
I hadn't thought about the null character possibility. That's a cool idea too. Things are good as they are now though, so I won't change anything.
 
@Frank: 
Thanks a lot!

@Benjamin:
I didn't know this update would be so useful to you Benjamin. I'm glad to hear that. I hope the guitar lib development is progressing smoothly.

To everyone:
I just wasted 30 minutes trying to find a bug which was caused by the empty-if-statement bug. Because of this I added an extra check during the compilation phase, so that scripts susceptible to this problem generate an error message: _"Warning: due to a ksp bug an empty if-statement is equivalent to invoking the exit function. Please make sure the body of your if-statement is not empty."_. I uploaded an updated V1.22.2 on top of the earlier one. No other changes. Btw. the ksp bug above only affects the if-part and not the else-part. I checked this.


----------



## Big Bob (May 30, 2007)

*Re: KScript Editor V1.22*

Hi Nils,



> To everyone:
> I just wasted 30 minutes trying to find a bug which was caused by the empty-if-statement bug. Because of this I added an extra check during the compilation phase, so that scripts susceptible to this problem generate an error message: "Warning: due to a ksp bug an empty if-statement is equivalent to invoking the exit function. Please make sure the body of your if-statement is not empty.". I uploaded an updated V1.22.2 on top of the earlier one. No other changes. Btw. the ksp bug above only affects the if-part and not the else-part. I checked this.



If memory serves me correctly (which it probably doesn't :? ), empty case statements, or something related to the 'select' construct also suffer from this problem. Because of this NI bug, I started including a NOP function in all my scripts some time ago. Then, whenever I encounter a situation where I have an empty 'if' clause, I simply insert a NOP call. For example:

if abc > 0
NOP
end if

where: 

function NOP
x := x { any variable in your script }
end function

BTW regarding the new 'compact' mode. It will only be useful for new scripts (or new versions of old scripts for someone just starting to use it). If someone has already been using a prior version of a script and has customized presets, etc, they can't be carried forward to the latest version without retaining the old source code format. But, from here on for new scripts it will be cool.

God Bless,

Bob


----------



## kotori (May 30, 2007)

*Re: KScript Editor V1.22*



Big Bob @ Wed May 30 said:


> If memory serves me correctly (which it probably doesn't :? ), empty case statements, or something related to the 'select' construct also suffer from this problem.


I tried some cases with empty while loops and case statements, but I've only been able to see the problem in relation to empty if-statements. If you can find another example, please post it and I'll add a check for it. Btw. the check I did add is part of the "Extra syntax checks" option so this must be activated for it to have any effect.


----------



## Big Bob (May 30, 2007)

*Re: KScript Editor V1.22*

HI Nils,

How about something like this:

*on init*
``*declare* ui_value_edit CX (0,10,1)
``*declare* ui_label Info (3,6)
````set_text(Info,'')
``*declare* MapX
*end on*

*on note*
``MapX := 0
``*select* CX
````*case* 3
``````MapX := 18
````*case* 4
````*case* 5
``````MapX := -6
``*end select*
``add_text_line(Info,MapX)
*end on*

Setting CX to 4 should output a 0 but does nothing. Thus, I think the 'empty case 4' also acts as 'exit', no? I'll try to dig through my old notes to see if I can find anything else like this (seems like I also remember a 'while-loop' situation that gave me a problem at one time).

Have a beautiful day my friend,

God Bless,

Bob


----------



## kotori (May 30, 2007)

*Re: KScript Editor V1.22*

Thanks Bob. The "extra syntax check" mode of the compiler now also detects and reports the empty case case.  
I uploaded the updated installer on top of the previous V1.22.2.


----------



## Thonex (May 30, 2007)

*Re: KScript Editor V1.22*

Thanks Nils!!!!! 

This is Awesome!!!!!

And Bob.... oh my... o-[][]-o .... a big "cheers" to you for hashing out this compacting riddle (pun intended  )

What a very interesting read this thread was... it was like a ballet.

Thanks again everyone for all your hard work.... and especially Nils for the best Music scripting editor in the world ( think that's a relatively safe statement to make  )

Cheers,

T


----------



## tfishbein82 (Jun 1, 2007)

*Re: KScript Editor V1.22*

Am I stupid? How come I can't find the navigation panel?


----------



## kotori (Jun 1, 2007)

*Re: KScript Editor V1.22*



tfishbein82 @ Fri Jun 01 said:


> Am I stupid? How come I can't find the navigation panel?



Not at all. It's not very clear at the moment. I should probably add an option to display it to make it easier. To display it you grab a handle very near to the left side of the window and drag it to the right. The navigation panel is there to the left, but if you cannot see it it's because it has zero width, so you have to expand it.


----------



## tfishbein82 (Jun 1, 2007)

*Re: KScript Editor V1.22*



kotori @ Fri Jun 01 said:


> tfishbein82 @ Fri Jun 01 said:
> 
> 
> > Am I stupid? How come I can't find the navigation panel?
> ...


Sweet! Thank you.


----------



## kotori (Jun 2, 2007)

*Re: KScript Editor V1.22 [now V1.22.3]*

Hi everyone,
I released version 1.22.3 of the editor, downloadable from here.

_Changes:
* Better auto-completion (invoked using Ctrl+Space)
* Better call tips (invoked using Ctrl+Shift+Space)_

I uploaded a short http://nilsliberg.se/ksp/screencast/screencast_editor_1.html (demonstration) of auto-completion, call tips and the navigation panel.

Details:
At the time _import_ and _family_ was introduced the auto-completion and call tips unfortunately became somewhat confused and wouldn't fully work in many cases. Instead of doing a full analysis of what's declared and where it is declared I resorted to a simpler and commonly used way to handle this by just analysing what names are actually used in the script. So if you type _myfamily.speed_ at some place in your script you can now type _myf_ and then Ctrl+Space to have it auto-completed (a list of options is presented if there are multiple ways to complete it). A good thing with the new version is that if a variable has been imported from another script module it will be available for code completion after you use it for the first time. Please note that the editor updates the analysis every tenth seconds or each time you press <enter> at the end of a line starting with 'declare'. It's not perfect, but I think it will be a lot more useful than the way the previous version worked. Furthermore the call tips have been extended to also cover user-defined functions (although it doesn't yet include functions in imported modules).


----------



## Big Bob (Jun 2, 2007)

*Re: KScript Editor V1.22 [now V1.23]*

Hi Nils,

Thanks again for the update, this tool just keeps getting better and better :D .

BTW Is it supposed to be V1.23 or V1.22.3?

God Bless,

Bob


----------



## kotori (Jun 2, 2007)

*Re: KScript Editor V1.22 [now V1.22.3]*



Big Bob @ Sat Jun 02 said:


> Thanks again for the update, this tool just keeps getting better and better :D .
> 
> BTW Is it supposed to be V1.23 or V1.22.3?



Oops. It was supposed to be V1.22.3. I edited the post above to fix it. Thanks! 
Btw. two other things fixed were duplicates in the auto-completion list and upper and lower case letters being treated differently when sorting the completion list.


----------



## Big Bob (Jun 4, 2007)

*Re: KScript Editor V1.22 [now V1.22.3]*

Hi Nils,

I was in the process of revising the User's Guide for SIPS to expand on the discussion of the Compact Compiler Output mode. As a result, I had an opportunity to use the compact mode on SIPS and, wouldn't you know it, there was a collision :o .

It wasn't as easy as I thought it would be to track it down and fix it. As a result, there are two improvements I'd like to ask you to implement if they aren't too difficult.

1. Instead of just reporting the collision line number, could you also report the module name as you do for syntactical errors?

2. Since the source line causing the trouble is apparently known, it seems like the source-form of the offending symbol must also be readily available. If so, it would be quite helpful if the pre-hashed form of the identifier could also be displayed.

Perhaps if you can find a little time, you could try compiling V150 of either the SLS or the SVS (they both have a collision), and experience first hand what's involved in tracking one down in a modest-sized script. It turns out that the offending identifier was defined in a fairly-easy area to spot and was only used about 3 or 4 places in all the modules. Otherwise the whole process might have been a lot more onerous :? . In any case, after going through the process, I think we'll need (and will greatly appreciate) all the help we can get from the collision report :wink: .

God Bless,

Bob


----------



## kotori (Jun 5, 2007)

*Re: KScript Editor V1.22 [now V1.22.4]*

I forgot some debugging code which increases compilation time for really large scripts. This is now fixed and I replaced the earlier version with the fixed version, but I noticed in the http://nilsliberg.se/ksp/download_stats.txt (download statistics) that one person had already downloaded the unfixed one. Please re-download.

_Edited to add:_
According to my calculations the collision probability reaches 50% for scripts with approximately 6800 variables (not lines). To get more confidence in the calculations and my current implementation I generated 10 scripts with 6800 variable declarations, each with a random name. Upon compilation I got a collision in exactly five of the ten scripts. So theory and practice seem to align nicely judging by these tests.


----------



## Big Bob (Jun 6, 2007)

*Re: KScript Editor V1.22 [now V1.22.4]*



> Edited to add:
> According to my calculations the collision probability reaches 50% for scripts with approximately 6800 variables (not lines). To get more confidence in the calculations and my current implementation I generated 10 scripts with 6800 variable declarations, each with a random name. Upon compilation I got a collision in exactly five of the ten scripts. So theory and practice seem to align nicely judging by these tests.



That's great Nils. The problem with just relying on theory is not so much that the theory is suspect but that our application of it may introduce errors :oops: . So, it's always comforting to obtain empirical evidence that corroborates our theoretical assertions 8) .

BTW using V1.22.4 of the editor, SIPS V1.50 no longer produces a hashing collision. I don't really know how many variables SIPS uses but I was rather surprised when a collision occured (with a theoretical probability of 3% for a 1000 variables). But, then I just thought it was Murphy's Law at work :wink: . Knowing that the actual probability was more like 38% for 1000 variables indicates that maybe I wasn't quite as 'unlucky' as I first thought :D .

Anyway, many thanks again for this very useful tool and all your hard work in producing it.

God Bless,

Bob


----------



## kotori (Jun 14, 2007)

*Re: KScript Editor V1.22 [now V1.22.4]*

Hello everyone,
I added variable families to the left side navigation panel (screenshot). You can download 1.22.5 from the script editor web page.

Btw. it seems that variable names which consist of only numbers, eg. $123, are not modified by the 'compact output' option. There's no real good reason for this but I don't plan to change it now since the code compaction is working fine in every other regard. It might be good to know of though.

Cheers,
Nils


----------



## Big Bob (Jun 14, 2007)

Hey Nils,

The new Family navigation feature will be *very* useful. I can't tell you how many times I hunt through the initialization block to find a lone family in a sea of declarations.

I'm also glad you aren't going to fix the $123 thing because otherwise I would have to again revise the SIPS manual discussion :( . Besides I suspect such identifiers are already fairly short (maybe even shorter than what you would replace them with? :wink: ).

Thanks again for a tool that just keeps getting better all the time. I hate to even *think* about how it would be with just notepad (or worse yet the KSP editor itself :cry: ).

Have a beautiful day my friend.

God Bless,

Bob


----------



## kotori (Jun 17, 2007)

Hi,
I'm thinking about creating an Intel Mac package for KScript Editor. The universal binary version of the user interface library I use for the editor is so far only available for Tiger (there's an inofficial test version available for Panther though, so hopefully it won't be too long). So I'm wondering: is there an interest for an Intel Mac version and how many use Tiger and how many Panther?


----------



## Big Bob (Jun 19, 2007)

Hey Nils,

I have a new feature request for your editor. Would it be difficult to add some kind of conditional compilation directives? The KSP pre-processor directives have some strange quirks and, even when they work, they of course still leave all the code lines present (the KSP just doesn't execute the excluded blocks, is that not so?). Since the KSP seems to slow down so much as the number of code lines increase, one would like to remove the unused lines of code. I have several applications that would benefit greatly from this feature and other scripters may also find it generally quite useful.

I realize one can write several variations of a given module but it would be more elegant if the importing script could specify which variations it wanted by simply setting a few switches so that one module covers the waterfront.

If this kind of thing isn't too difficult to do, I vote for adding it to the To-Do List  

Have a great day my friend,

God Bless,

Bob


----------



## kotori (Jun 20, 2007)

Hi Bob,
Yes, that would indeed be useful. I think the cleanest way of implementing it would be to optimize statements using conditions (if / while / select). Eg. a statement like if "($constant = $function_parameter)" would automatically be removed in case the equality doesn't hold after functions have been inlined. It would probably not be too hard to test very simple expressions this way if it weren't for the fact that KSP goes haywire when it sees empty if statements. So if one if statement contains another one and the inner one is optimized away one needs to make sure the empty if statements are removed and not just reported as errors.

I have experimented with outputting compiled code from the AST built during the 'extra syntax check' phase. This seems to work well, but I need to implement some general code for modifying the tree. I'll see what I can do. This approach is the most general since I would then be able to handle all kinds of expressions, but the downside is slightly increased compilation time. 

With the above approach one couldn't have conditional imports. Do you think that would be a problem?

Cheers,
Nils


----------



## Big Bob (Jun 20, 2007)

> With the above approach one couldn't have conditional imports. Do you think that would be a problem?



HI Nils,

No I don't think the lack of conditional imports would be devastating provided there is some way (using the new conditional compilation directives) to allow control of what variations of a module are 'loaded' (ie made available for calling). I'm sure whatever you cook up will be quite useful 8) . I'm just glad to hear you'll at least consider doing this.

Have a Great Day My Friend,

God Bless,

Bob

EDIT: Regarding the empty 'if clause' deal, if you can put some of the burden on the user by requiring that we take certain steps to insure that 'if clauses' cannot become empty, that would be fine. Since this new facility would probably only be used by reasonably-sophisticated scripters, having some rules to follow should be quite acceptable, especially if it reduces the effort for you to include this new feature.


----------



## kotori (Jun 20, 2007)

Big Bob @ Wed Jun 20 said:


> Would it be possible to have a variant of Compact Compiler Output that would strip all the comments, jam everything against the left margin, and all the other good stuff you do now but leave the K2 identifier names uncompressed?


Yes, that would be possible. In fact, it's http://nilsliberg.se/ksp/setup-kscript-editor-1.22.6.exe (already done). :wink:
It's now possible to compact the code and not the variable names, but not vice versa.


----------



## Big Bob (Jun 20, 2007)

Wow! o/~ o=< 

Like the US Marine Corps, 'The difficult we do immediately, the impossible takes a little while' :wink: . 

I gave it a quick check and as far as I can see it works just fine. However, do I understand correctly that when Compact Output is off, the Compact Names option has no effect (whether on or off)?

Thanks a million for the fast turnaround, we're really blessed to have you with us.

God Bless you my Friend,

Bob


----------



## kotori (Jun 20, 2007)

Big Bob @ Wed Jun 20 said:


> However, do I understand correctly that when Compact Output is off, the Compact Names option has no effect (whether on or off)?


Hi Bob,
Yes, that's correct. To make this clearer I now deactivate the second option when the first isn't selected. I uploaded an updated 1.22.6 on top of the other. It's not a very important change so it's really necessary to redownload it since it'll be included in the next version as well.


----------



## Big Bob (Jun 21, 2007)

Hi Nils,

Many thanks again :D . It was OK the way it was but the way you changed it will be less ambiguous to a new user.

BTW I don't know how long ago you added the F6, Recompile last script, feature (probably when you added the multi-script stuff?), but first now I noticed it :oops: . This is a really useful feature when working on a main script that uses importable modules. Maybe for the benefit of unobserving individuals like me, someday you ought to generate a comprehensive list of all the wonderful features included in the KScript Editor. I'll bet there are any number of goodies that some of us haven't yet tumbled to :o .

Have a wonderful day Nils,

God Bless,

Bob


----------



## Dynamitec (Jun 21, 2007)

I just want to step by and say thanks Nils! Great you still improve KScript Editor! =o If only NI would do so many great updates and listen to their users like you do!

@BigBob: Did you get my mail? Sorry again, i was ill!


----------



## Big Bob (Jun 21, 2007)

Dynamitec @ Thu Jun 21 said:


> I just want to step by and say thanks Nils! Great you still improve KScript Editor! =o If only NI would do so many great updates and listen to their users like you do!
> 
> @BigBob: Did you get my mail? Sorry again, i was ill!



No Benjamin, I didn't get any email from you. Sorry to hear you were sick, are you OK now?

God Bless,

Bob


----------

