- 18 Jun, 2019 4 commits
-
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
Spotted by: fgs & ubsan
-
- 17 Jun, 2019 5 commits
-
-
Poul-Henning Kamp authored
Instead of a timestamp per line, which makes diff(1) really hard to use, emit millisecond timestamps on separate "dT" lines, whenever time has changed since last timestamp.
-
Poul-Henning Kamp authored
so we apply it only where it makes most difference. The hard work done by: slink Closes: 2792
-
Dridi Boukelmoune authored
-
Andrew Wiik authored
-
Poul-Henning Kamp authored
-
- 13 Jun, 2019 3 commits
-
-
Federico G. Schwindt authored
-
Dridi Boukelmoune authored
That libtool bug on SunOS...
-
Dridi Boukelmoune authored
Spotted by VTEST.
-
- 12 Jun, 2019 15 commits
-
-
Dridi Boukelmoune authored
This would trigger the tautological-compare warning on a recent-enough Clang, and SunCC appears to complain as well. Reported by @daghf.
-
Dridi Boukelmoune authored
-
Geoff Simmons authored
Restructured so that: * 'Upgrading' is limited to work that has to be done to upgrade from a current deployment to the new version. * 'Changes' is a comprehensive, user-level description of changes and new features. Conflicts: doc/sphinx/whats-new/index.rst
-
Dridi Boukelmoune authored
Forcing one line per query can lead to very long lines for cases where we can't decompose OR-able individual queries. Where newline previously acted as a mere space between tokens, the backslash-newline sequence now fills that void.
-
Dridi Boukelmoune authored
Not a multiline VSL query, it's the record containing multiple lines.
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
This makes the following queries equivalent: vut -g request -q '*Error' -q 'BerespStatus >= 500' vut -g request -q ' *Error BerespStatus >= 500 ' vut -g request -q '(*Error) or (BerespStatus >= 500)' We now have two ways to express "compound" VSL queries, although this ultimately relies on multiline queries.
-
Dridi Boukelmoune authored
The two following queries now become equivalent: vut -g request -q ' # catch varnish errors *Error # catch backend errors BerespStatus >= 500 ' vut -g request -q '(*Error) or (BerespStatus >= 500)' It becomes interesting when we wish to capture transactions for different scenarios but would like to decompose them cleanly. Especially when the query of an individual scenario is rather complex and OR'ing everything manually would become cumbersome. This diff is better viewed with the --ignore-all-space flag.
-
Dridi Boukelmoune authored
We always add tokens in order, we don't need to check whether there was one present in the first place.
-
Dridi Boukelmoune authored
Now that we can have multiple lines in a query, it may come in handy to add a description of a query or its purpose.
-
Dridi Boukelmoune authored
Instead of treating it as a mere whitespace separator. As a result the lexer output looks like this: TOK_1, ..., TOK_N, EOI[, TOK_1, ..., TOK_N, EOI[...]] At this point though, only the first series of tokens is considered, in a single query mode that was already what we've had so far. It will also be the parser's job to ignore consecutive EOI tokens for "empty" queries.
-
Dridi Boukelmoune authored
-
Dridi Boukelmoune authored
We have a dedicated enum entry for that, and nothing prevents the caller from passing a negative value.
-
- 04 Jun, 2019 1 commit
-
-
Poul-Henning Kamp authored
-
- 03 Jun, 2019 11 commits
-
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
how vcc_expr actually works...
-
Poul-Henning Kamp authored
No methods are implemented yet.
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
get too confusing.
-
Poul-Henning Kamp authored
-
- 31 May, 2019 1 commit
-
-
Nils Goroll authored
background: When the ban lurker has finished working the bottom of the ban list, conceptually we mark all bans it has evaluated as completed and then remove the tail of the ban list which has no references any more. Yet, for efficiency, we first remove the tail and then mark only those bans completed, which we did not remove. Doing so depends on knowing where in the (obans) list of bans to be completed is the new tail of the bans list after pruning. 5dd54f83 was intended to solve this, but the fix was incomplete (and also unnecessarily complicated): For example when a duplicate ban was issued, ban_lurker_test_ban() could remove a ban from the obans list which later happens to become the new ban tail. We now - hopefully - solve the problem for real by properly cleaning the obans list when we prune the ban list. Fixes #3006 Fixes #2779 Fixes #2556 for real (5dd54f83 was incomplete)
-