--- Log opened Mon Dec 18 00:00:03 2023
04:21 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
05:28 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
05:35 -!- jon_atack [~jonatack@user/jonatack] has joined #secp256k1
05:37 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 264 seconds]
07:00 < real_or_random> meeting :)
07:00 < nickler> hi
07:01 < hebasto> hi
07:01 < sipa> hi
07:01 < real_or_random> hi
07:02 < real_or_random> topics?
07:02 < nickler> release?
07:02 < real_or_random> yep
07:02 < sipa> #1095 is still marked 0.4.1
07:03 < real_or_random> (just as a quick note, let me say that I still want to summarize the discussion of two weeks ago and reply in the fiat PR... hopefully this week :) )
07:04 < real_or_random> sipa: there's #1380 which will fix it
07:04 < real_or_random> I haven't addressed the review comments yet, but should be a quick thing if we want to have it in for the release
07:04 < sipa> real_or_random: 1095 is the standard header inclusion
07:04 < real_or_random> I meant 1461 sorry
07:04 < real_or_random> top of the PR list
07:06 < nickler> yeah imo 1461 looks pretty good
07:07 < sipa> looking
07:12 < real_or_random> I mean, we also shouldn't rush it. if it gets in the next release, that's not a big deal. let's just see if it's ready by thursday 
07:13 < real_or_random> "Do the warning messages add anything, as there are already deprecated markers on the unavailable functions?" I had just responded to myself a minute earlier
07:14 < real_or_random> let's just remove the messages in doubt. people building on exotic platforms will anyway need the skills and patience to figure out some build details 
07:15 < sipa> right
07:18 < nickler> which warning messages?
07:19 < real_or_random> # pragma message "<stdio.h> not available, disabling debugging output for fatal library errors."
07:19 < real_or_random> # pragma message "<stdlib.h> not available, disabling dynamic memory allocation."
07:19 < real_or_random> not the "deprecated" message (or in fact, error). I think these are useful
07:20 < nickler> I thought they are helpful
07:21 < sipa> the first of the two does change functionality that isn't related to an unavailable function
07:21 < sipa> but i'm unconvinced about producing warnings about lack of functionality that may be entirely intentional
07:22 < real_or_random> that's also my thinking
07:23 < nickler> it may not be intentional though, could be a mistake. But ok that's not a very strong argument.
07:23 < real_or_random> I mean... another approach is to say explicit is better than implicit and simply require a flag for this
07:23 < sipa> right
07:24 < sipa> but do we expect that in the majority of cases the autodetection will be correct?
07:24 < sipa> (as in: match the user's intent)
07:24 < real_or_random> just error out instead of trying to guess the right thing, and tell the user to build with -DSEPC256K1_NO_STDIO or whatever
07:25 < real_or_random> sipa: it's hard to say. apparently, it works out for rust-secp256k1 wasm stuff.
07:25 < nickler> real_or_random: sgtm
07:25 < sipa> i think another argument in favor of the current approach is that on these limited systems with unavailable stdio/malloc, you're also unlikely to even care about the functionality they provide
07:26 < sipa> e.g. on a hardware wallet or in wasm, a fatal error message just doesn't make sense
07:26 < real_or_random> the reason why I haven't done this initially is that we have two macros per header header. one for autodetection and one for what the user actually wants. seemed a bit overly complex to me, and could also confuse overs who want to set the correct flags  
07:27 < real_or_random> sipa: yeah. I mean for malloc, you'll anyway notice when the linking fails later. for stdio, the only loss of "functionality" is that you don't get an error message. I guess that's acceptable 
07:28 < real_or_random> note that we still call abort(). if that isn't available either, we'll anyway error out and ask the user to resolve
07:28 < sipa> real_or_random: the fatal error message is only for development... people generally don't do development in environments without printf, i'd wager
07:29 < real_or_random> indeed. I think embedded systems typically try to provide printf , it it's only via uart and when debugging is enabled
07:29 < sipa> whatever we choose, i think it'd be good if configure/cmake expose a config option to select with/without stdio/malloc
07:29 < real_or_random> same for wasm. they'll print to the browser console for example, as far as I understand
07:30 < sipa> so in wasm it's just malloc that's missing?
07:31 < real_or_random> sipa: if we add an option to configure/cmake, do you think it should be the enable/disable option, or just the override for the auto detection? in the former case, we'll have two macros then per header. but yeah, I guess it's okay
07:31 < sipa> --with-stdio=[yes|no|auto] (default: auto) ?
07:32 < real_or_random> in wasm: I think they also don't have (good) abort. it just doesn't abort. ^^  (and they don't provide a string.h header for memcpy and memset, but that's their bug. they should do it) 
07:33 < real_or_random> okay yes, that will mean, we'll still do the auto detection (one internal macro), but the user can override anything that the auto detection implies (one external macro).
07:34 < sipa> i think that's my preference
07:34 < real_or_random> that's what I had in mind first. I'll give it a try.
07:34 < nickler> cool
07:34 < real_or_random> when I started working on it, it seemed a bit overkill, but I had not actually implemented it
07:35 < real_or_random> (anyway, it's certainly one of many ways that solve the problem ^^)
07:37 < real_or_random> I guess 1380 is also in a good state,
07:38 < real_or_random> and that one is less critical as it's not user-facing. I think we should do a final review and get it merged, and then just see how it works out during the release process
07:39 < sipa> right
07:41 < real_or_random> any other topics?
07:41 < nickler> By the way, I wrote a little script that builds a secp256k1 branch and then builds & tests all packages in nixpkgs and nixbitcoin that depend on it. For example, this allowed testing that removing the scratch space from the API would not break any of those packages.
07:41 < nickler> https://gist.github.com/jonasnick/6ec0a45103eb297a80b361748f1d8593
07:42 < real_or_random> nice. I'm curious what depends on it. 
07:44 < nickler> the packages are listed in the script
07:44 < real_or_random> oh sure
07:45 < real_or_random> what's glow-lang?
07:46 < sipa> https://github.com/Glow-Lang/glow ?
07:46 < real_or_random> i see
07:48 < real_or_random> anything else? more topics? end of meeting?
07:51 < sipa> end of meeting i think
07:51 < real_or_random> apparently :)
09:40 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
10:01 -!- preimage [~halosghos@user/halosghost] has joined #secp256k1
10:16 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
10:54 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
10:59 -!- preimage [~halosghos@user/halosghost] has quit [Quit: WeeChat 4.1.1]
13:20 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
14:13 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
14:16 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
15:04 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Read error: Connection reset by peer]
16:42 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 276 seconds]
--- Log closed Tue Dec 19 00:00:04 2023