[WIP] Jebnix - A kOS Alternative

[John FX]

So multiple units running on unfocused craft is either really really hard or impossible. Either option means I`d not like to see an attempt at it although it would be fun to use. Glad that is sorted out. Now, what`s happening with Jebnix?

Woodywood, how do you see the changes being made to the language by Erendrake combining with your work? Are you planning to follow his changes and additions, or are you taking Kevin's kOS as canonical and running with it from the point he left off?

I would suggest picking a point, 0.94 for example, and making Jebnix backwards compatible with that. After release check up on all the many KOS variants out there and see which features are good. Rinse and repeat.

Until Jebnix is released it`s a moot point. I would imagine Jebnix will have features not in other Mods and vice verse so any program which will run on either platform will have to use a reduced feature set.

As woody says in his Sig, "All right, there's a thousand things that have to happen in order. We are on number eight. You're talking about number six hundred and ninety-two."

Jebnix Language

The original goal of Jebnix was to be a kOS replacement, using an improved version of the Kerboscript language. That goal still exists, and is not changing. I started working on this project three months before I announced it.

The Jebnix codebase is now nearly 4000 lines of code and comments. Just the scripting engine has reached more than 2100 lines. It's not that long, but that's weeks of work dedicated to a single project that I'm working on in the little spare time I have.

The language I'm implementing is Kerboscript++. End of story.

I may, in the future, as part of the idea of allowing the code to be compiled, add additional languages by merging a separate, ongoing project into this one, which will have a variety of language options, including a C-like language, and a BASIC-like language. This is not a guarantee, and you probably shouldn't bet on it.

If you'd prefer an immediate alternative to Kerboscript, there's another user named secretformula who's working on a scriptable guidance system called JsKsp, which is going to be implemented for JavaScript. I don't know the state of that project. There's also this: http://kerbalspaceprogram.com/agc/, the Automated Guidance Computer, which has some interesting features, and the language is LISP. And of course, there's the classic, ProgCom http://kerbalspaceprogram.com/0-18-4-progcom-cpu-emulator/, which lets you write everything in an assembly language.

I'm not saying these are good alternatives, and I'm not saying that my decision to write this thing for KerboScript is a great idea. I chose KerboScript because it was something that all kOS users are familiar with, and because it's simple and inflexible syntax makes it so easy to parse. The goal of the language was to be something easy for non-programmers to pick up. I don't know if that's actually what happened, and I know the language drives real programmers crazy, but this is what I'm doing, plain and simple.

Myself I managed to pick up using KOS very quickly except for finding workarounds for bugs and coping with the unintuitive direction system. If KOS did not have either of those then Kerboscript, even if it drives real programmers mad, would be very easy to pick up and use.

You can use all your energy chasing new features in other mods and get nowhere fast. I`d suggest finishing the plan you already have (which does seem to be your plan), then have a look and see what you want to incorporate as new features for Jebnix.

[Dunbaratu]

Myself I managed to pick up using KOS very quickly except for finding workarounds for bugs and coping with the unintuitive direction system. If KOS did not have either of those then Kerboscript, even if it drives real programmers mad, would be very easy to pick up and use.

Agreed. Most of what made kOS hard to pick up in the early days was not the weirdness of the language, but the buggy implementation of it and the many places where the documentation differed from the reality. If it had worked exactly as advertised it would have been easier to deal with. Keeping an active list in your head of all the stuff that doesn't work and all the workarounds for it was what made it hard. The fact that the language looked weird wasn't hard except insomuch as it made it difficult to tell the difference between "this is a bug" and "this is me not understanding the language". When there were lots and lots of bugs, the inability to tell that difference was a problem.

For example, the fact that all variables are global in scope and work across all subprograms was originally a bug and NOT what Nivekk intended. But by the time it was noticed too many people had depended on it (because there was no way for them to tell that it wasn't intentional. kOSscript was a weird language so if it's doing something buggy you might interpret that as what it was meant to do, which is what happened in this case). So what had been a bug became an accepted language feature and was kept.

Edited February 17, 2014 by Steven Mading

[woodywood245]

Agreed. Most of what made kOS hard to pick up in the early days was not the weirdness of the language, but the buggy implementation of it and the many places where the documentation differed from the reality. If it had worked exactly as advertised it would have been easier to deal with. Keeping an active list in your head of all the stuff that doesn't work and all the workarounds for it was what made it hard. The fact that the language looked weird wasn't hard except insomuch as it made it difficult to tell the difference between "this is a bug" and "this is me not understanding the language". When there were lots and lots of bugs, the inability to tell that difference was a problem.

For example, the fact that all variables are global in scope and work across all subprograms was originally a bug and NOT what Nivekk intended. But by the time it was noticed too many people had depended on it (because there was no way for them to tell that it wasn't intentional. kOSscript was a weird language so if it's doing something buggy you might interpret that as what it was meant to do, which is what happened in this case). So what had been a bug became an accepted language feature and was kept.

As I'm working on Jebnix, I'm working on writing a detailed language specification for Kerboscript++, that defines the expected behavior of each of the language elements, and how they should work on concert. This is for my own sanity as well as everyone else's. If something isn't working as I designed it, it will become obvious when reading the language definition. In the case of Kerboscript++, certain behaviors that exist in the original language (such as normal variables existing in global scope) will still be there, with fixes for other behaviors. There will also be no hidden keywords that can only be found by looking in the source code. Everything will be defined as obviously as possible. I'm going to try my best to make decent documentation as well as a decent implementation, because it drives me nuts when good software comes with bad documentation.

[woodywood245]

Woodywood, how do you see the changes being made to the language by Erendrake combining with your work? Are you planning to follow his changes and additions, or are you taking Kevin's kOS as canonical and running with it from the point he left off?

As far as language design is concerned, I'm starting where Kevin left off. I'm planning on adding core language improvements first (if-else/if-elseif statements, useful error messages, exception handling, return values, function blocks, enumerators, != operator, unary + and - operators, NOT operator, bitwise AND and OR operators, arrays, boolean type, ordered pair type, string operations, variable scopes, etc) before adding new surface-level features (dynamic arrays, VOLUME:NAME, etc). Features that Erendrake is adding may be included in my version, but it's not guaranteed.

[Camacha]

As far as language design is concerned, I'm starting where Kevin left off. I'm planning on adding core language improvements first (if-else/if-elseif statements, useful error messages, exception handling, return values, function blocks, enumerators, != operator, unary + and - operators, NOT operator, bitwise AND and OR operators, arrays, boolean type, ordered pair type, string operations, variable scopes, etc) before adding new surface-level features (dynamic arrays, VOLUME:NAME, etc). Features that Erendrake is adding may be included in my version, but it's not guaranteed.

O dear, it is going to be a real pain to choose the best alternative pretty soon. While on the subject: have you guys seen the RISC kOS variant? Do you think it could bring performance gains to Jebnix, or is that too much of a change?

[woodywood245]

O dear, it is going to be a real pain to choose the best alternative pretty soon. While on the subject: have you guys seen the RISC kOS variant? Do you think it could bring performance gains to Jebnix, or is that too much of a change?

It's a little too late to incorporate that kind of thing into what I already have. I've already reached the point where the DLLs compile and actually work. I haven't started looking at performance yet. I expect initial performance of Jebnix to either be abysmal or excellent, but I won't release it until I get it where I want it (the faster the better). I'm hoping the simplified codebase, which uses a lot of the optimization techniques I know, will help increase the speed. Most of the speed is based on the core clockspeed, which can be determined by implementation and potentially be configured.

I have been working on a separate project for quite some time now that is a virtual machine/scripting engine for .Net, which compiles everything to bytecode and runs it directly on a virtual machine. If that project is ever completed, I'm planning on releasing a version of Jebnix incorporating that scripting engine. The project is large and ambitious (and I can describe it in far more detail, PM me if you'd like more info), but is a backburner project so I'm not sure when it will be finished.

[woodywood245]

A preview of the improved error messages:

[Camacha]

A preview of the improved error messages:

http://i1269.photobucket.com/albums/jj600/woodywood245/Jebnix/Screenshot2014-02-23162958.png

I like that it is very desciptive (and actually making sense). I think I saw another implementation that actually pointed the error out with an arrow, that is pretty neat too.

This is the stuff that makes languages easy for beginners.

[woodywood245]

I like that it is very desciptive (and actually making sense). I think I saw another implementation that actually pointed the error out with an arrow, that is pretty neat too.

This is the stuff that makes languages easy for beginners.

The part in parentheses is the name of the file/process running (or, in this case, the interactive console process), and the line number the error occurs on, similar to how it would appear as a compiler error.

[Dunbaratu]

A preview of the improved error messages:

http://i1269.photobucket.com/albums/jj600/woodywood245/Jebnix/Screenshot2014-02-23162958.png

That is the advantage of using a real parser. Nice work.

[woodywood245]

And next, a preview of expression evaluation. There are still a few bugs that need to be worked out and some other work, but it's mostly working.

This demonstrates the importance of parentheses for equal-precedence operations.

Edited February 25, 2014 by woodywood245

[woodywood245]

A test of library functions:

Library functions will include:

Basic math functions:

abs - Absolute value

mod - Modulus (though this can be achieved with the % operator)

floor - Rounds a number up to an integer.

ceiling - Rounds a number down to an integer.

round - Rounds a number.

roundto - Rounds a number to a given decimal place.

sqrt - Square root

Trig functions

radtodeg - Converts radians to degrees

degtorad - Converts degrees to radians

sin - Sine function for degrees

cos - Cosine function for degrees

tan - Tangent function for degrees

sinr - Sine function for radians

cosr - Cosine function for radians

tanr - Tangent function for radians

asin - Arcsine function for degress

acos - Arccosine function for degrees

atan - Arctangent function for degrees

atan2 - Two-argument arctangent function for degrees

asinr - Arcsine function for radians

acosr - Arccosine function for radians

atanr - Arctangent function for radians

atan2r - Two-argument arctangent function for radians

Logarithmic Functions

log - Logarithm base 10

logx - Logarithm base x.

ln - Logarithm base e.

Also provided are constant values:

pi - The value pi.

e - The value e.

GravitationalConstant - the gravitational constant (6.67384×10^-11 m^3 kg^-1 s^-2)

[Mujun Kross]

Great work with this one. I hope it goes to release and we can have a go at breaking it for you.

I loved the idea of the original kos...I just wish the original author was able to take it to where it needed to go (whatever happened to the guy). I wish you the best of luck in this....however it sounds like you have it in hand with a solid design concept.

Thanks

[woodywood245]

Great work with this one. I hope it goes to release and we can have a go at breaking it for you.

I loved the idea of the original kos...I just wish the original author was able to take it to where it needed to go (whatever happened to the guy). I wish you the best of luck in this....however it sounds like you have it in hand with a solid design concept.

Thanks

This is going to release, I'm just not exactly sure when. Because I started completely from scratch, it is definitely an uphill battle, and I'm not able to put in as many hours as I'd like to. However, I never abandon projects (sometimes I just let them get dusty), so you can be assured that this project will be released within a reasonable time. I'm planning on distributing a pre-release alpha sometime in the coming weeks that uses RPM as an interface (with no keyboard support). This would simply be designed to test/run scripts and use the underlying systems. And I'm sure there will be plenty of stuff for the breaking. I'm writing the thing, and I'm finding new bugs every day. You can track day-to-day progress on Github (see first post).

Thanks for your support!

[woodywood245]

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?

The plugin system is being designed today. It will feature two systems: a legacy system that lets you use the old (and weird) method, and a newer system that lets you register your functions directly through the Jebnix library. The newer system will allow programmers to simply call the ExternalFunctions.RegisterFunction(string name, int paramCount, Delegate ptr) or ExternalFunction.RegisterFunction(string namespc, string name, int paramCount, Delegate ptr) method, and pass it a delegate (function pointer, for the C/C++ programmers). A unique internal name is generated for the function, and the function is registered with its delegate in a Dictionary (hash table). When its time for the function to be invoked, the ExternalFunctions.InvokeFunction() method is called, and the registered function is invoked, if it exists.

[woodywood245]

Storing script names as strings, creating them dynamically, and calling scripts through the stored variable.

Also demonstrates WHILE loops.

[drtedastro]

Hello Woodywood245,

Great to see how this is coming along.

quick question, in the above example, where is the space coming from between test and the variable "x"??

is is automatic or is it somehow implied???

just curious... trying to keep up with this so that i can get started soon...

cheers.

[woodywood245]

Hello Woodywood245,

Great to see how this is coming along.

quick question, in the above example, where is the space coming from between test and the variable "x"??

is is automatic or is it somehow implied???

just curious... trying to keep up with this so that i can get started soon...

cheers.

I'm not sure I understand your question. Are you taking about in the console, where it says "this is test 1.", "this is test 2.", etc?

[drtedastro]

I see now... I was looking at it the wrong way. Too late/early not enough coffee yet or too much....

It will be great to work with this...

[diomedea]

[joke mode on] Woody, you set at least 6 test# scripts, but only allowed the program to run the first 5 of them! [/joke mode]

[Camacha]

Storing script names as strings, creating them dynamically, and calling scripts through the stored variable.

Also demonstrates WHILE loops.

Ooh, nifty. Those are things I have been wanting.

[woodywood245]

Ooh, nifty. Those are things I have been wanting.

So have I. I'm also thinking about including do...while loops and for-loops, but I'm not exactly sure on the appropriate syntax to make it easy. For-loops are confusing already for newbies in other languages. I'm thinking something like this for do... while.

DO
{
// do something
} WHILE condition.

I want to add for-loops if possible because they are closely related to while-loops (virtually identical, actually) so they are easy to implement, and I'm going to have arrays (which will support a foreach iterator loop), but sometimes you don't want to iterate over the entire array.

[Camacha]

So have I. I'm also thinking about including do...while loops and for-loops, but I'm not exactly sure on the appropriate syntax to make it easy.

Would it not be best to use the already familiar syntax of the until loop?

while x < 5 {
   set x to (x + 5).
}.

Or am I missing something critical that causes that not to work? I am not sure about for loops - the concept is not complicated, but I understand that people need to get it before it becomes easy.

[woodywood245]

Would it not be best to use the already familiar syntax of the until loop?

while x < 5 {
   set x to (x + 5).
}.

Or am I missing something critical that causes that not to work? I am not sure about for loops - the concept is not complicated, but I understand that people need to get it before it becomes easy.

WHILE loops are already built into Jebnix.

WHILE loops and DO... WHILE loops are similar, but different. In a WHILE loop, the condition is checked before it is executed for the first time, whereas in a DO... WHILE loop, the block is executed at least once, with the condition checked at the end to see if it should be executed again.

set x to 0.
// this will run repeatedly until x is 5
while x < 5
{
set x to x + 5.
}

// this loop is functionally identical to the one above
set x to 0.
do
{
set x to x + 1.
} while x < 5.

set x to 5.
// this loop executes only once, and x becomes 6.
do
{
set x to x + 1.
} while x < 5.

[Camacha]

I am not sure what direction you want to take kOS, but looking at it from the point of wanting to develop a compact and easy language I might not bother with do... loops at all. People can substitute it with barely any code themselves.