GSoC: Binary package distribution through GnuNet (report 1)

GSoC: Binary package distribution through GnuNet (report 1)

[asgeir]

Hello,

it is high time I send you my first report, as the coding period
started last week. In the process of implementing package distribution
through GnuNet, I started writing Guile bindings.

During the community bonding period, besides the documentary work,
I’ve headed to the two first problems: options handling and variadic
functions.

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.

More detailed explanations:

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.

Variadic functions: these aren’t handled by Guile’s Dynamic FFI. As
the only one I’ve encountred has been replaced with a non-variadic
version in a separated C library.

Data structures: main work has been the mapping of the huge
ProgressInfo structure. GnuNet works with an event loop and you’re
supposed, as a GnuNet API user, to provide a callback that will be
used each time something happens in GnuNet’s File-Sharing
subsystem. This callback is given a big structure, ProgressInfo, that
contains every bit of information that could be needed. A good mapping
of this structure is fundamental. For now, I’ve settled on a set of
classes with a very simple hierarchy (one class for each type of
event).

If you have any suggestion or question, please feel free to contact
me!
--
Rémi

Re: GSoC: Binary package distribution through GnuNet (report 1)

[Ludovic Courtès]

Hi!

asgeir@free.fr 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.

> 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?  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.

> Variadic functions: these aren’t handled by Guile’s Dynamic FFI. As
> the only one I’ve encountred has been replaced with a non-variadic
> version in a separated C library.

I think I mentioned it before: In practice, we can manage to call
variadic functions from the FFI.  So you shouldn’t have to write any C
code.  Perhaps we could discuss the details on IRC?

> Data structures: main work has been the mapping of the huge
> ProgressInfo structure. GnuNet works with an event loop and you’re
> supposed, as a GnuNet API user, to provide a callback that will be
> used each time something happens in GnuNet’s File-Sharing
> subsystem. This callback is given a big structure, ProgressInfo, that
> contains every bit of information that could be needed. A good mapping
> of this structure is fundamental. For now, I’ve settled on a set of
> classes with a very simple hierarchy (one class for each type of
> event).

OK.  I must say I’m not fond of GOOPS, so I’d be curious to see the
code.  That shouldn’t block you, though.

Thank you for the update!

Ludo’.

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: [GNUnet-developers] GSoC: Binary package distribution through GnuNet (report 1)

[Christian Grothoff]

[-- Attachment #1: Type: text/plain, Size: 2303 bytes --]

On 06/03/2015 05:15 PM, Ludovic Courtès wrote:
> Hi!
> 
> asgeir@free.fr 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [GNUnet-developers] GSoC: Binary package distribution through GnuNet (report 1)

[Ludovic Courtès]

Christian Grothoff <grothoff@gnunet.org> skribis:

> On 06/03/2015 05:15 PM, Ludovic Courtès wrote:
>> asgeir@free.fr 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...

OK, I have requested the creation of a repo under the Guix project on
Savannah:

  https://savannah.gnu.org/support/?108833

Rémi: I will add you on Savannah so you can push your code there when
the repo is ready.  Make sure to add a ‘COPYING’ for the GNU GPL v3, as
well as copyright and license headers (see how this is done in Guix.)
Feel free to contact me off-list for additional details.

>>> 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.

OK, so I guess there’s nothing to worry about in the end.  :-)

Thanks for your feedback!

Ludo’.

Re: [GNUnet-developers] GSoC: Binary package distribution through GnuNet (report 1)

[Ludovic Courtès]

Hello Rémi,

ludo@gnu.org (Ludovic Courtès) skribis:

> OK, I have requested the creation of a repo under the Guix project on
> Savannah:
>
>   https://savannah.gnu.org/support/?108833

The repo was quickly set up.

> Rémi: I will add you on Savannah so you can push your code there when
> the repo is ready.  Make sure to add a ‘COPYING’ for the GNU GPL v3, as
> well as copyright and license headers (see how this is done in Guix.)
> Feel free to contact me off-list for additional details.

Could you send me your Savannah account name so I can add you to the
group, and then push the GNUnet bindings there for discussion?

TIA!

Ludo’.

Re: GSoC: Binary package distribution through GnuNet (report 1)

[asgeir]

Hello,

I've just done an inclusion request to Guix, with the name "remibd"!

By the way, I'm will have very few moments of internet access until
monday evening, therefore I'll probably be able to send my second
report and upload code only on thursday.

I'm a bit late, as the bindings are not functional yet (and were
supposed to be according to my schedule), I'll detail this on the
report.
-- 
Rémi

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Re: [GNUnet-developers] GSoC: Binary package distribution through GnuNet (report 1)

[Ludovic Courtès]

Hi Rémi,

asgeir@free.fr skribis:

> I've just done an inclusion request to Guix, with the name "remibd"!

Actually you had only created the account, but I’ve added you to the
group.

Please restrict yourself to the guix/gnunet.git repository:

  remibd@git.sv.gnu.org:/srv/git/guix/gnunet.git

> I'm a bit late, as the bindings are not functional yet (and were
> supposed to be according to my schedule), I'll detail this on the
> report.

Please do discuss any problems that you have on IRC, on the mailing
lists, etc.  I’m sure there are many fine people who’d be happy to
answer your questions about Guile, the FFI, GNUnet, and whatnot!

Ludo’.