# New version of my script editor



## kotori (Nov 14, 2006)

Hello everyone,

Sorry for not having been able to hang around more lately. 
Anyway, there's a new bug-fix release of the script editor (V1.16). You can download it from my webpage.
The day after tomorrow I'm going away for three weeks, so if you experience any problems please report them as quickly as possible so that I can try to fix them before I go.

_Fixes/changes_:
 Order of constant declarations - Bob reported some case where two variables were declared in the wrong order in the final script. I'm not completely sure I have covered this now, but I hope so. It works like this: on compilation all constants are moved to the top of 'on init'. First all the ones declared directly inside 'on init' followed by all the ones declared within functions in the order the functions are declared (this order was previously not respected).
 Nested families inside modules imported using a name ("import ... as") didn't work. This should be fixed now.
 Since it seems I may not receive the K2 update before going away and NI announced that there will be a couple of new functions I moved the list of builtin functions and variables out from the code into a text file. It's now possible to add new builtin functions and variables simply by editing the 'ksp_util.txt' file found in the program folder.
 It's no longer possible to pass parameter to the 'on_init' function of a module. This feature wasn't fully working so I decided to deactivate it for the time being.

Lately I've been trying to make a full rewrite of the compiler. It's not yet complete. So far it can parse the whole extended syntax into an abstract syntax tree and regenerate the code from the syntax tree, but thus far there is no function expansion or translation of for-loops and families into regular KSP code. During parsing all syntax errors are detected and reported.

Cheers,
Nils


----------



## Thonex (Nov 14, 2006)

Thanks Nils.... Have a great time wherever it is you're going  

Cheers,

T


----------



## Big Bob (Nov 14, 2006)

Hi Nils,

Really glad to see you back, even if it is for only a few days (wow another 3 weeks, what a bummer :cry: ). Also glad to see you whipped out another NL Editor update but unfortunately, there still seems to be some problems with the 'constants' thing.



> Order of constant declarations - Bob reported some case where two variables were declared in the wrong order in the final script. I'm not completely sure I have covered this now, but I hope so. It works like this: on compilation all constants are moved to the top of 'on init'. First all the ones declared directly inside 'on init' followed by all the ones declared within functions in the order the functions are declared (this order was previously not respected).



Evidentally, the above explanation can't be all that's to it. The attached file which contains a small host test script plus the latest KSP Math Library module, compiles by K2 when I use V1.11 of the NL Editor. However, while it compiles OK with version V1.16, K2 won't take it. Inspection of the K2 source generated by the NL Editor reveals that all the data declared in the on_init_Math routine is totally missing.

So I added a line to the test script at the end of the on init block 'calling' the on_init_Math function. *Up until now this has been unnecessary*. But, when I do this, it now pulls in the defs but they are always placed at the head of on init block no matter where in the on init block I call the function. Also, it doesn't seem to matter whether I put the 'import' line ahead of the on init block or after it. For this particular set of scripts, this is not a problem, but ...

I'm sort of going nuts trying to figure out what order to write declarations in and how to organize them so they will always compile with the NL Editor and then in K2. Maybe you could expand on the above set of rules? The problem for me is trying to find a way to write stuff so it will be handled properly with Vxxx *and up *of the NL Editor. So far I haven't been able to do this. What works for one revision of the editor doesn't seem to work for the next. But, maybe its simply that I don't fully understand how the Editor decides these issues and to what extent I can control the ordering of declarations in the final on init block by how I arrange things.

So, could you please elaborate, it would be most helpful  .

God Bless,

Bob

PS Terrific idea about making the ksp_util.txt file available to us so we can add whatever comes along in the next K2 update, even in your absence. That was indeed very thoughtful of you Nils. You're really a treasure!


----------



## Rodney Glenn (Nov 14, 2006)

Tack Nils. :smile:

Ha en trevlig resa och vistelse.

R


----------



## kotori (Nov 14, 2006)

Thanks everyone.

Bob, I look at this as soon as possible. There's one important change that I forgot to mention: only variables in used functions will be declared. If a function is used purely to define variables it has to be invoked in this version whereas that wasn't necessary earlier. This is to make it possible to make function libraries that don't pollute ones scripts with unused variables. Internally the compiler computes the transitive closure of the function invokations to determine which functions are used (starting with all callbacks).

Cheers,
Nils


----------



## Thonex (Nov 14, 2006)

kotori @ Tue Nov 14 said:


> the compiler computes the transitive closure of the function invokations...



I wish I spoke English as well as you :smile:


----------



## Dynamitec (Nov 14, 2006)

Hi Nils! 
Thanks for the new version. But i have a lot of trouble compiling my old scripts.
For example:

*import* "imports\needed.txt"

_{==========================================================================================================================}_
_{ on init
{==========================================================================================================================}_
*on init*````
````NeededInit 
````*declare* *const* DEMO_MODE := TRUE```

TRUE is a constant i define in needed.txt (function NeededInit) but even if i call NeededInit before declaring DEMO_MODE := TRUE it doesn't work in this release. Kontakt says "DEMO_MODE" not declared.


----------



## Dynamitec (Nov 14, 2006)

I found out more: all constants move to the beginning of on init...but not in the right order. So if i do this: declare const CONSTANT1 = CONSTANT2 it may not work if CONSTANT2 is declared in a function with "global". Even if this function is called before!


----------



## Big Bob (Nov 14, 2006)

kotori @ Tue Nov 14 said:


> Thanks everyone.
> 
> Bob, I look at this as soon as possible. There's one important change that I forgot to mention: only variables in used functions will be declared. If a function is used purely to define variables it has to be invoked in this version whereas that wasn't necessary earlier. This is to make it possible to make function libraries that don't pollute ones scripts with unused variables. Internally the compiler computes the transitive closure of the function invokations to determine which functions are used (starting with all callbacks).
> 
> ...



I sort of figured that might be the situation with needing to actually call the function. Your answer to that part is good news. However, the ordering of constants and whether or not we can control it to some extent is a much bigger issue. I hope you can work out a way that will cover all the usual situations. I really doesn't have to be totally automatic, as long as there is some way for us to exert some control over the ordering so we can make it come out right and, so we don't have to keep revisiting and re-arranging old code that used to compile without complaint.

Boy, are we ever getting picky huh? :lol: 

Remember everyone, it's still 10,000 times better than just using notepad (or worse, the KSP Editor itself :razz: ).

I for one, still love you Nils.

Bob


----------



## kotori (Nov 14, 2006)

Thank you for that report Benjamin and Bob for you comments. I'll try to do something about it tomorrow.

Btw. Bob, I saw I got a mail from you. Thank you for that. It's rather late here now, so I'll answer it tomorrow.

Cheers,
Nils


----------



## Dynamitec (Nov 14, 2006)

Hi Nils, hi Bob!

As Bob said: Of course Nil's Editor is still the number one tool...without Nil's Kscript Editor would be less then half as good as it is right now!


----------



## kotori (Nov 15, 2006)

Hi Bob and Benjamin,
I'm going to make a stab at the constant ordering problem now. I have two ideas about how to do it:
'on init' is scanned recursively (depth-first) for function invokations and a list of functions is built in the order of their first occurance (invokation - not definition). All variables (both constants and nonconstants) are then extracted from the functions in the list and insert at the top of 'on init' in that order.
Make it so that variables declared global must appear in a function which is invoked exactly one directly or indirectly from 'on init'. The declarations would be expanded during function inlining and there wouldn't be any special logic to handle them in the compiler.

I think the first alternative would work in most cases, but it's a bit more difficult to implement than the second choice. With the second alternative it wouldn't be possible to use 'global' declarations as 'static' in C. Apart from that drawback it would lead to a more transparent compiler logic - it would be easier to understand how the compiler works.
Here's an example of what I mean by static:
*function* play(n)
``*declare* global last_note
``*if* n = last_note
````_{ ... do something ... }_
``*end if*
``last_note := n
*end function*
This function would probably be invoked several times which would cause the compiler to complain that the last_note variable is redeclared. Solving it is easy though, just declare last_note in 'on_init' or some similar init function.

Primarily due to the ease of implementation I might prefer the second one. I don't know if the explanation above is easy to understand but it would essentially work the same in both cases, only that with the second alternative all functions containing global declarations (constants and nonconstants alike) would have to be explicitly invoked exactly once.

What do you think?


----------



## Big Bob (Nov 15, 2006)

Hi Nils,



> All variables (both constants and nonconstants) are then extracted from the functions in the list and insert at the top of 'on init' in that order.



The thing that concerns me here is that I can easily think of situations in which the main or host script has some constants defined at the top of the on init block *that should remain on top*. If 'imported' constants always move to the top I think there will be problems. The most desireable way to do this IMHO is to use your idea to compile global defs as the functions declaring them are 'referenced' in the on init block. *But don't move them out of order.* And, to keep it simple, don't allow global defs in procedures that are invoked more than once or outside of the on init block. Alternatively, I guess your compiler could keep track of whether or not the global constant has already been declared and just ignore further re-declarations.

If I want a declaration to be ahead of some others, I would just invoke the function ahead of where those others are declared. If I want them after something, I would just invoke the function after that something, etc.

I think this would fit in with your second proposed method but I'm not sure I fully understood what you were saying. But, since you'll be leaving soon, I didn't want to delay responding. I'll now re-read what you wrote more carefully and if a light comes on and time permits, I'll repost.

God Bless,

Bob


----------



## Dynamitec (Nov 15, 2006)

I thought of a third option:

Why don't use a statment that can be used in on init which is replaced with all declares of the imported modul (if not used it works the way it is at moment)

import "test.txt" as test

on init

declare some_stuff
declare that_should
declare remain_on_top

insert_declares(test)

end on


----------



## kotori (Nov 15, 2006)

Big Bob @ Wed Nov 15 said:


> If 'imported' constants always move to the top I think there will be problems.


Yes, I should've mentioned above that I have abandoned this idea of moving things around.



> And, to keep it simple, don't allow global defs in procedures that are invoked more than once or outside of the on init block. Alternatively, I guess your compiler could keep track of whether or not the global constant has already been declared and just ignore further re-declarations.


Very good points. I arrived at the same conclusion just before reading your reply about keeping track of wether the globals (both constants and variables actually) have been expanded already. I'll use this implementation strategy. The question is still where to place local variables. I guess as long as they are not assigned an initial value on the declaration line it doesn't matter. What do you think, should I place them at the bottom or top of 'on init'? (I don't either alternative will hinder one from writing any script)



> If I want a declaration to be ahead of some others, I would just invoke the function ahead of where those others are declared. If I want them after something, I would just invoke the function after that something, etc.


Yes

Cheers,
Nils


----------



## kotori (Nov 15, 2006)

Dynamitec @ Wed Nov 15 said:


> I thought of a third option:
> 
> Why don't use a statment that can be used in on init which is replaced with all declares of the imported modul (if not used it works the way it is at moment)
> 
> ...



Hi Benjamin,
Don't you think this will be equivalent to declaring the module's variables inside its on_init function and invoking on_init from 'on init' (the main callback)?

Cheers,
Nils


----------



## Dynamitec (Nov 15, 2006)

Ok  Your point...if i think this i why i understand what you meant with your prior post...


----------



## kotori (Nov 15, 2006)

Dynamitec @ Wed Nov 15 said:


> Ok  Your point...if i think this i why i understand what you meant with your prior post...


I'm not sure I understand that sentence... Anyway, to clarify your example would be:

```
import "test.txt" as test

on init
  declare some_stuff
  declare that_should
  declare remain_on_top

  test.on_init
end on
```

That would make all global variables in test be inlined as test.on_init is expanded (assuming that the test.on_init function invokes all functions declaring global variables in that module).


----------



## kotori (Nov 15, 2006)

:arrow: Ok everyone, now there's a release candidate that you can test. You can download it >>http://nilsliberg.se/ksp/setup-kscript-editor-1.17RC1.exe (here)<<.

I hope to get as much feedback as possible. Bob, it seems your test files compile fine with this version. Please experiment a little bit with it.


----------



## Thonex (Nov 15, 2006)

kotori @ Wed Nov 15 said:


> :arrow: Ok everyone, now there's a release candidate that you can test. You can download it >>http://nilsliberg.se/ksp/setup-kscript-editor-1.17RC1.exe (here)<<.
> 
> I hope to get as much feedback as possible. Bob, it seems your test files compile fine with this version. Please experiment a little bit with it.



Nils... you are a machine!!!! :shock: 

I don't know how you do it... amazing... 

Thanks for all your hard work!!

Cheers,

T


----------



## kotori (Nov 15, 2006)

Thanks Andrew!

It seems I rushed this a bit though, it's not working correctly yet. I'll be back in half an hour or a little bit more with a new version.


----------



## Thonex (Nov 15, 2006)

kotori @ Wed Nov 15 said:


> Thanks Andrew!
> 
> It seems I rushed this a bit though, it's not working correctly yet. I'll be back in half an hour or a little bit more with a new version.



Yes please... and if you have 5 minutes after that... could you please solve world hunger? :lol: 

Seriously though.... even though I'm not using some of the advanced features in your editor... I'm truly grateful for all these additions. One day I'll get there...

Cheers,

T


----------



## Big Bob (Nov 15, 2006)

kotori @ Wed Nov 15 said:


> :arrow: Ok everyone, now there's a release candidate that you can test. You can download it >>http://nilsliberg.se/ksp/setup-kscript-editor-1.17RC1.exe (here)<<.
> 
> I hope to get as much feedback as possible. Bob, it seems your test files compile fine with this version. Please experiment a little bit with it.



Still doesn't seem to work right Nils. If you try compiling my little sincos test file, here's how it goes. If you compile it as is, the on_init_Math declarations aren't compiled at all. If you add a line to the end of the on init block in the test script (just before the message clearing instruction) saying: on_init_Math to reference the initialization function, then here's what happens. All the declarations are compiled but there are still put at the very beginning of the on init block (not at the end where the reference to on_init_Math occurs. Except for the *atan* array which is re-declared at the point of reference so K2 then complains that *atan* was already defined.

What I expected to happen was that all the on_init_Math declarations would appear after the ui_control declarations (at the point where I called the on_init_Math function. However, if I were to call on_init_Math ahead of the ui_control declarations, then (and only then) I would expect the on_init_Math declarations to precede the ui_control defs.

I hope this was clear, let me know if not.

God Bless,

Bob


Whoops! I just noticed that you already made a new post indicating trouble in River City. Hopefully, we're talking about the same thing.


----------



## kotori (Nov 15, 2006)

Thanks for the report Bob. I'll do some packing now, and then return to this problem. I noticed that I forgot to remove some of the constant reordering which explains part of the problem. I have not yet really fixed the redeclaration thing, but I think it shouldn't be that hard if I can only find the fault. Stay tuned. (the RC1 is not usable in it's current form)


----------



## kotori (Nov 15, 2006)

:arrow: http://nilsliberg.se/ksp/setup-kscript-editor-1.17RC2.exe (Here)'s a new version with some errors corrected. Please try it out. I noticed that the newest version of SLS didn't compile as it is, but this may be because it doesn't invoke all necessary on_init functions explicitly. Bob's math routines seem to compile and run in K2 though.


----------



## Big Bob (Nov 15, 2006)

kotori @ Wed Nov 15 said:


> :arrow: http://nilsliberg.se/ksp/setup-kscript-editor-1.17RC2.exe (Here)'s a new version with some errors corrected. Please try it out. I noticed that the newest version of SLS didn't compile as it is, but this may be because it doesn't invoke all necessary on_init functions explicitly. Bob's math routines seem to compile and run in K2 though.



Sorry, but she still no fly. Take a look at this simple test script that 'imports' the Math Library.

*import* "KSPMath_V104.txt"

*on init*
``*declare* *const* me := 51
``*declare* *const* you := 15
``*declare* *const* us := 98
``on_init_Math 
``message('')
*end on* _{ init }_

Compile this and then examine what's in the clipboard. All the on_init_Math declares are always put ahead of the 'you' me' and 'us' constants no matter where I place the call to the on_init_Math routine.

Bob

PS I'll check on V112 of the SLS but I think I did explicitly 'call' all initialization routines (however, I'm not positive of that).


----------



## kotori (Nov 15, 2006)

Thanks for the feedback Bob.

I hope the *>>http://nilsliberg.se/ksp/setup-kscript-editor-1.17RC3.exe (RC3)<<* version will work better. Sorry to use you as beta testers to this extent.


----------



## Dynamitec (Nov 15, 2006)

....hmm...you say sorry for using us as beta tester?! :shock: We should say sorry for using you as the tool number 1 developer...

I just can say thank you for your work!


----------



## Big Bob (Nov 15, 2006)

Amen to that!

I've just downloaded RC3 and I'll get on it right away although I suspect you'll be catching some zzzzzzs by the time I report on it.

Thanks a million Nils.

Bob


----------



## kotori (Nov 15, 2006)

Thanks guys! :smile: I'll be catching some zzzzzzs quite soon, but I'll be awake for a little while longer.


----------



## Big Bob (Nov 15, 2006)

kotori @ Wed Nov 15 said:


> Thanks guys! :smile: I'll be catching some zzzzzzs quite soon, but I'll be awake for a little while longer.



Well here's some early feedback on RC3. Things appear to be much better now. At least on my simple tests things seem to happen as I would expect. V112 of SIPS still has problems but they're in the nature of array defs with a symbolic constant sizer and could well be the result of having to warp the code to 'trick' the compiler.

I'll go through it all carefully now and in a way this may be a good acid test of our theory. Now that we have some control over the ordering of global constants, etc, it will be interesting to see if I can rearrange SIPS V112 to compile in a more straight-forward way.

When I've got some results, I'll post it even though you may be sound asleep. Is it tomorrow AM that you are leaving or are you home yet another day?

God Bless,

Bob


----------



## kotori (Nov 15, 2006)

Thanks for the feedback Bob. I also noticed the problem with the size variable. I hope it has to do with the new requirements to use functions and to explicitly invoke on_init functions and not some error. Kontakt sometimes has very mysterious error messages - it seems that code like this:
declare %array[SIZE]
declare const SIZE := 10
make_persistent(%array)

gives an error message which basically says that %array has not been declared, even though the primary error is that SIZE was not declared at the point of the declaration of %array.

Unfortunately I'm going away quite early tomorrow. There might still be a chance that I can do something about any error that you might notice, so please post any feedback. However, I probably won't have much more than an hour or so. I'll try to bring with me a copy of the code. I might not have access to my development environment while being away, but if necessary I might try some source code changes blindly and send you the changed source for testing.

Cheers,
Nils


----------



## Dynamitec (Nov 15, 2006)

declare %array[SIZE]
declare const SIZE := 10
make_persistent(%array)

gives an error message which basically says that %array has not been declared, even though the primary error is that SIZE was not declared at the point of the declaration of %array. 

>> confirmed! This always happens if a constant is not declared but used as a array size.


----------



## kotori (Nov 15, 2006)

Hi Benjamin,
Yes, and I believe it's not undeclared constants which cause this strange behaviour. I think using non-constant expressions as array sizes causes the same strange error messages. But this is a K2 problem of course.

Have you had any chance to try out the RC3 version yet?


----------



## kotori (Nov 15, 2006)

I'm going to sleep very soon now. Any last-minute problems/observations that you want me to dream up a solution for?


----------



## Big Bob (Nov 15, 2006)

kotori @ Wed Nov 15 said:


> Hi Benjamin,
> Yes, and I believe it's not undeclared constants which cause this strange behaviour. I think using non-constant expressions as array sizes causes the same strange error messages. But this is a K2 problem of course.
> 
> Have you had any chance to try out the RC3 version yet?



This is a common problem with K2 but I do believe it makes sense. Apparently K2 is a one-pass compiler somewhat like Pascal. So nothing can be forward referenced. 

With this situation:

declare %array[SIZE] 
declare const SIZE := 10 
make_persistent(%array) 

when %array is being declared, SIZE is unknown so the compiler doesn't know how big to make the array, so it doesn't create it at all. But their diagnostic reporting is a little skimpy to say the least and I think it leaves a lot to be desired.

I have seen no problems with this kind of thing when SIZE *is defined first*, however, this kind of thing is one of the main reasons why it's very important that the NL Editor allow us to control the ordering of constants.

*BTW I have now got V112 of SIPS to compile *and it didn't take too many gymnastics to do it. I think the V1.17RC3 is going to be much more logical to deal with in these areas. I need to more carefully rearrange SIPS now because V112 has a lot of things in it that were done only to work around the forward ref problems, etc. With the V1.17, I think a lot of this can be cleaned up and that will make it a lot more readable. So, I'm hard at work on V113.

One consequence of these changes however may be that once things are put in the proper order, V113 will no longer compile with editors prior to V1.17RC3, but, I don't think that should be an issue.

So far, I can only find one thing that I might suggest you change but I'll hold the thought until I complete more testing and such. Glad you finally drifted off to lulaby land though.

I'll type up one last report before I crash tonight just to close the loop.

Once again, Thanks a million Nils for a really great tool.

God Bless,

Bob


----------



## Big Bob (Nov 15, 2006)

Hi Nils,



> The question is still where to place local variables. I guess as long as they are not assigned an initial value on the declaration line it doesn't matter. What do you think, should I place them at the bottom or top of 'on init'? (I don't either alternative will hinder one from writing any script)



After playing with the latest version 1.17RC3 and pondering the above question that you posted earlier, I think it would be better to place local declarations (as well as global declarations in functions that aren't called in the 'on init' block) *at the END of the 'on init block'*. There are a fair number of situations where a function needs to define a new local constant in terms of an 'already defined' constant. For example:


```
on init
  declare const two := 2
  declare Julius
  declare Wilbur
end on

function HotDog
  declare const three := two + 1

  Wilbur := Julius + three
end function

On the other hand, it is very seldom that the main set of 'on init' declarations ever need be made in terms of constants defined local to procedures (even when they are made global).

I notice that RC3 puts local declarations like the one for 'three' at the head of the 'on init' block and as a result K2 won't accept it because it doesn't yet know what 'two' stands for. If you or others think it would be better to put locals at the head of the list, I can make an even stronger case for putting them at the end but I'll have to take more time to illustrate it. On the other hand, if it's a toss up with you, and it isn't hard to do, etc,  I'd like to see you put locals at the end of the 'on init' block.

I'm still testing RC3 and probably will continue for another hour or so yet so I may make one more post before I retire for the evening.  But, if not, I sincerely hope you have a beautiful 3 weeks.

God Bless,

Bob
```


----------



## Big Bob (Nov 15, 2006)

Good Morning Nils,

As my final post for the evening I want to say that I really like the way the new editor handles things (except for the local defs at the head thing). Now I can even declare a global array locally in a function and call the function multiple times with only one declaration showing up in the on init block. Then, if I don't call the function at all, the declaration doesn't show up at all. This kind of thing is really going to help making a Library Module more memory efficient. For example, I have an arctangent table (array) that is needed only if the trig functions are called by the user. So, if I declare the table in the 'core' cordic routine, even if the user calls only one of the 'shell' routines that use the core routine, the table is nicely compiled. But, if no trig function is invoked, no table is compiled. Nice, really nice!  

Apart from the suggestion I made in my last post, I have only one other minor thing to discuss with you when you return but its an old array issue and has nothing to do with the latest stuff. Anyway, so far so good with all my testing. Tomorrow I'm going to start rearranging my Math Library and SIPS to take advantage of this great stuff that's been done with an already super editor.

As I said in my last post, I hope you have a truly enjoyable and refreshing time in Japan.

God Bless,

Bob


----------



## kotori (Nov 15, 2006)

Good morning Bob and thanks a lot for that encouraging report and for all work testing and experimenting. I'll take a look at moving the local declarations to the bottom of 'on init' instead. I think I'll release 1.17 with that and if it turns out bad in any way I'll leave the RC3 version around so that you can use it instead. I'll be back shortly...

Cheers,
Nils


----------



## kotori (Nov 16, 2006)

:arrow: The 1.17 version can now be downloaded from the editor web page.

Local variables declared inside functions which are invoked at some point but never invoked directly/indirectly from within 'on init' are now placed at the end of 'on init'.


----------



## Dynamitec (Nov 16, 2006)

Hi Nils!

Sorry, i wasn't there anymore yesterday. No i had no chance to try it out yet. The problem is: the KSP job i'm doing has to be finished soon and since there was problems compiling the old cod with the new releases i switched to 1.15 which worked for me.

I hope you had a good night!

Benjamin


----------



## Big Bob (Nov 16, 2006)

kotori @ Thu Nov 16 said:


> :arrow: The 1.17 version can now be downloaded from the editor web page.
> 
> Local variables declared inside functions which are invoked at some point but never invoked directly/indirectly from within 'on init' are now placed at the end of 'on init'.



Hey Nils,

Thanks ever so much for making this change before leaving. I'll be testing the daylights out of V1.17 while your gone. I know that by the time I'm posting this you're probably well on your way but, for when you get around to checking your email (when you get to your destination), I wanted to close the loop with a thank you.

Have a wonderful time, but, hurry back, we need you!

God Bless,

Bob


----------



## Dynamitec (Nov 16, 2006)

Hey Bob!

I'm really happy to get so many "Topic Reply Notification". And when i take a look i see you're really active here again  I'm REALLY glad you haven't fully retired yet.

I'm looking forward to finsish my commercial project soon and be back in the forum - to make some lookup tables :shock: and other useful stuff. Maybe the 2.2 update brings us some new stuff to play with.

I sometimes think about writing a pdf with all the information which is "saved" in this great forum here...but: the fact i'm not a native english speaking person limits me in doing this :(

Best wishes and a wholesome future!

Benjamin


----------



## Big Bob (Nov 16, 2006)

Hi Benj,



> I'm really happy to get so many "Topic Reply Notification". And when i take a look i see you're really active here again I'm REALLY glad you haven't fully retired yet.



Well, once in a great while, I get a burst of energy but it's far from consistent. Mostly I just read the posts and take note of things. But, generally my health has been doing a little better, so I'm still Praising the Lord!

In fact, I'm thinking of starting another script so I'm trying to pave the way with Math Functions and such. Thanks for your encouragement and, I'm glad to hear that you'll soon be back at 'full speed'. Hope you didn't burn too much midnight oil, you may need it someday. :wink: 

God Bless,

Bob


----------



## Thonex (Nov 16, 2006)

Big Bob @ Thu Nov 16 said:


> In fact, I'm thinking of starting another script so I'm trying to pave the way with Math Functions and such.




ooohhhh.... is it a secret?... any hints?


----------



## Big Bob (Nov 16, 2006)

> ooohhhh.... is it a secret?... any hints?



It's not a secret Andrew, but, I may never get it done and I don't want to get a reputation like NI, announcing things that I may not be able to deliver on. The spirit is willing but sometimes the flesh is weak.

My intention is to try to finish what I started with SIPS. but that's a pretty tall order and I may not be able to accomplish it. Even if I do, I may not be able to adequately prepare and support it as would be needed for a general distribution. So, for now, I have to just think of this as a personal project. But, if the Good Lord is willing, who knows, maybe someday there will be a 'Son of SIPS' :wink: 

There's a lot more I have to do before I can even start on this. For one thing I have to make a variant of SIPS SLS that uses change_vol() instead of the fade_in/fade_out functions. This will just be a test version that won't add any new capability, it'll just be an exercise to see if anything worsens. If not, then good things may start happening. When I've got a working version of the temporary SLS, I'll be looking for some testers and trying to get some feedback pro or con.

Meanwhile, I'm trying to finalize my KSP Math Library because I'm going to need these functions for what I intend to do. But remember, everything runs at a snail's pace for me these days, so be patient  .

God Bless,

Bob


----------



## Thonex (Nov 16, 2006)

Ahhh yes... your original intentions with SIPS was to use the change_vol() command but it was broken... now that it's fixed... and now that you have your custom math library... who know what may come  

Whatever it is.. It will be brilliant... it always is.

Cheers,

Bob,

T


----------



## kotori (Nov 16, 2006)

Dynamitec @ Thu Nov 16 said:


> Hi Nils!
> 
> Sorry, i wasn't there anymore yesterday. No i had no chance to try it out yet. The problem is: the KSP job i'm doing has to be finished soon and since there was problems compiling the old cod with the new releases i switched to 1.15 which worked for me.
> 
> ...



Hi Benjamin,
Didn`t it work in the 1.17 version? If not, and if you have time to test, please report what kind of problems you`re having. Maybe you mean to say that the new requirements of explicitly invoking functions declaring global vars makes your scripts not compile any longer and that you don`t want to change them too much in this late stage. 

Thank you all for all your valuable (and sometimes funny) feedback.

That late-night 1.17 version sprint was probably a good idea, because I hope it will now be easier to adjust to the time difference here (8 hours). I`ll check in here every now and then, so please continue to post your findings.

Cheers,
Nils


----------



## Big Bob (Nov 17, 2006)

Hi Nils,

As long as you're still checking the board, I'll lay a couple of things on you.

First, all the good news. I was able to rearrange SIPS so it now compiles with V1.17 of the NLE as well as still compiling with V1.11 of the NLE (the version I was using when I did V112 of SIPS). I bumped the version number of SIPS to V113 since the old V112 won't compile with the new editor. I'll email V113 of SIPS to you when you return.

Also, generally, everything continues to work well with the new NLE V1.17, I'm still playing with it trying to determine the best way to use the new behavior with something like the Math Library. I think it's going to be very cool.

However, I notice that when a function that isn't referenced in the ICB declares a global var, the def is still placed at the top of the ICB whereas when such a var is defined without the 'global' prefix it's now placed at the end of the ICB as expected. I think (but I'm not positive of this yet) that it would be better if the globals were treated the same as the locals (but of course only when the function is not referenced in the ICB).

Part of the reason I'm not sure about this yet has to do with an old array problem that I'm wondering if you can do anything about. The problem is, that there doesn't seem to be any way to declare a local array constant (ie a compile-time initialized array). Take a look at the following code:

*on init*
``*declare* X
*end on*

*function* Y
``*declare* K[5] := (0,1,2,3,4)
``*declare* global KX[5] := (0,1,2,3,4)
``
``X := 2*X + K[2]
*end function*

*on note*
``Y
*end on*

_{----------------------------- Compiled Code --------------------------}_
*on init*
``*declare* %KX[5] := (0,1,2,3,4)
``*declare* $X
``*declare* %_K[5] := (0,1,2,3,4)
*[color=#000077:bbò—Í   Jdx—Í   Jdy—Í   Jdz—Í   Jd{—Í   Jd|—Í   Jd}—Í   Jd~—Í   Jd—Î   Jd€—Î   Jd—Î   Jd‚—Î   Jdƒ—Î   Jd„—Î   Jd…—Î   Jd†—Î   Jd‡—Î   Jdˆ—Î   Jd‰—Î   JdŠ—Î   Jd‹—Î   JdŒ—Î   Jd—Î   JdŽ—Î   Jd—Î   Jd—Î   Jd‘—Î   Jd’—Î   Jd“—Î   Jd”—Î   Jd•—Î   Jd–—Î   Jd——Î   Jd˜—Î   Jd™—Î   Jdš—Î   Jd›—Î   Jdœ—Î   Jd—Î   Jdž—Î   JdŸ—Î   Jd —Î   Jd¡—Î   Jd¢—Î   Jd£—Î   Jd¤—Î   Jd¥—Î   Jd¦—Î   Jd§—Î   Jd¨—Î   Jd©—Î   Jdª—Î   Jd«—Î   Jd¬—Î   Jd­—Î   Jd®—Î   Jd¯—Ï   Jd°—Ï   Jd±—Ï   Jd²—Ï   Jd³—Ï   Jd´—Ï   Jdµ—Ï   Jd¶—Ï   Jd·—Ð   JbV—Ð   JbW—Ð   JbX—Ð   JbY—Ð   JbZ—Ð   Jb[—Ð   Jb\—Ð   Jb]—Ð   Jb^—Ð   Jb_—Ð   Jb`—Ð   Jba—Ð   Jbb—Ð   Jbc—Ð   Jbd—Ð   Jbe—Ð   Jbf—Ð   Jbg—Ð   JdÊ—Ð   JdË—Ð   JdÌ—Ð   JdÍ—Ð   JdÎ—Ð   JdÏ—Ð   JdÐ—Ð   JdÑ—Ð   JdÒ—Ð   JdÓ—Ð   JdÔ—Ð   JdÕ—Ð   JdÖ—Ð   Jd×—Ð   JdØ—Ð   JdÙ—Ð   JdÚ—Ð   JdÛ—Ð   JdÜ—Ð   JdÝ—Ð   JdÞ—Ð   Jdß—Ñ   Jdà—Ñ   Jdá—Ñ   Jdâ—Ñ   Jdã—Ñ   Jdä—Ñ   Jdå—Ñ   Jdæ—Ñ   Jdç              ò—Ò   Jdé—Ò   Jdê—Ò   Jdë—Ò   Jdì—Ò   Jdí—Ò   Jdî—Ò   Jdï—Ò   Jdð—Ò   Jdñ—Ò   Jdò—Ò   Jdó—Ò   Jdô—Ò   Jdõ—Ò   Jdö—Ò   Jd÷—Ò   Jdø—Ò   Jdù—Ò   Jdú—Ò   Jdû—Ò   Jdü—Ò   Jdý—Ó   Jdþ—Ó   Jdÿ—Ó   Je —Ó   Je—Ó   Je—Ó   Je—Ó   Je—Ó   Je—Ó   Je—Ó   Je—Ó   Je—Ó   Je	—Ó   Je
—Ó   Je—Ó   Je—Ó   Je —Ó   Je—Ó   Je—Ó   Je—Ó   Je—Ó   Je—Ó   Je—Ó   Je—Ó   Je—Ó   Je—Ó   Je—Ó   Je—Ó   Je—Ô   Je—Ô   Je—Ô   Je—Ô   Je—Ô   Je—Ô   Je—Ô   Je —Ô   Je!—Ô   Je"—Ô   Je#—Ô   Je$—Ô   Je%—Ô   Je&—Ô   Je'—Ô   Je(—Ô   Je)—Ô   Je*—Ô   Je+—Ô   Je,—Ô   Je-—Ô   Je.—Ô   Je/—Ô   Je0—Ô   Je1—Ô   Je2—Ô   Je3—Ô   Je4—Ô   Je5—Ô   Je6—Ô   Je7—Ô   Je8—Ô   Je9—Ô   Je:—Ô   Je;—Ô   Je<—Ô   Je=—Ô   Je>—Ô   Je?—Ô   [email protected]—Ô   JeA—Ô   JeB—Ô   JeC—Ô   JeD—Ô   JeE—Ô   JeF—Ô   JeG—Ô   JeH—Ô   JeI—Ô   JeJ—Ô   JeK—Ô   JeL—Ô   JeM—Ô   JeN—Ô   JeO—Ô   JeP—Ô   JeQ—Ô   JeR—Ô   JeS—Ô   JeT—Ô   JeU—Ô   JeV—Ô   JeW—Ô   JeX              ò—Ô   JeZ—Ô   Je[—Ô   Je\—Ô   Je]—Ô   Je^—Ô   Je_—Ô   Je`—Ô   Jea—Ô   Jeb—Ô   Jec—Ô   Jed—Ô   Jee—Ô   Jef—Ô   Jeg—Ô   Jeh—Ô   Jei—Ô   Jej—Ô   Jek—Ô   Jel—Ô   Jem—Ô   Jen—Ô   Jeo—Ô   Jep—Ô   Jeq—Ô   Jer—Ô   Jes—Ô   Jet—Ô   Jeu—Ô   Jev—Ô   Jew—Ô   Jex—Ô   Jey—Ô   Jez—Ô   Je{—*


----------



## Big Bob (Nov 17, 2006)

Hi Nils,

regarding:



> Other than this particular case, there might be some argument in favor of placing globals at the head because this would give us another measure of control. If we declare a var as local, we know it will be at the end of the ICB and if we declare it as global it will be positioned at the beginning of the ICB. I need more usage time to see if that might be more useful than if all non-ICB-referenced locals and globals are placed at the end of the ICB.



I have now bumped into several situations in which *it is better to leave the globals thing the way you have them now*, ie if a var is declared in a function using the 'global' prefix, and that function is not 'called' in the ICB, put the declaration at the TOP of the ICB (but leave the locals at the END of the ICB). It's just great the way you have it in V1.17.

The new feature of not compiling any function-declared vars if the function is not referenced by the user works out just super for Library construction. I'm arranging the KSP Math Library so that only the data declarations that are needed are compiled, and its based solely on whether or not the host script references the routines that need these vars. There is no need to include any kind of on_init_Math or on_init_Trig calls in the ICB. You can 'import' the whole Library and not have anything added to your host script if you don't use any of the Library's functions. This is really getting neat!  

However, if you can do something about providing a way to define and compile-time-initialize local arrays (without the illegal assignment), that would still be very, very, useful for the kind of stuff I've been doing.

I'll keep slugging away at this and continue to report on how it's going. Meanwhile, I hope you're having a really great time over there.

God Bless,

Bob


----------



## Thonex (Nov 17, 2006)

Big Bob @ Fri Nov 17 said:


> Meanwhile, I hope you're having a really great time over there.



Over where?

I know you're in California... so with my highly developed deductive reasoning skills... I'm surmising he's not on the West coast because you'd have said "I hope you're having a really great time over *here*."

So where is he... East Coast? China? Where's Nils..... :cry: :lol:

It's like our own little Vi-Pro version of *Where's Waldo*  

T


----------



## Nickie Fønshauge (Nov 17, 2006)

Hi Andrew,

I think Nils-san went to Nippon-koku :wink:


----------



## Thonex (Nov 17, 2006)

Nickie Fønshauge @ Fri Nov 17 said:


> Hi Andrew,
> 
> I think Nils-san went to Nippon-koku :wink:



Harigato


----------



## kotori (Nov 18, 2006)

Big Bob @ Sat Nov 18 said:


> I have now bumped into several situations in which *it is better to leave the globals thing the way you have them now*, ie if a var is declared in a function using the 'global' prefix, and that function is not 'called' in the ICB, put the declaration at the TOP of the ICB (but leave the locals at the END of the ICB). It's just great the way you have it in V1.17.
> 
> The new feature of not compiling any function-declared vars if the function is not referenced by the user works out just super for Library construction. I'm arranging the KSP Math Library so that only the data declarations that are needed are compiled, and its based solely on whether or not the host script references the routines that need these vars. There is no need to include any kind of on_init_Math or on_init_Trig calls in the ICB. You can 'import' the whole Library and not have anything added to your host script if you don't use any of the Library's functions. This is really getting neat!
> 
> ...



Hi Bob,
Just thought I'd confirm that I got your message. I'm very glad to hear that things seems to be working out with the latest version. I'll try to fix the array initialization thing as soon as I get a chance. It shouldn't be hard to do. I wonder if there is also a problem with constants declared inside functions. Will their assignments be included in the compiled code as well? It's not a particularily important use case, but if I fix the const array thing I might just as well do everything right.

I'm having a great time here. Beautiful nature, the best food there is, very kind people and plenty of chances to practice japanese. Couldn't be better. 

Cheers,
Nils


----------



## Big Bob (Nov 18, 2006)

Hi Nils,

Thanks for the 10-4. 

Regarding simple constants (and variables), 



> I wonder if there is also a problem with constants declared inside functions. Will their assignments be included in the compiled code as well? It's not a particularily important use case, but if I fix the const array thing I might just as well do everything right.



Simple variables have a similar problem as arrays but it's relatively harmless. Take a look at the following:

*on init*
``*declare* Julius
*end on*

*function* Test
``*declare* *const* abc := 6
``*declare* def := 7
``Julius := abc + def
*end function*

*on note*
``Test
*end on*

_{------------------------------- Compiled Code -----------------------------}_
*on init*
``*declare* $Julius
``*declare* *const* $_abc := 6
``*declare* $_def := 7
*end on*

*on note*
``_{begin Test}_
````$_def:= 7
````$Julius := $_abc + $_def
``_{end Test}_
*end on*

For 'real' constants (ie those declared with the *const* keyword (such as 'abc' in the example above), there is no assignment statement created. For 'typed' constants (ie variables assigned values at creation time), there is an assignment statement created when the function is called as you can see for the variable 'def' in the above example. However, in the case of simple variables, the extra assignment, while redundant (and I think unnecessary), is mostly harmless. However, in the case of arrays, the duplicated assignment is illegal in the KSP and thus problematical.

Since the variable 'def' *is* properly initialized in the ICB, I don't think there is any need to re-initialize it for each 'call' of 'Test'. So perhaps when you address the array assignment problem it will just naturally eliminate the redundant assignment for simple variables as well?



> I'm having a great time here. Beautiful nature, the best food there is, very kind people and plenty of chances to practice japanese. Couldn't be better.



Really glad to hear you are enjoying your holiday. Practice Japanese!!! How many languages to you speak anyway (besides computer languages that is :roll: )? Swedish, German, and English I think; and now Japanese! I'm always very impressed with anyone who can master more than one natural language. I have enough trouble with just English (and maybe one or two computer languages) :cry: . After my first wife died in '95, I married a lovely little gal from the Philipines (who fortunately speaks English). But I've been listening to her speak Tagalog for more than 10 years now and I haven't picked up more than 4 or 5 words :oops: .

Well, have a great day my friend.

God Bless,

Bob


----------



## Big Bob (Nov 18, 2006)

Hey Nils,

I have a question. Families defined in 'on_init' functions seem to always get shoved to the top of the ICB. Is there any way that I can 'force' a symbolic constant to be positioned ahead of a family declaration in the ICB so that the family can refer to this constant? When there is more than one family defined in a script, what determines the order in which they are positioned at the head of the ICB?

If you just happen to 'know' this stuff off the top of your head, please let me know but, if not, it'll keep until you get back.

Have another beautiful day on me.

God Bless,

Bob


----------



## Dynamitec (Nov 23, 2006)

The updated ksp_util.txt for K2.2...

Rename the file from ksp_util.txt.zip to ksp_util.txt and copy it it to KScript Editor program directory.


----------



## kotori (Nov 23, 2006)

Dynamitec @ Thu Nov 23 said:


> The updated ksp_util.txt for K2.2...
> 
> Rename the file from ksp_util.txt.zip to ksp_util.txt and copy it it to KScript Editor program directory.



Hi Benjamin,
Thanks a lot. I'm glad that this seems to work out. However, I can't see the file. Did it get attached?

Cheers,
Nils

Btw. Declarations of local arrays initialized on the same line will be possible in the next version of the compiler (this was a problem Bob reported above). I and Bob are trying to resolve the question about families via mail.


----------



## Dynamitec (Nov 23, 2006)

*edit* removed since i posted a new version


----------



## Dynamitec (Nov 23, 2006)

Now i discovered a problem. I can't get the new on ui_update to work. I did add it as a new keyword...

As a workaround move "ui_update" to the [functions] part. This works but isn't "correct"... since "ui_control" is in the [keywords] part.

Please Nils, remember this when you are home again!


----------



## kotori (Nov 23, 2006)

Benjamin, thanks for notifying me about this. With a bit of luck I might be able to fix this on a distance. Stay tuned!


----------



## Big Bob (Nov 23, 2006)

Dynamitec @ Thu Nov 23 said:


> Now i discovered a problem. I can't get the new on ui_update to work. I did add it as a new keyword...
> 
> As a workaround move "ui_update" to the [functions] part. This works but isn't "correct"... since "ui_control" is in the [keywords] part.
> 
> Please Nils, remember this when you are home again!



Hey Benj,

I've got a couple of patches from NILs that I'm going to post sometime tomorrow. One of these adds the ui_update callback. However, when I post the patch, I'd like to also include the revised ksp_util.txt file. To save some work, I thought I would download the one you did and just give it a quick check over. However, I can't get the file unzipped. I notice a lot of other posts about problems with unzipping your demo vibrato script but it seems like the thought there was that it had something to do with your download service. But now, it's simply an attachment on this forum and I can't unzip it! :o Are you sure there isn't something wrong with your version of WinZip or WinRAR or whatever you are using?

If you see this post in time, maybe you could try reposting the file? If not, I guess I'll just redo what you did to update the ksp_util.txt file :cry: 

God Bless,

Bob


----------



## Dynamitec (Nov 24, 2006)

Hi Bob! It's no zip...you have to rename it to ".txt" because it's not allowed to attache .txt files here


----------



## Big Bob (Nov 24, 2006)

Dynamitec @ Fri Nov 24 said:


> Hi Bob! It's no zip...you have to rename it to ".txt" because it's not allowed to attache .txt files here



Ah So! :oops: I guess I should learn how to read, sorry. 

I've got a few more tests to run with the editor patches and then I should be able to post it. Hang in there.

Bob


----------



## Big Bob (Nov 24, 2006)

Hi Guys,

I'm going to attach a patch file that I got from Nils that fixes or adds a few things for the benefit of V1.17. The file is a compiled Python file with a pyc extension but I'll wrap it in a .zip file so the forum will take it. To use this patch file, first unzip it and then put the file named *'ksp_preprocessor2.pyc' *in your *'KScript Editor' *folder. You should also download Benjamin's revised version of the *'ksp_util.txt' *file and replace the old one (by the same name) also in the *'KScript Editor' *folder. Here's a summary of the changes:

1. Adds the new 'ui_update' callback
2. Allows you to declare 'local' compile-time initialized arrays in functions without generating an illegal assignment statement when referenced.
3. When global variables are defined in functions that are not 'called' during the *ICB*, these variables are put at the head of the *ICB*. However, before this patch, variable blocks from different functions were put in the *ICB* in reverse order of their defining functions. Now they are put in the same order.

The rule summary now for *global* variables declared in functions is as follows.

If the function is referenced (ie called) in the *ICB*, the declarations are placed at the position of the *first call*. (Subsequent calls of the same function in or out of the *ICB* are ignored by the compiler insofar as declarations are concerned, that is *they won't be multiply declared*). All the variables for a given function are compiled in the same order they are declared within the function. Thus you can control what order the inter-function globals are compiled in the *ICB* by the order you 'call' the defining functions in.

Globals declared in functions* that are not referenced (called) in the ICB *are placed at the *head* of the *ICB* in the same order they are declared within the functions and in the same order the functions are written in. The order in which the functions are called has no bearing on the ordering in the *ICB*. However, if a function isn't called at all, neither its global nor local declarations will appear in the *ICB*. *This allows you to 'import' a large library and only use a small part of it without the penalty of compiling all the unused data and procedures.*

Finally, all local variables declared in functions are positioned at the *end* of the *ICB*. Within any given function block, the variables appear in the same order they are defined in the function (ie the intra-function ordering is respected). The inter-function ordering is currently in the reverse order that the functions are written in however this will probably change in the near future. Moreover, since local variables are by definition only used by the function that defines them, the inter-function ordering shouldn't post any problems.

*I know you will join me in giving a hearty thanks to Nils for taking the time during his well-earned vacation to provide us with this important patch. *

God Bless you Nils,

And please have a beautiful time for the rest of your vacation.

Bob


----------



## Thonex (Nov 24, 2006)

Big Bob @ Fri Nov 24 said:


> However, if a function isn't called at all, neither its global nor local declarations will appear in the *ICB*. *This allows you to 'import' a large library and only use a small part of it without the penalty of compiling all the unused data and procedures.*



This feature alone is truly awesome!!!!!ò™þ   JñC™þ   JñD™þ   JñE™þ   JñF™þ   JñG™þ   JñH™þ   JñI™þ   JñJ™þ   JñK™þ   JñL™þ   JñM™þ   JñN™þ   JñO™þ   JñP™þ   JñQ™þ   JñR™þ   JñS™þ   JñT™þ   JñU™þ   JñV™þ   JñW™þ   JñX™þ   JñY™þ   JñZ™þ   Jñ[™þ   Jñ\™þ   Jñ]™þ   Jñ^™þ   Jñ_™þ   J


----------



## Dynamitec (Nov 25, 2006)

Hi Bob!

Thanks for your post! In my ksp_util.txt above there is "ui_update" in the [function] part... with the new patch it should be in the [keyword] again? Am i right?

So, i made a zip with both files (the patch Bob posted) and the new ksp_util.txt. You just have to unpack it in the program directory of Nils Editor!

on ui_update works well now.


----------



## Nickie Fønshauge (Nov 25, 2006)

Thanks B & B. I am much obliged :smile:


----------



## Big Bob (Nov 25, 2006)

Hi Benj,



> Hi Bob!
> 
> Thanks for your post! In my ksp_util.txt above there is "ui_update" in the [function] part... with the new patch it should be in the [keyword] again? Am i right?



Thanks for pointing that out, I should have caught that but I thought you had already removed it. And thanks for combining the two needed files.

God Bless,

Bob


----------



## kotori (Nov 25, 2006)

Dynamitec @ Sat Nov 25 said:


> Hi Bob!
> 
> Thanks for your post! In my ksp_util.txt above there is "ui_update" in the [function] part... with the new patch it should be in the [keyword] again? Am i right?
> 
> ...



Hi everyone,
I'm glad that things are working out. A clarification on the ksp_util.txt file - unlike the other sections the keywords section only affects the syntax highlighting and not how the compiler does its work, so it's correct that ui_update should be a keyword and not a function.

Cheers,
Nils


----------

