- 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)
-
- 30 May, 2019 5 commits
-
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
- 29 May, 2019 4 commits
-
-
Nils Goroll authored
93d80501 made execution of ban_lurker_test_ban() conditional on bd != b, which effectively caused objects hanging off bans below request bans to not get tested against relevant bans. Because object bans (from the obans list) are being marked completed, the objects which were skipped would also be missed to get evaluated against the relevant bans at lookup time unless they were evaluated in request context. So, in effect, we would simply miss to test bans. Fixes #3007 Maybe related to #3006
-
Poul-Henning Kamp authored
This is not very elegant, but I wanted to maintain the same error messages for now. More to come.
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-