woodywood245

The one major issue with that is that the compiler and the program counter would have to talk to each other, just like an interpreter does. It wouldn't simplify things very much. That's pretty much what I'm doing now. Consider this basic example: 1 set x to 0. 2 while x < 5 3 { 4 set x to x + 1. 5 print x. 6 } 7 print "Finished!". Consider what is happening when it's translated into a pseudoassembly, and then executed without the compiler talking to the program counter. // When the whole thing is compiled and run // Assembly: main: mov x, 0 jmp while_loop print "Finished!" while_loop: add x, 1 print x cmp x, 5 jl while_loop ret // Output: 1 2 3 4 5 Finished! // Compiling one line at a time. The <-- indicates where the program counter is. // When line 1 is compiled alone: main: mov x, 0 <-- // Then lines 2 and 3 are compiled: main: mov x, 0 while_loop: // this is where the block should go cmp x, 5 <-- // this will begin an unending loop jl while_loop // Then line 4 is compiled: main: mov x, 0 while_loop: add x, 1 <-- // on the next pass, the counter winds up here. The loop will end within 17 cycles, which at even at 100 Hz is less than a 5th of a second. cmp x, 5 jl while_loop // Then lines 5 and 6 are compiled main: mov x, 0 while_loop: add x, 1 print x cmp x, 5 jl while_loop <-- // outside the loop, waiting for an instruction // Line 7 is compiled main: mov x, 0 jmp while_loop print "Finished!" while_loop: add x, 1 print x cmp x, 5 jl while_loop ret <-- // this is the new instruction. the call stack is empty, however, resulting in an underflow The way to fix this would be to halt execution whenever a control block is about to be written by the user, then compiling the block when the user closes the block. This, however, presents its own set of problems. Consider if I'd left out the period on line 4. Jebnix wouldn't let the user know about the syntax error until compilation. By that time, they've already written the line, and it may be buried deep inside a long block of code which now has to be rewritten from scratch. I'll admit that it's late, and I may not be able to think of an obvious solution to this problem, but this is how things look to me at the moment.

At the same time, given that this is "Jebnix," I think it might be fun and helpful to have a handful of *nix-like utilities to play with if people want to.

The primary reason I've been toying with the idea of getting rid of the interactive mode is that I've also been toying around with the idea of changing the language from interpreted to compiled. It would significantly simplify the project, as writing an interpreter is like writing a compiler that must track program state at the same time, and it can get ugly for certain things. I have a lot of more experience writing virtual machines and compilers than writing interpreters, and while this project is going as well as I hoped, I'd like it to be finished sooner rather than later. While the kOS situation has improved with other projects, the complete and utter lack of good documentation on those projects is driving me up the wall. I think I'd rather run my own system.

Would a combination of good documentation and a built-in editor with a "Run Now" button help?

I've got a question that I've been bouncing around in my head for the last few weeks: how important is it to everyone to have an interactive/immediate mode in Jebnix? Personally, I virtually never do anything in kOS that isn't already coded in a file somewhere, so the most I do in the console is use the RUN command. I've been thinking about getting rid of the interactive mode in Jebnix and replacing it with a small set of utilities. What does you think?

A few major life changes have gotten in the way of working on this project over the last few weeks, but I'm back at it again. I'm currently performing a major rewrite of the type system by doing away with the Value class and creating several new classes that essentially act as wrappers around the .Net types. I'm not sure if this concept is going to work, so I've split the code into a branch specifically for this rewrite. The rewrite will not affect the language design. It will allow for a broadened ability to use custom types and structures. Types will have functions associated with them that will be able to be called directly from the language. Types will also have properties that can be accessed the same way. The same goes for structures. The new Jebnix classes will be: JObject - Abstract class representing all value types JObject<T> - Abstract class for single-value types ValueArray - Inherits JObject and ICollection<JObject>, represents a collection of JObjects. JBoolean - Inherits JInteger, represents a boolean type JFloat - Inherits JObject<double>, represents a double-precision floating-point. JInteger - Inherits JObject<int>, represents an integer JString - Inherits JObject<string>, represents a string OrderedPair - Inherits JObject, represents an ordered pair structure Obviously, more structures, like Vector, Rotation, Quaternion, Heading, Body, etc, etc will be available upon release.

I haven't been able to work on this mod for the last week, unfortunately, but I put in a couple hours today. I've also uploaded what I have to Github. What's there is subject to change without notice, as much of it is still in the design phase. However, I consider the User Datagram Protocol stuff to be complete. https://github.com/griderd/TelemetryRadio

I've actually been working on something similar. In the case of my version, parts would fail randomly using MTBF as a guidepost. I haven't had time to actually plug it into KSP and test it though.

Update: After some mental deliberation, I've decided to include at least two protocols: UDP (User Datagram Protocol), and TCP (Transmission Control Protocol). I believe those, as well as perhaps one more, will be more than enough to get most people started. I'm also building all the protocols using a set of interfaces and abstract classes. This should make it significantly easier to make your own protocol, if you so choose.

Completely possible. Given the current design, it shouldn't be too hard to create a TCP network.

Most of my background is in application programming, with some systems and compiler programming thrown in for good measure, but I've done very little in the form of signal processing. As a result, I'm kind of just making it up as I go along. However, I love using raw data to calculate all kinds of meaningful pieces of information. That's why plugins like Logomatic are so great. I had the idea, what if I could take Telemachus, RemoteTech, and Logomatic, and smash them together into one system. After doing a bit of hacking, I got it working, but there is no time delay, and it only works if there's a RemoteTech connection, because data is only transmitted, not stored. So that's where this comes in. With the Telemetry Radio backend, I can do exactly what I want and lots lots more. And I'd love to see what kind of awesome stuff the community comes up with.

The Telemetry Radio mod will transmit raw bytes, and it's up to a mod on either end to encode and decode the data. It will look kind of like BinaryStream. There will be a basic transmission protocol, containing information for the length of the data, the sender ID, as well as the data itself, as well as a data compressor. Both may be optionally used, but it's not required. Using the transmission protocol could come in handy for most people because it will contain a reader and writer basic data types, and convert everything into raw bytes. The bytes will be sent in packets of four bytes per Unity update cycle. So it's both a serial and parallel transmission - serial transmission of four-byte chunks. The Data Recorder will be using Telemetry Radio to send telemetry data, sensor data, and the like, and when it arrives on Kerbin, it will be written as a CSV. Data Recorder will allow the user to pick variables to log, and the frequency, and they will be logged accordingly. However, because the Data Recorder hard disk part isn't infinitely large, you have to be careful not to record data too often if you're going to have a large blackout period, or it will start overwriting the beginning. Data Recorder will send all of its data on a single channel, one variable at a time. So, if you wanted to, you could use Telemetry Radio to create a mod that transmits sounds from your space craft, but everything would arrive on a delay. As long as you know how to encode and decode the data, and your mod is equipped to handle data in mid-transmission, you can transmit anything you want however you want. I expect that, if people actually create mods with Telemetry Radio, the eight channels will not be enough. Especially since doing both input and output requires two channels. Therefore, I am planning, for the future, to release a version that allows multiple signals to be multiplexed onto a single channel.

While RemoteTech allows you to control your spacecraft across the expanses of the solar system, there is, to my knowledge, no existing mod that allows you to transmit data back to Kerbin within the restrictions of RemoteTech. BTW, when I say "data" I mean real information, in the form of bytes. This is not a science-currency-making mod, this is a science-making mod. This mod will really be two separate mods: a Telemetry Radio, and an on-board Data Recorder, both of which being RemoteTech-compatible. The Telemetry Radio will consist of five things: a transmitter, a receiver, "air", a standard data transmission protocol, and a lossless data compressor (Huffman coding). A craft will be able to transmit data into space, and any listener (other craft, KSC, etc) that has a connection, will receive the signal, with the appropriate delay. The Telemetry Radio mod should be considered a basic framework from which to build other mods that wish to transmit data non-instantly. Transmission will occur on one of eight possible channels, and the receiver must tune to the channel it wants to receive the data it expects. Of course, the biggest restriction to Telemetry Radio is that it requires you to have a connection in order to receive any full message. This is where Data Recorder comes in. Data Recorder will have two areas: a hard drive part on which to temporarily store data awaiting transmission, and an in-game GUI which lets you chose which game variables to record and transmit. Data Recorder allow you to send a craft someplace where it may have an intermittent connection to KSC. The data is recorded on the craft hard drive until a connection is established, and then the recorded data is transmitted back to Kerbin. Source: https://github.com/griderd/TelemetryRadio UPDATE This mod is dead-ish. Please view the revived version of this mod here: http://forum.kerbalspaceprogram.com/threads/100781-WIP-Telemetry-Radio?p=1553448&posted=1#post1553448

I don't know if anyone was able to come up with a solution for this, but I'm having the exact same problem. Deedo's RemoteView is non-functional, as is my own project. My project is written in C#, using WebSocket4Net. I know my project works, because I've tested it with ws://echo.websocket.org. The connection occurs and is open. I don't get an error, but I never get a reply from the server.

Alrighty, thanks! If I use a portion of my external library, I will probably make that portion open-source.

I have a random question for those of you that have modded before. I have the thought of using an existing DLL that I wrote a few years back as part of this project, in order to make things a lot easier. This is the problem: the code for that project is closed-source. Obviously, as I wrote it, I could easily make it open-source, but I'd rather not. Does anyone know if I can use the library in question, or will I have to make portions of it open-source?

Well, I put in a little bit of work tonight, mostly to do with what I was working on before break. I leave you, however, with a feature that I finished a few weeks ago, and I'm quite happy with: simplified plugin function registration. The old kOS function registration looked something like this: vessel.parts.ForEach(part => part.SendMessage("RegisterkOSExternalFunction", new object[] { "test", this, "TestFunction", 0 })); I hated it. It was long, unreadable, and nightmarish. This is the new function registration method: Functions.RegisterFunction("test", 0, new Func<string>(TestFunction)); This utilizes a static function in Jebnix.Functions. The Functions class stores all functions that are registered with Jebnix inside a Dictionary, using a unique name and a Delegate. The RegisterFunction function syntax is: public static bool RegisterFunction(string name, int paramCount, Delegate ptr) where: name - Script-side function name paramCount - the number of parameters the function has ptr - A Delegate that points to your function By the way, you can call other external functions from your plugin. This is how the standard library works! Here's a full class that I use to test this: using System; using System.Collections.Generic; using System.Linq; using System.Text; using Jebnix; using Jebnix.stdlib; using Jebnix.Types; namespace ExternalFunctionTest { public class Class1 { const string TEST_NAMESPACE = "test"; public Class1() { Functions.RegisterFunction("test", 0, new Func<string>(TestFunction)); Functions.RegisterFunction("librarytest", 1, new Action<Value>(LibraryPrintTest)); Functions.RegisterFunction("getnumber", 0, new Func<double>(GetNumber)); Functions.RegisterFunction("externaltest", 0, new Action(ExternalCallTest)); } /// <summary> /// Returns "This is a test function." /// </summary> /// <returns></returns> public string TestFunction() { return "This is a test function."; } /// <summary> /// Prints "This is a library test." to the screen via stdio, along with the string value given. /// </summary> public void LibraryPrintTest(Value value) { stdio.PrintLine("This is a library test. " + value.StringValue); } /// <summary> /// Prints "This is an invocation test" to the screen via the registered function "stdio_println_1". /// </summary> public void ExternalCallTest() { Functions.InvokeMethod(Functions.STDIO, "println", "This is an invocation test."); } /// <summary> /// Returns the number 10. /// </summary> /// <returns></returns> public double GetNumber() { return 10; } } }

Well, back to it. I'm going to start coding again this week, if I have time. I've been thinking about a few details that I will talk about later. Just wanted to let you all know that I'm back.

Spring break is upon us, and so that means I'm taking a big break from everything, including writing this mod. Alas, I have another project that is far more demanding of my time and energy that I must work on this week: planning my wedding. Therefore, I shall continue work again next week. I likely will not be responding to things on the thread until the weekend, but I will be answering PMs. Thanks for your support everyone!

In short, no, I haven't had any time to code over this last week. The FOR loop isn't on my current list of things to be coded. I design each component in five phases: conceptualizing, preliminary design, detailed design, coding, and testing. Testing: WHILE loops Currently coding: Input/Interrupts Detailed design: Static/dynamic arrays Preliminary design: FOR loops and FOREACH loops Conceptualizing: Basic encapsulation Either way, I hadn't exactly planned on hammering out a detailed specification of the FOR loop quite yet, which is why it sounds like it's all over the place and this is now the only place I have anything written down for it. The way I look at it, unless it's coded AND written in the official documentation AND in the final release, it's not set in stone. In fact, there are things I'm adding that aren't in the list on the first post, because they are so far down the line that it will be a few weeks before I get to it. This is the thing: I'm adding for loops. I'm HOPING to make them work like C-style loops, and if you really go crazy and want them to, they probably can. That's not what they're designed for though, and you can tell simply from the syntax that its whole job is to increment in various ways through a set of numbers. KerboScript has always been a "toy" language designed to make rockets fly, that's easy enough for anyone to pick up. Everyone should just be happy with the idea that for loops are going to be included. Arguing over which language to implement, and arguing over the detailed implementation of a feature that is two weeks away from implementation just wastes your time and mine, and delays the release of this mod.

Be warned, this is going to be really ugly, and is, admittedly, more of a hack of the language than anything else. //set needle to "some string I'm looking for". //declare haystack[]. //set haystackSize to haystack:length. //declare min. //declare max. //declare middle. //declare cmp. // OPERATORS IN USE: // Assignment: both TO and = work. // Equivalence: both = and == work. I prefer ==. // Ternary operator: iif(x,y,z) is equivalent to (x ? y : z). I have not implemented this yet, but it is planned, just not listed in the official wishlist. This is really a function built into the language (as opposed to a library function). // And operator: & and AND both work for boolean and bitwise AND. // Or operator: | and OR both work for boolean and bitwise OR. // Not-equal operator: != for not equal. for set max to haystackSize. min from 0 to max | cmp != 0 step 0. iif(cmp < 0, set max to min + middle., set min to min + middle.) { set middle to ((max - min) + 1) / 2. set cmp to needle == haystack[middle]. if cmp == 0 { // hit was found at index "middle" } else { // hit was not found } } // loop is equivalent to set max to haystackSize. // commands found before FROM are treated like ordinary commands. set min to 0. // the last expression before FROM is assigned the expression after FROM. while min <= max | cmp != 0 // the <= is implied by comparing initial values of min and (max || cmp != 0). This can be changed via a convoluted hack: for min from 0 to min & min < max { set middle to ((max - min) + 1) / 2. set cmp to needle == haystack[middle]. if cmp == 0 // in KerboScript++, booleans and integers are interchangeable. Non-zero is always true, and zero is always false. However, assigning an integer from a true boolean does not guarantee any particular non-zero integer. { // hit was found at index "middle" } else { // hit was not found } set min to min + 0. // this cycle isn't wasted, because it's executed in the same cycle as the line below. LOOOONG story. iif(cmp < 0, set max to min + middle., set min to min + middle.). } It's possible. It's ugly as heck and requires quite a few hacks. My parser may know its way around error messages, but all-in-all it's pretty dumb and does as many things statically as possible, mostly in the name of language simplicity. Why anyone would want to do that type of thing in this language, I don't know. All-in-all, I don't recommend it. But like I said, it is possible. One day, I will build the language to compile to bytecode, but not today. Right now, it just kind of goes with the flow. So, in short, is the for-loop I designed intended to do this type of thing? No. It's just supposed to be a way to increment through a series of values. It CAN do things that are more complicated than that, but why you'd want it to is beyond me. By the way: // infinite for-loop // equivalent of: for (; { } for x from x to x { } // or for x from true to true { } // or for x from 0 to 0 { } // or... you get the idea // even better: while (true) {}

The break statement as well as the continue statement will be implemented.

The definition of a for loop, according to cppreference.com: "Executes init-statement once, then executes statement and iteration_expression repeatedly, until the value of condition becomes false. The test takes place before each iteration." C/C++ Syntax: for ([I]init-statement[/I]; [I]condition[/I]; [I]iteration_expression[/I]) [I]statement[/I] Which is equivalent to: [I]init_statement[/I]; while ([I]condition[/I]) { [I]statement[/I] [I]iteration_expression[/I]; } In Visual Basic.Net, according to MSDN: In KerboScript++: If the value of D is not given, it is assigned once, ahead of the loop executing, based upon the values of B and C. By default it is set to 1, or -1. The ternary expression I gave is actually wrong, I meant it as D = C - B >= 0 ? 1 : -1 for x from 1 to 5 { } for y from 5 to 1 { } Is equivalent to: for x from 1 to 5 step 1 { } for y from 5 to 1 step -1 { } Is equivalent to: set x to 1. while x < 5 { set x to x + 1. } set y to 5. while y > 5 { set y to y + -1. } While these.... set a to 5. for x = 1 to a step 1 { if x > 3 { set x to 10. // loop ends after this line } } // this is an infinite loop for x = 1 to a step 1 { if x > 3 { set x to -5. } } for x = 0 to a step 3 { if x > 2 { set a to 10. } print x. } // this loop prints: // 0 // 3 // 6 // 9 Are equivalent to, in C/C++: int x, a = 5; for (x = 1; x < a; x++) { if (x > 3) x = 10; } for (x = 1; x < a; x++) { if (x > 3) x = -5; } for (x = 0; x < a; x+=3) { if (x > 2) a = 10; printf("%i\n", x); }

It never changes the expressions it's provided, and if no increment value is provided via STEP, the increment value is statically determined only once ahead of the loop, and then set as a constant literal. I'll put it this way: Jebnix stores the expression tokens it needs and pushes them as metadata onto the call stack at the top of the loop. Whenever the end of the loop is reached, the expressions are popped off the call stack, and evaluated to determine whether to continue the loop. The expressions never change from the original ones they're given, and the variables only change according to what they are told to do. Loops in Jebnix will operate EXACTLY the same as loops in C/C++/Java/C#/Visual Basic, and pretty much any other language you would come across.

The + operator is playing three rolls: as the addition operator, the string concatenation operator, and the unary "positive" operator. Which it uses is determined by context. Most of the operators use a set of rules, where, in the case of A ~ B, where A and B are operands, and ~ is an operator, if A or B is a string, do one thing. If A or B is an integer, do something else. If A or B is a double, do a third thing. In any other case (like A and B are both strings), cast them to some predefined type and perform the correct operation: Example: the binary + operator If A is a string, or B is a string, convert A and B to strings and concatenate. Return a string. Otherwise... If A is a double, or B is a double, convert A and B to doubles and add. Return a double. Otherwise... If A is an integer, or B is an integer, convert A and B to integers and add. Return an integer. Otherwise... If A is a boolean, or B is a boolean, convert A and B to integers, add them, and convert back to a boolean (non-zero is true, zero is false) Otherwise... If A is an ordered pair, or B is an ordered pair, convert A and B to ordered pairs and perform a element-wise addition. Return an ordered pair. Example: the binary - operator If A is a double, or B is a double, convert A and B to doubles and subtract the B from the A. Return a double. Otherwise... If A is an integer, or B is an integer, convert A and B to integers and subtract the B from the A. Return an integer. Otherwise... If A is a boolean, or B is a boolean, convert A and B to integers, subtract B from A, and convert back to a boolean (non-zero is true, zero is false) Otherwise... If A is an ordered pair, or B is an ordered pair, convert A and B to ordered pairs and perform an element-wise subtraction. Return an ordered pair. Otherwise... Convert A and B to doubles, regardless of type, and subtract B from A. Return a double. Source code for these operations can be found here (this link takes you to the file and line number where operator overloads begin): https://github.com/griderd/Jebnix/blob/master/Jebnix/Types/Value.cs#L279 That's why there's a difference between print "2+2=" + (2 + 2). and print "2+2=" + 2 + 2. Operations are performed using order of operations, and left to right, just like most ordinary math. The first code results in "2+2=4", while the second results in "2+2=22". The first expression has the evaulator perform the operation in the parentheses first (integer addition), then the operation outside (string concatenation). The second expression has the evaluator perform the operations left to right, starting with a string concatenation, which results in a string, followed by another.