* Push
* prettierrc
* Use cjs cuz current api require's it
* Prettier override for md
* fix 2b-c-sharp
Hopefully fixed the break introduced by pnpm
Fix to nav.js generation
Now just using tsc to build the file
type = commonjs
Co-authored-by: Puru Vijay <47742487+PuruVJ@users.noreply.github.com>
2. Make `RowRef::row_hash` use the above.
3. Make `Table::insert` return a `RowRef`.
4. Use less unsafe because of 1-3.
5. Use `second-stack` to reuse temporary allocations in hashing and serialization.
* NFC: few more C# shorthand conversions
For some reason these automated refactoring conversions didn't get included in #1149.
* Also remove unused usings
* Restore a using that was erroneously marked as unused
Fixes#1173.
Previously we were only recording this metric for scheduled reducers.
We were also recording it before we acquired access to the module instance.
Now we record it for all reducers after we acquire access to the module instance.
This patch also removes max wait time since the histogram should suffice.
Fixes#1170.
Also updates the bucket values for the queue length histogram.
Also removes the max queue length metric, since the histogram should suffice.
* Simplify source generator csproj
Apparently custom scripts are no longer necessary, so removing to make maintenance simpler (noticed this while working on yet another source generator).
* Add smoketest based on Ingvar's comment, + run smoketests on Windows
* Whoops, don't mkdtemp outside of debugging
* Make smoketest sillier
* Finish up a print statement
* Revert "Make smoketest sillier"
This reverts commit 135b05b380.
* Resolve versioning issue in a non-silly, professional way.
---------
Co-authored-by: James Gilles <jameshgilles@gmail.com>
CLI `generate` code is a particularly heavy user of format-based macros, and so it benefits most from inlining format args where possible.
This is done by adding `#![warn(clippy::uninlined_format_args)]` + running `cargo clippy --fix` followed by `cargo fmt`, so shouldn't require manual review.
This is a follow-up to #1142 and, like that PR, is mainly done to make generate's code a bit cleaner and diffs simpler.
* doc: Onboarding impr, fixes, consistency, cleanup
refactor: Whats next cleanup, +unity, -bloat
Removed redundant text while there
refactor: Unity quickstart fixes, impr, prettify
refactor: Unity pt1 fixes, impr, prettify
fix(README): Rm "see test edits below" ref
* !exists
refactor(minor): General onboarding cleanup
* Shorter, prettier, consistent
fix(sdks/c#): Broken unitypackage url
feat(sdks/c#): Add OneTimeQuery api ref
* doc: Onboarding impr, fixes, consistency, cleanup
* fix: Rm redundant 'module_bindings' mention
* fix: Floating period, "arbitrary", "important":
- PR review change requests
- Additionally: hasUpdatedRecently fix and reformatting
* fix: Mentioned FilterBy, used FindBy
- Used FindBy since that was what the tutorial used, and also looking for a single Identity.
- Note: There may be a similar rust discrepancy in the Unity pt1 tutorial. It'll work with Filter, but just simply less consistent. Holding off on that since my Rust syntax knowledge !exists.
* fix(Unity-pt1): Rm copy+paste redundant comments
* Duplicate comments found both above and within funcs
* fix(unity): Rm unused using statement +merged info
* Removed `System.Runtime.CompilerServices`
* SpacetimeDB.Module seems to already include this (merged the info)
* refactor(minor): Code spacing for grouping/clarity
* feat: 'Standalone mode runs in foreground' memo
* At general quickstart for `spacetime start`
* refactor(unity-pt1): Standalone mode foreground memo
* Also, removed the "speed" loss mention of C#
* fix(syntaxErr): Fix err, keep FilterBy, handle null
- After a verbose discussion, we will eventually swap to FindBy for single-result queries, but not in this PR.
- For now, the syntax err is fixed by making the var nullable and suffixing a LINQ FirstOrDefault(). Approved by Tyler in Discord.
- We never *actually* created a player in the tutorial. This creates the player. Approved by Tyler in Discord.
* doc!(unity-tutorial): Add C# module parity + split
- Why?
- Despite being a Unity tutorial (we 100% know the user knows C#), the server example used Rust.
- This creates friction when the user is already learning multiple new things: The SpacetimeDB architecture, the CLI, the client SDK and server SDK. If they previously did not know Rust, this could add some weight to the onboarding friction.
- The Unity tutorial could use an overview since it's quite lengthy and progressive.
- Part1 should be split, anyway - it covers way too much for a single section to handle (especially since it jumps between client and server). Splitting between basic multiplayer + advanced makes things more-manageable and less intimidating.
- Before:
- UNITY TUTORIAL
- Part1 (Client + Rust Server)
- Part2 (Resources and Scheduling)
- Part3 (BitCraft Mini)
- After:
- UNITY TUTORIAL - BASIC MULTIPLAYER
- Overview
- Part1 (Setup)
- Part2a (Rust Server)
- Part2b (C# Server)
- Part3 (Client)
- UNITY TUTORIAL - ADVANCED
- Part4 (Resources and Scheduling)
- Part5 (BitCraft Mini)
* Update docs/unity/part-2b-c-sharp.md
Rust -> C#
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
* Update docs/unity/part-2b-c-sharp.md
- `--lang=rust` to `=csharp`
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
* Update docs/unity/part-2b-c-sharp.md
- Rm RustRover mention
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
* Update docs/unity/part-2b-c-sharp.md
- Rust -> C#
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
* fix: "Next tutorial" mixups
* fix: Bad troubleshooting links
- Server issues shouldn't link to Client troubleshooting that has no answer
* Update docs/unity/part-2b-c-sharp.md
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
* Update docs/unity/part-2a-rust.md
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
---------
Co-authored-by: Zeke Foppa <196249+bfops@users.noreply.github.com>
While looking through the large diffs while splitting out small PRs out of my refactor branch, I noticed that quite a lot of noise is from me working on a formatted code and using primary constructors while the one in master is not.
As such, I'm splitting out just those automated / non-functional changes into a separate PR to make subsequent functional diffs easier to read.
This allows to:
1. Have a preset logger that is already correctly matching the environment (console vs Unity).
2. Removes the need for explicit `SpacetimeDBClient.CreateInstance(...)` which is particularly awkward to use and easy to forget with singleton as it doesn't return a result as a factory method name could suggest. Instead, `SpacetimeDBClient.instance` is available on first use.
3. Slightly simplifies dependencies between classes, e.g. `ClientCache` doesn't need a circular dependency on `SpacetimeDBClient`, making future maintenance and changes a bit easier.
This is the last C# version supported by Unity.
While this PR doesn't require almost any C# code changes, I found that limiting the version is helpful for ensuring that I don't accidentally introduce Unity-incompatible code in larger PRs.
While working on the new C# codegen, I accidentally noticed that those tests were passing even when they clearly should've been failing due to changed output.
After running with `--nocapture`, I found out it's because the tests are silently skipped and reported as successful when `rust_wasm_test.wasm` isn't built.
This further led to finding that `rust_wasm_test.wasm` is never built - the relevant module results in `rust_wasm_test_module.wasm` instead - so these tests have been incorrectly passing for ages.
This PR changes them to actually build the module as part of testing and updates the snapshots to latest master.
This adds a non-fallible `write_fmt` method to `CodeIndenter<String>` (since we know it should never fail), which allows to use `write!` and `writeln!` without `.unwrap()` everywhere, making code a lot less noisy.
Mazdak Farrokhzad