automerge / automerge-swift

Swift language bindings presenting Automerge
https://automerge.org/automerge-swift/documentation/automerge/
MIT License
216 stars 11 forks source link

exposing Automerge::Diff through to Swift #183

Closed miguelangel-dev closed 4 weeks ago

miguelangel-dev commented 4 weeks ago

Bindings for being able to compare two points of the document history.

Related documentation: https://docs.rs/automerge/latest/automerge/struct.Automerge.html#method.diff

miguelangel-dev commented 4 weeks ago

... if they're effectively identical APIs with just slightly different parameters. Drop one, and I've made suggestions to change the parameter since to since since the other side that's passed to the core library's difference is the current set of heads.

Probably the API doc is not the best one and this note has confused you:

`from` and `to` do not have to be chronological. Document state can move backward.

Saying both do not need to be chronological (having order) does not mean the result won't change. Here is an example: let's say I append "World" to the existing "Hello"

Any suggestion for the DocC, to make it more clear is more than welcome 😅

I'm a unclear on why the WASM build didn't appear to pick up the change...

Not sure, but it looks like CI is always compiling against the latest XCFramework, instead of building a local one and using it.

Screenshot 2024-06-06 at 19 26 48
heckj commented 4 weeks ago

I saw the same thing in the logs re: downloading the XCFramework. It shouldn't be a requirement for builds on Linux or WASI, but I'd agree that this might be the bit that's hurting us. Unfortunately, XCFramework - while downloaded - can't be rebuilt on just Linux, so we don't have the same path to using a "local version".

If you've tried this on your own build servers and it works - flows through WASM builds correctly, etc - then I'm happy to merge this with that check breaking, on the idea that we can pop a release with the Rust updates which theoretically should resolve the issue for future builds after there's an updated point release.

miguelangel-dev commented 4 weeks ago

If you've tried this on your own build servers and it works - flows through WASM builds correctly, etc - then I'm happy to merge this with that check breaking, on the idea that we can pop a release with the Rust updates which theoretically should resolve the issue for future builds after there's an updated point release.

Adding manually missing autogenerate code (headers + automerge.swift), WASM is working 🎉. We should update the Linux bot to generate it automatically without committing it - please, double-check 868e8cd because it contains more changes than I expected. Probably, because of my rust version (nightly-2024-05-23-aarch64-apple-darwin)

side-note: I can revert this latest commit with the autogenerated code.

miguelangel-dev commented 4 weeks ago

I got the CI stuff updated - good call - with #185, and merged that in. You can rebase if you want to double check that this PR works without the checked in updates, but don't feel obliged.

Awesome! I have reverted the commits with the auto-generated code, to keep the PR clean and have rebased changes into this branch. Result: it works like a charm!

Thanks for the parallel work done into #185 - it is now ready to be merged