Re: [E-devel] JSON

[Cedric BAIL]

On Mon, Jul 18, 2016 at 11:55 AM, Larry de Oliveira Lira Jr
 wrote:
> Cedric, I did a json_simple_parser and refactore the previous ejson to use
> that, maybe we need some adjusts to new promise and we push to a felipe
> branch, if you like to see the json_simple_parse maybe I can push a diff to
> phab  :D

Ok, cool ! Yes, please go ahead. It won't go in upstream before 1.19
anyway, so we have time for the review process.

Cedric

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON

[Larry de Oliveira Lira Jr]

Cedric, I did a json_simple_parser and refactore the previous ejson to use
that, maybe we need some adjusts to new promise and we push to a felipe
branch, if you like to see the json_simple_parse maybe I can push a diff to
phab  :D

Grato

Larry Jr.

On Mon, Jul 18, 2016 at 3:29 PM, Cedric BAIL  wrote:

> Hello,
>
> On Sun, Jul 17, 2016 at 6:56 AM, Felipe Magno de Almeida
>  wrote:
> > On Sun, Jul 10, 2016 at 5:39 PM, Andrew Williams 
> wrote:
> >> Thanks - is it in a Dev repo somewhere I could peek at or are you
> keeping
> >> it under wraps until APIs stabilise?
> >
> > I'll push to a branch. Sorry for the delay.
>
> Is it different from your ejson branch in its use of an external  json
> library ? I still dislike that idea quite a lot as it require to bring
> also new data type as no external library obviously use eina for data
> type.
>
> Ideally I would have preferred to see something like eina simple XML
> parser but for json in eina. Along with maybe a json->eina data type
> converter with some facility (like fetching a subpart of a json,
> checking a specific field given a path). Of course this could be
> pushed further and I see no reason why our way of describind data
> descriptor couldn't also be applied on XML and JSON. I wish I had more
> time as that was my initial plan for emile, but I kind of stopped way
> before reaching that point...
> --
> Cedric BAIL
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.http://sdm.link/zohodev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON

[Cedric BAIL]

Hello,

On Sun, Jul 17, 2016 at 6:56 AM, Felipe Magno de Almeida
 wrote:
> On Sun, Jul 10, 2016 at 5:39 PM, Andrew Williams  wrote:
>> Thanks - is it in a Dev repo somewhere I could peek at or are you keeping
>> it under wraps until APIs stabilise?
>
> I'll push to a branch. Sorry for the delay.

Is it different from your ejson branch in its use of an external  json
library ? I still dislike that idea quite a lot as it require to bring
also new data type as no external library obviously use eina for data
type.

Ideally I would have preferred to see something like eina simple XML
parser but for json in eina. Along with maybe a json->eina data type
converter with some facility (like fetching a subpart of a json,
checking a specific field given a path). Of course this could be
pushed further and I see no reason why our way of describind data
descriptor couldn't also be applied on XML and JSON. I wish I had more
time as that was my initial plan for emile, but I kind of stopped way
before reaching that point...
-- 
Cedric BAIL

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON

[Felipe Magno de Almeida]

On Sun, Jul 10, 2016 at 5:39 PM, Andrew Williams  wrote:
> Hi Felipe,
>
> Thanks - is it in a Dev repo somewhere I could peek at or are you keeping
> it under wraps until APIs stabilise?

I'll push to a branch. Sorry for the delay.

> Cheers,
> Andy

Regards,
-- 
Felipe Magno de Almeida

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON

[Andrew Williams]

Hi Felipe,

Thanks - is it in a Dev repo somewhere I could peek at or are you keeping
it under wraps until APIs stabilise?

Cheers,
Andy
On Sun, 10 Jul 2016 at 16:47, Felipe Magno de Almeida <
felipe.m.alme...@gmail.com> wrote:

> On Sat, Jul 9, 2016 at 7:29 PM, Andrew Williams 
> wrote:
> > Hi all,
>
> Hello Andrew,
>
> > So it's a web world and APIs are cool right - and it's all json or XML.
> > I can't find anywhere (outside of the is bindings) where we use json...
> >
> > Assuming I need to read such an API are there any preferences or advice
> for
> > how (library, string parsing) it should be done in an efl app to best fit
> > with how we do things?
>
> There's a JSON and XML data model we want to push, however the
> Data Model API is still in beta, so its development has not really
> finished because modifications in API are still coming in. But for 1.19
> this should be stable.
>
> > Thanks :)
> > Andrew
>
> Regards,
> --
> Felipe Magno de Almeida
>
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON

[Felipe Magno de Almeida]

On Sat, Jul 9, 2016 at 7:29 PM, Andrew Williams  wrote:
> Hi all,

Hello Andrew,

> So it's a web world and APIs are cool right - and it's all json or XML.
> I can't find anywhere (outside of the is bindings) where we use json...
>
> Assuming I need to read such an API are there any preferences or advice for
> how (library, string parsing) it should be done in an efl app to best fit
> with how we do things?

There's a JSON and XML data model we want to push, however the
Data Model API is still in beta, so its development has not really
finished because modifications in API are still coming in. But for 1.19
this should be stable.

> Thanks :)
> Andrew

Regards,
-- 
Felipe Magno de Almeida

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON

[David Seikel]

On Sat, 9 Jul 2016 20:59:14 -0400 Michael Blumenkrantz
 wrote:

> On Sat, 09 Jul 2016 22:29:20 +
> Andrew Williams  wrote:
> 
> > Hi all,
> > 
> > So it's a web world and APIs are cool right - and it's all json or
> > XML. I can't find anywhere (outside of the is bindings) where we
> > use json...
> > 
> > Assuming I need to read such an API are there any preferences or
> > advice for how (library, string parsing) it should be done in an
> > efl app to best fit with how we do things?
> > 
> > Thanks :)
> > Andrew
> 
> 
> Azy has some support for this. Example:
> 
> https://git.enlightenment.org/devs/discomfitor/maelstrom.git/tree/src/tests/azy/identi.ca

Azy is something I've got on my TODO list to try out, along with
Esskyuehl.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON

[David Seikel]

On Sun, 10 Jul 2016 10:34:20 +1000 David Seikel 
wrote:

> On Sat, 09 Jul 2016 22:29:20 + Andrew Williams
>  wrote:
> 
> > So it's a web world and APIs are cool right - and it's all json or
> > XML. I can't find anywhere (outside of the is bindings) where we use
> > json...
> > 
> > Assuming I need to read such an API are there any preferences or
> > advice for how (library, string parsing) it should be done in an efl
> > app to best fit with how we do things?
> 
> In my big 3D virtual world application, I intend on supporting XML,
> JSON, and all those other legacy bloated things by inventing some sort
> of lean binary protocol, and having the others be wrappers around
> that.  There's a number of ways I could do that, but it's early days,
> so no start on it yet.
> 
> I intend to try a few things, and test their performance.  One of the
> contenders is to use EET as the low level binary format.  Another is
> to just use ordinary compression.
> 
> While as you say, all the cool kids are using bloated, text based,
> "human readable", file and network protocols, coz it makes it easy for
> developers to read and write it.  99.999% of the time it's computers
> that have to spend extra resources dealing with these hard for
> computers to read bloated protocols, humans never get a look in, all
> they do is take up more space and slow things down.  So in my new
> virtual world, those few developers that actually think they need to
> use bloated protocols to make things easier for them, can supply all
> the extra CPU, RAM, and network resources they want to waste, and the
> rest of us can enjoy proper lean binary protocols.  The dumb
> developers can run their own bloated legacy wrappers on their own
> hardware when they actually need it, keep that crap out of our faces
> the rest of the time.
> 
> As for dealing with web based JSON for now, I have a Lua script around
> here somewhere that used some library or other, I'd be using that, if
> I could find it again.  I'll have another look later today.

http://fperrad.github.io/lua-Spore/

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON

[Michael Blumenkrantz]

On Sat, 09 Jul 2016 22:29:20 +
Andrew Williams  wrote:

> Hi all,
> 
> So it's a web world and APIs are cool right - and it's all json or XML.
> I can't find anywhere (outside of the is bindings) where we use json...
> 
> Assuming I need to read such an API are there any preferences or advice for
> how (library, string parsing) it should be done in an efl app to best fit
> with how we do things?
> 
> Thanks :)
> Andrew


Azy has some support for this. Example:

https://git.enlightenment.org/devs/discomfitor/maelstrom.git/tree/src/tests/azy/identi.ca

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON

[David Seikel]

On Sat, 09 Jul 2016 22:29:20 + Andrew Williams
 wrote:

> So it's a web world and APIs are cool right - and it's all json or
> XML. I can't find anywhere (outside of the is bindings) where we use
> json...
> 
> Assuming I need to read such an API are there any preferences or
> advice for how (library, string parsing) it should be done in an efl
> app to best fit with how we do things?

In my big 3D virtual world application, I intend on supporting XML,
JSON, and all those other legacy bloated things by inventing some sort
of lean binary protocol, and having the others be wrappers around
that.  There's a number of ways I could do that, but it's early days,
so no start on it yet.

I intend to try a few things, and test their performance.  One of the
contenders is to use EET as the low level binary format.  Another is
to just use ordinary compression.

While as you say, all the cool kids are using bloated, text based,
"human readable", file and network protocols, coz it makes it easy for
developers to read and write it.  99.999% of the time it's computers
that have to spend extra resources dealing with these hard for
computers to read bloated protocols, humans never get a look in, all
they do is take up more space and slow things down.  So in my new
virtual world, those few developers that actually think they need to
use bloated protocols to make things easier for them, can supply all
the extra CPU, RAM, and network resources they want to waste, and the
rest of us can enjoy proper lean binary protocols.  The dumb developers
can run their own bloated legacy wrappers on their own hardware when
they actually need it, keep that crap out of our faces the rest of the
time.

As for dealing with web based JSON for now, I have a Lua script around
here somewhere that used some library or other, I'd be using that, if I
could find it again.  I'll have another look later today.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[The Rasterman]

On Thu, 2 May 2013 04:49:27 +0100 Michael Blumenkrantz
michael.blumenkra...@gmail.com said:

 On Thu, May 2, 2013 at 1:04 AM, Carsten Haitzler ras...@rasterman.comwrote:
 
  On Wed, 1 May 2013 14:56:32 +0100 Michael Blumenkrantz
  michael.blumenkra...@gmail.com said:
 
   cJSON, at least, exposes no hashes, lists, or any of that; I don't know
   what crazy parsers you kids have been using which do this, but they
   shouldn't since JSON doesn't have any concept of such things.
 
  errr.. json is really a tree of string key - values (where value can be a
  subtree) so thus by nature its a list and/or hash of strings and/or
  subtrees
  make sense.
 
 
 If you're using JSON for RPC, it doesn't make sense. This is a very common
 use case.

but that is not the point of the json parser jackdaniels etc. are talking
about. it is meant to load and store large blobs of structured data... not much
unlike edc files... so you need to have the view of general usage where it may
easily be pushed to load large blobs of json of a few mb a pop...

   This is all the code I have which uses an external JSON parser at
  present.
   It serializes and deserializes JSON-RPC (based on latest draft spec) very
   pedantically to/from Eina_Value, and all strings get stringshared.
  
  
  http://git.enlightenment.org/devs/discomfitor/maelstrom.git/tree/src/lib/azy/azy_content_json.c
 
  ok. so still about 500 loc to drive cjson and convert back to data structs
  (eina-value in this case). and... behind getobjectitem in cjson is
  probably
  a hash... and probably a set of lists... etc. duplicating strings inside of
   cjson that then are extracted and stuffed into stringshare strings. :)
 
 
  and we ned up with another fun thing... to use cjson... at least ubuntu
  users
  can't just apt-get install it. no package. so we have to copy it into the
  efl
  tree or make packages or force pl to download and compile it just for a
  small
  lib dep... and it nicely comes with a zip file with no makefile or
  configure...
  or any build infra, with __MACOSX metadata hidden files all thru the zip...
  good luck with that.
 
 Oh noes, scary __UNDERSCORE files and lack of build system which are
 irrelevant when importing the source!

it's more a matter of saying we dont have to maintain a json parser then if we
just use an external one... if u import it.. then u are going to be
maintaining it. if you don't then the above pretty much means its not available
as a package to link to AND has a low chance of acceptance asking people to go
download the zip file and figure out how to compile a .so themselves by hand. i
covered the case of importing as the other option below.

  so import the src entirely is the only way... and then... take a read of
  the
  src. seriously. once we import it we will have to fix it and maintain it
  entirely... THIS is just one of many functions where the WHOLE function
  including definition is on a single line:
 
  void   cJSON_ReplaceItemInObject(cJSON *object,const char *string,cJSON
  *newitem){int i=0;cJSON *c=object-child;while(c  cJSON_strcasecmp
  (c-string,string))i++,c=c-next;if(c){newitem-string=cJSON_strdup
  (string);cJSON_ReplaceItemInArray(object,i,newitem);}}
 
  no newlines. there's a whole batch of these 11-liner funcs there, it's not
  a
  one-off oh an i was wrong. it has no lists or hashes. it just has arrays of
  string-value and cJSON_GetObjectItem is... a linear O(n) walk thru the
  array
  strcmping every item until key found, then return... so for objects with
  lots
  of keys... we're talking a lot of walking... might be doable for like
  things
  with  10 keys... not so for a more expansive and generic need.
 
  so a quick 5 minute evaluation of cjson tells me:
 
  1. we can't just link to it... and HAVE to import it.
 
 That's the entire idea behind having a sub-1000 line parser, which is one
 of the cornerstones of Cedric's stance that we should write our won.

it then means we end up forking it and having to maintain it.

  2. it's coding conventions are far from what we are used to and do in efl
  land,
  so we'll have a nice sore thumb inside our src tree.
 
 Cedric's coding conventions are pretty far from it too, but we still let
 him work on Edje.

read cjson. not only is it pretty far... its in a whole other galaxy...
seriously. entire functions in 1 line of code with almost zero whitespace
we'll end up reformatting these just to read it... and once we reformat.. we
fork. and when we fork.. we now maintain fully. like all forks it becomes
totally our cost/responsibility.

  3. it will duplicate all things via strdups so we can't hope to minimize
  string copies in memory.
 
 
 Not a great argument since we could easily just s/strdup/stringshare/.

as above. becomes a fork. when we then make it use eina hash too and more
internally we basically now maintain a json parser anyway.. it just STARTED
life as copy someone elses but after that it's out job entirely.

  4. walking cjson 

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[Michael Blumenkrantz]

I argued vehemently against having an xml parser in eina, and the same
principle applies here. Too bad I seem to always be on the losing side of
these types of decisions.


On Wed, May 1, 2013 at 10:38 AM, Tom Hacohen tom.haco...@samsung.comwrote:

 Hey guys,

 It recently came to my attention (a week ago) that JackDanielZ is
 writing a JSON parser to go into the EFL.
 I've been arguing against it on IRC, but I think it's time to post it here.

 Although most of us (some more than others) suffer from a severe case of
 NIH, I think this is really going one step too far.

 Sure, a JSON parser is easy to implement and is sub 1000 lines of codes.
 That on it's own is not a good enough reason to get it in.
 We already have enough code to maintain. We always complain that we
 don't have enough people to do X and Y. The reason for that is we insist
 or adding more code we need to maintain instead of using one of the many
 available solutions.

 There are:
 json-c, yajl and jansson to name a few.

 It's crazy to re-implement it. We'll have to test it on our own,
 maintain it, document it, debug it and other kinds of unwanted extra work.

 Together we can stop this madness. Just send NOMOREDUP to 1212 to
 donate £5 to the effort. Hm... I meant, just reply to this email and
 voice your opinion. No more useless code duplication.

 --
 Tom.



 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
 Get 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% overhead
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap1
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[David Seikel]

On Wed, 1 May 2013 10:43:39 +0100 Michael Blumenkrantz
michael.blumenkra...@gmail.com wrote:

 I argued vehemently against having an xml parser in eina, and the same
 principle applies here. Too bad I seem to always be on the losing
 side of these types of decisions.

/me pushes Mike to the pro JSON side, so it looses.

 On Wed, May 1, 2013 at 10:38 AM, Tom Hacohen
 tom.haco...@samsung.comwrote:
 
  Hey guys,
 
  It recently came to my attention (a week ago) that JackDanielZ is
  writing a JSON parser to go into the EFL.
  I've been arguing against it on IRC, but I think it's time to post
  it here.
 
  Although most of us (some more than others) suffer from a severe
  case of NIH, I think this is really going one step too far.
 
  Sure, a JSON parser is easy to implement and is sub 1000 lines of
  codes. That on it's own is not a good enough reason to get it in.
  We already have enough code to maintain. We always complain that we
  don't have enough people to do X and Y. The reason for that is we
  insist or adding more code we need to maintain instead of using one
  of the many available solutions.
 
  There are:
  json-c, yajl and jansson to name a few.
 
  It's crazy to re-implement it. We'll have to test it on our own,
  maintain it, document it, debug it and other kinds of unwanted
  extra work.
 
  Together we can stop this madness. Just send NOMOREDUP to 1212 to
  donate £5 to the effort. Hm... I meant, just reply to this email and
  voice your opinion. No more useless code duplication.

If I remember correctly, not that I've actually tried it yet, eet was
supposed to be usable as a wire protocol.  JSON is yet another wire
protocol, so it's a duplication of features that we don't need.

In another project I have a user wanting a JSON interface.  I said
fine, write one yourself, as a stand alone binary that wraps around
the more efficient real wire protocol.  If you want that sort of bloat,
you put up with it yourself, keep it out of every one elses faces.
After all, people that like bloaty shit should not mind it being a
little more bloaty, and the rest of us can avoid it entirely.

So JackDanielZ could write his JSON parser as a stand alone wrapper
around eet, but keep it out of EFL, and every one is happy.  In this
way, people have more choice, those that want to actually use JSON can,
those that don't can use the more efficient protocol directly, and as a
bonus, compatibility in all apps between the two protocols.

Then he can make Mike even happier, by rewriting the EFL XML parser as a
layer around file based eet, and moving that to a separate binary as
well.  After all, he would by then have plenty of experience in
wrapping eet with bloat.  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[David Seikel]

On Wed, 1 May 2013 20:12:25 +1000 David Seikel onef...@gmail.com
wrote:

 On Wed, 1 May 2013 10:43:39 +0100 Michael Blumenkrantz
 michael.blumenkra...@gmail.com wrote:
 
  I argued vehemently against having an xml parser in eina, and the
  same principle applies here. Too bad I seem to always be on the
  losing side of these types of decisions.
 
 /me pushes Mike to the pro JSON side, so it looses.
 
  On Wed, May 1, 2013 at 10:38 AM, Tom Hacohen
  tom.haco...@samsung.comwrote:
  
   Hey guys,
  
   It recently came to my attention (a week ago) that JackDanielZ is
   writing a JSON parser to go into the EFL.
   I've been arguing against it on IRC, but I think it's time to post
   it here.
  
   Although most of us (some more than others) suffer from a severe
   case of NIH, I think this is really going one step too far.
  
   Sure, a JSON parser is easy to implement and is sub 1000 lines of
   codes. That on it's own is not a good enough reason to get it in.
   We already have enough code to maintain. We always complain that
   we don't have enough people to do X and Y. The reason for that is
   we insist or adding more code we need to maintain instead of
   using one of the many available solutions.
  
   There are:
   json-c, yajl and jansson to name a few.
  
   It's crazy to re-implement it. We'll have to test it on our own,
   maintain it, document it, debug it and other kinds of unwanted
   extra work.
  
   Together we can stop this madness. Just send NOMOREDUP to 1212
   to donate £5 to the effort. Hm... I meant, just reply to this
   email and voice your opinion. No more useless code duplication.
 
 If I remember correctly, not that I've actually tried it yet, eet was
 supposed to be usable as a wire protocol.  JSON is yet another wire
 protocol, so it's a duplication of features that we don't need.
 
 In another project I have a user wanting a JSON interface.  I said
 fine, write one yourself, as a stand alone binary that wraps around
 the more efficient real wire protocol.  If you want that sort of
 bloat, you put up with it yourself, keep it out of every one elses
 faces. After all, people that like bloaty shit should not mind it
 being a little more bloaty, and the rest of us can avoid it entirely.
 
 So JackDanielZ could write his JSON parser as a stand alone wrapper
 around eet, but keep it out of EFL, and every one is happy.  In this
 way, people have more choice, those that want to actually use JSON
 can, those that don't can use the more efficient protocol directly,
 and as a bonus, compatibility in all apps between the two protocols.
 
 Then he can make Mike even happier, by rewriting the EFL XML parser
 as a layer around file based eet, and moving that to a separate
 binary as well.  After all, he would by then have plenty of
 experience in wrapping eet with bloat.  B-)

I forgot to mention, we already have a precedent for this - the edje
compiler is a wrapper around a bloated human language that produces
nice efficient eet binaries.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[Tom Hacohen]

On 01/05/13 11:12, David Seikel wrote:
 On Wed, 1 May 2013 10:43:39 +0100 Michael Blumenkrantz
 michael.blumenkra...@gmail.com wrote:

 I argued vehemently against having an xml parser in eina, and the same
 principle applies here. Too bad I seem to always be on the losing
 side of these types of decisions.

 /me pushes Mike to the pro JSON side, so it looses.

 On Wed, May 1, 2013 at 10:38 AM, Tom Hacohen
 tom.haco...@samsung.comwrote:

 Hey guys,

 It recently came to my attention (a week ago) that JackDanielZ is
 writing a JSON parser to go into the EFL.
 I've been arguing against it on IRC, but I think it's time to post
 it here.

 Although most of us (some more than others) suffer from a severe
 case of NIH, I think this is really going one step too far.

 Sure, a JSON parser is easy to implement and is sub 1000 lines of
 codes. That on it's own is not a good enough reason to get it in.
 We already have enough code to maintain. We always complain that we
 don't have enough people to do X and Y. The reason for that is we
 insist or adding more code we need to maintain instead of using one
 of the many available solutions.

 There are:
 json-c, yajl and jansson to name a few.

 It's crazy to re-implement it. We'll have to test it on our own,
 maintain it, document it, debug it and other kinds of unwanted
 extra work.

 Together we can stop this madness. Just send NOMOREDUP to 1212 to
 donate £5 to the effort. Hm... I meant, just reply to this email and
 voice your opinion. No more useless code duplication.

 If I remember correctly, not that I've actually tried it yet, eet was
 supposed to be usable as a wire protocol.  JSON is yet another wire
 protocol, so it's a duplication of features that we don't need.

 In another project I have a user wanting a JSON interface.  I said
 fine, write one yourself, as a stand alone binary that wraps around
 the more efficient real wire protocol.  If you want that sort of bloat,
 you put up with it yourself, keep it out of every one elses faces.
 After all, people that like bloaty shit should not mind it being a
 little more bloaty, and the rest of us can avoid it entirely.

 So JackDanielZ could write his JSON parser as a stand alone wrapper
 around eet, but keep it out of EFL, and every one is happy.  In this
 way, people have more choice, those that want to actually use JSON can,
 those that don't can use the more efficient protocol directly, and as a
 bonus, compatibility in all apps between the two protocols.

 Then he can make Mike even happier, by rewriting the EFL XML parser as a
 layer around file based eet, and moving that to a separate binary as
 well.  After all, he would by then have plenty of experience in
 wrapping eet with bloat.  B-)

He wants to use JSON as a text way of representing data. I.e he's aiming 
to replace the eet language, not the eet binary protocol. So it's not 
exactly that.

Even if it was an outside of the efl but in e land project, it would 
have been a PITA, as we'd still have to maintain it.

The point here is not whether or not Daniel should use JSON, but more: 
should we accept this unneeded wheel re-invention.

--
Tom.



--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[Cedric BAIL]

On Wed, May 1, 2013 at 6:38 PM, Tom Hacohen tom.haco...@samsung.com wrote:
 It recently came to my attention (a week ago) that JackDanielZ is
 writing a JSON parser to go into the EFL.
 I've been arguing against it on IRC, but I think it's time to post it here.

 Although most of us (some more than others) suffer from a severe case of
 NIH, I think this is really going one step too far.

 Sure, a JSON parser is easy to implement and is sub 1000 lines of codes.
 That on it's own is not a good enough reason to get it in.
 We already have enough code to maintain. We always complain that we
 don't have enough people to do X and Y. The reason for that is we insist
 or adding more code we need to maintain instead of using one of the many
 available solutions.

 There are:
 json-c, yajl and jansson to name a few.

 It's crazy to re-implement it. We'll have to test it on our own,
 maintain it, document it, debug it and other kinds of unwanted extra work.

So you are arguing that linking to a library of 1000 lines is better.
And witch one to choose. Let take the fastest one in fact, QT Json
implementation is the fastest one by an order of magnitude. So if I
start an EFL application and I want the fastest JSON implementation, I
am better using QT... Sounds like a very good idea to me.

Also all implementation have draw back, first all of them come with
their own hash implementation, their own list implementation and all
of them do not integrate with our own code. So you can convert the
result to Eina_Value by yourself from a cjson object or any other
implementation, remember they are 10 times slower than the Qt one, and
now you even do a convertion adding insult to injury. It is just a non
competitive and viable solution.

Oh, and it is so difficult and dramatic to write a JSON parser that we
already have one implemented in an Everything module and nobody did
complain about it. Why ? Because the standard is simple, once
implemented their is no maintenance their. We need just a properly
implemented one that does integrate with our code and is as fast as
the Qt implementation. Oh, and we already have the Qt benchmark to
start with, so not as if we will push something slower or non
competitive.

And apparently people are using JSON quite a lot those day, not
providing a proper and viable solution is not going to help us at all
here. But sure we can recommend people to link to the fastest
implementation...
--
Cedric BAIL

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[The Rasterman]

On Wed, 1 May 2013 21:13:37 +0900 Cedric BAIL cedric.b...@free.fr said:

 On Wed, May 1, 2013 at 6:38 PM, Tom Hacohen tom.haco...@samsung.com wrote:
  It recently came to my attention (a week ago) that JackDanielZ is
  writing a JSON parser to go into the EFL.
  I've been arguing against it on IRC, but I think it's time to post it here.
 
  Although most of us (some more than others) suffer from a severe case of
  NIH, I think this is really going one step too far.
 
  Sure, a JSON parser is easy to implement and is sub 1000 lines of codes.
  That on it's own is not a good enough reason to get it in.
  We already have enough code to maintain. We always complain that we
  don't have enough people to do X and Y. The reason for that is we insist
  or adding more code we need to maintain instead of using one of the many
  available solutions.
 
  There are:
  json-c, yajl and jansson to name a few.
 
  It's crazy to re-implement it. We'll have to test it on our own,
  maintain it, document it, debug it and other kinds of unwanted extra work.
 
 So you are arguing that linking to a library of 1000 lines is better.
 And witch one to choose. Let take the fastest one in fact, QT Json
 implementation is the fastest one by an order of magnitude. So if I
 start an EFL application and I want the fastest JSON implementation, I
 am better using QT... Sounds like a very good idea to me.
 
 Also all implementation have draw back, first all of them come with
 their own hash implementation, their own list implementation and all
 of them do not integrate with our own code. So you can convert the
 result to Eina_Value by yourself from a cjson object or any other
 implementation, remember they are 10 times slower than the Qt one, and
 now you even do a convertion adding insult to injury. It is just a non
 competitive and viable solution.
 
 Oh, and it is so difficult and dramatic to write a JSON parser that we
 already have one implemented in an Everything module and nobody did
 complain about it. Why ? Because the standard is simple, once
 implemented their is no maintenance their. We need just a properly
 implemented one that does integrate with our code and is as fast as
 the Qt implementation. Oh, and we already have the Qt benchmark to
 start with, so not as if we will push something slower or non
 competitive.
 
 And apparently people are using JSON quite a lot those day, not
 providing a proper and viable solution is not going to help us at all
 here. But sure we can recommend people to link to the fastest
 implementation...

i will say.. it depends on the parser. if its sax-like then it doesnt
expose/fill in any data structs etc. but if it is exposing hashes, lists etc.
then the usefulness of a non-efl parser becomes exceedingly low as we now
invest 1k lines of code in converting/transporting data back and forth anyway.

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[Tom Hacohen]

On 01/05/13 13:13, Cedric BAIL wrote:
 On Wed, May 1, 2013 at 6:38 PM, Tom Hacohen tom.haco...@samsung.com wrote:
 It recently came to my attention (a week ago) that JackDanielZ is
 writing a JSON parser to go into the EFL.
 I've been arguing against it on IRC, but I think it's time to post it here.

 Although most of us (some more than others) suffer from a severe case of
 NIH, I think this is really going one step too far.

 Sure, a JSON parser is easy to implement and is sub 1000 lines of codes.
 That on it's own is not a good enough reason to get it in.
 We already have enough code to maintain. We always complain that we
 don't have enough people to do X and Y. The reason for that is we insist
 or adding more code we need to maintain instead of using one of the many
 available solutions.

 There are:
 json-c, yajl and jansson to name a few.

 It's crazy to re-implement it. We'll have to test it on our own,
 maintain it, document it, debug it and other kinds of unwanted extra work.

 So you are arguing that linking to a library of 1000 lines is better.
 And witch one to choose. Let take the fastest one in fact, QT Json
 implementation is the fastest one by an order of magnitude. So if I
 start an EFL application and I want the fastest JSON implementation, I
 am better using QT... Sounds like a very good idea to me.

 Also all implementation have draw back, first all of them come with
 their own hash implementation, their own list implementation and all
 of them do not integrate with our own code. So you can convert the
 result to Eina_Value by yourself from a cjson object or any other
 implementation, remember they are 10 times slower than the Qt one, and
 now you even do a convertion adding insult to injury. It is just a non
 competitive and viable solution.

 Oh, and it is so difficult and dramatic to write a JSON parser that we
 already have one implemented in an Everything module and nobody did
 complain about it. Why ? Because the standard is simple, once
 implemented their is no maintenance their. We need just a properly
 implemented one that does integrate with our code and is as fast as
 the Qt implementation. Oh, and we already have the Qt benchmark to
 start with, so not as if we will push something slower or non
 competitive.

 And apparently people are using JSON quite a lot those day, not
 providing a proper and viable solution is not going to help us at all
 here. But sure we can recommend people to link to the fastest
 implementation...

You have said it yourself, you haven't given cJSON a try, you don't know 
if it's indeed slow than the Qt implementation.

The only reason no one has noticed and commented about the one in 
Everything is that no one ever looked at that code. Had I noticed, I 
would have commented about it before.

Mike can interject, as he has used cJSON before, and I don't remember 
him mentioning any issues.


Your main argument is the speed, though I have requested benchmarks and 
comparisons with eina_json yet I have seen none. If it's so simple to 
implement, how come there are so many implementations? How come they 
vary in speed so much? And where do we stand compared to others?

--
Tom.


--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[daniel.za...@samsung.com]

On 05/01/2013 04:02 PM, Tom Hacohen wrote:
 On 01/05/13 13:13, Cedric BAIL wrote:
 On Wed, May 1, 2013 at 6:38 PM, Tom Hacohen tom.haco...@samsung.com wrote:
 It recently came to my attention (a week ago) that JackDanielZ is
 writing a JSON parser to go into the EFL.
 I've been arguing against it on IRC, but I think it's time to post it here.

 Although most of us (some more than others) suffer from a severe case of
 NIH, I think this is really going one step too far.

 Sure, a JSON parser is easy to implement and is sub 1000 lines of codes.
 That on it's own is not a good enough reason to get it in.
 We already have enough code to maintain. We always complain that we
 don't have enough people to do X and Y. The reason for that is we insist
 or adding more code we need to maintain instead of using one of the many
 available solutions.

 There are:
 json-c, yajl and jansson to name a few.

 It's crazy to re-implement it. We'll have to test it on our own,
 maintain it, document it, debug it and other kinds of unwanted extra work.
 So you are arguing that linking to a library of 1000 lines is better.
 And witch one to choose. Let take the fastest one in fact, QT Json
 implementation is the fastest one by an order of magnitude. So if I
 start an EFL application and I want the fastest JSON implementation, I
 am better using QT... Sounds like a very good idea to me.

 Also all implementation have draw back, first all of them come with
 their own hash implementation, their own list implementation and all
 of them do not integrate with our own code. So you can convert the
 result to Eina_Value by yourself from a cjson object or any other
 implementation, remember they are 10 times slower than the Qt one, and
 now you even do a convertion adding insult to injury. It is just a non
 competitive and viable solution.

 Oh, and it is so difficult and dramatic to write a JSON parser that we
 already have one implemented in an Everything module and nobody did
 complain about it. Why ? Because the standard is simple, once
 implemented their is no maintenance their. We need just a properly
 implemented one that does integrate with our code and is as fast as
 the Qt implementation. Oh, and we already have the Qt benchmark to
 start with, so not as if we will push something slower or non
 competitive.

 And apparently people are using JSON quite a lot those day, not
 providing a proper and viable solution is not going to help us at all
 here. But sure we can recommend people to link to the fastest
 implementation...
 You have said it yourself, you haven't given cJSON a try, you don't know
 if it's indeed slow than the Qt implementation.

 The only reason no one has noticed and commented about the one in
 Everything is that no one ever looked at that code. Had I noticed, I
 would have commented about it before.

 Mike can interject, as he has used cJSON before, and I don't remember
 him mentioning any issues.


 Your main argument is the speed, though I have requested benchmarks and
 comparisons with eina_json yet I have seen none. If it's so simple to
 implement, how come there are so many implementations? How come they
 vary in speed so much? And where do we stand compared to others?
Tom, you know that the reason why we didn't provide benchmarks yet is 
that because we have feature requests from HQ. Sure, we will check the 
perfs.

Concerning the JSON parser itself, except the benchmarks comparison + 
minor finalization, it is ready. So it just depends on the vote and 
really, the decision doesn't matter to me. I hate being between the EFL 
old couple (i.e Tom and Cedric). Well, maybe I like that.

I will create a branch for that soon so you will be able to look and 
complain.

 --
 Tom.


 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
 Get 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% overhead
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap1
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[Michael Blumenkrantz]

One of the reasons for not doing this is to not do it; you save those
developer resources and put them towards something useful. Saying I'll
have a branch with it implemented soon completely ignores that.


On Wed, May 1, 2013 at 2:22 PM, daniel.za...@samsung.com 
daniel.za...@samsung.com wrote:

 On 05/01/2013 04:02 PM, Tom Hacohen wrote:
  On 01/05/13 13:13, Cedric BAIL wrote:
  On Wed, May 1, 2013 at 6:38 PM, Tom Hacohen tom.haco...@samsung.com
 wrote:
  It recently came to my attention (a week ago) that JackDanielZ is
  writing a JSON parser to go into the EFL.
  I've been arguing against it on IRC, but I think it's time to post it
 here.
 
  Although most of us (some more than others) suffer from a severe case
 of
  NIH, I think this is really going one step too far.
 
  Sure, a JSON parser is easy to implement and is sub 1000 lines of
 codes.
  That on it's own is not a good enough reason to get it in.
  We already have enough code to maintain. We always complain that we
  don't have enough people to do X and Y. The reason for that is we
 insist
  or adding more code we need to maintain instead of using one of the
 many
  available solutions.
 
  There are:
  json-c, yajl and jansson to name a few.
 
  It's crazy to re-implement it. We'll have to test it on our own,
  maintain it, document it, debug it and other kinds of unwanted extra
 work.
  So you are arguing that linking to a library of 1000 lines is better.
  And witch one to choose. Let take the fastest one in fact, QT Json
  implementation is the fastest one by an order of magnitude. So if I
  start an EFL application and I want the fastest JSON implementation, I
  am better using QT... Sounds like a very good idea to me.
 
  Also all implementation have draw back, first all of them come with
  their own hash implementation, their own list implementation and all
  of them do not integrate with our own code. So you can convert the
  result to Eina_Value by yourself from a cjson object or any other
  implementation, remember they are 10 times slower than the Qt one, and
  now you even do a convertion adding insult to injury. It is just a non
  competitive and viable solution.
 
  Oh, and it is so difficult and dramatic to write a JSON parser that we
  already have one implemented in an Everything module and nobody did
  complain about it. Why ? Because the standard is simple, once
  implemented their is no maintenance their. We need just a properly
  implemented one that does integrate with our code and is as fast as
  the Qt implementation. Oh, and we already have the Qt benchmark to
  start with, so not as if we will push something slower or non
  competitive.
 
  And apparently people are using JSON quite a lot those day, not
  providing a proper and viable solution is not going to help us at all
  here. But sure we can recommend people to link to the fastest
  implementation...
  You have said it yourself, you haven't given cJSON a try, you don't know
  if it's indeed slow than the Qt implementation.
 
  The only reason no one has noticed and commented about the one in
  Everything is that no one ever looked at that code. Had I noticed, I
  would have commented about it before.
 
  Mike can interject, as he has used cJSON before, and I don't remember
  him mentioning any issues.
 
 
  Your main argument is the speed, though I have requested benchmarks and
  comparisons with eina_json yet I have seen none. If it's so simple to
  implement, how come there are so many implementations? How come they
  vary in speed so much? And where do we stand compared to others?
 Tom, you know that the reason why we didn't provide benchmarks yet is
 that because we have feature requests from HQ. Sure, we will check the
 perfs.

 Concerning the JSON parser itself, except the benchmarks comparison +
 minor finalization, it is ready. So it just depends on the vote and
 really, the decision doesn't matter to me. I hate being between the EFL
 old couple (i.e Tom and Cedric). Well, maybe I like that.

 I will create a branch for that soon so you will be able to look and
 complain.
 
  --
  Tom.
 
 
 
 --
  Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
  Get 100% visibility into your production application - at no cost.
  Code-level diagnostics for performance bottlenecks with 2% overhead
  Download for free and get started troubleshooting in minutes.
  http://p.sf.net/sfu/appdyn_d2d_ap1
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 



 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
 Get 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% 

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[Tom Hacohen]

On 01/05/13 14:15, Cedric BAIL wrote:
 WTF ! I am not saying that without a benchmark ! Where do you think
 that came from ? Just random praising for the fun ?

You said you haven't tested cJSON, only json-c. I asked you about it!
 Because there is no complexity there. It just work. There is no
 maintenance cost. There is no need to bring an external dependency for
 100 lines of code.

Pfft yeah, sounds like every other piece of code every written.


 Mike can interject, as he has used cJSON before, and I don't remember him
 mentioning any issues.

 So running cJSON, then converting to Eina_Value or C structure by hand
 in the application side is faster than just running a stupid automate
 that produce them in the first place...

Let's wait for mike. I wonder what he did. Also I wonder if you'd end up 
changing the Eina_Value and lists to your own struct anyway 99.99% of 
the time. Surely there must be a lib that let's you parse it straight to 
your data type, but that might be slower.


 Your main argument is the speed, though I have requested benchmarks and
 comparisons with eina_json yet I have seen none. If it's so simple to
 implement, how come there are so many implementations? How come they vary in
 speed so much? And where do we stand compared to others?

 Because it is damn easy to write one implementation ! Because most of
 the speed doesn't come from the parser automate who is always the same
 stupid table, but from the hash, object, list and array object
 manipulated. That is where the cost come from. And I am not only
 arguing about speed, but also integration and simplicity of use.
 Really forcing everyone to link with another library for less than
 1000 lines of code, to have another object api to manipulate, to do
 all the conversion manually is a great help to every one. Of course it
 is doable in the application. Of course you can write your own, it is
 so damn easy.

 As for the benchmark, we are going to reuse the one written by QT. I
 am going to do proper review and cleaning as necessary after 1.9,
 there is nothing to look at at this stage. I have already spend more
 time arguing on that subject that I am sure it will take me to write
 an implementation from scratch and likely to ever maintain it.

Let's wait for the benchmarks then. I find it really odd that the only 
different in speed is the implementations of the hash-tables and lists.

--
Tom.


--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[The Rasterman]

On Wed, 1 May 2013 14:26:12 +0100 Michael Blumenkrantz
michael.blumenkra...@gmail.com said:

that makes sense.. but it seems that its already done. as per my comment.. if
its exporting eina lists/hashes etc... then it pretty much has to be a newly
written json parser as it has to deal with our datatypes. otherwise we just
convert from someone elses and that ends up just as much work and we're arguing
over a moot point.

 One of the reasons for not doing this is to not do it; you save those
 developer resources and put them towards something useful. Saying I'll
 have a branch with it implemented soon completely ignores that.
 
 
 On Wed, May 1, 2013 at 2:22 PM, daniel.za...@samsung.com 
 daniel.za...@samsung.com wrote:
 
  On 05/01/2013 04:02 PM, Tom Hacohen wrote:
   On 01/05/13 13:13, Cedric BAIL wrote:
   On Wed, May 1, 2013 at 6:38 PM, Tom Hacohen tom.haco...@samsung.com
  wrote:
   It recently came to my attention (a week ago) that JackDanielZ is
   writing a JSON parser to go into the EFL.
   I've been arguing against it on IRC, but I think it's time to post it
  here.
  
   Although most of us (some more than others) suffer from a severe case
  of
   NIH, I think this is really going one step too far.
  
   Sure, a JSON parser is easy to implement and is sub 1000 lines of
  codes.
   That on it's own is not a good enough reason to get it in.
   We already have enough code to maintain. We always complain that we
   don't have enough people to do X and Y. The reason for that is we
  insist
   or adding more code we need to maintain instead of using one of the
  many
   available solutions.
  
   There are:
   json-c, yajl and jansson to name a few.
  
   It's crazy to re-implement it. We'll have to test it on our own,
   maintain it, document it, debug it and other kinds of unwanted extra
  work.
   So you are arguing that linking to a library of 1000 lines is better.
   And witch one to choose. Let take the fastest one in fact, QT Json
   implementation is the fastest one by an order of magnitude. So if I
   start an EFL application and I want the fastest JSON implementation, I
   am better using QT... Sounds like a very good idea to me.
  
   Also all implementation have draw back, first all of them come with
   their own hash implementation, their own list implementation and all
   of them do not integrate with our own code. So you can convert the
   result to Eina_Value by yourself from a cjson object or any other
   implementation, remember they are 10 times slower than the Qt one, and
   now you even do a convertion adding insult to injury. It is just a non
   competitive and viable solution.
  
   Oh, and it is so difficult and dramatic to write a JSON parser that we
   already have one implemented in an Everything module and nobody did
   complain about it. Why ? Because the standard is simple, once
   implemented their is no maintenance their. We need just a properly
   implemented one that does integrate with our code and is as fast as
   the Qt implementation. Oh, and we already have the Qt benchmark to
   start with, so not as if we will push something slower or non
   competitive.
  
   And apparently people are using JSON quite a lot those day, not
   providing a proper and viable solution is not going to help us at all
   here. But sure we can recommend people to link to the fastest
   implementation...
   You have said it yourself, you haven't given cJSON a try, you don't know
   if it's indeed slow than the Qt implementation.
  
   The only reason no one has noticed and commented about the one in
   Everything is that no one ever looked at that code. Had I noticed, I
   would have commented about it before.
  
   Mike can interject, as he has used cJSON before, and I don't remember
   him mentioning any issues.
  
  
   Your main argument is the speed, though I have requested benchmarks and
   comparisons with eina_json yet I have seen none. If it's so simple to
   implement, how come there are so many implementations? How come they
   vary in speed so much? And where do we stand compared to others?
  Tom, you know that the reason why we didn't provide benchmarks yet is
  that because we have feature requests from HQ. Sure, we will check the
  perfs.
 
  Concerning the JSON parser itself, except the benchmarks comparison +
  minor finalization, it is ready. So it just depends on the vote and
  really, the decision doesn't matter to me. I hate being between the EFL
  old couple (i.e Tom and Cedric). Well, maybe I like that.
 
  I will create a branch for that soon so you will be able to look and
  complain.
  
   --
   Tom.
  
  
  
  --
   Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
   Get 100% visibility into your production application - at no cost.
   Code-level diagnostics for performance bottlenecks with 2% overhead
   Download for free and get started troubleshooting in 

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[Michael Blumenkrantz]

cJSON, at least, exposes no hashes, lists, or any of that; I don't know
what crazy parsers you kids have been using which do this, but they
shouldn't since JSON doesn't have any concept of such things.

This is all the code I have which uses an external JSON parser at present.
It serializes and deserializes JSON-RPC (based on latest draft spec) very
pedantically to/from Eina_Value, and all strings get stringshared.

http://git.enlightenment.org/devs/discomfitor/maelstrom.git/tree/src/lib/azy/azy_content_json.c


On Wed, May 1, 2013 at 2:46 PM, Tom Hacohen tom.haco...@samsung.com wrote:

 On 01/05/13 14:15, Cedric BAIL wrote:
  WTF ! I am not saying that without a benchmark ! Where do you think
  that came from ? Just random praising for the fun ?

 You said you haven't tested cJSON, only json-c. I asked you about it!
  Because there is no complexity there. It just work. There is no
  maintenance cost. There is no need to bring an external dependency for
  100 lines of code.

 Pfft yeah, sounds like every other piece of code every written.

 
  Mike can interject, as he has used cJSON before, and I don't remember
 him
  mentioning any issues.
 
  So running cJSON, then converting to Eina_Value or C structure by hand
  in the application side is faster than just running a stupid automate
  that produce them in the first place...

 Let's wait for mike. I wonder what he did. Also I wonder if you'd end up
 changing the Eina_Value and lists to your own struct anyway 99.99% of
 the time. Surely there must be a lib that let's you parse it straight to
 your data type, but that might be slower.

 
  Your main argument is the speed, though I have requested benchmarks and
  comparisons with eina_json yet I have seen none. If it's so simple to
  implement, how come there are so many implementations? How come they
 vary in
  speed so much? And where do we stand compared to others?
 
  Because it is damn easy to write one implementation ! Because most of
  the speed doesn't come from the parser automate who is always the same
  stupid table, but from the hash, object, list and array object
  manipulated. That is where the cost come from. And I am not only
  arguing about speed, but also integration and simplicity of use.
  Really forcing everyone to link with another library for less than
  1000 lines of code, to have another object api to manipulate, to do
  all the conversion manually is a great help to every one. Of course it
  is doable in the application. Of course you can write your own, it is
  so damn easy.
 
  As for the benchmark, we are going to reuse the one written by QT. I
  am going to do proper review and cleaning as necessary after 1.9,
  there is nothing to look at at this stage. I have already spend more
  time arguing on that subject that I am sure it will take me to write
  an implementation from scratch and likely to ever maintain it.

 Let's wait for the benchmarks then. I find it really odd that the only
 different in speed is the implementations of the hash-tables and lists.

 --
 Tom.



 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
 Get 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% overhead
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap1
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[The Rasterman]

On Wed, 1 May 2013 14:56:32 +0100 Michael Blumenkrantz
michael.blumenkra...@gmail.com said:

 cJSON, at least, exposes no hashes, lists, or any of that; I don't know
 what crazy parsers you kids have been using which do this, but they
 shouldn't since JSON doesn't have any concept of such things.

errr.. json is really a tree of string key - values (where value can be a
subtree) so thus by nature its a list and/or hash of strings and/or subtrees
make sense.

 This is all the code I have which uses an external JSON parser at present.
 It serializes and deserializes JSON-RPC (based on latest draft spec) very
 pedantically to/from Eina_Value, and all strings get stringshared.
 
 http://git.enlightenment.org/devs/discomfitor/maelstrom.git/tree/src/lib/azy/azy_content_json.c

ok. so still about 500 loc to drive cjson and convert back to data structs
(eina-value in this case). and... behind getobjectitem in cjson is probably
a hash... and probably a set of lists... etc. duplicating strings inside of
cjson that then are extracted and stuffed into stringshare strings. :)

and we ned up with another fun thing... to use cjson... at least ubuntu users
can't just apt-get install it. no package. so we have to copy it into the efl
tree or make packages or force pl to download and compile it just for a small
lib dep... and it nicely comes with a zip file with no makefile or configure...
or any build infra, with __MACOSX metadata hidden files all thru the zip...
good luck with that.

so import the src entirely is the only way... and then... take a read of the
src. seriously. once we import it we will have to fix it and maintain it
entirely... THIS is just one of many functions where the WHOLE function
including definition is on a single line:

void   cJSON_ReplaceItemInObject(cJSON *object,const char *string,cJSON
*newitem){int i=0;cJSON *c=object-child;while(c  cJSON_strcasecmp
(c-string,string))i++,c=c-next;if(c){newitem-string=cJSON_strdup
(string);cJSON_ReplaceItemInArray(object,i,newitem);}}

no newlines. there's a whole batch of these 11-liner funcs there, it's not a
one-off oh an i was wrong. it has no lists or hashes. it just has arrays of
string-value and cJSON_GetObjectItem is... a linear O(n) walk thru the array
strcmping every item until key found, then return... so for objects with lots
of keys... we're talking a lot of walking... might be doable for like things
with  10 keys... not so for a more expansive and generic need.

so a quick 5 minute evaluation of cjson tells me:

1. we can't just link to it... and HAVE to import it.
2. it's coding conventions are far from what we are used to and do in efl land,
so we'll have a nice sore thumb inside our src tree.
3. it will duplicate all things via strdups so we can't hope to minimize
string copies in memory.
4. walking cjson stuff is either looking up every key you want with O(n) per
lookup with strcmps ... OR... walking the array by index and converting to a
hash then doing hash lookups (back to #3).
5. conclusion... cjson would not be the best choice of json parser to roll into
our src tree... :)

 On Wed, May 1, 2013 at 2:46 PM, Tom Hacohen tom.haco...@samsung.com wrote:
 
  On 01/05/13 14:15, Cedric BAIL wrote:
   WTF ! I am not saying that without a benchmark ! Where do you think
   that came from ? Just random praising for the fun ?
 
  You said you haven't tested cJSON, only json-c. I asked you about it!
   Because there is no complexity there. It just work. There is no
   maintenance cost. There is no need to bring an external dependency for
   100 lines of code.
 
  Pfft yeah, sounds like every other piece of code every written.
 
  
   Mike can interject, as he has used cJSON before, and I don't remember
  him
   mentioning any issues.
  
   So running cJSON, then converting to Eina_Value or C structure by hand
   in the application side is faster than just running a stupid automate
   that produce them in the first place...
 
  Let's wait for mike. I wonder what he did. Also I wonder if you'd end up
  changing the Eina_Value and lists to your own struct anyway 99.99% of
  the time. Surely there must be a lib that let's you parse it straight to
  your data type, but that might be slower.
 
  
   Your main argument is the speed, though I have requested benchmarks and
   comparisons with eina_json yet I have seen none. If it's so simple to
   implement, how come there are so many implementations? How come they
  vary in
   speed so much? And where do we stand compared to others?
  
   Because it is damn easy to write one implementation ! Because most of
   the speed doesn't come from the parser automate who is always the same
   stupid table, but from the hash, object, list and array object
   manipulated. That is where the cost come from. And I am not only
   arguing about speed, but also integration and simplicity of use.
   Really forcing everyone to link with another library for less than
   1000 lines of code, to have another object api to 

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[Michael Blumenkrantz]

On Thu, May 2, 2013 at 1:04 AM, Carsten Haitzler ras...@rasterman.comwrote:

 On Wed, 1 May 2013 14:56:32 +0100 Michael Blumenkrantz
 michael.blumenkra...@gmail.com said:

  cJSON, at least, exposes no hashes, lists, or any of that; I don't know
  what crazy parsers you kids have been using which do this, but they
  shouldn't since JSON doesn't have any concept of such things.

 errr.. json is really a tree of string key - values (where value can be a
 subtree) so thus by nature its a list and/or hash of strings and/or
 subtrees
 make sense.


If you're using JSON for RPC, it doesn't make sense. This is a very common
use case.



  This is all the code I have which uses an external JSON parser at
 present.
  It serializes and deserializes JSON-RPC (based on latest draft spec) very
  pedantically to/from Eina_Value, and all strings get stringshared.
 
 
 http://git.enlightenment.org/devs/discomfitor/maelstrom.git/tree/src/lib/azy/azy_content_json.c

 ok. so still about 500 loc to drive cjson and convert back to data structs
 (eina-value in this case). and... behind getobjectitem in cjson is
 probably
 a hash... and probably a set of lists... etc. duplicating strings inside of
  cjson that then are extracted and stuffed into stringshare strings. :)


 and we ned up with another fun thing... to use cjson... at least ubuntu
 users
 can't just apt-get install it. no package. so we have to copy it into the
 efl
 tree or make packages or force pl to download and compile it just for a
 small
 lib dep... and it nicely comes with a zip file with no makefile or
 configure...
 or any build infra, with __MACOSX metadata hidden files all thru the zip...
 good luck with that.


Oh noes, scary __UNDERSCORE files and lack of build system which are
irrelevant when importing the source!



 so import the src entirely is the only way... and then... take a read of
 the
 src. seriously. once we import it we will have to fix it and maintain it
 entirely... THIS is just one of many functions where the WHOLE function
 including definition is on a single line:

 void   cJSON_ReplaceItemInObject(cJSON *object,const char *string,cJSON
 *newitem){int i=0;cJSON *c=object-child;while(c  cJSON_strcasecmp
 (c-string,string))i++,c=c-next;if(c){newitem-string=cJSON_strdup
 (string);cJSON_ReplaceItemInArray(object,i,newitem);}}

 no newlines. there's a whole batch of these 11-liner funcs there, it's not
 a
 one-off oh an i was wrong. it has no lists or hashes. it just has arrays of
 string-value and cJSON_GetObjectItem is... a linear O(n) walk thru the
 array
 strcmping every item until key found, then return... so for objects with
 lots
 of keys... we're talking a lot of walking... might be doable for like
 things
 with  10 keys... not so for a more expansive and generic need.

 so a quick 5 minute evaluation of cjson tells me:

 1. we can't just link to it... and HAVE to import it.


That's the entire idea behind having a sub-1000 line parser, which is one
of the cornerstones of Cedric's stance that we should write our won.


 2. it's coding conventions are far from what we are used to and do in efl
 land,
 so we'll have a nice sore thumb inside our src tree.


Cedric's coding conventions are pretty far from it too, but we still let
him work on Edje.


 3. it will duplicate all things via strdups so we can't hope to minimize
 string copies in memory.


Not a great argument since we could easily just s/strdup/stringshare/.


 4. walking cjson stuff is either looking up every key you want with O(n)
 per
 lookup with strcmps ... OR... walking the array by index and converting to
 a
 hash then doing hash lookups (back to #3).


This is a valid point, and really the only one you've made. cJSON is NOT
great for a general use case. It fits the needs of RPC perfectly, but
that's about it.


 5. conclusion... cjson would not be the best choice of json parser to roll
 into
 our src tree... :)

  On Wed, May 1, 2013 at 2:46 PM, Tom Hacohen tom.haco...@samsung.com
 wrote:
 
   On 01/05/13 14:15, Cedric BAIL wrote:
WTF ! I am not saying that without a benchmark ! Where do you think
that came from ? Just random praising for the fun ?
  
   You said you haven't tested cJSON, only json-c. I asked you about it!
Because there is no complexity there. It just work. There is no
maintenance cost. There is no need to bring an external dependency
 for
100 lines of code.
  
   Pfft yeah, sounds like every other piece of code every written.
  
   
Mike can interject, as he has used cJSON before, and I don't
 remember
   him
mentioning any issues.
   
So running cJSON, then converting to Eina_Value or C structure by
 hand
in the application side is faster than just running a stupid automate
that produce them in the first place...
  
   Let's wait for mike. I wonder what he did. Also I wonder if you'd end
 up
   changing the Eina_Value and lists to your own struct anyway 99.99% of
   the time. Surely there must be a lib that 

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[David Seikel]

Er, somehow this thread went from stop the JSON madness to this is
how we should do JSON?  I need caffeine, I'm not keeping up.  Though I
blame E, it's dog slow now.  Did someone add JSON?  :-P

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON parser in Eina - together we can stop the madness

[Michael Blumenkrantz]

No, we added SOAP.


On Thu, May 2, 2013 at 6:22 AM, David Seikel onef...@gmail.com wrote:

 Er, somehow this thread went from stop the JSON madness to this is
 how we should do JSON?  I need caffeine, I'm not keeping up.  Though I
 blame E, it's dog slow now.  Did someone add JSON?  :-P

 --
 A big old stinking pile of genius that no one wants
 coz there are too many silver coated monkeys in the world.


 --
 Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
 Get 100% visibility into your production application - at no cost.
 Code-level diagnostics for performance bottlenecks with 2% overhead
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap1
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel