Just to prove to myself that it works! Specifically, I have some
concerns with HTTP streaming about how that will interact with bandwidth
limits, so having this in place should make it easier to write further
tests.
7c60ed109f already proving useful. As we
no longer have any global state we can run these tests in parallel.
I wrote this ages ago when looking at alternative GPS arrays for #1681.
None of the designs I've tried seem any more reliable, and still have
some positions where they fail, hence this test being marked "pending".
- Split JSON and SNBT parsers up, and move them into their own
modules. While there is a lot of overlap, there's sufficient
difference it's not worth trying to keep them the same.
- Update SNBT parser to support most of 26.3's features.
Fixes#2277.
- Correctly send a close websocket frame when a websocket is manually
closed (status code 1000) or is garbage collected (1001). Computer
shutdowns still just close the socket, as we don't/can't wait for the
socket to cleanly shutdown.
- After a user calls close(), don't mark the websocket as closed until
we receive the server's close response. This means we now have a
slightly awkward interstitial state where we can receive messages but
not send them, but I don't think there's much we can do about that.
Fixes#2096
A bit simpler, means we don't have to poll it every tick.
I had one test failure in the websocket code where the websocket was
GCed and closed too early, so adding some reference fences in here. I've
not been able to reproduce this, so fingers crossed it works.
Add a new HttpHandler interface, which handles checkUrl, request and
websocket calls for a computer. The default implementation is provided
by a NettyHttp class, which also stores any related HTTP config and
state.
This is a little over-engineered, but has two advantages:
- Our Javascript/TeaVM implementation can now just implement this
interface, rather than patching/overwriting classes.
- This removes the final (large) bits of global state/config from
CC:T's core. Our tests no longer need to temporarily override global
address rules, and the traffic shaping handler no longer requires
resetting.
It might be a bit nicer to move all the netty-specific code into a
dan200.computercraft.apis.http.netty package, so there's some cleaner
separation from the common code, but I'm trying to avoid moving code
about any more than I have to.
Within our TeaVM code we currently do some class rewriting magic to
replace individual classes, such as ComputerThread. However, all our
code is written to allow changing these implementations already, it's
just TeaVM isn't smart enough to look through our builder and realise
it's dead code!
We now make the ComputerContext's constructor public (though
deprecated), which allows our TeaVM code to call it directly.
Unlike (Neo)Forge, Fabric's transfer API distinguishes between slotted
containers (such as chests) and non-slotted ones (such as bundles). Our
current code (and interface) currently assumes everything to have slots,
but for #2213, we need a way to support non-slotted containers.
We can't really change the interface here, so instead we go the other
route: treat the Iterable<StorageView<...>> as a list of slots. This is
pretty gross (which is why I've put it off for so long), but easy enough
to implement.
This is an identical fix to 013f2e500f,
but for computers rather than redstone integrators.
I don't love the duplication — it might make more sense to move this
into RedstoneState.updateOutput and have an "initial tick" flag there
instead.
Fixes#2392.
- Fix missing license header and some over-eager gitignore removals.
- Fix several isolated project errors. I think all the remaining ones
come from limitations in other projects:
- MDG's mod configs don't support referencing source sets from other
projects.
- idea-ext is terrible in every way.
There's some nastiness in MergeTrees where we can't do
`resources.elements.map { it.single() }` as it throws a configuration
cache error, so we now use a ConfigurableFileCollection. Somehow it
still works.
- Fix a whole bunch of ErrorProne warnings. It's still quite noisy, but
most of the remaining ones now come from Java.
- Move some config from java-conventions to a new base-conventions,
which can be used for non-Java projects. As part of this, we now kill
the CCTweaked plugin, and just install the cct extension in
base-conventions instead.
- Kill inlineProject/externalSources. We now:
- Add an embeddedProject configuration which is used to define
projects that are embedded within the final jar. We do some fun
variant resolution in ExternalProjectArtifacts to extract the
class/resource/source directories from the configuration.
- Add a new verifyClassesMatch task which recompiles the game and
ensures compiling everything against the loader's version of
Minecraft gives us the same result.
There's some really awkward duplication in the HTTP API right now, where
the Lua code reimplements the validation the Java implementation
provides, in order to throw errors at the right level.
In this particular case, our Lua validation was stricter than the Java,
only permitting a known set of verbs. This commit:
- Makes the Java-side validation a little stricter, to only allow verbs
matching [A-Z_-]{1,32}. This is strictly much stricter than what the
HTTP spec allows, but I think makes sense as a restriction.
- Update the Lua wrapper to match this logic, rather than being
stricter.
Fixes#2501.
- Fix *some* cross-project isolation issues. This appears to be the
bare minimum to make the configuration cache happy. There is
obviously a lot more work to do here.
- Enable Configuration cache.
- Fix some new checkstyle/errorprone/nullaway warnings.
Using typos[^1]. I wrote a config for this years ago, but never checked
it in. All things considered, there's fewer than I expected.
Fun fact: the CCPL contains the text "if added to to the main
repository", and I can't/shouldn't fix it, because it's an external
license!
[^1]: https://github.com/crate-ci/typos/
This dates back from when we had multiple MC versions in a single
project (see the build-tools branch). We don't do this any more, so no
need for it.
(More importantly, something has changed in IDEA/Gradle so that the
1.20.1 now is escaped as 1_20_1, which breaks Fabric Loom).
When we resume a process, the code looks like:
resumeProcess(nCurrentProcess, ...)
if cullProcess(nCurrentProcess, ...) then ... end
However, if the focused tab changes while resuming (via
multishell.setFocus), then we don't cull the correct process!
To fix this, we just add a helper function which resumes+culls, meaning
we only read the mutable global once.
The "type" field definitions for the "edit.autocomplete" and
"lua.autocomplete" settings were both randomly indented, compared to the
rest of the setting definitions.
Just clarify a couple of things which are a little confusing.
- Explicitly initialise the position within deployOnEntity, rather than
relying on getWithPosition above.
- Rename "position" to "blockPos" in deployOnBlock to make it clearer
whose position it is.
- Clarify that we need to call use(...) for all directions.
When we upgrade a normal pocket computer to an advanced one, we need to
create a new ServerComputer instance (and destroy the old one).
On 1.20.1 the ComputerUpgradeRecipe does not preserve the
instance/session ID on the resulting stack. When the item is next
ticked, we create a new computer, with the old computer no longer being
kept alive and eventually dying.
On 1.21.1 we copy all components, *including* the the current computer
reference. This means a new computer is never created and so we continue
to use the old one (with the wrong family). We could exclude the
computer component from the recipe (and so have the same behaviour as
1.20.1), but by adding a hook in onCraftedBy we can destroy the old
computer immediately, ensuring it no longer continues to run.
Fixes#2479.
- Check whether impostor recipes (and other custom shaped/shapeless
recipes) match the "real" recipe.
- Check whether our upgrade recipe generator generates valid recipes.
Reasoning about left/right upgrades (and top/back ones on 26.2) is a
bit confusing, so this should prevent any errors.
Now we just use builtin INetAddress predicates or HostRange, rather than
a mix of custom predicates, sets and HostRange.
Also add some other ranges from the reserved list, and link to that list
to make it a bit easier to find stuff in the future.
I don't konw if this actually matters, but better safe than sorry.
Everything here confuses me — my understanding of RFC 6052 was that
private IP addresses cannot be used with NAT64, but AWS apparently
allows it? Not sure if I or Amazon is wrong (or both!).
Jonathan Coates