Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CanDB 1.0.7 HashTree bug #27

Open
viktorkovarik opened this issue Feb 18, 2024 · 3 comments
Open

CanDB 1.0.7 HashTree bug #27

viktorkovarik opened this issue Feb 18, 2024 · 3 comments

Comments

@viktorkovarik
Copy link

Hey I see this error when I try to build canDB with the latest version 1.0.7.

.mops/[email protected]/src/HashTree.mo:156.9-156.41: type error [M0045], wrong number of type arguments: expected 0 but got 2
.mops/[email protected]/src/HashTree.mo:160.16-160.48: type error [M0045], wrong number of type arguments: expected 0 but got 2

Can you check it out?

@ByronBecker
Copy link
Contributor

ByronBecker commented Feb 28, 2024

Hey @viktorkovarik sorry for the delayed response - that's peculiar you're running into an issue in HashTree, as that module shouldn't really be touched/used anywhere, as it's a deprecated artifact of an older version of CanDB. What version of dfx are you using?

CanDB 1.0.7 requires moc 0.9.8 or higher because of some of the APIs used by the map9 dependency it has. I'd recommend using dfx >= 0.16.1 if you aren't already using it.

If you want to use an earlier version of dfx, I'd recommend using CanDB 1.0.1.

@viktorkovarik
Copy link
Author

@ByronBecker I probably know why it does not work. It seems that it fails only in SingleCanisterCanDB since you've updated code only in non-deprecated one. I believe when I finally which to orchestrated CanDB it won't give this error.

and error started happening after stable-hash-map dependency was bumped/changed to different commit hash
before:
https://github.com/canscale/StableHashMap#v0.2.1@00243abd9541cbfb69c39647ec2475df6ab893f6
currently:
https://github.com/canscale/StableHashMap#v0.2.1@eb7edf4127233f2b1f3732ede7e2c55827ac6886

@ByronBecker
Copy link
Contributor

I believe when I finally which to orchestrated CanDB it won't give this error

Thanks for digging into this, and yes, I recommend using CanDB, not SingleCanisterCanDB. SingleCanisterCanDB was originally a Proof of Concept for the eventual CanDB library.

I'm assuming you were able to get things working then?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants