[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] GNUNET_PROGRAM* option evaluation does not work

From: Christian Grothoff
Subject: Re: [GNUnet-developers] GNUNET_PROGRAM* option evaluation does not work as expected
Date: Fri, 15 Mar 2019 22:51:25 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

On 3/15/19 4:06 PM, Schanzenbach, Martin wrote:
> No it was not.
> I am pretty sure that instead of calling gnunet-uri as a binary from a binary 
> is pretty nonsensical.

Why? I see nothing wrong with that. It's not like this matters for
performance or that starting gnunet-uri has any other real disadvantage
here that I can think of.

> Instead, gnunet-qr should just do what gnunet-uri does with the uri.
> If we need to share code between them, fine, then refactor. But imitating 
> python behavior here is not good style.
> Hence the CLI tools should be built using GNUNET_PROGRAM_run ().

Ok, now I undestand why you suggested GNUNET_PROGRAM_run(), but I don't
see this as "Python" behavior, more like UNIX behavior ;-).

>> On 15. Mar 2019, at 06:10, Christian Grothoff <address@hidden> wrote:
>> Signed PGP part
>> On 3/13/19 6:25 PM, Hartmut Goebel wrote:
>>> Martin wrote:
>>>> The first thing you should do it use GNUNET_PROGRAM*.
>> Actually, that advice was slightly off: as you don't want/need the
>> scheduler, you don't need GNUNET_PROGRAM_run() but just GNUNET_GETOPT_*
>> for gnunet-qr.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]