Lloyd Bryant wrote:
> >Christian Biere wrote:
> > > I wanted to sort the index by the modification time, so that browse host
> > > would show the newest files first. Maybe you want to implement this as
> >well?
> >Actually, it should be newest last, at least the indices to keep them
> >stable.
>
>
>Christian Biere wrote:
> > I wanted to sort the index by the modification time, so that browse host
> > would show the newest files first. Maybe you want to implement this as
>well?
>
>Actually, it should be newest last, at least the indices to keep them
>stable.
>The browse host output coul
>From: [EMAIL PROTECTED] (Raphael Manfredi)
>
>This is very neat, and it has been in my TODO for a long time...
>
>One comment on your patch though: it lacks comments. I understand the
>fix is simple, but when you read the code, nowhere does it say what it
>does.
>
>I'd summarize what you said
Quoting Lloyd Bryant <[EMAIL PROTECTED]> from ml.softs.gtk-gnutella.devel:
:The attached patch (to "src/core/matching.c") implements this by generating
:a random offset for the list of potential matches. This offset is added to
:the index (and wrapped around if it hits the end). This way, a que
Christian Biere wrote:
> I wanted to sort the index by the modification time, so that browse host
> would show the newest files first. Maybe you want to implement this as well?
Actually, it should be newest last, at least the indices to keep them stable.
The browse host output could of course be u
Lloyd Bryant wrote:
> Scenario: A host has a large number of files that match a particular
> query. As it stands, no matter how many times another nodes issues that
> query, the host in question will respond with the same 50 responses.
Excellent idea. I thought of something similar recently. I
Scenario: A host has a large number of files that match a particular query.
As it stands, no matter how many times another nodes issues that query,
the host in question will respond with the same 50 responses.
Ideally, if the user sees a large block of matching results from one node,
he coul
Raphael Manfredi wrote:
> In C, since there is no postfix "if" and "unless", there is no question
> about it. We must write that with a prefix "if", like:
>
> if (cond)
> return;
>
> if (cond)
> call();
>
> if (cond)
> a = b;
I don't
Quoting Christian Biere <[EMAIL PROTECTED]> from ml.softs.gtk-gnutella.devel:
:Alex Bennee wrote:
:> Maybe we should remove that rule and insist on braces all the time?
:
:Maybe.
I don't like to write:
if (cond) {
return;
}
or
if (cond) {
Alex Bennee wrote:
> > I really wish the syntax wouldn't allow both so that this was never a
> > question of "style".
> Much as I agree with you (I always use braces in my private code) our
> style guideline 6.2 does allow people to do the single line:
> if (condition)
> do_something();
I kn
On Sat, November 11, 2006 8:31, Christian Biere said:
> Lloyd Bryant wrote:
>> I found this section of code in "src/core/hosts.c":
>>
>> 149 if (count >= quick_connect_pool_size)
>> 150 if (dbg > 10) {
>> 151 g_message("host_timer - count %d >= pool size %d",
>> 152
Lloyd Bryant wrote:
> I found this section of code in "src/core/hosts.c":
>
> 149 if (count >= quick_connect_pool_size)
> 150 if (dbg > 10) {
> 151 g_message("host_timer - count %d >= pool size %d",
> 152 count, quick_connect_pool_size);
> 153 return
12 matches
Mail list logo
