Re: [Help-gnunet] Questions on latest version

[Tom Barnes-Lawrence]

Please note that I'm about to go visiting family for a week or so, so won't
be able to reply till I get back (yeah, I suppose I probably should have
picked a better time to start the thread, sorry...)

On Mon, Sep 01, 2003 at 06:20:50PM -0500, Christian Grothoff wrote:
> >  I tend not to bother with gnunet-gtk much, I'm afraid; I had another
> > look this release, but it didn't seem any more stable. So I'm still
> > working with gnunet-insert- or hoping to.
> 
> Hmm. I haven't seen gnunet-gtk crash in a long, long time. Maybe you could 
> bother to report what is going wrong?
 Like I've said in the past, the segfaults seem to be *very* unpredictable
(I've certainly tried to find a reliable way to reproduce them in the past),
and I don't habitually run processes through GDB.
This time, I managed to get:

Starting program: /usr/local/bin/gnunet-gtk 
[New Thread 1024 (LWP 799)]
[New Thread 2049 (LWP 800)]
[New Thread 1026 (LWP 801)]
[New Thread 2051 (LWP 802)]
[New Thread 3076 (LWP 807)]
[New Thread 4101 (LWP 809)]
[New Thread 5126 (LWP 811)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 799)]
0x08055d08 in _IO_stdin_used ()
(gdb) ba
#0  0x08055d08 in _IO_stdin_used ()
#1  0x08055d03 in _IO_stdin_used ()
#2  0x00000000 in ?? ()

after trying to start a download. I forget what caused the segfault a few
days ago, but in the past it's generally been from simply starting
searches. Whether it's been for unusual keywords or common keywords or
second searches or first searches, or what, has *never* been clear to me.

> For me, it has been rock solid for the 
> last versions (what GTK version are you using???)
The debian/stable package of libgtk1.2 (1.2.10-11)
which has the filename of libgtk-1.2.so.0.9.1 (don't ask me how they
come up with the numbers...)


> Let me try again. We have a directory which contains whatever. That directory 
> is identified uniquely (without updates, this version) with a file identifier 
> "F". The user providing the directory put this directory under keyword "k" 
> into the global namespace, creating the RBlock "R" (which contains F plus 
> some meta-data and which will be found when searching for "k").
 OK, with you so far.

>  The user 
> ALSO added the directory to his namespace "X" under the namespace key "T". 
> "T" is like "k" a keyword, just that  "T" is not in the global namespace but 
> in the private namespace "X".  Inserting the directory into the namespace "X" 
> under key "T" created an SBlock "S" containing "F" and meta-data, such as the 
> identifier "N" of a possible future update update.

 Aaaaahhhhh.
 Key as in keyword for finding the content, *not* key as in private/public
keys used to encrypt+insert or download+decrypt the content respectively.
Now it's making more sense to me.

> If another user wants to refer to the directory, he can add to his directory 
> either
> a) the RBlock "R" which knows nothing about the namespace and which will 
> continue to refer to the original version of the directory D
> b) the SBlock "S" which will by the nature of containing N also refer to 
> future versions of "D"

 What does the URI look like for SBlocks? AFAICT I've not seen one in any
search response yet.


> Patches are welcome (or you can make your FAQ even more valueable by 
> explaining what I obviously can not explain :-).

 Hehe, I was planning on doing that, my little FAQ drastically needs
updating, and this seemed an ideal time to do so. But that'll have
to wait till I get back again.

 I also considered making some sort of a glossary for the terms- I think
that's the main problem for me. Some of it reminds me of that Alice in
Wonderland scene where she's trying to find out what someone's called.
"No, that's just what his name's called", and so on. It gets generally
confusing (and I've not quoted it properly, I just remember it from that
weird book "Godel Escher Bach"). Sorry, I'm rambling again...


> >  I suppose that if you make a directory, you'll want to insert it
> > (maybe you'd want to make separate directories to create heirarchies
> > by hand, rather than relying on the -r flag, but it'd be no use without
> > having all the directories published), but when you try to create/
> > insert the directory at the same time as inserting what it refers to,
> > it all gets a bit unclear what's going on IMHO.
> 
> The problem is, that this is the only practical way to get all of the 
> file-identifiers straight. gnunet-gtk allows you to freely compose 
> directories from files inserted earlier. A GUI is the only good answer to a 
> drag-and-drop build-my-directory problem. I just see no good way to do this 
> with a simple CLI.

 Unless the CLI programs are used as tools by other gnunet programs (eg:
gui clients implemented with scripts). Not that I'd want the existing
CLI utilities to be relegated to only being used that way, but you know
what I mean. It's just a thought though, perhaps even that approach
is flawed.

> Easier to understand, maybe. Easier to use, definitely not. Also note that 
> gnunet-insert still can NOT do everything that the system may allow you to do 
> (like insert a file into your namespace of which you only have the file 
> identifier)
 I'd been wondering if that was the case. Your explanation that directories
could point to files in either way made me try to figure out how
gnunet-insert supported that, and I couldn't come up with anything.

>. gnunet-gtk actually can do that, but it currently does not allow 
> you to specify "N" and "T". While I'd like both tools to be able to do 
> everything, it'll take some more time to get there.

 Hey, simply having the namespaces and directories is a great step
forward already; I think as long as there's *some* way to do this stuff,
that's the main thing. Not that I don't care how complete everything
is, I'm just saying don't feel too pressured to get it all done straight
away. Or something. Ahem.

 Tomble