# New version of the KScript Editor



## kotori (Aug 6, 2006)

Hello everyone,
I'm glad to announce the new 1.03 version of the script editor. Download it at my homepage.
The latest available mac version is still 1.00, but I hope there'll be an updated version of mac as well eventually.

*Compiler:*
The syntax has been extended to provide support for variable families. This is a way to group related variables. It's easiest to demonstrate this with an example:
*family* settings
``*declare* humanize := 0
``*declare* default_volume
*end* *family*

*family* note
``*declare* polyphonic tuning
``*declare* polyphonic volume
*end* *family*

settings.default_volume = 1000
note.volume = settings.default_volume

The dot (.) will be replaced by two underscores on compilation. It's also possible to nest families (although the names will get pretty long quickly). No import statement yet.

*Editor:*
There are two new settings. You can now have the editor automatically close code blocks - type 'if 1=0' followed by <enter> and it will automatically add 'end if' if the indentation indicates that the code block is new. There's also a new auto-indent on paste feature - copy any piece of code and paste it anywhere and it will be correctly indented.

Cheers,
Nils


----------



## Thonex (Aug 6, 2006)

Thanks Nils!!!!  

This is great!!! We are so fortunate to have you around... I coudn't imagine programming in KPS without your editor.

I'll be downloading the new version next time I use the your editor.

Thanks again,

T


----------



## Rodney Glenn (Aug 6, 2006)

Thank's Nils (man tackar och bugar). :smile:

R


----------



## Dynamitec (Aug 6, 2006)

Hi Nils! THANK YOU VERY VERY MUCH!


----------



## Nickie Fønshauge (Aug 6, 2006)

Thanks Nils. I look forward to use these new additions. Just keep the good ideas comming :smile:


----------



## Dynamitec (Aug 6, 2006)

Hi Nils!

Why can't families be defined in functions? The error messages says: Variables may not be nested and have to be in function body. But in fact i placed FAMILY there.


----------



## kotori (Aug 6, 2006)

Dynamitec @ Mon Aug 07 said:


> Hi Nils!
> 
> Why can't families be defined in functions? The error messages says: Variables may not be nested and have to be in function body. But in fact i placed FAMILY there.



Oops, my mistake. It was some old error checking code to make sure people don't nest local declarations inside other blocks. Nesting inside families should of course be permitted though. Fixed now, thanks for pointing this out. Please download the 1.031 version.

I also fixed two other minor things: auto-close block now also closes function blocks, and there was an unharmful but confusing duplication of the file history which I got rid of. If anyone can spot something else, please let me know.

Btw. it can be good to know that the initialization of a declare statement isn't treated differently in a block, so for the moment one cannot write:
``*family* info
````*declare* x := 1
````*declare* y := x``
``*end* *family*
Instead this should be:
``*family* info
````*declare* x := 1
````*declare* y := info.x``
``*end* *family*


Cheers,
Nils


----------



## Nickie Fønshauge (Aug 7, 2006)

Nils, you forgot to change the link on your website. It still points to v1.03, which no longer exists.
For those, who don't want to wait for you to fix it, the correct link is http://www.nilsliberg.se/ksp/setup-kscript-editor-1.031.exe (http://www.nilsliberg.se/ksp/setup-kscr ... -1.031.exe)


----------



## kotori (Aug 7, 2006)

Nickie Fønshauge @ Mon Aug 07 said:


> Nils, you forgot to change the link on your website. It still points to v1.03, which no longer exists.
> For those, who don't want to wait for you to fix it, the correct link is http://www.nilsliberg.se/ksp/setup-kscript-editor-1.031.exe (http://www.nilsliberg.se/ksp/setup-kscr ... -1.031.exe)


No, actually I did remember to change it. Maybe you need to refresh the page in your browser. Thanks anyway.


----------



## Dynamitec (Aug 7, 2006)

This works (but only in Nils Editor, non working KSP Code):

_{------------------------------------------------------------------------------------------------------}_```
_{ ### on init ### 
{------------------------------------------------------------------------------------------------------}_```
*on init*
````_{--------------------------------------------------------------------------------------------------}_`````
````UiStandardInit
````_{--------------------------------------------------------------------------------------------------}_`````
*end on*

_{------------------------------------------------------------------------------------------------------}_```
_{ ### function UiStandardInit | => "on init" ### 
{------------------------------------------------------------------------------------------------------}_```
*function* UiStandardInit
````*family* ui_standard````````
````````*declare* global ui_label $titel(6, 1)``
````````*family* script````````````
````````````*declare* global @company
````````````*declare* global @name
````````````*declare* global @version `````
````````*end* *family*
````*end* *family*
````_{--------------------------------------------------------------------------------------------------}_
````ui_standard.script.company := 'dynamitec'
````ui_standard.script.name := 'KeyswitchModul'
````ui_standard.script.version := 'v1.00.00'
````_{--------------------------------------------------------------------------------------------------}_`````
````set_text(ui_standard.titel, ui_standard.script.company & ' | ' ...
`````````````& ui_standard.script.name & ' | ' ...
`````````````& ui_standard.script.version)
````_{--------------------------------------------------------------------------------------------------}_``
````move_control(ui_standard.titel, 1, 1) 
````_{--------------------------------------------------------------------------------------------------}_``
*end function*
[/font:b7òt   A·\t   A·]t   A·^t   A·_t   A·`t   A·at   A·bt   A·ct   A·dt   A·et   A·ft   A·gt   A·ht   A·it   A·jt   A·kt   A·lt   A·mt   A·nt   A·ot   A·pt   A·qt   A·rt   A·st   A·tt   A·ut   A·vt   A·wt   Aº*t   Aº+t   Aºþt   Aºÿt   A¼Zt   A¼[t   A½†t   A½‡t   A¿<t   A¿=t   A¿>t   A¿?t   A¿@t   A¿At   A¿Bt   A¿Ct   AÃ|t   AÃ}t   A³þt   A³ÿt


----------



## Dynamitec (Aug 7, 2006)

The only chance to get this FAMILY stuff running is:


_{------------------------------------------------------------------------------------------------------}_```
_{ ### on init ### 
{------------------------------------------------------------------------------------------------------}_```
*on init*
````_{--------------------------------------------------------------------------------------------------}_
````*family* ui_standard````````
````````*family* script````````````
````````````*declare* @company
````````````*declare* @name
````````````*declare* @version `````
````````*end* *family*
````````*declare* ui_label titel(6,1)
````*end* *family*
````_{--------------------------------------------------------------------------------------------------}_
````UiStandardInit
````_{--------------------------------------------------------------------------------------------------}_`````
*end on*

_{------------------------------------------------------------------------------------------------------}_```
_{ ### function UiStandardInit | => "on init" ### 
{------------------------------------------------------------------------------------------------------}_```
*function* UiStandardInit
````_{--------------------------------------------------------------------------------------------------}_
````ui_standard.script.company := 'dynamitec'
````ui_standard.script.name := 'KeyswitchModul'
````ui_standard.script.version := 'v1.00.00'
````_{--------------------------------------------------------------------------------------------------}_`````
````set_text(ui_standard.titel, ui_standard.script.company & ' | ' ...
`````````````& ui_standard.script.name & ' | ' ...
`````````````& ui_standard.script.version)
````_{--------------------------------------------------------------------------------------------------}_``
````move_control(ui_standard.titel, 1, 1) 
````_{--------------------------------------------------------------------------------------------------}_``
*end function*


But: This way it makes it rather useless since i have to to all declarations "on init". I'm used to copy and paste "modules" (which i like to import later when the import function is working), but this works only if i may declare variables or the new families inside functions.


----------



## kotori (Aug 7, 2006)

Hi Benjamin,
I thought I'd make this release a beta, but I didn't and in retrospect I was a bit too optimistic. The samples you posted should work, so I'll look at this and keep you posted.

Nils


----------



## Dynamitec (Aug 7, 2006)

Hi Nils,

thanks for your work. Yeah, hehe, it's getting a little bit complex now  And so the risks for bugs is growing. But it will be really useful when it works!


----------



## kotori (Aug 7, 2006)

Hi everyone,
I'm very sorry for the inconvenience, but now I hope I have fixed the problems with the new family construct. (Previously I could assume that all variables are declared directly inside functions, wereas they now can be nested in a family code block - I had forgot to change a line that was based on the old assumption)

There's a new version, 1.032, available on my webpage (only those who plan to use the 'family' keyword need to upgrade)

Cheers,
Nils


----------



## Nickie Fønshauge (Aug 7, 2006)

It seems it could be useful to have global families.
So, insted of



Dynamitec @ 7th August 2006 said:


> ````*family* ui_standard````````
> ````````*declare* global ui_label $titel(6, 1)``
> ````````*family* script````````````
> ````````````*declare* global @company
> ...



you could have



> ````*family* global ui_standard````````
> ````````*declare* ui_label $titel(6, 1)``
> ````````*family* script````````````
> ````````````*declare* @company
> ...



Could this be done?


----------



## Dynamitec (Aug 7, 2006)

Hi Nils!

Thank you, now it seems to work  Yeah!!! There is only one small thing left: why are there now lines with nothing in there in compact output?


----------



## kotori (Aug 7, 2006)

Nickie Fønshauge @ Mon Aug 07 said:


> [...]
> Could this be done?



Yes, I have thought about it myself. I don't know what would be a good syntax though. From a natural language perspective it feels more natural to say:
global family family_name than family global family_name
if you see what I mean. 

In any case I don't know how important this use-case really is as it mostly seem to be a way to make up for the current lack of 'import'. I think the best solution might be to let this be as it is, and then when 'import' is introduced also specify a special function or pseudo-callback where variable declarations are implicitly global. For example variables declared in a function called on_init (name suggestions are welcome) in a module would be treated as if they would have been declared in 'on init'. What do you think about this? Is it too implicit and magical or does the convenience compensate for that?

Nils


----------



## Dynamitec (Aug 7, 2006)

I agree with Nils. The import stuff is way more important  Not to say that i urgently need it... *g*


----------



## kotori (Aug 7, 2006)

I fixed the empty line problem and uploaded a new version (1.033) as a part of my current attempt to boost my release rate figures :wink:


----------



## Dynamitec (Aug 7, 2006)

Hi Nils! I would really like to see 10 RPH (releases per hour) :twisted: 

 Just kidding...

Your work is SO useful! Thanks.


----------



## Dynamitec (Aug 7, 2006)

Hi Nils!

Found another small bug...(with "Automaticaly indent pasted code" on)

Make a line:

{--------------------------------------------------------------------------------------------------}

Copy and paste it a few times... the last '}' gets lost after one or two pastes.

BTW: It's not that im searching for bugs, but i use your editor for 5-6 hours a day...so i'll find even such small things :lol:


----------



## kotori (Aug 7, 2006)

Dynamitec @ Mon Aug 07 said:


> Hi Nils!
> 
> Found another small bug...(with "Automaticaly indent pasted code" on)
> 
> ...



Hehe... nothing can escape your eyes. Thanks for pointing this out.

Strange, I cannot reproduce this. Anyway I saw this earlier during development and thought I had fixed it for good so I know where to look and I think I can work around it. After pasting code I wanted to cursor to be placed at the end of the line, but that looked strange if there happened to be any whitespace there, so I decided to trim trailing whitespace on that line - apparently I trimmed a little too much :oops:.


----------



## Dynamitec (Aug 7, 2006)

Thanks. 

BTW: With this version of your editor you can produce code that almost looks like the code of any higher language. That FAMILY stuff is really useful to get more structure to your code! I'm really looking forward to your IMPORT function! That will be a REAL breaktrough for KSP! 

I'll make some of my basis functions available as modules for those people here i know better (some of my queue and chord functions and the new modular ui i'm working on).


----------



## Nickie Fønshauge (Sep 4, 2006)

Nils, shouldn't it be possible to have something like this:


````````*family* Legato
``````````*family* CC
````````````*declare* ui_value_edit number (1,127,1) _{Attack Level controller}_
````````````*declare* number_reset
````````````*declare* number_reload
``````````*end* *family*
``````````*family* Level
````````````*declare* ui_knob value (1,127,1) _{Attack Level}_
````````````set_knob_unit (value,$KNOB_UNIT_NONE)
````````````*declare* value_reset
````````````*declare* value_reload
``````````*end* *family*
````````*end* *family*
````````*family* NonLegato
``````````*family* CC
````````````*declare* ui_value_edit number (1,127,1) _{Attack Level controller}_
````````````*declare* number_reset
````````````*declare* number_reload
``````````*end* *family*
``````````*family* Level
````````````*declare* ui_knob value (1,127,1) _{Attack Level}_
````````````set_knob_unit (value,$KNOB_UNIT_NONE)
````````````*declare* value_reset
````````````*declare* value_reload
``````````*end* *family*
````````*end* *family*

I get a compiler error:



> Redeclaration - another family with this name has already been declared. (line 117): family CC



Surely it should result in different variables, f.ex. Legato.CC.number and NonLegato.CC.number, so I don't quite see the problem. Is this a bug or deliberate?


----------



## kotori (Sep 4, 2006)

Nickie Fønshauge @ Tue Sep 05 said:


> I get a compiler error:
> "Redeclaration - another family with this name has already been declared. (line 117): family CC"
> 
> Surely it should result in different variables, f.ex. Legato.CC.number and NonLegato.CC.number, so I don't quite see the problem. Is this a bug or deliberate?



Hi Nickie,
That's indeed a bug. Thanks for the report. I'll see what I can do.

Cheers,
Nils


----------



## Nickie Fønshauge (Sep 5, 2006)

Thanks, Nils, for your always diligent support. It would be nice to be able to use the same name in different families. :smile:


----------



## kotori (Sep 5, 2006)

Nickie Fønshauge @ Tue Sep 05 said:


> [...] It would be nice to be able to use the same name in different families. :smile:



Indeed. 
Btw. I don't know if I have said this yet but it's possible to pass families as parameters to functions. Eg. one can write myfunc(Legato), or myfunc(NonLegato). Personally I always try to pass all things (or most at least) that a function needs in as parameters instead of just accessing the global variables in order to better document dependancies in the code. Passing families as parameters naturally make this much more easy as multiple parameters can be contracted into a single one. Because of this feature I think it's extra important that duplicated names of nested groups should be allowed.

I'll try to be back with a fix as soon as possible. I think SIPS needs some attendance first though.

Cheers,
Nils


----------



## Nickie Fønshauge (Sep 5, 2006)

kotori @ 5th September 2006 said:


> Indeed.
> Btw. I don't know if I have said this yet but it's possible to pass families as parameters to functions. Eg. one can write myfunc(Legato), or myfunc(NonLegato).


Nice. Very nice!  


kotori @ 5th September 2006 said:


> Personally I always try to pass all things (or most at least) that a function needs in as parameters instead of just accessing the global variables in order to better document dependancies in the code.


I agree - in theory. In real life, you can get some VERY long parameter lists. Family parameters could be great for keeping parameter lists short *and readable* :wink:


----------



## Nickie Fønshauge (Sep 5, 2006)

Nils, I am afraid I found one more bug.

*family* Expression
````````*family* Xpressn_CC
``````````*declare* ui_menu value _{source expression controller}_
``````````*add_menu_item (value,"Expr.CC 1 -> 1",101)*
``````````add_menu_item (value,"Expr.CC 1 -> 11",1101)
``````````add_menu_item (value,"Expr.CC 11 -> 1",111)
``````````add_menu_item (value,"Expr.CC 11 -> 11",1111)
``````````*declare* reset
``````````*declare* reload
````````*end* *family*
``````*end* *family*

In the line, I set in boldfase, I get "value not declared". It is obviously declared. If I change "value" to "num", it is OK. Why not "value"?

Edit: OK, got it. I have to write the entire name


----------



## kotori (Sep 5, 2006)

How about using "Expr.CC.value" - wouldn't that be easier to type?
Maybe I'll implement some fancier name-resolution some time. The current situation is of course not optimal.

Cheers,
Nils


----------



## Nickie Fønshauge (Sep 5, 2006)

kotori @ 5th September 2006 said:


> How about using "Expr.CC.value" - wouldn't that be easier to type?


It would, but I can't. I'm using CC in many families :wink: But maybe abbreviations is a good idea.


----------



## Dynamitec (Sep 5, 2006)

Hi Nils, i'm afraid the "lose some chars" bug while copy and pasting is still there sometimes... strange.


----------



## kotori (Sep 5, 2006)

Dynamitec @ Tue Sep 05 said:


> Hi Nils, i'm afraid the "lose some chars" bug while copy and pasting is still there sometimes... strange.


That's not good. Do you have any example of when this happens?


----------



## Dynamitec (Sep 5, 2006)

Sorry Nils, it's occasionally. I can't figure out when...I mean: It's not a too big problem, sometimes it's just a little bit anyoing...last time it was when i did some copy and paste from one open KScript Editor window to another.


----------



## Nickie Fønshauge (Sep 5, 2006)

Hi Nils,

New problem (bug?), I am afraid:

``````*family* Active
````````*declare* ui_button value := 1_{Script activation}_
````````set_text (Active.value,"Active")
````````make_persistent(Active.value)
````````*declare* reset := Active.value
````````_read_persistent_var($Active.value)
````````*declare* reload := Active.value
````````*family* Active_Position
``````````*declare* x[View.Pages]
``````````*declare* y[View.Pages]
``````````*for* i := 0 *to* View.Pages-1
````````````Active.Active_Position.x_ := 6
````````````Active.Active_Position.y := 6
``````````*end for*
````````*end* *family*
``````*end* *family*__

The "for" block gives me an error message:



CodeBlock instance has no attribute "lineno"

Click to expand...


Whazzup?_


----------



## kotori (Sep 5, 2006)

Hi Nickie,
Only declaration statements should go inside the family. However it seems I missed to disallow other one-line statements, so at the moment only block-statements like if, for, select and case violates the syntax. If you move the loops and other initialization code outside the family it should work. There was a slight error in the error reporting code which I fixed so in the future the correct error message will be displayed: "This line is not allowed inside a variable family".

Cheers,
Nils


----------



## Nickie Fønshauge (Sep 5, 2006)

Hi Nils,

I am not exactly sorry you missed those other one-line statements. It is easier to lump together items, that belong naturally together this way. Pitty you didn't miss the blocks too. I use the "for" blocks to initialize variables.


----------



## kotori (Sep 5, 2006)

Nickie Fønshauge @ Tue Sep 05 said:


> I am not exactly sorry you missed those other one-line statements. It is easier to lump together items, that belong naturally together this way. Pitty you didn't miss the blocks too. I use the "for" blocks to initialize variables.


Ok, I removed this restriction. Since it was such a small change I didn't bother to change version number. Please redownload the 1.1 version (for PC) and tell me if it works out. Personally I still like it better to do initialization outside of the family, but I figured I shouldn't impose my own design decisions to hardly upon others since everyone have different taste.

Cheers,
Nils


----------



## Nickie Fønshauge (Sep 5, 2006)

It works. Thanks a lot!


----------



## Nickie Fønshauge (Oct 9, 2006)

Sorry Nils, but I've got a small problem.

````*on init*

``````*family* Expression
````````*family* dummy0
``````````*family* dummy1
````````````*declare* dummy10
``````````*end* *family*
````````*end* *family*
````````*declare* ui_table meter[2] (3,3,128)
````````*declare* *const* CC := 11
````````*declare* *const* multi_meter_position := 1
``````*end* *family*
``````dummy_func (Expression.dummy0)

````*end on*
````*function* dummy_func (param)
``````param.dummy1.dummy10 := 1
````*end function*[/font]

It doesn't compile. I get







But, I only get the error when I pass a nested family as parameter to a function. If I remove family "dummy0" from the above example (making the parameter to dummy_func = "Expression"), everything is fine. 

This is very unfortunate, don't you think? (This is of course a leading question - you are supposed to answer "Yes, indeed it is! And I will fix it right away" :mrgreen: :razz: )


----------



## Big Bob (Oct 9, 2006)

Hi Nickie,

Since Nils will probably be sleeping a few more hours yet (I think), may I ask what version of the editor you are using? It's just that the problem you're having seems a little similar to a problem I reported for V1.14. Just for kicks, have you tried this with V1.11? That's the highest version number that has no known bugs, at least none known to me.

You've probably already tried this, but, if not give it try (until Nils jumps in with the real answer) :wink: .

God Bless,

Bob

*Oh never mind, I just tried it with V1.11 and I get the same problem.* :oops:


----------



## Nickie Fønshauge (Oct 10, 2006)

Hi Nils,

it seems to be working well now. Thanks a bunch! :smile:

EDIT: I'm afraid I was a tad too fast there. 

*function* shift_queue (name)
``*for* i := 1 *to* Thread.pointer
````%name.queue[i-1] := %name.queue_
``*end for*
*end function*{shift_queue}__

is still causing trouble. Apparently it doesn't like the "%".

The queues in question are

``*family* Thread
````*declare* *const* queue_length := 128
````*declare* *const* channel := 127
````*family* Type
``````*declare* %queue[Thread.queue_length]
``````*declare* head
````*end* *family*{Type}
````*family* Variable1
``````*declare* %queue[Thread.queue_length]
``````*declare* head
````*end* *family*{Variable1}
````*declare* pointer := UNDEFINED
``*end* *family*{Thread}

"name" would be either "Thread.Type" or "Thread.Variable1"_


----------



## kotori (Oct 10, 2006)

Nickie Fønshauge @ Tue Oct 10 said:


> Hi Nils,
> 
> it seems to be working well now. Thanks a bunch! :smile:
> 
> ...



Hi Nickie,
This isn't a problem but deliberate in the design - since it's hard for the compiler to know whether the parameter passed in will be an array or a scalar one cannot use prefixes ($%@!) on parameters. But if you just leave out the "%" in this case you should be ok. Just change "%name.queue[i-1] := %name.queue" into "name.queue[i-1] := name.queue".

Cheers,
Nils


----------



## Nickie Fønshauge (Oct 10, 2006)

Hi Nils,

the reason I explicitly state the variable type is because the compiler doesn't always get it right, at least not with strings/string arrays. So I made it a habit to be explicit. I will try without the "%". Thanks


----------



## kotori (Oct 10, 2006)

Nickie Fønshauge @ Tue Oct 10 said:


> Hi Nils,
> 
> the reason I explicitly state the variable type is because the compiler doesn't always get it right, at least not with strings/string arrays. So I made it a habit to be explicit. I will try without the "%". Thanks



Hi Nickie,
Do you have any example of when the compiler doesn't get it right? I can't recall that this has ever happened to me. Of course string variables have to be declared using the @ or ! prefix but on all other lines than the declaration no prefixes should be needed.

Nils


----------



## Nickie Fønshauge (Oct 10, 2006)

Nils,

I have been using "belt and suspenders" for a while now, so I can't remember exactly where I had a problem with strings the last time. Maybe I just didn't declare it correctly - it's possible :oops: . I don't remember the details. Anyway, it seems to work fine now - without the "belt and suspenders" :wink: Thanks.


----------



## Big Bob (Oct 10, 2006)

kotori @ Tue Oct 10 said:


> Thanks for the feedback Nickie. I corrected a pair of problems in the editor related to nested families. Please try http://nilsliberg.se/ksp/setup-kscript-editor-1.15.exe (version 1.15 of the KScript Editor). If it seems to be working ok I'll update the link on the web page as well, so please let me know if this fixes the problem.
> 
> Cheers,
> Nils



Hi Nils,

Unfortunately, the local var problem is still with us in V1.15.

*function* SetX(nx)
``*declare* NXA[4]
``
``*select* nx
````*case* 1
``````NXA[1] := 1
````*case* 2
``````NXA[2] := 2
````*case* 3
``````NXA[3] := 3
``*end select*
*end function* 

*function* FillNXA
``*declare* i

``*for* i := 1 *to* 36
````SetX(i)
``*end for*
*end function*

*on init*
``FillNXA``````````````````````````
*end on*




Try compiling the above code with V1.15, then try it with V1.1. V1.15 will only work if 'i' is declared as global.

Bob


----------



## Nickie Fønshauge (Oct 10, 2006)

That's odd. If you move "FillNXA" from "on init" to "on note" there's no error message.


----------



## Nickie Fønshauge (Oct 10, 2006)

kotori @ 10th October 2006 said:


> Nickie Fønshauge @ Tue Oct 10 said:
> 
> 
> > That's odd. If you move "FillNXA" from "on init" to "on note" there's no error message.
> ...


If the problem is not knowing whether a parameter is a variable/family name literal or a "normal" variable during the first compilation phase, why not use a special character, f.ex. "¤", to prefix the variable/family name literal variables with in function headers?


----------



## Nickie Fønshauge (Oct 21, 2006)

Hi Nils,

I got another Compilation Error, I can't figure out.

When Importing (as Solo)


````_{-------- on_init --------}_
````*function* on_init
``````*family* KeySwitch
````````*declare* dummy
````````KeySwitch.dummy := 1
````````*family* Group
``````````*declare* dummy
``````````KeySwitch.Group.dummy := 1
````````*end* *family*_{Group}_
``````*end* *family*_{KeySwitch}_
````*end function*_{on_init}_

I get the attached error message - the compiler doesn't like KeySwitch.Group.dummy. KeySwitch.dummy, on the other hand, is OK. Did I do something wrong (this is known to have happened :wink: )?


----------



## kotori (Oct 22, 2006)

Hi Nickie,
There seems to be a bug in the compiler. I'll look into this as soon as possible. Unfortunately I'm away and won't be back home until Thursday or Friday. Three things you could try:
* Make the assignment at the same time as the declaration: "declare dummy := 1"
* Move the assignment outside of the family declaration 
* Invoke on_init twice (this is not a solution, but if it makes a difference that would indicate to me that this problem is related to some of the latest changes in the compiler).

I'm working on a complete rewrite of the compiler engine which I hope will make problems like these go away.
Btw. what do you guys think of the current feature making it possible to import a module twice under different names:
import "funcs.txt" as f1
import "funcs.txt" as f2
Is this useful or would it be more useful being able to import the same instance of a module from different contexts? I'm thinking of moving towards the latter in the new compiler. 

Cheers,
Nils


----------



## Nickie Fønshauge (Oct 22, 2006)

kotori @ 22nd October 2006 said:


> Btw. what do you guys think of the current feature making it possible to import a module twice under different names:
> import "funcs.txt" as f1
> import "funcs.txt" as f2
> Is this useful or would it be more useful being able to import the same instance of a module from different contexts? I'm thinking of moving towards the latter in the new compiler.


Hi Nils,
I will try the things you listed.

I have not (yet) had any reason to import the same module twice under different names, so I don't really know what to answer to that question. :neutral: And as to *import the same instance of a module from different contexts*: I have absolutely no clue, what you mean by that :???: :razz:

BTW, I hope to see you back again "well and soon" :smile: In the meantime enjoy your holliday. You deserve it.


----------



## Nickie Fønshauge (Oct 22, 2006)

Sorry Nils,

but not even this works:


````_{-------- on_init --------}_
````*function* on_init
``````*family* KeySwitch
````````*declare* dummy
````````*family* Group
``````````*declare* dummy
````````*end* *family*_{Group}_
``````*end* *family*_{KeySwitch}_
````*end function*_{on_init}_
````
````*function* dummy_test
``````KeySwitch.dummy := 1
``````KeySwitch.Group.dummy := 1
````*end function*

I simply cannot reference variables declared inside nested families.

This is the test file, I imported it into:


``*import* "../../Dummy Solo.txt" *as* Solo

*on init*
````Solo.on_init
````
````Solo.dummy_test
*end on*


----------



## kotori (Oct 22, 2006)

Nickie Fønshauge @ Sun Oct 22 said:


> I have not (yet) had any reason to import the same module twice under different names, so I don't really know what to answer to that question. :neutral: And as to *import the same instance of a module from different contexts*: I have absolutely no clue, what you mean by that :???: :razz:
> 
> BTW, I hope to see you back again "well and soon" :smile: In the meantime enjoy your holliday. You deserve it.



Hi Nickie,
Sorry, I didn't explain myself very clear. By "importing the same instance of a module from different contexts" I mean for example that the main script imports module B and module A also imports module B. Currently if B is imported into the main script this means that there will be name clashes and if module A has it's own namespace it means that there will be two copies of module B each with its own set of variables. I don't think this is particularily useful and I don't think many people use it either, so I'm thinking about changing the import so that if the main script imports B and module A imports B then they will both share the same instance and the same module level variables. 

Sorry about the inconvenience with the nested families. Maybe you can use the name KeySwitch.Group_dummy until I get a chance to fix it.

Cheers,
Nils


----------



## Nickie Fønshauge (Oct 22, 2006)

kotori @ 22nd October 2006 said:


> Maybe you can use the name KeySwitch.Group_dummy until I get a chance to fix it.


Nils, you just gave me an idea. If I remove "as Solo" it works!


----------

