CC-Tweaked/src/main/java/dan200/computercraft/core/lua/CobaltLuaMachine.java

524 lines
18 KiB
Java
Raw Normal View History

/*
* This file is part of ComputerCraft - http://www.computercraft.info
* Copyright Daniel Ratcliffe, 2011-2021. Do not distribute without permission.
* Send enquiries to dratcliffe@gmail.com
*/
package dan200.computercraft.core.lua;
import dan200.computercraft.ComputerCraft;
import dan200.computercraft.api.lua.*;
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.core.asm.LuaMethod;
import dan200.computercraft.core.asm.ObjectSource;
import dan200.computercraft.core.computer.Computer;
import dan200.computercraft.core.computer.TimeoutState;
import dan200.computercraft.core.tracking.Tracking;
import dan200.computercraft.core.tracking.TrackingField;
import dan200.computercraft.shared.util.ThreadUtils;
2017-05-01 17:28:17 +00:00
import org.squiddev.cobalt.*;
import org.squiddev.cobalt.compiler.CompileException;
import org.squiddev.cobalt.compiler.LoadState;
import org.squiddev.cobalt.debug.DebugFrame;
import org.squiddev.cobalt.debug.DebugHandler;
import org.squiddev.cobalt.debug.DebugState;
import org.squiddev.cobalt.function.LuaFunction;
import org.squiddev.cobalt.lib.*;
import org.squiddev.cobalt.lib.platform.VoidResourceManipulator;
2017-05-06 23:07:42 +00:00
import javax.annotation.Nonnull;
import javax.annotation.Nullable;
2017-05-01 17:28:17 +00:00
import java.io.InputStream;
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 java.nio.ByteBuffer;
import java.util.*;
import java.util.concurrent.SynchronousQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
2017-05-01 17:28:17 +00:00
import static org.squiddev.cobalt.ValueFactory.valueOf;
import static org.squiddev.cobalt.ValueFactory.varargsOf;
import static org.squiddev.cobalt.debug.DebugFrame.FLAG_HOOKED;
import static org.squiddev.cobalt.debug.DebugFrame.FLAG_HOOKYIELD;
2017-05-01 17:28:17 +00:00
public class CobaltLuaMachine implements ILuaMachine
{
private static final ThreadPoolExecutor COROUTINES = new ThreadPoolExecutor(
0, Integer.MAX_VALUE,
Bump Cobalt version to enable single-threading The latest version of Cobalt has several major changes, which I'm looking forward to taking advantage of in the coming months: - The Lua interpreter has been split up from the actual LuaClosure instance. It now runs multiple functions within one loop, handling pushing/popping and resuming method calls correctly. This means we have a theoretically infinite call depth, as we're no longer bounded by Java's stack size. In reality, this is limited to 32767 (Short.MAX_VALUE), as that's a mostly equivalent to the limits PUC Lua exposes. - The stack is no longer unwound in the event of errors. This both simplifies error handling (not that CC:T needs to care about that) but also means one can call debug.traceback on a now-dead coroutine (which is more useful for debugging than using xpcall). - Most significantly, coroutines are no longer each run on a dedicated thread. Instead, yielding or resuming throws an exception to unwind the Java stack and switches to a different coroutine. In order to preserve compatability with CC's assumption about LuaJ's threading model (namely that yielding blocks the thread), we also provide a yieldBlock method (which CC:T consumes). This suspends the current thread and switches execution to a new thread (see SquidDev/Cobalt@b5ddf164f1c77bc2657f096f39dd167c19270f6d for more details). While this does mean we need to use more than 1 thread, it's still /substantially/ less than would otherwise be needed. We've been running these changes on SwitchCraft for a few days now and haven't seen any issues. One nice thing to observe is that the number of CC thread has gone down from ~1.9k to ~100 (of those, ~70 are dedicated to running coroutines). Similarly, the server has gone from generating ~15k threads over its lifetime, to ~3k. While this is still a lot, it's a substantial improvement.
2019-02-10 21:46:52 +00:00
5L, TimeUnit.MINUTES,
new SynchronousQueue<>(),
ThreadUtils.factory( "Coroutine" )
);
private static final LuaMethod FUNCTION_METHOD = ( target, context, args ) -> ((ILuaFunction) target).call( args );
private final Computer computer;
private final TimeoutState timeout;
private final TimeoutDebugHandler debug;
private final ILuaContext context;
2017-05-01 17:28:17 +00:00
private LuaState state;
private LuaTable globals;
private LuaThread mainRoutine = null;
private String eventFilter = null;
public CobaltLuaMachine( Computer computer, TimeoutState timeout )
2017-05-01 14:48:44 +00:00
{
this.computer = computer;
this.timeout = timeout;
this.context = new LuaContext( computer );
debug = new TimeoutDebugHandler();
2017-05-01 14:48:44 +00:00
// Create an environment to run in
LuaState state = this.state = LuaState.builder()
.resourceManipulator( new VoidResourceManipulator() )
.debug( debug )
.coroutineExecutor( command -> {
Tracking.addValue( this.computer, TrackingField.COROUTINES_CREATED, 1 );
COROUTINES.execute( () -> {
try
{
command.run();
}
finally
{
Tracking.addValue( this.computer, TrackingField.COROUTINES_DISPOSED, 1 );
}
} );
} )
.build();
2017-05-01 17:28:17 +00:00
globals = new LuaTable();
state.setupThread( globals );
2017-05-01 17:28:17 +00:00
// Add basic libraries
globals.load( state, new BaseLib() );
globals.load( state, new TableLib() );
globals.load( state, new StringLib() );
globals.load( state, new MathLib() );
globals.load( state, new CoroutineLib() );
globals.load( state, new Bit32Lib() );
globals.load( state, new Utf8Lib() );
if( ComputerCraft.debugEnable ) globals.load( state, new DebugLib() );
2017-05-01 17:28:17 +00:00
2017-05-01 14:48:44 +00:00
// Remove globals we don't want to expose
globals.rawset( "collectgarbage", Constants.NIL );
globals.rawset( "dofile", Constants.NIL );
globals.rawset( "loadfile", Constants.NIL );
globals.rawset( "print", Constants.NIL );
// Add version globals
globals.rawset( "_VERSION", valueOf( "Lua 5.1" ) );
globals.rawset( "_HOST", valueOf( computer.getAPIEnvironment().getComputerEnvironment().getHostString() ) );
globals.rawset( "_CC_DEFAULT_SETTINGS", valueOf( ComputerCraft.defaultComputerSettings ) );
2020-05-15 21:49:12 +00:00
if( ComputerCraft.disableLua51Features )
{
globals.rawset( "_CC_DISABLE_LUA51_FEATURES", Constants.TRUE );
}
2017-05-01 14:48:44 +00:00
}
2017-05-01 17:28:17 +00:00
2017-05-01 14:48:44 +00:00
@Override
public void addAPI( @Nonnull ILuaAPI api )
2017-05-01 14:48:44 +00:00
{
// Add the methods of an API to the global table
LuaTable table = wrapLuaObject( api );
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
if( table == null )
2017-05-01 14:48:44 +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
ComputerCraft.log.warn( "API {} does not provide any methods", api );
table = new LuaTable();
2017-05-01 14:48:44 +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
String[] names = api.getNames();
for( String name : names ) globals.rawset( name, table );
2017-05-01 14:48:44 +00:00
}
2017-05-01 17:28:17 +00:00
2017-05-01 14:48:44 +00:00
@Override
public MachineResult loadBios( @Nonnull InputStream bios )
2017-05-01 14:48:44 +00:00
{
// Begin executing a file (ie, the bios)
if( mainRoutine != null ) return MachineResult.OK;
2017-05-01 17:28:17 +00:00
2017-05-01 14:48:44 +00:00
try
{
LuaFunction value = LoadState.load( state, bios, "@bios.lua", globals );
mainRoutine = new LuaThread( state, value, globals );
return MachineResult.OK;
2017-05-01 17:28:17 +00:00
}
catch( CompileException e )
{
close();
return MachineResult.error( e );
2017-05-01 14:48:44 +00:00
}
catch( Exception e )
2017-05-01 14:48:44 +00:00
{
ComputerCraft.log.warn( "Could not load bios.lua", e );
close();
return MachineResult.GENERIC_ERROR;
2017-05-01 14:48:44 +00:00
}
}
2017-05-01 17:28:17 +00:00
2017-05-01 14:48:44 +00:00
@Override
public MachineResult handleEvent( String eventName, Object[] arguments )
2017-05-01 14:48:44 +00:00
{
if( mainRoutine == null ) return MachineResult.OK;
if( eventFilter != null && eventName != null && !eventName.equals( eventFilter ) && !eventName.equals( "terminate" ) )
2017-05-01 14:48:44 +00:00
{
return MachineResult.OK;
2017-05-01 14:48:44 +00:00
}
2017-05-01 17:28:17 +00:00
// If the soft abort has been cleared then we can reset our flag.
timeout.refresh();
if( !timeout.isSoftAborted() ) debug.thrownSoftAbort = false;
2017-05-01 14:48:44 +00:00
try
2017-05-01 17:28:17 +00:00
{
Varargs resumeArgs = Constants.NONE;
2017-05-01 14:48:44 +00:00
if( eventName != null )
{
2017-05-01 17:28:17 +00:00
resumeArgs = varargsOf( valueOf( eventName ), toValues( arguments ) );
2017-05-01 14:48:44 +00:00
}
2017-05-01 17:28:17 +00:00
// Resume the current thread, or the main one when first starting off.
LuaThread thread = state.getCurrentThread();
if( thread == null || thread == state.getMainThread() ) thread = mainRoutine;
Varargs results = LuaThread.run( thread, resumeArgs );
if( timeout.isHardAborted() ) throw HardAbortError.INSTANCE;
if( results == null ) return MachineResult.PAUSE;
Bump Cobalt version to enable single-threading The latest version of Cobalt has several major changes, which I'm looking forward to taking advantage of in the coming months: - The Lua interpreter has been split up from the actual LuaClosure instance. It now runs multiple functions within one loop, handling pushing/popping and resuming method calls correctly. This means we have a theoretically infinite call depth, as we're no longer bounded by Java's stack size. In reality, this is limited to 32767 (Short.MAX_VALUE), as that's a mostly equivalent to the limits PUC Lua exposes. - The stack is no longer unwound in the event of errors. This both simplifies error handling (not that CC:T needs to care about that) but also means one can call debug.traceback on a now-dead coroutine (which is more useful for debugging than using xpcall). - Most significantly, coroutines are no longer each run on a dedicated thread. Instead, yielding or resuming throws an exception to unwind the Java stack and switches to a different coroutine. In order to preserve compatability with CC's assumption about LuaJ's threading model (namely that yielding blocks the thread), we also provide a yieldBlock method (which CC:T consumes). This suspends the current thread and switches execution to a new thread (see SquidDev/Cobalt@b5ddf164f1c77bc2657f096f39dd167c19270f6d for more details). While this does mean we need to use more than 1 thread, it's still /substantially/ less than would otherwise be needed. We've been running these changes on SwitchCraft for a few days now and haven't seen any issues. One nice thing to observe is that the number of CC thread has gone down from ~1.9k to ~100 (of those, ~70 are dedicated to running coroutines). Similarly, the server has gone from generating ~15k threads over its lifetime, to ~3k. While this is still a lot, it's a substantial improvement.
2019-02-10 21:46:52 +00:00
LuaValue filter = results.first();
eventFilter = filter.isString() ? filter.toString() : null;
2017-05-01 17:28:17 +00:00
if( mainRoutine.getStatus().equals( "dead" ) )
{
close();
return MachineResult.GENERIC_ERROR;
}
else
{
return MachineResult.OK;
}
2017-05-01 14:48:44 +00:00
}
catch( HardAbortError | InterruptedException e )
{
close();
return MachineResult.TIMEOUT;
}
catch( LuaError e )
2017-05-01 14:48:44 +00:00
{
close();
Bump Cobalt version to enable single-threading The latest version of Cobalt has several major changes, which I'm looking forward to taking advantage of in the coming months: - The Lua interpreter has been split up from the actual LuaClosure instance. It now runs multiple functions within one loop, handling pushing/popping and resuming method calls correctly. This means we have a theoretically infinite call depth, as we're no longer bounded by Java's stack size. In reality, this is limited to 32767 (Short.MAX_VALUE), as that's a mostly equivalent to the limits PUC Lua exposes. - The stack is no longer unwound in the event of errors. This both simplifies error handling (not that CC:T needs to care about that) but also means one can call debug.traceback on a now-dead coroutine (which is more useful for debugging than using xpcall). - Most significantly, coroutines are no longer each run on a dedicated thread. Instead, yielding or resuming throws an exception to unwind the Java stack and switches to a different coroutine. In order to preserve compatability with CC's assumption about LuaJ's threading model (namely that yielding blocks the thread), we also provide a yieldBlock method (which CC:T consumes). This suspends the current thread and switches execution to a new thread (see SquidDev/Cobalt@b5ddf164f1c77bc2657f096f39dd167c19270f6d for more details). While this does mean we need to use more than 1 thread, it's still /substantially/ less than would otherwise be needed. We've been running these changes on SwitchCraft for a few days now and haven't seen any issues. One nice thing to observe is that the number of CC thread has gone down from ~1.9k to ~100 (of those, ~70 are dedicated to running coroutines). Similarly, the server has gone from generating ~15k threads over its lifetime, to ~3k. While this is still a lot, it's a substantial improvement.
2019-02-10 21:46:52 +00:00
ComputerCraft.log.warn( "Top level coroutine errored", e );
return MachineResult.error( e );
2017-05-01 14:48:44 +00:00
}
}
2017-05-01 17:28:17 +00:00
2017-05-01 14:48:44 +00:00
@Override
public void close()
2017-05-01 14:48:44 +00:00
{
LuaState state = this.state;
if( state == null ) return;
state.abandon();
mainRoutine = null;
this.state = null;
globals = null;
2017-05-01 14:48:44 +00:00
}
2017-05-01 17:28: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
@Nullable
private LuaTable wrapLuaObject( Object object )
2017-05-01 14:48:44 +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
String[] dynamicMethods = object instanceof IDynamicLuaObject
? Objects.requireNonNull( ((IDynamicLuaObject) object).getMethodNames(), "Methods cannot be null" )
: LuaMethod.EMPTY_METHODS;
2017-05-01 14:48:44 +00:00
LuaTable table = new LuaTable();
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( int i = 0; i < dynamicMethods.length; i++ )
2017-05-01 14:48:44 +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
String method = dynamicMethods[i];
table.rawset( method, new ResultInterpreterFunction( this, LuaMethod.DYNAMIC.get( i ), object, context, method ) );
2017-05-01 14:48:44 +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
ObjectSource.allMethods( LuaMethod.GENERATOR, object, ( instance, method ) ->
table.rawset( method.getName(), method.nonYielding()
? new BasicFunction( this, method.getMethod(), instance, context, method.getName() )
: new ResultInterpreterFunction( this, method.getMethod(), instance, context, method.getName() ) ) );
try
{
if( table.keyCount() == 0 ) return null;
}
catch( LuaError ignored )
{
}
2017-05-01 14:48:44 +00:00
return table;
}
@Nonnull
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
private LuaValue toValue( @Nullable Object object, @Nullable Map<Object, LuaValue> values )
2017-05-01 14:48:44 +00:00
{
if( object == null ) return Constants.NIL;
if( object instanceof Number ) return valueOf( ((Number) object).doubleValue() );
if( object instanceof Boolean ) return valueOf( (Boolean) object );
if( object instanceof String ) return valueOf( object.toString() );
if( object instanceof byte[] )
{
byte[] b = (byte[]) object;
2017-05-01 17:28:17 +00:00
return valueOf( Arrays.copyOf( b, b.length ) );
}
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
if( object instanceof ByteBuffer )
{
ByteBuffer b = (ByteBuffer) object;
byte[] bytes = new byte[b.remaining()];
b.get( bytes );
return valueOf( bytes );
}
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
if( values == null ) values = new IdentityHashMap<>( 1 );
LuaValue result = values.get( object );
if( result != null ) return result;
if( object instanceof ILuaFunction )
{
return new ResultInterpreterFunction( this, FUNCTION_METHOD, object, context, object.toString() );
}
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
if( object instanceof IDynamicLuaObject )
{
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
LuaValue wrapped = wrapLuaObject( object );
if( wrapped == null ) wrapped = new LuaTable();
values.put( object, wrapped );
return wrapped;
}
if( object instanceof Map )
{
2017-05-01 17:28:17 +00:00
LuaTable table = new LuaTable();
values.put( object, table );
for( Map.Entry<?, ?> pair : ((Map<?, ?>) object).entrySet() )
{
2017-05-01 17:28:17 +00:00
LuaValue key = toValue( pair.getKey(), values );
LuaValue value = toValue( pair.getValue(), values );
if( !key.isNil() && !value.isNil() ) table.rawset( key, value );
}
2017-05-01 17:28:17 +00:00
return table;
2017-05-01 14:48:44 +00:00
}
if( object instanceof Collection )
{
Collection<?> objects = (Collection<?>) object;
LuaTable table = new LuaTable( objects.size(), 0 );
values.put( object, table );
int i = 0;
for( Object child : objects ) table.rawset( ++i, toValue( child, values ) );
return table;
}
if( object instanceof Object[] )
{
Object[] objects = (Object[]) object;
LuaTable table = new LuaTable( objects.length, 0 );
values.put( object, table );
for( int i = 0; i < objects.length; i++ ) table.rawset( i + 1, toValue( objects[i], values ) );
return table;
2017-05-01 14:48:44 +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
LuaTable wrapped = wrapLuaObject( object );
if( wrapped != null )
{
values.put( object, wrapped );
return wrapped;
}
if( ComputerCraft.logComputerErrors )
{
ComputerCraft.log.warn( "Received unknown type '{}', returning nil.", object.getClass().getName() );
2017-05-01 17:28:17 +00:00
}
return Constants.NIL;
2017-05-01 14:48:44 +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
Varargs toValues( Object[] objects )
2017-05-01 14:48:44 +00:00
{
if( objects == null || objects.length == 0 ) return Constants.NONE;
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
if( objects.length == 1 ) return toValue( objects[0], null );
2017-05-01 17:28:17 +00:00
Map<Object, LuaValue> result = new IdentityHashMap<>( 0 );
LuaValue[] values = new LuaValue[objects.length];
for( int i = 0; i < values.length; i++ )
2017-05-01 14:48:44 +00:00
{
Object object = objects[i];
values[i] = toValue( object, result );
2017-05-01 14:48:44 +00:00
}
2017-05-01 17:28:17 +00:00
return varargsOf( values );
2017-05-01 14:48:44 +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
static Object toObject( LuaValue value, Map<LuaValue, Object> objects )
2017-05-01 14:48:44 +00:00
{
switch( value.type() )
{
2017-05-01 17:28:17 +00:00
case Constants.TNIL:
case Constants.TNONE:
2017-05-01 14:48:44 +00:00
return null;
2017-05-01 17:28:17 +00:00
case Constants.TINT:
case Constants.TNUMBER:
return value.toDouble();
case Constants.TBOOLEAN:
return value.toBoolean();
case Constants.TSTRING:
return value.toString();
case Constants.TTABLE:
2017-05-01 14:48:44 +00:00
{
// Table:
2017-05-01 17:28:17 +00:00
// Start remembering stuff
if( objects == null )
{
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
objects = new IdentityHashMap<>( 1 );
2017-05-01 17:28: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
else
2017-05-01 17:28: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
Object existing = objects.get( value );
if( existing != null ) return existing;
2017-05-01 17:28:17 +00:00
}
Map<Object, Object> table = new HashMap<>();
objects.put( value, table );
LuaTable luaTable = (LuaTable) value;
// Convert all keys
LuaValue k = Constants.NIL;
while( true )
{
2017-05-01 17:28:17 +00:00
Varargs keyValue;
try
{
2017-05-01 17:28:17 +00:00
keyValue = luaTable.next( k );
}
2017-05-01 17:28:17 +00:00
catch( LuaError luaError )
{
2017-05-01 17:28:17 +00:00
break;
}
2017-05-01 17:28:17 +00:00
k = keyValue.first();
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
if( k.isNil() ) break;
2017-05-01 17:28:17 +00:00
LuaValue v = keyValue.arg( 2 );
Object keyObject = toObject( k, objects );
Object valueObject = toObject( v, objects );
if( keyObject != null && valueObject != null )
{
2017-05-01 17:28:17 +00:00
table.put( keyObject, valueObject );
}
}
2017-05-01 17:28:17 +00:00
return table;
2017-05-01 14:48:44 +00:00
}
default:
return null;
2017-05-01 17:28:17 +00:00
}
2017-05-01 14:48:44 +00:00
}
2017-05-01 17:28: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
static Object[] toObjects( Varargs values )
2017-05-01 14:48:44 +00:00
{
2017-05-01 17:28:17 +00:00
int count = values.count();
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
Object[] objects = new Object[count];
for( int i = 0; i < count; i++ ) objects[i] = toObject( values.arg( i + 1 ), null );
2017-05-01 14:48:44 +00:00
return objects;
}
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
static IArguments toArguments( Varargs values )
{
return values == Constants.NONE ? VarargArguments.EMPTY : new VarargArguments( values );
}
/**
* A {@link DebugHandler} which observes the {@link TimeoutState} and responds accordingly.
*/
private class TimeoutDebugHandler extends DebugHandler
{
private final TimeoutState timeout;
private int count = 0;
boolean thrownSoftAbort;
private boolean isPaused;
private int oldFlags;
private boolean oldInHook;
TimeoutDebugHandler()
{
timeout = CobaltLuaMachine.this.timeout;
}
@Override
public void onInstruction( DebugState ds, DebugFrame di, int pc ) throws LuaError, UnwindThrowable
{
di.pc = pc;
if( isPaused ) resetPaused( ds, di );
// We check our current pause/abort state every 128 instructions.
if( (count = (count + 1) & 127) == 0 )
{
// If we've been hard aborted or closed then abort.
if( timeout.isHardAborted() || state == null ) throw HardAbortError.INSTANCE;
timeout.refresh();
if( timeout.isPaused() )
{
// Preserve the current state
isPaused = true;
oldInHook = ds.inhook;
oldFlags = di.flags;
// Suspend the state. This will probably throw, but we need to handle the case where it won't.
di.flags |= FLAG_HOOKYIELD | FLAG_HOOKED;
LuaThread.suspend( ds.getLuaState() );
resetPaused( ds, di );
}
handleSoftAbort();
}
super.onInstruction( ds, di, pc );
}
@Override
public void poll() throws LuaError
{
// If we've been hard aborted or closed then abort.
LuaState state = CobaltLuaMachine.this.state;
if( timeout.isHardAborted() || state == null ) throw HardAbortError.INSTANCE;
timeout.refresh();
if( timeout.isPaused() ) LuaThread.suspendBlocking( state );
handleSoftAbort();
}
private void resetPaused( DebugState ds, DebugFrame di )
{
// Restore the previous paused state
isPaused = false;
ds.inhook = oldInHook;
di.flags = oldFlags;
}
private void handleSoftAbort() throws LuaError
{
// If we already thrown our soft abort error then don't do it again.
if( !timeout.isSoftAborted() || thrownSoftAbort ) return;
thrownSoftAbort = true;
throw new LuaError( TimeoutState.ABORT_MESSAGE );
}
}
private static final class HardAbortError extends Error
Bump Cobalt version to enable single-threading The latest version of Cobalt has several major changes, which I'm looking forward to taking advantage of in the coming months: - The Lua interpreter has been split up from the actual LuaClosure instance. It now runs multiple functions within one loop, handling pushing/popping and resuming method calls correctly. This means we have a theoretically infinite call depth, as we're no longer bounded by Java's stack size. In reality, this is limited to 32767 (Short.MAX_VALUE), as that's a mostly equivalent to the limits PUC Lua exposes. - The stack is no longer unwound in the event of errors. This both simplifies error handling (not that CC:T needs to care about that) but also means one can call debug.traceback on a now-dead coroutine (which is more useful for debugging than using xpcall). - Most significantly, coroutines are no longer each run on a dedicated thread. Instead, yielding or resuming throws an exception to unwind the Java stack and switches to a different coroutine. In order to preserve compatability with CC's assumption about LuaJ's threading model (namely that yielding blocks the thread), we also provide a yieldBlock method (which CC:T consumes). This suspends the current thread and switches execution to a new thread (see SquidDev/Cobalt@b5ddf164f1c77bc2657f096f39dd167c19270f6d for more details). While this does mean we need to use more than 1 thread, it's still /substantially/ less than would otherwise be needed. We've been running these changes on SwitchCraft for a few days now and haven't seen any issues. One nice thing to observe is that the number of CC thread has gone down from ~1.9k to ~100 (of those, ~70 are dedicated to running coroutines). Similarly, the server has gone from generating ~15k threads over its lifetime, to ~3k. While this is still a lot, it's a substantial improvement.
2019-02-10 21:46:52 +00:00
{
private static final long serialVersionUID = 7954092008586367501L;
static final HardAbortError INSTANCE = new HardAbortError();
Bump Cobalt version to enable single-threading The latest version of Cobalt has several major changes, which I'm looking forward to taking advantage of in the coming months: - The Lua interpreter has been split up from the actual LuaClosure instance. It now runs multiple functions within one loop, handling pushing/popping and resuming method calls correctly. This means we have a theoretically infinite call depth, as we're no longer bounded by Java's stack size. In reality, this is limited to 32767 (Short.MAX_VALUE), as that's a mostly equivalent to the limits PUC Lua exposes. - The stack is no longer unwound in the event of errors. This both simplifies error handling (not that CC:T needs to care about that) but also means one can call debug.traceback on a now-dead coroutine (which is more useful for debugging than using xpcall). - Most significantly, coroutines are no longer each run on a dedicated thread. Instead, yielding or resuming throws an exception to unwind the Java stack and switches to a different coroutine. In order to preserve compatability with CC's assumption about LuaJ's threading model (namely that yielding blocks the thread), we also provide a yieldBlock method (which CC:T consumes). This suspends the current thread and switches execution to a new thread (see SquidDev/Cobalt@b5ddf164f1c77bc2657f096f39dd167c19270f6d for more details). While this does mean we need to use more than 1 thread, it's still /substantially/ less than would otherwise be needed. We've been running these changes on SwitchCraft for a few days now and haven't seen any issues. One nice thing to observe is that the number of CC thread has gone down from ~1.9k to ~100 (of those, ~70 are dedicated to running coroutines). Similarly, the server has gone from generating ~15k threads over its lifetime, to ~3k. While this is still a lot, it's a substantial improvement.
2019-02-10 21:46:52 +00:00
private HardAbortError()
{
super( "Hard Abort", null, true, false );
}
}
}