ninnghazad wrote:in case you are wondering why nothing is happening, i'm waiting for https://github.com/minetest/minetest/pull/1737.
and to be true, i don't think anybody actually feels responsible for pull requests from outside, on the contrary - there are >100 pull requests and most of these will be wasted time.
and i'm not bored enough to care, and i don't care enough to beg, so until stuff moves forward imma do something else.
laggy
dronetest.sys.loadApi = function(name)
local api = getApi(name, dronetest.sys.sandbox)
local env_save = table.copy(dronetest.userspace_environment)
local env_global = getfenv(api)
-- [[ debug code removed for post brevity ]]
-- Make drone/computer's env available to APIs, with id and stuff
--env_save.dronetest = getfenv(0).dronetest
env_save.sys = getfenv(2).sys
env_save.print = function(msg) dronetest.print(env_save.sys.id,msg) end
setfenv(api,env_save)
return api()
end
sys.loadApi = function(name)
local apifunc = getApi(name, sys.sandbox)
--following line now unnecessary, replaced by closure from containing function
--local env = table.copy(dronetest.userspace_environment)
local apienv = setmetatable({}, {__index=env})
setfenv(apifunc, apienv)
return apifunc()
end
To send commands to a drone, you open a connection to it and then send it commands. Any response data from the drone goes in the send_ack, although I didn't really explicitly say that in the protocol draft.
control drones over radio (which we should do)
Object identifiers are only used to initiate a connection (with open).
All external peripherals, including drones, should be controlled through digilines.
centralizing the event system
I see that you give rom programs access to the minetest table. This is a very bad idea. Any scary things like this should be in apis. In fact, we should probably find a safer way than the apis folder.
multitasker kernel I want to implement is basically a really fancy version of ComputerCraft's parallel.
ninnghazad wrote:i see... but why not still have a direct method-call without open? would save some overhead.
ninnghazad wrote:we do, the transceiver is a drone-control-radio-digilines-peripheral. it connects per digiline-wire to the diginet, and per its own "wireless" with the drones.
ninnghazad wrote:k, i guess thats what i meant with message-id, i just noticed the badness of my naming, as it doesn't just describe a single message but a session of communication.
ninnghazad wrote:i don't have my mind fixed on anything with the protocol, probably am ok with whatever you think up. i can see you are knowledgable about it, so go nuts. my "complaints" just stem from not wanting to add too much overhead to simple tasks.
ninnghazad wrote:they are. even the drones. i have not explained myself well enough. the drones aren't nodes, like other digilines-stuff, but entities, like mobs.
entities cannot connect directly to digilines-devices, mainly because digilines does not support that.
the callback that is added to nodes to implement digilines, is not called on entities.
and if it would be, it probably wouldn't be called for entities floating around somewhere like drones.
this is where the transceiver comes into play. it is a node and has the callback.
it hangs in the digilines-network and listens for pakets addressed to drones and receives those for the drones.
the transceiver then acts as the drone's callback, and the drone executes it's stuff like any other peripheral.
it's not that i think this is so cool, a kind of modem-node simply is needed atm to make it work.
the transceiver at least makes it transparent, the player needs it, but does not have to talk to the transceiver,
but can act as if the drone's were simply connected by digilines-wires.
oh, and all digilines stuff in dronetest right now uses dronetest.events.
ninnghazad wrote:it's central, there's dronetest.events.* and all event-functions sit there. some have wrappers for userspace-access.
the point in storing the events that get passed around in active_systems is obvious i think.
keeping a shared table is error prone and has exponential loss of speed per device added when searching and so on.
ninnghazad wrote:ROM is not player writable. whatever is there comes with the mod or was placed there by an admin.
everything in /rom to me is to be treated like an api security-wise. open-backend, secure-frontend.
that's why i meantioned implementing your api-loader in shell.run, to have all calls to /rom handled exactly like apis.
of course that means that all progs/bins/tools whatever we put into /rom must be as securely written as an api,
like not return the minetest object and such stuff.
that last point may not be the case atm (lots of debug stuff in there), but thats the plan.
i can't see any insecurety in a ROM /rom folder itself, and like the approach.
if there are no bugs then the player cannot write to /rom, and has no chance to use any of the goodness without calling premade programs or apis from userspace.
and those apis and programs are no more insecure than any other userspace-bridge stuff.
if system commands or apis fail and give out sensible stuff, thats an error, which is to be avoided in any kind of userspace-bridge.
ninnghazad wrote:yes yes yes. registering event callbacks from userspace is already possible though. dronetest.events gets partly wrapped to userspace sys.events (or smth like that). but as mentioned with just this coroutines do not each get an event, and cannot listen on the same event. call it parallel, i totally want something like that. ComputerCraft's parallel was much more comfortable to use as a player than plain coroutines with events. a layer atop that with its own event duplication/redistribution will come in handy for lots of possible player-built-projects.
The overhead only happens when you initiate a connection, which should be pretty rarely.
so THAT's why drones won't work for me
If you come up with a better name
it's not impossible to make moving blocks.
O(n)
callbacks and listeners aren't done in userspace
Why is shell.lua an api and not a sandboxed program or at least a sandboxed library?
non-sandboxed things in the normal filesystem won't work...
Yes, but it should be done in userspace
I'm so concerned about security because
...inventory....removable drives....peripherals....
ninnghazad wrote:i guess in the drones case this would mean opening a connection when wrapping the drone, so no additional hassle for the player and only little overhead.
ninnghazad wrote:if you use the version of minetest from my fork (with the formspec-stuff in it) you can even try the keyboard-feels and type in commands instead of using that inputfield/exebutton-thing.
ninnghazad wrote:nono, that wasn't really the problem. actually the drones started out as blocks. but thinking about how to have them interact with nodes/mobs/players i ended up changing them. entities are better to animate, and other entities, like mobs, can interact/notice them with ease. also rotation and stuff just was more natural with entities.
there is a drone-node that looks like a drone, but it's only used by players to place drones.
that node turns into a real drone once placed.
the drone's actually perform really well.
however, as you like the modem-approach, i'd say things are well on this front.
ninnghazad wrote:a single list of events for all systems (not split by system)
ninnghazad wrote:well, there are some wrappers to provide the event-functions to userspace. this is simply because i wanted quick access to events from userspace. that doesn't mean that userspace couldn't have an additional "real" event-layer (even outside of parallel i mean). currently userspace-event functions just fetch/send events from the mod's main event-queues, where currently all events/signals pass through. i'm not sure about the advantage of having another layer (outside of parallel,where it is obviously needed for duplication and stuff) but it's ofc possible.
ninnghazad wrote:i did not use mesecon's (or any other 3rdparty) queue just because of speed considerations. i neither wanted to "pollute" the mesecons queue, nor loose control over how the internal queue works. a few peripherals and a complex piece of software running will result in tons and tons of events, i want to reduce tic-based latencies as much as possible - meaning events that trigger callbacks shall do so immediately, and not wait one tic for a pollingmechanism to trigger. without this, for example, a player typing on a keyboard-peri would have multiple tics of delay for his actions to appear on a display. it was like this at some point, and it was just terrible to use, so i made sure callbacks get called right away on sending events.
ninnghazad wrote:but shell will contain more then just the run().
ninnghazad wrote:maybe we should call the whole possible contents of /rom "modules", and not have it accessible through fs. that would in the end just mean that programs like ls would have to be in userspace, and be written as userspace-code, and stuff like the quarry or the tests (just as examples right now) would have to be turned into modules and a corresponding userspace-prog. ls would be userspace code that accesses fs-module. quarry would be userspace-prog that accesses peripherals-module, maybe a special drone-module with convenience-functions and other modules.
this would dictate the single point of entry as the module-loader (which would be your api-loader basically).
this would also relieve us of the api/lib/prog/tool/yomom namings, all that stuff is a modules.
they don't reside in fs at all, and only exist to players as the output of lets say dronetest.load_module().
the more i write "modules" the more i like the idea =). modulesmodulesmodules....
how about "modules", no /rom? such safe, very compromise?
ninnghazad wrote:oh, i was talking about userspace. that /rom/api/coroutine.lua is userspace-coroutines. nothing fancy, just wanted to make sure there is a way to have them without having luajit/minetest choke. but that changes what i said - these userspace-coroutines are no userspace-parallel for the same reasons i mentioned before. userspace-parallel totally welcome, u can look to the simple coroutines to see whatever it was i did to them to not throw cross-boundary errors (that happens because luajit and coroutines in coroutines in sandboxes and stuff, but as i said we can wiggle around that).
while true do foo() end
ninnghazad wrote:...inventory....removable drives....peripherals....
ye, i also have that in mind. but lets put that back a little and focus on basic peripherals while keeping internal ones in mind. there may be some items to stick into computers that aren't digilines-devices, like power-related stuff. not sure about the whole power thing really yet.
but yes, lets have that, but i would say it's not on the top of the list atm.
ninnghazad wrote:the ugly way a drone currently spits out items into the sky when there is no chest just cracks me up.
after like 5 minutes there are still ore's raining down from the sky. to good to fix =).
The shell should definitely be in userspace.
but you implementation searches the queue instead of just popping the oldest element off
My kernel does this, but in userspace.
Why does the quarry test need a module? It should just use digilines->modem->drone.
while true do foo() end
ninnghazad wrote:ye, thats ugly. i think i left it like that cause of the filters. so receive({"key","mouse"}) would eat up key and mouse events, but would not pop any other it is not supposed to return.
ninnghazad wrote:k, the userspace-wrappers for dronetest.events are ugly anywho. we just tweak dronetest.events to immediately feed userspace-events that come from outside ("key"-events ie.) to the userspace-queue or something. so that shell.* for example has access to key events, not just those generated in userspace.
ninnghazad wrote:having to parse and scan all player-lua using game-lua, and parse well too - so many ways to hide nasty loops and recursions. also this would mean that all player-lua's loops and whiles have to contain function-calls. and ah, that is kind of strange, one could work with it but having to write a function for every loop... meh.
Passing nothing to coroutine.yield
local queue = os.loadlib("queue")
local q = queue.new()
local popper = kernel.spawn("pop",
function()
while true do
coroutine.yield({"queue_push"})
local i = q:pop(i)
if i then
print(i)
end
end
end
)
local pusher = kernel.spawn("push",
function()
local i = 1
while true do
q:push(i)
i = i + 2
kernel.send(popper, "queue_push")
kernel.yield() -- like coroutine.yield, but guarantees that we get a turn next tick
end
end
)
kernel.wait(pusher)
kernel.wait(popper)
kernel.events.receive[_async](filter)/send(type) + kernel.events.*
function os.pullEventRaw(...)
return coroutine.yield(...)
end
ninnghazad via irc wrote:one thing about the example i don't get yet: kernel.spawn("bla" < whats the bla for? or is it just the name for the function?
ninnghazad wrote:request/response-bundling is a good idea. but make one version with immediate yielding. so that the player can have a single request with built in yield, or have the bundled request to be send upon the next manual/auto-yield. makes player's code a little shorter in cases of lots of conditionally depending peripheral-calls, like with drones.
local f = fs.read(path)
-- wait, do other stuff
local str = f:getdata()
local str = fs.read(path):getdata()
ninnghazad wrote:"request 20 files":
what about requesting really large files in chunks? i think C's basic filehandle-operations like fseek,fput/fwrite should be supported by protocol, and should be supported seamlessly by a fs-module using an implementation of the protocol.
so that to a player a disk/mem-peripheral used through the shell may feel like a hdd on linux (mount, filehandles and stuff).
ninnghazad wrote:nice idea for peripheral btw, have hdds for permanent storage and mem for fast shared (parallel) storage that does not get saved but with same/similar peripheral-interface.
ninnghazad wrote:at this point we will also have to consider how long it may take to read a large file in a single go - we will need to make sure that actual reading of files on the server happens in a chunked and buffered manner with possible yields between chunks. this will make reading of large files slower, but is the proper way to go i think - otherwise players would be able to introduce uncontrollable io-load and could make the server choke. size of rw-buffers must be strictly limited ofc.
ninnghazad wrote:also i have an idea for preventing users from trying to overflow memory, but will have to try stuff first.
Users browsing this forum: No registered users and 3 guests