--- Log opened Fri Jun 25 00:00:49 2021
01:22 -!- belcher_ is now known as belcher
03:30 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has joined #bitcoin-rust
03:36 -!- prusnak[m] [~stickmatr@2001:470:69fc:105::98c] has joined #bitcoin-rust
03:36 -!- RCasatta[m] [~rcasattam@2001:470:69fc:105::c85] has joined #bitcoin-rust
03:36 -!- thomaseizinger [~thomaseiz@2001:470:69fc:105::16b2] has joined #bitcoin-rust
05:16 -!- tibo_ [~tibo@p3002252-ipngn18401marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]
06:35 -!- h4sh3d [~h4sh3d@user/h4sh3d] has quit [Ping timeout: 265 seconds]
06:44 -!- h4sh3d [~h4sh3d@user/h4sh3d] has joined #bitcoin-rust
10:21 < BlueMatt> elichai2: any updates on your core2 review?
10:21 < BlueMatt> or andytoshi any thoughts on the issue?
10:51 < andytoshi> i was just about to start burning down github notifications today
10:51 < andytoshi> what issue/pr should i look at?
10:53 < elichai2> BlueMatt: reviewed, basically just fixing the serde+no-std combination
10:53 < elichai2> but looks good :)
10:54 < BlueMatt> andytoshi: no_std support - https://github.com/rust-bitcoin/rust-bitcoin/pull/603 but specifically what we really think of core2 - its the only option, really, but its also kinda a one-man project and not super actively maintained - we could fork it into rust-bitcoin (which, like, i mean then we lose the compatibility which is nice, but maybe we can switch back if core2 gets real adoption?) or we could just leave it since its no_std anyway, 
10:54 < BlueMatt> and not enabled for normal builds
10:56 < andytoshi> BlueMatt: my vote is to go with core2
10:56 < andytoshi> i think our nostd support is gonna be kinda janky for a while
10:56 < andytoshi> but so is the nostd support for the whole ecosystem
10:56 < andytoshi> and we probably want to be along for the ride
10:56 < andytoshi> because it's a ton of work and ideally we can minimize how much of it we personally have to do
10:56 < andytoshi> ...and also we did make some partial attempts to "go our own way" with Vec and Read and such and it really blew up in terms of complexity
11:00 < BlueMatt> yea, alright, I mean I'm fine with that, just wanted to make sure we get more eyes on it before we commit more fully.
11:00 < BlueMatt> andytoshi: note that core2+bare-io currently has ~no reverse deps
11:00 < andytoshi> weird...how is anybody else doing nostd?
11:01 < BlueMatt> they aren't doing std::io, I think
11:01 < andytoshi> just avoiding Vecs and shit entirely?
11:01 < andytoshi> heh brutal
11:01 < andytoshi> ok I am reading all the github discussion on #603 and will read all the code
11:01 < andytoshi> over the next 15  mins
11:03 < andytoshi> heh looks like elichai might also be in the middle of a review
11:03 < BlueMatt> just submitted, it seems?
11:04 < BlueMatt> I mean its all trivial, tho, not a lot to change, mostly wanted eyeballs on core2 and the whole thing in total
11:07 < BlueMatt> even better, we'd be the only users of core2 and the core2 guy hates bitcoin (for the usual vaguely-misinformed reasons of average tech folk)
11:11 < andytoshi> lol. well, maybe he'll learn to like us
11:11 < andytoshi> i think ... our only alternative to core2 is to do our own thing, which seems (to me) to be infeasible
11:11 < andytoshi> so if core2 starts to become a problem in the future, maybe we wind up pinning a specific version of it, which is shitty but roughly equivalent to "do our own thing" but way less work
11:11 < BlueMatt> yea, I mean we could always freeze core2 and use that. If any other material crates ever adopt core2 then we can switch ot it.
11:12 < BlueMatt> i dont think thats a ton of work, but i agree better not to if possible
11:12 < andytoshi> but more optimistically, something else will arrive that has wide adoption, or libstd itself will get its shit together
11:12 < andytoshi> and we can switch to that some day
11:12 < BlueMatt> yea, libstd....maybe in like 2 years? :)
11:12 < andytoshi> :)
11:15 < gene> think core2 get the `Error` impl backwards, they fork `thiserror` to use `core2::error::Error`
11:22 < gene> `anyhow::Error` allows a no_std build
11:23 < andytoshi> i'm not sure i understand, thiserror and anyhow have very different error types
11:25 < gene> yeah, looks like thiserror doesn't have no_std build
11:25 < gene> thought they did, since they use anyhow
11:26 < gene> using anyhow::Error seems like the more future-proof solution
11:26 < andytoshi> ah i didn't know that thiserror used anyhow
11:26 < gene> way more usage, and maintainers
11:27 < andytoshi> has thiserror always used anyhow? this is kinda surprising to me
11:27 < gene> might be worth looking into if forking core2, to use anyhow::Error for the error type
11:28 < andytoshi> heh that sounds like it wouldn't be worth the maintenance burden
11:28 < andytoshi> though i agree not having an Error type blows
11:28 < gene> also impl BufReader and BufWriter using alloc types, instead of const generics (remove nightly dep)
11:29 < BlueMatt> I dont think core2 has a nightly dep?
11:29 < gene> it does for BufReader and BufWriter types
11:30 < gene> because they use const generics
11:30 < gene> think they are feature-gated
11:30 < andytoshi> that doesn't seem right, the lib builds on stable
11:30 < andytoshi> i think they may have been stabilized recently
11:30 < andytoshi> current rustc is 1.53, the PR OP says you need 1.51 .. so that's prety recent
11:31 < gene> "`BufReader` and `BufWriter` have a different signature, as they now use a const generic bounded array for the internal buffer. (Requires nightly feature)"
11:32 < gene> https://github.com/bbqsrc/core2#differences-to-stdio
11:32 < andytoshi> it looks like we use BufReader and it looks like the PR compiles with stable....but lemme see if it's not feature-gated somehow or something
11:33 < gene> might be a previous version that used alloc?
11:33 < andytoshi> ah no, it's just in network::stream_reader
11:33 < andytoshi> but all the network modules are gated on std
11:35 < gene> for sure
11:36 < gene> I'm personally for forking core2
11:36 < gene> especially if bbqsrc is hostile to bitcoin
11:37 < gene> I'd volunteer to help maintain the fork
11:52 < andytoshi> i'm not -against- it necessarily but i have very little insight into how much work it'd be (i think "a lot") and how much volunteer power we have for it
11:52 < andytoshi> though i appreciate your offer
11:52 < gene> :)
11:52 < gene> there's also some efforts ongoing in the rust-lang community
11:53 < gene> maybe we could join those efforts
11:56 < andytoshi> i would like to, but they have been pretty hostile to us by moving discussion to walled gardens
11:57 < gene> https://github.com/rust-lang/rust/issues/48331#issuecomment-802467559
11:57 < gene> walled gardens?
12:00 < gene> possible path for other std::io traits in no_std: https://github.com/rust-lang/rust/issues/48331#issuecomment-576942330
12:10 < gene> tracking issue in `rust-lang/project-error-handling`: https://github.com/rust-lang/project-error-handling/issues/11
12:31 < BlueMatt> gene: std is still a long, long, long, long ways off, afaict
12:31 < BlueMatt> gene: we can't wait around for it, that's the reason for core2.
12:32 < BlueMatt> gene: are you aware of any effort outside of "lets eventually get it in rust-lang in like a few years"? The only thing I found when searching was basically core2.
12:33 < BlueMatt> gene: we have users who want to run rust-bitcoin+rust-lightning and stuff in hardware, like, two months ago. we cant wait years for libcore
12:34 < BlueMatt> andytoshi: I dont understand this comment - https://github.com/rust-bitcoin/rust-bitcoin/pull/603#discussion_r658958838
12:34 < BlueMatt> you think we should change the function name in a minor version bump?
12:39 < andytoshi> no, i think we should do a major version bump
12:39 < andytoshi> we can't do any of this in a minor version bump
12:42 < BlueMatt> ah, ok, that I didnt understand - I'd thought the only version breaking thing in that pr was the default-features set
12:42 < BlueMatt> ie --no-default-features
12:50 < andytoshi> i believe that's the case ... which i suppose we could eat
12:50 < andytoshi> but my thinking is that --no-default-features is serious enough to warrant a major version bump
13:36 -!- Guest64 [~textual@c-73-189-219-70.hsd1.ca.comcast.net] has joined #bitcoin-rust
13:36 -!- arik [sid402902@id-402902.tooting.irccloud.com] has joined #bitcoin-rust
14:09 -!- Guest64 [~textual@c-73-189-219-70.hsd1.ca.comcast.net] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
14:33 -!- Guest64 [~textual@c-73-189-219-70.hsd1.ca.comcast.net] has joined #bitcoin-rust
14:39 -!- Guest64 [~textual@c-73-189-219-70.hsd1.ca.comcast.net] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
16:00 -!- belcher_ [~belcher@user/belcher] has joined #bitcoin-rust
16:02 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 256 seconds]
17:10 < gene> BlueMatt: I know about users that want to run rust-bitcoin+rust-lightning in hardware (I'm one of them)
17:11 < BlueMatt> ah! lol.
17:11 < gene> not aware of any other efforts besides the tracking issues I linked above
17:11 < BlueMatt> lol I didnt link your nick on here to your github
17:11 < BlueMatt> not sure *why* I didnt, but my brain did not.
17:11 < gene> :)
17:12 < BlueMatt> anyway, I mean i think its a decision on forking core2 or not at this point? I'm not aware of a better way?
17:13 < gene> yeah, I wasn't really arguing against that
17:13 < gene> more that we should fork core2, and replace its error type with anyhow::Error
17:13 < BlueMatt> I do kinda worry that if we make substantial modifications to it we're gonna be in pretty deep
17:14 < gene> because anyhow::Error has no_std support, and is likely to be closer to what gets impl upstream
17:14 < gene> deep as in a lot of maintenance + feature impl?
17:15 < BlueMatt> yea
17:15 < BlueMatt> msotly maintinence
17:15 < BlueMatt> and, what if "the ecosystem" *does* adopt core2, at least for now?
17:16 < BlueMatt> then we have to switch back to a new error type (including pain for downstream users), or stick with being incompatible :/
17:16 < gene> I'm fine with just using core2 as well, if they're open to collaborating
17:16 < BlueMatt> it looks like its one of many side projcts for the core2 guy :/
17:16 < BlueMatt> he responds, but only slowly
17:17 < gene> one of the first PRs I would make if not forking is to use anyhow::Error as the core2::error::Error type
17:18 < gene> need to look more closely at the impl
17:25 < gene> core2 has an alloc trait. If not forking, I would make a PR to have an alloc-based impl of the core2::buffered types
17:26 < BlueMatt> well, maybe if you are super jazzed to go do these things, do an easy first one, open a pr, see how responsive the maintainer is
17:26 < BlueMatt> if he's not responsive at all, then no difference where the crate lives.
17:28 < gene> +1
19:05 < gene> looks like the direct replacement of `core2::error::Error` (trait) > `anyhow::Error` (struct) isn't going to be easy
19:05 < gene> going to leave that alone for now
19:05 < gene> I'll look at doing a alloc-based impl for the buffered classes, see how much work that will be
19:06 < gene> there is an `initializer` API that uses unsafe, unclear why it needs it (API inside traits with no impls)
19:06 < gene> more than half the tests in the test suite are also commented out
19:07 < gene> so not really confidence inspiring
19:07 < gene> the rest of the code seems well-documented, except for some hangovers from the bare-io > core2 rename
19:08 < gene> plus some of the doctests use the std equivalents of the core2 impls they're documenting
19:08 < gene> not sure why, maybe those are the lowest-hanging fruit for the first PR though
19:20 -!- reallll [~belcher@user/belcher] has joined #bitcoin-rust
19:22 -!- belcher_ [~belcher@user/belcher] has quit [Ping timeout: 272 seconds]
23:20 -!- belcher_ [~belcher@user/belcher] has joined #bitcoin-rust
23:23 -!- reallll [~belcher@user/belcher] has quit [Ping timeout: 258 seconds]
--- Log closed Sat Jun 26 00:00:49 2021