{"action":"created","issue":{"url":"https://api.github.com/repos/KSP-KOS/KOS/issues/717","labels_url":"https://api.github.com/repos/KSP-KOS/KOS/issues/717/labels{/name}","comments_url":"https://api.github.com/repos/KSP-KOS/KOS/issues/717/comments","events_url":"https://api.github.com/repos/KSP-KOS/KOS/issues/717/events","html_url":"https://github.com/KSP-KOS/KOS/issues/717","id":66087203,"number":717,"title":"Can't call program functions from interpreter or visa versa.","user":{"login":"Dunbaratu","id":5216848,"avatar_url":"https://avatars.githubusercontent.com/u/5216848?v=3","gravatar_id":"","url":"https://api.github.com/users/Dunbaratu","html_url":"https://github.com/Dunbaratu","followers_url":"https://api.github.com/users/Dunbaratu/followers","following_url":"https://api.github.com/users/Dunbaratu/following{/other_user}","gists_url":"https://api.github.com/users/Dunbaratu/gists{/gist_id}","starred_url":"https://api.github.com/users/Dunbaratu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Dunbaratu/subscriptions","organizations_url":"https://api.github.com/users/Dunbaratu/orgs","repos_url":"https://api.github.com/users/Dunbaratu/repos","events_url":"https://api.github.com/users/Dunbaratu/events{/privacy}","received_events_url":"https://api.github.com/users/Dunbaratu/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/KSP-KOS/KOS/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2015-04-03T06:20:36Z","updated_at":"2015-04-20T21:01:01Z","closed_at":null,"body":"This is an issue I knew about but didn't think it was important enough to delay a 0.17 release.  But I shouldn't make that decision unilaterally so I want feedback from other devs, especially @erendrake.\r\n\r\nThe problem is when you want to bridge across the barrier from program commands to interpreter commands.\r\n\r\nIf you write several declare function statements in a script file called ```mylib.ks```, and then ```run mylib.``` *from another script file* it works as expected and that other script file can call the functions in ```mylib.ks```.  BUT if you do ```run mylib.``` from the interactive terminal window, then the interpreter cannot run the functions that were inside mylib.  They will appear to be nonexistent.  Similarly, if you type a ```declare function...``` command in the interpreter, the interpreter can call its functions, but a script file cannot call it.\r\n\r\nThis is because the interpreter and the script runner \"live\" in different program contexts.   (They are two different List&lt;Opcode&gt; \"machine code\" chunks.)  It may be possible to change this but doing so may or may not have cascading issues that affect other parts of the mod.  The fix would end up being one of two things:\r\n\r\nEither\r\n\r\n(A) A function variable, instead of containing just a single integer for the jump location to enter the function, would also contain a field mentioning which program context that locatioin lives in, the interpreter or the program context - thus the OpcodeCall would be able to read that and know which one of the two to jump to.\r\n\r\n(B) Change how scripts are compiled so that they end up living in the same program space as the interpreter does.  There already exists logic for whether or not the compiler should \"compile into same address space\" or not, and it is used when one program calls another program.  It is potentially possible to have the programs load into the interpreter's memory space so they all live together.\r\n\r\nEither option would also mean having to deal with figuring out when to \"throw away\" a program from memory.  Right now it's dealt with by merely orphaning the outermost program's program context after the interpreter's run command is done - that makes the structure holding all the compiled opcodes for it vanish.  But if programs that are run from the interpreter need to leave their functions in memory to be used by the interpreter after the run is finished, that would mean we would leave the program in the interpreter's memory for..... for.... how long?  Dunno.  Depends on if the interpreter will try to call one of its functions again or not, which since you can't scan ahead and see what the user will type in the future, you can't tell.\r\n\r\nIt's that last issue that made me consider this too thorny an issue to allow it to delay 0.17 release.  Fixing it would be unpleasant because of the issue of persisting the program after the run is done, and having no idea how long to persist it for, or how to purge it when re-running it so you don't run the stale old copy, etc.  (again, right now it does that by merely making a brand new program context to compile into - it already threw away the old one.)\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/KSP-KOS/KOS/issues/comments/94567138","html_url":"https://github.com/KSP-KOS/KOS/issues/717#issuecomment-94567138","issue_url":"https://api.github.com/repos/KSP-KOS/KOS/issues/717","id":94567138,"user":{"login":"abenkovskii","id":11031560,"avatar_url":"https://avatars.githubusercontent.com/u/11031560?v=3","gravatar_id":"","url":"https://api.github.com/users/abenkovskii","html_url":"https://github.com/abenkovskii","followers_url":"https://api.github.com/users/abenkovskii/followers","following_url":"https://api.github.com/users/abenkovskii/following{/other_user}","gists_url":"https://api.github.com/users/abenkovskii/gists{/gist_id}","starred_url":"https://api.github.com/users/abenkovskii/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/abenkovskii/subscriptions","organizations_url":"https://api.github.com/users/abenkovskii/orgs","repos_url":"https://api.github.com/users/abenkovskii/repos","events_url":"https://api.github.com/users/abenkovskii/events{/privacy}","received_events_url":"https://api.github.com/users/abenkovskii/received_events","type":"User","site_admin":false},"created_at":"2015-04-20T21:01:01Z","updated_at":"2015-04-20T21:01:01Z","body":"\"That's what is expected from not implemented enhancement.\"\r\nMy explanation of my thoughts is terrible, I mean that I expected one exception in **this** particular scenario."}}