mirrors/CC-Tweaked
1
0
Fork 0
mirror of https://github.com/SquidDev-CC/CC-Tweaked synced 2024-06-16 10:09:55 +00:00
Code Issues Releases Wiki Activity
a6a1b9b8e5
CC-Tweaked/src/main/java/dan200/computercraft/core/apis/handles/HandleGeneric.java

115 lines
3.3 KiB
Java
Raw Normal View History

Fix binary handles reading in multiples of 8192
2018-12-31 09:41:58 +00:00
/*
* This file is part of ComputerCraft - http://www.computercraft.info
Happy new year
2020-01-01 00:09:18 +00:00
* Copyright Daniel Ratcliffe, 2011-2020. Do not distribute without permission.
Fix binary handles reading in multiples of 8192
2018-12-31 09:41:58 +00:00
* Send enquiries to dratcliffe@gmail.com
*/
Refactor the filesystem and HTTP code - Move the encoding/decoding from the Filesystem implementation to the individual handles. - Move each handle into an core.apis.handles package from the main fs API. - Move the HTTP response to inherit from these handles. - Allow binary handles' read function to accept a number, specifying how many characters to read - these will be returned as a Lua string. - Add readAll to binary handles - Allow binary handles' write function to accept a string which is decoded into the individual bytes. - Add "binary" argument to http.request and friends in order to return a binary handle. - Ensure file handles are open when reading from/writing to them. - Return the error message when opening a file fails.
2017-05-12 21:49:44 +00:00
package dan200.computercraft.core.apis.handles;
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;
WIP: Http rework (#98) - Move all HTTP tasks to a unified "MonitoredResource" model. This provides a uniform way of tracking object's lifetimes and disposing of them when complete. - Rewrite HTTP requests to use Netty instead of standard Java. This offers several advantages: - We have access to more HTTP verbs (mostly PATCH). - We can now do http -> https redirects. - We no longer need to spawn in a new thread for each HTTP request. While we do need to run some tasks off-thread in order to resolve IPs, it's generally a much shorter task, and so is less likely to inflate the thread pool. - Introduce several limits for the http API: - There's a limit on how many HTTP requests and websockets may exist at the same time. If the limit is reached, additional ones will be queued up until pending requests have finished. - HTTP requests may upload a maximum of 4Mib and download a maximum of 16Mib (configurable). - .getResponseCode now returns the status text, as well as the status code.
2019-01-11 11:33:05 +00:00
import dan200.computercraft.shared.util.IoUtil;
Refactor the filesystem and HTTP code - Move the encoding/decoding from the Filesystem implementation to the individual handles. - Move each handle into an core.apis.handles package from the main fs API. - Move the HTTP response to inherit from these handles. - Allow binary handles' read function to accept a number, specifying how many characters to read - these will be returned as a Lua string. - Add readAll to binary handles - Allow binary handles' write function to accept a string which is decoded into the individual bytes. - Add "binary" argument to http.request and friends in order to return a binary handle. - Ensure file handles are open when reading from/writing to them. - Return the error message when opening a file fails.
2017-05-12 21:49:44 +00:00
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +00:00
import javax.annotation.Nonnull;
Refactor the filesystem and HTTP code - Move the encoding/decoding from the Filesystem implementation to the individual handles. - Move each handle into an core.apis.handles package from the main fs API. - Move the HTTP response to inherit from these handles. - Allow binary handles' read function to accept a number, specifying how many characters to read - these will be returned as a Lua string. - Add readAll to binary handles - Allow binary handles' write function to accept a string which is decoded into the individual bytes. - Add "binary" argument to http.request and friends in order to return a binary handle. - Ensure file handles are open when reading from/writing to them. - Return the error message when opening a file fails.
2017-05-12 21:49:44 +00:00
import java.io.Closeable;
import java.io.IOException;
Fix resource handle loading See #70
2018-10-29 15:59:43 +00:00
import java.nio.channels.Channel;
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +00:00
import java.nio.channels.SeekableByteChannel;
Add a whole tonne of documentation There's a bit of duplication here, so we might try to clean this up, but it's a good starting point.
2020-07-09 20:59:19 +00:00
import java.util.Optional;
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +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 abstract class HandleGeneric
Refactor the filesystem and HTTP code - Move the encoding/decoding from the Filesystem implementation to the individual handles. - Move each handle into an core.apis.handles package from the main fs API. - Move the HTTP response to inherit from these handles. - Allow binary handles' read function to accept a number, specifying how many characters to read - these will be returned as a Lua string. - Add readAll to binary handles - Allow binary handles' write function to accept a string which is decoded into the individual bytes. - Add "binary" argument to http.request and friends in order to return a binary handle. - Ensure file handles are open when reading from/writing to them. - Return the error message when opening a file fails.
2017-05-12 21:49: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
private Closeable closable;
private boolean open = true;
Refactor the filesystem and HTTP code - Move the encoding/decoding from the Filesystem implementation to the individual handles. - Move each handle into an core.apis.handles package from the main fs API. - Move the HTTP response to inherit from these handles. - Allow binary handles' read function to accept a number, specifying how many characters to read - these will be returned as a Lua string. - Add readAll to binary handles - Allow binary handles' write function to accept a string which is decoded into the individual bytes. - Add "binary" argument to http.request and friends in order to return a binary handle. - Ensure file handles are open when reading from/writing to them. - Return the error message when opening a file fails.
2017-05-12 21:49:44 +00:00
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +00:00
protected HandleGeneric( @Nonnull Closeable closable )
Refactor the filesystem and HTTP code - Move the encoding/decoding from the Filesystem implementation to the individual handles. - Move each handle into an core.apis.handles package from the main fs API. - Move the HTTP response to inherit from these handles. - Allow binary handles' read function to accept a number, specifying how many characters to read - these will be returned as a Lua string. - Add readAll to binary handles - Allow binary handles' write function to accept a string which is decoded into the individual bytes. - Add "binary" argument to http.request and friends in order to return a binary handle. - Ensure file handles are open when reading from/writing to them. - Return the error message when opening a file fails.
2017-05-12 21:49: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
this.closable = closable;
Refactor the filesystem and HTTP code - Move the encoding/decoding from the Filesystem implementation to the individual handles. - Move each handle into an core.apis.handles package from the main fs API. - Move the HTTP response to inherit from these handles. - Allow binary handles' read function to accept a number, specifying how many characters to read - these will be returned as a Lua string. - Add readAll to binary handles - Allow binary handles' write function to accept a string which is decoded into the individual bytes. - Add "binary" argument to http.request and friends in order to return a binary handle. - Ensure file handles are open when reading from/writing to them. - Return the error message when opening a file fails.
2017-05-12 21:49:44 +00:00
}
protected void checkOpen() throws 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
if( !open ) throw new LuaException( "attempt to use a closed file" );
Refactor the filesystem and HTTP code - Move the encoding/decoding from the Filesystem implementation to the individual handles. - Move each handle into an core.apis.handles package from the main fs API. - Move the HTTP response to inherit from these handles. - Allow binary handles' read function to accept a number, specifying how many characters to read - these will be returned as a Lua string. - Add readAll to binary handles - Allow binary handles' write function to accept a string which is decoded into the individual bytes. - Add "binary" argument to http.request and friends in order to return a binary handle. - Ensure file handles are open when reading from/writing to them. - Return the error message when opening a file fails.
2017-05-12 21:49:44 +00:00
}
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +00:00
protected final void close()
Refactor the filesystem and HTTP code - Move the encoding/decoding from the Filesystem implementation to the individual handles. - Move each handle into an core.apis.handles package from the main fs API. - Move the HTTP response to inherit from these handles. - Allow binary handles' read function to accept a number, specifying how many characters to read - these will be returned as a Lua string. - Add readAll to binary handles - Allow binary handles' write function to accept a string which is decoded into the individual bytes. - Add "binary" argument to http.request and friends in order to return a binary handle. - Ensure file handles are open when reading from/writing to them. - Return the error message when opening a file fails.
2017-05-12 21:49: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
open = false;
Ensure files cannot be closed multiple times Also fix an NPE if we try to close them twice. Fixes #230
2019-06-04 20:34:19 +00:00
Merge branch 'mc-1.14.x' into mc-1.15.x # Conflicts: # gradle.properties # src/main/java/dan200/computercraft/client/render/MonitorTextureBufferShader.java # src/main/java/dan200/computercraft/client/render/TileEntityMonitorRenderer.java # src/main/java/dan200/computercraft/core/apis/handles/HandleGeneric.java # src/main/java/dan200/computercraft/shared/Config.java # src/main/java/dan200/computercraft/shared/network/NetworkHandler.java # src/main/java/dan200/computercraft/shared/peripheral/monitor/TileMonitor.java # src/main/java/dan200/computercraft/shared/turtle/apis/TurtleAPI.java # src/main/resources/data/computercraft/lua/rom/help/changelog.txt # src/main/resources/data/computercraft/lua/rom/help/whatsnew.txt
2020-06-16 08:24:14 +00:00
IoUtil.closeQuietly( closable );
closable = null;
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +00:00
}
Add a whole tonne of documentation There's a bit of duplication here, so we might try to clean this up, but it's a good starting point.
2020-07-09 20:59:19 +00:00
/**
* Close this file, freeing any resources it uses.
*
* Once a file is closed it may no longer be read or written to.
*
* @throws LuaException If the file has already been closed.
*/
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( "close" )
public final void doClose() throws LuaException
{
checkOpen();
close();
}
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +00:00
/**
Make our Javadoc validation a little stricter I'm not sure there's much utility in this, but still feels worth doing.
2019-10-27 15:16:47 +00:00
* Shared implementation for various file handle types.
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +00:00
*
* @param channel The channel to seek in
Add a whole tonne of documentation There's a bit of duplication here, so we might try to clean this up, but it's a good starting point.
2020-07-09 20:59:19 +00:00
* @param whence The seeking mode.
* @param offset The offset to seek to.
Turn inspections up to 11 OK, so let's get this out of the way, there's some actual changes mixed in here too. I'm really sorry: - Turtles can now not be renamed with unnamed item tags (previously it would clear the name, this seemed a little unideal). - commands.getBlock(s)Data will also include NBT. Now, onto the horror story which is these inspection changes: - Make a lot of methods static - Typo fixes - Make utility classes final + private constructor - Lots of reformatting (ifs -> ternary, invert control flow, etc...) - ??? - Profit! I'm so going to regret this - can pretty much guarantee this is going to break something.
2019-03-29 21:21:39 +00:00
* @return The new position of the file, or null if some error occurred.
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +00:00
* @throws LuaException If the arguments were invalid
* @see <a href="https://www.lua.org/manual/5.1/manual.html#pdf-file:seek">{@code file:seek} in the Lua manual.</a>
*/
Add a whole tonne of documentation There's a bit of duplication here, so we might try to clean this up, but it's a good starting point.
2020-07-09 20:59:19 +00:00
protected static Object[] handleSeek( SeekableByteChannel channel, Optional<String> whence, Optional<Long> offset ) throws LuaException
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +00:00
{
Add a whole tonne of documentation There's a bit of duplication here, so we might try to clean this up, but it's a good starting point.
2020-07-09 20:59:19 +00:00
long actualOffset = offset.orElse( 0L );
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +00:00
try
{
Add a whole tonne of documentation There's a bit of duplication here, so we might try to clean this up, but it's a good starting point.
2020-07-09 20:59:19 +00:00
switch( whence.orElse( "cur" ) )
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +00:00
{
case "set":
Add a whole tonne of documentation There's a bit of duplication here, so we might try to clean this up, but it's a good starting point.
2020-07-09 20:59:19 +00:00
channel.position( actualOffset );
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +00:00
break;
case "cur":
Add a whole tonne of documentation There's a bit of duplication here, so we might try to clean this up, but it's a good starting point.
2020-07-09 20:59:19 +00:00
channel.position( channel.position() + actualOffset );
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +00:00
break;
case "end":
Add a whole tonne of documentation There's a bit of duplication here, so we might try to clean this up, but it's a good starting point.
2020-07-09 20:59:19 +00:00
channel.position( channel.size() + actualOffset );
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +00:00
break;
default:
throw new LuaException( "bad argument #1 to 'seek' (invalid option '" + whence + "'" );
}
Reformat everything It's been a long time comin' But tonight is the end of the war, my friend Tomorrow only one style will remain.
2018-12-23 17:46:58 +00:00
return new Object[] { channel.position() };
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +00:00
}
catch( IllegalArgumentException e )
{
Add a whole tonne of documentation There's a bit of duplication here, so we might try to clean this up, but it's a good starting point.
2020-07-09 20:59:19 +00:00
return new Object[] { null, "Position is negative" };
Rewrite file systems to use ByteChannels This replaces the existing IMount openFor* method with openChannelFor* ones, which return an appropriate byte channel instead. As channels are not correctly closed when GCed, we introduce a FileSystemWrapper. We store a weak reference to this, and when it is GCed or the file closed, we will remove it from our "open file" set and ensure any underlying buffers are closed. While this change may seem a little odd, it does introduce some benefits: - We can replace JarMount with a more general FileSystemMount. This does assume a read-only file system, but could technically be used for other sources. - Add support for seekable (binary) handles. We can now look for instances of SeekableByteChannel and dynamically add it. This works for all binary filesystem and HTTP streams. - Rewrite the io library to more accurately emulate PUC Lua's implementation. We do not correctly implement some elements (most noticably "*n", but it's a definite improvement.
2018-09-21 15:00:26 +00:00
}
catch( IOException e )
{
return null;
}
Refactor the filesystem and HTTP code - Move the encoding/decoding from the Filesystem implementation to the individual handles. - Move each handle into an core.apis.handles package from the main fs API. - Move the HTTP response to inherit from these handles. - Allow binary handles' read function to accept a number, specifying how many characters to read - these will be returned as a Lua string. - Add readAll to binary handles - Allow binary handles' write function to accept a string which is decoded into the individual bytes. - Add "binary" argument to http.request and friends in order to return a binary handle. - Ensure file handles are open when reading from/writing to them. - Return the error message when opening a file fails.
2017-05-12 21:49:44 +00:00
}
Fix resource handle loading See #70
2018-10-29 15:59:43 +00:00
protected static SeekableByteChannel asSeekable( Channel channel )
{
if( !(channel instanceof SeekableByteChannel) ) return null;
SeekableByteChannel seekable = (SeekableByteChannel) channel;
try
{
seekable.position( seekable.position() );
return seekable;
}
catch( IOException | UnsupportedOperationException e )
{
return null;
}
}
Refactor the filesystem and HTTP code - Move the encoding/decoding from the Filesystem implementation to the individual handles. - Move each handle into an core.apis.handles package from the main fs API. - Move the HTTP response to inherit from these handles. - Allow binary handles' read function to accept a number, specifying how many characters to read - these will be returned as a Lua string. - Add readAll to binary handles - Allow binary handles' write function to accept a string which is decoded into the individual bytes. - Add "binary" argument to http.request and friends in order to return a binary handle. - Ensure file handles are open when reading from/writing to them. - Return the error message when opening a file fails.
2017-05-12 21:49:44 +00:00
}
Reference in New Issue Copy Permalink