date:20130501

On Wed, 1 May 2013 13:32:56 +0900 Daniel Juyung Seo seojuyu...@gmail.com said:

 Is it allowed to do the internal refactoring after alpha?
 I should push elm_diskselecotr dynamic object creation algorithm.
 This is only elm_diskselector internal refactoring.

minor improvements, i'd say yes. at least until beta, big overhauls... no. we
will begin freeze once we just the first alpha. i suspect that may not be
today. :)

 Thanks.
 
 Daniel Juyung Seo (SeoZ)
 
 On Wed, May 1, 2013 at 1:15 PM, Carsten Haitzler ras...@rasterman.com wrote:
  so it's on our todo list. is everyone happy now its eldbus? :) everyone
  happy otherwise?
 
  cedric - loader module api. if it isnt public by now... it can wait for 1.9.
 
  tom/bluezery - genlist map stuff... we need to talk...
 
  cserve2 - need to talk..
 
  and dark theme - i know. underway.
 
  so given the above... do we all think an alpha1 would be a good call today?
 
  --
  - 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
 
 --
 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
 


-- 
- 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] efl/elm 1.8 (attn!)

On Wed, 1 May 2013 01:55:58 -0300 Lucas De Marchi
lucas.demar...@profusion.mobi said:

 On Wed, May 1, 2013 at 1:15 AM, Carsten Haitzler ras...@rasterman.com wrote:
  so it's on our todo list. is everyone happy now its eldbus? :) everyone
  happy otherwise?
 
  cedric - loader module api. if it isnt public by now... it can wait for 1.9.
 
  tom/bluezery - genlist map stuff... we need to talk...
 
  cserve2 - need to talk..
 
  and dark theme - i know. underway.
 
  so given the above... do we all think an alpha1 would be a good call today?
 
 today? wouldn't 1/2/3 week(s) from today be much better?

may 1 was our date for release freeze... and at least the idea ws to cut a
first alpha today, and then regularly until release on may 31 (well series of
alphas then betas then out).

 As I said, I didn't have time to properly review eldbus API. And seems
 nobody  did (or it was perfect, which I'm sure it isn't).

well imho eldbus should/could/would get eo underneath it so we can bind
connection, api or whatever objects TO other efl objects easily (automatic
refcounting/deletion etc. etc.)... but that can be slid underneath like we did
with the rest of efl...


 Lucas De Marchi
 
 --
 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
 


-- 
- 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] [EGIT] [core/efl] master 01/01: it is possible with wchart_t to have it signed.. so unicode can be 0... dont crash.

On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote:
 On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen tom.haco...@samsung.com said:

 Where did you get that on?
 Anyhow, what do you think about changing it to unsigned wchar_t?

 on my pentium-m test machine... unicode val 0 was  0 and thus walked below 
 the
 array. yes. literally a negative.  wouldnt that be wuchar_t or something? as
 wchar_t .. is a typedef... :)


Hm... Annoying. There's no wuchar_t though.

--
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] efl/elm 1.8 (attn!)

On 01/05/13 05:15, Carsten Haitzler (The Rasterman) wrote:
 so it's on our todo list. is everyone happy now its eldbus? :) everyone
 happy otherwise?

 cedric - loader module api. if it isnt public by now... it can wait for 1.9.

 tom/bluezery - genlist map stuff... we need to talk...

 cserve2 - need to talk..

 and dark theme - i know. underway.

 so given the above... do we all think an alpha1 would be a good call today?


Huh? I thought this was not going upstream.

--
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] efl/elm 1.8 (attn!)

On Wed, May 1, 2013 at 1:55 PM, Lucas De Marchi
lucas.demar...@profusion.mobi wrote:
 On Wed, May 1, 2013 at 1:15 AM, Carsten Haitzler ras...@rasterman.com wrote:
 so it's on our todo list. is everyone happy now its eldbus? :) everyone
 happy otherwise?

 cedric - loader module api. if it isnt public by now... it can wait for 1.9.

It can land before end of the week.

 tom/bluezery - genlist map stuff... we need to talk...

I have been thinking about exposing the bounding box of a smart object
to evas map, solving the forced clipping issue. Also I am going to
push the auto move, but not the auto map, there is to much fine
tunning there and I don't like what I had. I may push the pixel
density information so that elm mapbuf can use that and the object
scrolling speed to decide if it is worth it to do an intermediate
rendering. Should be doable before middle of next week.

 cserve2 - need to talk..

 and dark theme - i know. underway.

 so given the above... do we all think an alpha1 would be a good call today?

 today? wouldn't 1/2/3 week(s) from today be much better?

I do agree with you, see my previous mail on the 1.8 release and I see
we still have some stuff to do.

 As I said, I didn't have time to properly review eldbus API. And seems
 nobody  did (or it was perfect, which I'm sure it isn't).

There is also the review of edje ephysics integration I hadn't have
the time to do until now and ephysics is maybe broken or did broke
EFBB. We need to look at that. I was hoping to get some time, but
didn't... At least I think we should be able to release EFBB along EFL
1.8 as a good demonstration of ephysics.

In the same idea, I had have not enough time to review Ecore_Audio and
I was hoping to get some real test case of the API. Integration in
Elemines and EFBB come to my mind.

So yes, at least a week is necessary in my opinion.
--
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

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

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

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

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] [EGIT] [core/efl] master 01/01: it is possible with wchart_t to have it signed.. so unicode can be 0... dont crash.

On Wed, 01 May 2013 10:08:48 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote:
  On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  Where did you get that on?
  Anyhow, what do you think about changing it to unsigned wchar_t?
 
  on my pentium-m test machine... unicode val 0 was  0 and thus walked below
  the array. yes. literally a negative.  wouldnt that be wuchar_t or
  something? as wchar_t .. is a typedef... :)
 
 
 Hm... Annoying. There's no wuchar_t though.

then we have... a problem... and it requires we check for  0. :(


-- 
- 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] efl/elm 1.8 (attn!)

On Wed, 01 May 2013 10:15:19 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 01/05/13 05:15, Carsten Haitzler (The Rasterman) wrote:
  so it's on our todo list. is everyone happy now its eldbus? :) everyone
  happy otherwise?
 
  cedric - loader module api. if it isnt public by now... it can wait for 1.9.
 
  tom/bluezery - genlist map stuff... we need to talk...
 
  cserve2 - need to talk..
 
  and dark theme - i know. underway.
 
  so given the above... do we all think an alpha1 would be a good call today?
 
 
 Huh? I thought this was not going upstream.

yes - it's on the 1.8 todo... why is it on the todo? thus need to talk. see
phab's efl/elm 1.8 wiki page.


-- 
- 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] [EGIT] [core/efl] master 01/01: it is possible with wchart_t to have it signed.. so unicode can be 0... dont crash.

On 01/05/13 10:58, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 10:08:48 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote:
 On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 Where did you get that on?
 Anyhow, what do you think about changing it to unsigned wchar_t?

 on my pentium-m test machine... unicode val 0 was  0 and thus walked below
 the array. yes. literally a negative.  wouldnt that be wuchar_t or
 something? as wchar_t .. is a typedef... :)


 Hm... Annoying. There's no wuchar_t though.

 then we have... a problem... and it requires we check for  0. :(



I think me might be better off casting to unsigned. Damn you people for 
not doing all the char type unsigned, wth?!

--
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

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

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

[E-devel] [PATCH] adding check for elementary

2013-05-01 Thread ryuan Choi

Hi,

While digging some elementary bug recently, I think that elementary needs
unit testing framework like other EFL core modules in order to prevent
regressions or understand what commits fixed.

Can we have chance to introduce check for elementary?

Initial commit is here.
https://phab.enlightenment.org/D91

Thanks in advance.
--
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] Cgit enhancements

2013-05-01 Thread Daniel Willmann

On 30/04/13 21:29, Bertrand Jacquin wrote:
 Hi in there,
 
 Here is a couple of improvements in cgit interfaces :
 
  - You are now able to filter the view by appending a directory in the
  URL to show the repositories of a specific directory. For exemple, to
  see only core/ repo:
   http://git.enlightenment.org/core

Looks nice, good job!

Regards,
Daniel


--
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] efl/elm 1.8 (attn!)

2013-05-01 Thread Daniel Willmann

On 01/05/13 05:15, Carsten Haitzler (The Rasterman) wrote:
 so it's on our todo list. is everyone happy now its eldbus? :) everyone
 happy otherwise?
 
 cedric - loader module api. if it isnt public by now... it can wait for
 1.9.
 
 tom/bluezery - genlist map stuff... we need to talk...
 
 cserve2 - need to talk..
 
 and dark theme - i know. underway.

ecore_audio - After the eo rewrite I need to at least update the docs, I
would like someone to review the API as well and take care of
https://phab.enlightenment.org/rEFL8c96a841e49ce22eaddd912f78449e506a51b1d8

 so given the above... do we all think an alpha1 would be a good call
 today?

Regards,
Daniel

--
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] Cgit enhancements

2013-05-01 Thread Bertrand Jacquin

On 2013-05-01 09:05, Daniel Juyung Seo wrote:
 This is cool :)
 I wonder if this didn't work before hehe.

It should have yes :) But as we are using the virtual-root feature in 
cgit, this wasn't working and didn't notice it before yesterday. I just 
tweak a bit the .htaccess

+# Serve local file
+RewriteCond %{REQUEST_FILENAME} -f
+RewriteRule .* - [L]

  # Access cgit from /
-RewriteRule ^([^/]+)(?(.*)) /cgit.cgi/$1$2 [L,QSA,NS]
+RewriteRule ^([^/]+)(/?(.*)) /cgit.cgi/$1$2 [L,QSA,NS]


--
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] [PATCH] adding check for elementary

On Wed, May 1, 2013 at 7:48 PM, ryuan Choi ryuan.c...@gmail.com wrote:
 While digging some elementary bug recently, I think that elementary needs
 unit testing framework like other EFL core modules in order to prevent
 regressions or understand what commits fixed.

 Can we have chance to introduce check for elementary?

 Initial commit is here.
 https://phab.enlightenment.org/D91

I wish we had exactness integrated... but that would be a start. Will
do some push before the end of the week.
--
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

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] [PATCH] adding check for elementary

On 01/05/13 12:40, Cedric BAIL wrote:
 On Wed, May 1, 2013 at 7:48 PM, ryuan Choi ryuan.c...@gmail.com wrote:
 While digging some elementary bug recently, I think that elementary needs
 unit testing framework like other EFL core modules in order to prevent
 regressions or understand what commits fixed.

 Can we have chance to introduce check for elementary?

 Initial commit is here.
 https://phab.enlightenment.org/D91

 I wish we had exactness integrated... but that would be a start. Will
 do some push before the end of the week.

As Cedric has mentioned.

Anyhow, replied to your patch.

--
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

[E-devel] enlightenmant file manager make some problems while tranfaring

2013-05-01 Thread المسالم المسالمة

hello again

today i tried to transfer about 700 megabyte from Downloads to USB flash
storage

the problem here is

after click paste from mouse left button list

file manager will sow to me a message that says transferring is complete

but in reality is not

the transferring is still in progress

so i hope that problem will be solved next release

thanks again
--
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

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] enlightenmant file manager make some problems while tranfaring

On Wed, 1 May 2013 15:07:42 +0300 المسالم المسالمة
almusalimalmusali...@gmail.com said:

 hello again
 
 today i tried to transfer about 700 megabyte from Downloads to USB flash
 storage
 
 the problem here is
 
 after click paste from mouse left button list
 
 file manager will sow to me a message that says transferring is complete
 
 but in reality is not
 
 the transferring is still in progress
 
 so i hope that problem will be solved next release
 
 thanks again

how is it not complete? is efm showing a progress bar? if efm/e is showing its
compleye and u can see/browser thru the destination file tree.. it's complete.
the rest is your KERNEL buffering/syncing and this is not a bug. it is how
linux orks. it does everything it can in ram first... cached. spooling it out
to disk later. if you don't like this... you want your fs's mounded with a sync
option... and then prepare for the awesome slowness you'll enjoy :) thats why
there is an unmount/eject option in menus... to ensure all ops are synced to
disk before the media is removed...

-- 
- 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] [EGIT] [core/efl] master 01/01: it is possible with wchart_t to have it signed.. so unicode can be 0... dont crash.

On Wed, 01 May 2013 11:00:01 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 01/05/13 10:58, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 10:08:48 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote:
  On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  Where did you get that on?
  Anyhow, what do you think about changing it to unsigned wchar_t?
 
  on my pentium-m test machine... unicode val 0 was  0 and thus walked
  below the array. yes. literally a negative.  wouldnt that be wuchar_t or
  something? as wchar_t .. is a typedef... :)
 
 
  Hm... Annoying. There's no wuchar_t though.
 
  then we have... a problem... and it requires we check for  0. :(
 
 
 
 I think me might be better off casting to unsigned. Damn you people for 
 not doing all the char type unsigned, wth?!

chances are the compiler will produce the exact same code regardless... a cast
or what is there now.

-- 
- 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

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] enlightenmant file manager make some problems while tranfaring

this is a known behavior. the only way to fix it would be to monitor the
destination file size and show a progress bar based on this, but it would
not be entirely accurate or practical.


On Wed, May 1, 2013 at 2:02 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Wed, 1 May 2013 15:07:42 +0300 المسالم المسالمة
 almusalimalmusali...@gmail.com said:

  hello again
 
  today i tried to transfer about 700 megabyte from Downloads to USB flash
  storage
 
  the problem here is
 
  after click paste from mouse left button list
 
  file manager will sow to me a message that says transferring is complete
 
  but in reality is not
 
  the transferring is still in progress
 
  so i hope that problem will be solved next release
 
  thanks again

 how is it not complete? is efm showing a progress bar? if efm/e is showing
 its
 compleye and u can see/browser thru the destination file tree.. it's
 complete.
 the rest is your KERNEL buffering/syncing and this is not a bug. it is how
 linux orks. it does everything it can in ram first... cached. spooling it
 out
 to disk later. if you don't like this... you want your fs's mounded with a
 sync
 option... and then prepare for the awesome slowness you'll enjoy :) thats
 why
 there is an unmount/eject option in menus... to ensure all ops are synced
 to
 disk before the media is removed...

 --
 - 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

--
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] [EGIT] [core/efl] master 01/01: it is possible with wchart_t to have it signed.. so unicode can be 0... dont crash.

On 01/05/13 13:54, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 11:00:01 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 01/05/13 10:58, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 10:08:48 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote:
 On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 Where did you get that on?
 Anyhow, what do you think about changing it to unsigned wchar_t?

 on my pentium-m test machine... unicode val 0 was  0 and thus walked
 below the array. yes. literally a negative.  wouldnt that be wuchar_t or
 something? as wchar_t .. is a typedef... :)


 Hm... Annoying. There's no wuchar_t though.

 then we have... a problem... and it requires we check for  0. :(



 I think me might be better off casting to unsigned. Damn you people for
 not doing all the char type unsigned, wth?!

 chances are the compiler will produce the exact same code regardless... a cast
 or what is there now.


Nah, the whole point of the cast is to convert it to unsigned, I'm quite 
certain the compiler is capable of doing that.

--
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] [EGIT] [core/efl] master 01/01: it is possible with wchart_t to have it signed.. so unicode can be 0... dont crash.

On Wed, 01 May 2013 13:52:50 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 01/05/13 13:54, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 11:00:01 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 01/05/13 10:58, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 10:08:48 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote:
  On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  Where did you get that on?
  Anyhow, what do you think about changing it to unsigned wchar_t?
 
  on my pentium-m test machine... unicode val 0 was  0 and thus walked
  below the array. yes. literally a negative.  wouldnt that be wuchar_t or
  something? as wchar_t .. is a typedef... :)
 
 
  Hm... Annoying. There's no wuchar_t though.
 
  then we have... a problem... and it requires we check for  0. :(
 
 
 
  I think me might be better off casting to unsigned. Damn you people for
  not doing all the char type unsigned, wth?!
 
  chances are the compiler will produce the exact same code regardless... a
  cast or what is there now.
 
 
 Nah, the whole point of the cast is to convert it to unsigned, I'm quite 
 certain the compiler is capable of doing that.

but your casting inside the func to just avoid if (x  0)... which a compiler
will figure out to be the same as the cast to unsigned...


-- 
- 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

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] [EGIT] [core/efl] master 01/01: it is possible with wchart_t to have it signed.. so unicode can be 0... dont crash.

On 01/05/13 14:07, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 13:52:50 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 01/05/13 13:54, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 11:00:01 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 On 01/05/13 10:58, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 10:08:48 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote:
 On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 Where did you get that on?
 Anyhow, what do you think about changing it to unsigned wchar_t?

 on my pentium-m test machine... unicode val 0 was  0 and thus walked
 below the array. yes. literally a negative.  wouldnt that be wuchar_t or
 something? as wchar_t .. is a typedef... :)


 Hm... Annoying. There's no wuchar_t though.

 then we have... a problem... and it requires we check for  0. :(



 I think me might be better off casting to unsigned. Damn you people for
 not doing all the char type unsigned, wth?!

 chances are the compiler will produce the exact same code regardless... a
 cast or what is there now.


 Nah, the whole point of the cast is to convert it to unsigned, I'm quite
 certain the compiler is capable of doing that.

 but your casting inside the func to just avoid if (x  0)... which a compiler
 will figure out to be the same as the cast to unsigned...



The cast will work for unicode values that are greater than the signed 
limit (less than 0), while the if just fail for them.

--
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] enlightenmant file manager make some problems while tranfaring

Or force a sync on the device. As long as nobody remove the usb drive
until the umount did succeed, data will be safe.

On Wed, May 1, 2013 at 9:53 PM, Michael Blumenkrantz
michael.blumenkra...@gmail.com wrote:
 this is a known behavior. the only way to fix it would be to monitor the
 destination file size and show a progress bar based on this, but it would
 not be entirely accurate or practical.


 On Wed, May 1, 2013 at 2:02 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Wed, 1 May 2013 15:07:42 +0300 المسالم المسالمة
 almusalimalmusali...@gmail.com said:

  hello again
 
  today i tried to transfer about 700 megabyte from Downloads to USB flash
  storage
 
  the problem here is
 
  after click paste from mouse left button list
 
  file manager will sow to me a message that says transferring is complete
 
  but in reality is not
 
  the transferring is still in progress
 
  so i hope that problem will be solved next release
 
  thanks again

 how is it not complete? is efm showing a progress bar? if efm/e is showing
 its
 compleye and u can see/browser thru the destination file tree.. it's
 complete.
 the rest is your KERNEL buffering/syncing and this is not a bug. it is how
 linux orks. it does everything it can in ram first... cached. spooling it
 out
 to disk later. if you don't like this... you want your fs's mounded with a
 sync
 option... and then prepare for the awesome slowness you'll enjoy :) thats
 why
 there is an unmount/eject option in menus... to ensure all ops are synced
 to
 disk before the media is removed...

 --
 - 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

 --
 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



--
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] enlightenmant file manager make some problems while tranfaring

On Wed, 1 May 2013 22:04:23 +0900 Cedric BAIL cedric.b...@free.fr said:

 Or force a sync on the device. As long as nobody remove the usb drive
 until the umount did succeed, data will be safe.

then the bug becomes my system is really slow while copying files or the
progress bar hangs at 100% for ages ... etc. the only way to do it is to do
fsync() directly during the copy and then people just get upset at how slow
file ops become compared to cp or mv which they then complain are so much
faster...

 On Wed, May 1, 2013 at 9:53 PM, Michael Blumenkrantz
 michael.blumenkra...@gmail.com wrote:
  this is a known behavior. the only way to fix it would be to monitor the
  destination file size and show a progress bar based on this, but it would
  not be entirely accurate or practical.
 
 
  On Wed, May 1, 2013 at 2:02 PM, Carsten Haitzler
  ras...@rasterman.comwrote:
 
  On Wed, 1 May 2013 15:07:42 +0300 المسالم المسالمة
  almusalimalmusali...@gmail.com said:
 
   hello again
  
   today i tried to transfer about 700 megabyte from Downloads to USB flash
   storage
  
   the problem here is
  
   after click paste from mouse left button list
  
   file manager will sow to me a message that says transferring is complete
  
   but in reality is not
  
   the transferring is still in progress
  
   so i hope that problem will be solved next release
  
   thanks again
 
  how is it not complete? is efm showing a progress bar? if efm/e is showing
  its
  compleye and u can see/browser thru the destination file tree.. it's
  complete.
  the rest is your KERNEL buffering/syncing and this is not a bug. it is how
  linux orks. it does everything it can in ram first... cached. spooling it
  out
  to disk later. if you don't like this... you want your fs's mounded with a
  sync
  option... and then prepare for the awesome slowness you'll enjoy :) thats
  why
  there is an unmount/eject option in menus... to ensure all ops are synced
  to
  disk before the media is removed...
 
  --
  - 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
 
  --
  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
 
 
 
 --
 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


-- 
- 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] [EGIT] [core/efl] master 01/01: it is possible with wchart_t to have it signed.. so unicode can be 0... dont crash.

On Wed, 01 May 2013 14:03:42 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 01/05/13 14:07, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 13:52:50 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 01/05/13 13:54, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 11:00:01 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 01/05/13 10:58, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 10:08:48 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote:
  On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen
  tom.haco...@samsung.com said:
 
  Where did you get that on?
  Anyhow, what do you think about changing it to unsigned wchar_t?
 
  on my pentium-m test machine... unicode val 0 was  0 and thus walked
  below the array. yes. literally a negative.  wouldnt that be wuchar_t
  or something? as wchar_t .. is a typedef... :)
 
 
  Hm... Annoying. There's no wuchar_t though.
 
  then we have... a problem... and it requires we check for  0. :(
 
 
 
  I think me might be better off casting to unsigned. Damn you people for
  not doing all the char type unsigned, wth?!
 
  chances are the compiler will produce the exact same code regardless... a
  cast or what is there now.
 
 
  Nah, the whole point of the cast is to convert it to unsigned, I'm quite
  certain the compiler is capable of doing that.
 
  but your casting inside the func to just avoid if (x  0)... which a
  compiler will figure out to be the same as the cast to unsigned...
 
 
 
 The cast will work for unicode values that are greater than the signed 
 limit (less than 0), while the if just fail for them.

there are no unicode values of that magnitude... unicode by definition doesnt
even get close to using the most significant bit... :) it's by definition an
invalid code if  0 (for 32bit signed)... 


-- 
- 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

2013-05-01 Thread 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

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] [EGIT] [core/efl] master 01/01: it is possible with wchart_t to have it signed.. so unicode can be 0... dont crash.

On 01/05/13 14:17, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 14:03:42 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 01/05/13 14:07, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 13:52:50 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 On 01/05/13 13:54, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 11:00:01 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 On 01/05/13 10:58, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 10:08:48 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote:
 On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen
 tom.haco...@samsung.com said:

 Where did you get that on?
 Anyhow, what do you think about changing it to unsigned wchar_t?

 on my pentium-m test machine... unicode val 0 was  0 and thus walked
 below the array. yes. literally a negative.  wouldnt that be wuchar_t
 or something? as wchar_t .. is a typedef... :)


 Hm... Annoying. There's no wuchar_t though.

 then we have... a problem... and it requires we check for  0. :(



 I think me might be better off casting to unsigned. Damn you people for
 not doing all the char type unsigned, wth?!

 chances are the compiler will produce the exact same code regardless... a
 cast or what is there now.


 Nah, the whole point of the cast is to convert it to unsigned, I'm quite
 certain the compiler is capable of doing that.

 but your casting inside the func to just avoid if (x  0)... which a
 compiler will figure out to be the same as the cast to unsigned...



 The cast will work for unicode values that are greater than the signed
 limit (less than 0), while the if just fail for them.

 there are no unicode values of that magnitude... unicode by definition doesnt
 even get close to using the most significant bit... :) it's by definition an
 invalid code if  0 (for 32bit signed)...



Oh, forgot to mention, I was thinking about boxes where wchar_t is 
signed and 16bit. :) There we'll have trouble.
If you got negative values it must mean you've reached big enough 
unicode values, so the issue I'm describing is indeed real.

--
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

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

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] [EGIT] [core/efl] master 01/01: it is possible with wchart_t to have it signed.. so unicode can be 0... dont crash.

On Wed, 01 May 2013 14:37:37 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 01/05/13 14:17, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 14:03:42 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 01/05/13 14:07, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 13:52:50 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 01/05/13 13:54, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 11:00:01 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 01/05/13 10:58, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 10:08:48 +0100 Tom Hacohen
  tom.haco...@samsung.com said:
 
  On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote:
  On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen
  tom.haco...@samsung.com said:
 
  Where did you get that on?
  Anyhow, what do you think about changing it to unsigned wchar_t?
 
  on my pentium-m test machine... unicode val 0 was  0 and thus
  walked below the array. yes. literally a negative.  wouldnt that be
  wuchar_t or something? as wchar_t .. is a typedef... :)
 
 
  Hm... Annoying. There's no wuchar_t though.
 
  then we have... a problem... and it requires we check for  0. :(
 
 
 
  I think me might be better off casting to unsigned. Damn you people for
  not doing all the char type unsigned, wth?!
 
  chances are the compiler will produce the exact same code regardless...
  a cast or what is there now.
 
 
  Nah, the whole point of the cast is to convert it to unsigned, I'm quite
  certain the compiler is capable of doing that.
 
  but your casting inside the func to just avoid if (x  0)... which a
  compiler will figure out to be the same as the cast to unsigned...
 
 
 
  The cast will work for unicode values that are greater than the signed
  limit (less than 0), while the if just fail for them.
 
  there are no unicode values of that magnitude... unicode by definition
  doesnt even get close to using the most significant bit... :) it's by
  definition an invalid code if  0 (for 32bit signed)...
 
 
 
 Oh, forgot to mention, I was thinking about boxes where wchar_t is 
 signed and 16bit. :) There we'll have trouble.
 If you got negative values it must mean you've reached big enough 
 unicode values, so the issue I'm describing is indeed real.

on boxes where its 16bit.. we will have problems... because unicode does not
fit into 16bit we explicitly MUSt have it be a 32bit type in order to have
enough space to store the hmmm... 22? bits needed for unicode? quick check...
10  is the top unicode value... that means 21bits... so unicode needs
21bits. if we have 16bit wchar_t's we are not able to do unicode. signed or not
is irrelevant here. if its 32bit... we don't care :)

-- 
- 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

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

Re: [E-devel] Eo object data referencing

On 01/05/13 09:13, daniel.za...@samsung.com wrote:
 Hi all,

 I pushed today the data referencing feature for Eo objects in efl and
 elementary. Check the commit log for explanations on why/how we do that.

   From now, eo_data_get is deprecated, so please use eo_data_scope_get,
 eo_data_ref or eo_data_xref instead.

Comments:
1. Super spank, you've included unrelated changes!!!

@@ -1240,7 +1244,7 @@ eo_xunref(Eo *obj_id, const Eo *ref_obj_id)
 Eo_Xref_Node *xref = NULL;
 EINA_INLIST_FOREACH(obj-xrefs, xref)
   {
-if (xref-ref_obj == ref_obj)
+if (xref-ref_obj == ref_obj_id)

Fixes another issue that you've introduced (or so it seems).

2. I don't like the way you handle the data. You keep a refcount for it, 
but you actually delete the data even if the reference is non-0. You 
should do it like a true reference count.
You should free the data once the reference count hits 0.
You should always maintain at least one reference count (the object 
referencing it's own data) so when the object is deleted that will get 
decremented and the data will be freed or kept according to the 
maintained reference count.

3. +_eo_data_xref_internal
You return uninitialised data if klass is NULL.
I know your code in it's current iteration won't get there, but still, 
initialise it, or remove the klass!=NULL check if you think it should 
never happen. At the moment it's unclear.

4. I don't understand how this even get in. You didn't add tests at all. 
It's Eo, in Eo we actually test shit. I'm really tempted to just revert 
it. Especially since my e got slow and annoying since your changes 
(among others, haven't checked which).

Bottom line. Fix it. It needs fixing. Especially test stuff. Though the 
general patch looks good and clean.

--
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] [EGIT] [core/efl] master 01/01: it is possible with wchart_t to have it signed.. so unicode can be 0... dont crash.

On 01/05/13 14:47, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 14:37:37 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 01/05/13 14:17, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 14:03:42 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 On 01/05/13 14:07, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 13:52:50 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 On 01/05/13 13:54, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 11:00:01 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 On 01/05/13 10:58, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 10:08:48 +0100 Tom Hacohen
 tom.haco...@samsung.com said:

 On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote:
 On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen
 tom.haco...@samsung.com said:

 Where did you get that on?
 Anyhow, what do you think about changing it to unsigned wchar_t?

 on my pentium-m test machine... unicode val 0 was  0 and thus
 walked below the array. yes. literally a negative.  wouldnt that be
 wuchar_t or something? as wchar_t .. is a typedef... :)


 Hm... Annoying. There's no wuchar_t though.

 then we have... a problem... and it requires we check for  0. :(



 I think me might be better off casting to unsigned. Damn you people for
 not doing all the char type unsigned, wth?!

 chances are the compiler will produce the exact same code regardless...
 a cast or what is there now.


 Nah, the whole point of the cast is to convert it to unsigned, I'm quite
 certain the compiler is capable of doing that.

 but your casting inside the func to just avoid if (x  0)... which a
 compiler will figure out to be the same as the cast to unsigned...



 The cast will work for unicode values that are greater than the signed
 limit (less than 0), while the if just fail for them.

 there are no unicode values of that magnitude... unicode by definition
 doesnt even get close to using the most significant bit... :) it's by
 definition an invalid code if  0 (for 32bit signed)...



 Oh, forgot to mention, I was thinking about boxes where wchar_t is
 signed and 16bit. :) There we'll have trouble.
 If you got negative values it must mean you've reached big enough
 unicode values, so the issue I'm describing is indeed real.

 on boxes where its 16bit.. we will have problems... because unicode does not
 fit into 16bit we explicitly MUSt have it be a 32bit type in order to have
 enough space to store the hmmm... 22? bits needed for unicode? quick check...
 10  is the top unicode value... that means 21bits... so unicode needs
 21bits. if we have 16bit wchar_t's we are not able to do unicode. signed or 
 not
 is irrelevant here. if its 32bit... we don't care :)


Well, a subset of... :)

But anyhow, how did you get your issue then? That it was negative? 
That's what I'm interested in, as that means it's a path we actually get to.

--
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] [EGIT] [core/efl] master 01/01: it is possible with wchart_t to have it signed.. so unicode can be 0... dont crash.

On Wed, 01 May 2013 15:00:57 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 01/05/13 14:47, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 14:37:37 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 01/05/13 14:17, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 14:03:42 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 01/05/13 14:07, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 13:52:50 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 01/05/13 13:54, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 11:00:01 +0100 Tom Hacohen
  tom.haco...@samsung.com said:
 
  On 01/05/13 10:58, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 10:08:48 +0100 Tom Hacohen
  tom.haco...@samsung.com said:
 
  On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote:
  On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen
  tom.haco...@samsung.com said:
 
  Where did you get that on?
  Anyhow, what do you think about changing it to unsigned wchar_t?
 
  on my pentium-m test machine... unicode val 0 was  0 and thus
  walked below the array. yes. literally a negative.  wouldnt that
  be wuchar_t or something? as wchar_t .. is a typedef... :)
 
 
  Hm... Annoying. There's no wuchar_t though.
 
  then we have... a problem... and it requires we check for  0. :(
 
 
 
  I think me might be better off casting to unsigned. Damn you people
  for not doing all the char type unsigned, wth?!
 
  chances are the compiler will produce the exact same code
  regardless... a cast or what is there now.
 
 
  Nah, the whole point of the cast is to convert it to unsigned, I'm
  quite certain the compiler is capable of doing that.
 
  but your casting inside the func to just avoid if (x  0)... which a
  compiler will figure out to be the same as the cast to unsigned...
 
 
 
  The cast will work for unicode values that are greater than the signed
  limit (less than 0), while the if just fail for them.
 
  there are no unicode values of that magnitude... unicode by definition
  doesnt even get close to using the most significant bit... :) it's by
  definition an invalid code if  0 (for 32bit signed)...
 
 
 
  Oh, forgot to mention, I was thinking about boxes where wchar_t is
  signed and 16bit. :) There we'll have trouble.
  If you got negative values it must mean you've reached big enough
  unicode values, so the issue I'm describing is indeed real.
 
  on boxes where its 16bit.. we will have problems... because unicode does not
  fit into 16bit we explicitly MUSt have it be a 32bit type in order to
  have enough space to store the hmmm... 22? bits needed for unicode? quick
  check... 10  is the top unicode value... that means 21bits... so
  unicode needs 21bits. if we have 16bit wchar_t's we are not able to do
  unicode. signed or not is irrelevant here. if its 32bit... we don't care :)
 
 
 Well, a subset of... :)
 
 But anyhow, how did you get your issue then? That it was negative? 
 That's what I'm interested in, as that means it's a path we actually get to.

it looked like a garbage buffer... but evas shouldnt segv if there is an
invalid unicode value there... :)


-- 
- 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] [EGIT] [core/efl] master 01/01: it is possible with wchart_t to have it signed.. so unicode can be 0... dont crash.

On 01/05/13 15:03, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 15:00:57 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 01/05/13 14:47, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 14:37:37 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 On 01/05/13 14:17, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 14:03:42 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 On 01/05/13 14:07, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 13:52:50 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 On 01/05/13 13:54, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 11:00:01 +0100 Tom Hacohen
 tom.haco...@samsung.com said:

 On 01/05/13 10:58, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 10:08:48 +0100 Tom Hacohen
 tom.haco...@samsung.com said:

 On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote:
 On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen
 tom.haco...@samsung.com said:

 Where did you get that on?
 Anyhow, what do you think about changing it to unsigned wchar_t?

 on my pentium-m test machine... unicode val 0 was  0 and thus
 walked below the array. yes. literally a negative.  wouldnt that
 be wuchar_t or something? as wchar_t .. is a typedef... :)


 Hm... Annoying. There's no wuchar_t though.

 then we have... a problem... and it requires we check for  0. :(



 I think me might be better off casting to unsigned. Damn you people
 for not doing all the char type unsigned, wth?!

 chances are the compiler will produce the exact same code
 regardless... a cast or what is there now.


 Nah, the whole point of the cast is to convert it to unsigned, I'm
 quite certain the compiler is capable of doing that.

 but your casting inside the func to just avoid if (x  0)... which a
 compiler will figure out to be the same as the cast to unsigned...



 The cast will work for unicode values that are greater than the signed
 limit (less than 0), while the if just fail for them.

 there are no unicode values of that magnitude... unicode by definition
 doesnt even get close to using the most significant bit... :) it's by
 definition an invalid code if  0 (for 32bit signed)...



 Oh, forgot to mention, I was thinking about boxes where wchar_t is
 signed and 16bit. :) There we'll have trouble.
 If you got negative values it must mean you've reached big enough
 unicode values, so the issue I'm describing is indeed real.

 on boxes where its 16bit.. we will have problems... because unicode does not
 fit into 16bit we explicitly MUSt have it be a 32bit type in order to
 have enough space to store the hmmm... 22? bits needed for unicode? quick
 check... 10  is the top unicode value... that means 21bits... so
 unicode needs 21bits. if we have 16bit wchar_t's we are not able to do
 unicode. signed or not is irrelevant here. if its 32bit... we don't care :)


 Well, a subset of... :)

 But anyhow, how did you get your issue then? That it was negative?
 That's what I'm interested in, as that means it's a path we actually get to.

 it looked like a garbage buffer... but evas shouldnt segv if there is an
 invalid unicode value there... :)



Haha, so you were hiding your bugs using my code. Making me an accessory 
to segfault!

OK though, I agree.

--
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] enlightenmant file manager make some problems while tranfaring

2013-05-01 Thread المسالم المسالمة

this way of transferring left me confused

look what happened . and then judge me as you want

in thunar . i can see the progress bar about that process  so i can
tell from it if the process is complete

and it takes 3 minutes to do the whole transferring

but in EFM all what i saw is (( transferring is complete )) without any
progress bar

and Unfortunately that didnt happened at the first time

so i give it another try to see what is the problem

and you know what

i discovered that your new feature that you are proud to see it in E17 ((
unmount / eject ))

has a bug in it

so let me explain its problem

this feature should be used by user himself ... that its purpose . but

it seems that bug let this feature to turn itself off after close EFM
windows

and this bug is the main problem that make a this problem in files
transferring

so i hope that you can fix it later

thanks again

2013/5/1 Michael Blumenkrantz michael.blumenkra...@gmail.com

 this is a known behavior. the only way to fix it would be to monitor the
 destination file size and show a progress bar based on this, but it would
 not be entirely accurate or practical.



On Wed, May 1, 2013 at 2:02 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Wed, 1 May 2013 15:07:42 +0300 المسالم المسالمة
 almusalimalmusali...@gmail.com said:

  hello again
 
  today i tried to transfer about 700 megabyte from Downloads to USB flash
  storage
 
  the problem here is
 
  after click paste from mouse left button list
 
  file manager will sow to me a message that says transferring is complete
 
  but in reality is not
 
  the transferring is still in progress
 
  so i hope that problem will be solved next release
 
  thanks again

 how is it not complete? is efm showing a progress bar? if efm/e is showing
 its
 compleye and u can see/browser thru the destination file tree.. it's
 complete.
 the rest is your KERNEL buffering/syncing and this is not a bug. it is how
 linux orks. it does everything it can in ram first... cached. spooling it
 out
 to disk later. if you don't like this... you want your fs's mounded with a
 sync
 option... and then prepare for the awesome slowness you'll enjoy :) thats
 why
 there is an unmount/eject option in menus... to ensure all ops are synced
 to
 disk before the media is removed...

 --
 - 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

--
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] Eo object data referencing

2013-05-01 Thread daniel.za...@samsung.com

On 05/01/2013 04:59 PM, Tom Hacohen wrote:
 On 01/05/13 09:13, daniel.za...@samsung.com wrote:
 Hi all,

 I pushed today the data referencing feature for Eo objects in efl and
 elementary. Check the commit log for explanations on why/how we do that.

From now, eo_data_get is deprecated, so please use eo_data_scope_get,
 eo_data_ref or eo_data_xref instead.
 Comments:
 1. Super spank, you've included unrelated changes!!!

 @@ -1240,7 +1244,7 @@ eo_xunref(Eo *obj_id, const Eo *ref_obj_id)
   Eo_Xref_Node *xref = NULL;
   EINA_INLIST_FOREACH(obj-xrefs, xref)
 {
 -if (xref-ref_obj == ref_obj)
 +if (xref-ref_obj == ref_obj_id)

 Fixes another issue that you've introduced (or so it seems).
Super spank on this!!! So yes, it's a fix of the Eo Id commit. And what? 
Spank because it is on the same commit. For that, I call you enculeur 
de mouches. Learn, it is a new french expression for you.

 2. I don't like the way you handle the data. You keep a refcount for it,
 but you actually delete the data even if the reference is non-0. You
 should do it like a true reference count.
 You should free the data once the reference count hits 0.
 You should always maintain at least one reference count (the object
 referencing it's own data) so when the object is deleted that will get
 decremented and the data will be freed or kept according to the
 maintained reference count.
I will check it. For the moment, EO_DEBUG is disabled (otherwise, we 
will have to spank the entire world for the errors that will appear). 
The most important was to push the new APIs for the release. The next 
phase of the data referencing will focus on this part.

 3. +_eo_data_xref_internal
 You return uninitialised data if klass is NULL.
 I know your code in it's current iteration won't get there, but still,
 initialise it, or remove the klass!=NULL check if you think it should
 never happen. At the moment it's unclear.
Even if we don't use it, I had to initialize it. I will fix it.
 4. I don't understand how this even get in. You didn't add tests at all.
 It's Eo, in Eo we actually test shit. I'm really tempted to just revert
 it. Especially since my e got slow and annoying since your changes
 (among others, haven't checked which).
So revert. I will not push it back. And before accusing me of making 
your E slow, just check WHICH COMMITS ARE AROUND MINE! 
Check, not the name but the contents of each.

 Bottom line. Fix it. It needs fixing. Especially test stuff. Though the
 general patch looks good and clean.
As usual, the good guy sentence!

 --
 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] [PATCH] adding check for elementary

2013-05-01 Thread Gustavo Lima Chaves

* ryuan Choi ryuan.c...@gmail.com [2013-05-01 19:48:43 +0900]:

Is github login working fine? Borked for me :( Sorry for hijacking the thread.

 Hi,
 
 While digging some elementary bug recently, I think that elementary needs
 unit testing framework like other EFL core modules in order to prevent
 regressions or understand what commits fixed.
 
 Can we have chance to introduce check for elementary?
 
 Initial commit is here.
 https://phab.enlightenment.org/D91
 
 Thanks in advance.
 --
 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

-- 
Gustavo Lima Chaves
Senior Developer @ ProFUSION Embedded Systems

--
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] Eo object data referencing

On 01/05/13 15:27, daniel.za...@samsung.com wrote:
 On 05/01/2013 04:59 PM, Tom Hacohen wrote:
 On 01/05/13 09:13, daniel.za...@samsung.com wrote:
 Hi all,

 I pushed today the data referencing feature for Eo objects in efl and
 elementary. Check the commit log for explanations on why/how we do that.

From now, eo_data_get is deprecated, so please use eo_data_scope_get,
 eo_data_ref or eo_data_xref instead.
 Comments:
 1. Super spank, you've included unrelated changes!!!

 @@ -1240,7 +1244,7 @@ eo_xunref(Eo *obj_id, const Eo *ref_obj_id)
   Eo_Xref_Node *xref = NULL;
   EINA_INLIST_FOREACH(obj-xrefs, xref)
 {
 -if (xref-ref_obj == ref_obj)
 +if (xref-ref_obj == ref_obj_id)

 Fixes another issue that you've introduced (or so it seems).
 Super spank on this!!! So yes, it's a fix of the Eo Id commit. And what?
 Spank because it is on the same commit. For that, I call you enculeur
 de mouches. Learn, it is a new french expression for you.


Dude, seriously that's *SO* not nit-picking. If there's anything 
important about committing is this. People may want to cherry-pick 
commits that fix stuff, but wouldn't want to introduce new issues. 
People (me?) might have wanted to violently revert this commit. Would 
have been really annoying had I had to commit the fix manually 
afterwards. Really, if there's one important thing, it's this.


 2. I don't like the way you handle the data. You keep a refcount for it,
 but you actually delete the data even if the reference is non-0. You
 should do it like a true reference count.
 You should free the data once the reference count hits 0.
 You should always maintain at least one reference count (the object
 referencing it's own data) so when the object is deleted that will get
 decremented and the data will be freed or kept according to the
 maintained reference count.
 I will check it. For the moment, EO_DEBUG is disabled (otherwise, we
 will have to spank the entire world for the errors that will appear).
 The most important was to push the new APIs for the release. The next
 phase of the data referencing will focus on this part.

Has nothing to do with EO_DEBUG... It's just the count itself which 
needs fixing. As you mentioned, the API is more important, nonetheless, 
this should be fixed.


 3. +_eo_data_xref_internal
 You return uninitialised data if klass is NULL.
 I know your code in it's current iteration won't get there, but still,
 initialise it, or remove the klass!=NULL check if you think it should
 never happen. At the moment it's unclear.
 Even if we don't use it, I had to initialize it. I will fix it.

Cool.

 4. I don't understand how this even get in. You didn't add tests at all.
 It's Eo, in Eo we actually test shit. I'm really tempted to just revert
 it. Especially since my e got slow and annoying since your changes
 (among others, haven't checked which).
 So revert. I will not push it back. And before accusing me of making
 your E slow, just check WHICH COMMITS ARE AROUND MINE!
 Check, not the name but the contents of each.

I didn't say it was you, and as I told you on IRC (or xmpp, can't 
remember), I'm looking into that. It actually doesn't look like you.
That was just an additional comment, the most important part is the 
inclusion of testing, which you have SERIOUSLY fucked up. As I've said, 
Eo is CORE if Eo breaks, everything breaks. Eo should be tested. Well 
everything should be tested, but Eo must be tested. Also, Eo is already 
well tested, don't ruin that.


 Bottom line. Fix it. It needs fixing. Especially test stuff. Though the
 general patch looks good and clean.
 As usual, the good guy sentence!

I'm a schizophrenic good-cop, bad-cop, you know that.

--
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] [PATCH] adding check for elementary

On 01/05/13 15:32, Gustavo Lima Chaves wrote:
 * ryuan Choi ryuan.c...@gmail.com [2013-05-01 19:48:43 +0900]:

 Is github login working fine? Borked for me :( Sorry for hijacking the thread.

If you are sorry, why did you do it? :)

Anyhow, I thought I've fixed it, let me check to see if there's anything 
else to be done.

--
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] [PATCH] adding check for elementary

On 01/05/13 15:39, Tom Hacohen wrote:
 On 01/05/13 15:32, Gustavo Lima Chaves wrote:
 * ryuan Choi ryuan.c...@gmail.com [2013-05-01 19:48:43 +0900]:

 Is github login working fine? Borked for me :( Sorry for hijacking the 
 thread.

 If you are sorry, why did you do it? :)

 Anyhow, I thought I've fixed it, let me check to see if there's anything
 else to be done.

I think it's fixed, please try now.

--
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] [EGIT] [core/efl] master 01/01: it is possible with wchart_t to have it signed.. so unicode can be 0... dont crash.

On Wed, 01 May 2013 15:10:26 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 01/05/13 15:03, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 15:00:57 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 01/05/13 14:47, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 14:37:37 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 01/05/13 14:17, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 14:03:42 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 01/05/13 14:07, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 13:52:50 +0100 Tom Hacohen
  tom.haco...@samsung.com said:
 
  On 01/05/13 13:54, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 11:00:01 +0100 Tom Hacohen
  tom.haco...@samsung.com said:
 
  On 01/05/13 10:58, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 10:08:48 +0100 Tom Hacohen
  tom.haco...@samsung.com said:
 
  On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote:
  On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen
  tom.haco...@samsung.com said:
 
  Where did you get that on?
  Anyhow, what do you think about changing it to unsigned
  wchar_t?
 
  on my pentium-m test machine... unicode val 0 was  0 and thus
  walked below the array. yes. literally a negative.  wouldnt that
  be wuchar_t or something? as wchar_t .. is a typedef... :)
 
 
  Hm... Annoying. There's no wuchar_t though.
 
  then we have... a problem... and it requires we check for  0. :(
 
 
 
  I think me might be better off casting to unsigned. Damn you people
  for not doing all the char type unsigned, wth?!
 
  chances are the compiler will produce the exact same code
  regardless... a cast or what is there now.
 
 
  Nah, the whole point of the cast is to convert it to unsigned, I'm
  quite certain the compiler is capable of doing that.
 
  but your casting inside the func to just avoid if (x  0)... which a
  compiler will figure out to be the same as the cast to unsigned...
 
 
 
  The cast will work for unicode values that are greater than the signed
  limit (less than 0), while the if just fail for them.
 
  there are no unicode values of that magnitude... unicode by definition
  doesnt even get close to using the most significant bit... :) it's by
  definition an invalid code if  0 (for 32bit signed)...
 
 
 
  Oh, forgot to mention, I was thinking about boxes where wchar_t is
  signed and 16bit. :) There we'll have trouble.
  If you got negative values it must mean you've reached big enough
  unicode values, so the issue I'm describing is indeed real.
 
  on boxes where its 16bit.. we will have problems... because unicode does
  not fit into 16bit we explicitly MUSt have it be a 32bit type in
  order to have enough space to store the hmmm... 22? bits needed for
  unicode? quick check... 10  is the top unicode value... that means
  21bits... so unicode needs 21bits. if we have 16bit wchar_t's we are not
  able to do unicode. signed or not is irrelevant here. if its 32bit... we
  don't care :)
 
 
  Well, a subset of... :)
 
  But anyhow, how did you get your issue then? That it was negative?
  That's what I'm interested in, as that means it's a path we actually get
  to.
 
  it looked like a garbage buffer... but evas shouldnt segv if there is an
  invalid unicode value there... :)
 
 
 
 Haha, so you were hiding your bugs using my code. Making me an accessory 
 to segfault!
 
 OK though, I agree.

buffer still was nul terminated... :)

-- 
- 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

[E-devel] E is being super slow because of EFL changes.

Hey dudes,

So E gets super slow after a few minutes of usage. The reason is one of 
the commits in this range (EFL repo): 
2e699fbab9abb2ddaac85661af329b0f16bacf16..dee226221447fad70c8e847014f34789d207a549

Here is the list of commits, if you see your name on this list, make 
sure it wasn't your code who broke everything.


commit dee226221447fad70c8e847014f34789d207a549
Author: Chris Michael cp.mich...@samsung.com

 Remove hack for changed state.

commit 1c442867c47a417c92e2672efd36dad145acc8c6
Author: Chris Michael cp.mich...@samsung.com

 Remove duplicated wdata variable.

commit 127bee584d9083019b14697a1d087f5d69bf9ad1
Author: Chris Michael cp.mich...@samsung.com

 Revert Fix some formatting.

commit 6f6a0951f283734b4b144592799dd73ec8dd8de0
Author: Chris Michael cp.mich...@samsung.com

 Revert Check for valid engine resize function before calling it.

commit 9372a1e21714e470076a3186beb458fab26bbc0b
Author: Chris Michael cp.mich...@samsung.com

 Revert Reduce duplicated code and comment out region_add sections 
that are

commit 1f58a59a61804b21915e29595d5565c2487f7bac
Author: Rafael Antognolli rafael.antogno...@intel.com

 ecore_evas/wayland: Remove hack for changed state.

commit a9b500370ab0c98e58fe26e8b878bcb387e99099
Author: Rafael Antognolli rafael.antogno...@intel.com

 ecore/wayalnd: Add some getters to ecore_wl_window.

commit f2d550f986e5f66ab1a62bcee01614894b9b6d8a
Author: Daniel Juyung Seo seojuy...@gmail.com

 edc.vim: updated more label and constants for multisense.

commit ab0fdf5916757d9f30c606ef464f10852d7fa42d
Author: Carsten Haitzler (Rasterman) ras...@rasterman.com

 it is possible with wchart_t to have it signed.. so unicode can be 
 0... dont crash.

commit 809144780e79387b0dfa55abd117fa0bb8d0a627
Author: Chris Michael cp.mich...@samsung.com

 Fix some formatting.
 Reduce duplicated code in ecore_evas_wl_resize and just call the
 _common_resize function
 Fix segfault on elm app closing

commit b9fa3b30892adb1b1e57840e31dda66a84c33108
Author: Chris Michael cp.mich...@samsung.com

 We don't need evas_sync on resize here.

commit 6e0075aa0491003ea717a248dea9886e99cc489b
Author: Chris Michael cp.mich...@samsung.com

 Check for valid engine resize function before calling it.
 In the window_configure callback, reduce duplicated/not needed code.
 Account for rotation when getting new size during common_rotation_set.
 Reduce duplicated code in ecore_evas_wl_resize function and just call
 the _common_resize function (as that already has most of this code).

commit 279c5ac28e93ef6f02dc890435eb5342efe19571
Author: Chris Michael cp.mich...@samsung.com

 Reduce duplicated code and comment out region_add sections that are
 not needed.
 During buffer_attach, just call window_damage function which already
 handles surface_damage  commit.

commit 53f9d6ce8cfbff4ea0f3c901a2a53a3f45cb9d3a
Author: Chris Michael cp.mich...@samsung.com

 Check for a valid buffer before we free it (this fixes resize issues
 when async_render).

commit 036454746b1937789a2b2fe9d80f32661f6047fa
Author: Chris Michael cp.mich...@samsung.com

 Fix update_region to use bpl from the buffer

commit 2ac4cdce762184fe46865ee7dcb69ed86abf19cf
Author: Daniel Zaoui daniel.za...@samsung.com

 Eo: Fix for warning on 64 bits.

commit 29ef0f71bab1971c1703ec605319d1289f06fc0d
Author: ChunEon Park chuneon.p...@samsung.com

 evas - fix the wrong compare. thanks JackDanielZ for spotting it.

commit c71edd740c5ac8efaff8a2b624336357ce2e736f
Author: Chris Michael cp.mich...@samsung.com

 Add some initial code to create the Outbuf and to free it.

commit 79b65ab1846b8130aa08d2c8805fde5c150923d9
Author: Chris Michael cp.mich...@samsung.com

 Override the output_free engine function.
 Add code to cleanup on engine shutdown.

commit 6a369b2a2ae2dff1dc572477ae7a0610e4930611
Author: Chris Michael cp.mich...@samsung.com

 If we have an existing outbuf, then free the old one and try to create
 a new one.

commit e701a13e868684d89141121044806507d5728830
Author: Chris Michael cp.mich...@samsung.com

 Add outbuf file to drm build.

commit 021e76aa258d7852e6ef724a7053cb7be57ad693
Author: Chris Michael cp.mich...@samsung.com

 Try to create the Outbuf during initial engine setup.

commit 248c2f8233e6ecbe6054aa56589831ca41eb9b9e
Author: Chris Michael cp.mich...@samsung.com

 Add initial file for Outbuf

commit a67894a5a71ea3ca4c90f3249e0a445f9bc1b2be
Author: Chris Michael cp.mich...@samsung.com

 Add Render_Engine structure
 Start on code to setup the output buffer.
 Add code to init evas_common functions
 Add override for engine setup.

commit b607e66f68f7966078626d4e98faf87ac53114ff
Author: Chris Michael cp.mich...@samsung.com

 Add Outbuf structure and some function prototypes

commit 8ef46df20dd4e20ae378b22dab5a6f276a1f606e
Author: Chris Michael cp.mich...@samsung.com

 Add rotation,

Re: [E-devel] E is being super slow because of EFL changes.

On Wed, 01 May 2013 15:49:11 +0100 Tom Hacohen tom.haco...@samsung.com said:

i blame cedric. my commit sure didn't do it! :) seriously... if this is really
happening.. this is a big problem.  given the commits.. DEVILHORNS! check your
mush! :)

 Hey dudes,
 
 So E gets super slow after a few minutes of usage. The reason is one of 
 the commits in this range (EFL repo): 
 2e699fbab9abb2ddaac85661af329b0f16bacf16..dee226221447fad70c8e847014f34789d207a549
 
 Here is the list of commits, if you see your name on this list, make 
 sure it wasn't your code who broke everything.
 
 
 commit dee226221447fad70c8e847014f34789d207a549
 Author: Chris Michael cp.mich...@samsung.com
 
  Remove hack for changed state.
 
 commit 1c442867c47a417c92e2672efd36dad145acc8c6
 Author: Chris Michael cp.mich...@samsung.com
 
  Remove duplicated wdata variable.
 
 commit 127bee584d9083019b14697a1d087f5d69bf9ad1
 Author: Chris Michael cp.mich...@samsung.com
 
  Revert Fix some formatting.
 
 commit 6f6a0951f283734b4b144592799dd73ec8dd8de0
 Author: Chris Michael cp.mich...@samsung.com
 
  Revert Check for valid engine resize function before calling it.
 
 commit 9372a1e21714e470076a3186beb458fab26bbc0b
 Author: Chris Michael cp.mich...@samsung.com
 
  Revert Reduce duplicated code and comment out region_add sections 
 that are
 
 commit 1f58a59a61804b21915e29595d5565c2487f7bac
 Author: Rafael Antognolli rafael.antogno...@intel.com
 
  ecore_evas/wayland: Remove hack for changed state.
 
 commit a9b500370ab0c98e58fe26e8b878bcb387e99099
 Author: Rafael Antognolli rafael.antogno...@intel.com
 
  ecore/wayalnd: Add some getters to ecore_wl_window.
 
 commit f2d550f986e5f66ab1a62bcee01614894b9b6d8a
 Author: Daniel Juyung Seo seojuy...@gmail.com
 
  edc.vim: updated more label and constants for multisense.
 
 commit ab0fdf5916757d9f30c606ef464f10852d7fa42d
 Author: Carsten Haitzler (Rasterman) ras...@rasterman.com
 
  it is possible with wchart_t to have it signed.. so unicode can be 
  0... dont crash.
 
 commit 809144780e79387b0dfa55abd117fa0bb8d0a627
 Author: Chris Michael cp.mich...@samsung.com
 
  Fix some formatting.
  Reduce duplicated code in ecore_evas_wl_resize and just call the
  _common_resize function
  Fix segfault on elm app closing
 
 commit b9fa3b30892adb1b1e57840e31dda66a84c33108
 Author: Chris Michael cp.mich...@samsung.com
 
  We don't need evas_sync on resize here.
 
 commit 6e0075aa0491003ea717a248dea9886e99cc489b
 Author: Chris Michael cp.mich...@samsung.com
 
  Check for valid engine resize function before calling it.
  In the window_configure callback, reduce duplicated/not needed code.
  Account for rotation when getting new size during common_rotation_set.
  Reduce duplicated code in ecore_evas_wl_resize function and just call
  the _common_resize function (as that already has most of this code).
 
 commit 279c5ac28e93ef6f02dc890435eb5342efe19571
 Author: Chris Michael cp.mich...@samsung.com
 
  Reduce duplicated code and comment out region_add sections that are
  not needed.
  During buffer_attach, just call window_damage function which already
  handles surface_damage  commit.
 
 commit 53f9d6ce8cfbff4ea0f3c901a2a53a3f45cb9d3a
 Author: Chris Michael cp.mich...@samsung.com
 
  Check for a valid buffer before we free it (this fixes resize issues
  when async_render).
 
 commit 036454746b1937789a2b2fe9d80f32661f6047fa
 Author: Chris Michael cp.mich...@samsung.com
 
  Fix update_region to use bpl from the buffer
 
 commit 2ac4cdce762184fe46865ee7dcb69ed86abf19cf
 Author: Daniel Zaoui daniel.za...@samsung.com
 
  Eo: Fix for warning on 64 bits.
 
 commit 29ef0f71bab1971c1703ec605319d1289f06fc0d
 Author: ChunEon Park chuneon.p...@samsung.com
 
  evas - fix the wrong compare. thanks JackDanielZ for spotting it.
 
 commit c71edd740c5ac8efaff8a2b624336357ce2e736f
 Author: Chris Michael cp.mich...@samsung.com
 
  Add some initial code to create the Outbuf and to free it.
 
 commit 79b65ab1846b8130aa08d2c8805fde5c150923d9
 Author: Chris Michael cp.mich...@samsung.com
 
  Override the output_free engine function.
  Add code to cleanup on engine shutdown.
 
 commit 6a369b2a2ae2dff1dc572477ae7a0610e4930611
 Author: Chris Michael cp.mich...@samsung.com
 
  If we have an existing outbuf, then free the old one and try to create
  a new one.
 
 commit e701a13e868684d89141121044806507d5728830
 Author: Chris Michael cp.mich...@samsung.com
 
  Add outbuf file to drm build.
 
 commit 021e76aa258d7852e6ef724a7053cb7be57ad693
 Author: Chris Michael cp.mich...@samsung.com
 
  Try to create the Outbuf during initial engine setup.
 
 commit 248c2f8233e6ecbe6054aa56589831ca41eb9b9e
 Author: Chris Michael cp.mich...@samsung.com
 
  Add initial file for Outbuf
 
 commit a67894a5a71ea3ca4c90f3249e0a445f9bc1b2be
 Author: Chris Michael cp.mich...@samsung.com
 
  Add Render_Engine structure

Re: [E-devel] [PATCH] adding check for elementary

2013-05-01 Thread Gustavo Lima Chaves

* Tom Hacohen tom.haco...@samsung.com [2013-05-01 15:41:44 +0100]:

 On 01/05/13 15:39, Tom Hacohen wrote:
  On 01/05/13 15:32, Gustavo Lima Chaves wrote:
  * ryuan Choi ryuan.c...@gmail.com [2013-05-01 19:48:43 +0900]:
 
  Is github login working fine? Borked for me :( Sorry for hijacking the 
  thread.
 
  If you are sorry, why did you do it? :)
 
  Anyhow, I thought I've fixed it, let me check to see if there's anything
  else to be done.
 
 I think it's fixed, please try now.

Working fine! Thanks, Tom :)

 
 --
 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

-- 
Gustavo Lima Chaves
Senior Developer @ ProFUSION Embedded Systems

--
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] [EGIT] [core/efl] master 01/01: it is possible with wchart_t to have it signed.. so unicode can be 0... dont crash.

On 01/05/13 15:42, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 15:10:26 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 01/05/13 15:03, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 15:00:57 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 On 01/05/13 14:47, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 14:37:37 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 On 01/05/13 14:17, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 14:03:42 +0100 Tom Hacohen tom.haco...@samsung.com
 said:

 On 01/05/13 14:07, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 13:52:50 +0100 Tom Hacohen
 tom.haco...@samsung.com said:

 On 01/05/13 13:54, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 11:00:01 +0100 Tom Hacohen
 tom.haco...@samsung.com said:

 On 01/05/13 10:58, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 01 May 2013 10:08:48 +0100 Tom Hacohen
 tom.haco...@samsung.com said:

 On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote:
 On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen
 tom.haco...@samsung.com said:

 Where did you get that on?
 Anyhow, what do you think about changing it to unsigned
 wchar_t?

 on my pentium-m test machine... unicode val 0 was  0 and thus
 walked below the array. yes. literally a negative.  wouldnt that
 be wuchar_t or something? as wchar_t .. is a typedef... :)


 Hm... Annoying. There's no wuchar_t though.

 then we have... a problem... and it requires we check for  0. :(



 I think me might be better off casting to unsigned. Damn you people
 for not doing all the char type unsigned, wth?!

 chances are the compiler will produce the exact same code
 regardless... a cast or what is there now.


 Nah, the whole point of the cast is to convert it to unsigned, I'm
 quite certain the compiler is capable of doing that.

 but your casting inside the func to just avoid if (x  0)... which a
 compiler will figure out to be the same as the cast to unsigned...



 The cast will work for unicode values that are greater than the signed
 limit (less than 0), while the if just fail for them.

 there are no unicode values of that magnitude... unicode by definition
 doesnt even get close to using the most significant bit... :) it's by
 definition an invalid code if  0 (for 32bit signed)...



 Oh, forgot to mention, I was thinking about boxes where wchar_t is
 signed and 16bit. :) There we'll have trouble.
 If you got negative values it must mean you've reached big enough
 unicode values, so the issue I'm describing is indeed real.

 on boxes where its 16bit.. we will have problems... because unicode does
 not fit into 16bit we explicitly MUSt have it be a 32bit type in
 order to have enough space to store the hmmm... 22? bits needed for
 unicode? quick check... 10  is the top unicode value... that means
 21bits... so unicode needs 21bits. if we have 16bit wchar_t's we are not
 able to do unicode. signed or not is irrelevant here. if its 32bit... we
 don't care :)


 Well, a subset of... :)

 But anyhow, how did you get your issue then? That it was negative?
 That's what I'm interested in, as that means it's a path we actually get
 to.

 it looked like a garbage buffer... but evas shouldnt segv if there is an
 invalid unicode value there... :)



 Haha, so you were hiding your bugs using my code. Making me an accessory
 to segfault!

 OK though, I agree.

 buffer still was nul terminated... :)


At index 14354545? :P

--
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] Cgit enhancements

On 30/04/13 21:29, Bertrand Jacquin wrote:
 Hi in there,

 Here is a couple of improvements in cgit interfaces :

   - You are now able to filter the view by appending a directory in the
   URL to show the repositories of a specific directory. For exemple, to
   see only core/ repo:
http://git.enlightenment.org/core

   Only legacy/binding:
http://git.enlightenment.org/legacy/bindings

   Only seoz repo:
http://git.enlightenment.org/devs/seoz

   - Also, developers have their own section for make the presentation a
   bit more comfortable instead of all merge sorted by dev. Still at the
   end of the list



Very nice, thanks!

--
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] [EGIT] [core/efl] master 01/01: it is possible with wchart_t to have it signed.. so unicode can be 0... dont crash.

On Wed, 01 May 2013 16:28:17 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 01/05/13 15:42, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 15:10:26 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 01/05/13 15:03, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 15:00:57 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 01/05/13 14:47, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 14:37:37 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  On 01/05/13 14:17, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 14:03:42 +0100 Tom Hacohen
  tom.haco...@samsung.com said:
 
  On 01/05/13 14:07, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 13:52:50 +0100 Tom Hacohen
  tom.haco...@samsung.com said:
 
  On 01/05/13 13:54, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 11:00:01 +0100 Tom Hacohen
  tom.haco...@samsung.com said:
 
  On 01/05/13 10:58, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 01 May 2013 10:08:48 +0100 Tom Hacohen
  tom.haco...@samsung.com said:
 
  On 30/04/13 18:48, Carsten Haitzler (The Rasterman) wrote:
  On Tue, 30 Apr 2013 15:15:05 +0100 Tom Hacohen
  tom.haco...@samsung.com said:
 
  Where did you get that on?
  Anyhow, what do you think about changing it to unsigned
  wchar_t?
 
  on my pentium-m test machine... unicode val 0 was  0 and thus
  walked below the array. yes. literally a negative.  wouldnt
  that be wuchar_t or something? as wchar_t .. is a
  typedef... :)
 
 
  Hm... Annoying. There's no wuchar_t though.
 
  then we have... a problem... and it requires we check for  0. :
  (
 
 
 
  I think me might be better off casting to unsigned. Damn you
  people for not doing all the char type unsigned, wth?!
 
  chances are the compiler will produce the exact same code
  regardless... a cast or what is there now.
 
 
  Nah, the whole point of the cast is to convert it to unsigned, I'm
  quite certain the compiler is capable of doing that.
 
  but your casting inside the func to just avoid if (x  0)... which a
  compiler will figure out to be the same as the cast to unsigned...
 
 
 
  The cast will work for unicode values that are greater than the
  signed limit (less than 0), while the if just fail for them.
 
  there are no unicode values of that magnitude... unicode by definition
  doesnt even get close to using the most significant bit... :) it's by
  definition an invalid code if  0 (for 32bit signed)...
 
 
 
  Oh, forgot to mention, I was thinking about boxes where wchar_t is
  signed and 16bit. :) There we'll have trouble.
  If you got negative values it must mean you've reached big enough
  unicode values, so the issue I'm describing is indeed real.
 
  on boxes where its 16bit.. we will have problems... because unicode does
  not fit into 16bit we explicitly MUSt have it be a 32bit type in
  order to have enough space to store the hmmm... 22? bits needed for
  unicode? quick check... 10  is the top unicode value... that means
  21bits... so unicode needs 21bits. if we have 16bit wchar_t's we are not
  able to do unicode. signed or not is irrelevant here. if its 32bit... we
  don't care :)
 
 
  Well, a subset of... :)
 
  But anyhow, how did you get your issue then? That it was negative?
  That's what I'm interested in, as that means it's a path we actually get
  to.
 
  it looked like a garbage buffer... but evas shouldnt segv if there is an
  invalid unicode value there... :)
 
 
 
  Haha, so you were hiding your bugs using my code. Making me an accessory
  to segfault!
 
  OK though, I agree.
 
  buffer still was nul terminated... :)
 
 
 At index 14354545? :P

:-P


-- 
- 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] E is being super slow because of EFL changes.

On Wed, 1 May 2013 23:53:20 +0900 Carsten Haitzler (The Rasterman)
ras...@rasterman.com said:

 On Wed, 01 May 2013 15:49:11 +0100 Tom Hacohen tom.haco...@samsung.com said:
 
 i blame cedric. my commit sure didn't do it! :) seriously... if this is really
 happening.. this is a big problem.  given the commits.. DEVILHORNS! check your
 mush! :)

other candidate after some more looking... jackdaniels! :)... who is it? it's a
race.

tom: it might be worth narrowing down the commit... :)

  Hey dudes,
  
  So E gets super slow after a few minutes of usage. The reason is one of 
  the commits in this range (EFL repo): 
  2e699fbab9abb2ddaac85661af329b0f16bacf16..dee226221447fad70c8e847014f34789d207a549
  
  Here is the list of commits, if you see your name on this list, make 
  sure it wasn't your code who broke everything.
  
  
  commit dee226221447fad70c8e847014f34789d207a549
  Author: Chris Michael cp.mich...@samsung.com
  
   Remove hack for changed state.
  
  commit 1c442867c47a417c92e2672efd36dad145acc8c6
  Author: Chris Michael cp.mich...@samsung.com
  
   Remove duplicated wdata variable.
  
  commit 127bee584d9083019b14697a1d087f5d69bf9ad1
  Author: Chris Michael cp.mich...@samsung.com
  
   Revert Fix some formatting.
  
  commit 6f6a0951f283734b4b144592799dd73ec8dd8de0
  Author: Chris Michael cp.mich...@samsung.com
  
   Revert Check for valid engine resize function before calling it.
  
  commit 9372a1e21714e470076a3186beb458fab26bbc0b
  Author: Chris Michael cp.mich...@samsung.com
  
   Revert Reduce duplicated code and comment out region_add sections 
  that are
  
  commit 1f58a59a61804b21915e29595d5565c2487f7bac
  Author: Rafael Antognolli rafael.antogno...@intel.com
  
   ecore_evas/wayland: Remove hack for changed state.
  
  commit a9b500370ab0c98e58fe26e8b878bcb387e99099
  Author: Rafael Antognolli rafael.antogno...@intel.com
  
   ecore/wayalnd: Add some getters to ecore_wl_window.
  
  commit f2d550f986e5f66ab1a62bcee01614894b9b6d8a
  Author: Daniel Juyung Seo seojuy...@gmail.com
  
   edc.vim: updated more label and constants for multisense.
  
  commit ab0fdf5916757d9f30c606ef464f10852d7fa42d
  Author: Carsten Haitzler (Rasterman) ras...@rasterman.com
  
   it is possible with wchart_t to have it signed.. so unicode can be 
   0... dont crash.
  
  commit 809144780e79387b0dfa55abd117fa0bb8d0a627
  Author: Chris Michael cp.mich...@samsung.com
  
   Fix some formatting.
   Reduce duplicated code in ecore_evas_wl_resize and just call the
   _common_resize function
   Fix segfault on elm app closing
  
  commit b9fa3b30892adb1b1e57840e31dda66a84c33108
  Author: Chris Michael cp.mich...@samsung.com
  
   We don't need evas_sync on resize here.
  
  commit 6e0075aa0491003ea717a248dea9886e99cc489b
  Author: Chris Michael cp.mich...@samsung.com
  
   Check for valid engine resize function before calling it.
   In the window_configure callback, reduce duplicated/not needed code.
   Account for rotation when getting new size during common_rotation_set.
   Reduce duplicated code in ecore_evas_wl_resize function and just call
   the _common_resize function (as that already has most of this code).
  
  commit 279c5ac28e93ef6f02dc890435eb5342efe19571
  Author: Chris Michael cp.mich...@samsung.com
  
   Reduce duplicated code and comment out region_add sections that are
   not needed.
   During buffer_attach, just call window_damage function which already
   handles surface_damage  commit.
  
  commit 53f9d6ce8cfbff4ea0f3c901a2a53a3f45cb9d3a
  Author: Chris Michael cp.mich...@samsung.com
  
   Check for a valid buffer before we free it (this fixes resize issues
   when async_render).
  
  commit 036454746b1937789a2b2fe9d80f32661f6047fa
  Author: Chris Michael cp.mich...@samsung.com
  
   Fix update_region to use bpl from the buffer
  
  commit 2ac4cdce762184fe46865ee7dcb69ed86abf19cf
  Author: Daniel Zaoui daniel.za...@samsung.com
  
   Eo: Fix for warning on 64 bits.
  
  commit 29ef0f71bab1971c1703ec605319d1289f06fc0d
  Author: ChunEon Park chuneon.p...@samsung.com
  
   evas - fix the wrong compare. thanks JackDanielZ for spotting it.
  
  commit c71edd740c5ac8efaff8a2b624336357ce2e736f
  Author: Chris Michael cp.mich...@samsung.com
  
   Add some initial code to create the Outbuf and to free it.
  
  commit 79b65ab1846b8130aa08d2c8805fde5c150923d9
  Author: Chris Michael cp.mich...@samsung.com
  
   Override the output_free engine function.
   Add code to cleanup on engine shutdown.
  
  commit 6a369b2a2ae2dff1dc572477ae7a0610e4930611
  Author: Chris Michael cp.mich...@samsung.com
  
   If we have an existing outbuf, then free the old one and try to create
   a new one.
  
  commit e701a13e868684d89141121044806507d5728830
  Author: Chris Michael cp.mich...@samsung.com
  
   Add outbuf file to drm build.
  
  commit 021e76aa258d7852e6ef724a7053cb7be57ad693

Re: [E-devel] E is being super slow because of EFL changes.

On 01/05/13 17:10, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 1 May 2013 23:53:20 +0900 Carsten Haitzler (The Rasterman)
 ras...@rasterman.com said:

 On Wed, 01 May 2013 15:49:11 +0100 Tom Hacohen tom.haco...@samsung.com 
 said:

 i blame cedric. my commit sure didn't do it! :) seriously... if this is 
 really
 happening.. this is a big problem.  given the commits.. DEVILHORNS! check 
 your
 mush! :)

 other candidate after some more looking... jackdaniels! :)... who is it? it's 
 a
 race.

 tom: it might be worth narrowing down the commit... :)

Yeah. The problem is that it only happens after a few minutes of usage, 
which makes it quite a PITA to track. Will give it a go though, I guess. 
If not one stands up and takes responsibility.

--
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] E is being super slow because of EFL changes.

On 01/05/13 17:10, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 1 May 2013 23:53:20 +0900 Carsten Haitzler (The Rasterman)
 ras...@rasterman.com said:

 On Wed, 01 May 2013 15:49:11 +0100 Tom Hacohen tom.haco...@samsung.com 
 said:

 i blame cedric. my commit sure didn't do it! :) seriously... if this is 
 really
 happening.. this is a big problem.  given the commits.. DEVILHORNS! check 
 your
 mush! :)

 other candidate after some more looking... jackdaniels! :)... who is it? it's 
 a
 race.


Hm... ? I think JackDanielZ lost the race. He only has one commit in 
this range
(run: git log 
2e699fbab9abb2ddaac85661af329b0f16bacf16..dee226221447fad70c8e847014f34789d207a549).

I'm trying to bisect now. Really hard, as I don't even know how to 
trigger it. I think it's time related, but it might as well be something 
I did at that point in time.

--
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] Building python-efl

2013-05-01 Thread Davide Andreoli

2013/4/30 Massimo Maiurana maiur...@gmail.com

 Davide Andreoli, il 30/04/2013 12:26, ha scritto:

  installing cython is super simple, just download from:
http://www.cython.org/release/Cython-0.17.3.tar.gz
  and install with:
(sudo) python setup.py install
  it need the python-dev package

 Ok, I installed it, then tried to install python-efl with
 prefix=/opt/e17 but got another error when it tried to build efl.evas:

 Cythonizing efl/evas/efl.evas.pyx
 warning: efl/evas/efl.evas_object_image.pxi:1268:4: Overriding cdef
 method with def method.
 usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: setup.py --help [cmd1 cmd2 ...]
or: setup.py --help-commands
or: setup.py cmd --help
 error: option --prefix not recognized

 Looks like --prefix is correctly recognized by ecore, edje, elementary,
 emotion, eo, but not by evas.


hmmm, this is so strange :/
what command are you using to build?



 --

   Massimo Maiurana   GPG keyID #7044D601

   La fede e' credere in cio' che sai non essere vero
 [Mark Twain]


 --
 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] E is being super slow because of EFL changes.

On Wed, 01 May 2013 17:22:38 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 01/05/13 17:10, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 1 May 2013 23:53:20 +0900 Carsten Haitzler (The Rasterman)
  ras...@rasterman.com said:
 
  On Wed, 01 May 2013 15:49:11 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  i blame cedric. my commit sure didn't do it! :) seriously... if this is
  really happening.. this is a big problem.  given the commits.. DEVILHORNS!
  check your mush! :)
 
  other candidate after some more looking... jackdaniels! :)... who is it?
  it's a race.
 
 
 Hm... ? I think JackDanielZ lost the race. He only has one commit in 
 this range
 (run: git log 
 2e699fbab9abb2ddaac85661af329b0f16bacf16..dee226221447fad70c8e847014f34789d207a549).

but it touches a LOT of stuff... the eo_data_get change... no? oh no it's not!
hmmm... hmm well... then... dh made most of the changes... other than cedric (0
commits in that range) he's my other suspect. :)

 I'm trying to bisect now. Really hard, as I don't even know how to 
 trigger it. I think it's time related, but it might as well be something 
 I did at that point in time.

argh. heisenbug!

 --
 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
 


-- 
- 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

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

[E-devel] terminology - less scroll up broken..

try up-arrow in less... borkens. it was commit
cff21ea5b8e98e66dfecf1e9e2f16fd37f83ce64 that broke things. i havent narrowed
down WHAT in there it is.. yet.

-- 
- 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] E is being super slow because of EFL changes.

2013-05-01 Thread Daniel Juyung Seo

Aggg maybe my edc.vim change triggered it!

commit f2d550f986e5f66ab1a62bcee01614
894b9b6d8a
Author: Daniel Juyung Seo seojuy...@gmail.com

 edc.vim: updated more label and constants for multisense.

On Thu, May 2, 2013 at 8:35 AM, Carsten Haitzler ras...@rasterman.com wrote:
 On Wed, 01 May 2013 17:22:38 +0100 Tom Hacohen tom.haco...@samsung.com said:

 On 01/05/13 17:10, Carsten Haitzler (The Rasterman) wrote:
  On Wed, 1 May 2013 23:53:20 +0900 Carsten Haitzler (The Rasterman)
  ras...@rasterman.com said:
 
  On Wed, 01 May 2013 15:49:11 +0100 Tom Hacohen tom.haco...@samsung.com
  said:
 
  i blame cedric. my commit sure didn't do it! :) seriously... if this is
  really happening.. this is a big problem.  given the commits.. DEVILHORNS!
  check your mush! :)
 
  other candidate after some more looking... jackdaniels! :)... who is it?
  it's a race.
 

 Hm... ? I think JackDanielZ lost the race. He only has one commit in
 this range
 (run: git log
 2e699fbab9abb2ddaac85661af329b0f16bacf16..dee226221447fad70c8e847014f34789d207a549).

 but it touches a LOT of stuff... the eo_data_get change... no? oh no it's not!
 hmmm... hmm well... then... dh made most of the changes... other than cedric 
 (0
 commits in that range) he's my other suspect. :)

 I'm trying to bisect now. Really hard, as I don't even know how to
 trigger it. I think it's time related, but it might as well be something
 I did at that point in time.

 argh. heisenbug!

 --
 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



 --
 - 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

--
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] terminology - less scroll up broken..

On Thu, 2 May 2013 09:22:01 +0900 Carsten Haitzler (The Rasterman)
ras...@rasterman.com said:

 try up-arrow in less... borkens. it was commit
 cff21ea5b8e98e66dfecf1e9e2f16fd37f83ce64 that broke things. i havent narrowed
 down WHAT in there it is.. yet.

oh and i think this also breaks htop updates.. over time chars and lines become
blank... as it keeps updating...

-- 
- 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] terminology - less scroll up broken..

2013-05-01 Thread Daniel Juyung Seo

+ the weird strings I reported on phab.

https://phab.enlightenment.org/rTRM65f07f77003b6d22637548428d464dff0b773b40

Daniel Juyung Seo (SeoZ)

On Thu, May 2, 2013 at 11:45 AM, Carsten Haitzler ras...@rasterman.com wrote:
 On Thu, 2 May 2013 09:22:01 +0900 Carsten Haitzler (The Rasterman)
 ras...@rasterman.com said:

 try up-arrow in less... borkens. it was commit
 cff21ea5b8e98e66dfecf1e9e2f16fd37f83ce64 that broke things. i havent narrowed
 down WHAT in there it is.. yet.

 oh and i think this also breaks htop updates.. over time chars and lines 
 become
 blank... as it keeps updating...

 --
 - 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

--
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

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

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

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

Re: [E-devel] E is being super slow because of EFL changes.