I have no real interest in patching uniffi-bindgen-go as that sound gnarly af. iroh isn't changing the v1 API, so that is out. I think the Correct Solution ™️ would be to just search/replace the generated output because it's such a small change at the end of the day.
re: https://github.com/n0-computer/iroh-ffi/issues/248#issuecomment-4777541073
I have no real interest in patching `uniffi-bindgen-go` as that sound gnarly af. `iroh` isn't changing the v1 API, so that is out. I think the Correct Solution ™️ would be to just search/replace the generated output because it's such a small change at the end of the day.
Otherwise, the bindings appear to be working well: https://git.coopcloud.tech/decentral1se/iroh-go/src/branch/main/examples
I read the issue as stemming from []byte not being a valid map key, but we can use strings which are trivially convertible from []byte. What's the concrete thing that needs to be searched for? map[[]byte] -> map[string]? Go go sed!
I read the issue as stemming from []byte not being a valid `map` key, but we can use strings which are trivially convertible from []byte. What's the concrete thing that needs to be searched for? `map[[]byte]` -> `map[string]`? Go go `sed`!
Yeh, that's it! However, trying to sed this on the iroh-go side turns into a major sidequest as the generated code as all sorts of references to Bytes in the naming of internal functions. For now, I'm just cheekily building from a fork which mangles HashMap<Vec<u8>,...> into HashMap<String,...> and then building stuff 🙃 I can document this as a known issue and hopefully it doesn't explode later 🙏
Yeh, that's it! However, trying to sed this on the `iroh-go` side turns into a major sidequest as the generated code as all sorts of references to `Bytes` in the naming of internal functions. For now, I'm just cheekily building from a fork which mangles `HashMap<Vec<u8>,...>` into `HashMap<String,...>` and then building stuff 🙃 I can document this as a known issue and hopefully it doesn't explode later 🙏
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
re: https://github.com/n0-computer/iroh-ffi/issues/248#issuecomment-4777541073
I have no real interest in patching
uniffi-bindgen-goas that sound gnarly af.irohisn't changing the v1 API, so that is out. I think the Correct Solution ™️ would be to just search/replace the generated output because it's such a small change at the end of the day.Otherwise, the bindings appear to be working well: https://git.coopcloud.tech/decentral1se/iroh-go/src/branch/main/examples
I read the issue as stemming from []byte not being a valid
mapkey, but we can use strings which are trivially convertible from []byte. What's the concrete thing that needs to be searched for?map[[]byte]->map[string]? Go gosed!Yeh, that's it! However, trying to sed this on the
iroh-goside turns into a major sidequest as the generated code as all sorts of references toBytesin the naming of internal functions. For now, I'm just cheekily building from a fork which manglesHashMap<Vec<u8>,...>intoHashMap<String,...>and then building stuff 🙃 I can document this as a known issue and hopefully it doesn't explode later 🙏