--- Log opened Mon Apr 11 00:00:51 2022
00:36 -!- rusty [~rusty@203.217.95.210] has joined #c-lightning
00:42 -!- rusty [~rusty@203.217.95.210] has quit [Ping timeout: 248 seconds]
00:53 -!- opsec_x122 [~opsec_x12@44-25-143-42.ip.hamwan.net] has quit [Remote host closed the connection]
01:20 -!- jarthur [~jarthur@user/jarthur] has quit [Quit: jarthur]
01:46 -!- jonatack [jonatack@user/jonatack] has quit [Ping timeout: 248 seconds]
02:03 -!- kexkey [~kexkey@178.249.214.27] has quit [Ping timeout: 248 seconds]
02:05 -!- kexkey [~kexkey@178.249.214.10] has joined #c-lightning
02:10 -!- opsec_x12 [~opsec_x12@44-25-143-42.ip.hamwan.net] has joined #c-lightning
02:13 -!- jonatack [jonatack@user/jonatack] has joined #c-lightning
02:22 -!- jonatack [jonatack@user/jonatack] has quit [Ping timeout: 250 seconds]
02:39 -!- jonatack [jonatack@user/jonatack] has joined #c-lightning
04:25 -!- jespada [~jespada@2a0c:5c84:1:4000::91c2] has quit [Quit: Textual IRC Client: www.textualapp.com]
04:35 -!- jespada [~jespada@2a0c:5c84:1:4000::8dad] has joined #c-lightning
05:35 -!- jonatack [jonatack@user/jonatack] has quit [Ping timeout: 248 seconds]
05:36 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
07:16 -!- ShotokanZH [~ShotokanZ@aitch.me] has quit [Ping timeout: 256 seconds]
07:18 -!- sturles [~sturles@sauron.uio.no] has quit [Ping timeout: 250 seconds]
07:19 -!- sturles [~sturles@sauron.uio.no] has joined #c-lightning
07:24 -!- ShotokanZH [~ShotokanZ@aitch.me] has joined #c-lightning
08:06 -!- jonatack [jonatack@user/jonatack] has joined #c-lightning
09:00 -!- An0rak [An0rak@user/an0rak] has joined #c-lightning
09:01 -!- An0rak [An0rak@user/an0rak] has quit [Client Quit]
09:07 -!- jonatack [jonatack@user/jonatack] has quit [Ping timeout: 272 seconds]
09:31 -!- jonatack [jonatack@user/jonatack] has joined #c-lightning
09:34 -!- jarthur [~jarthur@user/jarthur] has joined #c-lightning
11:32 < vincenzopalazzo> mschmoock: Can you take a look to it https://github.com/lightningd/plugins/pull/356 when you have time?
11:50 < cdecker[m]> Acked, nothing better to do in the TSA line. And I also need to fix up CI again
11:51 < vincenzopalazzo> cdecker[m]: You already did :) I see your change with poetry
11:51 < vincenzopalazzo> In addition, do you think that it is better some time in the future diveded the test in two type
11:52 < vincenzopalazzo> with dev dependeces installed from cln
11:52 < vincenzopalazzo> and one with the dependencies inside the plugin dir, in this way we can find quickly this problem here
11:53 < vincenzopalazzo> or just migrate all in rust :p
12:05 < cdecker[m]> I think a single check with pyln deps overriden to use cln master might be a good idea to alert us on breakage in the API, but we can do that on a schedule rather than for each PR (it's checking regressions in pyln and not in the plugins after all)
12:08 < vincenzopalazzo> Yeah I see, just a single run I think can be good after X time
13:12 -!- stonefox12885 [~stonefox@user/stonefox] has joined #c-lightning
13:14 -!- stonefox1288 [~stonefox@user/stonefox] has quit [Ping timeout: 272 seconds]
13:14 -!- stonefox12885 is now known as stonefox1288
14:56 < grubman> if i have a secondary db on a flash drive being written to simultaneously with the primary db, would that slow down cln significantly while it waits to finish writing to the slow flash drive?
15:11 < cdecker[m]> Indeed backups and secondary DBs have to be written synchronously, as missing a transition renders them unusable. The backup plugin however uses a very efficient append-only method that doesn't do random access and has just one write per DB transaction, whereas the secondary DB actually has to do work to complete the write. Never measured it, but I think it might be faster than the secondary DB
15:16 < grubman> ahh interesting
15:16 < grubman> thx
15:18 < cdecker[m]> It's worth mentioning though that compared to network latency the time to read/write from/to disk is likely negligible, and the added safety is definitely worth the extra time.
15:34 -!- An0rak [An0rak@user/an0rak] has joined #c-lightning
16:10 < vincenzopalazzo> rusty: in the deprecated propriety of a JSON payload we should keep it in the JSON schema until we don't remove it from the API? I'm thining this because now we generate the code from the schema
16:22 -!- An0rak [An0rak@user/an0rak] has quit [Ping timeout: 256 seconds]
16:25 -!- An0rak [An0rak@user/an0rak] has joined #c-lightning
16:56 < cdecker[m]> `msggen` will ignore deprecated fields fwiw. And I think they have to stay in the schema until they actually get removed, otherwise verification may fail, but I'm not 100% on that
16:58 < vincenzopalazzo> Oh ok msggen will ignore the deprecated fields anyway?
16:58 < vincenzopalazzo> and about testing, yes but I just skipping the phase to test deprecated rpc command for now
16:59 < vincenzopalazzo> but yes, make sense keep the schema as is also in deprecate mode
18:25 -!- rusty [~rusty@203.217.95.210] has joined #c-lightning
18:42 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
20:03 -!- rusty [~rusty@203.217.95.210] has left #c-lightning []
21:19 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
21:21 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
22:33 -!- livestradamus [~quassel@user/livestradamus] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
22:34 -!- livestradamus [~quassel@user/livestradamus] has joined #c-lightning
--- Log closed Tue Apr 12 00:00:52 2022