On Tuesday, April 12, 2016 at 3:22:50 PM UTC, Aaron R. M. wrote: > > Hey I'm looking for a solution to some problems that i have using Julia as > a general purpose language. > Given that there are no access modifiers i cannot restrict people calling > functions i don't want them to call. > Use case is a game (yeah that's somewhat new territory) that has its > codebase (provided by me) but allows scripting the environment (within some > borders also outlined by me). Examples would be spawning some > plants/animals etc. manipulating what happens on clicking and so on. All > stuff that changes your experience in the game. > > But i clearly don't want people do be able to accidentally harm their > computers by downloading/removing/creating anything in their file system. >
As I think you may know, Julia is not a sandboxed environment (like the JVM, or I guess similar in Android). I've been meaning to write a post on this.. There is some old one if I recall. I would like there to be a safe subset of Julia. As ccall is a keyword, I'm not sure if it can be disabled. Basically, when you can call another lower level language (C) with that, all bets on safety are off (this is like with JNI in Java, while the permission is off by default there, right). For many users, ccall is critical for getting Julia popular, even if they do not use directly then indirectly through libraries. I find it amazing how self-sufficient Java programmers have gotten in a sandbox (for their needs, I guess most suff has been implemented in Java). > The other obvious reason is that i don't want people to be able to open a > file stream download a virus and execute it (what theoretically would be > possible). > Right, if there is not a sandbox, finding out if your code ends up using ccall, imples the "halting problem", proofably not possible. See here on limitiing Julia power (as must happen for when compiling to static binaries, and not embedding the compiler): http://juliacomputing.com/blog/2016/02/09/static-julia.html "Or if a program written in a dynamic language doesn’t use eval, then it can be transpiled to avoid the runtime interpreter[1]." eval is one of your problems, if you get around that one, disable ccall (limitting to Julia only code..) and run julia with "yes": --check-bounds={yes|no} Emit bounds checks always or never (ignoring declarations) I think Julia could be made safe. Am I missing something else? Is this a 3D game? The garbage collection could be a problem.. There are ways around (as Lua does, disabling in vblank). And there is Libc.malloc etc. This is no problem in a singleplayer game but imagine it being multiplayer. > This case could also be handled by just not sharing stuff or having no > multiplayer but i think you get my problem. > > The next problem that also results from the very same game idea was the > following: > Mind you've got some automation tool that does anything on its own (like > protecting you like a shield) now say this shield does something scheduled > as well. Since this is all coded by the player there are no real hooks in > his code. So what can i do to preserve the current state of the execution > of this script in case he leaves the game or pauses it. (Means i need > something to make the current execution state persistent aswell as being > able to stop it at any given point and of course resume it later) > This problem leads to something similar to an interpreter or even debugger > (or even more abstract a VM, but i think that'd be overkill) but for the > current existing ones they clearly don't focus on persistence and the > ability to yield after like 10 execution steps. A perfect solution to this > problem would be some sort of scheduler for the interpreter/debugger that > can save the state of it's scheduled program. But sadly something like that > doesn't exist (at least i didn't find it). > > So are there any tips/workarounds to come nearer to my dream of game? > Partial solutions/solutions/ideas etc even for "only" one of the problems > are highly appreciated. > > Of course i know these problems are very special but I'm sure that having > more people reading it might result in some very nice ideas. >
