Hiya,
I've just updated to the latest squid-2.6 source and have found the
code isn't building. Any ideas?
[EMAIL PROTECTED]:~/work/squid/squid-2.6$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefi
On Tue, 2006-05-23 at 21:40 +0200, Henrik Nordstrom wrote:
> tis 2006-05-23 klockan 15:01 -0400 skrev Nick Lewycky:
>
> > If possible, it should store the HttpHeaderEntry objects themselves
> > instead of pointers to them. Done properly, there shouldn't be any need
> > for a destructor at all.
>
tis 2006-05-23 klockan 21:40 +0200 skrev Henrik Nordstrom:
> In this case there was a const barrier which needed to be penetrated,
> triggering all of this.. Probably a design error somewhere (missing
> write access method, or the code in question executing in the wrong
> context).
The code in qu
tis 2006-05-23 klockan 11:08 -0300 skrev Gonzalo Arana:
> I would like to have a somehwat explicit cache level. Alternatives to this
> is:
> a) expand %| to some string: discarded.
> b) helper tells squid about format specification & cache levels upon startup.
> c) squid notifies helper at star
tis 2006-05-23 klockan 15:01 -0400 skrev Nick Lewycky:
> If possible, it should store the HttpHeaderEntry objects themselves
> instead of pointers to them. Done properly, there shouldn't be any need
> for a destructor at all.
In this case there was a const barrier which needed to be penetrated,
t
Henrik Nordstrom wrote:
> tis 2006-05-23 klockan 13:22 -0400 skrev Nick Lewycky:
>
>
>>It's a temporary. pe->getReply()->head will get casted into the
>>HttpHeader, used to call putStr(...), then its life is over, at which
>>point the C++ implementation is free to destroy it at its leisure (some
tis 2006-05-23 klockan 13:22 -0400 skrev Nick Lewycky:
> It's a temporary. pe->getReply()->head will get casted into the
> HttpHeader, used to call putStr(...), then its life is over, at which
> point the C++ implementation is free to destroy it at its leisure (some
> impl's do it after the end of
Henrik Nordstrom wrote:
> Hi Robert,
>
> can you (or someone else who groks C++ casts) please explain why this
> happened?
>
> http://www.squid-cache.org/Versions/v3/3.0/changesets/10249.patch
>
>
> store.cc:712
>
> ((HttpHeader) pe->getReply()->header).putStr(HDR_VARY, vary.buf());
It'
Hi Robert,
can you (or someone else who groks C++ casts) please explain why this
happened?
http://www.squid-cache.org/Versions/v3/3.0/changesets/10249.patch
store.cc:712
((HttpHeader) pe->getReply()->header).putStr(HDR_VARY, vary.buf());
called the ~HttpHeader destructor, which made a
ons 2006-05-24 klockan 00:43 +1200 skrev Reuben Farrelly:
> Hi Henrik,
>
> Would you be able to set up a cron job to create 2.6 snapshots, the same as
> we
> do for 3.0?
As soon as the merge frenzy is over there will be a PRE release,
snapshots, version page, releae notes etc.. all the things y
Just to summ up:
Letting the helper do random combining/reordering leads into
highly-ineffitient lookup algorithm, and apparently it is not needed.
Cache level could structured in a 'path'-alike, or disjoint. Disjoint
solves reordering issue in an efficient manner.
Having each token a member o
Hi,
Adrian asked me to check the connection pinning code in HEAD (as we're
actually using it on our network), and I can see a couple of problems.
I've attached a diff that should fix them.
The first part of this patch will make sure we only mark a requset with the
pinned and auth flags if th
mån 2006-05-22 klockan 23:17 -0300 skrev Gonzalo Arana:
> Ah, I see now. As long as the helper & squid follow "lower level
> number, higher priority" policy, there is no need for cache
> invalidation.
Correct.
> > To be able to make sane lookup structures it is very beneficial if the
> > data c
tis 2006-05-23 klockan 04:03 -0400 skrev Tsantilas Christos:
> icap-2.6 branch already exists in sourceforge cvs repository.
Excellent!
Regards
Henrik
signature.asc
Description: Detta är en digitalt signerad meddelandedel
Hi all,
> tor 2006-05-18 klockan 01:59 +0200 skrev [EMAIL PROTECTED]:
>
>> Just a question, (i've been quite busy those weeks to follow this ml),
>> is the
>> ICAP support already merged ? I'd like to help Christos if not
>
icap-2.6 branch already exists in sourceforge cvs repository.
Looks that m
15 matches
Mail list logo
