* Re: ANN: Simple components for Ada v.4.42
2019-09-16 6:58 ` briot.emmanuel
@ 2019-09-16 7:44 ` Dmitry A. Kazakov
2019-10-03 18:58 ` Olivier Henley
2019-09-16 8:18 ` J-P. Rosen
` (2 subsequent siblings)
3 siblings, 1 reply; 16+ messages in thread
From: Dmitry A. Kazakov @ 2019-09-16 7:44 UTC (permalink / raw)
On 2019-09-16 08:58, briot.emmanuel@gmail.com wrote:
> On Monday, September 16, 2019 at 8:48:36 AM UTC+2, Dmitry A. Kazakov wrote:
>> The new version provides an implementation of JSON (RFC 7158)
>
> I would be curious to know the differences compared to what GNATCOLL.JSON provides, if you know ? It would be nice if the Ada world did not have too many packages competing here.
> (Although I was the GNATCOLL maintainer for a long time, I did not write the JSON package, so this is really an open question :-)
>
> Various things which I find limiting in GNATCOLL.JSON: performance is not really good because there are a lot of memory allocations (your short description seems to indicate this might be an area where your package improves things); gnatcoll treats arrays and objects completely differently, one without tagged types and the other with; simple types systematically have to be converted explicitly to a json object with Create;...
The difference as far as I can tell:
1. My JSON parser sits on top of table-driven parser with does all work.
The implementation merely defines a table with JSON operations ("[]",
"{}", ":").
2. Parts of the input object are allocated in an external pool. The pool
allocation policy is strictly LIFO, so an arena can be used to free JSON
object once consumed. IMO there is no reason to keep JSON objects any
longer. No tagged objects used.
3. No mutable JSON objects and construction methods are provided as I
see no reason for having them for such a primitive thing. It is far more
easier just to output JSON stuff using Ada I/O facilities or
Strings_Edit. The only less trivial thing is JSON-escaped strings. For
them a procedure Put and function Image are provided.
> The GNATCOLL.JSON parser can be extended to support YAML (I have some local patches to support comments and optional quotes for strings, but not the indentation-based structures), but it would be nice if this was provided out of the box...
YAML looks a completely different thing. Any relation to JSON seems
purely historical.
It would be no problem to write a table-driven parser for YAML, if there
were demand.
I am kind of sceptical regarding YAML usefulness. Not that JSON has much
merits either, but at least it is actively used with HTTP REST API and
JavaScript.
YAML is like XML a wrong solution to a non-existent problem.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ANN: Simple components for Ada v.4.42
2019-09-16 7:44 ` Dmitry A. Kazakov
@ 2019-10-03 18:58 ` Olivier Henley
2019-10-03 19:58 ` Dmitry A. Kazakov
0 siblings, 1 reply; 16+ messages in thread
From: Olivier Henley @ 2019-10-03 18:58 UTC (permalink / raw)
> Not that JSON has much merits either
I want to know more on why you think so?
Since virtually every web 'distributed architecture' since 2010 decided to go 'string based', what could be more appropriate than Json?
Is it the 'string based' approach that itches you?
...
I know protobuf is serialization of structured primitive types and grpc handle these as a form of rpc over http2.
I know grpc is available for many languages and therefore makes a viable alternative to Json in an heterogeneous network of services.
I also know Ada has no implementation of protobuf and/or grpc.
Where do we go from there?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ANN: Simple components for Ada v.4.42
2019-10-03 18:58 ` Olivier Henley
@ 2019-10-03 19:58 ` Dmitry A. Kazakov
2019-10-03 21:16 ` Olivier Henley
0 siblings, 1 reply; 16+ messages in thread
From: Dmitry A. Kazakov @ 2019-10-03 19:58 UTC (permalink / raw)
On 2019-10-03 20:58, Olivier Henley wrote:
>> Not that JSON has much merits either
>
> I want to know more on why you think so?
>
> Since virtually every web 'distributed architecture' since 2010 decided to go 'string based', what could be more appropriate than Json?
>
> Is it the 'string based' approach that itches you?
It is many things, not just one. Before talking about a solution I would
like know the problem.
Why there should a data definition language there. Why this language
must lack any decent language features? You could not parse it
otherwise, then why a language again? Why it must pretend to be
readable, while nobody ever reads it. Why it should be weakly typed. Why
it should be non-portable (e.g. JSON numbers) etc.
> I know protobuf is serialization of structured primitive types and grpc handle these as a form of rpc over http2.
>
> I know grpc is available for many languages and therefore makes a viable alternative to Json in an heterogeneous network of services.
RPC is not a good idea either. But even so, there is no reason to use
something like JSON for marshaling RPC parameters.
> I also know Ada has no implementation of protobuf and/or grpc.
Well, Ada community has very limited resources available. It must treat
such things pragmatically.
I would say, if you need communication do it in Ada. If you need
interoperability with some legacy mess, OK, then there is a demand and
one could consider some Ada bindings/adapter to that mess. So far nobody
voiced it.
> Where do we go from there?
We sit and wait. Bad ideas tend to drown themselves in countless useless
implementations, JSON, XML, YAML ... There is no rush. Next year
somebody will invent something no less worse.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ANN: Simple components for Ada v.4.42
2019-10-03 19:58 ` Dmitry A. Kazakov
@ 2019-10-03 21:16 ` Olivier Henley
2019-10-03 21:29 ` Olivier Henley
0 siblings, 1 reply; 16+ messages in thread
From: Olivier Henley @ 2019-10-03 21:16 UTC (permalink / raw)
First I want to say that I totally agree with you.
> Before talking about a solution I would like know the problem.
The problem is that Ada is nowhere to be seen on things such as the Tiobe programming index and therefore communicating Ada-Ada does not make the cut for a lot of projects. There is just no public Ada API out there.
This fact, for sure, puts off a lot of adoption where many new projects probably have 'cloud communication' needs to non Ada services.
> OK, then there is a demand and one could consider some Ada bindings/adapter to that mess. So far nobody voiced it.
I think nobody voiced it because they are actively building business using another language that provides the 'fashionist' way of communicating.
Its a chicken-egg problem and I am not sure we should sit and wait though.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ANN: Simple components for Ada v.4.42
2019-10-03 21:16 ` Olivier Henley
@ 2019-10-03 21:29 ` Olivier Henley
2019-10-04 7:56 ` Dmitry A. Kazakov
0 siblings, 1 reply; 16+ messages in thread
From: Olivier Henley @ 2019-10-03 21:29 UTC (permalink / raw)
In essence what I am trying to say is that 'Ada is not in the game'.
Do not get me wrong, every company using Ada deserves uttermost respect but they are no Google, Apple, Microsoft etc of this world.
Those are setting the rules, you like it or not (http2?), and if I can use an analogy, we are on the bench for the whole 'cloud' segment.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ANN: Simple components for Ada v.4.42
2019-10-03 21:29 ` Olivier Henley
@ 2019-10-04 7:56 ` Dmitry A. Kazakov
0 siblings, 0 replies; 16+ messages in thread
From: Dmitry A. Kazakov @ 2019-10-04 7:56 UTC (permalink / raw)
On 2019-10-03 23:29, Olivier Henley wrote:
> In essence what I am trying to say is that 'Ada is not in the game'.
There are different games.
> Do not get me wrong, every company using Ada deserves uttermost respect but they are no Google, Apple, Microsoft etc of this world.
True, but Google, Apple and Microsoft are not companies. They are so big
that in fact they are cartels.
> Those are setting the rules, you like it or not (http2?), and if I can use an analogy, we are on the bench for the whole 'cloud' segment.
That depends on what your company does. Usually the pressure to use
something you do not like comes from the customer, not from Microsoft et al.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ANN: Simple components for Ada v.4.42
2019-09-16 6:58 ` briot.emmanuel
2019-09-16 7:44 ` Dmitry A. Kazakov
@ 2019-09-16 8:18 ` J-P. Rosen
2019-09-16 19:10 ` Dmitry A. Kazakov
2019-10-03 23:53 ` onox
3 siblings, 0 replies; 16+ messages in thread
From: J-P. Rosen @ 2019-09-16 8:18 UTC (permalink / raw)
Le 16/09/2019 à 08:58, briot.emmanuel@gmail.com a écrit :
> It would be nice if the Ada world did not have too many packages competing here.
Sure. See https://xkcd.com/927/ :-)
--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ANN: Simple components for Ada v.4.42
2019-09-16 6:58 ` briot.emmanuel
2019-09-16 7:44 ` Dmitry A. Kazakov
2019-09-16 8:18 ` J-P. Rosen
@ 2019-09-16 19:10 ` Dmitry A. Kazakov
2019-10-03 23:53 ` onox
3 siblings, 0 replies; 16+ messages in thread
From: Dmitry A. Kazakov @ 2019-09-16 19:10 UTC (permalink / raw)
On 2019-09-16 08:58, briot.emmanuel@gmail.com wrote:
> The GNATCOLL.JSON parser can be extended to support YAML (I have some local patches to support comments and optional quotes for strings, but not the indentation-based structures), but it would be nice if this was provided out of the box...
I forgot, there is an Ada YAML implementation:
https://ada.yaml.io
https://github.com/yaml/AdaYaml
Maybe I would do it rather naked without IMO unnecessary DOM,
presentation etc, yet it is there!
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ANN: Simple components for Ada v.4.42
2019-09-16 6:58 ` briot.emmanuel
` (2 preceding siblings ...)
2019-09-16 19:10 ` Dmitry A. Kazakov
@ 2019-10-03 23:53 ` onox
2019-10-04 7:56 ` Dmitry A. Kazakov
3 siblings, 1 reply; 16+ messages in thread
From: onox @ 2019-10-03 23:53 UTC (permalink / raw)
On Monday, September 16, 2019 at 8:58:41 AM UTC+2, briot....@gmail.com wrote:
> On Monday, September 16, 2019 at 8:48:36 AM UTC+2, Dmitry A. Kazakov wrote:
> > The new version provides an implementation of JSON (RFC 7158)
>
>
> Hi Dmitry,
> I would be curious to know the differences compared to what GNATCOLL.JSON provides, if you know ? It would be nice if the Ada world did not have too many packages competing here.
Uh oh, I've written a JSON parser ([0]) too! Sorry :) It's quite fast, only about 1K SLOC, supports Ada 2012's iterator and indexing syntax, Apache 2.0 license, but it does not handle UTF-8 yet (patches welcome though)
> Various things which I find limiting in GNATCOLL.JSON: performance is not really good because there are a lot of memory allocations
I did some benchmarking of some JSON parsers using a 110 M large .json file from [1]:
- Parsers.JSON choked on it (I used Parsers.Multiline_Source.Stream_IO)
- GNATCOLL.JSON needs about ~ 17 seconds
- json-ada needs about ~ 3 seconds (should be ~ 1 second to be competitive with other languages, patches/advice welcome)
[0] https://github.com/onox/json-ada
[1] https://github.com/kostya/benchmarks#Json
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: ANN: Simple components for Ada v.4.42
2019-10-03 23:53 ` onox
@ 2019-10-04 7:56 ` Dmitry A. Kazakov
2019-10-04 10:52 ` Olivier Henley
0 siblings, 1 reply; 16+ messages in thread
From: Dmitry A. Kazakov @ 2019-10-04 7:56 UTC (permalink / raw)
On 2019-10-04 01:53, onox wrote:
> Uh oh, I've written a JSON parser ([0]) too! Sorry :) It's quite fast, only about 1K SLOC, supports Ada 2012's iterator and indexing syntax, Apache 2.0 license, but it does not handle UTF-8 yet (patches welcome though)
Good to know, thanks.
>> Various things which I find limiting in GNATCOLL.JSON: performance is not really good because there are a lot of memory allocations
>
> I did some benchmarking of some JSON parsers using a 110 M large .json file from [1]:
It do not find the JSON file there. Can you give a link how to download it?
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 16+ messages in thread