payonel

simply put, you cannot. All threading must be cooperative; everyone must yield on their own. However, you should know that OpenOS now has threads! [ in case you are wondering how, threads intercept yields and computer.pullSignal and hide the cooperative layer from the user ] There is actually quite a lot that went into developing threads for OpenOS. Please consider the wiki doc I wrote up about them, and please provide feedback and questions! Any issues or bugs you run into, please use github to create a new issue. http://ocdoc.cil.li/api:thread

If my last response was too heavy handed I apologize. I'm just passionate about OpenOS and I care about how it works and how it is used. Perhaps what OpenOS needs is a way for a program to register hard interrupt handlers. But until then..pcalls, coroutines, or threads

Soft interrupts are already passed as an event We're talking about hard interrupts, which are designed to abort a process, like a SIG* in linux-land. It's worse than "not ideal". It's bad form and a slippery slope. My point is that this is not the correct way to use OpenOS in user code. I cannot agree that changing os behavior as a by-product of a user program is OK. If you want to make a variation of OpenOS, or consider your library a patch to the OS, that's different. As this is not how the libraries should be used, I would classify this more of a KERNEL change.

I don't know the code, but I bet oop.inherit(bar_base, frame_base); Sets a metatable on bar_base that provides a getSize method from from_base, so find the code in local frame_base = require("libGUI/frame");

Oh I would prefer people DO NOT override system methods such as event.* Please Hard interrupts are thrown as exceptions, use pcall or xpcall to capture events. Note that interrupts are not checked until you yield for computer signals Examples: coroutine.yield() out of your program will yield for the next computer signal literally calling computer.pullSignal or event.pull will yield os.sleep If during these "yields" the user is pressing ctrl+shift+c, a hard interrupt exception is thrown and your program will abort if uncaught. Thus, if you have code that you

the real "how to print to screen" work is done in a kernel level library called tty. These are NOT public methods because the method names and parameters will change without warning as I see fit to optimize or refactor code. But, if you want to know where "print" EVENTUALLY gets to actually rendering text on the screen, look here: https://github.com/payonel/OpenComputers/blob/master-MC1.7.10/src/main/resources/assets/opencomputers/loot/openos/lib/tty.lua#L319 The boot code has a far simpler, dumbed down version (for example, it doesn't wrap, it doesn't have a cursor position): https://git

Also see the new thread library which can solve the "I need to event.pull without blocking other parts of my code": http://ocdoc.cil.li/api:thread

Also, io.open takes RELATIVE or ABSOLUTE paths, ALL FILESYSTEM API methods ASSUME absolute paths e.g. require("filesystem").open("file.txt") opens /file.txt not /your/current/path/file.txt compare to io.open("file.txt") opens /your/current/path/file.txt

loadstring is depcrated in Lua 5.2, and obsolete (removed, gone) in Lua 5.3 load(text)() works equivalently https://www.lua.org/manual/5.2/manual.html#8.2

OpenOS provide threads now, see http://ocdoc.cil.li/api:thread

In this response when I say "In EERPROM" I am referring to any code that is running without or before OpenOS. It doesn't necessarily have to be literally in EEPROM code. It could be your own custom OS, it could be literally code in an EEPROM. So.... require("filesystem") ~= require("component").filesystem We are dealing with some confusion here. I should make a wiki page specifically about the two weird+confusing things here We need to understand what is a library and what is a proxy require() returns libraries component.proxy() and component[component_type_name

in your sample code you create a coroutine, but you never resume it. Coroutines run like function calls, and yields are like having multiple returns points in said method. The solutions provided are good solutions, but i just wanted to point out that your original code has the right idea, you were just expecting that your code would run two sections autonomously and in parallel, which is possible with threads (we have threads in OpenOS now) your original sample of code would work just find if you replace coroutine.create(keyCheck) with local thread = require("thread")

eeprom is not a filesystem, it is an eeprom filesystems can create files via open eeprom only has 2 data storage areas > 1. eeprom.get() + eeprom.set() -- this is the code that is run by boot. it's like one large file > 2. eeprom.getData() + eeprom.setData() -- this is a small data field meant to store persistent data like "which hard drive has the OS" Graphics are done by the gpu component. In eeprom you could get the first gpu using: local gpu = component.list("gpu")() When that you can make all the gpu calls, see: http://ocdoc.cil.li/component:gp

Allow me to comment on this code suggestion: You do not need to require("io"), it is a global library and I recommend using io.open 1. the read/write is buffered (more options, better perf) 2. the path is relative, fs.open is always absolute read more here: http://ocdoc.cil.li/api:non-standard-lua-libs#input_and_output_facilities

you don't need to require("io"), that is a global library you don't need to require("term") simply because you weren't using it

any file you create is created on the host machine, it has nothing to do with openos, but OC doesn't create empty dirs for those. The idea is that each filesystem component (e.g. a floppy) will have a GUID, files created in that filesystem are created on the host (real) using that GUID as a dir name, with a path to your file. So, in term of the filesystem api ( see http://ocdoc.cil.li/component:filesystem ) Assuming you have a proxy to a filesystem (this complexity is hidden behind the io library provided by OpenOS): local filesystem_address = "deadbeaf-..." -- some filesyst

OpenOS already fires an event called "shutdown" when computer.shutdown is called. Please don't override any system methods, nor add metatables to nor remove metatables from system libraries. However, pressing the power button on the machine, losing power, or breaking -- do not send any such signal

There is no require provided by the `computer`because there is no default "filesystem", but only filesystems provided by the filesystem components. That is why OpenOS defines require: https://github.com/MightyPirates/OpenComputers/blob/master-MC1.7.10/src/main/resources/assets/opencomputers/loot/openos/lib/package.lua

Also, there is a "redstone_changed" event that is fired when the input changes. So...the monitor_thread could be a bit cleaner without the sleep, but instead: local monitor_thread = thread.create(function() while true do if redstone.getBundledInput(sides.back, colors.magenta) then break end event.pull("redstone_changed") end end) You could also do something quite different with `event.listen`: local thread = require("thread") local component = require("component") local sides = require("sides") local colors = require("colors") local redston

OpenOS 1.6.5 introduces threads: http://ocdoc.cil.li/api:thread The examples at the end of that wiki page demonstrate how you could cancel io.read due to some condition: http://ocdoc.cil.li/api:thread#thread_interrupt_handler_example So for your case: local thread = require("thread") local component = require("component") local sides = require("sides") local colors = require("colors") local redstone = component.redstone local monitor_thread = thread.create(function() while true do if redstone.getBundledInput(sides.back, colors.magenta) then break end os.slee

I"m a new patreon (looks like it's just two of us) My donation is pathetically small ($1/month) - Sangar and those that help him deserve so much more. When I start spending more time using OC, I should increase my patreon to match. Truly great work, Sangar. Thank you so much. Not only is your mod work fantastic, you're kind to your fans, and you make your work open and easily configurable. Truly the perfect example of a great mod for the community. Sincerely, Payo