[c-lightning] adding new commands to lightning-cli

Fri Dec 14 13:58:11 AEDT 2018

Hi  Zmn,

Good morning.

Yes, completely agree with you, I would like to contribute to LN, I'm
running lightning in integration with this repo(
https://github.com/sg777/chips3) which is a bitcoin fork. Can I add changes
to LN that support CHIPS, so that I can push the commands upstream which I
implemented?

Regards,
Sarat G

On Thu, Dec 13, 2018 at 6:43 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Sarat,
>
> Adding commands to lightningd directly without contributing them to
> lightningd development is risky for you.
> You will have to maintain your own fork forever, and if we rework command
> system again, you will have to adapt your new commands.
>
>
> Regards,
> Zmn
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, December 13, 2018 11:17 AM, Sarat G <
> sarath.ginjupalli89 at gmail.com> wrote:
>
> Hi  ZmnSCPxj,
>
> Sorry for the late reply, I overlooked the mail. I'm implementing few of
> the commands mentioned below:
>
> 1. invoice-count:  Returns the count of the invoices
> 2. delete-all-invoices: Deletes all the existing invoices
> 3. peer-channel-state: Returns the state of the channel for the given
> peer_id.
>
> As mentioned by Christian, for the commands to which I don;t need to pass
> arguments I was able to implement them successfully. But for implementing
> the command 'peer-channel-state' I need to pass peer_id as parameter. when
> I passed so the it's crashing in the lightningd.
>
> Below is the crash log, while passing parameters do we need to handle them
> at the lightningd?
>
> root*@sg777*-1 ~/lightning/cli # ./lightning-cli peer-channel-state "03943d572eb97ac78055cf4c708660228a60b2956fdcfeaaceba5551f98e92e727"lightningd: lightningd/jsonrpc.c:480: parse_request: Assertion `c->pending' failed.2018-12-*13T03*:07:34.*086Z* lightningd(14958): FATAL SIGNAL 6 RECEIVED2018-12-*13T03*:07:34.*103Z* lightningd(14958): backtrace: lightningd/log.c:494 (log_crash) 0x55a79691c9932018-12-*13T03*:07:34.*103Z* lightningd(14958): backtrace: (null):0 ((null)) 0x7ffae5b3cf1f2018-12-*13T03*:07:34.*103Z* lightningd(14958): backtrace: (null):0 ((null)) 0x7ffae5b3ce972018-12-*13T03*:07:34.*103Z* lightningd(14958): backtrace: (null):0 ((null)) 0x7ffae5b3e8002018-12-*13T03*:07:34.*103Z* lightningd(14958): backtrace: (null):0 ((null)) 0x7ffae5b2e3992018-12-*13T03*:07:34.*103Z* lightningd(14958): backtrace: (null):0 ((null)) 0x7ffae5b2e4112018-12-*13T03*:07:34.*103Z* lightningd(14958): backtrace: lightningd/jsonrpc.c:480 (parse_request) 0x55a796918cba2018-12-*13T03*:07:34.*103Z* lightningd(14958): backtrace: lightningd/jsonrpc.c:645 (read_json) 0x55a79691954a2018-12-*13T03*:07:34.*103Z* lightningd(14958): backtrace: ccan/ccan/io/io.c:59 (next_plan) 0x55a79696c3002018-12-*13T03*:07:34.*103Z* lightningd(14958): backtrace: ccan/ccan/io/io.c:387 (do_plan) 0x55a79696cdfd2018-12-*13T03*:07:34.*103Z* lightningd(14958): backtrace: ccan/ccan/io/io.c:397 (io_ready) 0x55a79696ce3b2018-12-*13T03*:07:34.*103Z* lightningd(14958): backtrace: ccan/ccan/io/poll.c:310 (io_loop) 0x55a79696e8032018-12-*13T03*:07:34.*103Z* lightningd(14958): backtrace: lightningd/lightningd.c:407 (main) 0x55a79691b0a12018-12-*13T03*:07:34.*103Z* lightningd(14958): backtrace: (null):0 ((null)) 0x7ffae5b1fb962018-12-*13T03*:07:34.*103Z* lightningd(14958): backtrace: (null):0 ((null)) 0x55a7969099392018-12-*13T03*:07:34.*103Z* lightningd(14958): backtrace: (null):0 ((null)) 0xffffffffffffffff
> Fatal signal 6. 0x55a79691ca91 log_crash
> 	lightningd/log.c:5200x7ffae5b3cf1f ???
> 	???:00x7ffae5b3ce97 ???
> 	???:00x7ffae5b3e800 ???
> 	???:00x7ffae5b2e399 ???
> 	???:00x7ffae5b2e411 ???
> 	???:00x55a796918cba parse_request
> 	lightningd/jsonrpc.c:4800x55a79691954a read_json
> 	lightningd/jsonrpc.c:6450x55a79696c300 next_plan
> 	ccan/ccan/io/io.c:590x55a79696cdfd do_plan
> 	ccan/ccan/io/io.c:3870x55a79696ce3b io_ready
> 	ccan/ccan/io/io.c:3970x55a79696e803 io_loop
> 	ccan/ccan/io/poll.c:3100x55a79691b0a1 main
> 	lightningd/lightningd.c:4070x7ffae5b1fb96 ???
> 	???:00x55a796909939 ???
> 	???:00xffffffffffffffff ???
> 	???:0
> Log dumped in crash.log
> lightning-cli: Non-object response *''*[1]+  Aborted                 (core dumped) ../lightningd/lightningd
>
>
> Thank You.
>
> Regards,
> Sarat G
>
>
>
>
> On Fri, Dec 7, 2018 at 12:50 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning Sarat,
>>
>> What are you querying on the database?
>> If you find it useful, it might be that others find it useful, so it is
>> best if you feed it back to us upstream what extra command you made.
>> It might also be possible, as cdecker said, that, extra command can be
>> built from existing commands, and so it is better to put in some plugin
>> instead.
>>
>> Regards,
>> ZmnSCPxj
>>
>>
>> Sent with ProtonMail <https://protonmail.com> Secure Email.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Friday, December 7, 2018 2:30 PM, Sarat G <
>> sarath.ginjupalli89 at gmail.com> wrote:
>>
>> Hi Christian,
>>
>> Thank you very much for the help, now I'm able to add the commands
>> successfully by registering it with AUTODATA. Since I'm running the
>> customised queries on the database now I'm registering my methods with
>> AUTODATA and doing.
>>
>> Prior to this, I'm opening the `lightningd.sqlite3` file from the
>> program. But the problem which I encountered is if I make an RPC call the
>> DB gets locked and that sometimes preventing me to access the DB directly
>> from the same process.
>>
>> Anyways I written few queries and registered them with AUTODATA and there
>> are working fine.
>>
>> Thank you once again.
>>
>> Regards,
>> Sarat G
>>
>>
>>
>>
>> On Thu, Dec 6, 2018 at 7:50 PM Christian Decker <
>> decker.christian at gmail.com> wrote:
>>
>>> Hi Sarat,
>>>
>>> `AUTODATA` will take care of registering the json command with the
>>> JSON-RPC framework and you should be able to see your command with
>>> `lightning-cli help` after recompiling and restarting. The `struct
>>> json_command` that you registered with `AUTODATA` contains the method
>>> name and the function to be called when a request matching that method
>>> name comes in. The compiler should be able to help you with the
>>> signature of the function that we expect.
>>>
>>> Notice that if the information you require is exposed in some other way,
>>> you can also write a plugin, instead. Plugins can be written in whatever
>>> language you want, and can register options and JSON-RPC methods as well
>>> (more to come in future). So if you don't need information that is not
>>> otherwise exposed that might be a good option (you'd need to run the
>>> unreleased `master` version though).
>>>
>>> Cheers,
>>> Christian
>>>
>>> Sarat G <sarath.ginjupalli89 at gmail.com> writes:
>>> > Hi,
>>> >
>>> > As part of my project requirement, i got to need the command that
>>> returns
>>> > the status of the channel by taking input as peer id. For that I
>>> written up
>>> > the necessary logic and lined it using AUTODATA. My doubt is on the
>>> > lightningd side at which part do I need to add the logic to process the
>>> > command information sent by the lightning-cli.
>>> >
>>> > Can someone please provide me some insights into adding a single
>>> command to
>>> > the lightning-cli repo.
>>> >
>>> > Thanks in advance.
>>> >
>>> > Regards,
>>> > Sarat G
>>> > --
>>> > c-lightning mailing list
>>> > c-lightning at lists.ozlabs.org
>>> > https://lists.ozlabs.org/listinfo/c-lightning
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/c-lightning/attachments/20181214/796d8311/attachment-0001.html>