mirrors/CC-Tweaked
1
0
Fork 0
mirror of https://github.com/SquidDev-CC/CC-Tweaked synced 2024-06-25 22:53:22 +00:00
Code Issues Releases Wiki Activity
367773e173
CC-Tweaked/projects/core/src/test/java/dan200/computercraft/core/computer/ComputerBootstrap.java

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

140 lines
4.9 KiB
Java
Raw Normal View History

Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
/*
* This file is part of ComputerCraft - http://www.computercraft.info
Happy new year Should be the last time I'll have to do this!
2022-01-01 00:07:26 +00:00
* Copyright Daniel Ratcliffe, 2011-2022. Do not distribute without permission.
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
* Send enquiries to dratcliffe@gmail.com
*/
package dan200.computercraft.core.computer;
Initial pass of the API breaking changes for 1.19.3 (#1232) - Remove deprecated API members in prep for 1.19.3. This allows us to remove the mc-stubs and forge-stubs projects. - Make several methods take a MinecraftServer instead of a Level (or nothing at all). - Remove I prefixes from a whole bunch of interfaces, making things a little more consistent with Java conventions. This avoids touching the "main" interfaces people consume for now. I want to do that another Minecraft version, to avoid making the update too painful. - Remove IFileSystem and associated getters. This has never worked very well and I don't think has got much (any?) usage.
2022-12-03 15:02:00 +00:00
import dan200.computercraft.api.filesystem.WritableMount;
Replace getMethodNames/callMethod with annotations (#447) When creating a peripheral or custom Lua object, one must implement two methods: - getMethodNames(): String[] - Returns the name of the methods - callMethod(int, ...): Object[] - Invokes the method using an index in the above array. This has a couple of problems: - It's somewhat unwieldy to use - you need to keep track of array indices, which leads to ugly code. - Functions which yield (for instance, those which run on the main thread) are blocking. This means we need to spawn new threads for each CC-side yield. We replace this system with a few changes: - @LuaFunction annotation: One may annotate a public instance method with this annotation. This then exposes a peripheral/lua object method. Furthermore, this method can accept and return a variety of types, which often makes functions cleaner (e.g. can return an int rather than an Object[], and specify and int argument rather than Object[]). - MethodResult: Instead of returning an Object[] and having blocking yields, functions return a MethodResult. This either contains an immediate return, or an instruction to yield with some continuation to resume with. MethodResult is then interpreted by the Lua runtime (i.e. Cobalt), rather than our weird bodgey hacks before. This means we no longer spawn new threads when yielding within CC. - Methods accept IArguments instead of a raw Object array. This has a few benefits: - Consistent argument handling - people no longer need to use ArgumentHelper (as it doesn't exist!), or even be aware of its existence - you're rather forced into using it. - More efficient code in some cases. We provide a Cobalt-specific implementation of IArguments, which avoids the boxing/unboxing when handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
import dan200.computercraft.api.lua.IArguments;
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
import dan200.computercraft.api.lua.ILuaAPI;
import dan200.computercraft.api.lua.LuaException;
Replace getMethodNames/callMethod with annotations (#447) When creating a peripheral or custom Lua object, one must implement two methods: - getMethodNames(): String[] - Returns the name of the methods - callMethod(int, ...): Object[] - Invokes the method using an index in the above array. This has a couple of problems: - It's somewhat unwieldy to use - you need to keep track of array indices, which leads to ugly code. - Functions which yield (for instance, those which run on the main thread) are blocking. This means we need to spawn new threads for each CC-side yield. We replace this system with a few changes: - @LuaFunction annotation: One may annotate a public instance method with this annotation. This then exposes a peripheral/lua object method. Furthermore, this method can accept and return a variety of types, which often makes functions cleaner (e.g. can return an int rather than an Object[], and specify and int argument rather than Object[]). - MethodResult: Instead of returning an Object[] and having blocking yields, functions return a MethodResult. This either contains an immediate return, or an instruction to yield with some continuation to resume with. MethodResult is then interpreted by the Lua runtime (i.e. Cobalt), rather than our weird bodgey hacks before. This means we no longer spawn new threads when yielding within CC. - Methods accept IArguments instead of a raw Object array. This has a few benefits: - Consistent argument handling - people no longer need to use ArgumentHelper (as it doesn't exist!), or even be aware of its existence - you're rather forced into using it. - More efficient code in some cases. We provide a Cobalt-specific implementation of IArguments, which avoids the boxing/unboxing when handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
import dan200.computercraft.api.lua.LuaFunction;
Refactor out main thread tasks into an interface Computers now use a MainThreadScheduler to construct a MainThreadScheduler.Executor, which is used to submit tasks. Our previous (singleton) MainThread and MainThreadExecutor now implement these interfaces. The main purpose of this is to better manage the lifetime of the server thread tasks. We've had at least one bug caused by us failing to reset its state, so good to avoid those! This also allows us to use a fake implementation in tests where we don't expect main thread tasks to run. As we're now passing a bunch of arguments into our Computer, we bundle the "global" ones into ComputerContext (which now also includes the Lua machine factory!). This definitely isn't the nicest API, so we might want to rethink this one day.
2022-10-22 13:12:46 +00:00
import dan200.computercraft.core.ComputerContext;
Prepare dan200.computercraft.core for splitting off - Move core-specific config options to a separate CoreConfig class. - Use class-specific loggers, instead of a global one. - Use log markers instead of a logComputerErrors option.
2022-11-04 19:56:45 +00:00
import dan200.computercraft.core.CoreConfig;
Refactor out main thread tasks into an interface Computers now use a MainThreadScheduler to construct a MainThreadScheduler.Executor, which is used to submit tasks. Our previous (singleton) MainThread and MainThreadExecutor now implement these interfaces. The main purpose of this is to better manage the lifetime of the server thread tasks. We've had at least one bug caused by us failing to reset its state, so good to avoid those! This also allows us to use a fake implementation in tests where we don't expect main thread tasks to run. As we're now passing a bunch of arguments into our Computer, we bundle the "global" ones into ComputerContext (which now also includes the Lua machine factory!). This definitely isn't the nicest API, so we might want to rethink this one day.
2022-10-22 13:12:46 +00:00
import dan200.computercraft.core.computer.mainthread.MainThread;
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
import dan200.computercraft.core.terminal.Terminal;
Move some test support code into testFixtues This offers very few advantages now, but helps support the following in the future: - Reuse test support code across multiple projects (useful for multi-loader). - Allow using test fixture code in testMod. We've got a version of our gametest which use Kotlin instead of Lua for asserting computer behaviour. We can't use java-test-fixtures here for Forge reasons, so have to roll our own version. Alas. - Add an ILuaMachine implementation which runs Kotlin coroutines instead. We can use this for testing asynchronous APIs. This also replaces the FakeComputerManager. - Move most things in the .support module to .test.core. We need to use a separate package in order to cope with Java 9 modules (again, thanks Forge).
2022-10-29 17:17:02 +00:00
import dan200.computercraft.test.core.computer.BasicEnvironment;
import dan200.computercraft.test.core.filesystem.MemoryMount;
Some refactoring of mounts - Separate FileMount into separate FileMount and WritableFileMount classes. This separates the (relatively simple) read-only code from the (soon to be even more complex) read/write code. It also allows you to create read-only mounts which don't bother with filesystem accounting, which is nice. - Make openForWrite/openForAppend always return a SeekableFileHandle. Appendable files still cannot be seeked within, but that check is now done on the FS side. - Refactor the various mount tests to live in test contract interfaces, allowing us to reuse them between mounts. - Clean up our error handling a little better. (Most) file-specific code has been moved to FileMount, and ArchiveMount-derived classes now throw correct path-localised exceptions.
2022-12-09 22:01:01 +00:00
import dan200.computercraft.test.core.filesystem.ReadOnlyWritableMount;
Update to JUnit 5 Also display test results within the Gradle build
2019-03-01 23:48:32 +00:00
import org.junit.jupiter.api.Assertions;
Move dan200.computercraft.core into a separate module This is a very big diff in changed files, but very small in actual changes.
2022-11-04 22:31:56 +00:00
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
Add a function for type-checking arguments (#207) - Define an expect(index, actual_value, types...) helper function which takes an argument index, value and list of permissable types and ensures the value is of one of those types. If not, it will produce an error message with the expected and actual type, as well as the argument number and (if available) the function name. - Expose expect in the global scope as _G["~expect"], hopefully making it clear it is internal. - Replace most manual type checks with this helper method. - Write tests to ensure this argument validation works as expected Also fix a couple of bugs exposed by this refactor and the subsequent tests: - Make rednet checks a little more strict - rednet.close(false) is no longer valid. - Error when attempting to redirect the terminal to itself (term.redirect(term)).
2019-05-30 18:36:28 +00:00
import java.util.Arrays;
Correctly shut down computer threads We now wait for workers to terminate when closing the computer thread. I'll be honest, I'm not happy with this code. Multi-threading is really hard to get right, and I can't say I'm convinced this is especially well behaved. I did look at trying to model this in TLA+, but in the end decided it wasn't worth it. In the future we probably want to split ComputerExecutor into two objects, where one is our entry in the ComputerThread queue (and so holds timing information) while the other is responsible for actual execution.
2022-10-25 08:30:09 +00:00
import java.util.concurrent.TimeUnit;
Add a basic test framework for CraftOS This runs tests on CraftOS using a tiny test runner that I originally knocked up for LuaDash. It can be run both from JUnit (so IDEA and Gradle) and in-game in the shell, so is pretty accessible to work with. I also add a very basic POC test for the io library. I'd like to flesh this out soon enough to contain most of the things from the original io test.
2019-03-02 02:09:14 +00:00
import java.util.function.Consumer;
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
/**
* Helper class to run a program on a computer.
*/
public class ComputerBootstrap {
Move dan200.computercraft.core into a separate module This is a very big diff in changed files, but very small in actual changes.
2022-11-04 22:31:56 +00:00
private static final Logger LOG = LoggerFactory.getLogger(ComputerBootstrap.class);
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
private static final int TPS = 20;
Replace getMethodNames/callMethod with annotations (#447) When creating a peripheral or custom Lua object, one must implement two methods: - getMethodNames(): String[] - Returns the name of the methods - callMethod(int, ...): Object[] - Invokes the method using an index in the above array. This has a couple of problems: - It's somewhat unwieldy to use - you need to keep track of array indices, which leads to ugly code. - Functions which yield (for instance, those which run on the main thread) are blocking. This means we need to spawn new threads for each CC-side yield. We replace this system with a few changes: - @LuaFunction annotation: One may annotate a public instance method with this annotation. This then exposes a peripheral/lua object method. Furthermore, this method can accept and return a variety of types, which often makes functions cleaner (e.g. can return an int rather than an Object[], and specify and int argument rather than Object[]). - MethodResult: Instead of returning an Object[] and having blocking yields, functions return a MethodResult. This either contains an immediate return, or an instruction to yield with some continuation to resume with. MethodResult is then interpreted by the Lua runtime (i.e. Cobalt), rather than our weird bodgey hacks before. This means we no longer spawn new threads when yielding within CC. - Methods accept IArguments instead of a raw Object array. This has a few benefits: - Consistent argument handling - people no longer need to use ArgumentHelper (as it doesn't exist!), or even be aware of its existence - you're rather forced into using it. - More efficient code in some cases. We provide a Cobalt-specific implementation of IArguments, which avoids the boxing/unboxing when handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
public static final int MAX_TIME = 10;
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
Replace getMethodNames/callMethod with annotations (#447) When creating a peripheral or custom Lua object, one must implement two methods: - getMethodNames(): String[] - Returns the name of the methods - callMethod(int, ...): Object[] - Invokes the method using an index in the above array. This has a couple of problems: - It's somewhat unwieldy to use - you need to keep track of array indices, which leads to ugly code. - Functions which yield (for instance, those which run on the main thread) are blocking. This means we need to spawn new threads for each CC-side yield. We replace this system with a few changes: - @LuaFunction annotation: One may annotate a public instance method with this annotation. This then exposes a peripheral/lua object method. Furthermore, this method can accept and return a variety of types, which often makes functions cleaner (e.g. can return an int rather than an Object[], and specify and int argument rather than Object[]). - MethodResult: Instead of returning an Object[] and having blocking yields, functions return a MethodResult. This either contains an immediate return, or an instruction to yield with some continuation to resume with. MethodResult is then interpreted by the Lua runtime (i.e. Cobalt), rather than our weird bodgey hacks before. This means we no longer spawn new threads when yielding within CC. - Methods accept IArguments instead of a raw Object array. This has a few benefits: - Consistent argument handling - people no longer need to use ArgumentHelper (as it doesn't exist!), or even be aware of its existence - you're rather forced into using it. - More efficient code in some cases. We provide a Cobalt-specific implementation of IArguments, which avoids the boxing/unboxing when handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
public static void run(String program, Consumer<Computer> setup, int maxTimes) {
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
var mount = new MemoryMount()
.addFile("test.lua", program)
Replace getMethodNames/callMethod with annotations (#447) When creating a peripheral or custom Lua object, one must implement two methods: - getMethodNames(): String[] - Returns the name of the methods - callMethod(int, ...): Object[] - Invokes the method using an index in the above array. This has a couple of problems: - It's somewhat unwieldy to use - you need to keep track of array indices, which leads to ugly code. - Functions which yield (for instance, those which run on the main thread) are blocking. This means we need to spawn new threads for each CC-side yield. We replace this system with a few changes: - @LuaFunction annotation: One may annotate a public instance method with this annotation. This then exposes a peripheral/lua object method. Furthermore, this method can accept and return a variety of types, which often makes functions cleaner (e.g. can return an int rather than an Object[], and specify and int argument rather than Object[]). - MethodResult: Instead of returning an Object[] and having blocking yields, functions return a MethodResult. This either contains an immediate return, or an instruction to yield with some continuation to resume with. MethodResult is then interpreted by the Lua runtime (i.e. Cobalt), rather than our weird bodgey hacks before. This means we no longer spawn new threads when yielding within CC. - Methods accept IArguments instead of a raw Object array. This has a few benefits: - Consistent argument handling - people no longer need to use ArgumentHelper (as it doesn't exist!), or even be aware of its existence - you're rather forced into using it. - More efficient code in some cases. We provide a Cobalt-specific implementation of IArguments, which avoids the boxing/unboxing when handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
.addFile("startup.lua", "assertion.assert(pcall(loadfile('test.lua', nil, _ENV))) os.shutdown()");
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
Some refactoring of mounts - Separate FileMount into separate FileMount and WritableFileMount classes. This separates the (relatively simple) read-only code from the (soon to be even more complex) read/write code. It also allows you to create read-only mounts which don't bother with filesystem accounting, which is nice. - Make openForWrite/openForAppend always return a SeekableFileHandle. Appendable files still cannot be seeked within, but that check is now done on the FS side. - Refactor the various mount tests to live in test contract interfaces, allowing us to reuse them between mounts. - Clean up our error handling a little better. (Most) file-specific code has been moved to FileMount, and ArchiveMount-derived classes now throw correct path-localised exceptions.
2022-12-09 22:01:01 +00:00
run(new ReadOnlyWritableMount(mount), setup, maxTimes);
Add a basic test framework for CraftOS This runs tests on CraftOS using a tiny test runner that I originally knocked up for LuaDash. It can be run both from JUnit (so IDEA and Gradle) and in-game in the shell, so is pretty accessible to work with. I also add a very basic POC test for the io library. I'd like to flesh this out soon enough to contain most of the things from the original io test.
2019-03-02 02:09:14 +00:00
}
Replace getMethodNames/callMethod with annotations (#447) When creating a peripheral or custom Lua object, one must implement two methods: - getMethodNames(): String[] - Returns the name of the methods - callMethod(int, ...): Object[] - Invokes the method using an index in the above array. This has a couple of problems: - It's somewhat unwieldy to use - you need to keep track of array indices, which leads to ugly code. - Functions which yield (for instance, those which run on the main thread) are blocking. This means we need to spawn new threads for each CC-side yield. We replace this system with a few changes: - @LuaFunction annotation: One may annotate a public instance method with this annotation. This then exposes a peripheral/lua object method. Furthermore, this method can accept and return a variety of types, which often makes functions cleaner (e.g. can return an int rather than an Object[], and specify and int argument rather than Object[]). - MethodResult: Instead of returning an Object[] and having blocking yields, functions return a MethodResult. This either contains an immediate return, or an instruction to yield with some continuation to resume with. MethodResult is then interpreted by the Lua runtime (i.e. Cobalt), rather than our weird bodgey hacks before. This means we no longer spawn new threads when yielding within CC. - Methods accept IArguments instead of a raw Object array. This has a few benefits: - Consistent argument handling - people no longer need to use ArgumentHelper (as it doesn't exist!), or even be aware of its existence - you're rather forced into using it. - More efficient code in some cases. We provide a Cobalt-specific implementation of IArguments, which avoids the boxing/unboxing when handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
public static void run(String program, int maxTimes) {
Store colour support in the Terminal Previously we stored it alongside the terminal. While this makes sense - it's not a property of the terminal itself, it ends up duplicating code in a bunch of places. We now track the colour flag on the terminal itself. This allows us to simplify a couple of things: - The palette now also knows whether it supports colours or not, and so performs greyscale conversion. This means we no longer need to thread a "greyscale" flag throughout terminal rendering. - Remove isColour() getters from a whole load of places (TerminalMethods, ServerTerminal, IComputerEnvironment).
2022-10-21 17:26:57 +00:00
run(program, x -> {
}, maxTimes);
Replace getMethodNames/callMethod with annotations (#447) When creating a peripheral or custom Lua object, one must implement two methods: - getMethodNames(): String[] - Returns the name of the methods - callMethod(int, ...): Object[] - Invokes the method using an index in the above array. This has a couple of problems: - It's somewhat unwieldy to use - you need to keep track of array indices, which leads to ugly code. - Functions which yield (for instance, those which run on the main thread) are blocking. This means we need to spawn new threads for each CC-side yield. We replace this system with a few changes: - @LuaFunction annotation: One may annotate a public instance method with this annotation. This then exposes a peripheral/lua object method. Furthermore, this method can accept and return a variety of types, which often makes functions cleaner (e.g. can return an int rather than an Object[], and specify and int argument rather than Object[]). - MethodResult: Instead of returning an Object[] and having blocking yields, functions return a MethodResult. This either contains an immediate return, or an instruction to yield with some continuation to resume with. MethodResult is then interpreted by the Lua runtime (i.e. Cobalt), rather than our weird bodgey hacks before. This means we no longer spawn new threads when yielding within CC. - Methods accept IArguments instead of a raw Object array. This has a few benefits: - Consistent argument handling - people no longer need to use ArgumentHelper (as it doesn't exist!), or even be aware of its existence - you're rather forced into using it. - More efficient code in some cases. We provide a Cobalt-specific implementation of IArguments, which avoids the boxing/unboxing when handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
}
Initial pass of the API breaking changes for 1.19.3 (#1232) - Remove deprecated API members in prep for 1.19.3. This allows us to remove the mc-stubs and forge-stubs projects. - Make several methods take a MinecraftServer instead of a Level (or nothing at all). - Remove I prefixes from a whole bunch of interfaces, making things a little more consistent with Java conventions. This avoids touching the "main" interfaces people consume for now. I want to do that another Minecraft version, to avoid making the update too painful. - Remove IFileSystem and associated getters. This has never worked very well and I don't think has got much (any?) usage.
2022-12-03 15:02:00 +00:00
public static void run(WritableMount mount, Consumer<Computer> setup, int maxTicks) {
Prepare dan200.computercraft.core for splitting off - Move core-specific config options to a separate CoreConfig class. - Use class-specific loggers, instead of a global one. - Use log markers instead of a logComputerErrors option.
2022-11-04 19:56:45 +00:00
CoreConfig.maxMainComputerTime = CoreConfig.maxMainGlobalTime = Integer.MAX_VALUE;
Add a basic test framework for CraftOS This runs tests on CraftOS using a tiny test runner that I originally knocked up for LuaDash. It can be run both from JUnit (so IDEA and Gradle) and in-game in the shell, so is pretty accessible to work with. I also add a very basic POC test for the io library. I'd like to flesh this out soon enough to contain most of the things from the original io test.
2019-03-02 02:09:14 +00:00
Move dan200.computercraft.core into a separate module This is a very big diff in changed files, but very small in actual changes.
2022-11-04 22:31:56 +00:00
var term = new Terminal(51, 19, true);
Refactor out main thread tasks into an interface Computers now use a MainThreadScheduler to construct a MainThreadScheduler.Executor, which is used to submit tasks. Our previous (singleton) MainThread and MainThreadExecutor now implement these interfaces. The main purpose of this is to better manage the lifetime of the server thread tasks. We've had at least one bug caused by us failing to reset its state, so good to avoid those! This also allows us to use a fake implementation in tests where we don't expect main thread tasks to run. As we're now passing a bunch of arguments into our Computer, we bundle the "global" ones into ComputerContext (which now also includes the Lua machine factory!). This definitely isn't the nicest API, so we might want to rethink this one day.
2022-10-22 13:12:46 +00:00
var mainThread = new MainThread();
Start work on curtailing our global state The last 4 or 5 commits have simplified things. I can now have some unnecessary complexity as a treat! This is some initial work on better tying the lifecycle of computers (and ComputerCraft) related state to the lifecycle of the current Minecraft server. - Move server-wide methods in IComputerEnvironment (such as creating resource mounts) into a separate interface. - Add a new ServerContext class, which now holds the ID Assigner, server computer registry, and some other tiny bits and bobs. This can only be accessed by ServerContect.get(MinecraftServer), forcing slightly better discipline for how we use these globals. This does allow us to nuke some of the ugliest bits in IDAssigner. Even if it makes things much longer!
2022-10-21 20:01:01 +00:00
var environment = new BasicEnvironment(mount);
Manage ComputerThread's lifecycle in ComputerContext This converts ComputerThread from a singleton into a proper object, which is setup when starting a computer, and tore down when the ComputerContext is closed. While this is mostly for conceptual elegance, it does offer some concrete benefits: - You can now adjust the thread count without restarting the whole game (just leaving and rentering the world). Though, alas, no effect on servers. - We can run multiple ComputerThreads in parallel, which makes it much easier to run tests in parallel. This allows us to remove our rather silly IsolatedRunner test helper.
2022-10-22 13:36:25 +00:00
var context = new ComputerContext(environment, 1, mainThread);
Refactor out main thread tasks into an interface Computers now use a MainThreadScheduler to construct a MainThreadScheduler.Executor, which is used to submit tasks. Our previous (singleton) MainThread and MainThreadExecutor now implement these interfaces. The main purpose of this is to better manage the lifetime of the server thread tasks. We've had at least one bug caused by us failing to reset its state, so good to avoid those! This also allows us to use a fake implementation in tests where we don't expect main thread tasks to run. As we're now passing a bunch of arguments into our Computer, we bundle the "global" ones into ComputerContext (which now also includes the Lua machine factory!). This definitely isn't the nicest API, so we might want to rethink this one day.
2022-10-22 13:12:46 +00:00
final var computer = new Computer(context, environment, term, 0);
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
var api = new AssertApi();
Migrate the computer tasks into a separate thread - Move state management (turnOn, shutdown, etc...) event handling and the command queue into a ComputerExecutor - This means the computer thread now just handles running "work" on computer executors, rather than managing a separate command queue + requeuing it.
2019-02-26 10:31:29 +00:00
computer.addApi(api);
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
Add a basic test framework for CraftOS This runs tests on CraftOS using a tiny test runner that I originally knocked up for LuaDash. It can be run both from JUnit (so IDEA and Gradle) and in-game in the shell, so is pretty accessible to work with. I also add a very basic POC test for the io library. I'd like to flesh this out soon enough to contain most of the things from the original io test.
2019-03-02 02:09:14 +00:00
setup.accept(computer);
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
try {
computer.turnOn();
var everOn = false;
Replace getMethodNames/callMethod with annotations (#447) When creating a peripheral or custom Lua object, one must implement two methods: - getMethodNames(): String[] - Returns the name of the methods - callMethod(int, ...): Object[] - Invokes the method using an index in the above array. This has a couple of problems: - It's somewhat unwieldy to use - you need to keep track of array indices, which leads to ugly code. - Functions which yield (for instance, those which run on the main thread) are blocking. This means we need to spawn new threads for each CC-side yield. We replace this system with a few changes: - @LuaFunction annotation: One may annotate a public instance method with this annotation. This then exposes a peripheral/lua object method. Furthermore, this method can accept and return a variety of types, which often makes functions cleaner (e.g. can return an int rather than an Object[], and specify and int argument rather than Object[]). - MethodResult: Instead of returning an Object[] and having blocking yields, functions return a MethodResult. This either contains an immediate return, or an instruction to yield with some continuation to resume with. MethodResult is then interpreted by the Lua runtime (i.e. Cobalt), rather than our weird bodgey hacks before. This means we no longer spawn new threads when yielding within CC. - Methods accept IArguments instead of a raw Object array. This has a few benefits: - Consistent argument handling - people no longer need to use ArgumentHelper (as it doesn't exist!), or even be aware of its existence - you're rather forced into using it. - More efficient code in some cases. We provide a Cobalt-specific implementation of IArguments, which avoids the boxing/unboxing when handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
for (var tick = 0; tick < TPS * maxTicks; tick++) {
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
var start = System.currentTimeMillis();
computer.tick();
Refactor out main thread tasks into an interface Computers now use a MainThreadScheduler to construct a MainThreadScheduler.Executor, which is used to submit tasks. Our previous (singleton) MainThread and MainThreadExecutor now implement these interfaces. The main purpose of this is to better manage the lifetime of the server thread tasks. We've had at least one bug caused by us failing to reset its state, so good to avoid those! This also allows us to use a fake implementation in tests where we don't expect main thread tasks to run. As we're now passing a bunch of arguments into our Computer, we bundle the "global" ones into ComputerContext (which now also includes the Lua machine factory!). This definitely isn't the nicest API, so we might want to rethink this one day.
2022-10-22 13:12:46 +00:00
mainThread.tick();
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
if (api.message != null) {
Move dan200.computercraft.core into a separate module This is a very big diff in changed files, but very small in actual changes.
2022-11-04 22:31:56 +00:00
LOG.debug("Shutting down due to error");
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
computer.shutdown();
Update to JUnit 5 Also display test results within the Gradle build
2019-03-01 23:48:32 +00:00
Assertions.fail(api.message);
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
return;
}
var remaining = (1000 / TPS) - (System.currentTimeMillis() - start);
if (remaining > 0) Thread.sleep(remaining);
// Break if the computer was once on, and is now off.
everOn |= computer.isOn();
if ((everOn || tick > TPS) && !computer.isOn()) break;
}
if (computer.isOn() || !api.didAssert) {
Allow pausing Lua machines TimeoutState now introduces a TIMESLICE, which is the maximum period of time a computer can run before we will look into pausing it. When we have executed a task for more than this period, and if there are other computers waiting to execute work, then we will suspend the machine. Suspending the machine sets a flag on the ComputerExecutor, and pauses the "cumulative" time - the time spent handling this particular event. When resuming the machine, we restart our timer and resume the machine.
2019-02-28 16:36:26 +00:00
var builder = new StringBuilder().append("Did not correctly [");
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
if (!api.didAssert) builder.append(" assert");
if (computer.isOn()) builder.append(" shutdown");
Allow pausing Lua machines TimeoutState now introduces a TIMESLICE, which is the maximum period of time a computer can run before we will look into pausing it. When we have executed a task for more than this period, and if there are other computers waiting to execute work, then we will suspend the machine. Suspending the machine sets a flag on the ComputerExecutor, and pauses the "cumulative" time - the time spent handling this particular event. When resuming the machine, we restart our timer and resume the machine.
2019-02-28 16:36:26 +00:00
builder.append(" ]\n");
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
for (var line = 0; line < 19; line++) {
builder.append(String.format("%2d | %" + term.getWidth() + "s |\n", line + 1, term.getLine(line)));
}
computer.shutdown();
Update to JUnit 5 Also display test results within the Gradle build
2019-03-01 23:48:32 +00:00
Assertions.fail(builder.toString());
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
}
} catch (InterruptedException ignored) {
Thread.currentThread().interrupt();
Refactor out main thread tasks into an interface Computers now use a MainThreadScheduler to construct a MainThreadScheduler.Executor, which is used to submit tasks. Our previous (singleton) MainThread and MainThreadExecutor now implement these interfaces. The main purpose of this is to better manage the lifetime of the server thread tasks. We've had at least one bug caused by us failing to reset its state, so good to avoid those! This also allows us to use a fake implementation in tests where we don't expect main thread tasks to run. As we're now passing a bunch of arguments into our Computer, we bundle the "global" ones into ComputerContext (which now also includes the Lua machine factory!). This definitely isn't the nicest API, so we might want to rethink this one day.
2022-10-22 13:12:46 +00:00
} finally {
Correctly shut down computer threads We now wait for workers to terminate when closing the computer thread. I'll be honest, I'm not happy with this code. Multi-threading is really hard to get right, and I can't say I'm convinced this is especially well behaved. I did look at trying to model this in TLA+, but in the end decided it wasn't worth it. In the future we probably want to split ComputerExecutor into two objects, where one is our entry in the ComputerThread queue (and so holds timing information) while the other is responsible for actual execution.
2022-10-25 08:30:09 +00:00
try {
context.ensureClosed(1, TimeUnit.SECONDS);
} catch (InterruptedException e) {
throw new IllegalStateException("Runtime thread was interrupted", e);
}
Refactor out main thread tasks into an interface Computers now use a MainThreadScheduler to construct a MainThreadScheduler.Executor, which is used to submit tasks. Our previous (singleton) MainThread and MainThreadExecutor now implement these interfaces. The main purpose of this is to better manage the lifetime of the server thread tasks. We've had at least one bug caused by us failing to reset its state, so good to avoid those! This also allows us to use a fake implementation in tests where we don't expect main thread tasks to run. As we're now passing a bunch of arguments into our Computer, we bundle the "global" ones into ComputerContext (which now also includes the Lua machine factory!). This definitely isn't the nicest API, so we might want to rethink this one day.
2022-10-22 13:12:46 +00:00
}
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
}
Replace getMethodNames/callMethod with annotations (#447) When creating a peripheral or custom Lua object, one must implement two methods: - getMethodNames(): String[] - Returns the name of the methods - callMethod(int, ...): Object[] - Invokes the method using an index in the above array. This has a couple of problems: - It's somewhat unwieldy to use - you need to keep track of array indices, which leads to ugly code. - Functions which yield (for instance, those which run on the main thread) are blocking. This means we need to spawn new threads for each CC-side yield. We replace this system with a few changes: - @LuaFunction annotation: One may annotate a public instance method with this annotation. This then exposes a peripheral/lua object method. Furthermore, this method can accept and return a variety of types, which often makes functions cleaner (e.g. can return an int rather than an Object[], and specify and int argument rather than Object[]). - MethodResult: Instead of returning an Object[] and having blocking yields, functions return a MethodResult. This either contains an immediate return, or an instruction to yield with some continuation to resume with. MethodResult is then interpreted by the Lua runtime (i.e. Cobalt), rather than our weird bodgey hacks before. This means we no longer spawn new threads when yielding within CC. - Methods accept IArguments instead of a raw Object array. This has a few benefits: - Consistent argument handling - people no longer need to use ArgumentHelper (as it doesn't exist!), or even be aware of its existence - you're rather forced into using it. - More efficient code in some cases. We provide a Cobalt-specific implementation of IArguments, which avoids the boxing/unboxing when handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
public static class AssertApi implements ILuaAPI {
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
boolean didAssert;
String message;
@Override
public String[] getNames() {
return new String[]{ "assertion" };
}
Replace getMethodNames/callMethod with annotations (#447) When creating a peripheral or custom Lua object, one must implement two methods: - getMethodNames(): String[] - Returns the name of the methods - callMethod(int, ...): Object[] - Invokes the method using an index in the above array. This has a couple of problems: - It's somewhat unwieldy to use - you need to keep track of array indices, which leads to ugly code. - Functions which yield (for instance, those which run on the main thread) are blocking. This means we need to spawn new threads for each CC-side yield. We replace this system with a few changes: - @LuaFunction annotation: One may annotate a public instance method with this annotation. This then exposes a peripheral/lua object method. Furthermore, this method can accept and return a variety of types, which often makes functions cleaner (e.g. can return an int rather than an Object[], and specify and int argument rather than Object[]). - MethodResult: Instead of returning an Object[] and having blocking yields, functions return a MethodResult. This either contains an immediate return, or an instruction to yield with some continuation to resume with. MethodResult is then interpreted by the Lua runtime (i.e. Cobalt), rather than our weird bodgey hacks before. This means we no longer spawn new threads when yielding within CC. - Methods accept IArguments instead of a raw Object array. This has a few benefits: - Consistent argument handling - people no longer need to use ArgumentHelper (as it doesn't exist!), or even be aware of its existence - you're rather forced into using it. - More efficient code in some cases. We provide a Cobalt-specific implementation of IArguments, which avoids the boxing/unboxing when handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
@LuaFunction
public final void log(IArguments arguments) {
Move dan200.computercraft.core into a separate module This is a very big diff in changed files, but very small in actual changes.
2022-11-04 22:31:56 +00:00
LOG.info("[Computer] {}", Arrays.toString(arguments.getAll()));
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
}
Replace getMethodNames/callMethod with annotations (#447) When creating a peripheral or custom Lua object, one must implement two methods: - getMethodNames(): String[] - Returns the name of the methods - callMethod(int, ...): Object[] - Invokes the method using an index in the above array. This has a couple of problems: - It's somewhat unwieldy to use - you need to keep track of array indices, which leads to ugly code. - Functions which yield (for instance, those which run on the main thread) are blocking. This means we need to spawn new threads for each CC-side yield. We replace this system with a few changes: - @LuaFunction annotation: One may annotate a public instance method with this annotation. This then exposes a peripheral/lua object method. Furthermore, this method can accept and return a variety of types, which often makes functions cleaner (e.g. can return an int rather than an Object[], and specify and int argument rather than Object[]). - MethodResult: Instead of returning an Object[] and having blocking yields, functions return a MethodResult. This either contains an immediate return, or an instruction to yield with some continuation to resume with. MethodResult is then interpreted by the Lua runtime (i.e. Cobalt), rather than our weird bodgey hacks before. This means we no longer spawn new threads when yielding within CC. - Methods accept IArguments instead of a raw Object array. This has a few benefits: - Consistent argument handling - people no longer need to use ArgumentHelper (as it doesn't exist!), or even be aware of its existence - you're rather forced into using it. - More efficient code in some cases. We provide a Cobalt-specific implementation of IArguments, which avoids the boxing/unboxing when handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
@LuaFunction("assert")
public final Object[] doAssert(IArguments arguments) throws LuaException {
didAssert = true;
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
Replace getMethodNames/callMethod with annotations (#447) When creating a peripheral or custom Lua object, one must implement two methods: - getMethodNames(): String[] - Returns the name of the methods - callMethod(int, ...): Object[] - Invokes the method using an index in the above array. This has a couple of problems: - It's somewhat unwieldy to use - you need to keep track of array indices, which leads to ugly code. - Functions which yield (for instance, those which run on the main thread) are blocking. This means we need to spawn new threads for each CC-side yield. We replace this system with a few changes: - @LuaFunction annotation: One may annotate a public instance method with this annotation. This then exposes a peripheral/lua object method. Furthermore, this method can accept and return a variety of types, which often makes functions cleaner (e.g. can return an int rather than an Object[], and specify and int argument rather than Object[]). - MethodResult: Instead of returning an Object[] and having blocking yields, functions return a MethodResult. This either contains an immediate return, or an instruction to yield with some continuation to resume with. MethodResult is then interpreted by the Lua runtime (i.e. Cobalt), rather than our weird bodgey hacks before. This means we no longer spawn new threads when yielding within CC. - Methods accept IArguments instead of a raw Object array. This has a few benefits: - Consistent argument handling - people no longer need to use ArgumentHelper (as it doesn't exist!), or even be aware of its existence - you're rather forced into using it. - More efficient code in some cases. We provide a Cobalt-specific implementation of IArguments, which avoids the boxing/unboxing when handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
var arg = arguments.get(0);
if (arg == null || arg == Boolean.FALSE) {
message = arguments.optString(1, "Assertion failed");
throw new LuaException(message);
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
}
Replace getMethodNames/callMethod with annotations (#447) When creating a peripheral or custom Lua object, one must implement two methods: - getMethodNames(): String[] - Returns the name of the methods - callMethod(int, ...): Object[] - Invokes the method using an index in the above array. This has a couple of problems: - It's somewhat unwieldy to use - you need to keep track of array indices, which leads to ugly code. - Functions which yield (for instance, those which run on the main thread) are blocking. This means we need to spawn new threads for each CC-side yield. We replace this system with a few changes: - @LuaFunction annotation: One may annotate a public instance method with this annotation. This then exposes a peripheral/lua object method. Furthermore, this method can accept and return a variety of types, which often makes functions cleaner (e.g. can return an int rather than an Object[], and specify and int argument rather than Object[]). - MethodResult: Instead of returning an Object[] and having blocking yields, functions return a MethodResult. This either contains an immediate return, or an instruction to yield with some continuation to resume with. MethodResult is then interpreted by the Lua runtime (i.e. Cobalt), rather than our weird bodgey hacks before. This means we no longer spawn new threads when yielding within CC. - Methods accept IArguments instead of a raw Object array. This has a few benefits: - Consistent argument handling - people no longer need to use ArgumentHelper (as it doesn't exist!), or even be aware of its existence - you're rather forced into using it. - More efficient code in some cases. We provide a Cobalt-specific implementation of IArguments, which avoids the boxing/unboxing when handling numbers and binary strings.
2020-05-15 12:21:16 +00:00
return arguments.getAll();
Add a test which boots a computer and runs forever Ideally we'd add a couple more tests in the future, but this'll do for now. The bootstrap class is largely yoinked from CCTweaks-Lua, so is a tad ugly. It works though.
2019-02-26 08:44:17 +00:00
}
}
}
Reference in New Issue Copy Permalink