--- Log opened Thu Mar 05 00:00:12 2020
00:17 -!- vasild_ is now known as vasild
00:51 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Quit: Leaving]
00:55 < vasild> What about checking if plugin->dynamic is false in destroy_plugin() and exiting if so?
00:56 < vasild> Sounds a bit too crude.
01:07 -!- Netsplit *.net <-> *.split quits: jonatack, fiatjaf
01:16 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection]
01:17 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #c-lightning
01:35 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 272 seconds]
01:43 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning
01:43 -!- fiatjaf [~fiatjaf@2804:7f2:2980:90fa:ea40:f2ff:fe85:d2dc] has joined #c-lightning
02:12 -!- k3tan [~pi@unaffiliated/k3tan] has joined #c-lightning
03:06 -!- belcher [~belcher@unaffiliated/belcher] has joined #c-lightning
03:46 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:55fc:f43c:fed0:4fc6] has joined #c-lightning
03:47 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:55fc:f43c:fed0:4fc6] has quit [Client Quit]
04:54 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has left #c-lightning []
04:54 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has joined #c-lightning
05:02 < vasild> I am trying to nail down the build failures that have been plaguing travis lately. From what I see it should always fail with gcc 4.8, compiling libwally-core and a fix should be applied to it - either compile with -std=c99 or remove the variable declaration from the for loop (ie make it c89 compliant).
05:03 < vasild> However https://travis-ci.org/ElementsProject/lightning/jobs/658424251 has passed
05:03 <@cdecker> That'd be awesome to have a fix for, I was already tempted to remove that config from the build matrix because the results have become totally useless since that compiler started acting up
05:03 < vasild> and I am comparing the travis logs with another job that failed: https://travis-ci.org/ElementsProject/lightning/jobs/658627632
05:03 <@cdecker> But if we find a good solution (I haven't found a good place to pass in `-std=c99` yet) that'd be even better
05:04 < vasild> cdecker: why did your travis job pass? Some secret magic touch? ;)
05:05 < vasild> comparing the raw logs of the failing jobs:
05:05 < vasild> travis_fold:start:script.2\r+make -j3
05:05 < vasild> cmp: gen_version.h: No such file or directory
05:05 < vasild> +echo -en 'travis_fold:end:script.2\\r'
05:05 < vasild> travis_fold:end:script.2\r+make check-source
05:05 < vasild> is the log for the ok job
05:05 <@cdecker> Absolutely no idea why it worked :-)
05:06 < vasild> and for the failing job:
05:06 < vasild> +echo -en 'travis_fold:start:script.2\\r'
05:06 < vasild> travis_fold:start:script.2\r+make V=1
05:06 < vasild> gcc-4.8 -DBINTOPKGLIBEXECDIR=....... and the build fails
05:07 < vasild> I removed the -j3 and added V=1 (verbose) to make the build log more easier to grasp, there is no way that this could make a difference
05:08 < vasild> well, -j3 could introduce some nondeterminism and I would expect that it could break with parallel build sometimes
05:09 <@cdecker> Yeah, but stylistic warnings about declarations in a function? That's very strange if caused by concurrency
05:09 <@cdecker> (or are we not talking about the declaration order warning with gcc 4.8?)
05:10 < vasild> in the failing job https://api.travis-ci.org/v3/job/658627632/log.txt 
05:10 < vasild> it fails with:
05:10 < vasild> ../../libwally-core/src/elements.c: In function ‘wally_asset_pak_whitelistproof’:
05:10 < vasild> ../../libwally-core/src/elements.c:629:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
05:10 < vasild>      for (size_t i = 0; i < num_keys; ++i) {
05:10 < vasild>      ^
05:11 < vasild> I find it puzzling that "make -j3 > /dev/null" prints nothing other than "cmp: gen_version.h: No such file or directory" and then succeeds
05:13 < vasild> also, "2>&2" is strange here: https://github.com/ElementsProject/lightning/blob/master/Makefile#L388, but lets not get distracted...
05:13 < vasild> maybe it was intended to be "2>&1"
05:14 < vasild> anyway, I think I will give up trying to answer why it passes sometimes
05:15 < vasild> cdecker: "I haven't found a good place to pass in `-std=c99` yet" -- that should be somewhere in libwally-core CFLAGS, no?
05:23 <@cdecker> Yes, but libwally-core is a submodule we can't edit, so we should likely add the flag to `external/Makefile` which invokes `configure` and `make` in libwally-core
05:38 < vasild> pushed the -std=c99 addition at https://github.com/ElementsProject/lightning/pull/3561/commits/1ad706af53b193d905af4b1b4cd11314dee61665, lets see if it will fix it and/or break something else...
05:55 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
05:55 -!- belcher [~belcher@unaffiliated/belcher] has joined #c-lightning
06:02 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
06:03 -!- belcher [~belcher@unaffiliated/belcher] has joined #c-lightning
06:06 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:55fc:f43c:fed0:4fc6] has joined #c-lightning
06:08 < michaelfolkson> Hey. darosior presented on c-lightning plugins in London earlier this week. I'm writing up an article for Bitcoin Magazine (review would be welcome!) and have a few additional questions.
06:11 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds]
06:12 < darosior> Hi michaelfolkson !
06:12 < darosior> You can ask your question here, otherwise feel free to PM me
06:13 < michaelfolkson> I'm interested in this use case (only one of many obviously) of existing Bitcoin wallets integrating Lightning. The rust-lightning BYO approach seems optimal for this use case but some e.g. harding have talked about using hsmd as a wrapper around Bitcoin Core. Is this use case something that could be done with c-lightning? What additional work needs to be done to make this possible?
06:13 < michaelfolkson> Hey darosior!
06:14 < michaelfolkson> I'll send you the draft article when it is done. Anyone else who is interested in reviewing/suggesting edits can do so too
06:14 < m-schmoock> :D great
06:16 < darosior> "Is this use case something that could be done with c-lightning" => I'd say writing a Bitcoin plugin to make C-lightning gather data from your wallet, then make an interface around C-lightning for your users to feel like they use your wallet but you just past requests to C-lightning
06:16 < darosior> If that's an end-user wallet there are a lot of drawbacks though..
06:16 < darosior> s/past/pass/
06:18 < harding> michaelfolkson: to be clear, my mailing list post was refering to just using Bitcoin Core as a keystore, the same way you'd use a trezor or ledger today.  I was refering to enabling LN support in the Bitcoin Core GUI or CLI.
06:19 < harding> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002138.html
06:22 < michaelfolkson> Thanks for clarifying. So I suppose I need to be clearer on exactly what "Bitcoin wallets integrating Lightning" means and the different approaches for doing so. Your approach isn't using the Bitcoin Core wallet, just they keystore
06:23 < michaelfolkson> The rust-lightning use case is for utilizing your existing wallet code rather than just the keystore
06:24 < michaelfolkson> (Or at least that's the aim)
06:26 < harding> That's what they advertise, but I'm not quite sure they're communicating the extent of changes necessary to an existing wallet in order for it to support LN, nor how rust-lightning's library API differs from an existing wallet using c-lightning's RPC API or LND's gRPC API or eclair's rest API.
06:29 < michaelfolkson> I suppose until a wallet actually tries to use rust-lightning for this purpose it won't be clear. And rust-lightning isn't completed yet to even start trying afaiu
06:31 < harding> Sure.  I hear they're working on better documentation, which may help clarify things.
06:33 < michaelfolkson> Rusty said in one of his presentations that the intention is to push as much c-lightning functionality to plugins as possible which is moving in that rust-lightning direction. I don't know what is left of lightningd at that stage. It could look similar to a rust-lightning "core" component
06:45 < michaelfolkson> OK thanks. Another question. This RPC command hook that darosior built. Extra functionality in plugins is great but merging in dangerous hooks surely negates the whole point of having a secure core? It seems to me there is a fine line and a direct trade-off between security and allowing functionality here.
06:46 < darosior> I'd argue that the responsibility is on the hook user, hence the plugin developer
06:46 < darosior> An unused hook doesn't harm
06:47 < darosior> I recall you asked me this question during the meetup but I think I didn't understand it plainly ^^"
06:49 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning
06:50 < michaelfolkson> And so it is important not only to curate which plugins are "well written" (caveat emptor) but also which hooks they utilize when deciding on whether to run those plugins
06:52 < michaelfolkson> I'm guessing some hooks in c-lightning will be rejected because they encourage insecure practices and maybe this RPC command hook sits at that fault line currently
06:55 < michaelfolkson> You only find out where to draw that fault line with experimentation so this isn't criticism. Just trying to work out if my understanding is correct or not
06:59 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:55fc:f43c:fed0:4fc6] has quit [Quit: Sleep mode]
07:01 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:55fc:f43c:fed0:4fc6] has joined #c-lightning
07:04 -!- Amperture [~amp@65.79.129.113] has joined #c-lightning
07:13 -!- k3tan [~pi@unaffiliated/k3tan] has quit [Ping timeout: 268 seconds]
07:13 < darosior> "And so it is important not only to curate which plugins are "well written" (caveat emptor) but also which hooks they utilize when deciding on whether to run those plugins" ==> Absolutely, hence the curated list that cdecker has been maintaining
07:13 -!- k3tan [~pi@unaffiliated/k3tan] has joined #c-lightning
07:14 < darosior> Moreover we don't have hook chaining for every hook yet so you need to make the choice of the only plugin that will register your precious hook (not true anymore for htlc_accepted :) )
07:17 < darosior> "I'm guessing some hooks in c-lightning will be rejected because they encourage insecure practices and maybe this RPC command hook sits at that fault line currently" ==> I personally don't know. However since I told you that I thought it was a bad idea there were some use cases that were given to me and that changed my mind (cf the logs of this
07:17 < darosior> channel, and this gist I wrote afterwards https://gist.github.com/darosior/a35d43e952b2b120672a5bbcfa71bcf8)
07:19 -!- mdunnio [~mdunnio@38.126.31.226] has joined #c-lightning
07:23 < michaelfolkson> Cool. You need to be clear on separating upsides and downsides imo. Having use cases is an upside. Introducing vulnerabilities or encouraging insecure practices is a downside. It is possible to have both. Just because it has use cases doesn't necessarily mean it is a good idea :)
07:25 < willcl_ark> My interpretation of the plugin system is a bit different, with the exception of the rpc_command hook, most plugin hooks have equivalent subscribable streams in e.g. LND's RPC system.
07:29 < darosior> willcl_ark: I wasn't aware LND had such a system similar to hooks ?
07:31 < willcl_ark> darosior: it's true, you can't do hook-like things as-in custom behaviour in reaction to events.
07:32 < darosior> Ah ok what about those streams you were talking about then ?
07:32 < willcl_ark> But I am not aware of any hooks, except the aforementioned rpc_command, which could let someone write a malicious plugin which would e.g. send all their funds to you when you used it.
07:32 < darosior> It's like our notifications ?
07:33 < willcl_ark> yes exactly, see e.g. ChannelAcceptor: https://api.lightning.community/#channelacceptor
07:33 < darosior> "which could let someone write a malicious plugin" ==> No need for hooks to write a malicious plugin.. The RPC commands interface is enough
07:34 < willcl_ark> (it seems that, since i last checked, in fact this bi-directional stream now _does_ let you control whether to accept a channel open or not!)
07:34 < darosior> Ah interesting it's very similar to the openchannel hook
07:35 < willcl_ark> indeed... 
07:35 < michaelfolkson> The intention of lnd from the start wasn't customizability. I don't know if that has changed since. More maximum functionality, taking load off app developers
07:36 < willcl_ark> yeah my underlying point was that, I don't think it would be a fair classification of the CL plugin system to equate it to a balance between functionality and security, it's more a focus on modularity as I see it
07:36 < michaelfolkson> I saw this repo on emulating some lnd commands with c-lightning https://github.com/kristapsk/c-lightning-lnd-plugins
07:37 < willcl_ark> (although certainly, running un-reviewed plugins could represent a security risk, much like a random app which used a local LND as the backend whom you gave your admin macaroon to, for example)
07:58 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:55fc:f43c:fed0:4fc6] has quit [Quit: Sleep mode]
08:15 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:55fc:f43c:fed0:4fc6] has joined #c-lightning
08:29 < vasild> woho!
08:29 < vasild> sneaking -std=c99 into libwally-core works
08:34 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
08:51 < vasild> cdecker: the libwally-core build fix is in https://github.com/ElementsProject/lightning/pull/3561/commits/6395c4340b6efe5a463fbf2d47b76726e62a7041, two more minor commits in this PR
09:16 < m-schmoock> darosior: want to review? https://github.com/ElementsProject/lightning/pull/3572
09:16 < m-schmoock> waiting for your build in out pipeline :D
09:16 < m-schmoock> *our
09:18 < m-schmoock> now its starting
09:22 < darosior> m-schmoock: already gave a look :p
09:22 < darosior> Need to go, will give a closer look tomorrow
09:27 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds]
09:39 < m-schmoock> cu
09:59 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
10:09 < m-schmoock> Travis is so slooooow. Didn't knew it got this worse. I should have been more active
10:10 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:55fc:f43c:fed0:4fc6] has quit [Quit: Sleep mode]
10:23 < kanzure> which one is hsmd?
10:31 <@cdecker> Awesome, thanks vasild ^^
11:09 -!- Amperture [~amp@65.79.129.113] has quit [Remote host closed the connection]
11:17 < vasild> m-schmoock: I pushed like crazy in the last few hours to a wip PR, maybe that overloaded travis, if it has load quota
11:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
11:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
11:44 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
11:44 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
11:47 -!- vasild_ is now known as vasild
11:48 < vasild> cdecker: so, libwally's code was adjusted to be c89 compliant in https://github.com/ElementsProject/libwally-core/pull/177 but that is not included in the latest release `release_0.7.7`.
11:50 < grubles> the description for --enable-autotor-v2-mode is confusing to me. "Try to get a v2 onion address from the Tor service call, default is v3" 
11:50 < vasild> when libwally 0.7.8 is out, including the c89 compliance fix, then we can revert the sneak of -std=c99 via CFLAGS https://github.com/ElementsProject/lightning/pull/3561/commits/6395c4340b6efe5a463fbf2d47b76726e62a7041
11:51 < grubles> what's the v3 flag? i.e. if i want lightningd to create a v3 address automatically for me.
11:57 < vasild> grubles: it must be (I have not tested it): --addr=autotor:toradd:torport
11:58 < vasild> "--addr=autotor:toradd:torport" -- create v3 tor service
11:58 < vasild> "--addr=autotor:toradd:torport --enable-autotor-v2-mode" -- create v2 tor service
11:59 < vasild> maybe :)
12:08 < grubles> oh ok i see. thanks!
12:09 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
12:11 -!- mdunnio [~mdunnio@38.126.31.226] has joined #c-lightning
12:29 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:55fc:f43c:fed0:4fc6] has joined #c-lightning
12:39 -!- Maitor [~goban@gateway/tor-sasl/maitor] has quit [Remote host closed the connection]
12:41 -!- Maitor [~goban@gateway/tor-sasl/maitor] has joined #c-lightning
12:42 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:55fc:f43c:fed0:4fc6] has quit [Quit: Sleep mode]
12:48 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:55fc:f43c:fed0:4fc6] has joined #c-lightning
12:53 -!- michaelfolkson [~textual@2a00:23c5:be01:b201:55fc:f43c:fed0:4fc6] has quit [Quit: Sleep mode]
12:55 <@niftynei> cdecker what's the tl;dr on how COMPAT_VxXX flags work?
12:55 <@niftynei> #lazynifty
12:57 <@niftynei> are they used as markers for when it's safe to remove things?
12:59 <@cdecker> Exactly I think that's the idea
13:00 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has left #c-lightning []
13:01 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has joined #c-lightning
13:07 -!- michaelfolkson [~textual@host86-177-156-70.range86-177.btcentralplus.com] has joined #c-lightning
13:07 -!- michaelfolkson [~textual@host86-177-156-70.range86-177.btcentralplus.com] has quit [Client Quit]
13:11 <@niftynei> good to know!
13:12 <@niftynei> i've been working on getting glightning up to speed for v0.8.1; it'd be really nice if we had: 
13:12 <@niftynei> 1) really clear docs for the JSON requests / responses for RPC calls
13:12 <@niftynei> 2) clear documentation of the plugin requests / responses
13:14  * niftynei goes looking for the fancy clightning docs cdecker set up at one point
13:23 < m-schmoock> niftynei: As I see it, most of the c-code indentation we have uses 8char tabstops, correct?
13:23 < m-schmoock> in any case we should point that out in  doc/STYLE.md
13:24 < m-schmoock> I just recocnized this yet and was using 4char tabs in the past
13:28 < m-schmoock> I see   .clang-format   IndentWidth: 8
13:31 < k3tan> does lightningd not need to authenticate with bitcoind if rpcuser/rpcpassword is set?
13:34 < m-schmoock> k3tan: if you have   bitcoin-rpcuser=XZY   and  bitcoin-rpcpassword=1234... set does not need anything else
13:34 < m-schmoock> (in the clightning config file)
13:36 < k3tan> thanks m-schmoock 
13:47 < m-schmoock> niftynei: added STYLE.md 8char tabs note by https://github.com/ElementsProject/lightning/pull/3572/commits/2b8fa7a596974e92b82de09a1b61582b3c9c7a4d
13:47 < m-schmoock> thx for nitting ;)
13:52 -!- Maitor_ [~goban@gateway/tor-sasl/maitor] has joined #c-lightning
13:55 -!- Maitor [~goban@gateway/tor-sasl/maitor] has quit [Ping timeout: 240 seconds]
14:13 <@niftynei> m-schmoock: i believe there's a specific style note about lining up params to functions
14:13 <@niftynei> which is independent of the 8-space tabstop style note
14:14 <@niftynei> in fact, it's often in contravention of the 8-space tabstop rule
14:25 <@niftynei> damn i can't find it now ... lol
14:37 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
14:39 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
14:50 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
14:53 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning
15:41 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
16:11 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 256 seconds]
16:13 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #c-lightning
16:15 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #c-lightning
16:18 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds]
16:40 -!- Maitor_ [~goban@gateway/tor-sasl/maitor] has quit [Quit: Maitor_]
16:40 -!- Maitor [~goban@gateway/tor-sasl/maitor] has joined #c-lightning
17:11 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
17:13 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
17:51 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
18:06 < fiatjaf> how do I get dev-sendcustommsg?
18:06 < zmnscpxj> compile with DEVELOPER=1
18:06 < zmnscpxj> ?
18:06 < fiatjaf> I have dev-listaddrs and dev-rescan-outputs
18:06 < fiatjaf> does that mean I compiled with DEVELOPER=1?
18:06 < zmnscpxj> hmmm version?
18:07 < zmnscpxj> it should
18:07 < fiatjaf> master
18:07 < fiatjaf> where is that DEVELOPER=1 thing?
18:07 < zmnscpxj> at configure or make
18:08 < fiatjaf> config.vars has DEVELOPER=0
18:08 < fiatjaf> is that a flag?
18:08 < fiatjaf> or just changing it on config.vars will do the job?
18:09 < zmnscpxj> you probably want to git clean -fxd . everything, then ./configure --enable-developer
18:09 < zmnscpxj> then make && make install
18:09 < zmnscpxj> just to be sure :P
18:10 < zmnscpxj> dev-listaddrs is not behind DEVELOPERS? how weird
18:42 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Ping timeout: 260 seconds]
18:55 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
18:58 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
19:16 < fiatjaf> ok, now I have a ton more dev- commands
19:17 < fiatjaf> great!
19:22 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #c-lightning
19:46 < rusty> fiatjaf: ./configure --enable-developer
20:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
20:50 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 255 seconds]
20:54 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
20:55 -!- achow101 [~achow101@unaffiliated/achow101] has joined #c-lightning
21:23 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has left #c-lightning []
21:23 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has joined #c-lightning
22:01 -!- cryptoso- [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Ping timeout: 240 seconds]
22:02 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #c-lightning
23:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
23:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
23:43 -!- vasild_ is now known as vasild
23:46 < vasild> m-schmoock: niftynei: wrt code indentation/style - I have integrated clang-format into my editor so it does the formatting, line wrapping, parameters indentation, etc. The good thing is that I know this way I do the correct formatting and also any other dev that is using clang-format would have formatted it in exactly the same way.
23:49 < vasild> No more worrying about style. Eventually it would be good to have a pre-push automatic check that the new code is formatted correctly.
--- Log closed Fri Mar 06 00:00:18 2020