[documentation] Linux unable to run files with CAPS.

[TDW89]

Might be worth a quick mention in the case insensitivity docs that if your OS file system (linux, don't know about mac as i don't have one) is case sensitive then files on the archive with capital letters in them will not be found and are impossible to run.

[erendrake]

what i would likely do is just get the full list of fileinfo for the folder, then compare the lowercase version of all of them to the name you specified. that being said

FOO.ks

and

foo.ks

i dont plan on making tools to disambiguate these.

[abenkovskii]

From documentation: If your filesystem is case-senstive (Linux and sometimes Mac OSX, or even Windows if using some kinds of remote network drives), then bareword filenames will only work properly on filenames that are all lowercase.

[erendrake]

@abenkovskii i guess i had a rough day dealing with people telling me "working as intended" so i wanted to fix some stuff :)

@TDW89 @abenkovskii do you think that the current way it works is good enough? am i spending time on something of little value?

[abenkovskii]

@erendrake It could confuse new users. So I think changing this will make kOS a bit easier for them.

[oaken-source]

to add to this - the way most systems cope with modeling file access on top of case sensitive or insensitive filesystems is to just don't change the case of the filename that is provided. That way, you just retain the way the original filesystem works.

Is there a particular reason why you change the case of the filenames to all lowercase?

Come to think of it, is there a reason why you don't allow quoted strings as parameters to the run command as opposed to barewords?

IMO, not being able to run scripts with capital letters in them is a major issue.

Thanks!

[abenkovskii]

• example:

// main.ks
// when executing the next line kOS compiles "my_file.ks" into bytecode, appends this bytecode
// to the "code segment" and stores the addres of it's entry point in "$program-my_file.ks*" variable.
run my_file.ks.
run my_file.ks. // when executing this line kOS just jumps to $program-my_file*

• Don't ask me why this complicated design was chosen.
• But:
  1. It requires all file names passed to run command to be "valid" identifiers (dot is allowed in filenames)
  2. kOS compiler needs to know the name of file when it compiles run command i.e. when it complies "main.ks" in the example above.
• To make sure only "valid" identifiers are passed to the run command quoted strings were disallowed
• Kerboscript is case insensitive. It achieves case insensitivity by changing all keywords and identifiers in the program to lowercase.
• That's why the problem we are talking about occurs.

[abenkovskii]

@erendrake @Dunbaratu Could you explain why this design was chosen? Or we'll have to ask @Nivekk?

[Dunbaratu]

Come to think of it, is there a reason why you don't allow quoted strings as parameters to the run command as opposed to barewords?

Because the compilation system as originally designed by marianoapp depends on being able to know at compile-time what the names of all the runnable programs are going to be, so it knows to build stubs for them in the initialization code before it starts. If you do run foo over and over again in a loop, it knows that it only needs to allocate room for one program initializer - for foo.ks. But if you do run "prog"+num over and over, i.e. the first time its prog1.ks, then its prog2.ks, then its prog3.ks... then it cannot know at compile time how many different programs inside this program there really are. This limitation is why we chose not to support any arbitrary expression as the filename, and instead only allow bareword identifiers, because those can't change at runtime like "any string expression goes here" could.

Come to think of it, is there a reason why you don't allow quoted strings as parameters to the run command as opposed to barewords?

The case-insensitive mashing for identifiers happens for all identifiers, without carving out any special exceptions for those which were used inside run statements. It's faster to mash them to lowercase once when compiling than to do a case insensitive check every time the cpu needs to look up the variable. This logic is sensible for identifiers, any only gets messed up when those identifiers happen to be filenames, which only has to be the case because of the limitation mentioned above.

I'm not saying you're wrong that it would be better if it was changed. I'm saying don't assume it's a simple matter of just changing the language spec, as if it was just the language spec alone that was causing the limitation. The language spec contains the limitation to reflect the underlying low level limitation of the system under it.

I can't say for sure if the old original system had the limitation or not. I never got deep into this part of the implementation until after marianoapp had already changed it drastically.

Originally NO filenames ANYWHERE accepted generic expressions. Fixed that recently, and it was only when we did that it caused RUN to stick out like a sore thumb. ALL the file commands used to work like RUN still currently does - where they only work on hardcoded identifiers and don't let you make arbitrary string expressions for the filename. When we tried to change them all, we hit this snag with RUN and punted so we could still get the other ones out, instead of letting RUN's limitations hold up the rest of them.

It's probably fixable - but the fix means going deep into how programs are loaded and compiled, not just merely changing a high level language spec. It was always a low priority for me. There's bigger problems out there to tackle. Using all-lowercase filenames is just fine by me as a good-enough solution for now. It's not like you can't use it on linux at all because of the limitation. you just have to make all the filenames lowercase - which is what I end up doing anyway on linux most of the time for most of my filenames.

[oaken-source]

@Dunbaratu Thanks for the detailed explanation!

[Dunbaratu]

The main reason for the problem is that the program context is trying to be smart enough to avoid compiling the same program many times. If you run foo. in a loop 100 times, it only pays the expense of parsing and compiling foo.ks once, then the other 99 times it just runs the already-compiled version that's in memory.

But in the interactive interpreter context, it does re-compile from scratch each time you do it - under the assumption that you're going to be in an edit-try-edit-try-edit-try cycle and need to see the new change take place, not run the old stale code.

I'm wondering whether or not this model is still appropriate now that we have functions. People had been using the run command as a sort of poor-man's function call before, which is why keeping it speedy mattered. I wonder how much backward compatibility would break if we just did it the "interpreter way" inside programs too - and made it always recompile from scratch on each run command. That might alleviate the need to know ahead of time what the runnable files are going to be, and thus open up the possibility of using runtime expressions in run. I'll have to think about it more.

[abenkovskii]

@Dunbaratu It will break a lot of backward compatibility because:

1. Compiling is a slow process
2. kOS is currently using the main Unity thread to compile files

But I think that doing things the right way sometimes worth breaking backward compatibility.

[Dunbaratu]

2 is something we've been thinking of changing, but it wouldn't affect how slow kOS is at compiling - just keep the universe from freezing in place while the compile happens like it does now. Basically start a thread, compile in the thread, and then have CPU's FixedUpdate() short-circuit return each time it's called, until that thread says it finished, and then FixedUpdate() will start working normally again.

[oaken-source]

maybe it would be worth compiling the scripts outside of the game, as in, write a standalone compiler that compiles .ks files to .ko files, load .ko bytecode from .ko files at runtime?

[Dunbaratu]

http://ksp-kos.github.io/KOS_DOC/general/compiling.html I'm done for tonight. I already stayed up to the dawn and hear the birds starting. That's too late.

[abenkovskii]

It will break a lot of backward compatibility

We can just say: "[breaking change] if you are still using files as 'functions' make sure to compile them before running your program or you'll experience serious performance drop".