little contest

[Bonita Montero]

I've found this contest of a hotel brokerage agency on the web:
http://jobs4smartdevs.de/
Maybe someone here as a desire to do an efficient solution in C++.
I've developed one with this JSON-parser:
https://github.com/open-source-parsers/jsoncpp

[Mr Flibble]

I dislike coding contests as their only purpose is to massage people's egos and epeen.

I've already made a full JSON/RJSON (Relaxed JSON) parser/generator that is in the top 5% of parsers performance-wise.

/Flibble

--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."

[Bonita Montero]

>> I've found this contest of a hotel brokerage agency on the web:
>> http://jobs4smartdevs.de/
>> Maybe someone here as a desire to do an efficient solution in C++.
>> I've developed one with this JSON-parser:
>> https://github.com/open-source-parsers/jsoncpp

> I dislike coding contests as their only purpose is to massage people's
> egos and epeen.

That's a misinterpretation.

> I've already made a full JSON/RJSON (Relaxed JSON) parser/generator
> that is in the top 5% of parsers performance-wise.

That's quite easy.

[bol...@nowhere.org]

On Fri, 3 Jan 2020 15:33:08 +0000
Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>On 03/01/2020 15:29, Bonita Montero wrote:
>> I've found this contest of a hotel brokerage agency on the web:
>> http://jobs4smartdevs.de/
>> Maybe someone here as a desire to do an efficient solution in C++.
>> I've developed one with this JSON-parser:
>> https://github.com/open-source-parsers/jsoncpp
>
>I dislike coding contests as their only purpose is to massage people's egos
>and epeen.
>
>I've already made a full JSON/RJSON (Relaxed JSON) parser/generator that is in
>the top 5% of parsers performance-wise.

Of course you did. Did you solve the 3 body problem and world peace at the
same time?

[Melzzzzz]

I hate writting parsers in C++, especially in C.

--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[Bonita Montero]

>> I've found this contest of a hotel brokerage agency on the web:
>> http://jobs4smartdevs.de/
>> Maybe someone here as a desire to do an efficient solution in C++.
>> I've developed one with this JSON-parser:
>> https://github.com/open-source-parsers/jsoncpp

> I hate writting parsers in C++, especially in C.

Writing parsers is always a industrious task,
but in C++ it's rather convenient.

[Melzzzzz]

How so?

[Bonita Montero]

>> Writing parsers is always a industrious task,
>> but in C++ it's rather convenient.

> How so?

https://www.boost.org/doc/libs/1_67_0/libs/spirit/doc/html/spirit/introduction.html
... and many other parser-libs.

[Melzzzzz]

On 2020-01-04, Bonita Montero <Bonita....@gmail.com> wrote:
>

Having library is necessary, as it is tedious to write parser in C++...

[Bonita Montero]

>>>> Writing parsers is always a industrious task,
>>>> but in C++ it's rather convenient.

>>> How so?

>> https://www.boost.org/doc/libs/1_67_0/libs/spirit/doc/html/spirit/introduction.html
>> ... and many other parser-libs.

> Having library is necessary, as it is tedious to write parser in C++...

That's in every language "tedious".

[Melzzzzz]

On 2020-01-04, Bonita Montero <Bonita....@gmail.com> wrote:

Nope.

[Jorgen Grahn]

On Sat, 2020-01-04, Melzzzzz wrote:
> On 2020-01-04, Bonita Montero <Bonita....@gmail.com> wrote:
>>
>>>> Writing parsers is always a industrious task,
>>>> but in C++ it's rather convenient.
>>
>>> How so?
>>
>> https://www.boost.org/doc/libs/1_67_0/libs/spirit/doc/html/spirit/introduction.html
>> ... and many other parser-libs.
>
> Having library is necessary, as it is tedious to write parser in C++...

You guys are talking about a subclass of languages here. I often write
parsers for simple, "flat" languages, and plain C++ works well for
that.

For example:
- the container file format for JPEG images
- the TIFF file format
- linker symbols as seen in the output from 'nm -CP'

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Bonita Montero]

> You guys are talking about a subclass of languages here. I often write
> parsers for simple, "flat" languages, and plain C++ works well for
> that.
> For example:
> - the container file format for JPEG images
> - the TIFF file format
> - linker symbols as seen in the output from 'nm -CP'

That has nothing to do with parsing.

[Öö Tiib]

It is extending all "deserializtion" into "parsing" that is
pedantically wrong to do. But your "nothing to do" is
exaggeration. Parsing is subset of activities, deserialization
of text formats.

[Jorgen Grahn]

(Note that the output from nm -CP is text, an address and a C++ name.)

I was not aware at all that there is a distinction. If there is one,
it must be hard to draw the line. Recursive definition?

Not that matters much.

The real reason I brought it up is that there's often a choice when
designing a data format:

- use XML or JSON or similar, and you need help parsing it
- make up your own simpler format (often "key: value" is enough) and
you can make your own parser, can use normal Unix tools on it ...
but don't get any help from XML or JSON tools.

This second option may not be popular right now, but it does exist.

[Öö Tiib]

On Saturday, 4 January 2020 17:04:29 UTC+2, Jorgen Grahn wrote:
> On Sat, 2020-01-04, Öö Tiib wrote:
> > On Saturday, 4 January 2020 12:04:24 UTC+2, Bonita Montero wrote:
> >> > You guys are talking about a subclass of languages here. I often write
> >> > parsers for simple, "flat" languages, and plain C++ works well for
> >> > that.
> >> > For example:
> >> > - the container file format for JPEG images
> >> > - the TIFF file format
> >> > - linker symbols as seen in the output from 'nm -CP'
> >>
> >> That has nothing to do with parsing.
> >
> > It is extending all "deserializtion" into "parsing" that is
> > pedantically wrong to do. But your "nothing to do" is
> > exaggeration. Parsing is subset of activities, deserialization
> > of text formats.
>
> (Note that the output from nm -CP is text, an address and a C++ name.)
>
> I was not aware at all that there is a distinction. If there is one,
> it must be hard to draw the line. Recursive definition?
>
> Not that matters much.

Are you saying the term has widened from linguistics (where parsing is
semantic analysis of text) to computer science where it now means
any kind of deserializations? I am last from whom to ask extent of
modern English anyway.

> The real reason I brought it up is that there's often a choice when
> designing a data format:
>
> - use XML or JSON or similar, and you need help parsing it
> - make up your own simpler format (often "key: value" is enough) and
> you can make your own parser, can use normal Unix tools on it ...
> but don't get any help from XML or JSON tools.
>
> This second option may not be popular right now, but it does exist.

I myself like to use well-established portable formats, (like say png
for raster picture). Then I use json for everything for what I don't
have such format. That might result with lot of files that I prefer
to zip into one file in Open Document Format style.

[Mr Flibble]

Yes I did: if you don't believe me then you simply have to look at the source code as it is on github. Now kindly fuck off.

[bol...@nowhere.org]

On Sat, 4 Jan 2020 20:50:14 +0000

Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>On 03/01/2020 16:01, bol...@nowhere.org wrote:
>> On Fri, 3 Jan 2020 15:33:08 +0000
>> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>>> On 03/01/2020 15:29, Bonita Montero wrote:
>>>> I've found this contest of a hotel brokerage agency on the web:
>>>> http://jobs4smartdevs.de/
>>>> Maybe someone here as a desire to do an efficient solution in C++.
>>>> I've developed one with this JSON-parser:
>>>> https://github.com/open-source-parsers/jsoncpp
>>>
>>> I dislike coding contests as their only purpose is to massage people's egos
>>> and epeen.
>>>
>>> I've already made a full JSON/RJSON (Relaxed JSON) parser/generator that is
>in
>>> the top 5% of parsers performance-wise.
>>
>> Of course you did. Did you solve the 3 body problem and world peace at the
>> same time?
>
>Yes I did: if you don't believe me then you simply have to look at the source
>code as it is on github. Now kindly fuck off.

No idea where it is on github and I have better things to do that wade through
the convoluted mess you'll have written. Plus that tells me nothing about its
speed compared to other parsers.

[Jorgen Grahn]

On Sat, 2020-01-04, Öö Tiib wrote:
> On Saturday, 4 January 2020 17:04:29 UTC+2, Jorgen Grahn wrote:
>> On Sat, 2020-01-04, Öö Tiib wrote:
>> > On Saturday, 4 January 2020 12:04:24 UTC+2, Bonita Montero wrote:
>> >> > You guys are talking about a subclass of languages here. I often write
>> >> > parsers for simple, "flat" languages, and plain C++ works well for
>> >> > that.
>> >> > For example:
>> >> > - the container file format for JPEG images
>> >> > - the TIFF file format
>> >> > - linker symbols as seen in the output from 'nm -CP'
>> >>
>> >> That has nothing to do with parsing.
>> >
>> > It is extending all "deserializtion" into "parsing" that is
>> > pedantically wrong to do. But your "nothing to do" is
>> > exaggeration. Parsing is subset of activities, deserialization
>> > of text formats.
>>
>> (Note that the output from nm -CP is text, an address and a C++ name.)
>>
>> I was not aware at all that there is a distinction. If there is one,
>> it must be hard to draw the line. Recursive definition?
>>
>> Not that matters much.
>
> Are you saying the term has widened from linguistics (where parsing is
> semantic analysis of text) to computer science where it now means
> any kind of deserializations? I am last from whom to ask extent of
> modern English anyway.

I'm not an authority either.

I always assumed parsing meant reading any kind of data, deciding if
it matches the parser's language, and if it does, offering the
"pieces" in a helpful way to the next step of processing.

E.g. yacc is a parser generator, but in my mind so is scanf().

(And as background: I know for sure I was taught in computer science
that "language" is anything with a syntax and (I suppose) semantics.
It doesn't have to be Turing-complete or anything.)

>> The real reason I brought it up is that there's often a choice when
>> designing a data format:
>>
>> - use XML or JSON or similar, and you need help parsing it
>> - make up your own simpler format (often "key: value" is enough) and
>> you can make your own parser, can use normal Unix tools on it ...
>> but don't get any help from XML or JSON tools.
>>
>> This second option may not be popular right now, but it does exist.
>
> I myself like to use well-established portable formats, (like say png
> for raster picture). Then I use json for everything for what I don't
> have such format. That might result with lot of files that I prefer
> to zip into one file in Open Document Format style.

We probably solve different kinds of problems; I tend to do things
which fit in Unix pipelines.

[Tim Rentsch]

Jorgen Grahn <grahn...@snipabacken.se> writes:

[...]

> I always assumed parsing meant reading any kind of data, deciding if
> it matches the parser's language, and if it does, offering the
> "pieces" in a helpful way to the next step of processing.

This description is consistent with my own understanding and also
with the various definitions and other online resources I
consulted.

> E.g. yacc is a parser generator, but in my mind so is scanf().

I wouldn't say scanf() is a parser generator, because it doesn't
generate a parser but rather goes ahead and does (some) parsing.

Perhaps more significantly, usually scanf() is used to parse not
an entire language but only some part of an input, with other
calls to scanf() parsing other parts of the input (and hence
other parts of the language being accepted). To me scanf() is
closer to being a lexer than a parser. However these are minor
distinctions; it's fair to say that a scanf() call parses a
line (or some other part) of an input.

> (And as background: I know for sure I was taught in computer science
> that "language" is anything with a syntax and (I suppose) semantics.
> It doesn't have to be Turing-complete or anything.)

In formal Computer Science, a language is any set of strings over
a finite alphabet. In most cases we are concerned only with those
languages that can be recognized by a computer program, and so
necessarily have a finite (and well-defined) "grammar". I put the
word "grammar" in quotes only because computer programs are more
varied than what is generally meant by the word grammar.

By themselves languages are just sets of strings, and do not have
any associated semantics. However it is certainly right that
a language needn't be large or "complete" in any sense. The set
of strings { "cat", "dog" } qualifies as a language in formal
language theory.


> [...] I tend to do things which fit in Unix pipelines.

(Comment about English language usage only.) In English, this
sentence is better written using "that" in place of "which". The
reason is the word "that" is restrictive, whereas the word "which"
is non-restrictive. That should be enough so you can read a more
full description somewheres on the web. (Or if not ask and I will
try to track down a good reference.)

(Note: my comment is meant only to be helpful, not corrective. My
friends for whom English is not their first language tell me it's
helpful for them to hear remarks like this, so their English can
be better. That's all I'm trying to do here.)