guix-devel
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] GSoC: Binary package distribution through GnuNet


From: Christian Grothoff
Subject: Re: [GNUnet-developers] GSoC: Binary package distribution through GnuNet (report 1)
Date: Wed, 03 Jun 2015 21:12:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0

On 06/03/2015 05:15 PM, Ludovic Courtès wrote:
> Hi!
> 
> address@hidden skribis:
> 
>> This first week started with cleaning and organizing the draft
>> bindings I’ve been working on previously (set up of a proper directory
>> structure, a small Makefile, etc.), then most of the work has been on
>> mapping GnuNet’s data structures.
>>
>> This week, I’m heading for the remaining “most-needed” functions (URI
>> handling, scheduling) and some testing, and also writing a simplified
>> version of the `gnunet-search` utility, as it could be a good test and
>> example of usage for the bindings.
> 
> OK, sounds like a good plan!
> 
> Are you already using a public repo that we could look at?  If not, we
> should set up a Git repository at gnunet.org or Savannah, whichever is
> more convenient.

gnunet.org isn't quite setup for *public* Git's yet...

>> Options handling: the standard way of writing software that uses
>> GnuNet’s API is to let GnuNet handle the command line options: the
>> API’s entry point, must be fed directly with the C arguments vector
>> `argv`; it assures that all GnuNet programs have a uniform CLI. The
>> first difficulty I encountred is: how to properly handle these
>> options? After some work, I decided to manually craft a fake `argv` as
>> a quick temporary fix.
> 
> OK.  Question for the GNUnet people: What’s the recommended way to
> handle argc/argv if we want to provide a library?

Well, libgnunetutil contains a wrapper around getopt for our own
convenience, but I'm totally fine with using a language-specific
argv-parser for command-line tools. Note that GNUnet *libraries*
obviously also don't take command-line arguments, so I'm not sure what
the question is.

> Typically a Guile
> module cannot be passed any arguments, and the initialization that
> happens is just that its top-level forms are evaluated when it’s loaded.
> Having to explicitly call an initialization function that takes an argv
> would look unidiomatic.

Right, same applies for (most) GNUnet APIs, with the exception of our
"service" and "program" abstractions which are there to make it easy to
write a 'main' function.  But I don't see a need to expose those two
APIs to Guile.

Happy hacking!

Christian

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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