1. 12 11月, 2018 3 次提交
  2. 02 11月, 2018 3 次提交
  3. 22 10月, 2018 2 次提交
  4. 13 10月, 2018 1 次提交
    • A
      Bugfix: Math function checking · 0c845aa2
      Alex Ozdemir 提交于
      We had config machinery that determined which math functions are
      available in libc. If a c math function was missing on the host system,
      then the corresponding jq function would be removed from the source,
      enabling the build to proceed anyway. The detection machinery was broken
      in a subtle way, as was shown after glibc updated to 2.27, dropping the
      `pow10` function. This caused compilation to fail.
      The essential problem was that we detected whether a math function was
      available by compiling and linking a small program evaluating that
      function on constants. However, since gcc's optimization machinery has
      special knowledge of some math functions (e.g. `pow10`), it can
      optimize them away, even if they don't exist in the library and are not
      linkable. That is, the following example compiles and links against
      glibc 2.27, even though `pow10` has been removed:
      int main () {
        printf("%f", pow10(0.5));
        return 0;
      On the other hand, this program does not link:
      int main () {
        double f;
        printf("%f", &f);
        printf("%f", pow10(f));
        return 0;
      In the first program the call to `pow10` can be optimized away as a
      constant expression. This requires GCC to know about `pow10` (which it
      does!), but it does not require `pow10` to be in the library (and
      actually linkable).
      The solution is to use autoconf's machinery for detecting function
      presence, instead of our own (buggy) machinery. This has the added
      benefit of simplifying the code.
      The bug was reported in issue #1659
  5. 31 8月, 2018 2 次提交
  6. 18 8月, 2018 2 次提交
    • W
      Restore JV_PRINT_COLOUR as an alias · 46d1ce26
      William Langford 提交于
      JV_PRINT_COLOUR was part of the public libjq headers and was removed as
      part of 2d05b547. While JV_PRINT_COLOR is definitely the preferred
      spelling this side of the pond, we shouldn't just remove otherwise
      exposed enum values.
    • W
      Fix destructuring alternation · 0673dee1
      William Langford 提交于
      Attempting to use the existing FORK_OPT opcode resulted in difficulty
      knowing when to pop an error message off the stack and when not to. This
      commit makes DESTRUCTURE_ALT a real opcode that is identical to
      FORK_OPT, except for never pushing the error message onto the stack when
      continuing from an error backtrack.
      Some small changes were necessary to the DUP/POP behavior surrounding
      destructuring to accomodate this.
  7. 17 8月, 2018 1 次提交
  8. 12 5月, 2018 1 次提交
  9. 07 3月, 2018 2 次提交
  10. 02 3月, 2018 1 次提交
  11. 24 2月, 2018 1 次提交
  12. 21 2月, 2018 4 次提交
  13. 05 1月, 2018 1 次提交
  14. 13 12月, 2017 1 次提交
  15. 12 12月, 2017 3 次提交
    • N
      Update AUTHORS · 8eff744e
      Nicolas Williams 提交于
    • D
      Added rawfile · b4742c12
      David Fetter 提交于
      In passing, clean remnants of argfile from slurpfile docs.
    • N
      Revert "reduce: handle empty updates (fix #1313)" · 9a4576e7
      Nicolas Williams 提交于
      This reverts commit e24af3c7.
      While the semantics are desirable, there is no way to implement them
      efficiently.  The reason is that in order to handle backtracking (empty)
      from the state update expression, we have to retain a reference to the
      reduction state value in order to restore it upon backtracking.
      Retaining a reference to the reduction state kills performance by
      causing lots of additional memory allocations and garbage because the
      input to the update expression will always have at least two references,
      thus no changes to it can be done in-place, and all changes end up being
      CoW changes.
      Avoiding this is the very reason for the LOADVN instruction (leaving
      `null` in the variable loaded from).
  16. 11 12月, 2017 1 次提交
  17. 05 12月, 2017 2 次提交
  18. 30 11月, 2017 2 次提交
    • W
      Actually fix the strptime tests · 0c9eaced
      William Langford 提交于
      This has been a complicated issue to fix for a number of reasons.
      The core of it is that the behavior is different between different
      versions of macOS, some of which set possible-but-incorrect values.
      This commit addresses the issue by always using our computation for
      tm_wday and tm_yday on macOS. As a side-effect, strptime format
      strings that specify %u and %j will no longer work on macOS.
    • E
      Keep object keys in parsing order in `tostream` output · 476b3677
      Eric Bréchemier 提交于
      As noted by @nicowilliams, `tostream` used `keys`,
      which sorts the keys in alphabetical order, instead
      of `keys_unsorted`, which preserves the parsing order.
      Fixes #1541.
  19. 28 11月, 2017 3 次提交
  20. 23 11月, 2017 2 次提交
  21. 19 6月, 2017 1 次提交
  22. 22 5月, 2017 1 次提交
    • N
      Deal with strptime() on OS X and *BSD (fix #1415) · c538237f
      Nicolas Williams 提交于
      strptime() on OS X and *BSDs (reputedly) does not set tm_wday and
      tm_yday unless corresponding %U and %j format specifiers were used.
      That can be... surprising when one parsed year, month, and day anyways.
      Glibc's strptime() conveniently sets tm_wday and tm_yday in those cases,
      but OS X's does not, ignoring them completely.
      This commit makes jq compute those where possible, though the day of
      week computation may be wrong for dates before 1900-03-01 or after