payonel

Hi @lukeh990 saw your message in irc. you only stuck around in irc for 7 minutes after you pinged me I hope you give irc and troubleshooting this issue with me more again.

is it a local game? can you zip up your entire minecraft instance of that pack and share a link for me to download? if you dont have a place from which you can share it, I can create a cloud folder. just private message me in irc (oc on esper)

ideally it repros with OC only and all we need is a world tarball.

ideally i don't have to use another launcher, but can just drop the world, config, and mods in an mmc instance

try copying the world to a new pack that contains OC only, turn off power requirements for oc in the config then start it up and let fml drop all the blocks you've removed support for, test the machines and see if they still fail.

if anyone is able to create a simple repro, with a TINY number of mods, and are able to pack that into a zip, then share that zip with me (here, or in our #oc irc channel) i WILL look into this

the problem i have is that this does not repro for me

functions have to have an `end`

local event = require("timer")
event.timer(2, function() print("do something") end,3)

aye, the threading library is part of openos. without installing it, you've got not thread api

My solution to your issue would be to put a timeout on computer.pullSignal. If it times, execute the next pending command (if there is one)

First of all, if you pull off getting our machines to run without forced cooperative yields....that's just awesome. I'm pretty excited about the work you did with eris already.

Secondly, a fixed user-defined __gc solution also sounds very nice, but raises new risks. I would like to suggest we look at these two features separately. Obviously, the gc work coming after. The problem with __gc code is that debug hooks are disabled during __gc code execution. So a user could rob the thread and we'd not be able to yield it. So unless you have found a way to execute gc code WHILE not disabling debug hooks -- this is not something we can have enabled by default. (but still a thing we should fix, as yes, the current implementation is not perfect)

Thirdly, At this point, you can make a github issue as a feature request. We'll hold off making a PR until we have all the pieces and scope agreed on. You can also discuss these issues with me in a more real-time medium on our irc channel (esper.net) #oc

it's a limitation of eris (edit: that is to say, eris is incompatible with hooks)

components send signals, and the screens send touch events.

for more signal info read here: https://ocdoc.cil.li/component:signals

and you should run `dmesg` on the command line shell, which prints all signals the machine is getting. it can be quite helpful

I appreciate the study you've put into this. You aren't alone; we also care deeply about these issues.

The reason we don't do pre-emptive scheduling actually isn't due to yielding issues from the debug hook (as you've demonstrated) but because we can't persist the lua runtime state in a suspended debug hook. In other words, if the minecraft world chunk were to unload whilst we have a coroutine-in-a-suspended-debug-hook, then upon loading that lua state again (when the chunk loads again), we'd be forced to "stop" the machine. On the other hand, we definitely CAN persist when the root-level coroutine yields back to the machine (which is what you get when you call computer.pullSignal)

I'll try to explain what is happening in the perspective of the lua compiler

In this code chunk, we are assigning buildWitherButton.onTouch to a function.

powerButton is declared in the local scope previously, and is captured (linked) from the current scope

throwWitherBuildError is not declared, and thus no variable is linked. When executing this code, access to this variable will be checked in the global scope, _G. If when this code is executed there is no _G.throwWitherBuildError then it will resolve as nil.

clearAndInitProgressBar is declared in the local scope previously, and is captured (linked) from the current scope

event is declared in the local scope previously, and is captured (linked) from the current scope

buildWitherButton.onTouch = function()
  if(powerButton.pressed ~= true)
  then
    throwWitherBuildError("Can't build Wither with shield down, are you mad?!?!?")
  else
    clearAndInitProgressBar()
    event.timer(1, progressUpdate, 10)
  end
end

Later we see this:

local function throwWitherBuildError(text)
  note.play(30)
  return GUI.alert(text)
end

which creates a local function throwWitherBuildError, and it is never used nor linked

btw, if the onTouch callback is made to an event.listern (inside the gui library you are using), which it likely is, then you would see the crash log in /tmp/event.log (it would be crashing because the assert of the 2nd argument is a function and NOT nil)

Looks like your you've declared `progressUpdate` after your used it, thus passing nil to event.timer for its 2nd argument. Which, btw, isn't allowed, it should error (it requires you pass a function there)

mounting is a kernel concept that puts a filesystem at a directory path, so you would implement that yourself

you'll see signals pertaining to filesystem components as they become available (see computer.pullSignal)

the (hardware) component library provides mechanisms to query available components, list methods, invoke methods, create proxies, etc

so, assuming filesystem_address is your hardware address for your filesystem component:

local fs = component.proxy(filesystem_address)

firstly, always declare your identifiers as local unless you intend to create global variables for use and effect in other scripts.

local component = require("component")
local printer = component.printer3d

secondly, you could iterate the component proxy, it is a table

for k, v in pairs(printer) do
	print(k, type(v))
end

or you can use the command line tool, components

/home # components

and you can list functions and doc details of component using the -l option, and you can filter the components listed specifying a name

/home # components -l printer3d

you could add this line to your .shrc

/etc/motd

btw, I made a typo (which I'll correct inline), I meant to say that (in regards to memory swapping) we cannot serialize all data types. So for a kernel to really swap memory, it would only be able to swap specific segments of data ... and could not force arbitrary user code to fully swap. It is sadly outside what Lua can do.

We kill the the current coroutine that is long running. So you can catch it yourself, in your kernel, without the kernel crashing. This isn't a detail of machine.lua, but rather, how lua hooks work.

And yes, I empathize with the challenge of that switch. Strangely I found have found that I enjoy the two contrasting worlds (lua <--> c++).

I appreciate the interest and enthusiasm. I disagree with a few of the points you've made if you would allow me to explain.

16 hours ago, Varscott11 said:

This combined with some clever mechanisms can result in an almost hybrid between preemptive and cooperative multithreading system with lightning fast interrupt (event) dispatching.

"almost" as in it isn't. Killing a thread pre-emptively is the only thing you can do in this case and that is not multithread nor cooperative. You can't resume coroutines from the same Lua state either. It isn't lightening fast, debug hooks are actually extremely costly. Also, we cannot persist debug hooks, thus when a machine is unloaded and reloaded in chunks, any state and special hook magic you might make would be lost.

16 hours ago, Varscott11 said:

The problem is that memory management is very limited without collectgarbage

We collect garbage when you've yielded 10 times. Also, lua state will collect garbage dynamically

16 hours ago, Varscott11 said:

stop a malicious program from infinitely allocating memory until the computer runs out crashing it

You can already do that, see pcall. Or, run untrusted code in a sandboxed coroutine. The coroutine will die if they OOM.

16 hours ago, Varscott11 said:

VIRTUAL MEMORY SWAP FILE:

We looked into this, unfortunately you cannot arbitrarily serialize all value types in lua.

Kernel Security:

There is nothing MORE secure about unboxing any part of the sandbox. In fact, you could just run the machine.lua code, again, inside minecraft, and run an OS inside that sandbox. Sandbox inception! You wouldn't have debug hook, but hooks do not increase security, we only use them for stopping long running processes. And you don't need to do that, we do it for you.

16 hours ago, Varscott11 said:

skipping the sandbox init if the config says to do so

We are not in favor of making it this easy for uninformed server owners to expose their private server environments to users. Users have brought this up before and we (developers) are in strong agreement about this.

Hopefully you're still reading this far, and not just mad at me for shooting down your sincere request, inspired by your obvious passion. I wanted to encourage you to ignore the constraints of the sandbox, and rather, look at what you really can do with developing a custom kernel. There is a lot more power than you might give credit to the system as it is. I whole heartedly agree that the virtual world in OC can be restricting, and at times extremely frustrating. I sympathize. Look at OpenOS. I have spent thousands of hours of my life developing OpenOS. WIthout a question, the single hardest part has been memory optimization and refinement. I'm a C++ developer (irl); I live in a world where I have complete and precise control over memory management (allocation, monitoring, profiling...). The way Lua allocates memory in chunks for its stack makes knowing the true cost of operations and new code actually very difficult to measure. I built an OC emulator primarily to provide a way for me to profile and measure memory usage. But none of this would have been "easier" outside the sandbox.

1. OpenOS doesn't add to nor remove from the debug library, what you see in OpenOS is available to all user space programs/custom operating systems

2. The debug library filtering/sandboxing occurs in the "hardware", before your eeprom code is executed, by our machine.lua (which builds the sandbox)

3. OpenOS has no kernel.lua and never has. OpenOS never calls debug.sethook anywhere. The machine.lua I mentioned (which again, runs OUTSIDE the sandbox, running unsandboxed, running lua code unavailable to OpenOS, unavailable to any user code), but this machine.lua used to be called kernel.lua -- renamed December 7th 2014. Yes, it uses debug.sethook, but users (and openos) are inside the sandbox.

for k in pairs(debug) do print(k) end

traceback
getupvalue
getlocal
getinfo

getlocal, btw, is limited, it only returns the first result (the name of the field, not its value)

I've developed a remote shell client and rc daemon called psh (payo-sh, like ssh but without the "secure" part)

It's still a work in progress, but at this point should be quite usable for basic operations. You can find it via oppm, just `oppm install psh`

On your hosts that should accept psh connections, run the rc daemon: `rc pshd start`. To have pshd running every boot, make sure to enable it: `rc pshd enable`

From the client, run `psh -l` or `psh --list` to scan/search for available pshd hosts

`psh -f` or `psh --first` to connect to the first host to respond, or `psh -f <address_prefix>` to connect to the first pshd host whose modem address string starts with the address_prefix you specify (this gives a quick short hand mechanism for connecting to remote hosts by just a prefix). No, I don't (yet) have hostname-like support

`psh <full_remote_adddress>` saves you from any broadcast/scan calls, and connects directly to the specified host.

At this time, psh only works stricly with standard io only, it does not intercept nor fake gpu calls.Most programs will assume you can read and write via the gpu, and psh tells the remote shell that a natural tty (and gpu) is available, thus fooling some programs (such as edit).

psh also takes an optional additional argument to run as a command on the remote host (just like ssh does). So `psh -f "" ls` is a fast way to run ls on the remote machine without starting an interactive shell (and close the connection immediately)

In the future I'll be adding `pcp` to the same `psh` oppm package, which will support cp calls (inspired by scp), but for now `psh ... "cat file" > file` works reasonably well. Note though at this time stderr is being communicated to psh as stdout, and thus trying to copy a file in this manner may produce a file with a shell error message (such as if a file doesn't exist). Again, in the future, pcp will be the reliable solution for copying files and folders.

I recommend you read our documentation on components https://ocdoc.cil.li/component:component_access

thanks for testing so much but did you try the flatworld and  `/oc_sc` ?

sounds like a massively bad integration with some other mod. try creating a creative flat world, look at a block on the ground a space or two in front of you, and run `/oc_sc` to spawn a computer and start it up -- just to see if things work at all. you can troubleshoot from there

local fs = component.proxy(component.list("filesystem")())
local handle = fs.open("init.lua")
local buffer = {}
repeat
  local data = fs.read(handle, math.huge)
  table.insert(buffer, data)
until not data
fs.close(handle)
local entire_contents_of_file = table.concat(buffer)

stream handles naturally don't returns ALL of what you ask for, it can take multiple reads. read returns nil when the stream has ended (e.g. eof)