1
0
mirror of https://github.com/SquidDev-CC/CC-Tweaked synced 2024-11-17 15:24:52 +00:00
Commit Graph

21 Commits

Author SHA1 Message Date
Jonathan Coates
7eb3b691da
Fix misplaced calls to IArguments.escapes
- Fix mainThread=true methods calling IArguments.escapes too late. This
   should be done before scheduling on the main thread, not on the main
   thread itself!

 - Fix VarargsArguments.escapes not checking that the argument haven't
   been closed. This is slightly prone to race conditions, but I don't
   think it's worth the overhead of tracking the owning thread.

   Maybe when panama and its resource scopes are released.

Thanks Sara for pointing this out!

Slightly irked that none of our tests caught this. Alas.

Also fix a typo in AddressPredicate. Yes, no commit discipline.
2023-06-27 18:28:54 +01:00
Jonathan Coates
3112f455ae
Support arguments being coerced from strings
In this case, we use Lua's tostring(x) semantics (well, modulo
metamethods), instead of Java's Object.toString(x) call. This ensures
that values are formatted (mostly) consistently between Lua and Java
methods.

 - Add IArguments.getStringCoerced, which uses Lua's tostring semantics.

 - Add a Coerced<T> wrapper type, which says to use the .getXCoerced
   methods. I'm not thrilled about this interface - there's definitely
   an argument for using annotations - but this is probably more
   consistent for now.

 - Convert existing methods to use this call.

Closes #1445
2023-05-20 18:54:22 +01:00
Jonathan Coates
8fe509ecb1
Properly scope IArguments to the current function call
This is a horrible commit: It's a breaking change in a pretty subtle
way, which means it won't be visible while updating. Fortunately I think
the only mod on 1.19.4 is Plethora, but other mods (Mek, Advanced
Peripherals) may be impacted when they update. Sorry!

For some motivation behind the original issue:

The default IArguments implementation (VarargArguments) lazily converts
Lua arguments to Java ones. This is mostly important when passing tables
to Java functions, as we can avoid the conversion entirely if the
function uses IArguments.getTableUnsafe.

However, this lazy conversion breaks down if IArguments is accessed on a
separate thread, as Lua values are not thread-safe. Thus we need to
perform this conversion before the cross-thread sharing occurs.

Now, ideally this would be an implementation detail and entirely
invisible to the user. One approach here would be to only perform this
lazy conversion for methods annotated with @LuaFunction(unsafe=true),
and have it be eager otherwise.

However, the peripheral API gets in the way here, as it means we can no
longer inspect the "actual" method being invoked. And so, alas, this
must leak into the public API.

TLDR: If you're getting weird errors about scope, add an
IArguments.escapes() call before sharing the arguments between threads.

Closes #1384
2023-04-01 11:09:03 +01:00
Jonathan Coates
a9547d1d6f
Further licensing work
- Fix several inaccuracies with several files not marking Dan's
   authorship. Most of these are new files, where the code was moved from
   somewhere else:
   - In the public API:  IDynamicLuaObject, ILuaAPI, TaskCallbakc,
     IDynamicPeripheral, UpgradeBase
   - In the ROM: fs, http, require

 - Do not mark Dan as an author for entirely new code. This affects
   DetailHelpers, DropConsumer, FluidData, InventoryMethods, ItemDetails,
   MonitorRenderState, NoTermComputerScreen, Palette, PlatformHelperImpl,
   UploadFileMessage, the Terminal tests, and any speaker-related files.

 - Relicence many files under the MPL where we have permission to do
   so. See #1339 for further details.

Thank you to everyone who has contributed so far! Cannot overstate how
appreciated it is <3.
2023-03-29 23:00:18 +01:00
Jonathan Coates
435aea18dc
Some cleanup to argument checking
- Consult __name in native code too. Closes #1355. This has the added
   advantage that unconvertable values (i.e. functions) will now
   correctly be reported as their original type, not just nil.

 - Fix the error message in cc.expect, so it matches the rest of Lua.
   This has been bugging me for years, and I keep forgetting to change
   it.
2023-03-28 19:17:15 +01:00
Jonathan Coates
895bc7721a
License CC:T according to the REUSE specification (#1351)
This adds SPDX license headers to all source code files, following the
REUSE[1] specification. This does not include any asset files (such as
generated JSON files, or textures). While REUSE does support doing so
with ".license" files, for now we define these licences using the
.reuse/dep5 file.

[1]: https://reuse.software/
2023-03-15 21:52:13 +00:00
Jonathan Coates
e7fe22d4f8
Don't round trip values in executeMainThreadTask
I've been meaning to fix this for over 6 years, and just kept
forgetting.

Previously ILuaContext.executeMainThreadTask worked by running
ILuaContext.issueMainThreadTask, pulling task_complete events, and then
returning the results.

While this makes the implementation simple, it means that the task's
results were converted into Lua values (in order to queue the event) and
then back into Java ones (when the event was pulled), before eventually
being converted into Lua once more.

Not only is this inefficient, as roundtripping isn't lossless, you
couldn't return functions or rich objects from main thread functions
(see https://github.com/dan200/ComputerCraft/issues/125).

We now store the return value on the Java side and then return that when
the receiving the task_complete event - the event no longer carries the
result. Note this does not affect methods using issueMainThreadTask!
2022-12-15 20:19:28 +00:00
Jonathan Coates
0787e17ebe
Use git shortlog for gathering contributors 2022-12-13 20:31:59 +00:00
Jonathan Coates
18fbd96c10
Some further improvemnets to mount error handling
- Correctly handle FileOperationExceptions for the root mount.
 - Remove some checks from MountWrapper: Mount/WritableMount should do
   these already!
 - Normalise file paths, always using a '/'.
2022-12-10 12:54:49 +00:00
Jonathan Coates
367773e173
Some refactoring of mounts
- Separate FileMount into separate FileMount and WritableFileMount
   classes. This separates the (relatively simple) read-only code from
   the (soon to be even more complex) read/write code.

   It also allows you to create read-only mounts which don't bother with
   filesystem accounting, which is nice.

 - Make openForWrite/openForAppend always return a SeekableFileHandle.
   Appendable files still cannot be seeked within, but that check is now
   done on the FS side.

 - Refactor the various mount tests to live in test contract interfaces,
   allowing us to reuse them between mounts.

 - Clean up our error handling a little better. (Most) file-specific code
   has been moved to FileMount, and ArchiveMount-derived classes now
   throw correct path-localised exceptions.
2022-12-09 22:02:31 +00:00
Jonathan Coates
9962ce1a5c
Finish a sentence
Folks have been waiting 2 years for this, it's time to end the suspense.
2022-12-07 09:53:16 +00:00
Jonathan Coates
020c5cd2d3
Support renaming files directly without copying/deleting
In classic squid tradition: 20% code, and 80% test logic.

Closes #962. Alas, whoever reported this has deleted their account, so
they can't even be happy about it :(.
2022-12-04 21:59:30 +00:00
Jonathan Coates
fc5f296eeb
Make Mount.openForRead always return a SeekableByteChannel
I want to make some further changes to Mount here, but this helps
simplify BinaryReadableHandle a little.
2022-12-03 18:20:50 +00:00
Jonathan Coates
c96172e78d
Refactor common {Jar,Resource}Mount code into a parent class 2022-12-03 18:02:12 +00:00
Jonathan Coates
87c6d3aef6
Initial pass of the API breaking changes for 1.19.3 (#1232)
- Remove deprecated API members in prep for 1.19.3. This allows us to
   remove the mc-stubs and forge-stubs projects.

 - Make several methods take a MinecraftServer instead of a Level (or
   nothing at all).

 - Remove I prefixes from a whole bunch of interfaces, making things a
   little more consistent with Java conventions.

   This avoids touching the "main" interfaces people consume for now. I
   want to do that another Minecraft version, to avoid making the update
   too painful.

 - Remove IFileSystem and associated getters. This has never worked very
   well and I don't think has got much (any?) usage.
2022-12-03 15:02:00 +00:00
Drew Edwards
47816805fb
Check the filesystem for isReadOnly (#1226) 2022-11-25 20:40:40 +00:00
Jonathan Coates
b36b96e0bc
Make the main mod non-null by default
This was actually much more work than I thought it would be. Tests pass,
but I'm sure there's some regressions in here.
2022-11-09 18:59:51 +00:00
Jonathan Coates
320007dbc6
Improve packaging of published jars
- Publish javadoc again: for now this is just the common-api

 - Remove all dependencies from the published Forge jar. This is
   technically not needed (fg.deobf does this anyway), but seems
   sensible.
2022-11-08 16:43:27 +00:00
Jonathan Coates
c82f37d3bf
Switch the core library to be non-null by default
See comments in c8c128d335 for further
details. This requires /relatively/ few changes - mostly cases we were
missing @Nullable annotations.
2022-11-06 11:55:26 +00:00
Jonathan Coates
c8c128d335
Switch the core-api to be non-null by default
We'll do this everywhere eventually, but much easier to do it
incrementally:

 - Use checker framework to default all field/methods/parameters to
   @Nonnull.

 - Start using ErrorProne[1] and NullAway[2] to check for possible null
   pointer issues. I did look into using CheckerFramework, but it's much
   stricter (i.e. it's actually Correct). This is technically good, but
   is a much steeper migration path, which I'm not sure we're prepared
   for yet!

[1]: https://github.com/google/error-prone
[2]: https://github.com/uber/NullAway
2022-11-06 10:28:49 +00:00
Jonathan Coates
a17b001950
Move the core API into a separate module
It should be possible to consume the ComputerCraft's core (i.e.
non-Minecraft code) in other projects, such as emulators.  While this
has been possible for years, it's somewhat tricky from a maintenance
perspective - it's very easy to accidentally add an MC dependency
somewhere!

By publishing a separate "core" jar, we can better distinguish the
boundaries between our Lua runtime and the Minecraft-specific code.

Ideally we could have one core project (rather than separate core and
core-api modules), and publish a separate "api" jar, like we do for the
main mod. However, this isn't really possible to express using Maven
dependencies, and so we must resort to this system.

Of course, this is kinda what the Java module system is meant to solve,
but unfortunately getting that working with Minecraft is infeasible.
2022-11-04 21:41:59 +00:00