I replaced the eprintln!s with println!, but it didn’t make any difference. Maybe we should remove those statements completely.

I can’t really find the place that kills the kernel. The last command to run is xvc file list:

print(xvc_test_data.file().list("test-data/dir-0002"))

and the output it produces is:

[src/output.rs:144:13] &output_str = "SS         131 2024-06-05 08:57:11 41e16be7          test-data/dir-0002/file-0003.bin\nSS         131 2024-06-05 08:57:11 27f0
efd0          test-data/dir-0002/file-0002.bin\nSS         131 2024-06-05 08:57:11 66de5084          test-data/dir-0002/file-0001.bin\nTotal #: 3 Workspace Size:
      393 Cached Size:        6006\n"

print may be causing the crash, but the more likely cause is the command that comes after this:

!ls -l test-data/dir-0001/

I replaced this with lsd, which also failed. Maybe it’s actually a Python crash or bug.

The way to understand is to create a notebook file with only that cell and try to run it.

The ls line runs fine with a new notebook. It even runs on the README file when run at the beginning. The line that makes the kernel crash is:

xvc_test_data.storage().new_s3(name="backup", bucket_name="xvc-test", region="eu-central-1", storage_prefix="xvc-storage")

We can start by removing the new_s3 part.

The storage() method runs fine. It returns an XvcStorage() object, as it should.

When I run storage().list(), it takes a very long time. The bug is likely related to storage().

It looks like the storage object was adding file instead of storage as a subcommand. I’ve fixed it now.

That was the bug. The README notebook now creates the S3 storage.

What was the reason behind this?

Parsing the CLI to the XvcCLI object was perhaps the culprit. Let’s look at it more clearly.

Let’s try xvc file new s3 as a command to see how it behaves.

It says unrecognized subcommand for new.

This is how it should be, but I wonder why it doesn’t work for the XvcCLI parser.

Anyway, it’s already 13:00, so let’s stop here for today.

🐇 LGTM. I think you can also link to commits here when they occur.

🐢 I think that’s a bit too much work, but PRs may be linked.

🐇 Ok. Let’s start with the PRs. What are you working on these days?

🐢 I started fixing warnings in issue #3 and am now fixing missing documentation warnings.

🐇 Do you really think that we’ll have a use for [RMNStore] in the future?

🐢 I’m not sure. Possibly any M-N relationship can be tracked by two 1-N relationships. Under the hood, this is what RMNStore does actually.

🐇 Maybe we should just remove it.

🐢 I want to save it for the time being. If [xvc-ecs] is used in other places, it may be needed.

🐇 Ok. Probably YAGNI, but let’s keep it for the time being.

🐢 Writing documentation can be a debugging method, too. I think I’ve found the reason for a bug here.

🐇 Um, how could it lead to a bug?

🐢 Insert means a new event happened. But when converting a VStore to an XvcStore, new events are not happening. We are simply converting from one store to another.

🐇 That means they are added to XvcStore::current events, not XvcStore::previous, and when save_dir is called, they are saved.

🐢 Yeah, that was the bug. From time to time, I was seeing duplicate JSON files.

🐇 Then maybe it’s better to limit all insert usage.

🐢 Yeah, I should review that, too.

🐇 Added a bug report.

🐢 I’m installing cargo-geiger to show that there is no unsafe code.

🐇 Do you think you’ll maintain Xvc that way? That it won’t require any unsafe code?

🐢 Maintain the forbidden(unsafe) status? I think so. Xvc doesn’t seem to need any unsafe blocks by itself. Most of the dependencies may need it, though.

🐇 Working on it, and it will be merged today.

🐢 I worked on that s3cmd bug yesterday, and it turned out that my modification of the configuration was the cause.

🐇 You were thinking that it’s about R2 all along?

🐢 I should suspect my custom config more.

🐇 Anyway, congratulations 🌠 that Xvc now has Cloudflare R2 support.