--- Log opened Thu Sep 05 00:00:01 2019
00:00 < elichai2> they're pretty serious "presumably want to know also things like 2fa, review policy, etc" about dependencies
00:10 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Ping timeout: 245 seconds]
00:48 -!- justinmoon [~manjaro-i@2605:6000:1018:46a::d30] has quit [Ping timeout: 264 seconds]
00:49 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #rust-bitcoin
01:26 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection]
01:42 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #rust-bitcoin
02:58 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection]
03:24 < elichai2> wumpus: Hi, when you develop no-std on RISC-V and other embedded, do you use global-allocator?
03:31 -!- ccdle12 [~ccdle12@static-84-9-17-116.vodafonexdsl.co.uk] has joined #rust-bitcoin
03:43 < wumpus> elichai2: I've been able to do without allocators for now (just statically allocated memory and stack)
03:44 < wumpus> there is a riscv-alloc crate that could be used as a global allocator to have a heap but it's very immature
03:45 < elichai2> hmm i'm curious if no-std without an allocator is even a real use case, for anything that will want to use libsecp, you can allocate some stack and use that in the allocator trait
03:45 < elichai2> not saying heap, you could implement the allocator trait on stack
03:46 < wumpus> it's a real use case, many people do embedded dev in rust without a heap
03:46 < wumpus> (i'd dare say, most people that do embedded dev in rust, because allocator implementations are pretty immature and non-stdandardized)
03:47 < wumpus> it's interesting that you first ask me what I do then claim it's not a real use-case *shrug*
03:48 < elichai2> I never claimed anything :)
03:48 < wumpus> "allocate some stack and use that in the allocator trait" you mean that you can pass in an allocator?
03:49 < elichai2> I asked you because I know of only 2 no-std users of rust-secp, you and a company, and I know that that company uses global allocator, so I was curious about you, it's hard to guess use cases of stuff you(I) don't do
03:49 < elichai2> i'll try to write some example, see if it even makes sense
03:50 < wumpus> what I'd prefer is to define secp256k1's memory entirely statically
03:50 < wumpus> no allocators at all
03:50 < wumpus> I know it's possible because it's all fixed-sized structures given fixed parameters
03:50 < elichai2> yeah, that would've been best
03:51 < elichai2> removing the Context all together
03:51 < wumpus> I definitely don't want to define a global allocator, passing in a local allocator is OK with me as a hack, that's basically what happens now
03:52 < elichai2> nvm, while trying to implement a stack allocator I reallized this is not trivial at all, because if you want to reuse deallocated memory you need to start keeping tables of ptr and sizes or some other trick
03:52 < wumpus> kay
03:52 < elichai2> wumpus: yeah obviously, you're right. I tried thinking of ways we could utilize https://doc.rust-lang.org/std/alloc/struct.Layout.html in the future, because it gives good promises on alignment
03:52 < elichai2> but I guess not
03:55 < wumpus> yeah, that's okay for the std case; for the alignment in the embedded case, I think forcing the caller to provide properly aligned memory (documenting and checking this) is good enough for embedded purposes
03:56 < wumpus> any embedded software is already hacking around with memory on a low-level by definition; the only reason for my issue is that I was surprised at some behavior (e.g. it seems to expect 32-bit alignment but expects 64-bit because it needs to put pointers in the struct)
03:58 < elichai2> I'm more trying to think of future proofing this. i.e. if upstream decides to write u128 to the memory, it won't be properly aligned
03:58 < wumpus> I don't expect secp256k1 to do hand-holding in that regard :)
04:00 < wumpus> maybe make embedded clients using the low-level interface pass in a raw pointer that must be 16-byte aligned
04:01 < wumpus> I really don't mind, as long as it's documented what is expected of the caller
04:07 < elichai2> yeah, C attitude, ha? :P
04:07 < elichai2> sadly there is no primitve in rust that is 16 byte aligned
04:11 < wumpus> hehe, embedded systems attitude, I mean, DMA engines, framebuffers, also have the weirdest requirements with regard to alignment sometimes (usually more than 16, like 64, 256...) .. for statically aligned memory it can be achieved with a linker script, or #[repr(align(64))] on a struct that contains the arrays
04:13 < elichai2> wumpus: yeah my original thought was with repr like: https://play.rust-lang.org/?gist=5a1f3faf2db9972f76a6d29e3de55390
04:13 < elichai2> The problem is that I can't find a promise that bytes used for alignment can't be reused for something else
04:14 -!- ccdle12 [~ccdle12@static-84-9-17-116.vodafonexdsl.co.uk] has quit [Remote host closed the connection]
04:17 < wumpus> right, which is why I'd leave the problem to the caller
04:38 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #rust-bitcoin
07:02 < andytoshi> FWIW upstream can't magically break us; we have to pull in changes. and given that i am a maintainer both here and upstream, it is very unlikely that we'll pull in a u128 into the context object
07:03 < andytoshi> +1 that having a full static context would be valuable. this is something we've punted on because it'd result in multi-megabyte code generation and we weren't sure about the value
07:03 < andytoshi> and because it's a bit of a pita to write the code
07:16 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection]
07:16 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined #rust-bitcoin
08:01 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection]
08:02 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #rust-bitcoin
09:09 -!- justinmoon [~manjaro-i@2605:6000:1018:46a::d30] has joined #rust-bitcoin
09:28 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection]
09:37 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #rust-bitcoin
10:05 < wumpus> andytoshi: if it'd result in multi-megabyte code it'd be fairly pointless for embedded; I don't think it's necessarily true for smaller window sizes?
10:32 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection]
10:59 < BlueMatt> andytoshi: is it possible to do it in a build.rs lol
10:59 < BlueMatt> as a shitty workaround
11:25 < andytoshi> wumpus: correct, not an issue for smaller window sizes
11:25 < andytoshi> BlueMatt: hmmmmmm
11:25 < andytoshi> i'm going to say "no", because from the perspective of the rust bindings all these types are opaque
11:26 < andytoshi> we could serialize a byte array but there's no guarantee that the representation at build-time (which we store) will represent the representation at run-time (which we need)
11:37 < BlueMatt> right
11:38 < BlueMatt> I guess it def wouldnt work for cross-compilation
11:58 < wumpus> I kind of liked https://github.com/bitcoin-core/secp256k1/pull/614, which hardcodes the table for smaller WINDOW sizes
11:59 < wumpus> in some cases these precomputed constants are smaller than the code used to generate them; I think the kind of cases where you use a large WINDOW_G are also where a heap is available and it's fine to generate it at run time
12:22 -!- reallll [~belcher@unaffiliated/belcher] has joined #rust-bitcoin
12:25 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 264 seconds]
12:44 -!- reallll is now known as belcher
13:14 -!- justinmoon [~manjaro-i@2605:6000:1018:46a::d30] has quit [Ping timeout: 250 seconds]
13:16 -!- justinmoon [~manjaro-i@2605:6000:1018:46a::d30] has joined #rust-bitcoin
14:03 -!- justinmoon [~manjaro-i@2605:6000:1018:46a::d30] has quit [Ping timeout: 276 seconds]
14:03 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #rust-bitcoin
14:15 -!- justinmoon [~manjaro-i@2605:6000:1018:46a:a369:7ca8:8232:c68a] has joined #rust-bitcoin
14:28 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection]
15:05 -!- stanimal [~stanimal@195.159.29.126] has quit [Read error: Connection reset by peer]
15:05 -!- stanimal [~stanimal@195.159.29.126] has joined #rust-bitcoin
16:29 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #rust-bitcoin
16:33 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Ping timeout: 244 seconds]
16:33 < dpc> https://users.rust-lang.org/t/call-for-help-implementing-an-independent-rust-frontend-for-gcc/32163 "Call for help implementing an independent Rust frontend for GCC"
17:21 -!- justinmoon [~manjaro-i@2605:6000:1018:46a:a369:7ca8:8232:c68a] has quit [Read error: Connection reset by peer]
17:27 -!- justinmoon [~manjaro-i@2605:6000:1018:46a::13f] has joined #rust-bitcoin
17:31 -!- TamasBlummer1 [~Thunderbi@p200300DD6712641614826B47369865EB.dip0.t-ipconnect.de] has joined #rust-bitcoin
17:31 -!- justinmoon [~manjaro-i@2605:6000:1018:46a::13f] has quit [Read error: Connection reset by peer]
17:33 -!- TamasBlummer [~Thunderbi@p200300DD6712647058DD267A87CD9F8E.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
17:33 -!- TamasBlummer1 is now known as TamasBlummer
20:30 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #rust-bitcoin
20:34 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Ping timeout: 244 seconds]
20:58 -!- gwillen [~gwillen@unaffiliated/gwillen] has quit [Ping timeout: 244 seconds]
20:59 -!- gwillen [~gwillen@unaffiliated/gwillen] has joined #rust-bitcoin
--- Log closed Fri Sep 06 00:00:02 2019