Re: [E-devel] Shared Strings

[Peter Wehrfritz]

Nathan Ingersoll schrieb:
 Were these numbers from ecore before or after cedric's changes this morning?
   

I updated ecore_data just before.

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Network Manager

[Atton Jonathan]

On Wed, 7 May 2008 21:47:44 +0200
Stefan Schmidt [EMAIL PROTECTED] wrote:

 
 Sounds good. Some first ideas:
 o Gadget for the shelf to show signal strength for wifi, gsm/3g
   and indicates what kind of connection is used atm.
 o Click on the gadget shows available wifi networks, and other
   network connections like ethernet (Only with connected cable?) and
   wireless broadband modems.
Show all the interface with their state, a picture for example (not
link, not activate  ...), as exalt does. I think it's better to have a
complete status of the computer.  You can look the exalt page for some
screen-shots:
http://watchwolf.fr/wiki/doku.php?id=exaltDokuWiki=2bf5ee6465fc1ce8875bf7431e7a6c51

 o Some kind of advanced settings UI. Handling stored connections,
   set IP address, stuff for complicated wifi setup, etc.. Not sure
   how connected this should be to the gadget.
 

Personally I don't like the apps with a lot of windows as gnome-applet,
I prefer 1 window, with a list of interfaces and for each interface 1
frame. An advanced mode can be use for some options (run a command, the
wpa_supplicant drivers ...), something you don't change each days.

 regards
 Stefan Schmidt

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Shared Strings

[The Rasterman]

On Wed, 7 May 2008 20:55:40 -0500 Nathan Ingersoll [EMAIL PROTECTED]
babbled:

after. i've run the tests myself now.

i'll add some stats. e17 maintains about 3000-4000 unique strings in
evas_stringshare. in my tests. i also checked on number of adds, dels and
lookups in evas_stringshare usage. about 6.48% of calls are for adds of a
unique string. 5.12% are for deletes of a string. 88.41% are accesses (an add
or a del of an existing string where the operation does not free or allocate
any memory but just refcounts up or down).

now based on this, the existing stringshare vs. string_instance means, that if
you account for the relative usage of add, del and access paths,
string_instance gets overall faster once you have about 3200 or so strings. so
e17 is about at the cusp point. it's also one of the heavier users i imagine.

i simply changed hash bucket size to be 1024 items instead of 256 and that
makes the crossover point at about 7200 strings items - well beyond normal
usage of e17 anyway. adds and delets are still significantly faster (string
instance takes 1.8 and 1.4 times the time respectively compared to stringshare)
even at 10,000 strings. with the 1024 buckets for stringshare of course. but
string_instance takes 0.8 times the time for lookups.

overall it's a close race. i'll try improve stringshare a little and see what i
get, but beyond making it have dynamic bucket sizes (like ecore_hash) it isn't
likely to go far. a dynamic bucket size will mean it will scale very high
(question: do we need it to go that high?) but the idea of having to re-do the
bucket array at certain points is a little uncomfortable (so u go from 3000 to
3001 and the system has to spend extra cycles re-packing all hash items in a new
bucket set thats bigger). yes - this is nicer in terms of base mem usage of
course. so the thing here is to figure out how to get the best thing we can for
the least cost. i do know stringshare has a 1 alloc per unique string overhead.
thats about as small as it gets (also either 8 or 12 bytes (32 or 64bit) per
unique string for refcount and pointer).

now... more interestingly - i now started looking at the test. it is very
artificial. at most 2 copies of a string, so n repeated adds, and all short
strings. not very representative of common usage. in common usage i have
seen some strings with refcounts of  200. in fact the del wont work with
stringshare. on del u need to supply the actual string pointer - not the
snprintf'd buffer. so nothing gets found and deleted. ie its meant to work with:

char *s;

s = evas_stringshare_add(string);
...
evas_stringshare_del(s);

ie - the same return from stringshare.
evas_stringshare_del(string) will not work.

... so as such you need a test that is more representative of actual usage.

so that's just what i did. i literally logged all stringshare add's, dels etc.
in such a way it'd produce correct code from a session of e17 i fiddled with
for about 5 minutes doing stuff. you'll forgive me for not including the code
as the .c file generated is 11m (239,000 lines of c) that i included into the
compare.c infra to test both ecore and evas code and just time it doing exactly
what e does. i also included nops where functions are called, but do nothing
so we can remove the simple test harness and function call overhead and compare
just core. as it was a little too fast i make it run 1000 loops of what e
actually does one after the other (yes it'll be bad as it doesn't start with a
clean slate but better than nothing). result for 1000 iterations one after the
other:

evas: 20.691495
ecore: 30.510302
nops: 3.444793

real factor: 1.57

so really 20.69 - 3.44 vs 30.51 - 3.44 - i.e 17.25 vs 27.07 (evas being the
lower). yes - this means a lot of things will get high refcounts as things get
re-added a lot and then not removed, so the raw results of only 1 iteration:

evas: 0.031672
ecore: 0.045482
nops: 0.004831

real factor: 1.51

not as accurate as the times are so small, but the same order of magnitude as
above.

so as such... if we are doing benchmarks to know which implementation to use to
find the one with best results - at least for the case of e17, evas is the
winner here. of course if you think e17's use case is pretty atypical and you
need another one, we should continue to check.

comments. ?

 Were these numbers from ecore before or after cedric's changes this morning?
 
 On Wed, May 7, 2008 at 1:20 PM, Peter Wehrfritz [EMAIL PROTECTED]
 wrote:
  Yesterday we had a discussion on irc, if we should put abstract data
   types of ecore and of evas into a single standalone lib. The whole
   discussion came up because of the two implementations of the shared
   strings. And in fact if we really want to share strings efficient, we
   have to share them over the borders of the different libraries.
 
   Raster's idea was to first put the shared string stuff in this new
   library because both implementation have the same api (of course the
   names are different) 

[E-devel] Nightly build log for E17 on 2008-05-08 07:09:17 -0700

[Nightly build system]

Build log for Enlightenment DR 0.17 on 2008-05-08 07:09:17 -0700
Build logs are available at http://download.enlightenment.org/tests/logs

Packages that failed to build:
edje_viewer  http://download.enlightenment.org/tests/logs/edje_viewer.log
enna  http://download.enlightenment.org/tests/logs/enna.log
epdf  http://download.enlightenment.org/tests/logs/epdf.log
evolve  http://download.enlightenment.org/tests/logs/evolve.log

Packages with no supported build system:
entice, esmart_rsvg, exorcist, python-efl, 

Packages skipped:
camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, 
etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, 
ruby-efl, webcam, 

Packages that build OK:
alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, 
edb, e_dbus, edje_editor, edje, edvi, eet, eflame, eflpp, efm_nav, efm_path, 
efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, 
emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, 
enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, 
ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, 
etk-perl, evas, evfs, ewl, examine, execwatch, exhibit, exml, expedite, 
express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, 
imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, 
mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, 
rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, 
winselector, wlan, 

Debian GNU/Linux 4.0 \n \l

Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 
GNU/Linux


See http://download.enlightenment.org/tests/ for details.


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Shared Strings

[Hisham Mardam Bey]

On Wed, May 7, 2008 at 2:20 PM, Peter Wehrfritz [EMAIL PROTECTED] wrote:
 Yesterday we had a discussion on irc, if we should put abstract data
 types of ecore and of evas into a single standalone lib. The whole
 discussion came up because of the two implementations of the shared
 strings. And in fact if we really want to share strings efficient, we
 have to share them over the borders of the different libraries.

 Raster's idea was to first put the shared string stuff in this new
 library because both implementation have the same api (of course the
 names are different) and the same functionality. Remains the question
 which implementation we use.



And for something completely non-technical now. I went over this
discussion's backlog over irc and talked to Jorge (turran) as well.
Whatever ends up happening, I want to point you to Jorge's work on
this matter (a general shared data library that should be used by the
EFL as opposed to maintaining per library implementations). Currently,
there are two, one in the EFL's CVS repository, and one in the
EFL-Research SVN repository on Google code. I want to remind everyone
that this effort has already been started, and the idea has been
indeed put forth by Jorge, and if anyone wants to work on something
like this they should in fact continue, build upon, and help Jorge
with developing this common library. This library has been there
floating in CVS for (over?) a year now, so pick it up and keep the
ball rolling.

-- 
Hisham Mardam Bey
http://hisham.cc/

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Epsilon [PATCHES]

[Leo Sobral Cunha]

hi guys,

attached are some patches for epsilon, mostly small bugfixes.

any comments?

BR,
-- 
// leo

---
Leonardo Sobral Cunha
OpenBossa Labs
INdT - Instituto Nokia de Tecnologia
PGP: 0x5751676C @ wwwkeys.pgp.net
---
From d365c959ca9f5a13cc07893d59d43d4c1e5287ff Mon Sep 17 00:00:00 2001
From: Leonardo Sobral Cunha [EMAIL PROTECTED]
Date: Sat, 24 Nov 2007 02:29:51 -0300
Subject: [PATCH] Fixed w - h unnoticed miss-exchange

When calculating thumbnail geometry
---
 src/lib/Epsilon.c |   32 
 1 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/src/lib/Epsilon.c b/src/lib/Epsilon.c
index 315154b..2f44f14 100644
--- a/src/lib/Epsilon.c
+++ b/src/lib/Epsilon.c
@@ -577,13 +577,13 @@ epsilon_generate (Epsilon * e)
   epeg_size_get (im, iw, ih);
   if (iw  ih)
 	{
-	  th = e-th * ((double) ih / (double) iw);
-	   if (th  1) th = 1;
+	  th = ((unsigned long) e-tw * ih) / iw;
+	  if (th  1) th = 1;
 	}
   else
 	{
-	  tw = e-tw * ((double) iw / (double) ih);
-	   if (tw  1) tw = 1;
+	  tw = ((unsigned long) e-th *  iw) / ih;
+	  if (tw  1) tw = 1;
 	}
   epeg_decode_size_set (im, tw, th);
   epeg_quality_set (im, 100);
@@ -695,18 +695,18 @@ epsilon_generate (Epsilon * e)
 #ifdef HAVE_PNG_H
 if (tmp)
   {
-	iw = imlib_image_get_width ();
-	ih = imlib_image_get_height ();
-	if (iw  ih)
-	  {
-	th = e-th * ((double) ih / (double) iw);
-	   if (th  1) th = 1;
-	  }
-	else
-	  {
-	tw = e-tw * ((double) iw / (double) ih);
-	   if (tw  1) tw = 1;
-	  }
+iw = imlib_image_get_width ();
+ih = imlib_image_get_height ();
+if (iw  ih)
+  {
+th = ((unsigned long) e-tw * ih) / iw;
+if (th  1) th = 1;
+  }
+else
+  {
+tw = ((unsigned long) e-th *  iw) / ih;
+if (tw  1) tw = 1;
+  }
 	imlib_context_set_cliprect (0, 0, tw, th);
 	if ((src = imlib_create_cropped_scaled_image (0, 0, iw, ih, tw, th)))
 	  {
-- 
1.5.3.6

From b6e5b2a8099a0e9d497022ee8c50330b022a6962 Mon Sep 17 00:00:00 2001
From: Leonardo Sobral Cunha [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 16:50:52 -0300
Subject: [PATCH] Fix alignment patch

---
 src/lib/exiftags/canon.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/lib/exiftags/canon.c b/src/lib/exiftags/canon.c
index 675c223..d757696 100644
--- a/src/lib/exiftags/canon.c
+++ b/src/lib/exiftags/canon.c
@@ -52,7 +52,7 @@
 struct ccstm {
 	int32_t val;
 	struct descrip *table;
-	const char descr[];
+	const char *descr;
 };
 
 
-- 
1.5.3.6

From 264627decb0e1ce453ae7be752adf8c7f4a3ecef Mon Sep 17 00:00:00 2001
From: Leonardo Sobral Cunha [EMAIL PROTECTED]
Date: Fri, 7 Dec 2007 17:54:28 -0300
Subject: [PATCH] Added IF in epsilon_thumb.c's epsilon_cb_server_data to avoid segfault

---
 src/lib/epsilon_thumb.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/lib/epsilon_thumb.c b/src/lib/epsilon_thumb.c
index 780e260..a791635 100644
--- a/src/lib/epsilon_thumb.c
+++ b/src/lib/epsilon_thumb.c
@@ -218,6 +218,9 @@ epsilon_cb_server_data(void *data, int type, void *event)
 	if (e-server != epsilon_server)
 		return 1;
 
+	if (!(e  e-data))
+		return 1;
+
 	msg = e-data;
 	Epsilon_Request *thumb;
 
-- 
1.5.3.6

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Epsilon [PATCHES]

[Christopher Michael]

Leo Sobral Cunha wrote:
 hi guys,
 
 attached are some patches for epsilon, mostly small bugfixes.
 
 any comments?
 
 BR,
 
Just FYI, but in the future please add a short description somewhere in 
your email about what your patches address. It saves the developers some 
time.

Thanks
dh

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Epsilon [PATCHES]

[Christopher Michael]

Leo Sobral Cunha wrote:
 hi guys,
 
 attached are some patches for epsilon, mostly small bugfixes.
 
 any comments?
 
 BR,
 
Just FYI, but in the future please add a short description somewhere in 
your email about what your patches address. mostly small bugfixes is 
just a bit too generic :) What bugs? It saves the developers some time.

Thanks
dh

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Network Manager

[Christopher Michael]

Atton Jonathan wrote:
 On Wed, 7 May 2008 21:47:44 +0200
 Stefan Schmidt [EMAIL PROTECTED] wrote:
 
 Sounds good. Some first ideas:
 o Gadget for the shelf to show signal strength for wifi, gsm/3g
   and indicates what kind of connection is used atm.
 o Click on the gadget shows available wifi networks, and other
   network connections like ethernet (Only with connected cable?) and
   wireless broadband modems.
 Show all the interface with their state, a picture for example (not
 link, not activate  ...), as exalt does. I think it's better to have a
 complete status of the computer.  You can look the exalt page for some
 screen-shots:
 http://watchwolf.fr/wiki/doku.php?id=exaltDokuWiki=2bf5ee6465fc1ce8875bf7431e7a6c51
 
Yea, I would tend to agree with this approach. Showing all the 
interfaces along with their respective status would be a lot nicer for 
users.

 o Some kind of advanced settings UI. Handling stored connections,
   set IP address, stuff for complicated wifi setup, etc.. Not sure
   how connected this should be to the gadget.

 
 Personally I don't like the apps with a lot of windows as gnome-applet,
 I prefer 1 window, with a list of interfaces and for each interface 1
 frame. An advanced mode can be use for some options (run a command, the
 wpa_supplicant drivers ...), something you don't change each days.
 
Sure, a lot of windows tends to confuse a Joe Smith user...so yea, I 
would agree with this approach also.

dh

 regards
 Stefan Schmidt


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel