| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Test Plan:
To verify that this is in fact the behavior:
```
$ jq --indent 7 -n '[1]'
[
1
]
$ jq --indent 8 -n '[1]'
jq: --indent takes a number between -1 and 7
Use jq --help for help with command-line options,
or see the jq manpage, or online docs at https://stedolan.github.io/jq
```
This patch was generated by running `git grep "no more than"` and fixing
up appropriate results.
wchargin-branch: docs-fix-indent-bounds
|
|
|
|
|
|
|
|
|
|
Closes: https://github.com/stedolan/jq/issues/1271
|
|
Minor rephrasing to prevent read/brain backtracking when using capital letter A as an article and a variable term.
|
|
Extend jv_number to use decNumber for storing number literals. Any math
operations on the numbers will truncate them to double precision.
Comparisons when both numbers are literal numbers will compare them
without truncation.
Delay conversion of numbers to doubles until a math operation is performed,
to preserve precision. A literal jv_number will only need conversion to
double once, and will reuse the resultant double on subsequent
conversions.
Outputting literal jv_numbers preserves the original precision.
Add strong pthread requirement to manage contexts/allocations for
converting numbers between their decNumber, string, and double formats.
|
|
The library adds support for decimal numbers of arbitrary length.
Downloaded from ICU, under ICU 1.8.1 license
http://download.icu-project.org/files/decNumber/decNumber-icu-368.zip
|
|
The current instructions tell users to perform two actions:
- update the package database
- install the jq package
The only thing users need to or should be doing is actually installing
the jq package -- regardless of which version is being installed.
Guidelines on how to perform system updates are massively out of scope.
In the case of partially performing a system update as a prerequisite
for installing jq, the official guidance from Arch Linux is not to do
this: partial updates are not supported, we refuse to support them, and
anyone who does try to perform them anyway is assumed to know so much
about their system that they clearly do not ever need help from anyone
else (which is a good thing since they won't get it). The result is a
frankensteined system that can only ever be supported by the person who
frankensteined it to begin with. The only reason the package manager
even allows it to occur in the first place is because other
distributions using pacman might have different LTS policies, and
because it would prevent expert users from being in control of their
system, as per the traditional Unix philosophy:
"Unix was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things."
Consequences of performing partial updates without understanding the
ramifications in extensive detail can include breaking the partially
updated application (jq), breaking any application that shares a mutual
dependency with the partially updated application (which jq is *lucky*
to only depend on the ever-backwards-compatible glibc), or breaking the
entire operating system by leaving armed traps behind for the next time
a `pacman -S new-package` is executed and thereby breaks *its* cascading
dependencies.
See:
https://wiki.archlinux.org/index.php/System_maintenance#Partial_upgrades_are_unsupported
|
|
The current paragraph is not complete, since a digit is not a special character.
Changing it to:
If the key contains special characters or starts with a digit,
you need to surround it with double quotes like this:
`."foo$"`, or else `.["foo$"]`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"(.+)" doesn't match new line characters so the link generated for [if-then-else](https://github.com/stedolan/jq/blob/90bc29c1b544c0436ec44246e180fdbb6d6384df/docs/content/3.manual/v1.5/manual.yml#L1804) doesn't work
|
|
Fix grammar typo.
|
|
Users are often surprised by the requirement to parenthesize any
non-trivial object key expressions in object constructors. E.g.,
{"a"+"b":1}. This commit adds one more kind of key expression besides
literals and idents: variable references.
A common use case for this is jq programs as JSON templates to fill in
with variables computed from inputs or passed in on the command-line.
E.g., {some_key:$value}. Now users can also use, e.g., {$key:$value}.
This and the restrictions on key and value expressions in object
constructors are now clarified a bit in the documentation.
|
|
'operator' needs to be plural here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In passing, clean remnants of argfile from slurpfile docs.
|
|
This reverts commit e24af3c78e78a3aab05a2800d825d56f1d842b1b.
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).
|
|
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.
|
|
Suppresion -> Suppression
|
|
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
2099-12-31.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
