Michael,
Internally JsonTools just stores the document as JSON fragments or text, in
the case of object, array, or null, the text is empty, but in the case of
number or bool, it converts the text to a number or bool when you ask
AsNumber or AsBoolean. Now normally this wont be a problem because
On Sat, 31 Aug 2019, Luca Olivetti via lazarus wrote:
El 31/8/19 a les 16:22, Michael Van Canneyt via lazarus ha escrit:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse
Also frequently encountered is omitting "" around property names. JSON is
El 31/8/19 a les 16:22, Michael Van Canneyt via lazarus ha escrit:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse
Also frequently encountered is omitting "" around property names. JSON is a
subset of Javascript:
D.Parse('{ d: 12345678.3 }');
On Sat, 31 Aug 2019, Anthony Walter wrote:
Could you include https://github.com/BeRo1985/pasjson in the comparison?
Sure. I also have a few other people have requested. I will also list the
license of each in the first table.
[snip]
For example if wanted to store object state using
> Could you include https://github.com/BeRo1985/pasjson in the comparison?
Sure. I also have a few other people have requested. I will also list the
license of each in the first table.
Regarding a huge gigabytes of JSON in a file, I know a small portion of
programmers of people might be inclined
On Fri, Aug 30, 2019 at 11:02 PM Michael Van Canneyt via lazarus
wrote:
> Can you try setting defaultsystemcodepage to UTF8 ?
Feeling a little bit embarrassed now (I'm used to Lazarus which
defaults to that).
With DefaultSystemCodePage := CP_UTF8 it works:
Handles unicode chars correctly: >{
Could you include https://github.com/BeRo1985/pasjson in the comparison?
On Fri, Aug 30, 2019 at 4:22 PM Anthony Walter via lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> Alan, oh that's a good idea. I will do that as well as add a few more
> parser libraries as requested by a few people in
On Sat, 31 Aug 2019, Sven Barth via lazarus wrote:
Am 31.08.2019 um 09:45 schrieb Michael Van Canneyt via lazarus:
Codepages & strings require careful setup. Contrary to popular belief, it
does not 'just work'.
All this is documented:
Am 31.08.2019 um 11:08 schrieb Sven Barth:
Am 31.08.2019 um 09:45 schrieb Michael Van Canneyt via lazarus:
Codepages & strings require careful setup. Contrary to popular
belief, it does not 'just work'.
All this is documented:
Am 31.08.2019 um 09:45 schrieb Michael Van Canneyt via lazarus:
Codepages & strings require careful setup. Contrary to popular belief,
it does not 'just work'.
All this is documented:
https://www.freepascal.org/docs-html/current/ref/refsu9.html#x32-390003.2.4
Many people tend to ignore
On 28.08.2019 09:23, Ondrej Pokorny via lazarus wrote:
On 17.08.2019 16:53, Mattias Gaertner via lazarus wrote:
On Thu, 15 Aug 2019 13:43:58 +0200
Ondrej Pokorny via lazarus wrote:
[...]
Project groups are saving my LPI files upon loading the project
group.
Huh? Do you really mean, merely
On Sat, 31 Aug 2019, Michael Van Canneyt via lazarus wrote:
On Sat, 31 Aug 2019, Anthony Walter via lazarus wrote:
Okay, going back and looking through the messages I see you did post a test
with:
{$codepage UTF8} and uses cwstring
Here are the results with that added:
On Linux using
On Sat, 31 Aug 2019, Anthony Walter via lazarus wrote:
Okay, going back and looking through the messages I see you did post a test
with:
{$codepage UTF8} and uses cwstring
Here are the results with that added:
On Linux using {$codepage UTF8} by itself causes both tests to fail. Adding
Okay, going back and looking through the messages I see you did post a test
with:
{$codepage UTF8} and uses cwstring
Here are the results with that added:
On Linux using {$codepage UTF8} by itself causes both tests to fail. Adding
cwstring causes both tests to work. On Windows trying to use
On Sat, 31 Aug 2019, Anthony Walter via lazarus wrote:
Michael, regarding this unicode problem, all the code has already been
posted in this thread.
program Test;
uses
FPJson, JsonParser, JsonTools;
There you are. You're missing the cwstring unit and the codepage directive.
Change
Michael, I hadn't tried your example code yet as I thought the discussion
was on the topic of the unicode failure, and your example was about parsing
speed. I'll be happy to take a look at speed improvements, but like you I
am interested to find our what's failing with VerifyUnicodeCharsFPJson.
--
If there is any chance the char codes are being altered through whatever
browser / mail client you are using, here is a direct link to the program
source:
https://cache.getlazarus.org/projects/test.lpr
--
___
lazarus mailing list
Michael, regarding this unicode problem, all the code has already been
posted in this thread.
program Test;
uses
FPJson, JsonParser, JsonTools;
const
UnicodeChars = '{ "name": "Joe®Schmoe", "occupation": "bank teller \u00Ae
" }';
function VerifyUnicodeCharsFPJson: Boolean;
var
N:
On Fri, 30 Aug 2019, Anthony Walter via lazarus wrote:
Okay, so I turned on my Windows VM with a different version of FPC and ran
VerifyUnicodeChars with both FPJson and JsonTools. The resutls are the
same. JsonTools sees the unicode correctly, and something is wrong when
using FPJson. I
19 matches
Mail list logo
