Re: [E-devel] E17 problems with systray
Dnia 2010-02-08, pon o godzinie 23:56 -0500, P Purkayastha pisze: > On Monday 08 February 2010 16:12:45 Krzysztof Borowczyk wrote: [...] > > It's the same with kadu - GaduGadu client. I didn't test other > > applications. > > > > This is true. I have seen it happen too with qt4/kde4 applications. It > seems more like a problem with qt4 instead of e since gtk applications > work just fine. Even though other window managers do it right? Ok... maybe Qt needs special care ;) > > 2. Second problem is with hiding the window by clicking on it's icon on > > task bar when you are on different virtual desktop than the > > applications window. > > > > When you open some application (tested on psi, kadu - based on Qt, > > Sonata - based on GTK+) on one virtual desktop, then switch to some > > other and try to hide it by clicking it's task bar icon and come back > > to that virtual desktop - the contents of the window (i.e. buttons, > > text) disappear, but the window stays. > > This seems to be a problem with whatever task bar management module you > are using. I can not reproduce this problem with itask-ng. I meant systray not taskbar, sorry for confusion... had to be tired yesterday. It's a module for the standard shelves. -- best regards Chris -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Font Problem (EFL-related)
On Wed, Feb 10, 2010 at 6:23 PM, Cedric BAIL wrote: > On Wed, Feb 10, 2010 at 8:53 AM, Brian Wang wrote: >> Hello all, >> >> I'm using Elementary with recent svn code. >> This font problem seems new, but I have no clue how it happens. >> >> I don't know if my observation is correct, but here it goes: >> 1. When the app first starts up, I see the string correctly displayed. >> 2. Then the app gets closed and started again, some character within >> the string (the same string as 1) becomes a 'rectangle'. >> * The problem is easily reproducible but not reproducible every time. >> * evas is built with fontconfig support. The fonts are truetype fonts. > > Did you restart your apps using elementary quicklaunch infra, or is it > an execution from scratch ? I'm not using the quicklaunch infra. Plain executables started by ecore_exe_run(). > >> If I have only one font, the problem doesn't show up. But since I >> don't have a reliable way of reproducing the problem, I can't >> guarantee it's true. >> If I have two fonts (one is a big font with CJK characters and the >> other is a Dejavu Mono font), then the problem will show up quite >> easily. >> >> Is it a configuration problem? I didn't notice such a problem before >> and I just svn up yesterday. > > When was your previous svn update ? Quite some time ago. I'm sorry I did not record the svn version. I am able to reproduce it quite reliably now. First launch is ok. Second launch will cause the first Chinese character to be a 'rectangle'. And I'm pretty sure if there is only one font, the problem does not exist. > -- > Cedric BAIL > -- brian -- Cool-Karaoke - The smallest recording studio, in your palm, open-sourced http://cool-idea.com.tw/ iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] patch for edje program filter on source state
On Mon, Feb 8, 2010 at 11:20 AM, tristan wrote: > Ok, I followed your recommandations. Here is a new patch, with filter state > using its own keyword. in svn, with few modification. -- Cedric BAIL -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e16-1.0.2
On Wed, 10 Feb 2010 05:58:50 +0100, Mike Frysinger wrote: > On Sunday 24 January 2010 17:16:55 Kim Woelders wrote: >> e16-1.0.2 is available for download: >> http://sourceforge.net/projects/enlightenment/files/ > > someone want to update: > http://www.enlightenment.org/p.php?p=download&l=en > -mike Yeah, I forgot that. Done now. Thanks. /Kim -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Lua leaking resources (timers, idlers, animators...)
Hi all,
I don't know Lua (yet), but if someone can look at
edje_lua.c/edje_file.c, the deletion of an Edje object does not delete
associated resources such as timers, idlers, animators.
I'll dig into this, but any help is appreciated.
See attached files for working example of the problem. Run and it will
crash as timer will tick but referring object is gone. Code is
courtesy of Rafael Fonseca, who spotted the problem.
BR,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
collections {
group {
name: "clock";
min: 200 50;
max: 200 50;
parts {
part {
name: "bg";
type: RECT;
description {
state: "default" 0.0;
rel1.relative: 0.0 0.0;
rel2.relative: 1.0 1.0;
color: 0 0 0 255;
}
}
part {
name: "clock";
type: TEXT;
description {
state: "default" 0.0;
rel1.relative: 0.0 0.0;
rel2.relative: 1.0 1.0;
text {
text: "";
font: "default";
size: 30;
align: 0.5 0.5;
}
}
}
}
programs {
program {
signal: "show";
source: "";
lua_script {
function cb (self)
local time = os.date("%H:%M:%S")
self.ed.clock.text = time
return CALLBACK_RENEW
end
tim = ed:timer(1, cb)
tim.ed = ed
local d = os.date("%H:%M:%S")
ed.clock.text = d
}
}
}
}
}
#include
#include
#include
int
main(int argc, char *argv[])
{
Ecore_Evas *ee;
Evas_Object *ed;
Evas_Coord w, h;
ecore_evas_init();
edje_init();
ee = ecore_evas_new(NULL, 0, 0, 320, 240, NULL);
ed = edje_object_add(ecore_evas_get(ee));
if (!edje_object_file_set(ed, "clock.edj", "clock")) {
fprintf(stderr, "Could not load edje file clock.edj, group clock: %s\n",
edje_load_error_str(edje_object_load_error_get(ed)));
return -1;
}
ecore_evas_object_associate(ee, ed, ECORE_EVAS_OBJECT_ASSOCIATE_DEL);
edje_object_size_min_get(ed, &w, &h);
evas_object_resize(ed, w, h);
evas_object_show(ed);
ecore_main_loop_begin();
edje_shutdown();
ecore_evas_shutdown();
return 0;
}
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Desire to move elmdentica to e's svn and trac
Em 07-02-2010 13:40, Carsten Haitzler (The Rasterman) escreveu: > On Tue, 02 Feb 2010 18:52:12 + Rui Miguel Silva Seabra > said: > >> Em 02-02-2010 17:16, Gustavo Sverzut Barbieri escreveu: >>> On Mon, Feb 1, 2010 at 5:15 PM, Rui Miguel Silva Seabra >>> wrote: Hello all, I'm the author of a identi.ca and twitter.com Free Software client application (should support natively the former sometime in the future instead of using it's twitter compatible api) made with EFL, most importantly Elementary. This application has been designed taking in account small touchscreens with a reasonable resolution (VGA) like the OpenMoko (where I use and test it before releases). Two reasons for this desire: 1. Google Code forbids access to some Free Software communities going beyond what is required by US law on software export restrictions 2. I'd love to have it there :) If accepted, please tell me what you need from me (ssh public key? OpenPGP key? etc...) >>> >>> Well, I know your work on OpenMoko and elmdentica and agree to have >>> you as developer. Just wait bit more until raster have some time to >>> breath and give his opinion. > > i'm thumbs up on this. no problems. begin the indoctrination proceedings! (get > public key, info.txt!) :P Great! Who should I send my public key to, and what info should be cat into info.txt? Rui -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Desire to move elmdentica to e's svn and trac
On 02/10/2010 04:19 PM, Rui Miguel Silva Seabra wrote: > Em 07-02-2010 13:40, Carsten Haitzler (The Rasterman) escreveu: >> On Tue, 02 Feb 2010 18:52:12 + Rui Miguel Silva Seabra >> said: >> >>> Em 02-02-2010 17:16, Gustavo Sverzut Barbieri escreveu: On Mon, Feb 1, 2010 at 5:15 PM, Rui Miguel Silva Seabra wrote: > Hello all, > > I'm the author of a identi.ca and twitter.com Free Software client > application (should support natively the former sometime in the future > instead of using it's twitter compatible api) made with EFL, most > importantly Elementary. > > This application has been designed taking in account small touchscreens > with a reasonable resolution (VGA) like the OpenMoko (where I use and > test it before releases). > > Two reasons for this desire: > 1. Google Code forbids access to some Free Software communities going > beyond what is required by US law on software export restrictions > 2. I'd love to have it there :) > > If accepted, please tell me what you need from me (ssh public key? > OpenPGP key? etc...) Well, I know your work on OpenMoko and elmdentica and agree to have you as developer. Just wait bit more until raster have some time to breath and give his opinion. >> >> i'm thumbs up on this. no problems. begin the indoctrination proceedings! >> (get >> public key, info.txt!) :P > > Great! > > Who should I send my public key to, and what info should be cat into > info.txt? > > Rui > Check other existing info.txt files in the e/trunk/devs folder for examples. You can send your info to anyone with commit access ... (tho make sure there are actually 'active' developers else it won't do you any good) :) dh -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] RFC - e doxygen
Hi All, I need to ease the process of creating documentation for the illume2 module API's. This includes documentation about writing policies and how to interact with the module, which API calls are available and how to use them, etc, etc. I wanted to do this via doxygen (as it just makes things simpler), but I noticed that E17 itself does not check for doxygen in it's configure.ac file. Would there be any objections to adding that check in configure.ac ?? I can see several cases where this could be very useful for others...writing modules (we could document the various calls that are available for modules), documenting the widgets, etc, etc... Thoughts ?? dh -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Lua leaking resources (timers, idlers, animators...)
On Wed, Feb 10, 2010 at 4:50 PM, Gustavo Sverzut Barbieri
wrote:
> Hi all,
>
> I don't know Lua (yet), but if someone can look at
> edje_lua.c/edje_file.c, the deletion of an Edje object does not delete
> associated resources such as timers, idlers, animators.
>
> I'll dig into this, but any help is appreciated.
>
> See attached files for working example of the problem. Run and it will
> crash as timer will tick but referring object is gone. Code is
> courtesy of Rafael Fonseca, who spotted the problem.
Ok, I spent lots of time trying to figure this out, without any luck
(maybe choosing to solve the problem without really knowing lua C api
was not a wise idea). My findings follows:
--> garbage collector runs, but the code to automatically call
"obj.del" is commented out. Uncommenting this does not work, and I
tried a lot of options to make this work, without luck:
static int
_edje_lua_class_mt_gc(lua_State *L)
{
_edje_lua_checkudata(L, 1, &mClass);
//printf("_edje_lua_class_mt_gc\n");
/* FIXME has to be commented to not raise an error, solve differently
lua_getfield(L, 1, "del");
if (!lua_isnil(L, -1))
{
lua_pushvalue(L, 1);
int err_code;
if (err_code = lua_pcall(L, 1, 0, 0))
_edje_lua_error(L, err_code);
}
lua_pop(L, 1);
*/
return 0;
}
So I opted to go back to my knowledge area and added a free() callback
to all Edje_Lua_*, if set this callback would be called, in
Edje_Lua_Timer, it would call ecore_timer_del().
It did not work, so I realized that the pointer returned by
_edje_lua_checkudata(L, 1, &mClass) is not returning the allocated
userdata created by:
static int
_edje_lua_group_fn_timer(lua_State *L)
{
Edje_Lua_Timer *tar = lua_newuserdata(L, sizeof(Edje_Lua_Timer));
_edje_lua_set_class(L, -1, cTimer);
tar->et = ecore_timer_add(luaL_checknumber(L, 2), _edje_lua_timer_cb, tar);
tar->L = L;
_edje_lua_new_reg(L, -1, tar); // freed in _edje_lua_timer_cb/del
tar->cb = _edje_lua_new_ref(L, 3); // freed in _edje_lua_timer_cb/del
return 1;
}
AFAIU, the "tar" pointer created here is the one to get as first
argument for garbage collector with lua_touserdata(). Probably solving
this issue will make the commented code work, with "del" being called
and releasing resources.
Last, I read some code from lua's own libraries and they make lots of
use of luaL (aux/helpers) that we don't. Any reason for this? Seems
that using things like luaL_newmetatable(), luaL_checkudata() is much
easier than reimplementing it all in Edje.
Any help is appreciated.
BR,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - e doxygen
On Wed, 10 Feb 2010 17:28:03 -0500 Christopher Michael said: > Hi All, > > I need to ease the process of creating documentation for the illume2 > module API's. This includes documentation about writing policies and how > to interact with the module, which API calls are available and how to > use them, etc, etc. > > I wanted to do this via doxygen (as it just makes things simpler), but I > noticed that E17 itself does not check for doxygen in it's configure.ac > file. > > Would there be any objections to adding that check in configure.ac ?? > > I can see several cases where this could be very useful for > others...writing modules (we could document the various calls that are > available for modules), documenting the widgets, etc, etc... > > Thoughts ?? no objections. make it so! -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Massive Valgrind Memory Check Warnings
Hello all, I'm using Elementary with recent svn. I got lots of valgrind memory check warning at program exit such as: ==6296== 5 bytes in 1 blocks are possibly lost in loss record 10 of 1,788 ==6296==at 0x4024C1C: malloc (vg_replace_malloc.c:195) ==6296==by 0x429FC8F: strdup (strdup.c:43) ==6296==by 0x406A19E: evas_key_modifier_add (evas_key.c:172) ==6296==by 0x47355EC: ecore_event_window_register (ecore_input_evas.c:88) ==6296==by 0x4180B73: ecore_evas_software_x11_new (ecore_evas_x.c:2603) ==6296==by 0x41CA91A: elm_win_add (elm_win.c:361) ==6296==by 0x80500B3: win_standard_populate (app.c:2036) ==6296==by 0x8050570: win_mode_player_populate_delay (app.c:2148) ==6296==by 0x8050646: win_mode_switch (app.c:2193) ==6296==by 0x805074E: startup_win_init (app.c:2241) ==6296==by 0x80508AC: elm_main (app.c:2283) ==6296==by 0x80508EA: main (app.c:2292) ==6296== 8 bytes in 1 blocks are possibly lost in loss record 59 of 1,788 ==6296==at 0x4023F5B: calloc (vg_replace_malloc.c:418) ==6296==by 0x4084B38: evas_object_rectangle_new (evas_object_rectangle.c:134) ==6296==by 0x4084A13: evas_object_rectangle_init (evas_object_rectangle.c:109) ==6296==by 0x40849E1: evas_object_rectangle_add (evas_object_rectangle.c:95) ==6296==by 0x41EB134: elm_pager_add (elm_pager.c:222) ==6296==by 0x804E4E1: control_pager_add (app.c:1264) ==6296==by 0x80505A8: win_mode_player_populate_delay (app.c:2156) ==6296==by 0x8050646: win_mode_switch (app.c:2193) ==6296==by 0x805074E: startup_win_init (app.c:2241) ==6296==by 0x80508AC: elm_main (app.c:2283) ==6296==by 0x80508EA: main (app.c:2292) ==6296== ==6296== 8 bytes in 1 blocks are possibly lost in loss record 60 of 1,788 ==6296==at 0x4023F5B: calloc (vg_replace_malloc.c:418) ==6296==by 0x4084B38: evas_object_rectangle_new (evas_object_rectangle.c:134) ==6296==by 0x4084A13: evas_object_rectangle_init (evas_object_rectangle.c:109) ==6296==by 0x40849E1: evas_object_rectangle_add (evas_object_rectangle.c:95) ==6296==by 0x41EB171: elm_pager_add (elm_pager.c:226) ==6296==by 0x804E4E1: control_pager_add (app.c:1264) ==6296==by 0x80505A8: win_mode_player_populate_delay (app.c:2156) ==6296==by 0x8050646: win_mode_switch (app.c:2193) ==6296==by 0x805074E: startup_win_init (app.c:2241) ==6296==by 0x80508AC: elm_main (app.c:2283) ==6296==by 0x80508EA: main (app.c:2292) ==6296== ==6296== 8 bytes in 1 blocks are possibly lost in loss record 61 of 1,788 ==6296==at 0x4023F5B: calloc (vg_replace_malloc.c:418) ==6296==by 0x4084B38: evas_object_rectangle_new (evas_object_rectangle.c:134) ==6296==by 0x4084A13: evas_object_rectangle_init (evas_object_rectangle.c:109) ==6296==by 0x40849E1: evas_object_rectangle_add (evas_object_rectangle.c:95) ==6296==by 0x43E532E: _edje_add (edje_main.c:211) ==6296==by 0x43E86F8: _edje_smart_add (edje_smart.c:65) ==6296==by 0x4085D83: evas_object_smart_add (evas_object_smart.c:346) ==6296==by 0x43E86D4: edje_object_add (edje_smart.c:56) ==6296==by 0x41D1A75: elm_button_add (elm_button.c:222) ==6296==by 0x804C6B6: button_add (app.c:442) ==6296==by 0x804E2FD: elapsed_bar_add (app.c:1228) ==6296==by 0x804E535: control_pager_add (app.c:1270) There are lots of more. The summary is quite scary: ==6671== LEAK SUMMARY: ==6671==definitely lost: 1,016 bytes in 12 blocks ==6671==indirectly lost: 4,340 bytes in 217 blocks ==6671== possibly lost: 2,915,620 bytes in 5,119 blocks ==6671==still reachable: 584,490 bytes in 6,969 blocks ==6671== suppressed: 0 bytes in 0 blocks I'm not sure how possible "possibly lost" means. Is it safe to ignore? I believe those warnings were not there. But my memory might be at fault. Thanks in advance. brian -- brian -- Cool-Karaoke - The smallest recording studio, in your palm, open-sourced http://cool-idea.com.tw/ iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Massive Valgrind Memory Check Warnings
On Thu, 11 Feb 2010 11:35:26 +0800 Brian Wang wrote: > Hello all, > > I'm using Elementary with recent svn. I got lots of valgrind memory > check warning at program exit such as: > > ==6296== 5 bytes in 1 blocks are possibly lost in loss record 10 of > 1,788 ==6296==at 0x4024C1C: malloc (vg_replace_malloc.c:195) > ==6296==by 0x429FC8F: strdup (strdup.c:43) > ==6296==by 0x406A19E: evas_key_modifier_add (evas_key.c:172) > ==6296==by 0x47355EC: ecore_event_window_register > (ecore_input_evas.c:88) ==6296==by 0x4180B73: > ecore_evas_software_x11_new (ecore_evas_x.c:2603) ==6296==by > 0x41CA91A: elm_win_add (elm_win.c:361) ==6296==by 0x80500B3: > win_standard_populate (app.c:2036) ==6296==by 0x8050570: > win_mode_player_populate_delay (app.c:2148) ==6296==by 0x8050646: > win_mode_switch (app.c:2193) ==6296==by 0x805074E: > startup_win_init (app.c:2241) ==6296==by 0x80508AC: elm_main > (app.c:2283) ==6296==by 0x80508EA: main (app.c:2292) > > > ==6296== 8 bytes in 1 blocks are possibly lost in loss record 59 of > 1,788 ==6296==at 0x4023F5B: calloc (vg_replace_malloc.c:418) > ==6296==by 0x4084B38: evas_object_rectangle_new > (evas_object_rectangle.c:134) > ==6296==by 0x4084A13: evas_object_rectangle_init > (evas_object_rectangle.c:109) > ==6296==by 0x40849E1: evas_object_rectangle_add > (evas_object_rectangle.c:95) ==6296==by 0x41EB134: elm_pager_add > (elm_pager.c:222) ==6296==by 0x804E4E1: control_pager_add > (app.c:1264) ==6296==by 0x80505A8: win_mode_player_populate_delay > (app.c:2156) ==6296==by 0x8050646: win_mode_switch (app.c:2193) > ==6296==by 0x805074E: startup_win_init (app.c:2241) > ==6296==by 0x80508AC: elm_main (app.c:2283) > ==6296==by 0x80508EA: main (app.c:2292) > ==6296== > ==6296== 8 bytes in 1 blocks are possibly lost in loss record 60 of > 1,788 ==6296==at 0x4023F5B: calloc (vg_replace_malloc.c:418) > ==6296==by 0x4084B38: evas_object_rectangle_new > (evas_object_rectangle.c:134) > ==6296==by 0x4084A13: evas_object_rectangle_init > (evas_object_rectangle.c:109) > ==6296==by 0x40849E1: evas_object_rectangle_add > (evas_object_rectangle.c:95) ==6296==by 0x41EB171: elm_pager_add > (elm_pager.c:226) ==6296==by 0x804E4E1: control_pager_add > (app.c:1264) ==6296==by 0x80505A8: win_mode_player_populate_delay > (app.c:2156) ==6296==by 0x8050646: win_mode_switch (app.c:2193) > ==6296==by 0x805074E: startup_win_init (app.c:2241) > ==6296==by 0x80508AC: elm_main (app.c:2283) > ==6296==by 0x80508EA: main (app.c:2292) > ==6296== > ==6296== 8 bytes in 1 blocks are possibly lost in loss record 61 of > 1,788 ==6296==at 0x4023F5B: calloc (vg_replace_malloc.c:418) > ==6296==by 0x4084B38: evas_object_rectangle_new > (evas_object_rectangle.c:134) > ==6296==by 0x4084A13: evas_object_rectangle_init > (evas_object_rectangle.c:109) > ==6296==by 0x40849E1: evas_object_rectangle_add > (evas_object_rectangle.c:95) ==6296==by 0x43E532E: _edje_add > (edje_main.c:211) ==6296==by 0x43E86F8: _edje_smart_add > (edje_smart.c:65) ==6296==by 0x4085D83: evas_object_smart_add > (evas_object_smart.c:346) ==6296==by 0x43E86D4: edje_object_add > (edje_smart.c:56) ==6296==by 0x41D1A75: elm_button_add > (elm_button.c:222) ==6296==by 0x804C6B6: button_add (app.c:442) > ==6296==by 0x804E2FD: elapsed_bar_add (app.c:1228) > ==6296==by 0x804E535: control_pager_add (app.c:1270) > > There are lots of more. The summary is quite scary: > ==6671== LEAK SUMMARY: > ==6671==definitely lost: 1,016 bytes in 12 blocks > ==6671==indirectly lost: 4,340 bytes in 217 blocks > ==6671== possibly lost: 2,915,620 bytes in 5,119 blocks > ==6671==still reachable: 584,490 bytes in 6,969 blocks > ==6671== suppressed: 0 bytes in 0 blocks > > I'm not sure how possible "possibly lost" means. Is it safe to > ignore? I believe those warnings were not there. But my memory might > be at fault. Possibly lost means it wasn't freed at exit generally. Ignore them. The OS is a hell of a lot better (and faster) at cleaning such things up[1]. Regards, nash [1] Deleting an entire address space is great cleanup method[2] ;-) [2] And doesn't need you to thrash your TLB and swap following free memory lists too. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - e doxygen
On Wed, 10 Feb 2010, Christopher Michael wrote: > I need to ease the process of creating documentation for the illume2 > module API's. This includes documentation about writing policies and how > to interact with the module, which API calls are available and how to > use them, etc, etc. > > I wanted to do this via doxygen (as it just makes things simpler), but I > noticed that E17 itself does not check for doxygen in it's configure.ac > file. > > Would there be any objections to adding that check in configure.ac ?? > > I can see several cases where this could be very useful for > others...writing modules (we could document the various calls that are > available for modules), documenting the widgets, etc, etc... > > Thoughts ?? no problem for me. Just follow these steps: http://trac.enlightenment.org/e/wiki/AutotoolsIntegration#Documentation Vincent -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Massive Valgrind Memory Check Warnings
On Thu, 11 Feb 2010 14:29:53 +0800 Brett Nash said: > On Thu, 11 Feb 2010 11:35:26 +0800 > Brian Wang wrote: > > > Hello all, > > > > I'm using Elementary with recent svn. I got lots of valgrind memory > > check warning at program exit such as: > > > > ==6296== 5 bytes in 1 blocks are possibly lost in loss record 10 of > > 1,788 ==6296==at 0x4024C1C: malloc (vg_replace_malloc.c:195) > > ==6296==by 0x429FC8F: strdup (strdup.c:43) > > ==6296==by 0x406A19E: evas_key_modifier_add (evas_key.c:172) > > ==6296==by 0x47355EC: ecore_event_window_register > > (ecore_input_evas.c:88) ==6296==by 0x4180B73: > > ecore_evas_software_x11_new (ecore_evas_x.c:2603) ==6296==by > > 0x41CA91A: elm_win_add (elm_win.c:361) ==6296==by 0x80500B3: > > win_standard_populate (app.c:2036) ==6296==by 0x8050570: > > win_mode_player_populate_delay (app.c:2148) ==6296==by 0x8050646: > > win_mode_switch (app.c:2193) ==6296==by 0x805074E: > > startup_win_init (app.c:2241) ==6296==by 0x80508AC: elm_main > > (app.c:2283) ==6296==by 0x80508EA: main (app.c:2292) > > > > > > ==6296== 8 bytes in 1 blocks are possibly lost in loss record 59 of > > 1,788 ==6296==at 0x4023F5B: calloc (vg_replace_malloc.c:418) > > ==6296==by 0x4084B38: evas_object_rectangle_new > > (evas_object_rectangle.c:134) > > ==6296==by 0x4084A13: evas_object_rectangle_init > > (evas_object_rectangle.c:109) > > ==6296==by 0x40849E1: evas_object_rectangle_add > > (evas_object_rectangle.c:95) ==6296==by 0x41EB134: elm_pager_add > > (elm_pager.c:222) ==6296==by 0x804E4E1: control_pager_add > > (app.c:1264) ==6296==by 0x80505A8: win_mode_player_populate_delay > > (app.c:2156) ==6296==by 0x8050646: win_mode_switch (app.c:2193) > > ==6296==by 0x805074E: startup_win_init (app.c:2241) > > ==6296==by 0x80508AC: elm_main (app.c:2283) > > ==6296==by 0x80508EA: main (app.c:2292) > > ==6296== > > ==6296== 8 bytes in 1 blocks are possibly lost in loss record 60 of > > 1,788 ==6296==at 0x4023F5B: calloc (vg_replace_malloc.c:418) > > ==6296==by 0x4084B38: evas_object_rectangle_new > > (evas_object_rectangle.c:134) > > ==6296==by 0x4084A13: evas_object_rectangle_init > > (evas_object_rectangle.c:109) > > ==6296==by 0x40849E1: evas_object_rectangle_add > > (evas_object_rectangle.c:95) ==6296==by 0x41EB171: elm_pager_add > > (elm_pager.c:226) ==6296==by 0x804E4E1: control_pager_add > > (app.c:1264) ==6296==by 0x80505A8: win_mode_player_populate_delay > > (app.c:2156) ==6296==by 0x8050646: win_mode_switch (app.c:2193) > > ==6296==by 0x805074E: startup_win_init (app.c:2241) > > ==6296==by 0x80508AC: elm_main (app.c:2283) > > ==6296==by 0x80508EA: main (app.c:2292) > > ==6296== > > ==6296== 8 bytes in 1 blocks are possibly lost in loss record 61 of > > 1,788 ==6296==at 0x4023F5B: calloc (vg_replace_malloc.c:418) > > ==6296==by 0x4084B38: evas_object_rectangle_new > > (evas_object_rectangle.c:134) > > ==6296==by 0x4084A13: evas_object_rectangle_init > > (evas_object_rectangle.c:109) > > ==6296==by 0x40849E1: evas_object_rectangle_add > > (evas_object_rectangle.c:95) ==6296==by 0x43E532E: _edje_add > > (edje_main.c:211) ==6296==by 0x43E86F8: _edje_smart_add > > (edje_smart.c:65) ==6296==by 0x4085D83: evas_object_smart_add > > (evas_object_smart.c:346) ==6296==by 0x43E86D4: edje_object_add > > (edje_smart.c:56) ==6296==by 0x41D1A75: elm_button_add > > (elm_button.c:222) ==6296==by 0x804C6B6: button_add (app.c:442) > > ==6296==by 0x804E2FD: elapsed_bar_add (app.c:1228) > > ==6296==by 0x804E535: control_pager_add (app.c:1270) > > > > There are lots of more. The summary is quite scary: > > ==6671== LEAK SUMMARY: > > ==6671==definitely lost: 1,016 bytes in 12 blocks > > ==6671==indirectly lost: 4,340 bytes in 217 blocks > > ==6671== possibly lost: 2,915,620 bytes in 5,119 blocks > > ==6671==still reachable: 584,490 bytes in 6,969 blocks > > ==6671== suppressed: 0 bytes in 0 blocks > > > > I'm not sure how possible "possibly lost" means. Is it safe to > > ignore? I believe those warnings were not there. But my memory might > > be at fault. > > Possibly lost means it wasn't freed at exit generally. > > Ignore them. The OS is a hell of a lot better (and faster) at cleaning > such things up[1]. > > Regards, > nash > > [1] Deleting an entire address space is great cleanup method[2] ;-) > [2] And doesn't need you to thrash your TLB and swap following free > memory lists too. you said it for me. the onyl things to really worry about are the definitely losts. indirectly lost - cant remember. need to check. as such the definitely losts in efl are quite small and limited to 1-offs. if they were recurring - they'd be fixed. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com
Re: [E-devel] Massive Valgrind Memory Check Warnings
On Thu, Feb 11, 2010 at 3:10 PM, Carsten Haitzler wrote: > On Thu, 11 Feb 2010 14:29:53 +0800 Brett Nash said: > >> On Thu, 11 Feb 2010 11:35:26 +0800 >> Brian Wang wrote: >> >> > Hello all, >> > >> > I'm using Elementary with recent svn. I got lots of valgrind memory >> > check warning at program exit such as: >> > >> > ==6296== 5 bytes in 1 blocks are possibly lost in loss record 10 of >> > 1,788 ==6296== at 0x4024C1C: malloc (vg_replace_malloc.c:195) >> > ==6296== by 0x429FC8F: strdup (strdup.c:43) >> > ==6296== by 0x406A19E: evas_key_modifier_add (evas_key.c:172) >> > ==6296== by 0x47355EC: ecore_event_window_register >> > (ecore_input_evas.c:88) ==6296== by 0x4180B73: >> > ecore_evas_software_x11_new (ecore_evas_x.c:2603) ==6296== by >> > 0x41CA91A: elm_win_add (elm_win.c:361) ==6296== by 0x80500B3: >> > win_standard_populate (app.c:2036) ==6296== by 0x8050570: >> > win_mode_player_populate_delay (app.c:2148) ==6296== by 0x8050646: >> > win_mode_switch (app.c:2193) ==6296== by 0x805074E: >> > startup_win_init (app.c:2241) ==6296== by 0x80508AC: elm_main >> > (app.c:2283) ==6296== by 0x80508EA: main (app.c:2292) >> > >> > >> > ==6296== 8 bytes in 1 blocks are possibly lost in loss record 59 of >> > 1,788 ==6296== at 0x4023F5B: calloc (vg_replace_malloc.c:418) >> > ==6296== by 0x4084B38: evas_object_rectangle_new >> > (evas_object_rectangle.c:134) >> > ==6296== by 0x4084A13: evas_object_rectangle_init >> > (evas_object_rectangle.c:109) >> > ==6296== by 0x40849E1: evas_object_rectangle_add >> > (evas_object_rectangle.c:95) ==6296== by 0x41EB134: elm_pager_add >> > (elm_pager.c:222) ==6296== by 0x804E4E1: control_pager_add >> > (app.c:1264) ==6296== by 0x80505A8: win_mode_player_populate_delay >> > (app.c:2156) ==6296== by 0x8050646: win_mode_switch (app.c:2193) >> > ==6296== by 0x805074E: startup_win_init (app.c:2241) >> > ==6296== by 0x80508AC: elm_main (app.c:2283) >> > ==6296== by 0x80508EA: main (app.c:2292) >> > ==6296== >> > ==6296== 8 bytes in 1 blocks are possibly lost in loss record 60 of >> > 1,788 ==6296== at 0x4023F5B: calloc (vg_replace_malloc.c:418) >> > ==6296== by 0x4084B38: evas_object_rectangle_new >> > (evas_object_rectangle.c:134) >> > ==6296== by 0x4084A13: evas_object_rectangle_init >> > (evas_object_rectangle.c:109) >> > ==6296== by 0x40849E1: evas_object_rectangle_add >> > (evas_object_rectangle.c:95) ==6296== by 0x41EB171: elm_pager_add >> > (elm_pager.c:226) ==6296== by 0x804E4E1: control_pager_add >> > (app.c:1264) ==6296== by 0x80505A8: win_mode_player_populate_delay >> > (app.c:2156) ==6296== by 0x8050646: win_mode_switch (app.c:2193) >> > ==6296== by 0x805074E: startup_win_init (app.c:2241) >> > ==6296== by 0x80508AC: elm_main (app.c:2283) >> > ==6296== by 0x80508EA: main (app.c:2292) >> > ==6296== >> > ==6296== 8 bytes in 1 blocks are possibly lost in loss record 61 of >> > 1,788 ==6296== at 0x4023F5B: calloc (vg_replace_malloc.c:418) >> > ==6296== by 0x4084B38: evas_object_rectangle_new >> > (evas_object_rectangle.c:134) >> > ==6296== by 0x4084A13: evas_object_rectangle_init >> > (evas_object_rectangle.c:109) >> > ==6296== by 0x40849E1: evas_object_rectangle_add >> > (evas_object_rectangle.c:95) ==6296== by 0x43E532E: _edje_add >> > (edje_main.c:211) ==6296== by 0x43E86F8: _edje_smart_add >> > (edje_smart.c:65) ==6296== by 0x4085D83: evas_object_smart_add >> > (evas_object_smart.c:346) ==6296== by 0x43E86D4: edje_object_add >> > (edje_smart.c:56) ==6296== by 0x41D1A75: elm_button_add >> > (elm_button.c:222) ==6296== by 0x804C6B6: button_add (app.c:442) >> > ==6296== by 0x804E2FD: elapsed_bar_add (app.c:1228) >> > ==6296== by 0x804E535: control_pager_add (app.c:1270) >> > >> > There are lots of more. The summary is quite scary: >> > ==6671== LEAK SUMMARY: >> > ==6671== definitely lost: 1,016 bytes in 12 blocks >> > ==6671== indirectly lost: 4,340 bytes in 217 blocks >> > ==6671== possibly lost: 2,915,620 bytes in 5,119 blocks >> > ==6671== still reachable: 584,490 bytes in 6,969 blocks >> > ==6671== suppressed: 0 bytes in 0 blocks >> > >> > I'm not sure how possible "possibly lost" means. Is it safe to >> > ignore? I believe those warnings were not there. But my memory might >> > be at fault. >> >> Possibly lost means it wasn't freed at exit generally. >> >> Ignore them. The OS is a hell of a lot better (and faster) at cleaning >> such things up[1]. >> >> Regards, >> nash >> >> [1] Deleting an entire address space is great cleanup method[2] ;-) >> [2] And doesn't need you to thrash your TLB and swap following free >> memory lists too. > > you said it for me. the onyl things to really worry about are the definitely > losts. indirectly lost - cant remember. need to check. as such the definitely > losts in efl are quite small and limited to 1-offs. if they were recurring - > they'd be fixed. OK.
