Kode for Unity(In game editor)

[TN-1]

Thanks to Dunbaratu's tip about the compiler I think I have a basic understand of how it goes but I just want to clarify a few assumptions I have made.
For the most part, I think I can ignore the majority of the function for kOS(run) and so I am left with this bit which obviously does all the work:

string filePath = string.Format("{0}/{1}", shared.VolumeMgr.GetVolumeRawIdentifier(targetVolume), fileName);
var options = new CompilerOptions { LoadProgramsInSameAddressSpace = true, FuncManager =   shared.FunctionManager };
List<CodePart> parts = shared.ScriptHandler.Compile(filePath, 1, file.ReadAll().String, "program", options);
var builder = new ProgramBuilder();
builder.AddRange(parts);
List<Opcode> program = builder.BuildProgram();
shared.ProcessorMgr.RunProgramOn(program, targetVolume);  

For my purposes, I won't need line 1(I will have the filepath already worked out and can just use that)
Assumption 1: shared.ProcessorMgr.RunProgramOn(), Thats the command that runs the just compiled script on the VM? If so, I can get rid of it.
Assumption 2: Script.ksm is a file with extension .ksm that is filled with the contents of List program. If so, After that line I would then have a File.Save(file.ksm, program.ToString(Id need to parse it myself most likely)
Thanks!

[Dunbaratu]

This issue is missing any introductory explanation of what you're trying to do.

[TN-1]

My bad. I'm working on adding compilation capability to Kode, And so I need to integrate the kOS compilation function into my code. I think I have it worked out, Just had those few questions I wanted to ask before I spent any significant amount of time getting it working in case I was looking at the wrong bit.

[Dunbaratu]

Your two assumptions are correct, plus I'd like to mention that RunProgramOn() is probably broken. It hasn't been updated in a long time and we're not really using it. Once there was a system to run programs on a "foreign" CPU and it was really messy so we backed off.

[Dunbaratu]

Also, there's a chance that you might have to slightly change a bit of the code when we get the new subdirectories PR merged in, so just be on the lookout for that one. It's #1567 .

[TN-1]

Yay, I like it when things are simple.
About RunProgramOn(), That won't be a problem, I won't have any need to include it on my end.
Looks like the only changes in that PR that would affect me are a few variables getting renamed, I'll keep my eye on it though incase something bigger changes.
Thanks for the help :)

[hvacengi]

I'd also like to point out that I have a pending PR that works on a number of these similar issues: #1552.

I would recommend you hold off on a major change until after that PR gets updated and merged, or that you work with that branch as well. I know it currently has conflicts, but it hasn't been a huge priority for me with 1.1 looming so I haven't bothered to update it to the current develop branch.

RunProgramOn() is definitely broken, we had a bug report on it a while ago where we basically said we forgot that it still was a thing. It's undocumented, and should have been deleted a while ago. It technically means changing around a few opcodes to do it right, not just deleting that section of code which is why it hasn't been done yet. I'm pretty sure that Tom took out the inter-processor stuff in his communication PR.

It looks to me like the code you are referencing above is from the run function. I'd say for your purposes you're rather reference the load function. Specifically these lines:

KOS/src/kOS/Function/Misc.cs

Lines 280 to 295 in d547422

	if (shared.ScriptHandler != null)
	{
	shared.Cpu.StartCompileStopwatch();
	var options = new CompilerOptions { LoadProgramsInSameAddressSpace = true, FuncManager = shared.FunctionManager };
	string filePath = shared.VolumeMgr.GetVolumeRawIdentifier(shared.VolumeMgr.CurrentVolume) + "/" + fileName;
	// add this program to the address space of the parent program,
	// or to a file to save:
	if (justCompiling)
	{
	List<CodePart> compileParts = shared.ScriptHandler.Compile(filePath, 1, fileContent.String, string.Empty, options);
	VolumeFile volumeFile = shared.VolumeMgr.CurrentVolume.Save(fileNameOut, new FileContent(compileParts));
	if (volumeFile == null)
	{
	throw new KOSFileException("Can't save compiled file: not enough space or access forbidden");
	}
	}

After #1552 is finished though, it should provide you a clean and easy path for running the compiler, as well as a small test shell within your IDE. To "properly" compile with true support for built in functions you'll need these changes. Technically trying to call a built in function should still work even if the compiler does not recognize the function. My PR includes the ability to add "dummy" function stubs so that built in functions are still recognized, even though they cannot be executed in the stand alone console program.

[TN-1]

#1552 looks really interesting. I think I may just hold off on the compilation update until that is ready. Do you have any rough timeframe on when it will be done?
Reason for thinking that is it's getting pretty complicated and out of my knowledge to try and hack into the compilation function because it is all designed to run while KSP is and so everything is going null. As soon as I fix one thing another issue pops up which leaves me scratching my head for 10 minutes.

In the future, it would be nice to expand it to have a graphical interface, capable of listing all files in the archive folder (or any arbitrary folder for that matter) and then selecting multiple files to compile. In theory we could set it up to compile multiple files in parallel at that point.

About this quote, If you would like I will offer up Kode as being that future graphical interface. Kill 2 birds with one stone, You get your tool and I get my compiler.

[hvacengi]

It won't be ready in the initial 1.1 compatibility release, but I think I'd like to have it in the v1.0.0 release if possible. So within a couple of weeks of 1.1 dropping.

[Dunbaratu]

On the issue of integrating Kode into kOS, what \was actually being looked for in that quote was something that runs inside the game (so that means the whole GUI has to be done through Unity, and the editor class would be an instance of Monobehaviour). There's another person who was trying to work on a KSP mod that gives you that in-game editor, but its a lot more primitive than Kode and it's not as far along: http://forum.kerbalspaceprogram.com/index.php?/topic/133573-early-wip-kos-editor/#comment-2443830 .
But, it has the "advantage" of existing inside the game itself, as a Unity project. I know that changing Kode to work that way would be seriously frustrating for you at this late stage, and the available GUI widgets in Unity to build the editor with are obviously going to be a bit more primitive than ones made for a windowed interface.

[TN-1]

@hvacengi, Thats not so bad. Just swap this release with the next and that should make up the time.

Ah I see.
Just from a surface level, Most of the logic should be pretty easy to bring over. Id just need to strip out all the winforms stuff. It shouldn't be overly difficult to branch off the work I have done so far and adapt it to run inside unity. It opens the door to have some more in depth communication between Kode and kOS if there is a version of Kode running inside the game, The two separate instances could work together to make it easier to rapidly develop scripts.
If you guys are interested in this idea, I will certainly take a serious look at it.

[Dunbaratu]

@TN-1 , while I really like the idea of having a nice in-game editor partnered in with kOS like that, I also don't want to impose if it turns into a lot of work for you. Architecturally if we do end up doing it, it would probably be a good idea to still keep the two as separate projects with their own DLL's and their own github repos, but maybe we can provide some externally call-able hooks into our DLL for you, and visa versa with you for us to call, to make the two talk to each other but not in a way that ends up requiring one to exist for the other to exist. When it comes to the architecture of C# and .NET itself in order to pull that off, @erendrake is a much better expert than either @hvacengi or myself.

[TN-1]

Wouldn't be anymore work for me than Kode already is. I would most likely fork off my current code base, then replace all the Windows specific UI code with Unity controls. Most of the non-UI related code should be easily ported over. Using the existing kOS terminal code as a start point and I only then really need to come up with a Unity based TreeView and the rest of the UI elements which I should just be able to use stock Unity controls. Once I have done the initial transition I don't see it being too hard to port over new features as I implement them into Kode(Prime) where appropriate.
I definitely agree on the separate DLL's though, and as for communication between our separate entities, Something like the Microsoft Extensibility Framework(Supported by Mono as far as I can tell) could be very useful. Im planning to slowly add it into Kode as a way to support third party plugins, but with some planning between you guys and I we should be able to implement it as a way for kOS and Kode(Unity) to talk.