gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] [GSoC] GNUnet + Guix


From: Christian Grothoff
Subject: Re: [GNUnet-developers] [GSoC] GNUnet + Guix
Date: Sun, 23 Aug 2015 01:42:10 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0

On 08/21/2015 09:09 PM, address@hidden wrote:
> Hello!
> 
> it’s been a while since my last report, time for some news.

Thanks for the update!!!

>   What happened since last time?
>   ——————————————————————————————
> 
> After our meeting with Ludovic and Christian, I started working on the
> downloading and publication related functions. The tests and example
> programs were rapidly riddled with bugs and segfaults, and I’ve spent
> around one month trying to get the publication working.

Did you upgrade to SVN HEAD? Your last reports on the bugtracker all
seemed to point to GNUnet bugs that were fixed over a year ago in SVN...

> Once these problems have been addressed (i.e. a week ago), I could
> finally start working on the GNUnet publisher for Guix. Its first
> version can only upload one store item at a time, and isn’t even
> functional yet: a fikle segfault deems it unusable. Before noticing
> this segfault (it doesn’t always happen), I started working on a more
> complex version that would allow bulk publication of store items, but
> this gain in complexity came with a hole new set of strange and hardly
> traceable errors (SIGILL and SIGBUS), and it’s far from being
> usable. Moreover, the two version seem to have difficulties handling
> symlinks.

Interesting. Now, I cannot say that I tested gnunet-publish extensively
with symlinks.  If you can be specific about what doesn't work (assuming
the problem shows up just with gnunet-publish), I can look into it.
(Ideally just file such issues to gnunet.org/bugs/).

As for SIGBUS, the most likely case is that you're trying to write to a
read-only mmapped memory area (unless you're testing on sparc/ppc). If
that's really the case, gdb should be very helpful. SIGILL sounds more
like you're having memory corruption.  Unless Guile did grow a JIT (I
only recall prototypes), you ought to be able to find that with valgrind.

>   Guile – GNUnet
>   ——————————————
> 
> The bindings are focused on the FileSharing service, and seem
> usable. I’ll write detailed documentation before the end of the GSoC,
> and list the pitfalls to avoid (at least those I’m aware of). There’s
> still work to do, notably:
> 
>   — unify the names, according to Scheme/Guile/Guix conventions, and
>     reorganize the source.
> 
>   — check every function for lacks of arguments checking, verify
>     everything that’s given to foreign functions.
> 
>   — replace all ad-hoc exceptions with more meaningful srfi-34
>     exceptions;
> 
>   — replace `invalid-result` exceptions, raised whenever a foreign
>     function returns NULL, with more meaningful ones (by inspecting
>     the GNUnet source);
> 
>   — use the various “context pointers” to allow a more functional
>     style: discarded in the current bindings, these are transmitted
>     from one function call to another (akin `fold`).
> 
>   — improve testing, document everything, complete the bindings and
>     extend them to other GNUnet services.
> 
>   Publishing packages
>   ———————————————————
> 
> Eclosed you’ll find the more usable version of the publisher, “tested”
> with the following software:
> 
>   — Guix:         commit 7cb6f648b2486b0e6060a333564432a0830637de
>   — GNUnet:       rev.   36242
>   — Libextractor: rev. 36031
>   — the bindings: commit dc6f74d269fcb324d8649f3c511299b7ba2be2a4
> 
> This publisher can be tested: for that you’ll have to put
> `publish-gnunet.scm` and `publish-utils.scm` in `guix/scripts`, and
> start GNUnet (see my previous reports). Then you can create an ego:
> 
>   $ gnunet-identity -C mytestego
> 
> and call the publisher with:
> 
>   $ guix publish-gnunet -c /path/to/gnunet.conf -P mytestego \
>                            /gnu/store/somedirectory
> 
> The file `publish-utils.scm` contains code shared between the HTTP
> publisher and this one; I did not knew were to store it, thus the
> improper module in (guix scripts). `publish-utils-multi.scm` is the
> second version of the publisher, not usable though :(
> 
> As usual, do not hesitate to contact me for any question!

Well, thanks for the update, and please don't hesitate to file more bugs
on Mantis if you have an issue that looks like it comes from the GNUnet
code.

Happy hacking!

Christian

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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