Hi,
I have create a new JSON parser using conditional re2c and pure pull Bison
parser. It's a native UTF-8 parser licensed under PHP license (it can be
used for Evil though :) ). The extension is available at
https://github.com/bukka/php-jsond
The encoder is taken from the current ext/json but the decoder has been
completely rewritten.
I have done some basic benchmarks (the results are on the README.md page).
For short strings the results are almost the same (the new parser is
usually slightly faster) but there is a big difference for longer strings.
For example for string with 800 characters the new parser is 4 times
faster. If the string is longer, the results are even better. It's also
much faster for big arrays. For example decoding json_encode($_SERVER) is
twice faster with the new parser.
In addition to the speed improvements there also is a big memory saving.
The old parser converts every serialized string to UTF-16 which requires
additional memory. Although the memory is freed after the parsing, it can
be problematic if the memory_limit is set. The new parser parses supplied
string and no extra memory for conversion is allocated.
I need to do more testing before creating RFC for replacing the current
parser. There is still space for further improvements. If anyone has any
ideas, please let me know. Or if you could test it, that would be great
too! ;)
I haven't finished the build config (it's working but it's not auto rebuild
when you change *.y or *.re files). Need to figure out how to add
Makefile.frag for bison and re2c . It's not working when I add
PHP_ADD_MAKEFILE_FRAGMENT($abs_srcdir/Makefile.frag)
$ make
make: *** No rule to make target jsond.lo', needed byjsond.la'. Stop.
Has anyone got any idea? :)
Also there is no build for Win atm as I don't have Windows... :( Hopefully
someone will do it for me... :)
Thanks
Jakub
Hi,
I have create a new JSON parser using conditional re2c and pure pull Bison
parser. It's a native UTF-8 parser licensed under PHP license (it can be
used for Evil though :) ). The extension is available athttps://github.com/bukka/php-jsond
The encoder is taken from the current ext/json but the decoder has been
completely rewritten.I have done some basic benchmarks (the results are on the README.md page).
For short strings the results are almost the same (the new parser is
usually slightly faster) but there is a big difference for longer strings.
For example for string with 800 characters the new parser is 4 times
faster. If the string is longer, the results are even better. It's also
much faster for big arrays. For example decoding json_encode($_SERVER) is
twice faster with the new parser.In addition to the speed improvements there also is a big memory saving.
The old parser converts every serialized string to UTF-16 which requires
additional memory. Although the memory is freed after the parsing, it can
be problematic if the memory_limit is set. The new parser parses supplied
string and no extra memory for conversion is allocated.I need to do more testing before creating RFC for replacing the current
parser. There is still space for further improvements. If anyone has any
ideas, please let me know. Or if you could test it, that would be great
too! ;)I haven't finished the build config (it's working but it's not auto rebuild
when you change *.y or *.re files). Need to figure out how to add
Makefile.frag for bison and re2c . It's not working when I add
PHP_ADD_MAKEFILE_FRAGMENT($abs_srcdir/Makefile.frag)
$ make
make: *** No rule to make targetjsond.lo', needed byjsond.la'. Stop.
Has anyone got any idea? :)
Also there is no build for Win atm as I don't have Windows... :( Hopefully
someone will do it for me... :)
This sounds great! We solve the licensing issue and get a performance
benefit at the same time :)
One quick note, while looking over the code: FLOAT = INT "." UINT should be
FLOAT = INT "." DIGIT+ otherwise you'll disallow numbers with leading
zeros, e.g. 1.001. Same applies to ( INT | FLOAT ) [eE] [+-]? UINT, where
the exponent should also allow leading zeros ;)
Nikita
One quick note, while looking over the code: FLOAT = INT "." UINT should
be FLOAT = INT "." DIGIT+ otherwise you'll disallow numbers with leading
zeros, e.g. 1.001. Same applies to ( INT | FLOAT ) [eE] [+-]? UINT, where
the exponent should also allow leading zeros ;)
Yeah definitely! Good catch! Fixed... ;)
Thanks
Jakub
Hi,
I need to do more testing before creating RFC for replacing the current
parser. There is still space for further improvements. If anyone has any
ideas, please let me know. Or if you could test it, that would be great
too! ;)
At least for the decoding part, it might be worth to look at the
"Improving JSON" proposal (http://bolinfest.com/essays/json.html).
tl;dr: support trailing or automatic line-end commas, //-style
comments and keys not wrapped in "s, basically extend JSON syntax to
ES5.
I think it would be really cool if the new parser could (maybe with a
option "JSON_NO_STRICT_PARSING") implement these enhancements to ease
hand-writing of JSON files.
Also, will end-users be able to get the JSON parser error message?
Currently, all you get is a NULL returned when you have a parse error
somewhere in your JSON - and it's a nightmare to debug with this.
Marco
At least for the decoding part, it might be worth to look at the
"Improving JSON" proposal (http://bolinfest.com/essays/json.html).
tl;dr: support trailing or automatic line-end commas, //-style
comments and keys not wrapped in "s, basically extend JSON syntax to
ES5.I think it would be really cool if the new parser could (maybe with a
option "JSON_NO_STRICT_PARSING") implement these enhancements to ease
hand-writing of JSON files.
Please, I urge you not to implement anything except the pure JSON standard. One of JSON’s great strengths is that there is only a single, canonical JSON standard. Implementing other standards would be damaging to interoperability.
If people want nice config files, they can use PHP ;)
--
Andrea Faulds
http://ajf.me/
Hi,
At least for the decoding part, it might be worth to look at the
"Improving JSON" proposal (http://bolinfest.com/essays/json.html).
tl;dr: support trailing or automatic line-end commas, //-style
comments and keys not wrapped in "s, basically extend JSON syntax to
ES5.I think it would be really cool if the new parser could (maybe with a
option "JSON_NO_STRICT_PARSING") implement these enhancements to ease
hand-writing of JSON files.Please, I urge you not to implement anything except the pure JSON
standard. One of JSON’s great strengths is that there is only a single,
canonical JSON standard. Implementing other standards would be damaging to
interoperability.
Nothing is set in stone, and evolution should be allowed, especially
where it makes sense (trailing comma!). Also, that's why I suggested a
"relaxed parsing" flag. This way, people knowing the differences can
use what suits them best. (Also, IIRC there already exist polyfills to
implement this syntax).
If people want nice config files, they can use PHP ;)
Sure, but it's a bit uncool to keep the same stuff in two places - I'm
thinking of a translation support for an app I write which supports
both AJAX/template-based client rendering and a more basic,
server-rendered version.
Currently, I have the stuff in a PHP array which generates a JSON file
with the translation upon manual rebuild. Alone the "support trailing
comma" function (to ease working with version control) would give me
the option of doing everything in JSON without manual rebuilds etc.
Marco
I think it would be really cool if the new parser could (maybe with a
option "JSON_NO_STRICT_PARSING") implement these enhancements to ease
hand-writing of JSON files.Please, I urge you not to implement anything except the pure JSON standard.
One of JSON’s great strengths is that there is only a single, canonical
JSON standard. >Implementing other standards would be damaging to interoperability.If people want nice config files, they can use PHP ;)
+1
Or they can use YAML, which is great for configs, in my opinion. Symfony2 and Doctrine uses it a lot.
Christian
I need to do more testing before creating RFC for replacing the current
parser. There is still space for further improvements. If anyone has any
ideas, please let me know. Or if you could test it, that would be great
too! ;)At least for the decoding part, it might be worth to look at the
"Improving JSON" proposal (http://bolinfest.com/essays/json.html).
tl;dr: support trailing or automatic line-end commas, //-style
comments and keys not wrapped in "s, basically extend JSON syntax to
ES5.
I also oppose these proposals.
Also, will end-users be able to get the JSON parser error message?
Currently, all you get is aNULLreturned when you have a parse error
somewhere in your JSON - and it's a nightmare to debug with this.
This is a problem, I agree.
At least for the decoding part, it might be worth to look at the
"Improving JSON" proposal (http://bolinfest.com/essays/json.html).
tl;dr: support trailing or automatic line-end commas, //-style
comments and keys not wrapped in "s, basically extend JSON syntax to
ES5.I think it would be really cool if the new parser could (maybe with a
option "JSON_NO_STRICT_PARSING") implement these enhancements to ease
hand-writing of JSON files.
The current implementation doesn't introduce any changes from the user
point of view (except improved performance :) ). I want to keep it simple
and not over complicate the proposal. I am sure that we can discuss further
improvements if the new parser is accepted to the core. However it will
require a new RFC and thread... :)
Also, will end-users be able to get the JSON parser error message?
Currently, all you get is a
NULLreturned when you have a parse error
somewhere in your JSON - and it's a nightmare to debug with this.
You can get some info using json_last_error(_msg). However it's not very
useful because you can't identify the position of the error. I plan to
improve that but again it's not gonna be in the current proposal.
To sum it up. There are NO changes for PHP users! This is just internal
change... ;)
Thanks
Jakub
This is awesome. Thanks!
At least for the decoding part, it might be worth to look at the
"Improving JSON" proposal (http://bolinfest.com/essays/json.html).
tl;dr: support trailing or automatic line-end commas, //-style
comments and keys not wrapped in "s, basically extend JSON syntax to
ES5.I think it would be really cool if the new parser could (maybe with a
option "JSON_NO_STRICT_PARSING") implement these enhancements to ease
hand-writing of JSON files.The current implementation doesn't introduce any changes from the user
point of view (except improved performance :) ). I want to keep it simple
and not over complicate the proposal. I am sure that we can discuss further
improvements if the new parser is accepted to the core. However it will
require a new RFC and thread... :)Also, will end-users be able to get the JSON parser error message?
Currently, all you get is a
NULLreturned when you have a parse error
somewhere in your JSON - and it's a nightmare to debug with this.You can get some info using json_last_error(_msg). However it's not very
useful because you can't identify the position of the error. I plan to
improve that but again it's not gonna be in the current proposal.To sum it up. There are NO changes for PHP users! This is just internal
change... ;)Thanks
Jakub
Le 13/03/2014 20:48, Jakub Zelenka a écrit :
Hi,
I have create a new JSON parser using conditional re2c and pure pull Bison
parser. It's a native UTF-8 parser licensed under PHP license (it can be
used for Evil though :) ). The extension is available at
Nice !
Can you pull all the test suite from official ext/json to check if it is
a dropin alternative ?
Remi.
Can you pull all the test suite from official ext/json to check if it is
a dropin alternative ?
Done! ;) I just renamed json to jsond. All tests pass for me. Just one skip
for 32bit test (pass001.1.phpt) but it's 64bit variant is fine. If someone
could try that test, that would be great.
It's tested only with PHP master branch and apparently not compile under
5.5. I will have a look on older PHP versions and fix it later. Also need
to improve build and do more benchmarking.
Any testing, ideas and comments will be appreciated... ;)
Thanks
Jakub
Jakub Zelenka bukka@php.net schrieb:
--001a11330a7413861304f4aa17a7
Content-Type: text/plain; charset=ISO-8859-1Can you pull all the test suite from official ext/json to check if it is
a dropin alternative ?Done! ;) I just renamed json to jsond. All tests pass for me. Just one skip
for 32bit test (pass001.1.phpt) but it's 64bit variant is fine. If someone
could try that test, that would be great.It's tested only with PHP master branch and apparently not compile under
5.5. I will have a look on older PHP versions and fix it later. Also need
to improve build and do more benchmarking.Any testing, ideas and comments will be appreciated... ;)
Thanks
Jakub
--001a11330a7413861304f4aa17a7--
have you been testing this with a json testing library like
https://code.google.com/p/json-test-suite/ ?
I really like your project, but we have to be very very careful when it
comes to json adn make sure it supports everything the current json lib
supports.
-David
have you been testing this with a json testing library like
https://code.google.com/p/json-test-suite/ ?
Not yet. I will definitely have a look.
I really like your project, but we have to be very very careful when it
comes to json adn make sure it supports everything the current json lib
supports.
I agree with you 100%. Currently it passes all ext/json tests that should
cover lots of cases but definitely need to do more testing.
Thanks
Jakub
Jakub Zelenka bukka@php.net schrieb:
--001a11330a7413861304f4aa17a7
Content-Type: text/plain; charset=ISO-8859-1On Fri, Mar 14, 2014 at 8:36 AM, Remi Collet remi@fedoraproject.org
wrote:Can you pull all the test suite from official ext/json to check if it is
a dropin alternative ?Done! ;) I just renamed json to jsond. All tests pass for me. Just one
skip
for 32bit test (pass001.1.phpt) but it's 64bit variant is fine. If
someone
could try that test, that would be great.It's tested only with PHP master branch and apparently not compile under
5.5. I will have a look on older PHP versions and fix it later. Also need
to improve build and do more benchmarking.Any testing, ideas and comments will be appreciated... ;)
Thanks
Jakub
--001a11330a7413861304f4aa17a7--
have you been testing this with a json testing library like
https://code.google.com/p/json-test-suite/ ?I really like your project, but we have to be very very careful when it
comes to json adn make sure it supports everything the current json lib
supports.-David
really great！
thanks for the work！
Sent from my iPhone
Hi,
I have create a new JSON parser using conditional re2c and pure pull Bison
parser. It's a native UTF-8 parser licensed under PHP license (it can be
used for Evil though :) ). The extension is available athttps://github.com/bukka/php-jsond
The encoder is taken from the current ext/json but the decoder has been
completely rewritten.I have done some basic benchmarks (the results are on the README.md page).
For short strings the results are almost the same (the new parser is
usually slightly faster) but there is a big difference for longer strings.
For example for string with 800 characters the new parser is 4 times
faster. If the string is longer, the results are even better. It's also
much faster for big arrays. For example decoding json_encode($_SERVER) is
twice faster with the new parser.In addition to the speed improvements there also is a big memory saving.
The old parser converts every serialized string to UTF-16 which requires
additional memory. Although the memory is freed after the parsing, it can
be problematic if the memory_limit is set. The new parser parses supplied
string and no extra memory for conversion is allocated.I need to do more testing before creating RFC for replacing the current
parser. There is still space for further improvements. If anyone has any
ideas, please let me know. Or if you could test it, that would be great
too! ;)I haven't finished the build config (it's working but it's not auto rebuild
when you change *.y or *.re files). Need to figure out how to add
Makefile.frag for bison and re2c . It's not working when I add
PHP_ADD_MAKEFILE_FRAGMENT($abs_srcdir/Makefile.frag)
$ make
make: *** No rule to make targetjsond.lo', needed byjsond.la'. Stop.
Has anyone got any idea? :)
Also there is no build for Win atm as I don't have Windows... :( Hopefully
someone will do it for me... :)Thanks
Jakub
Hi,
I have create a new JSON parser using conditional re2c and pure pull Bison
parser. It's a native UTF-8 parser licensed under PHP license (it can be
used for Evil though :) ). The extension is available athttps://github.com/bukka/php-jsond
The encoder is taken from the current ext/json but the decoder has been
completely rewritten.I have done some basic benchmarks (the results are on the README.md page).
For short strings the results are almost the same (the new parser is
usually slightly faster) but there is a big difference for longer strings.
For example for string with 800 characters the new parser is 4 times
faster. If the string is longer, the results are even better. It's also
much faster for big arrays. For example decoding json_encode($_SERVER) is
twice faster with the new parser.In addition to the speed improvements there also is a big memory saving.
The old parser converts every serialized string to UTF-16 which requires
additional memory. Although the memory is freed after the parsing, it can
be problematic if the memory_limit is set. The new parser parses supplied
string and no extra memory for conversion is allocated.I need to do more testing before creating RFC for replacing the current
parser. There is still space for further improvements. If anyone has any
ideas, please let me know. Or if you could test it, that would be great
too! ;)I haven't finished the build config (it's working but it's not auto rebuild
when you change *.y or *.re files). Need to figure out how to add
Makefile.frag for bison and re2c . It's not working when I add
PHP_ADD_MAKEFILE_FRAGMENT($abs_srcdir/Makefile.frag)
$ make
make: *** No rule to make targetjsond.lo', needed byjsond.la'. Stop.
Has anyone got any idea? :)
Also there is no build for Win atm as I don't have Windows... :( Hopefully
someone will do it for me... :)Thanks
Jakub
Thanks very much for taking the time to put together php-jsond,
I also think supporting the new ES5 proposal is a no-go and stick to what
we have now.
Essentially I see php-jsond being a drop-in replacement for the existing
implementation of the json_* functions.
hi Jakub,
Hi,
I have create a new JSON parser using conditional re2c and pure pull Bison
parser. It's a native UTF-8 parser licensed under PHP license (it can be
used for Evil though :) ). The extension is available athttps://github.com/bukka/php-jsond
The encoder is taken from the current ext/json but the decoder has been
completely rewritten.I have done some basic benchmarks (the results are on the README.md page).
For short strings the results are almost the same (the new parser is
usually slightly faster) but there is a big difference for longer strings.
For example for string with 800 characters the new parser is 4 times
faster. If the string is longer, the results are even better. It's also
much faster for big arrays. For example decoding json_encode($_SERVER) is
twice faster with the new parser.In addition to the speed improvements there also is a big memory saving.
The old parser converts every serialized string to UTF-16 which requires
additional memory. Although the memory is freed after the parsing, it can
be problematic if the memory_limit is set. The new parser parses supplied
string and no extra memory for conversion is allocated.I need to do more testing before creating RFC for replacing the current
parser. There is still space for further improvements. If anyone has any
ideas, please let me know. Or if you could test it, that would be great
too! ;)I haven't finished the build config (it's working but it's not auto rebuild
when you change *.y or *.re files). Need to figure out how to add
Makefile.frag for bison and re2c . It's not working when I add
PHP_ADD_MAKEFILE_FRAGMENT($abs_srcdir/Makefile.frag)
$ make
make: *** No rule to make targetjsond.lo', needed byjsond.la'. Stop.
Has anyone got any idea? :)
Also there is no build for Win atm as I don't have Windows... :( Hopefully
someone will do it for me... :)
Awesome job, thanks!
We can provide windows builds (it builds fine as of now). As soon as
you do pecl releases, build will be done automatically.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi,
Hi Jakub,
I have create a new JSON parser using conditional re2c and pure pull Bison
parser. It's a native UTF-8 parser licensed under PHP license (it can be
used for Evil though :) ). The extension is available athttps://github.com/bukka/php-jsond
Very nice work, thanks!
[snip]
I need to do more testing before creating RFC for replacing the current
parser. There is still space for further improvements. If anyone has any
ideas, please let me know. Or if you could test it, that would be great
too! ;)
For my PhD thesis in the automatic testing domain, I have created some
grammar-based testing algorithms, based on our dedicated LL(k) compiler
compiler (with its dedicated grammar description language called PP).
Please, see the article [1] (along with the presentation [2] and all the
details [3] about the article and the conference) and also the tool [4]
(called Hoa\Compiler). In this article, my experimentation consisted to
generate a lot of JSON strings (based on the JSON grammar [5] written in
PP) and compared them against the JSON parsers of Gecko and PHP. Now I
re-play this experimentation but I compare all the generated data with
ext/json and ext/jsond to see if there is no potential regression. Also,
I test it with a bounded exhaustive algorithm: it means we generate all
possible JSON strings up to a given size (the unit is the number of
tokens in a sequence, so{,trueorfooare tokens). Note that we
have two ther algorithms: uniform random generation and coverage-based
generation.
I have created a little repository to share my work [6]. I have
generated all sequences up to 15 tokens, which represents 356'327 data
and no one has failed. Congrats!
Just for the record, a good test is a test that fails. Here, I have
detected no regeression, and because I have previously compared the
ext/json with the JSON parser from Gecko, we can consider your
implementation as “safe”.
This is my little contribution of the morning :-). You can use this work
to generate data in a static file and use them to compare the memory and
CPU usage between ext/json and ext/jsond also.
Best regards.
[1] http://hoa-project.net/Literature/Research/Amost12.html
[2] http://keynote.hoa-project.net/Amost12/EDGB12.pdf
[3] http://hoa-project.net/Event/Amost12.html
[4] https://github.com/hoaproject/Compiler
[5] https://github.com/hoaproject/Json/blob/master/Grammar.pp
[6] https://github.com/Hywan/jsond-test
--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
[… I have generated all sequences up to 15 tokens, which represents
356'327 data and no one has failed.
I have re-play the experimentation with more data. I stop at 1 million
of generated data (longer and deeper JSON strings), without any fail.
Seems good :-] !
--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
On Tue, Mar 18, 2014 at 9:09 AM, Ivan Enderlin @ Hoa <
ivan.enderlin@hoa-project.net> wrote:
Hi,
Hi Jakub,
I have create a new JSON parser using conditional re2c and pure pull Bison
parser. It's a native UTF-8 parser licensed under PHP license (it can be
used for Evil though :) ). The extension is available atVery nice work, thanks!
[snip]
I need to do more testing before creating RFC for replacing the current
parser. There is still space for further improvements. If anyone has any
ideas, please let me know. Or if you could test it, that would be great
too! ;)For my PhD thesis in the automatic testing domain, I have created some
grammar-based testing algorithms, based on our dedicated LL(k) compiler
compiler (with its dedicated grammar description language called PP).
Please, see the article [1] (along with the presentation [2] and all the
details [3] about the article and the conference) and also the tool [4]
(called Hoa\Compiler). In this article, my experimentation consisted to
generate a lot of JSON strings (based on the JSON grammar [5] written in
PP) and compared them against the JSON parsers of Gecko and PHP. Now I
re-play this experimentation but I compare all the generated data with
ext/json and ext/jsond to see if there is no potential regression. Also, I
test it with a bounded exhaustive algorithm: it means we generate all
possible JSON strings up to a given size (the unit is the number of tokens
in a sequence, so{,trueorfooare tokens). Note that we have two
ther algorithms: uniform random generation and coverage-based generation.I have created a little repository to share my work [6]. I have generated
all sequences up to 15 tokens, which represents 356'327 data and no one has
failed. Congrats!
Just for the record, a good test is a test that fails. Here, I have
detected no regeression, and because I have previously compared the
ext/json with the JSON parser from Gecko, we can consider your
implementation as "safe".This is my little contribution of the morning :-). You can use this work
to generate data in a static file and use them to compare the memory and
CPU usage between ext/json and ext/jsond also.Best regards.
[1] http://hoa-project.net/Literature/Research/Amost12.html
[2] http://keynote.hoa-project.net/Amost12/EDGB12.pdf
[3] http://hoa-project.net/Event/Amost12.html
[4] https://github.com/hoaproject/Compiler
[5] https://github.com/hoaproject/Json/blob/master/Grammar.pp
[6] https://github.com/Hywan/jsond-test
Hi! That looks really nice! I've been actually looking for something like
this. It's cool that I can have a bunch of JSON sub-grammars for generating
test data for benchmarks. Need to have a look properly what it can do but
think that it will be really useful...
Thanks
Zitat von Jakub Zelenka bukka@php.net:
Hi,
I have create a new JSON parser using conditional re2c and pure pull Bison
parser. It's a native UTF-8 parser licensed under PHP license (it can be
used for Evil though :) ). The extension is available athttps://github.com/bukka/php-jsond
The encoder is taken from the current ext/json but the decoder has been
completely rewritten.I have done some basic benchmarks (the results are on the README.md page).
For short strings the results are almost the same (the new parser is
usually slightly faster) but there is a big difference for longer strings.
For example for string with 800 characters the new parser is 4 times
faster. If the string is longer, the results are even better. It's also
much faster for big arrays. For example decoding json_encode($_SERVER) is
twice faster with the new parser.In addition to the speed improvements there also is a big memory saving.
The old parser converts every serialized string to UTF-16 which requires
additional memory. Although the memory is freed after the parsing, it can
be problematic if the memory_limit is set. The new parser parses supplied
string and no extra memory for conversion is allocated.I need to do more testing before creating RFC for replacing the current
parser. There is still space for further improvements. If anyone has any
ideas, please let me know. Or if you could test it, that would be great
too! ;)I haven't finished the build config (it's working but it's not auto rebuild
when you change *.y or *.re files). Need to figure out how to add
Makefile.frag for bison and re2c . It's not working when I add
PHP_ADD_MAKEFILE_FRAGMENT($abs_srcdir/Makefile.frag)
$ make
make: *** No rule to make targetjsond.lo', needed byjsond.la'. Stop.
Has anyone got any idea? :)
Also there is no build for Win atm as I don't have Windows... :( Hopefully
someone will do it for me... :)Thanks
Jakub
Can you explain what exactly the following means in your
documentation: "If the extension is compiled with defined macro
PHP_JSOND_PRIMARY", or how to actually accomplish this? Maybe even for
PECL builds?
Thanks.
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject
Can you explain what exactly the following means in your documentation:
"If the extension is compiled with defined macro PHP_JSOND_PRIMARY", or how
to actually accomplish this? Maybe even for PECL builds?
Hi,
This will work only if you don't have compiled ext/json (it means if you
compile PHP with --disable-json) and then define macro in CFLAGS when you
compile jsond. For example:
$ CFLAGS="-O2 -Wall -DPHP_JSOND_PRIMARY" ./configure
I know it's not really user friendly at the moment... :) I probably
shouldn't have documented yet.
I would like to simplify it a bit in the future:
- replace json function if ext\json already loaded
- configuration option (--enble-jsond-primary) instead of explicit macro
definition
Not sure about PECL if you can specify configuration option for
extension... Need to have a look
Thanks
Jakub
Hi,
I have create a new JSON parser using conditional re2c and pure pull Bison
parser. It's a native UTF-8 parser licensed under PHP license (it can be
used for Evil though :) ). The extension is available athttps://github.com/bukka/php-jsond
The encoder is taken from the current ext/json but the decoder has been
completely rewritten.
While looking at this code I noticed that the encoder also does a UTF-8 -> UTF-16 conversion that can be avoided. I've written a patch to avoid doing so: https://github.com/php/php-src/pull/636
The performance improvement is not as awesome as jsond, just 15-30%. Interestingly it also makes decoding slightly faster.
In the process I've also spotted some unused code lying around, removal is here: https://github.com/php/php-src/pull/637
Best regards
Rouven
Hi Jakub,
I've just tested JSOND 1.3 on Windows and discovered some incompatibilities
with JSON implementation in 5.5.9. All of those incompatibilities are PHP's
syntax extensions over the RFC and are mostly related to parsing of numbers.
See https://gist.github.com/JanTvrdik/10277952#file-test-php-L43-L61
Jan Tvrdik
Hi Jakub,
I've just tested JSOND 1.3 on Windows and discovered some
incompatibilities with JSON implementation in 5.5.9. All of those
incompatibilities are PHP's syntax extensions over the RFC and are mostly
related to parsing of numbers.See https://gist.github.com/JanTvrdik/10277952#file-test-php-L43-L61
Hi,
Thanks for finding these differences. I consider them as bugs in the
current json implementation as they are not compatible with the ECMA-404
standard. Actually the top level is not even compatible with the level
1+... :)
I have added notes about that to the
https://github.com/bukka/php-jsond/blob/master/UPGRADE.md
Cheers
Jakub
Hi Jakub,
I've just tested JSOND 1.3 on Windows and discovered some incompatibilities
with JSON implementation in 5.5.9. All of those incompatibilities are PHP's
syntax extensions over the RFC and are mostly related to parsing of numbers.
See https://gist.github.com/JanTvrdik/10277952#file-test-php-L43-L61
Jan Tvrdik