[.. status]
> So if those last two can be pushed onward this week I would like to
> branch once they are merged and the build farm gives them a mostly-blue
> pass rate.
+1
--
Kinkie
> Am 10.08.2014 20:25, schrieb Kinkie:
>> Hi,
>> what version of libtool are you using? What OS and version?
>>
>> On Sun, Aug 10, 2014 at 8:10 PM, Christian wrote:
>>> Hi,
>>>
>>> haveing Problems to build squid 3.4.6.
>>> Getting the
Hi,
what version of libtool are you using? What OS and version?
On Sun, Aug 10, 2014 at 8:10 PM, Christian wrote:
> Hi,
>
> haveing Problems to build squid 3.4.6.
> Getting the Following:
>
> [ 554s] In file included from LoadableModule.cc:10:
> [ 554s] ../libltdl/ltdl.h:106: error: 'LT_DLSYM
On Wed, Aug 6, 2014 at 2:10 PM, Fred Maranhão wrote:
> Hi,
>
> I just updated my squid in an debian stable box and after the update
> everything works fine. but I restart my squid and it not started.
>
> I detected a (very old) line in /etc/squid3/squid.conf with an error,
> but propably an warnin
Sounds good to me.
On Fri, Jul 25, 2014 at 6:37 AM, Amos Jeffries wrote:
> As luck would have it today is exactly 1 year since the first patch was
> held in trunk for 3.5 series release.
>
> Below is my current plan. Any objections please speak up.
>
>
> 1) Branching:
>
> I hope this can be done
> In all seriousness "haproxy-protocol" is probably the most correct
> descriptive right now. But I am trying hard to avoid naming a competitor
> in our most visible documentations.
How so? We are not a commercial product; I have no issues with naming
a competitor.
> I was thinking you had something funny along the lines of:
>
> * Traffic Envelope Annex protocol (TEA p'ot)
>
> We could also reply with HTTP 418 and close the connection on protocol
> failures.
iLike.
Willy, what do you think?
Kinkie
Committed to trunk r13482
On Sun, Jun 22, 2014 at 8:10 AM, Amos Jeffries wrote:
> On 4/06/2014 2:28 a.m., Kinkie wrote:
>> Hi,
>> the attached patch removes some cruft from libTrie (c bindings and
>> .cci files). No functional changes apart from that.
>>
>
>
Amos already +1-ed the patch, I have no insights to add so unless
someone speaks up real fast, we proceed.
On Tue, Jun 24, 2014 at 9:29 PM, Alex Rousskov
wrote:
> On 06/24/2014 12:55 PM, Kinkie wrote:
>
>
>> Did you run coadvisor and polygraph against it?
>
> Co-Advisor do
We can't know except by hammering it.
Did you run coadvisor and polygraph against it?
If not, and if the branch is public, it's trivial tor un them against
it now (thanks TMF, thanks Pavel!). It doesn't guarantee to catch all
cases, but at least it should raise confidence.
On Tue, Jun 24, 2014 at
be useful to have a chance to log the timing of certain key
moments in a request's processing path. Things like accept, end of
slow acl matching, end of dns resolution(s), connected to uplink, and
so on. This could help administrators identify congestion issues in
their infrastructure.
Kinkie
LGTM, only:
Are the first two columns really necessary in the statement
::Parser::Tokenizer tok
?
On Sun, Jun 15, 2014 at 8:05 AM, Amos Jeffries wrote:
> Update the service_name global to an SBuf and use Tokenizer to validate
> the -n argument is a pure alphanumeric.
>
> Amos
--
Francesc
I agree on the objective, and while this is not the solution it's a a
workaround; +1 but if you haven't already please add a TODO mentioning
the eventual refcount objective.
On Sat, Jun 14, 2014 at 3:21 AM, Amos Jeffries wrote:
> On 14/06/2014 7:57 a.m., Alex Rousskov wrote:
>> On 04/25/2014 01
On Fri, Jun 13, 2014 at 4:50 PM, Alex Rousskov
wrote:
> On 06/11/2014 04:43 PM, Kinkie wrote:
>> level-compact-trie: the mean time is 11 sec; all runs take between
>> 10.782 and 11.354 secs; 18 Mb of core used
>
>> full-trie: mean is 7.5 secs +- 0.2secs; 85 Mb of core.
>
Hi,
I've done some benchmarking, here are the results so far:
The proposal I'm suggesting for dstdomain acl is at
lp:~kinkie/squid/flexitrie . It uses the level-compact trie approach
I've described in this thread (NOT a Patricia trie). As a comparison,
lp:~kinkie/squid/domai
> depend on the port value!).
How about "listen"? It's consistent with apache, clear, and protocol-neutral.
Kinkie
Sounds like a good idea to me.
On Mon, Jun 9, 2014 at 7:07 AM, Amos Jeffries wrote:
> Hi,
>
> I propose that we combine the http_port and https_port directives into
> a single directive called "port" with the old names as aliases and an
> option to select between TCP and TLS transport protocol.
Hi,
I'd extend the window to one calendar week, but apart from that it
all seems very reasonable.
On Sun, Jun 8, 2014 at 1:05 PM, Amos Jeffries wrote:
> While discussing in IRC how we could improve our procedures and reduce
> audit problems we hit on the issue of wide-ranging code cleanup or A
How about enabling this only for trunk (should be possible to detect
it by the release tag) and not for beta and stable releases? This
would make it no-maintenance and active by default for people who
should know what they're doing, while not having less clueful users
worry.
On Wed, Jun 4, 2014 at
14 at 10:12 PM, Alex Rousskov
wrote:
> On 06/03/2014 08:40 AM, Kinkie wrote:
>> Hi all,
>> as an experiment and to encourage some discussion I prepared an
>> alternate implementation of TrieNode which uses a std::map instead of
>> an array to store a node's children.
&
On Tue, Jun 3, 2014 at 5:52 PM, Amos Jeffries wrote:
> On 4/06/2014 2:40 a.m., Kinkie wrote:
>> Hi all,
>> as an experiment and to encourage some discussion I prepared an
>> alternate implementation of TrieNode which uses a std::map instead of
>> an array to store a
Hi all,
as an experiment and to encourage some discussion I prepared an
alternate implementation of TrieNode which uses a std::map instead of
an array to store a node's children.
The expected result is a worst case performance degradation on insert
and delete from O(N) to O(N log R) where N is t
Hi,
the attached patch removes some cruft from libTrie (c bindings and
.cci files). No functional changes apart from that.
--
Francesco
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: kin...@squid-cache.org-20140603115956-q46uuszw534vp55i
# target_branch: http://bzr.squid-cac
It's in there, it's working, I am OK with this going in; also to trunk
and from there to parser-ng.
+1
On Tue, Jun 3, 2014 at 4:22 PM, Amos Jeffries wrote:
> On 4/06/2014 1:08 a.m., Alex Rousskov wrote:
>> On 06/03/2014 04:46 AM, Amos Jeffries wrote:
>>
>>> This replaces the SBuf::trim() to use
Hi,
this patch extracts the stdint compat to a compat/xstdint.h header,
and references that from strtoll.c and Tokenizer.cc;
Full farm tested, it introduces no regressions.
--
Francesco
=== modified file 'compat/Makefile.am'
--- compat/Makefile.am 2014-04-21 08:27:21 +
+++ compat/Makef
Hi,
adapting the current implementation to the "extra optional
parameter" was rather trivial; please consider the attached patch,
whose bulk is unit tests and (certainly improvable) documentation.
On Mon, Jun 2, 2014 at 8:07 PM, Alex Rousskov
wrote:
> On 06/02/2014 11:27 AM,
Hi Alex,
welcome back!
On to the meat:
>> +Parser::Tokenizer::token(SBuf &returnedToken, const CharacterSet
>> &delimiters)
>> +{
>> +SBuf savebuf(buf_);
>> +SBuf retval;
>> +SBuf::size_type tokenLen = 0;
>
> This code has changed since the patch was posted for review, but please
> d
Good. Setting off to merge.
Thanks!
On Sun, Jun 1, 2014 at 4:13 PM, Amos Jeffries wrote:
> On 30/05/2014 9:56 p.m., Kinkie wrote:
>> Hi,
>> here's the patch for merging the sbuf-tokenizer branch. Includes the
>> fixes to Parser::Tokenizer::int64 method (via reimple
Hi,
here's the patch for merging the sbuf-tokenizer branch. Includes the
fixes to Parser::Tokenizer::int64 method (via reimplementation of
strtoll to account for SBufs sharing MemBlobs).
Please review.
--
Kinkie
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: kin...@
LGTM. +1.
On Fri, May 9, 2014 at 9:31 PM, Amos Jeffries wrote:
> On 28/04/2014 2:39 p.m., Amos Jeffries wrote:
>> On 28/04/2014 3:51 a.m., Kinkie wrote:
>>> On Sun, Apr 27, 2014 at 4:52 PM, Amos Jeffries wrote:
>>>> This continues the bug 1961 redesi
On Sun, May 11, 2014 at 7:16 PM, Amos Jeffries wrote:
> This patch adds a Comm::Write API for accepting SBuf output buffers.
[...]
> To get it in action and tested the main tunnel.cc I/O
> "data pipe" buffers are converted to SBuf. Initial testing with a few
> hundred CONNECT requests in real tra
Hi all,
the attached patch integrates the delayer helper with Squid's build
system; it's build- and run-tested.
On Sun, May 11, 2014 at 4:11 PM, Kinkie wrote:
> On Sun, May 11, 2014 at 11:44 AM, Amos Jeffries wrote:
>> On 11/05/2014 9:17 a.m., Kinkie wrote:
>>> On
On Sun, May 11, 2014 at 11:44 AM, Amos Jeffries wrote:
> On 11/05/2014 9:17 a.m., Kinkie wrote:
>> On Fri, May 9, 2014 at 3:35 PM, Amos Jeffries wrote:
>>> On 5/09/2013 6:23 a.m., Kinkie wrote:
>>>> Hi all,
>>>> I've developed a new external_acl h
On Fri, May 9, 2014 at 3:35 PM, Amos Jeffries wrote:
> On 5/09/2013 6:23 a.m., Kinkie wrote:
>> Hi all,
>> I've developed a new external_acl helper. Its purpose is to add an
>> artificial delay to requests flowing through squid. It is orthogonal
>> to delay
http://www.boutell.com/newfaq/misc/urllength.html
Squid defines MAX_URL at 8KiB (in src/defines.h)
On Tue, Apr 29, 2014 at 4:40 PM, Eliezer Croitoru wrote:
> I am working on external_acl helper and I want to work with a DB of urls and
> domains.
>
> I know that there is a limit for domains size
On Sun, Apr 27, 2014 at 4:52 PM, Amos Jeffries wrote:
> This continues the bug 1961 redesign of URL handling.
Hi,
+SBuf tmp = checklist->request->url.userInfo();
+// NOTE: unescape works in-place and may decrease the c-string
length, never increase.
+rfc1738_unescape(const_cast(tmp.c
m quite curious about where the third argument to
ftruncate comes from, and why it differs in the two runs.
A possible alternative: since ftruncate is used to extend the shm
area, what bout simply writing to it to extend it? Would it work in
your opinion?
On Mon, Apr 14, 2014 at 9:22 PM, Alex
_test kinkie$ ./shm_test 66584
start
fd: 3
sz: 66584
mmap
mem at 0x10dd9b000
ok!
--
testRock:
mini:squid kinkie$ gdb-apple ./src/tests/testRock
[...]
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0068
0x7fff92f
yes.
But IMO wordlist and strList must die (eventually).
On Tue, Apr 8, 2014 at 4:17 PM, Amos Jeffries wrote:
> On 8/04/2014 10:30 p.m., Kinkie wrote:
>> Removing squis-dwv from cc, I am on mobile and the HTML encoding would get
>> the message rejected anyway.
>>
>>
On Tue, Apr 8, 2014 at 5:45 AM, Amos Jeffries wrote:
>
> Add mk-sbuf-strings.awk script to produce a global array of SBuf for the
> string objects of registered methods. This can be re-used to convert
> other enum name arrays as we go forward.
>
> Use an SBuf to store unknown method names "image".
Compiles, builds and runs. +1.
Unfortunately, it doesn't fix trunk's crashes, but it's a good step ahead IMO.
On Wed, Apr 2, 2014 at 1:03 PM, Amos Jeffries wrote:
> This removes the needless Comm::ConnectionList* parameter to the PSC
> (Peer Select callback) function.
>
> The callee state object
lback (q=0x24eec80, q@entry=0x24f5370,
error=error@entry=0x0) at dns_internal.cc:1127
I'm currently investigating more in depth.
On Wed, Mar 26, 2014 at 8:32 AM, Kinkie wrote:
> Hi,
> I think I have isolated the changelet in FwdState::connectionList.
> However WHAT in that change
Is there any progress regarding the random coredumps related to
> std::vector migration?
>
> Best,
> Niki
>
> On Mon, Mar 17, 2014 at 6:41 PM, Kinkie wrote:
>> Yes, I will.
>>
>> On Mon, Mar 17, 2014 at 5:24 PM, Alex Rousskov
>> wrote:
>>> Hel
Hi Eliezer,
the dependencies look legitimate to me.
The only way I can see to reduce them is to split the package in two,
squid and squid-helpers. This could help remove perl-*, shadow-utils
and possibly krb5* from the dependencies of the main squid package.
On Thu, Mar 20, 2014 at 2:59 AM, E
Hi,
the whole train has now been merge in trunk r13318.
On Tue, Mar 18, 2014 at 11:11 AM, Kinkie wrote:
>> I'm favour of this and have been for some time. However the patch does
>> not go far eonough to do what this submission claims.
>>
>> 1) do_mallinfo i
> I'm favour of this and have been for some time. However the patch does
> not go far eonough to do what this submission claims.
>
> 1) do_mallinfo is removed in tools.cc but the globals.h and main.cc
> parts of it are not removed.
Removed.
> 2) The high_memory_warning directive now depends uniqu
Hi,
helpers/basic_auth/NCSA/crypt_md5.cc
there's an XXX hinting at some uncertainty. Is it stale or is there some doubts?
helpers/basic_auth/RADIUS/basic_radius_auth.cc and elsewhere
+#if HAVE_NETTLE_MD5_H
+#include
+#endif
I know that the conventions mandate to #if-guard this include, but
since
deleted object is
> still being used. For example:
>
> template
> size_t
> Vector::size() const
> {
> assert(!deleted);
> return count;
> }
>
> If one of those asserts is triggered, we would be closer to solving this
> mystery.
>
>
> Kinkie, if yo
:~kinkie/squid/sbrk-removal feature-branch.
Thanks
--
Francesco
=== modified file 'acinclude/os-deps.m4'
--- acinclude/os-deps.m4 2013-10-04 12:15:52 +
+++ acinclude/os-deps.m4 2014-03-17 14:27:13 +
@@ -197,26 +197,6 @@
])
-dnl checks that the system provides struct ma
Hi,
after removing MEM_GEN_TRACE, XMALLOC_DEBUG and XMALLOC_TRACE, the file
lib/malloc_trace.cc is empty and useless. This patch removes it.
--
Francesco
=== modified file 'lib/Makefile.am'
--- lib/Makefile.am 2014-01-08 04:29:04 +
+++ lib/Makefile.am 2014-03-17 11:20:35 +
@@ -58,7
Hi,
this patch removes code depending on MEM_GEN_TRACE. I haven't seen this
code used in years, like all other memory-management debug code.
--
Francesco
=== modified file 'compat/xalloc.cc'
--- compat/xalloc.cc 2014-03-17 11:04:57 +
+++ compat/xalloc.cc 2014-03-17 11:18:01 +
@@ -89
Hi,
the attached patch removes code conditional on XMALLOC_DEBUG - a followup
to XMALLOC_TRACE removal.
--
Francesco
=== modified file 'compat/xalloc.cc'
--- compat/xalloc.cc 2014-03-16 12:44:59 +
+++ compat/xalloc.cc 2014-03-17 11:04:57 +
@@ -86,9 +86,6 @@
exit(1);
}
Hi all,
the attached patch removes all references to xmalloc-trace and sbrk.
The former is very rarely used, valgrind is preferred to trace allocations.
The latter is basically useless to detect memory usage on modern OSes which
use other means than brk(2) to obtain memory pages for the heap; it
Hi all,
some of these values are really orthogonal in scope, so I'd love to
see them logged independently. Doing so would however change the
standard logging format, so this proposal is the second best choice
and I support it.
On Sun, Mar 9, 2014 at 6:18 AM, Alex Rousskov
wrote:
> On 03/07/2014
ide the header registry,
> setting its field type to generic String, and adding it to the
> connection-headers mask.
>
> (B) the putRange() can detect multiples and set the range to a special
> (empty header?) value that gets stripped at the end of parsing. In order
> not to reject even counts of Range headers while allowing odd-counts.
>
>
>
> I kind of favour (A), but we may end up having to do both eventually
> anyway to enforce correct Range compliance.
(A) looks better to me.
(B) as expressed doesn't look right to me. I don't know what the
standard says; in my opinion it's not worth the (code and
computational) effort needed to try and reconcile broken Range
requests; the safest response is to drop them all in case of
duplicates, and I'd suggest we do just that.
--
Kinkie
On Tue, Feb 18, 2014 at 5:58 PM, Alex Rousskov
wrote:
> On 02/17/2014 11:16 PM, Francesco wrote:
>>
>> On 18 Feb 2014, at 00:44, Alex Rousskov
>> wrote:
>>
>>> On 02/17/2014 02:46 PM, Kinkie wrote:
>>>
>>>> the attached patch aims
Ok then :)
On Mon, Feb 17, 2014 at 9:38 AM, Amos Jeffries wrote:
> On 17/02/2014 8:34 p.m., Francesco Chemolli wrote:
>>
>> On 17 Feb 2014, at 08:03, Amos Jeffries wrote:
>>
>>> On 15/02/2014 6:47 a.m., Francesco Chemolli wrote:
On 14 Feb 2014, at 13:24, Amos Jeffries wrote:
ache.log.
Is it actually used anywhere or is it just something we could get rid
of without regret?
Thanks.
--
Kinkie
Merged.
On Wed, Feb 12, 2014 at 2:06 AM, Amos Jeffries wrote:
> On 2014-02-12 04:45, Kinkie wrote:
>>
>> Hi,
>> the attached patch is the missing piece of Vector refactoring: it
>> replaces users of Stack with std::stack (or std::vector, in one case
>> where i
o not use it
>
> * custom headers provided by Squid:
> - omit wrappers
> - always include with ""
> - use full path (only src/ prefix may be omitted)
>
>
> Also, for now restricting ourselves to the C++98 set of headers since we
> have not made C++11 support mandatory yet.
Hi,
perfectly in line with what I had in mind. +1 from me.
--
Kinkie
re design ideas before going for an implementation attempt.
Thanks.
--
Kinkie
=== modified file 'src/HttpHeader.cc'
--- src/HttpHeader.cc 2014-02-10 15:07:49 +
+++ src/HttpHeader.cc 2014-02-11 16:13:35 +
@@ -410,99 +410,115 @@ HttpHeader::HttpHeader(const ht
less-readable error message when the
build eventually fails.
What do you think?
--
Kinkie
worked on (e.g. the parser-ng work)
What's your thoughts?
--
Kinkie
On Mon, Feb 10, 2014 at 5:16 PM, Alex Rousskov
wrote:
> On 02/10/2014 02:20 AM, Kinkie wrote:
>>> The kind of cast appears to be wrong here: Const_cast<> is normally used
>>> to remove const, not add it. It is not used to change the type.
>>
>> It is cur
> The kind of cast appears to be wrong here: Const_cast<> is normally used
> to remove const, not add it. It is not used to change the type.
It is currently a c-style cast.
Attributes is built over push_back(), so the only way to cleanly make
it const would be to copy it after it's built.
Without
On Sun, Feb 9, 2014 at 2:08 AM, Alex Rousskov
wrote:
> On 02/08/2014 03:44 PM, Kinkie wrote:
>
>> And I don't see how to reliably get to vector[0] in pre-11 STL. Do you
>> have any clue?
>
> My understanding is that you just do &vector_object[0], but I have not
&
On Fri, Feb 7, 2014 at 6:32 AM, Alex Rousskov
wrote:
> On 02/04/2014 12:57 PM, Kinkie wrote:
>> On Sun, Feb 2, 2014 at 10:42 PM, Amos Jeffries wrote:
>>> On 2014-02-03 08:06, Kinkie wrote:
>>>>
>>>> Hi,
>>>> the attached patch (merge from
On 01/30/2014 12:14 PM, Kinkie wrote:
>>> Ok, here's some numbers (same testing methodology as before)
>>>
>>> Trunk: mean RPS (CPU time)
>>> 10029.11 (996.661872)
>>> 9786.60 (1021.695007)
>>> 10116.93 (988.395665)
>>> 9958.71
Hi,
Apparently my checked-out tree had some problems. I've performed a
follow-up commit with the actual changes.
On Thu, Feb 6, 2014 at 11:53 AM, Amos Jeffries wrote:
> On 6/02/2014 9:54 p.m., Kinkie wrote:
>> Hi,
>> Maybe there's some issue with launchpad mirr
Doh! you are right.
For some reason I botched the commit in r13257. I've now committed the
change as r13258. Please try it.
On Thu, Feb 6, 2014 at 10:25 AM, Nikolai Gorchilov wrote:
> On Thu, Feb 6, 2014 at 10:54 AM, Kinkie wrote:
>>
>> Hi,
>> Maybe there's some
ified files -
> http://bazaar.launchpad.net/~squid/squid/trunk/revision/13257
>
> On Thu, Feb 6, 2014 at 8:24 AM, Kinkie wrote:
>> It' the tip, a bzr pull should get it for you
>>
>> On Feb 6, 2014 2:45 AM, "Nikolai Gorchilov" wrote:
>>>
On Tue, Feb 4, 2014 at 2:17 AM, Alex Rousskov
wrote:
> On 02/02/2014 02:42 PM, Amos Jeffries wrote:
>
>> in src/HttpHdrRange.cc
>>
>> * This pattern happens several times throughout this patch:
>> -while (!specs.empty())
>> -delete specs.pop_back();
>> +whil
ed or not; the issue is
present regardless.
--
Kinkie
On Thu, Jan 30, 2014 at 12:39 AM, Alex Rousskov
wrote:
> On 01/29/2014 02:32 PM, Kinkie wrote:
>> On Wed, Jan 29, 2014 at 7:52 PM, Alex Rousskov wrote:
>>> On 01/29/2014 07:08 AM, Kinkie wrote:
>
>> (in a trunk checkout)
>> bzr diff -r lp:/squid/squid/vector-to-s
On Wed, Jan 29, 2014 at 7:52 PM, Alex Rousskov
wrote:
> On 01/29/2014 07:08 AM, Kinkie wrote:
>
>>Amos has asked me over IRC to investigate any performance
>> differences between Vector and std::vector. To do that, I've
>> implemented astd::vector-based impleme
access some cachemgr
page. Squid will send all the data, but not release the TCP
connection. Cachemgr will sit there waiting for a few seconds
(~30-ish), then it will complete and exit.
--
/kinkie
dware over the loopback interface.
- immediately after ab exits, collect counters (mgr:counters)
numbers (for trunk / stdvector)
- mean response time: 1.032/1.060ms
- req/sec: 9685/9430
- cpu_time: 102.878167/106.013725
--
/kinkie
s loosely FHS, but it's readonly and the only writeable
parts (which end up including many configurations) are in /tmp.
But this brings an entirely different question: how much are we
willing to invest in order to support those kind of systems?
--
/kinkie
nspecified paths to something less hardcoded
than now. The general structure we use is consistent with GNU
guidelines, and I would recommend not to change that. At the same
time, having a "-${servicename}" added to file name defaults when
servicename is specified by the admin won't hurt .
--
/kinkie
nd don't really need checked
> out copies of the sources of each branch on the server
>
> If server side checkouts is needed then it's easily created separately
>
>bzr checkout --lightweight /path/to/shared/repo/branch
>
> --lightweight is entierly optional, and depends on what you want to use
> the checkout for.
>
> Regards
> Henrik
>
--
/kinkie
On Tue, Jan 21, 2014 at 2:31 AM, Amos Jeffries wrote:
> On 2014-01-21 12:47, Alex Rousskov wrote:
>>
>> On 01/20/2014 02:28 PM, Amos Jeffries wrote:
>>>
>>> On 2014-01-21 08:05, Alex Rousskov wrote:
>>>>
>>>> On 01/20/2014 08:15 AM, Ki
Hi all,
the attached patch is an attempt (build-tested) to rely more on
nullptr in place of NULL.
It takes from the current implementation, it is just a bit more
forceful in using nullptr if available.
--
/kinkie
=== modified file 'compat/types.h'
--- compat/types.h 2012-10-0
This ensures
compatibility but should also allow us to detect gcc-isms and fail if
we by mistake use one.
What do you think?
On Wed, Jan 15, 2014 at 3:42 PM, Kinkie wrote:
> I'm trying a build downgrading the icc from 14.0 to 13.1 (which used
> to work). Let's see.
>
>
> On
5::__gthrw_pthread_cancel(unsigned
>>> long)'
>>> AclRegs.o:(.rodata+0x0): undefined reference to
>>> `_INTERNAL_20___src_AclRegs_cc_a4e5ab95::__gthrw_pthread_cancel(unsigned
>>> long)'
>>
>> It seems to be explained by this discussion from 2010:
>> http://software.intel.com/en-us/forums/topic/289533
>>
>> So perhapse the ICC version and GCC versions installed headers are clashing
>> yet again?
>>
>> Amos
>
--
/kinkie
Tested and committed.
Thanks!
On Thu, Jan 9, 2014 at 11:17 PM, Amos Jeffries wrote:
> On 2014-01-10 04:14, Kinkie wrote:
>>
>> It's been there forever, and a build with the most recent clang
>> version is failing on it:
>>
>> store_repl_heap.cc:224
>
done.
On Fri, Jan 10, 2014 at 12:53 AM, Amos Jeffries wrote:
> On 9/01/2014 9:57 p.m., Kinkie wrote:
>> Hi,
>> Coverity detected a possible division by zero in
>> src/format/Format.cc line 500, on a Token->divisor.
>> The defect is a false positive as that
eap_empty(h->theHeap))
but before doing that I'd like to make sure I didn't misunderstand.
Thanks
--
/kinkie
in the default
constructor.
Attached patch does just that.
--
/kinkie
=== modified file 'src/format/Token.h'
--- src/format/Token.h 2013-02-11 23:11:12 +
+++ src/format/Token.h 2014-01-09 08:49:21 +
@@ -8,73 +8,73 @@
* Squid configuration allows users to define cust
27;s due to the basic
> dact that my Laptop was not suppose to be used with UBUNTU and was supposed
> to be locked only for SLED, windows and RH.
>
> I have installed OpenSUSE on my XEON server and it is building fine and also
> running.
[...]
/kinkie
Hi,
here's a merge proposal for Parser::Tokenizer, an implementation of
the API suggested by Alex.
The feature branch is available at lp:~squid/squid/sbuf-tokenizer
--
/kinkie
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: kin...@squid-cache.org-201401062
tructors.
>
> +1 once those are fixed.
Fixed and merged.
Thanks.
--
/kinkie
Hi,
the attached patch expands on the already-merged CharacterSet, adding:
- operator+
- addRange
- range-based constructor
- a number of predefined sets, mostly taken from the HTTP specs
- unit test
It's a candidate for merging to trunk.
--
/kinkie
# Bazaar merge directive for
.1.2.
> Does RHEL have the gcc44 package ?
I guess so: I can see the SRPM for gcc 4.4.7 in Red Hat's public FTP.
That's a relief. Thanks for pointing things out!
Next questions:
do we want to require c++0x sometime before requiring c++11 or do we
make only one big leap?
And do we want to keep gcc 4.1 around on our CentOS 5 build nodes to
notice if any c++0x sneaks in?
--
/kinkie
here is mostly convenience, I can work around it.
However I am annoyed; we will need to make decision and this fact
complicates things.
--
/kinkie
> Looks good to me, thank you. There is only one bug (listed first below).
> The rest is minor polishing:
Thanks
>> +
>> std::copy_if(src.chars_.begin(),src.chars_.end(),chars_.begin(),isNonZero);
>
> copy_if does not advance the output iterator when the predicate returns
> false, so you will
Hi all,
here's the updated patch.
Thanks
On Tue, Dec 17, 2013 at 6:04 PM, Kinkie wrote:
> On Tue, Dec 17, 2013 at 6:06 AM, Alex Rousskov
> wrote:
>> On 12/16/2013 03:36 PM, Alex Rousskov wrote:
>>>> Rewrite the += operator loop to simply
>>>> this-&
t; I think the above is still valid though.
>
> but I cannot find a suitable algorithm. If you cannot either, just use
> add() calls in an explicit loop.
std::copy_if is perfect for the job; using that.
--
/kinkie
sition-to-character
mapping method (currently we only map character-to-position). This in
turn would mean using a position-based loop and operator[] instead of
an iterator. Is it worth it for something which is essentially a dumb
copy on a probably-not-too-used operation?
Note: I'm not resisting the change. Just pointing to the drawbacks I
see so that an informed decision can be made :)
--
/kinkie
On Mon, Dec 16, 2013 at 5:40 PM, Alex Rousskov
wrote:
> On 12/15/2013 04:54 AM, Kinkie wrote:
>
>> attached patch is from branch lp:~squid/squid/characterset/
>
>
>> +std::vector chars_; //std::vector is optimized
>
> According to STL documentation for std::vec
aming convention compliant (that's right,
they are modeled after std::string). I'm fine with changing them as a
follow-up commit if this is the collegial decision; I'd avoid do to it
as part of this merge.
--
/kinkie
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: ki
1 - 100 of 1082 matches
Mail list logo
