| 1 | Revision history for Perl extension JSON::XS |
1 | Revision history for Perl extension JSON::XS |
|
|
2 | |
|
|
3 | TODO: document precision loss for floating point. |
|
|
4 | - implement our own atof function - perl's can be orders of |
|
|
5 | magnitudes slower than even the system one. on the positive |
|
|
6 | side, ours seems to be more exact in general than perl's. |
|
|
7 | (testcase provided by Tim Meadowcroft). |
|
|
8 | - update jpsykes csrf article url. |
|
|
9 | - updated benchmark section - JSON::PP became much faster! |
|
|
10 | |
|
|
11 | 2.27 Thu Jan 7 07:35:08 CET 2010 |
|
|
12 | - support relaxed option inside the incremental parser |
|
|
13 | (testcase provided by IKEGAMI via Makamaka). |
|
|
14 | |
|
|
15 | 2.26 Sat Oct 10 03:26:19 CEST 2009 |
|
|
16 | - big integers could become truncated (based on patch |
|
|
17 | by Strobl Anton). |
|
|
18 | - output format change: indent now adds a final newline, which is |
|
|
19 | more expected and more true to the documentation. |
|
|
20 | |
|
|
21 | 2.25 Sat Aug 8 12:04:41 CEST 2009 |
|
|
22 | - the perl debugger completely breaks lvalue subs - try to work |
|
|
23 | around the issue. |
|
|
24 | - ignore RMAGICAL hashes w.r.t. CANONICAL. |
|
|
25 | - try to work around a possible char signedness issue on aix. |
|
|
26 | - require common sense. |
|
|
27 | |
|
|
28 | 2.24 Sat May 30 08:25:45 CEST 2009 |
|
|
29 | - the incremental parser did not update its parse offset |
|
|
30 | pointer correctly when parsing utf8-strings (nicely |
|
|
31 | debugged by Martin Evans). |
|
|
32 | - appending a non-utf8-string to the incremental parser |
|
|
33 | in utf8 mode failed to upgrade the string. |
|
|
34 | - wording of parse error messages has been improved. |
| 2 | |
35 | |
| 3 | 2.232 Sun Feb 22 11:12:25 CET 2009 |
36 | 2.232 Sun Feb 22 11:12:25 CET 2009 |
| 4 | - use an exponential algorithm to extend strings, to |
37 | - use an exponential algorithm to extend strings, to |
| 5 | help platforms with bad or abysmal==windows memory |
38 | help platforms with bad or abysmal==windows memory |
| 6 | allocater performance, at the expense of some memory |
39 | allocater performance, at the expense of some memory |
