[WIP] Jebnix - A kOS Alternative

[nothke]

Just got an idea:

What about adding an ability to detect exceptions, and then, instead of just terminating the program, being able to do something else, like run an abort program. Sometimes, it happens that things happen very quickly, like launching or landing a rover, and you really want to have some fail-safe program behind it. Or you could even run a self-destruct program, as many real world rockets are adjusted to in case of a software error.

for example

IFEXCEPTION { RUN KerbalX_abort. }

Knowing there will be nothke making those parts, I would not like to not have them. But, many "computational" tools were questioned because of their reliance with parts (MechJeb, Protractor, Kerbal Engineer Redux, kOS itself, to name a few).

I would propose the possibility to have two different setup for the same functionality, and believe it may be as easy as to set a switch or a config value, to let the user decide if Jebnix is made dependent on its parts or not with that user install.

Hmmm, maybe a compromise could be made so that each pod includes a computer and a single hard drive for example, and that you could add more additional part-hard drives if you wanted more code on board.

Edited January 20, 2014 by nothke

[Camacha]

I am really happy to see the kOS idea picked up by someone obviously capable and willing. The coming period I will (un)fortunately be of limited use due to my (hopefully) graduation work, but I wish you all the best and will help where possible.

Something I wonder about is the language: Kevin had a very specific goal in mind when creating KerboScript. How are you going to extend the language without it being nether fish nor fowl. Without pursuing the same goals I guess there is a real danger of it being too simple for power users, while not providing any ease for first time users.

Compiling the code does seem like a very interesting possibility. Although I think a (relatively slow) scripting language provides certain challenges, a fast compiled program combined with extended and extensive control over seperate inputs/control surfaces would enable users to create incredibly complex and amazing auto pilot systems.

[Dunbaratu]

Compiling the code does seem like a very interesting possibility. Although I think a (relatively slow) scripting language provides certain challenges, a fast compiled program combined with extended and extensive control over seperate inputs/control surfaces would enable users to create incredibly complex and amazing auto pilot systems.

It could be implemented using a pseudo-compile pre-parse model like a lot of modern "interpreted" scripting languages use. In this model, it behaves like an interpreted language in the sense that a user directly "runs" the ASCII source code without making a binary code version first, but what the "interpreter" actually does when you run it is take a first pass through the entire source code of the program before it starts doing anything, and it pre-compiles it up front into some internal tighter representation that's not quite machine code and not quite source code but something halfway between. Then it runs that.

The biggest advantage that model has in performance is that you don't pay the parsing cost repeatedly when running a loop, like you would when running a truly 100% interpreted language. If a 5-line loop runs 100 times, you pay the cost of parsing 5 lines of code, not the cost of parsing 500 lines of code.

The second advantage isn't about performance but about exposing syntax errors in the infrequently run code. In a truly 100% interpreted language, if there's code that normally never runs and only runs when certain exceptional conditions become true, the syntax of those statements is never properly checked until that condition happens to occur at runtime. Code that, for example, checks for weird cases that "shouldn't happen", could have a secret hidden syntax error in it for years that never gets found because the code has to actually execute before the error is found. A pre-parse "interpreted" language engine reports syntax errors in code regardless of whether it ends up ever executing or not.

On the topic of slow language challenges, while it's true that a slow language running slow code does sort of present a lot of fun challenges that it's been fun to work with in kOS, the brute force slow implementation of kOS has also created a problem of bogus simulation artifacts in the underlying KSP engine itself that are not meant to be part of that challenge. It's one thing for slow execution to cause your code to have poor reaction times. It's something else entirely for it to cause the entire universe itself to keep stuttering and halting because kOS is exceuting it's hooks slowly enough to clog up the KSP engine itself.

The model used by KSP to have Mods run 'hook' routines sort of requires those hooks to finish their tasks quickly. It's sort of like the bad old days of cooperative multitasking on Macs before they switched to running on UNIX. One slow 'citizen' can ruin it for the rest of the system very easily. In that regard, to make Jebnix play nice with other mods sort of requires that it be made faster and more efficient than kOS was.

[jxi24]

Just got an idea:

What about adding an ability to detect exceptions, and then, instead of just terminating the program, being able to do something else, like run an abort program. Sometimes, it happens that things happen very quickly, like launching or landing a rover, and you really want to have some fail-safe program behind it. Or you could even run a self-destruct program, as many real world rockets are adjusted to in case of a software error.

for example

IFEXCEPTION { RUN KerbalX_abort. }

Another idea would be to use a

Try ... Catch ... 

In order to have it run different programs based on the excpetion. Or something along those lines to do something different for different kinds of exceptions.

And maybe also add the ability to throw our own exceptions if we have some numerical calculation that gets out of hand (error gets to large for example). I don't know, just throwing out some ideas.

[jxi24]

On another note, I am also willing to help in testing if you need people.

[woodywood245]

First of all, I'd like to thank everyone for their continued support. Sorry I disappeared for a couple weeks, but I had a handful of emergencies all pop up at the same time.

The college semester has started, so most of my time is being dedicated towards my school work. However, work is continuing even if it doesn't look like it.

A few weeks ago, I started working on a closely related project that will enable me to explore the idea of having an IMU that keeps track of the current pitch-roll-yaw angles, allowing the user to program their directions that way if they so choose. I had to stop working on that temporarily to finish another project (I'm a very busy person, obviously), however, work will proceed again this week, and I think I've got everything narrowed down.

Two things:

1. No matter how long I might be quiet, this project will not die. Even when I'm quiet, I'm still working.

2. Please please please PLEASE read the first post on this thread before asking for a feature. The first post has a list of features that are probably going to be added. I kind of feel like a jerk whenever I have to point out that the requested feature is already on the list.

Also, check if the date/time on the "Last Edited" part of the first post. If it's been changed since you've last read it, you're going to miss something.

Now I will respond to each of you individually.

[woodywood245]

Wow, this will be amazing. Any idea when you'll be able to do the alpha testing?

Also, I have one small recommendation. Using kOS in Real Solar System, I couldn't connect to the archive (I think the location of Kerbin is hardcoded into kOS) Could you code in something that figures out where Kerbin is and does the whole antenna thing accordingly?

I will look into this. I don't use Real Solar System, nor do I know how it works. So keep watch on the development so when testing does begin, you will be able to help me get it working with Real Solar System.

I don't know when the alpha will be ready. I am hesitant to make an estimation because I'm ALWAYS late when I do that. I consider this project still in the early stages. There are large chunks of the KSP API that I still need to learn, and get some additional talent aboard.

[woodywood245]

/me peeks in.

Just when I wanted to start working on kOS/RPM integration.

I want a place where I can hook a terminal in, partless or not.

Actually, I was really hoping I could figure out a way to make Jebnix work with RPM. I'm working on a conceptual testbed for Jebnix's navigation system that uses RPM as it's GUI, and I'd love to be able to use RPM as an optional console for Jebnix. The only thing I would need is the ability to get keyboard input from RPM.

I'm utterly unfamiliar with designing GUIs for KSP so I'll probably need a lot of guidance in this area. However, the RPM system is brilliantly easy to use from the programmer's end.

[woodywood245]

Instead of building your own language, or continuing on the "less than stellar" syntax of kOs.

Why not simply implement an existing game scripting library? Like Lua, or Javascript?

The obvious benefits are twofold...

First of all you don't have to worry about language and syntax, only implementation, so you can spend all your time on getting the language to work with KSP well..

Secondly. People don't need to learn a new language which in it's initial stages is likely to be very fickle and buggy. And they get to use existing editing tools like luaedit and learn from existing internet resources.

Your work would then be restricted to handling in and output to and from the script. Meaning you get to add lots of features in little time once the initial plumbing is done.

There are several reasons why I chose to continue using KerboScript.

1. The language may have a variety of syntax issues, but it is incredibly easy to learn.

2. I spent several weeks working on and perfecting a unified guidance system for my rockets, and all of it is written in KerboScript. Personally, I don't want to have to convert the whole thing to a different language.

3. In order to implement a language, one must be intimately familiar with it, either by designing it from scratch, or knowing A LOT about it. I may not have designed KerboScript, but I do know it pretty well, and there are a few people around here that can help fill in the gaps in my knowledge. I do not know Lua, and I really don't like JavaScript, but I do know that KerboScript has a lot of potential if given a little TLC.

4. I have done this type of thing before (including implementing a new language), and I know how to do it right. I've been studying language design and implementation for several years.

[woodywood245]

I hadn't noticed this thread before. This would be good if it can be accomplished. It's a pretty ambitious set of goals.

What are the plans for release?

1 - Release nothing until all the goals in the bullet-point list are met.

2 - Release when some of them are met, and plan to hit the rest in future updates.

I'm going to release as I get things done. My first goal is to have a version that works with the existing KerboScript language, and includes a few core language improvements (such as if-else) that are easier to implement from the beginning.

From there, I will add features starting with language features and moving towards functional features, releasing every few weeks.

[woodywood245]

Do you plan to use the addition operator (+) for string concatenation like what kOS does now? Because if so then it would be nice if there was a way for the script writer to pick which meaning of "+" was meant - string concatenation or math addition. Imagine if you implemented automatic casting (which I think is the right way to go to make the language newbie-friendly), then it would be very odd and confusing if the following two statements get treated differently:

set val to "50".

set answer to val + 1. // Result: answer = "501" because '+' is concatenation.

set answer to val - 1. // Result: answer = 49 because '-' is math subtraction and "50" got parsed into a number.

To have the '-' and the '+' operator give such opposite behaviors would be weird, and it would mean if you really DO want addition you'd have to subtract a negative, which would be really messy looking.

One possible solution: Don't overload the meaning of "+" to be concatenate anymore. Concatenate with a different operator. (problem, backward compatibility with kosscript).

Another possible solution: Although automatic casting exists, also provide a means for manual casting, so someone can do something like this:

set answer to val:AS_NUMBER + 1.

(I was thinking what would make a good "cast" operator and thought the : suffix format might work for it and be in keeping with how the rest of kOS looks, as in: :AS_NUMBER or :AS_STRING. )

Thanks for responding to this. I was hoping to get a response several weeks ago, but didn't, so I implemented this without anyone's judgement, but it can be easily changed.

I have a different set of implementation rules for each operation. A Value object has an underlying type value, which determines whether the Value is a string, floating-point (double), integer, boolean, ordered pair, etc, etc, etc. Each binary operator compares the operands internal types, and performs casts based upon a set of order rules. For example:

The + operator does a string concatenation first, only if one of the values has an internal type as a string. Then it tries it for floating-point, then integers, then booleans, then complex types.

        public static Value operator +(Value a, Value 
        {
            if (a.IsNull | b.IsNull) throw new NullReferenceException();

            if ((a.Type == ValueTypes.String) | (b.Type == ValueTypes.String))
                return new Value(a.StringValue + b.StringValue);
            else if ((a.Type == ValueTypes.Float) | (b.Type == ValueTypes.Float))
                return new Value(a.FloatValue + b.FloatValue);
            else if ((a.Type == ValueTypes.Integer) | (b.Type == ValueTypes.Integer))
                return new Value(a.IntegerValue + b.IntegerValue);
            else if ((a.Type == ValueTypes.Boolean) | (b.Type == ValueTypes.Boolean))
                return new Value((a.IntegerValue + b.IntegerValue) != 0 ? true : false);
            else if ((a.Type == ValueTypes.OrderedPair) | (b.Type == ValueTypes.OrderedPair))
                return new Value(new OrderedPair(a.OrderedPairValue.X + b.OrderedPairValue.X, a.OrderedPairValue.Y + b.OrderedPairValue.Y));
            else
                return new Value();
        }

Also, some operations cannot be performed on certain types as it is currently written.

For example:

set val to "50".
set answer to val + 1.
print answer.
set answer to val - 1.
print answer.

Would result in.

501
InvalidOperationException: Cannot perform subtraction with a string value.
501

The second occurrence of "501" will be because I don't plan on having a program halt because of an error unless it is explicitly told to do so in the code. The code will run into an exception at "set answer to val - 1.", ignore the line, and execute the next.

I really like your idea of explicit casting. Implementing that will solve the problem.

set val to "50".
set answer to val:ToNumber + 1.
print answer.
set answer to val:ToNumber - 1.
print answer.

Would result in.

51
49

I could implement it as such:

ToInt - casts the value to an integer

ToFloat - casts the value to a double

ToNumber - if the value has a fractional value, converts it to a double. otherwise, converts it to an int.

ToString - casts the value to a string

[woodywood245]

I think it makes sense to invent a Part for this - a small itty bitty thing the same size as the little science instruments like the Gravioli Detector of Seismometer. Then instead of using the orientation of the craft, you base it on the orientation of the part. Whichever way the distance-finder-part is pointed, that's the line it shoots its "ray" in to look for intersecting terrain. Most of the time, you'll want to mount it aimed down to get the behavior you mention, but for other purposes you could mount it in other directions.

I've been wanting to make a part like this for a while, though it will be part of another project that I'm also working on.

[woodywood245]

Besides wishing you good luck, I'd also like to make a petition here: please document your stuff!

As the author of an IDE for kOS looking into supporting Jebnix, lack of documentation is a hell of a problem. And for your potential users too.

Good luck man!

Trust me, I try to document EVERYTHING. Sometimes it's tough (I hate writing documentation), but if I don't document stuff, it comes back to bite me when I forget what I'm doing exactly. Part of the project includes writing a thorough language specification. You'll find what I have done so far in the codebase wiki. It's not anywhere near finished, but it will detail all language keywords, functions, types, and other language features.

https://github.com/griderd/Jebnix/wiki/KerboScript-Plus-Plus-Language-Specification

[woodywood245]

Because this project looks ambitious and I therefore expect it will be quite a while before there's a release, I'll continue using eerandrake's attempts to make a kOS 10.0 that is compatible with KSP 0.23 in the meantime. But once this thing is working well I'd definitely want to use it.

To that end, is backward compatibility with kOSscript really a necessary goal? If you're going to rebuild everything from the ground up anyway, and it will probably differ enough to require people to re-write scripts anyway (many scripts have weird twiddly behavior to work around bugs that you'd hopefully be trying to get rid of), maybe it's not as important to make it kosscript compatible. I don't know - it's up to you at any rate. I wish you good luck. I want to use this.

Keeping compatibility with the older language is partially a selfish goal. I spent several weeks writing a unified guidance system that I have no urge to rewrite in it's entirety. However, I plan on allowing programmers to implement whatever language they like on the system. The front end and back ends are going to be two different systems.

[woodywood245]

I am really happy to see the kOS idea picked up by someone obviously capable and willing. The coming period I will (un)fortunately be of limited use due to my (hopefully) graduation work, but I wish you all the best and will help where possible.

Something I wonder about is the language: Kevin had a very specific goal in mind when creating KerboScript. How are you going to extend the language without it being nether fish nor fowl. Without pursuing the same goals I guess there is a real danger of it being too simple for power users, while not providing any ease for first time users.

Compiling the code does seem like a very interesting possibility. Although I think a (relatively slow) scripting language provides certain challenges, a fast compiled program combined with extended and extensive control over seperate inputs/control surfaces would enable users to create incredibly complex and amazing auto pilot systems.

One of my goals for KerboScript++ (as I'm calling it) is to make it as KerboScript compatible as possible. You'll still be able to run your old code with little to no modification. However, there will be a variety of additions to the language that will make it more powerful for the power user, without sacrificing the ease of the language.

[Dunbaratu]

Keeping compatibility with the older language is partially a selfish goal. I spent several weeks writing a unified guidance system that I have no urge to rewrite in it's entirety. However, I plan on allowing programmers to implement whatever language they like on the system. The front end and back ends are going to be two different systems.

True, but my point is that there will inevitably be incompatibilities with exisitng kosscript because of how quirky and weird kOS behaves and some of that quirky behavior you probably won't *want* to emulate as it's actually buggy design. That means people will have to go over their existing code anyway and find out why things changed, and that might make a clean break better.

It's a bit like the problem people have who implement WINE. Re-implementing the Windows API to work correctly actually isn't enough to make it compatibile. They also have to make it have the same BUGs and really stupid behaviors as exist in the original, even in places where the original behavior is clearly wrong, to make it really compatible.

[diomedea]

Must say I concur with Steven Mading here.

The history of Information Technology is filled with examples of poor solutions, being preferred over some more solid and straightforward ones just to keep backward compatibility. Just look at MS-DOS Memory Management, for one. Would be better to design without such constraints, and if required to allow backward compatibility by means of a dedicated additional plugin.

[Sacred Aardvark]

Would be better to design without such constraints, and if required to allow backward compatibility by means of a dedicated additional plugin.

Looking at the first post, isn't this what he is planning to do? There will be a separate dll for each language interpreter, just that the first interpreter will be for kerboScript. One could code a different one to interpret say lua and feed it to Jebnix for execution.

Jebnix will also include a modularized system. The Jebnix computer will exist in one DLL, while the KerboScript++ engine will exist in another DLL. This will allow me to modify one without disrupting the other, and for myself and others to interchange scripting engines, or add additional scripting engines to the existing system. More detail to come.

[Agathorn]

Just out of curiosity will this use the same mod plugin system, so that mods written to work with kOS will work with this without being changed?

[Rokker]

I have a few ideas, though they may be kind of hard to accomplish. One would be that as you progress through and unlock more of the tech tree or just certain branches, the amount of memory storage density of the part increases in a way sort of like how mechjeb unlocks more capabilities the farther into the tree you get. Another idea is to allow the exporting of data from the game into something like a .txt so that you can log certain things, like sensor readouts or fuel usage. Lastly, something I would like to see is for it to be easy to make parts from other mods easily compatible with the system. For example lets say I want to use the magnetometer from the KSP Interstellar mod. I would like to be able to write a simple .cfg and be able to activate and deactivate it through code, and if possible, obtain the number readouts from it and print them. Sorry if any of these features have been mentioned or are on the first post. I tried to read all the posts and everything in the first post, but I may have missed or forgotten something.

Edit: Oh and also it would be nice if you could work with Cilph and see if we can finally get a RemoteTech 2 compatible computer. And along with being able to tell apoapsis and periapsis, a semi-major axis ability would be nice. Also, while loops would be nice.

Edited February 1, 2014 by Rokker

[Kerbart]

Instead of building your own language, or continuing on the "less than stellar" syntax of kOs.

Why not simply implement an existing game scripting library? Like Lua, or Javascript?

That is such a great idea. One can argue that even a language like Javascript is not "Kerbalesque" enough but the syntax of kerboscript always drove me nuts. Not that it was a big problem, since kOS was somehow not able to control any rocket once it left the launchpad I wasn't using it anyway, but it would be so much easier if it's just using a well-documented language without issues around operators, etc.

[jxi24]

Continuing on this line of thought. The idea I had was adding in a communication delay based on the file size. I know that a signal delay was mentioned, but I am referring to uploading or downloading scripts from the mission control. Just like what would happen in the real world you have some speed of transmission of the data which can be upgraded in the tech tree. And maybe on top of that add the ability to use input files so that you can write a generic code you send up with the probe and then if you need to make changes just have a short file to be read by the script to preform the actions.

[Rokker]

Continuing on this line of thought. The idea I had was adding in a communication delay based on the file size. I know that a signal delay was mentioned, but I am referring to uploading or downloading scripts from the mission control. Just like what would happen in the real world you have some speed of transmission of the data which can be upgraded in the tech tree. And maybe on top of that add the ability to use input files so that you can write a generic code you send up with the probe and then if you need to make changes just have a short file to be read by the script to preform the actions.

so... sort of like science transmitting takes time and has to go in packets. I wouldn't be opposed to just using the stats of the antennas and their transfer rates.

[Garek]

Edit: Oh and also it would be nice if you could work with Cilph and see if we can finally get a RemoteTech 2 compatible computer. And along with being able to tell apoapsis and periapsis, a semi-major axis ability would be nice. Also, while loops would be nice.

Yes, RemoteTech 2 integration would be awesome, I can't imagine how one would do powered probe landings without it. About the SMA, isn't that just the average of Apoapsis and Periapsis heights plus body radius? Of course, having it in the standard library would be nice.

[Sacred Aardvark]

One can argue that even a language like Javascript is not "Kerbalesque" enough but the syntax of kerboscript always drove me nuts.

I'll do KS over JS or lua any day. Only issue I had with KS was the fact that I kept using semicolons instead of periods, but that's not a big deal.

If kerboscript gets dropped, lets change to MEL! (or Ch, or Rexx, or Squirrel, or AngelScript, etc)

[edit] reading this now it seems less lighthearted than I intended it to be :|

Edited February 1, 2014 by Sacred Aardvark