-
Notifications
You must be signed in to change notification settings - Fork 25
Refactor to refmt #30
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
Conversation
node.go
Outdated
cid *cid.Cid | ||
err = cbor.UnmarshalAtlased(b, &m, cborAtlas) | ||
if err != nil { | ||
fmt.Printf("bytes: %s\n", hex.EncodeToString(b)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
btw, you can use %x
instead of %s
to automatically encode to hex.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sweet, thank you <3
More tests are passing with the latest fixes + latest refmt. Some more tests to fix before we are ready. |
I actually think that something is broken on master. In TestMarshalRoundtrip, the object that gets created (on master) looks like this:
The string 'hello' is missing. This test started failing once we switched to refmt, and the created object looks like:
So while I was trying to avoid changing any tests, I think we actually should here. |
Ignore my previous comment, it looks like @dignifiedquire added that hello key in earlier commits but didnt update the expected hash. |
All thats left here is to add in the right sorting for maps to refmt for canonical cbor. I can manually make that change (and have locally), but would rather do it in a way thats flexible and have it officially be a part of refmt. |
yeah that was probably some debugging tries that I forgot to clean up
…On 13. Dec 2017, 23:38 +0100, Whyrusleeping ***@***.***>, wrote:
All thats left here is to add in the right sorting for maps to refmt for canonical cbor. I can manually make that change (and have locally), but would rather do it in a way thats flexible and have it officially be a part of refmt.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@whyrusleeping I think this is ready as soon as polydawn/refmt#19 is merged and we have a gx version of refmt. |
Alright, we're ready to go here I think |
@whyrusleeping is there a reason this is not merged yet? |
@dignifiedquire mostly because we need to do the update into go-ipfs intentionally, and not have it get included arbitrarily with a bunch of other updates. This sort of thing is a higher risk change, and is something we want to test carefully and individually. |
This is blocked until it stops deserializing CIDs as |
@Stebalien cant we just change the castBytesToCid method to return a *cid.Cid? |
@whyrusleeping no, this is a limitation of refmt as it stands (I've discussed it with @warpfork and I just filed an issue (polydawn/refmt#32) so we can track it). We could fix all the CIDs up using My other open concern is that I'm not sure we really want to expose the |
We also need: polydawn/refmt@2e9ba99 |
I have attempted to unblock :) |
Also, use a cloner instead of unmarshalling when wrapping an object.
Increasing `numWorkers` doesn't seem to help at all (not supprising). Really, we could probably drop to NumCPUs (instad of 2x that) and we'd still be fine.
More than that doesn't help. +1 helps for the case where a goroutine holding a worker gets unscheduled.
IIRC, pools are cleaned every GC cycle. However, by benchmarks aren't actually *faster* with this change so I figured we might as well go for it. Our issue here is really throughput, not latency, so even *if* these pools are cleaned on GC, it's still useful.
We don't need to mutate, just replace.
Make sure we *actually* serialize/deserialize. Addresses @warpfork's CR.
I've just rebased this on master in the refmt-rebased branch. Basically, we now just use I've done a sanity check with the new uber-cool @dignifiedquire please reset this branch to |
What's the landing strategy going to be for this? IIUC, there's already releases of go-ipld-cbor cut from this branch being used in some other projects... I guess gx snapshots also do preserve those, but ditching the original git commit hashes matching those releases would also seem pretty lossy. Idea: do a giant Maybe that's unnecessary footwork, just floating the idea. |
It's probably fine to drop the release commits, IMO. That shouldn't actually break anything due to how gx works. |
@Stebalien maybe best you do what you want with the branch, I have a fork for the current version I need, so nothing should break.
…On 17. Sep 2018, 20:13 +0200, Steven Allen ***@***.***>, wrote:
It's probably fine to drop the release commits, IMO. That shouldn't actually break anything due to how gx works.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Ref #29