Re: [E-devel] [EGIT] [core/efl] master 01/01: Eo: Change eo_add/del/unref behaviour.
On 28/09/14 05:51, Daniel Zaoui wrote:
> On 09/25/14 19:49, Tom Hacohen wrote:
>> I know it sounds intrusive, but it's actually more intrusive than it
>> sounds. :P
>>
>> Please keep an eye out for widgets leaking references, or errors in the
>> terminal. Things seem to be sane here, but one can never know.
>>
>> If you see a break, please don't blindly revert these changes, and
>> instead help me find and fix it.
>>
>> Thanks.
>>
>> --
>> Tom.
>>
>> On 25/09/14 17:39, Tom Hacohen wrote:
>>> tasn pushed a commit to branch master.
>>>
>>> http://git.enlightenment.org/core/efl.git/commit/?id=a7560dbc61953c3652780f232e38adbd2d711972
>>>
>>> commit a7560dbc61953c3652780f232e38adbd2d711972
>>> Author: Tom Hacohen
>>> Date: Thu Sep 25 15:51:17 2014 +0100
>>>
>>> Eo: Change eo_add/del/unref behaviour.
>>>
>>> Before this change eo_add() used to create an object with 1 ref, and
>>> if
>>> the object had a parent, a second ref.
>>> Now, eo_add() always returns an object with 1 ref, and eo_add_ref()
>>> preserves the old behaviour (for bindings).
>>>
>>> eo_unref now un-parents if refcount is 0, and eo_del() is an alias for
>>> eo_unref (will change to be a way to ensure an object is dead and goes
>>> to zombie-land even if still refed).
>>> ---
>>>src/lib/ecore/ecore_anim.c | 2 --
>>>src/lib/ecore/ecore_idle_enterer.c | 2 --
>>>src/lib/ecore/ecore_idle_exiter.c | 1 -
>>>src/lib/ecore/ecore_idler.c| 1 -
>>>src/lib/ecore/ecore_job.c | 1 -
>>>src/lib/ecore/ecore_poller.c | 1 -
>>>src/lib/ecore/ecore_timer.c| 2 --
>>>src/lib/edje/edje_edit.c | 1 -
>>>src/lib/edje/edje_smart.c | 1 -
>>>src/lib/emotion/emotion_smart.c| 1 -
>>>src/lib/eo/Eo.h| 26
>>> ++
>>>src/lib/eo/eo.c| 17 +-
>>>src/lib/eo/eo_private.h| 11 +
>>>src/lib/evas/canvas/evas_3d_camera.c | 1 -
>>>src/lib/evas/canvas/evas_3d_light.c| 1 -
>>>src/lib/evas/canvas/evas_3d_material.c | 1 -
>>>src/lib/evas/canvas/evas_3d_mesh.c | 1 -
>>>src/lib/evas/canvas/evas_3d_node.c | 1 -
>>>src/lib/evas/canvas/evas_3d_scene.c| 1 -
>>>src/lib/evas/canvas/evas_3d_texture.c | 1 -
>>>src/lib/evas/canvas/evas_object_box.c | 1 -
>>>src/lib/evas/canvas/evas_object_grid.c | 1 -
>>>src/lib/evas/canvas/evas_object_image.c| 1 -
>>>src/lib/evas/canvas/evas_object_line.c | 1 -
>>>src/lib/evas/canvas/evas_object_main.c | 3 +--
>>>src/lib/evas/canvas/evas_object_polygon.c | 1 -
>>>src/lib/evas/canvas/evas_object_rectangle.c| 1 -
>>>src/lib/evas/canvas/evas_object_smart.c| 1 -
>>>src/lib/evas/canvas/evas_object_table.c| 1 -
>>>src/lib/evas/canvas/evas_object_text.c | 1 -
>>>src/lib/evas/canvas/evas_object_textblock.c| 1 -
>>>src/lib/evas/canvas/evas_object_textgrid.c | 1 -
>>>src/lib/evas/canvas/evas_out.c | 1 -
>>>src/tests/eo/children/children_simple.c| 2 +-
>>>.../eo/composite_objects/composite_objects_comp.c | 2 --
>>>src/tests/eo/suite/eo_test_general.c | 12 +-
>>>36 files changed, 61 insertions(+), 44 deletions(-)
>>>
>>> diff --git a/src/lib/ecore/ecore_anim.c b/src/lib/ecore/ecore_anim.c
>>> index 7116538..6dee5ad 100644
>>> --- a/src/lib/ecore/ecore_anim.c
>>> +++ b/src/lib/ecore/ecore_anim.c
>>> @@ -204,7 +204,6 @@ ecore_animator_add(Ecore_Task_Cb func,
>>>
>>> animator = eo_add(MY_CLASS, _ecore_parent,
>>>ecore_animator_constructor(func, data));
>>> - eo_unref(animator);
>>> return animator;
>>>}
>>>
>>> @@ -224,7 +223,6 @@ ecore_animator_timeline_add(doubleruntime,
>>> Ecore_Animator *animator;
>>> animator = eo_add(MY_CLASS, _ecore_parent,
>>>ecore_animator_timeline_constructor(runtime,
>>> func, data));
>>> - eo_unref(animator);
>>> return animator;
>>>}
>>>
>>> diff --git a/src/lib/ecore/ecore_idle_enterer.c
>>> b/src/lib/ecore/ecore_idle_enterer.c
>>> index f6d5b99..038b5c9 100644
>>> --- a/src/lib/ecore/ecore_idle_enterer.c
>>> +++ b/src/lib/ecore/ecore_idle_enterer.c
>>> @@ -64,7 +64,6 @@ ecore_idle_enterer_add(Ecore_Task_Cb func,
>>>{
>>> Ecore_Idle_Enterer *ie = NULL;
>>> ie = eo_add(MY_CLASS, _ecore_parent,
>>> ecore_idle_enterer_after_constructor(func, data)
[EGIT] [core/efl] master 01/03: efreet: tab to spaces
englebass pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=f60fdced444bd2a7b1c75618500cb4f2643f3935
commit f60fdced444bd2a7b1c75618500cb4f2643f3935
Author: Sebastian Dransfeld
Date: Mon Sep 29 09:31:38 2014 +0200
efreet: tab to spaces
---
src/lib/efreet/efreet_icon.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/lib/efreet/efreet_icon.c b/src/lib/efreet/efreet_icon.c
index b121ae6..70e7fca 100644
--- a/src/lib/efreet/efreet_icon.c
+++ b/src/lib/efreet/efreet_icon.c
@@ -701,10 +701,10 @@ efreet_icon_lookup_path_path(Efreet_Cache_Icon_Element
*elem, const char *path)
EINA_LIST_FOREACH(efreet_icon_extensions, ll, ext)
if (!strcmp(pp, ext))
- {
- r = elem->paths[i];
- break;
- }
+{
+r = elem->paths[i];
+break;
+}
}
free((void*) path);
@@ -794,10 +794,10 @@
efreet_icon_fallback_lookup_path_path(Efreet_Cache_Fallback_Icon *icon, const ch
EINA_LIST_FOREACH(efreet_icon_extensions, ll, ext)
if (!strcmp(pp, ext))
- {
- r = icon->icons[i];
- break;
- }
+{
+r = icon->icons[i];
+break;
+}
}
free((void*) path);
--
[EGIT] [core/efl] master 03/03: efreet: improve messages
englebass pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=b624345bbd577cfee7746abef0cb0595dbd9b72b
commit b624345bbd577cfee7746abef0cb0595dbd9b72b
Author: Sebastian Dransfeld
Date: Mon Sep 29 09:39:17 2014 +0200
efreet: improve messages
---
src/lib/efreet/efreet_cache.c | 14 +--
src/lib/efreet/efreet_desktop.c | 7 +++---
src/lib/efreet/efreet_desktop_command.c | 4 ++--
src/lib/efreet/efreet_icon.c| 6 ++---
src/lib/efreet/efreet_ini.c | 4 ++--
src/lib/efreet/efreet_menu.c| 42 -
src/lib/efreet/efreet_trash.c | 8 +++
src/lib/efreet/efreet_xml.c | 2 +-
8 files changed, 48 insertions(+), 39 deletions(-)
diff --git a/src/lib/efreet/efreet_cache.c b/src/lib/efreet/efreet_cache.c
index 23c9e44..2742545 100644
--- a/src/lib/efreet/efreet_cache.c
+++ b/src/lib/efreet/efreet_cache.c
@@ -665,7 +665,7 @@ efreet_cache_icon_find(Efreet_Icon_Theme *theme, const char
*icon)
if (theme_name && strcmp(theme_name, theme->name.internal))
{
/* FIXME: this is bad if people have pointer to this cache, things
will go wrong */
-INF("theme_name change from `%s` to `%s`", theme_name,
theme->name.internal);
+INF("theme_name change from '%s' to '%s'", theme_name,
theme->name.internal);
IF_RELEASE(theme_name);
icon_cache = efreet_cache_close(icon_cache);
eina_hash_free(icons);
@@ -824,13 +824,13 @@ efreet_cache_desktop_find(const char *file)
/* If less than one second since last stat, return desktop */
if ((ecore_time_get() - cache->check_time) < 1)
{
-INF("Return without stat %f %f", ecore_time_get(),
cache->check_time);
+INF("Return without stat %f %f for file '%s'", ecore_time_get(),
cache->check_time, file);
eina_lock_release(&_lock);
return &cache->desktop;
}
if (cache->desktop.load_time ==
ecore_file_mod_time(cache->desktop.orig_path))
{
-INF("Return with stat %f %f", ecore_time_get(), cache->check_time);
+INF("Return with stat %f %f for file '%s'", ecore_time_get(),
cache->check_time, file);
cache->check_time = ecore_time_get();
eina_lock_release(&_lock);
return &cache->desktop;
@@ -848,7 +848,7 @@ efreet_cache_desktop_find(const char *file)
if (cache->desktop.load_time !=
ecore_file_mod_time(cache->desktop.orig_path))
{
/* Don't return stale data */
-INF("We got stale data in the desktop cache");
+INF("We got stale data in the desktop cache for file '%s'",
cache->desktop.orig_path);
efreet_cache_desktop_free(&cache->desktop);
eina_hash_set(desktops, file, NON_EXISTING);
}
@@ -883,7 +883,7 @@ efreet_cache_desktop_free(Efreet_Desktop *desktop)
curr = eina_hash_find(desktops, desktop->orig_path);
if (curr == desktop)
{
-INF("Found in current cache, purge\n");
+INF("Found '%s' in current cache, purge", desktop->orig_path);
eina_hash_del_by_key(desktops, desktop->orig_path);
}
@@ -892,11 +892,11 @@ efreet_cache_desktop_free(Efreet_Desktop *desktop)
curr = eina_hash_find(d->hash, desktop->orig_path);
if (curr == desktop)
{
-INF("Found in old cache, purge\n");
+INF("Found '%s' in old cache, purge", desktop->orig_path);
eina_hash_del_by_key(d->hash, desktop->orig_path);
if (eina_hash_population(d->hash) == 0)
{
-INF("Cache empty, close file\n");
+INF("Cache empty, close file");
eina_hash_free(d->hash);
eet_close(d->ef);
free(d);
diff --git a/src/lib/efreet/efreet_desktop.c b/src/lib/efreet/efreet_desktop.c
index f857de8..2645c94 100644
--- a/src/lib/efreet/efreet_desktop.c
+++ b/src/lib/efreet/efreet_desktop.c
@@ -571,8 +571,7 @@ efreet_desktop_string_list_parse(const char *string)
if (*s)
{
#ifdef STRICT_SPEC
-WRN("[Efreet]: Found a string list without ';' "
-"at the end: %s", string);
+WRN("Found a string list without ';' at the end: '%s'", string);
#endif
list = eina_list_append(list, (void *)eina_stringshare_add(s));
}
@@ -644,7 +643,7 @@ efreet_desktop_read(Efreet_Desktop *desktop)
if (!ok) ok = efreet_ini_section_set(ini, "KDE Desktop Entry");
if (!ok)
{
-ERR("efreet_desktop_new error: no Desktop Entry section");
+ERR("no Desktop Entry section in file '%s'", desktop->orig_path);
error = 1;
}
@@ -957,7 +956,7 @@ efreet_desktop_generic_fields_parse(Efreet_Desktop
*desktop, Efreet_Ini *ini)
if (val) desktop->name = strdup(val);
else
{
-ERR("efreet_desktop_generic_fields_parse error: no Na
[EGIT] [core/efl] master 02/03: efreet: remove dead code
englebass pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=d8aead7ab825eaca1bb3dda20946968f4b8680f3
commit d8aead7ab825eaca1bb3dda20946968f4b8680f3
Author: Sebastian Dransfeld
Date: Mon Sep 29 09:32:48 2014 +0200
efreet: remove dead code
---
src/lib/efreet/efreet_desktop_command.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/src/lib/efreet/efreet_desktop_command.c
b/src/lib/efreet/efreet_desktop_command.c
index 15a4a5c..c6c8d18 100644
--- a/src/lib/efreet/efreet_desktop_command.c
+++ b/src/lib/efreet/efreet_desktop_command.c
@@ -613,11 +613,6 @@ efreet_desktop_command_file_process(Efreet_Desktop_Command
*command, const char
Efreet_Desktop_Command_File *f;
const char *uri, *base;
int nonlocal = 0;
-/*
-DBG("FLAGS: %d, %d, %d, %d\n",
-command->flags & EFREET_DESKTOP_EXEC_FLAG_FULLPATH ? 1 : 0,
-command->flags & EFREET_DESKTOP_EXEC_FLAG_URI ? 1 : 0);
-*/
f = NEW(Efreet_Desktop_Command_File, 1);
if (!f) return NULL;
@@ -691,12 +686,6 @@ efreet_desktop_command_file_process(Efreet_Desktop_Command
*command, const char
free(absol);
}
-#if 0
-INF(" fullpath: %s", f->fullpath);
-INF(" uri: %s", f->uri);
-INF(" dir: %s", f->dir);
-INF(" file: %s", f->file);
-#endif
return f;
error:
IF_FREE(f);
--
Re: [E-devel] [EGIT] [core/efl] master 01/01: Eo: Change eo_add/del/unref behaviour.
On 28/09/14 08:54, Daniel Zaoui wrote:
> On 09/25/14 19:49, Tom Hacohen wrote:
>> I know it sounds intrusive, but it's actually more intrusive than it
>> sounds. :P
>>
>> Please keep an eye out for widgets leaking references, or errors in the
>> terminal. Things seem to be sane here, but one can never know.
>>
>> If you see a break, please don't blindly revert these changes, and
>> instead help me find and fix it.
>>
>> Thanks.
>>
>> --
>> Tom.
>>
>> On 25/09/14 17:39, Tom Hacohen wrote:
>>> tasn pushed a commit to branch master.
>>>
>>> http://git.enlightenment.org/core/efl.git/commit/?id=a7560dbc61953c3652780f232e38adbd2d711972
>>>
>>> commit a7560dbc61953c3652780f232e38adbd2d711972
>>> Author: Tom Hacohen
>>> Date: Thu Sep 25 15:51:17 2014 +0100
>>>
>>> Eo: Change eo_add/del/unref behaviour.
>>>
>>> Before this change eo_add() used to create an object with 1 ref, and
>>> if
>>> the object had a parent, a second ref.
>>> Now, eo_add() always returns an object with 1 ref, and eo_add_ref()
>>> preserves the old behaviour (for bindings).
>>>
>>> eo_unref now un-parents if refcount is 0, and eo_del() is an alias for
>>> eo_unref (will change to be a way to ensure an object is dead and goes
>>> to zombie-land even if still refed).
>>> ---
>>>src/lib/ecore/ecore_anim.c | 2 --
>>>src/lib/ecore/ecore_idle_enterer.c | 2 --
>>>src/lib/ecore/ecore_idle_exiter.c | 1 -
>>>src/lib/ecore/ecore_idler.c| 1 -
>>>src/lib/ecore/ecore_job.c | 1 -
>>>src/lib/ecore/ecore_poller.c | 1 -
>>>src/lib/ecore/ecore_timer.c| 2 --
>>>src/lib/edje/edje_edit.c | 1 -
>>>src/lib/edje/edje_smart.c | 1 -
>>>src/lib/emotion/emotion_smart.c| 1 -
>>>src/lib/eo/Eo.h| 26
>>> ++
>>>src/lib/eo/eo.c| 17 +-
>>>src/lib/eo/eo_private.h| 11 +
>>>src/lib/evas/canvas/evas_3d_camera.c | 1 -
>>>src/lib/evas/canvas/evas_3d_light.c| 1 -
>>>src/lib/evas/canvas/evas_3d_material.c | 1 -
>>>src/lib/evas/canvas/evas_3d_mesh.c | 1 -
>>>src/lib/evas/canvas/evas_3d_node.c | 1 -
>>>src/lib/evas/canvas/evas_3d_scene.c| 1 -
>>>src/lib/evas/canvas/evas_3d_texture.c | 1 -
>>>src/lib/evas/canvas/evas_object_box.c | 1 -
>>>src/lib/evas/canvas/evas_object_grid.c | 1 -
>>>src/lib/evas/canvas/evas_object_image.c| 1 -
>>>src/lib/evas/canvas/evas_object_line.c | 1 -
>>>src/lib/evas/canvas/evas_object_main.c | 3 +--
>>>src/lib/evas/canvas/evas_object_polygon.c | 1 -
>>>src/lib/evas/canvas/evas_object_rectangle.c| 1 -
>>>src/lib/evas/canvas/evas_object_smart.c| 1 -
>>>src/lib/evas/canvas/evas_object_table.c| 1 -
>>>src/lib/evas/canvas/evas_object_text.c | 1 -
>>>src/lib/evas/canvas/evas_object_textblock.c| 1 -
>>>src/lib/evas/canvas/evas_object_textgrid.c | 1 -
>>>src/lib/evas/canvas/evas_out.c | 1 -
>>>src/tests/eo/children/children_simple.c| 2 +-
>>>.../eo/composite_objects/composite_objects_comp.c | 2 --
>>>src/tests/eo/suite/eo_test_general.c | 12 +-
>>>36 files changed, 61 insertions(+), 44 deletions(-)
>>>
>>> diff --git a/src/lib/ecore/ecore_anim.c b/src/lib/ecore/ecore_anim.c
>>> index 7116538..6dee5ad 100644
>>> --- a/src/lib/ecore/ecore_anim.c
>>> +++ b/src/lib/ecore/ecore_anim.c
>>> @@ -204,7 +204,6 @@ ecore_animator_add(Ecore_Task_Cb func,
>>>
>>> animator = eo_add(MY_CLASS, _ecore_parent,
>>>ecore_animator_constructor(func, data));
>>> - eo_unref(animator);
>>> return animator;
>>>}
>>>
>>> @@ -224,7 +223,6 @@ ecore_animator_timeline_add(doubleruntime,
>>> Ecore_Animator *animator;
>>> animator = eo_add(MY_CLASS, _ecore_parent,
>>>ecore_animator_timeline_constructor(runtime,
>>> func, data));
>>> - eo_unref(animator);
>>> return animator;
>>>}
>>>
>>> diff --git a/src/lib/ecore/ecore_idle_enterer.c
>>> b/src/lib/ecore/ecore_idle_enterer.c
>>> index f6d5b99..038b5c9 100644
>>> --- a/src/lib/ecore/ecore_idle_enterer.c
>>> +++ b/src/lib/ecore/ecore_idle_enterer.c
>>> @@ -64,7 +64,6 @@ ecore_idle_enterer_add(Ecore_Task_Cb func,
>>>{
>>> Ecore_Idle_Enterer *ie = NULL;
>>> ie = eo_add(MY_CLASS, _ecore_parent,
>>> ecore_idle_enterer_after_constructor(func, data)
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler wrote: > On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL said: >> On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi >> wrote: >> > Em 28/09/2014 08:46, "Graham Gower" escreveu: >> >> I've attempted to build using the easy_efl.sh script and received the >> >> build error referenced in the subject (full build log follows >> >> message). >> >> >> >> Is there a particular version of udev that is required now, but hasn't >> >> been put in the autoconf goo? I have udev 182 on a linux distro >> >> without systemd. >> > >> > From >> > http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f >> > >> > libudev 199 >> >> Question as always how many distribution ship this library and how >> many don't. Should we make 199 mandatory or should we just disable the >> code that require 199 (I guess it is related to wayland). > > since systemd and udev merged... a lot seem to have stopped updating udev at > all and may b e on a multi-year-old udev (eg 2011). so our choices are to > force > an upgrade or work on these distros, or we need a way to emulate this udev > call > inside eeze iof udev is older. that means someone has to do the emulation code > work there. Do we really need to ? We could just disable Wayland support if udev is to old, as I think that is the only think that rely on it. The question is more what about other system than Linux. -- Cedric BAIL -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/elementary] master 01/01: scale: fix the floating number comparison.
I didn't know about DBL_EPSILON.
- if ((int)(base_scale * 1) == 0) return;
+ if (fabs(base_scale) > DBL_EPSILON) return;
How about this change?
(I don't want to increase unnecessary commits..)
2014년 9월 26일 금요일, Cedric BAIL님이 작성한 메시지:
> I think you are trying to compare double together, but that's not the
> way to go. Look at Enlightenment, dblequal if you want, but basically
> the right way is I think : fabs(a DBL_EPSILON;
>
> On Fri, Sep 26, 2014 at 5:11 AM, Jaehwan Kim > wrote:
> > jaehwan pushed a commit to branch master.
> >
> >
> http://git.enlightenment.org/core/elementary.git/commit/?id=dc1382b9d0c32cc64d6de6266244889578eb13bd
> >
> > commit dc1382b9d0c32cc64d6de6266244889578eb13bd
> > Author: Jaehwan Kim >
> > Date: Fri Sep 26 12:07:34 2014 +0900
> >
> > scale: fix the floating number comparison.
> >
> > There's no meaning 0.1 in scale. So in that case, it is ignored.
> > ---
> > src/lib/elm_main.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/lib/elm_main.c b/src/lib/elm_main.c
> > index 9fabd43..86ea7c7 100644
> > --- a/src/lib/elm_main.c
> > +++ b/src/lib/elm_main.c
> > @@ -461,14 +461,15 @@ elm_app_locale_dir_get(void)
> > EAPI void
> > elm_app_base_scale_set(double base_scale)
> > {
> > - if (base_scale <= 0.0) return;
> > + if (base_scale < 0.0) return;
> > + if ((int)(base_scale * 1) == 0) return;
> > app_base_scale = base_scale;
> > }
> >
> > EAPI double
> > elm_app_base_scale_get(void)
> > {
> > - if (app_base_scale) return app_base_scale;
> > + if (app_base_scale > 0.0) return app_base_scale;
> > return 1.0;
> > }
> >
> >
> > --
> >
> >
> >
>
>
>
> --
> Cedric BAIL
>
>
> --
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Slashdot TV. Videos for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/elementary] master 01/01: scale: fix the floating number comparison.
On 29/09/14 09:12, Jaehwan Kim wrote:
> I didn't know about DBL_EPSILON.
>
> - if ((int)(base_scale * 1) == 0) return;
> + if (fabs(base_scale) > DBL_EPSILON) return;
Shouldn't this be < DBL_EPSILON?
--
Tom.
>
> How about this change?
> (I don't want to increase unnecessary commits..)
>
>
>
> 2014년 9월 26일 금요일, Cedric BAIL님이 작성한 메시지:
>
>> I think you are trying to compare double together, but that's not the
>> way to go. Look at Enlightenment, dblequal if you want, but basically
>> the right way is I think : fabs(a DBL_EPSILON;
>>
>> On Fri, Sep 26, 2014 at 5:11 AM, Jaehwan Kim > > wrote:
>>> jaehwan pushed a commit to branch master.
>>>
>>>
>> http://git.enlightenment.org/core/elementary.git/commit/?id=dc1382b9d0c32cc64d6de6266244889578eb13bd
>>>
>>> commit dc1382b9d0c32cc64d6de6266244889578eb13bd
>>> Author: Jaehwan Kim >
>>> Date: Fri Sep 26 12:07:34 2014 +0900
>>>
>>> scale: fix the floating number comparison.
>>>
>>> There's no meaning 0.1 in scale. So in that case, it is ignored.
>>> ---
>>> src/lib/elm_main.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/lib/elm_main.c b/src/lib/elm_main.c
>>> index 9fabd43..86ea7c7 100644
>>> --- a/src/lib/elm_main.c
>>> +++ b/src/lib/elm_main.c
>>> @@ -461,14 +461,15 @@ elm_app_locale_dir_get(void)
>>> EAPI void
>>> elm_app_base_scale_set(double base_scale)
>>> {
>>> - if (base_scale <= 0.0) return;
>>> + if (base_scale < 0.0) return;
>>> + if ((int)(base_scale * 1) == 0) return;
>>> app_base_scale = base_scale;
>>> }
>>>
>>> EAPI double
>>> elm_app_base_scale_get(void)
>>> {
>>> - if (app_base_scale) return app_base_scale;
>>> + if (app_base_scale > 0.0) return app_base_scale;
>>> return 1.0;
>>> }
>>>
>>>
>>> --
>>>
>>>
>>>
>>
>>
>>
>> --
>> Cedric BAIL
>>
>>
>> --
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
> --
> Slashdot TV. Videos for Nerds. Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Slashdot TV. Videos for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
2014-09-29 8:52 GMT+01:00 Cedric BAIL : > On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler > wrote: > > On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL > said: > >> On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi > >> wrote: > >> > Em 28/09/2014 08:46, "Graham Gower" > escreveu: > >> >> I've attempted to build using the easy_efl.sh script and received the > >> >> build error referenced in the subject (full build log follows > >> >> message). > >> >> > >> >> Is there a particular version of udev that is required now, but > hasn't > >> >> been put in the autoconf goo? I have udev 182 on a linux distro > >> >> without systemd. > >> > > >> > From > >> > > http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f > >> > > >> > libudev 199 > >> > >> Question as always how many distribution ship this library and how > >> many don't. Should we make 199 mandatory or should we just disable the > >> code that require 199 (I guess it is related to wayland). > > > > since systemd and udev merged... a lot seem to have stopped updating > udev at > > all and may b e on a multi-year-old udev (eg 2011). so our choices are > to force > > an upgrade or work on these distros, or we need a way to emulate this > udev call > > inside eeze iof udev is older. that means someone has to do the > emulation code > > work there. > > Do we really need to ? We could just disable Wayland support if udev > is to old, as I think that is the only think that rely on it. The > question is more what about other system than Linux. > No eeze at all on non-Linux systems. The functionality is usually there but has a different library that is API-incompatible... but Eeze being a very thin wrapper == near impossible to port. I've always been saying that it's a stupid idea to have a wrapper as thin as this, should've been a more abstracted library. > -- > Cedric BAIL > > > -- > Slashdot TV. Videos for Nerds. Stuff that Matters. > > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > D5 -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/elementary] master 01/01: scale: fix the floating number comparison.
You're right. sorry~
2014년 9월 29일 월요일, Tom Hacohen님이 작성한 메시지:
> On 29/09/14 09:12, Jaehwan Kim wrote:
> > I didn't know about DBL_EPSILON.
> >
> > - if ((int)(base_scale * 1) == 0) return;
> > + if (fabs(base_scale) > DBL_EPSILON) return;
>
> Shouldn't this be < DBL_EPSILON?
>
> --
> Tom.
>
> >
> > How about this change?
> > (I don't want to increase unnecessary commits..)
> >
> >
> >
> > 2014년 9월 26일 금요일, Cedric BAIL>님이 작성한
> 메시지:
> >
> >> I think you are trying to compare double together, but that's not the
> >> way to go. Look at Enlightenment, dblequal if you want, but basically
> >> the right way is I think : fabs(a DBL_EPSILON;
> >>
> >> On Fri, Sep 26, 2014 at 5:11 AM, Jaehwan Kim
> >> > wrote:
> >>> jaehwan pushed a commit to branch master.
> >>>
> >>>
> >>
> http://git.enlightenment.org/core/elementary.git/commit/?id=dc1382b9d0c32cc64d6de6266244889578eb13bd
> >>>
> >>> commit dc1382b9d0c32cc64d6de6266244889578eb13bd
> >>> Author: Jaehwan Kim
> >
> >>> Date: Fri Sep 26 12:07:34 2014 +0900
> >>>
> >>> scale: fix the floating number comparison.
> >>>
> >>> There's no meaning 0.1 in scale. So in that case, it is
> ignored.
> >>> ---
> >>> src/lib/elm_main.c | 5 +++--
> >>> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/src/lib/elm_main.c b/src/lib/elm_main.c
> >>> index 9fabd43..86ea7c7 100644
> >>> --- a/src/lib/elm_main.c
> >>> +++ b/src/lib/elm_main.c
> >>> @@ -461,14 +461,15 @@ elm_app_locale_dir_get(void)
> >>> EAPI void
> >>> elm_app_base_scale_set(double base_scale)
> >>> {
> >>> - if (base_scale <= 0.0) return;
> >>> + if (base_scale < 0.0) return;
> >>> + if ((int)(base_scale * 1) == 0) return;
> >>> app_base_scale = base_scale;
> >>> }
> >>>
> >>> EAPI double
> >>> elm_app_base_scale_get(void)
> >>> {
> >>> - if (app_base_scale) return app_base_scale;
> >>> + if (app_base_scale > 0.0) return app_base_scale;
> >>> return 1.0;
> >>> }
> >>>
> >>>
> >>> --
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Cedric BAIL
> >>
> >>
> >>
> --
> >> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> >> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> >> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> >> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> >>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> >
> --
> > Slashdot TV. Videos for Nerds. Stuff that Matters.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
>
>
>
> --
> Slashdot TV. Videos for Nerds. Stuff that Matters.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Slashdot TV. Videos for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/elementary] master 01/01: elm_object_item: add a convenient macro api.
hermet pushed a commit to branch master. http://git.enlightenment.org/core/elementary.git/commit/?id=3c25b810c0d014e5ad304214756a35757da9af9e commit 3c25b810c0d014e5ad304214756a35757da9af9e Author: ChunEon Park Date: Mon Sep 29 19:00:09 2014 +0900 elm_object_item: add a convenient macro api. elm_object_item_translatable_set(). --- src/lib/elm_object_item.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/lib/elm_object_item.h b/src/lib/elm_object_item.h index 6a46712..6e4f550 100644 --- a/src/lib/elm_object_item.h +++ b/src/lib/elm_object_item.h @@ -200,6 +200,8 @@ EAPI void elm_object_item_domain_part_text_translatable_set(Elm_Object_Item *it, #define elm_object_item_domain_text_translatable_set(it, domain, translatable) elm_object_item_domain_part_text_translatable_set((it), NULL, (domain), (translatable)) +#define elm_object_item_text_translatable_set(it, translatable) elm_object_item_domain_part_text_translatable_set((it), NULL, NULL, (translatable)) + /** * Set the text to read out when in accessibility mode * --
[EGIT] [core/elementary] master 01/01: scale: change the floating number comparison method.
jaehwan pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=5c3c137b80cbc47c32208fb651f22fa71f8634ed
commit 5c3c137b80cbc47c32208fb651f22fa71f8634ed
Author: Jaehwan Kim
Date: Mon Sep 29 19:02:18 2014 +0900
scale: change the floating number comparison method.
---
src/lib/elm_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/lib/elm_main.c b/src/lib/elm_main.c
index 86ea7c7..6469693 100644
--- a/src/lib/elm_main.c
+++ b/src/lib/elm_main.c
@@ -462,7 +462,7 @@ EAPI void
elm_app_base_scale_set(double base_scale)
{
if (base_scale < 0.0) return;
- if ((int)(base_scale * 1) == 0) return;
+ if (fabs(base_scale) < DBL_EPSILON) return;
app_base_scale = base_scale;
}
--
[EGIT] [core/efl] master 01/01: elua: update lualian generation code to potentially deal with cycles
q66 pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=afc5dd02f939c9bbf698e88dfcffe066d42a2d23
commit afc5dd02f939c9bbf698e88dfcffe066d42a2d23
Author: Daniel Kolesa
Date: Mon Sep 29 11:52:50 2014 +0100
elua: update lualian generation code to potentially deal with cycles
---
src/bin/elua/modules/lualian.lua | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/bin/elua/modules/lualian.lua b/src/bin/elua/modules/lualian.lua
index dd317d0..8f76dd6 100644
--- a/src/bin/elua/modules/lualian.lua
+++ b/src/bin/elua/modules/lualian.lua
@@ -382,7 +382,7 @@ local Mixin = Node:clone {
s:write(([[
local __class = __lib.%s_class_get()
-%s.%s = eo.class_register("%s", {
+%s.%s = eo.class_register("%s", nil, {
]]):format(self.prefix, mname, self.klass:name_get(),
self.klass:full_name_get()))
@@ -446,19 +446,19 @@ local Class = Node:clone {
mname = "M"
end
+local kn = self.klass:full_name_get()
+
s:write(([[
local __class = __lib.%s_class_get()
-local Parent = eo.class_get("%s")
-eo.class_register("%s", Parent:clone {
-]]):format(self.prefix, self.parent, self.klass:full_name_get()))
+eo.class_register("%s", %s, {
+]]):format(self.prefix, kn, self.parent and ('"' .. self.parent .. '"') or
"nil"))
self:gen_children(s)
s:write("})")
for i, v in ipairs(self.mixins) do
-s:write(("\nM.%s:mixin(eo.class_get(\"%s\"))\n")
-:format(ename, v))
+s:write(("\neo.class_mixin(\"%s\", \"%s\")\n"):format(kn, v))
end
-- write the constructor
--
[EGIT] [core/efl] master 01/01: elua: properly register the eo class into the system in generated code
q66 pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=73bf20fe4e9450b2f38f948529975dd10c0957c5
commit 73bf20fe4e9450b2f38f948529975dd10c0957c5
Author: Daniel Kolesa
Date: Mon Sep 29 12:40:50 2014 +0100
elua: properly register the eo class into the system in generated code
---
src/bin/elua/modules/lualian.lua | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/bin/elua/modules/lualian.lua b/src/bin/elua/modules/lualian.lua
index 8f76dd6..1fba42d 100644
--- a/src/bin/elua/modules/lualian.lua
+++ b/src/bin/elua/modules/lualian.lua
@@ -388,7 +388,7 @@ local __class = __lib.%s_class_get()
self:gen_children(s)
-s:write("})\n")
+s:write("}, __class)\n")
end,
gen_ffi = function(self, s)
@@ -455,7 +455,7 @@ eo.class_register("%s", %s, {
self:gen_children(s)
-s:write("})")
+s:write("}, __class)")
for i, v in ipairs(self.mixins) do
s:write(("\neo.class_mixin(\"%s\", \"%s\")\n"):format(kn, v))
--
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Mon, 29 Sep 2014 09:30:57 +0100 Daniel Kolesa said: > 2014-09-29 8:52 GMT+01:00 Cedric BAIL : > > > On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler > > wrote: > > > On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL > > said: > > >> On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi > > >> wrote: > > >> > Em 28/09/2014 08:46, "Graham Gower" > > escreveu: > > >> >> I've attempted to build using the easy_efl.sh script and received the > > >> >> build error referenced in the subject (full build log follows > > >> >> message). > > >> >> > > >> >> Is there a particular version of udev that is required now, but > > hasn't > > >> >> been put in the autoconf goo? I have udev 182 on a linux distro > > >> >> without systemd. > > >> > > > >> > From > > >> > > > http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f > > >> > > > >> > libudev 199 > > >> > > >> Question as always how many distribution ship this library and how > > >> many don't. Should we make 199 mandatory or should we just disable the > > >> code that require 199 (I guess it is related to wayland). > > > > > > since systemd and udev merged... a lot seem to have stopped updating > > udev at > > > all and may b e on a multi-year-old udev (eg 2011). so our choices are > > to force > > > an upgrade or work on these distros, or we need a way to emulate this > > udev call > > > inside eeze iof udev is older. that means someone has to do the > > emulation code > > > work there. > > > > Do we really need to ? We could just disable Wayland support if udev > > is to old, as I think that is the only think that rely on it. The > > question is more what about other system than Linux. > > > > No eeze at all on non-Linux systems. The functionality is usually there but > has a different library that is API-incompatible... but Eeze being a very > thin wrapper == near impossible to port. I've always been saying that it's > a stupid idea to have a wrapper as thin as this, should've been a more > abstracted library. i agree there. it should be higher up the stack (abstracted) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL said: > On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler > wrote: > > On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL said: > >> On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi > >> wrote: > >> > Em 28/09/2014 08:46, "Graham Gower" escreveu: > >> >> I've attempted to build using the easy_efl.sh script and received the > >> >> build error referenced in the subject (full build log follows > >> >> message). > >> >> > >> >> Is there a particular version of udev that is required now, but hasn't > >> >> been put in the autoconf goo? I have udev 182 on a linux distro > >> >> without systemd. > >> > > >> > From > >> > http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f > >> > > >> > libudev 199 > >> > >> Question as always how many distribution ship this library and how > >> many don't. Should we make 199 mandatory or should we just disable the > >> code that require 199 (I guess it is related to wayland). > > > > since systemd and udev merged... a lot seem to have stopped updating udev at > > all and may b e on a multi-year-old udev (eg 2011). so our choices are to > > force an upgrade or work on these distros, or we need a way to emulate this > > udev call inside eeze iof udev is older. that means someone has to do the > > emulation code work there. > > Do we really need to ? We could just disable Wayland support if udev > is to old, as I think that is the only think that rely on it. The > question is more what about other system than Linux. that makes for a poor eeze api that may or may not work based on a hidden udev version at compile time of eeze. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Preparing EFL Korea Seminar
Hi, This is Hermet. I and SeoZ 're planning 2nd EFL Korea Seminar for EFl Korea Community continued to last year. The purpose of this seminar is not only for introducing EFL to developers in Korea but sharing EFL information each others. Im expecting students, 3rd party developers, Samsung engineers... and some efl korea commnunity members will attend the event. Im trying to reserve the seminar room in Kangnam. It's gonna be held on 25th(Sat)/Oct from 13:30 to 18:00. (If the place is not available, the date could be changed.) Here is the sessions of the main event. Opening (10 min) - Hermet Introduction of EFL and Enlightenment (30 min) - Hermet (NOT CONFIRMED) Getting Started - Writing EFL App (30 min) - WooChan Lee Various widget themes with Elm Theme Viewer (20 min) - SeoZ Scalable GUI in EFL (30 min) - JaeHwan Kim EDC Programming with Enventor (30 min) - JaeHyun Jo (NOT CONFIRMED) Webkit EFL (30 min) - Ryuan (NOT CONFIRMED) Enlightenment Window Manager (30 min) - Raster Closing (10 min) - Hermet In the last year, the count of the attendees was around 35, but I'm expecting more than 50 people will attend this seminar, since Tizen and EFL have been much more spreaded. Even I checked about 150 members have joined in our efl korea community additionally since the last year. After the main event is over, we will have E-Korea Dinner as usual. Please update your session info in our phabricator page. (see Details) https://phab.enlightenment.org/w/events/efl_korean_seminar_2014/ Notify me if you can't prepare the session in advance, And give me any suggestions for better event. Thank you. -Regards, Hermet- -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: ecore-drm: Added internal function to set output brightness level
devilhorns pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=9b84f98e2748694c5b0e114c84aeb7744dfbcb03
commit 9b84f98e2748694c5b0e114c84aeb7744dfbcb03
Author: vivek
Date: Mon Sep 29 08:52:30 2014 -0400
ecore-drm: Added internal function to set output brightness level
Summary:
Added _ecore_drm_output_brightness_set function to set brightness level
Signed-off-by: vivek
Reviewers: devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1499
---
src/lib/ecore_drm/ecore_drm_output.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/src/lib/ecore_drm/ecore_drm_output.c
b/src/lib/ecore_drm/ecore_drm_output.c
index 9b7fae8..7f96797 100644
--- a/src/lib/ecore_drm/ecore_drm_output.c
+++ b/src/lib/ecore_drm/ecore_drm_output.c
@@ -296,6 +296,9 @@ _ecore_drm_output_brightness_get(Ecore_Drm_Backlight
*backlight)
const char *brightness = NULL;
double ret;
+ if (!(backlight) || !(backlight->device))
+ return 0;
+
brightness = eeze_udev_syspath_get_sysattr(backlight->device, "brightness");
if (!brightness) return 0;
@@ -312,6 +315,9 @@ _ecore_drm_output_actual_brightness_get(Ecore_Drm_Backlight
*backlight)
const char *brightness = NULL;
double ret;
+ if (!(backlight) || !(backlight->device))
+ return 0;
+
brightness = eeze_udev_syspath_get_sysattr(backlight->device,
"actual_brightness");
if (!brightness) return 0;
@@ -328,6 +334,9 @@ _ecore_drm_output_max_brightness_get(Ecore_Drm_Backlight
*backlight)
const char *brightness = NULL;
double ret;
+ if (!(backlight) || !(backlight->device))
+ return 0;
+
brightness = eeze_udev_syspath_get_sysattr(backlight->device,
"max_brightness");
if (!brightness) return 0;
@@ -338,6 +347,19 @@ _ecore_drm_output_max_brightness_get(Ecore_Drm_Backlight
*backlight)
return ret;
}
+static double
+_ecore_drm_output_brightness_set(Ecore_Drm_Backlight *backlight, double
brightness_val)
+{
+ Eina_Bool ret = EINA_FALSE;
+
+ if (!(backlight) || !(backlight->device))
+ return ret;
+
+ ret = eeze_udev_syspath_set_sysattr(backlight->device, "brightness",
brightness_val);
+
+ return ret;
+}
+
static Ecore_Drm_Backlight *
_ecore_drm_output_backlight_init(Ecore_Drm_Output *output EINA_UNUSED,
uint32_t conn_type)
{
--
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On 09/29/2014 07:47 AM, Carsten Haitzler (The Rasterman) wrote: > On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL said: > >> On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler >> wrote: >>> On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL said: On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi wrote: > Em 28/09/2014 08:46, "Graham Gower" escreveu: >> I've attempted to build using the easy_efl.sh script and received the >> build error referenced in the subject (full build log follows >> message). >> >> Is there a particular version of udev that is required now, but hasn't >> been put in the autoconf goo? I have udev 182 on a linux distro >> without systemd. > > From > http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f > > libudev 199 Question as always how many distribution ship this library and how many don't. Should we make 199 mandatory or should we just disable the code that require 199 (I guess it is related to wayland). >>> >>> since systemd and udev merged... a lot seem to have stopped updating udev at >>> all and may b e on a multi-year-old udev (eg 2011). so our choices are to >>> force an upgrade or work on these distros, or we need a way to emulate this >>> udev call inside eeze iof udev is older. that means someone has to do the >>> emulation code work there. >> >> Do we really need to ? We could just disable Wayland support if udev >> is to old, as I think that is the only think that rely on it. The >> question is more what about other system than Linux. > > that makes for a poor eeze api that may or may not work based on a hidden udev > version at compile time of eeze. > Well, perhaps for the moment we can detect the udev version and just #ifdef the internal eeze code to skip that function call. Fixes the build problem while Not breaking code for people that have a sane udev version. Thoughts ?? dh -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Mon, 29 Sep 2014 09:06:30 -0400 Chris Michael said: > On 09/29/2014 07:47 AM, Carsten Haitzler (The Rasterman) wrote: > > On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL said: > > > >> On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler > >> wrote: > >>> On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL said: > On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi > wrote: > > Em 28/09/2014 08:46, "Graham Gower" escreveu: > >> I've attempted to build using the easy_efl.sh script and received the > >> build error referenced in the subject (full build log follows > >> message). > >> > >> Is there a particular version of udev that is required now, but hasn't > >> been put in the autoconf goo? I have udev 182 on a linux distro > >> without systemd. > > > > From > > http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f > > > > libudev 199 > > Question as always how many distribution ship this library and how > many don't. Should we make 199 mandatory or should we just disable the > code that require 199 (I guess it is related to wayland). > >>> > >>> since systemd and udev merged... a lot seem to have stopped updating udev > >>> at all and may b e on a multi-year-old udev (eg 2011). so our choices are > >>> to force an upgrade or work on these distros, or we need a way to emulate > >>> this udev call inside eeze iof udev is older. that means someone has to > >>> do the emulation code work there. > >> > >> Do we really need to ? We could just disable Wayland support if udev > >> is to old, as I think that is the only think that rely on it. The > >> question is more what about other system than Linux. > > > > that makes for a poor eeze api that may or may not work based on a hidden > > udev version at compile time of eeze. > > > > Well, perhaps for the moment we can detect the udev version and just > #ifdef the internal eeze code to skip that function call. Fixes the > build problem while Not breaking code for people that have a sane udev > version. Thoughts ?? but downside is we have an eeze fn that now is broken for some and not others... and then when some try wayland things mysteriously fail.. we'll hit this sooner or later in one form or another. best get it sorted now while fresh. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On 09/29/2014 09:17 AM, Carsten Haitzler (The Rasterman) wrote: > On Mon, 29 Sep 2014 09:06:30 -0400 Chris Michael > said: > >> On 09/29/2014 07:47 AM, Carsten Haitzler (The Rasterman) wrote: >>> On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL said: >>> On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler wrote: > On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL said: >> On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi >> wrote: >>> Em 28/09/2014 08:46, "Graham Gower" escreveu: I've attempted to build using the easy_efl.sh script and received the build error referenced in the subject (full build log follows message). Is there a particular version of udev that is required now, but hasn't been put in the autoconf goo? I have udev 182 on a linux distro without systemd. >>> >>> From >>> http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f >>> >>> libudev 199 >> >> Question as always how many distribution ship this library and how >> many don't. Should we make 199 mandatory or should we just disable the >> code that require 199 (I guess it is related to wayland). > > since systemd and udev merged... a lot seem to have stopped updating udev > at all and may b e on a multi-year-old udev (eg 2011). so our choices are > to force an upgrade or work on these distros, or we need a way to emulate > this udev call inside eeze iof udev is older. that means someone has to > do the emulation code work there. Do we really need to ? We could just disable Wayland support if udev is to old, as I think that is the only think that rely on it. The question is more what about other system than Linux. >>> >>> that makes for a poor eeze api that may or may not work based on a hidden >>> udev version at compile time of eeze. >>> >> >> Well, perhaps for the moment we can detect the udev version and just >> #ifdef the internal eeze code to skip that function call. Fixes the >> build problem while Not breaking code for people that have a sane udev >> version. Thoughts ?? > > but downside is we have an eeze fn that now is broken for some and not > others... and then when some try wayland things mysteriously fail.. we'll hit > this sooner or later in one form or another. best get it sorted now while > fresh. > Ok. Makes sense :) So...what is the general "agreed" plan for sorting this ?? I've seen a couple of thoughts on this thread, but no clear plan/path. I don't mind doing the legwork if we all can agree on a path dh -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 02/02: ecore-drm: Added private function to cleanup backlight structure
devilhorns pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=4125f1cef95dba4891671cd4610728afc31dc281
commit 4125f1cef95dba4891671cd4610728afc31dc281
Author: vivek
Date: Mon Sep 29 09:28:58 2014 -0400
ecore-drm: Added private function to cleanup backlight structure
Summary:
Added _ecore_drm_output_backlight_shutdown function to clean up
the resources related to backlight structure and initialized backlight
structure
in _ecore_drm_output_create.
Signed-off-by: vivek
Reviewers: devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1501
---
src/lib/ecore_drm/ecore_drm_output.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/lib/ecore_drm/ecore_drm_output.c
b/src/lib/ecore_drm/ecore_drm_output.c
index 7f96797..38ba1a0 100644
--- a/src/lib/ecore_drm/ecore_drm_output.c
+++ b/src/lib/ecore_drm/ecore_drm_output.c
@@ -416,6 +416,18 @@ out:
return backlight;
}
+static void
+_ecore_drm_output_backlight_shutdown(Ecore_Drm_Backlight *backlight)
+{
+ if (!backlight)
+ return;
+
+ if (backlight->device)
+ eina_stringshare_del(backlight->device);
+
+ free(backlight);
+}
+
static Ecore_Drm_Output *
_ecore_drm_output_create(Ecore_Drm_Device *dev, drmModeRes *res,
drmModeConnector *conn, int x, int y)
{
@@ -523,7 +535,7 @@ _ecore_drm_output_create(Ecore_Drm_Device *dev, drmModeRes
*res, drmModeConnecto
DBG("Setup Output %d for Software Rendering", output->crtc_id);
}
- /* TODO: Backlight */
+ output->backlight = _ecore_drm_output_backlight_init(output,
conn->connector_type);
return output;
--
[EGIT] [core/efl] master 01/02: ecore_wayland: Created test suit for ecore_wayland.
devilhorns pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=a79adfcc69c8b7655a8464ce685921d3427302c3
commit a79adfcc69c8b7655a8464ce685921d3427302c3
Author: Srivardhan Hebbar
Date: Mon Sep 29 09:20:04 2014 -0400
ecore_wayland: Created test suit for ecore_wayland.
Summary:
Created test suit for ecore_wayland and added test case for ecore_wl_init
and ecore_wl_shutdown.
Signed-off-by: Srivardhan Hebbar
Reviewers: devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1498
---
src/Makefile_Ecore.am | 13 ---
src/tests/ecore/ecore_suite.c | 3 +++
src/tests/ecore/ecore_suite.h | 1 +
src/tests/ecore/ecore_test_ecore_wayland.c | 37 ++
4 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/src/Makefile_Ecore.am b/src/Makefile_Ecore.am
index 09a292a..fe62dfd 100644
--- a/src/Makefile_Ecore.am
+++ b/src/Makefile_Ecore.am
@@ -215,7 +215,8 @@ tests_ecore_ecore_suite_CPPFLAGS =
-I$(top_builddir)/src/lib/efl \
@ECORE_FILE_CFLAGS@ \
@ECORE_X_CFLAGS@ \
@ECORE_IMF_CFLAGS@ \
-@ECORE_EVAS_CFLAGS@
+@ECORE_EVAS_CFLAGS@ \
+@ECORE_WAYLAND_CFLAGS@
tests_ecore_ecore_suite_LDADD = \
@CHECK_LIBS@ \
@@ -225,7 +226,8 @@ tests_ecore_ecore_suite_LDADD = \
@USE_ECORE_FILE_LIBS@ \
@USE_ECORE_X_LIBS@ \
@USE_ECORE_IMF_LIBS@ \
-@USE_ECORE_EVAS_LIBS@
+@USE_ECORE_EVAS_LIBS@ \
+@USE_ECORE_WAYLAND_LIBS@
tests_ecore_ecore_suite_DEPENDENCIES = \
@USE_ECORE_INTERNAL_LIBS@ \
@USE_ECORE_AUDIO_INTERNAL_LIBS@ \
@@ -233,12 +235,17 @@ tests_ecore_ecore_suite_DEPENDENCIES = \
@USE_ECORE_FILE_INTERNAL_LIBS@ \
@USE_ECORE_X_INTERNAL_LIBS@ \
@USE_ECORE_IMF_INTERNAL_LIBS@ \
-@USE_ECORE_EVAS_INTERNAL_LIBS@
+@USE_ECORE_EVAS_INTERNAL_LIBS@ \
+@USE_ECORE_WAYLAND_INTERNAL_LIBS@
if HAVE_ECORE_AUDIO
tests_ecore_ecore_suite_SOURCES += tests/ecore/ecore_test_ecore_audio.c
endif
+if HAVE_ECORE_WAYLAND
+tests_ecore_ecore_suite_SOURCES += tests/ecore/ecore_test_ecore_wayland.c
+endif
+
endif
EXTRA_DIST += \
diff --git a/src/tests/ecore/ecore_suite.c b/src/tests/ecore/ecore_suite.c
index 5cee498..63d6596 100644
--- a/src/tests/ecore/ecore_suite.c
+++ b/src/tests/ecore/ecore_suite.c
@@ -30,6 +30,9 @@ static const Ecore_Test_Case etc[] = {
{ "Ecore_Evas", ecore_test_ecore_evas },
{ "Ecore_Animators", ecore_test_animator },
{ "Ecore_Test_Ccore_Thread_Eina_Thread_Queue",
ecore_test_ecore_thread_eina_thread_queue },
+#if HAVE_ECORE_WAYLAND
+ { "Ecore_Wayland", ecore_test_ecore_wayland },
+#endif
{ NULL, NULL }
};
diff --git a/src/tests/ecore/ecore_suite.h b/src/tests/ecore/ecore_suite.h
index 307ad0e..1487fb4 100644
--- a/src/tests/ecore/ecore_suite.h
+++ b/src/tests/ecore/ecore_suite.h
@@ -13,5 +13,6 @@ void ecore_test_timer(TCase *tc);
void ecore_test_ecore_evas(TCase *tc);
void ecore_test_animator(TCase *tc);
void ecore_test_ecore_thread_eina_thread_queue(TCase *tc);
+void ecore_test_ecore_wayland(TCase *tc);
#endif /* _ECORE_SUITE_H */
diff --git a/src/tests/ecore/ecore_test_ecore_wayland.c
b/src/tests/ecore/ecore_test_ecore_wayland.c
new file mode 100644
index 000..54aca3f
--- /dev/null
+++ b/src/tests/ecore/ecore_test_ecore_wayland.c
@@ -0,0 +1,37 @@
+#ifdef HAVE_CONFIG_H
+# include
+#endif
+
+#include
+#include
+
+#include
+
+#include "ecore_suite.h"
+
+#define MAX_ITER 15
+
+START_TEST(ecore_test_ecore_wl_init)
+{
+ int ret, i, j;
+
+ for (i = 1; i <= MAX_ITER; i++)
+ {
+ret = ecore_wl_init(NULL);
+fprintf(stderr, "Created %d ecore wayland instance.\n", i);
+fail_if(ret != i);
+ }
+
+ for (j = MAX_ITER - 1; j >= 0; j--)
+ {
+ret = ecore_wl_shutdown();
+fprintf(stderr, "Deleted %d ecore wayland instance.\n", MAX_ITER - j);
+fail_if(ret != j);
+ }
+}
+END_TEST
+
+void ecore_test_ecore_wayland(TCase *tc)
+{
+ tcase_add_test(tc, ecore_test_ecore_wl_init);
+}
--
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Mon, Sep 29, 2014 at 3:23 PM, Chris Michael wrote: > On 09/29/2014 09:17 AM, Carsten Haitzler (The Rasterman) wrote: >> On Mon, 29 Sep 2014 09:06:30 -0400 Chris Michael >> said: >>> On 09/29/2014 07:47 AM, Carsten Haitzler (The Rasterman) wrote: On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL said: > On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler > > wrote: >> >> On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL >> said: >>> >>> On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi >>> wrote: Em 28/09/2014 08:46, "Graham Gower" escreveu: > > I've attempted to build using the easy_efl.sh script and received > the > build error referenced in the subject (full build log follows > message). > > Is there a particular version of udev that is required now, but > hasn't > been put in the autoconf goo? I have udev 182 on a linux distro > without systemd. From http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f libudev 199 >>> >>> >>> Question as always how many distribution ship this library and how >>> many don't. Should we make 199 mandatory or should we just disable >>> the >>> code that require 199 (I guess it is related to wayland). >> >> >> since systemd and udev merged... a lot seem to have stopped updating >> udev >> at all and may b e on a multi-year-old udev (eg 2011). so our choices >> are >> to force an upgrade or work on these distros, or we need a way to >> emulate >> this udev call inside eeze iof udev is older. that means someone has >> to >> do the emulation code work there. > > > Do we really need to ? We could just disable Wayland support if udev > is to old, as I think that is the only think that rely on it. The > question is more what about other system than Linux. that makes for a poor eeze api that may or may not work based on a hidden udev version at compile time of eeze. >>> >>> Well, perhaps for the moment we can detect the udev version and just >>> #ifdef the internal eeze code to skip that function call. Fixes the >>> build problem while Not breaking code for people that have a sane udev >>> version. Thoughts ?? >> >> >> but downside is we have an eeze fn that now is broken for some and not >> others... and then when some try wayland things mysteriously fail.. we'll >> hit >> this sooner or later in one form or another. best get it sorted now while >> fresh. >> > > Ok. Makes sense :) > > So...what is the general "agreed" plan for sorting this ?? I've seen a > couple of thoughts on this thread, but no clear plan/path. I don't mind > doing the legwork if we all can agree on a path I am voting to put a big eina log warning in that #if for people who have an old version and make sure that when Wayland fail to setup that warning is correctly displayed. After that it is not our duty anymore. -- Cedric BAIL -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On 09/29/2014 10:03 AM, Cedric BAIL wrote: > On Mon, Sep 29, 2014 at 3:23 PM, Chris Michael wrote: >> On 09/29/2014 09:17 AM, Carsten Haitzler (The Rasterman) wrote: >>> On Mon, 29 Sep 2014 09:06:30 -0400 Chris Michael >>> said: On 09/29/2014 07:47 AM, Carsten Haitzler (The Rasterman) wrote: > On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL > said: >> On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler >> >> wrote: >>> >>> On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL >>> said: On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi wrote: > > Em 28/09/2014 08:46, "Graham Gower" > escreveu: >> >> I've attempted to build using the easy_efl.sh script and received >> the >> build error referenced in the subject (full build log follows >> message). >> >> Is there a particular version of udev that is required now, but >> hasn't >> been put in the autoconf goo? I have udev 182 on a linux distro >> without systemd. > > > From > > http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f > > libudev 199 Question as always how many distribution ship this library and how many don't. Should we make 199 mandatory or should we just disable the code that require 199 (I guess it is related to wayland). >>> >>> >>> since systemd and udev merged... a lot seem to have stopped updating >>> udev >>> at all and may b e on a multi-year-old udev (eg 2011). so our choices >>> are >>> to force an upgrade or work on these distros, or we need a way to >>> emulate >>> this udev call inside eeze iof udev is older. that means someone has >>> to >>> do the emulation code work there. >> >> >> Do we really need to ? We could just disable Wayland support if udev >> is to old, as I think that is the only think that rely on it. The >> question is more what about other system than Linux. > > > that makes for a poor eeze api that may or may not work based on a > hidden > udev version at compile time of eeze. > Well, perhaps for the moment we can detect the udev version and just #ifdef the internal eeze code to skip that function call. Fixes the build problem while Not breaking code for people that have a sane udev version. Thoughts ?? >>> >>> >>> but downside is we have an eeze fn that now is broken for some and not >>> others... and then when some try wayland things mysteriously fail.. we'll >>> hit >>> this sooner or later in one form or another. best get it sorted now while >>> fresh. >>> >> >> Ok. Makes sense :) >> >> So...what is the general "agreed" plan for sorting this ?? I've seen a >> couple of thoughts on this thread, but no clear plan/path. I don't mind >> doing the legwork if we all can agree on a path > > I am voting to put a big eina log warning in that #if for people who > have an old version and make sure that when Wayland fail to setup that > warning is correctly displayed. After that it is not our duty anymore. > Well, the wayland stuff won't fail without it. It's only used for setting the output backlight brightness...so if anything, they won't have backlight control, but that's about it. Everything else will be fine. dh -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
2014-09-29 14:23 GMT+01:00 Chris Michael : > On 09/29/2014 09:17 AM, Carsten Haitzler (The Rasterman) wrote: > > On Mon, 29 Sep 2014 09:06:30 -0400 Chris Michael > said: > > > >> On 09/29/2014 07:47 AM, Carsten Haitzler (The Rasterman) wrote: > >>> On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL > said: > >>> > On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler < > ras...@rasterman.com> > wrote: > > On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL > said: > >> On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi > >> wrote: > >>> Em 28/09/2014 08:46, "Graham Gower" > escreveu: > I've attempted to build using the easy_efl.sh script and received > the > build error referenced in the subject (full build log follows > message). > > Is there a particular version of udev that is required now, but > hasn't > been put in the autoconf goo? I have udev 182 on a linux distro > without systemd. > >>> > >>> From > >>> > http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f > >>> > >>> libudev 199 > >> > >> Question as always how many distribution ship this library and how > >> many don't. Should we make 199 mandatory or should we just disable > the > >> code that require 199 (I guess it is related to wayland). > > > > since systemd and udev merged... a lot seem to have stopped updating > udev > > at all and may b e on a multi-year-old udev (eg 2011). so our > choices are > > to force an upgrade or work on these distros, or we need a way to > emulate > > this udev call inside eeze iof udev is older. that means someone has > to > > do the emulation code work there. > > Do we really need to ? We could just disable Wayland support if udev > is to old, as I think that is the only think that rely on it. The > question is more what about other system than Linux. > >>> > >>> that makes for a poor eeze api that may or may not work based on a > hidden > >>> udev version at compile time of eeze. > >>> > >> > >> Well, perhaps for the moment we can detect the udev version and just > >> #ifdef the internal eeze code to skip that function call. Fixes the > >> build problem while Not breaking code for people that have a sane udev > >> version. Thoughts ?? > > > > but downside is we have an eeze fn that now is broken for some and not > > others... and then when some try wayland things mysteriously fail.. > we'll hit > > this sooner or later in one form or another. best get it sorted now > while fresh. > > > > Ok. Makes sense :) > > So...what is the general "agreed" plan for sorting this ?? I've seen a > couple of thoughts on this thread, but no clear plan/path. I don't mind > doing the legwork if we all can agree on a path > IMHO best approach would be to create an abstracted library that doesn't access libudev or anything directly, but rather provides abstracted controls for stuff like backlight, disks etc. - which could potentially be integrated with any OS or backend, including udev, devd, etc.; after that, deprecate Eeze. It would be the cleanest solution, but is also more of a long term solution. So for the time being, just ifdef it out and keep a ticket open for solution. If there's anything we do *not* need, it's stupid thin wrappers. > > dh > > > > -- > Slashdot TV. Videos for Nerds. Stuff that Matters. > > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > D5 -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On 29/09/14 15:03, Cedric BAIL wrote: > On Mon, Sep 29, 2014 at 3:23 PM, Chris Michael wrote: >> On 09/29/2014 09:17 AM, Carsten Haitzler (The Rasterman) wrote: >>> On Mon, 29 Sep 2014 09:06:30 -0400 Chris Michael >>> said: On 09/29/2014 07:47 AM, Carsten Haitzler (The Rasterman) wrote: > On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL > said: >> On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler >> >> wrote: >>> >>> On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL >>> said: On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi wrote: > > Em 28/09/2014 08:46, "Graham Gower" > escreveu: >> >> I've attempted to build using the easy_efl.sh script and received >> the >> build error referenced in the subject (full build log follows >> message). >> >> Is there a particular version of udev that is required now, but >> hasn't >> been put in the autoconf goo? I have udev 182 on a linux distro >> without systemd. > > > From > > http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f > > libudev 199 Question as always how many distribution ship this library and how many don't. Should we make 199 mandatory or should we just disable the code that require 199 (I guess it is related to wayland). >>> >>> >>> since systemd and udev merged... a lot seem to have stopped updating >>> udev >>> at all and may b e on a multi-year-old udev (eg 2011). so our choices >>> are >>> to force an upgrade or work on these distros, or we need a way to >>> emulate >>> this udev call inside eeze iof udev is older. that means someone has >>> to >>> do the emulation code work there. >> >> >> Do we really need to ? We could just disable Wayland support if udev >> is to old, as I think that is the only think that rely on it. The >> question is more what about other system than Linux. > > > that makes for a poor eeze api that may or may not work based on a > hidden > udev version at compile time of eeze. > Well, perhaps for the moment we can detect the udev version and just #ifdef the internal eeze code to skip that function call. Fixes the build problem while Not breaking code for people that have a sane udev version. Thoughts ?? >>> >>> >>> but downside is we have an eeze fn that now is broken for some and not >>> others... and then when some try wayland things mysteriously fail.. we'll >>> hit >>> this sooner or later in one form or another. best get it sorted now while >>> fresh. >>> >> >> Ok. Makes sense :) >> >> So...what is the general "agreed" plan for sorting this ?? I've seen a >> couple of thoughts on this thread, but no clear plan/path. I don't mind >> doing the legwork if we all can agree on a path > > I am voting to put a big eina log warning in that #if for people who > have an old version and make sure that when Wayland fail to setup that > warning is correctly displayed. After that it is not our duty anymore. > So what you are doing is saying: Hey guys, we don't support your distro. I mean, we kinda say we do, because you can compile, but actually in reality things will fail in the background without you knowing because no one really looks at the stdout of gui applications. -- Tom. -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Mon, Sep 29, 2014 at 4:08 PM, Chris Michael wrote: > On 09/29/2014 10:03 AM, Cedric BAIL wrote: >> On Mon, Sep 29, 2014 at 3:23 PM, Chris Michael >> wrote: >>> On 09/29/2014 09:17 AM, Carsten Haitzler (The Rasterman) wrote: On Mon, 29 Sep 2014 09:06:30 -0400 Chris Michael said: > On 09/29/2014 07:47 AM, Carsten Haitzler (The Rasterman) wrote: >> On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL >> said: >>> On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler >>> >>> wrote: On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL said: > On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi > wrote: >> Em 28/09/2014 08:46, "Graham Gower" >> escreveu: >>> >>> I've attempted to build using the easy_efl.sh script and received >>> the >>> build error referenced in the subject (full build log follows >>> message). >>> >>> Is there a particular version of udev that is required now, but >>> hasn't >>> been put in the autoconf goo? I have udev 182 on a linux distro >>> without systemd. >> >> >> >> From >> >> >> http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f >> >> libudev 199 > > > > Question as always how many distribution ship this library and how > many don't. Should we make 199 mandatory or should we just disable > the > code that require 199 (I guess it is related to wayland). since systemd and udev merged... a lot seem to have stopped updating udev at all and may b e on a multi-year-old udev (eg 2011). so our choices are to force an upgrade or work on these distros, or we need a way to emulate this udev call inside eeze iof udev is older. that means someone has to do the emulation code work there. >>> >>> >>> >>> Do we really need to ? We could just disable Wayland support if udev >>> is to old, as I think that is the only think that rely on it. The >>> question is more what about other system than Linux. >> >> >> >> that makes for a poor eeze api that may or may not work based on a >> hidden >> udev version at compile time of eeze. >> > > Well, perhaps for the moment we can detect the udev version and just > #ifdef the internal eeze code to skip that function call. Fixes the > build problem while Not breaking code for people that have a sane udev > version. Thoughts ?? but downside is we have an eeze fn that now is broken for some and not others... and then when some try wayland things mysteriously fail.. we'll hit this sooner or later in one form or another. best get it sorted now while fresh. >>> >>> Ok. Makes sense :) >>> >>> So...what is the general "agreed" plan for sorting this ?? I've seen a >>> couple of thoughts on this thread, but no clear plan/path. I don't mind >>> doing the legwork if we all can agree on a path >> >> I am voting to put a big eina log warning in that #if for people who >> have an old version and make sure that when Wayland fail to setup that >> warning is correctly displayed. After that it is not our duty anymore. > > Well, the wayland stuff won't fail without it. It's only used for setting > the output backlight brightness...so if anything, they won't have backlight > control, but that's about it. Everything else will be fine. Really, that's just it ? Then make it optional is a no brainer in my opinion. -- Cedric BAIL -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Mon, Sep 29, 2014 at 4:13 PM, Daniel Kolesa wrote: > 2014-09-29 14:23 GMT+01:00 Chris Michael : >> On 09/29/2014 09:17 AM, Carsten Haitzler (The Rasterman) wrote: >> > On Mon, 29 Sep 2014 09:06:30 -0400 Chris Michael >> said: >> >> On 09/29/2014 07:47 AM, Carsten Haitzler (The Rasterman) wrote: >> >>> On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL >> said: >> >>> >> On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler < >> ras...@rasterman.com> >> wrote: >> > On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL >> said: >> >> On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi >> >> wrote: >> >>> Em 28/09/2014 08:46, "Graham Gower" >> escreveu: >> I've attempted to build using the easy_efl.sh script and received >> the >> build error referenced in the subject (full build log follows >> message). >> >> Is there a particular version of udev that is required now, but >> hasn't >> been put in the autoconf goo? I have udev 182 on a linux distro >> without systemd. >> >>> >> >>> From >> >>> >> http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f >> >>> >> >>> libudev 199 >> >> >> >> Question as always how many distribution ship this library and how >> >> many don't. Should we make 199 mandatory or should we just disable >> the >> >> code that require 199 (I guess it is related to wayland). >> > >> > since systemd and udev merged... a lot seem to have stopped updating >> udev >> > at all and may b e on a multi-year-old udev (eg 2011). so our >> choices are >> > to force an upgrade or work on these distros, or we need a way to >> emulate >> > this udev call inside eeze iof udev is older. that means someone has >> to >> > do the emulation code work there. >> >> Do we really need to ? We could just disable Wayland support if udev >> is to old, as I think that is the only think that rely on it. The >> question is more what about other system than Linux. >> >>> >> >>> that makes for a poor eeze api that may or may not work based on a >> hidden >> >>> udev version at compile time of eeze. >> >>> >> >> >> >> Well, perhaps for the moment we can detect the udev version and just >> >> #ifdef the internal eeze code to skip that function call. Fixes the >> >> build problem while Not breaking code for people that have a sane udev >> >> version. Thoughts ?? >> > >> > but downside is we have an eeze fn that now is broken for some and not >> > others... and then when some try wayland things mysteriously fail.. >> we'll hit >> > this sooner or later in one form or another. best get it sorted now >> while fresh. >> > >> >> Ok. Makes sense :) >> >> So...what is the general "agreed" plan for sorting this ?? I've seen a >> couple of thoughts on this thread, but no clear plan/path. I don't mind >> doing the legwork if we all can agree on a path >> > > IMHO best approach would be to create an abstracted library that doesn't > access libudev or anything directly, but rather provides abstracted > controls for stuff like backlight, disks etc. - which could potentially be > integrated with any OS or backend, including udev, devd, etc.; after that, > deprecate Eeze. It would be the cleanest solution, but is also more of a > long term solution. So for the time being, just ifdef it out and keep a > ticket open for solution. If there's anything we do *not* need, it's stupid > thin wrappers. Of course, a better library would be the best solution, sadly no time nor anyone interested at this stage. I am guessing the one that would have to do it will be someone that use a BSD all day where those feature are missing and will start to do it because of that. -- Cedric BAIL -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On 09/29/2014 10:42 AM, Cedric BAIL wrote: > On Mon, Sep 29, 2014 at 4:08 PM, Chris Michael wrote: >> On 09/29/2014 10:03 AM, Cedric BAIL wrote: >>> On Mon, Sep 29, 2014 at 3:23 PM, Chris Michael >>> wrote: On 09/29/2014 09:17 AM, Carsten Haitzler (The Rasterman) wrote: > On Mon, 29 Sep 2014 09:06:30 -0400 Chris Michael > > said: >> On 09/29/2014 07:47 AM, Carsten Haitzler (The Rasterman) wrote: >>> On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL >>> said: On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler wrote: > On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL > said: >> On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi >> wrote: >>> Em 28/09/2014 08:46, "Graham Gower" >>> escreveu: I've attempted to build using the easy_efl.sh script and received the build error referenced in the subject (full build log follows message). Is there a particular version of udev that is required now, but hasn't been put in the autoconf goo? I have udev 182 on a linux distro without systemd. >>> >>> >>> >>> From >>> >>> >>> http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f >>> >>> libudev 199 >> >> >> >> Question as always how many distribution ship this library and how >> many don't. Should we make 199 mandatory or should we just disable >> the >> code that require 199 (I guess it is related to wayland). > > > > since systemd and udev merged... a lot seem to have stopped updating > udev > at all and may b e on a multi-year-old udev (eg 2011). so our > choices > are > to force an upgrade or work on these distros, or we need a way to > emulate > this udev call inside eeze iof udev is older. that means someone has > to > do the emulation code work there. Do we really need to ? We could just disable Wayland support if udev is to old, as I think that is the only think that rely on it. The question is more what about other system than Linux. >>> >>> >>> >>> that makes for a poor eeze api that may or may not work based on a >>> hidden >>> udev version at compile time of eeze. >>> >> >> Well, perhaps for the moment we can detect the udev version and just >> #ifdef the internal eeze code to skip that function call. Fixes the >> build problem while Not breaking code for people that have a sane udev >> version. Thoughts ?? > > but downside is we have an eeze fn that now is broken for some and not > others... and then when some try wayland things mysteriously fail.. > we'll > hit > this sooner or later in one form or another. best get it sorted now > while > fresh. Ok. Makes sense :) So...what is the general "agreed" plan for sorting this ?? I've seen a couple of thoughts on this thread, but no clear plan/path. I don't mind doing the legwork if we all can agree on a path >>> >>> I am voting to put a big eina log warning in that #if for people who >>> have an old version and make sure that when Wayland fail to setup that >>> warning is correctly displayed. After that it is not our duty anymore. >> >> Well, the wayland stuff won't fail without it. It's only used for setting >> the output backlight brightness...so if anything, they won't have backlight >> control, but that's about it. Everything else will be fine. > > Really, that's just it ? Then make it optional is a no brainer in my opinion. > That is it :) We originally coded the backlight to work directly on the backlight "fd" (raw read/write), however a certain german ;) did not like that approach and opted for udev/eeze approach (which was fine in it's own right)...but in order to set the backlight brightness via udev, we needed that function. Ok, so if nobody has any objections ??? , I'll do some modifications today and #ifdef out that function call with a udev version check For those that have ancient udev versions, they won't be able to set backlight levels (when running in drm)...but that's all that will break. dh -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
2014-09-29 15:43 GMT+01:00 Cedric BAIL : > On Mon, Sep 29, 2014 at 4:13 PM, Daniel Kolesa wrote: > > 2014-09-29 14:23 GMT+01:00 Chris Michael : > >> On 09/29/2014 09:17 AM, Carsten Haitzler (The Rasterman) wrote: > >> > On Mon, 29 Sep 2014 09:06:30 -0400 Chris Michael < > devilho...@comcast.net> > >> said: > >> >> On 09/29/2014 07:47 AM, Carsten Haitzler (The Rasterman) wrote: > >> >>> On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL > > >> said: > >> >>> > >> On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler < > >> ras...@rasterman.com> > >> wrote: > >> > On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL < > cedric.b...@free.fr> > >> said: > >> >> On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi > >> >> wrote: > >> >>> Em 28/09/2014 08:46, "Graham Gower" > >> escreveu: > >> I've attempted to build using the easy_efl.sh script and > received > >> the > >> build error referenced in the subject (full build log follows > >> message). > >> > >> Is there a particular version of udev that is required now, but > >> hasn't > >> been put in the autoconf goo? I have udev 182 on a linux distro > >> without systemd. > >> >>> > >> >>> From > >> >>> > >> > http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f > >> >>> > >> >>> libudev 199 > >> >> > >> >> Question as always how many distribution ship this library and > how > >> >> many don't. Should we make 199 mandatory or should we just > disable > >> the > >> >> code that require 199 (I guess it is related to wayland). > >> > > >> > since systemd and udev merged... a lot seem to have stopped > updating > >> udev > >> > at all and may b e on a multi-year-old udev (eg 2011). so our > >> choices are > >> > to force an upgrade or work on these distros, or we need a way to > >> emulate > >> > this udev call inside eeze iof udev is older. that means someone > has > >> to > >> > do the emulation code work there. > >> > >> Do we really need to ? We could just disable Wayland support if > udev > >> is to old, as I think that is the only think that rely on it. The > >> question is more what about other system than Linux. > >> >>> > >> >>> that makes for a poor eeze api that may or may not work based on a > >> hidden > >> >>> udev version at compile time of eeze. > >> >>> > >> >> > >> >> Well, perhaps for the moment we can detect the udev version and just > >> >> #ifdef the internal eeze code to skip that function call. Fixes the > >> >> build problem while Not breaking code for people that have a sane > udev > >> >> version. Thoughts ?? > >> > > >> > but downside is we have an eeze fn that now is broken for some and not > >> > others... and then when some try wayland things mysteriously fail.. > >> we'll hit > >> > this sooner or later in one form or another. best get it sorted now > >> while fresh. > >> > > >> > >> Ok. Makes sense :) > >> > >> So...what is the general "agreed" plan for sorting this ?? I've seen a > >> couple of thoughts on this thread, but no clear plan/path. I don't mind > >> doing the legwork if we all can agree on a path > >> > > > > IMHO best approach would be to create an abstracted library that doesn't > > access libudev or anything directly, but rather provides abstracted > > controls for stuff like backlight, disks etc. - which could potentially > be > > integrated with any OS or backend, including udev, devd, etc.; after > that, > > deprecate Eeze. It would be the cleanest solution, but is also more of a > > long term solution. So for the time being, just ifdef it out and keep a > > ticket open for solution. If there's anything we do *not* need, it's > stupid > > thin wrappers. > > Of course, a better library would be the best solution, sadly no time > nor anyone interested at this stage. I am guessing the one that would > have to do it will be someone that use a BSD all day where those > feature are missing and will start to do it because of that. > It's not just about BSD, it's also about having a better abstraction on Linux and elsewhere. Thin wrappers suck and are completely useless; might as well use libudev API directly, there's no point in having Eeze. But having a properly abstracted library might provide decent support for different backends, including Linux/udev, Linux/mdev, FreeBSD/devd, whatever OS X uses, etc... and ultimately, make for a better cross platform experience. After all, the purpose of libraries is to abstract away things, not to wrap around them. > -- > Cedric BAIL > > > -- > Slashdot TV. Videos for Nerds. Stuff that Matters. > > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lis
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On 29/09/14 15:46, Chris Michael wrote: > On 09/29/2014 10:42 AM, Cedric BAIL wrote: >> On Mon, Sep 29, 2014 at 4:08 PM, Chris Michael >> wrote: >>> On 09/29/2014 10:03 AM, Cedric BAIL wrote: On Mon, Sep 29, 2014 at 3:23 PM, Chris Michael wrote: > On 09/29/2014 09:17 AM, Carsten Haitzler (The Rasterman) wrote: >> On Mon, 29 Sep 2014 09:06:30 -0400 Chris Michael >> >> said: >>> On 09/29/2014 07:47 AM, Carsten Haitzler (The Rasterman) wrote: On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL said: > On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler > > wrote: >> On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL >> said: >>> On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi >>> wrote: Em 28/09/2014 08:46, "Graham Gower" escreveu: > > I've attempted to build using the easy_efl.sh script and received > the > build error referenced in the subject (full build log follows > message). > > Is there a particular version of udev that is required now, but > hasn't > been put in the autoconf goo? I have udev 182 on a linux distro > without systemd. From http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f libudev 199 >>> >>> >>> >>> Question as always how many distribution ship this library and how >>> many don't. Should we make 199 mandatory or should we just disable >>> the >>> code that require 199 (I guess it is related to wayland). >> >> >> >> since systemd and udev merged... a lot seem to have stopped updating >> udev >> at all and may b e on a multi-year-old udev (eg 2011). so our >> choices >> are >> to force an upgrade or work on these distros, or we need a way to >> emulate >> this udev call inside eeze iof udev is older. that means someone has >> to >> do the emulation code work there. > > > > Do we really need to ? We could just disable Wayland support if udev > is to old, as I think that is the only think that rely on it. The > question is more what about other system than Linux. that makes for a poor eeze api that may or may not work based on a hidden udev version at compile time of eeze. >>> >>> Well, perhaps for the moment we can detect the udev version and just >>> #ifdef the internal eeze code to skip that function call. Fixes the >>> build problem while Not breaking code for people that have a sane udev >>> version. Thoughts ?? >> >> but downside is we have an eeze fn that now is broken for some and not >> others... and then when some try wayland things mysteriously fail.. >> we'll >> hit >> this sooner or later in one form or another. best get it sorted now >> while >> fresh. > > Ok. Makes sense :) > > So...what is the general "agreed" plan for sorting this ?? I've seen a > couple of thoughts on this thread, but no clear plan/path. I don't mind > doing the legwork if we all can agree on a path I am voting to put a big eina log warning in that #if for people who have an old version and make sure that when Wayland fail to setup that warning is correctly displayed. After that it is not our duty anymore. >>> >>> Well, the wayland stuff won't fail without it. It's only used for setting >>> the output backlight brightness...so if anything, they won't have backlight >>> control, but that's about it. Everything else will be fine. >> >> Really, that's just it ? Then make it optional is a no brainer in my opinion. >> > > That is it :) We originally coded the backlight to work directly on the > backlight "fd" (raw read/write), however a certain german ;) did not > like that approach and opted for udev/eeze approach (which was fine in > it's own right)...but in order to set the backlight brightness via udev, > we needed that function. > > Ok, so if nobody has any objections ??? , I'll do some modifications > today and #ifdef out that function call with a udev version check > > For those that have ancient udev versions, they won't be able to set > backlight levels (when running in drm)...but that's all that will break. Again, an horrible precedence and a passive aggressive way of saying "we no longer support all of you guys who haven't jumped on the systemd band-wagon". -- Tom. -- Slashdot TV. Videos for Nerds. Stuff that Matters. http:/
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
> Date: Mon, 29 Sep 2014 15:54:44 +0100 > From: tom.haco...@samsung.com > To: enlightenment-devel@lists.sourceforge.net > Subject: Re: [E-devel] libeeze.so: undefined reference to > `udev_device_set_sysattr_value' > > On 29/09/14 15:46, Chris Michael wrote: >> On 09/29/2014 10:42 AM, Cedric BAIL wrote: >>> On Mon, Sep 29, 2014 at 4:08 PM, Chris Michael >>> wrote: On 09/29/2014 10:03 AM, Cedric BAIL wrote: > On Mon, Sep 29, 2014 at 3:23 PM, Chris Michael > wrote: >> On 09/29/2014 09:17 AM, Carsten Haitzler (The Rasterman) wrote: >>> On Mon, 29 Sep 2014 09:06:30 -0400 Chris Michael >>> >>> said: On 09/29/2014 07:47 AM, Carsten Haitzler (The Rasterman) wrote: > On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL > said: >> On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler >> >> wrote: >>> On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL >>> said: On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi wrote: > Em 28/09/2014 08:46, "Graham Gower" > escreveu: >> >> I've attempted to build using the easy_efl.sh script and received >> the >> build error referenced in the subject (full build log follows >> message). >> >> Is there a particular version of udev that is required now, but >> hasn't >> been put in the autoconf goo? I have udev 182 on a linux distro >> without systemd. > > > > From > > > http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f > > libudev 199 Question as always how many distribution ship this library and how many don't. Should we make 199 mandatory or should we just disable the code that require 199 (I guess it is related to wayland). >>> >>> >>> >>> since systemd and udev merged... a lot seem to have stopped updating >>> udev >>> at all and may b e on a multi-year-old udev (eg 2011). so our >>> choices >>> are >>> to force an upgrade or work on these distros, or we need a way to >>> emulate >>> this udev call inside eeze iof udev is older. that means someone has >>> to >>> do the emulation code work there. >> >> >> >> Do we really need to ? We could just disable Wayland support if udev >> is to old, as I think that is the only think that rely on it. The >> question is more what about other system than Linux. > > > > that makes for a poor eeze api that may or may not work based on a > hidden > udev version at compile time of eeze. > Well, perhaps for the moment we can detect the udev version and just #ifdef the internal eeze code to skip that function call. Fixes the build problem while Not breaking code for people that have a sane udev version. Thoughts ?? >>> >>> but downside is we have an eeze fn that now is broken for some and not >>> others... and then when some try wayland things mysteriously fail.. >>> we'll >>> hit >>> this sooner or later in one form or another. best get it sorted now >>> while >>> fresh. >> >> Ok. Makes sense :) >> >> So...what is the general "agreed" plan for sorting this ?? I've seen a >> couple of thoughts on this thread, but no clear plan/path. I don't mind >> doing the legwork if we all can agree on a path > > I am voting to put a big eina log warning in that #if for people who > have an old version and make sure that when Wayland fail to setup that > warning is correctly displayed. After that it is not our duty anymore. Well, the wayland stuff won't fail without it. It's only used for setting the output backlight brightness...so if anything, they won't have backlight control, but that's about it. Everything else will be fine. >>> >>> Really, that's just it ? Then make it optional is a no brainer in my >>> opinion. >>> >> >> That is it :) We originally coded the backlight to work directly on the >> backlight "fd" (raw read/write), however a certain german ;) did not >> like that approach and opted for udev/eeze approach (which was fine in >> it's own right)...but in order to set the backlight brightness via udev, >> we needed that function. >> >> Ok, so if nobody has any objections ??? , I'll do some modifications >> today and #ifdef out that function call with a udev version check >> >> For those that have ancient udev versions, they won't be able to set
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On 30 September 2014 00:42, Doug Newgard wrote: > > udev works fine without systemd. Those distros that are refusing to update > past 184 are either ones that use ancient software anyway or they are just > taking a very childish stance and refusing to even build it now. I think you'll find the version of udev I have (182) really isn't that old. -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Mon, Sep 29, 2014, Doug Newgard wrote: > > > > > Date: Mon, 29 Sep 2014 15:54:44 +0100 > > From: tom.haco...@samsung.com > > To: enlightenment-devel@lists.sourceforge.net > > Subject: Re: [E-devel] libeeze.so: undefined reference to > > `udev_device_set_sysattr_value' [...] snip > > Again, an horrible precedence and a passive aggressive way of saying "we > > no longer support all of you guys who haven't jumped on the systemd > > band-wagon". > > udev works fine without systemd. Those distros that are refusing to update > past 184 are either ones that use ancient software anyway or they are just > taking a very childish stance and refusing to even build it now. Distros tend to not move past 184 (or 182 here) precisely because it's annoying to get building and working. It's not simply because they're being childish. But anyway, the point is moot. Have a look at http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html Quoting: > Also note that at that point we intend to move udev onto kdbus as > transport, and get rid of the userspace-to-userspace netlink-based > tranport udev used so far. Unless the systemd-haters prepare another > kdbus userspace until then this will effectively also mean that we will > not support non-systemd systems with udev anymore starting at that > point. Gentoo folks, this is your wakeup call. IOW, even if it were all working nicely right now, that won't last. For future versions this raises the issue of chosing what is being depended upon. As far as I'm concerned, I don't really care but thought that you should remember that even in the best case for compatibility, this won't last long. Regards, Adrien Nader -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
> Date: Tue, 30 Sep 2014 00:50:23 +0930 > From: graham.go...@gmail.com > To: enlightenment-devel@lists.sourceforge.net > Subject: Re: [E-devel] libeeze.so: undefined reference to > `udev_device_set_sysattr_value' > > On 30 September 2014 00:42, Doug Newgard wrote: >> >> udev works fine without systemd. Those distros that are refusing to update >> past 184 are either ones that use ancient software anyway or they are just >> taking a very childish stance and refusing to even build it now. > > I think you'll find the version of udev I have (182) really isn't that old. Two and a half years and over 30 releases ago is pretty out of date. > > -- > Slashdot TV. Videos for Nerds. Stuff that Matters. > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
> Date: Mon, 29 Sep 2014 17:29:39 +0200 > From: adr...@notk.org > To: enlightenment-devel@lists.sourceforge.net > Subject: Re: [E-devel] libeeze.so: undefined reference to > `udev_device_set_sysattr_value' > > On Mon, Sep 29, 2014, Doug Newgard wrote: >> >> >> >>> Date: Mon, 29 Sep 2014 15:54:44 +0100 >>> From: tom.haco...@samsung.com >>> To: enlightenment-devel@lists.sourceforge.net >>> Subject: Re: [E-devel] libeeze.so: undefined reference to >>> `udev_device_set_sysattr_value' > [...] snip >>> Again, an horrible precedence and a passive aggressive way of saying "we >>> no longer support all of you guys who haven't jumped on the systemd >>> band-wagon". >> >> udev works fine without systemd. Those distros that are refusing to update >> past 184 are either ones that use ancient software anyway or they are just >> taking a very childish stance and refusing to even build it now. > > Distros tend to not move past 184 (or 182 here) precisely because it's > annoying to get building and working. It's not simply because they're > being childish. systemd/udev is actually pretty straight forward to build. Those distros that refuse to update udev because they have to build it as part of systemd are being childish, nothing more. Refusing to update an important part of your system simply because you don't want to deal with it can be called nothing less. > > But anyway, the point is moot. Have a look at > http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html > > Quoting: >> Also note that at that point we intend to move udev onto kdbus as >> transport, and get rid of the userspace-to-userspace netlink-based >> tranport udev used so far. Unless the systemd-haters prepare another >> kdbus userspace until then this will effectively also mean that we will >> not support non-systemd systems with udev anymore starting at that >> point. Gentoo folks, this is your wakeup call. > > IOW, even if it were all working nicely right now, that won't last. For > future versions this raises the issue of chosing what is being depended > upon. As far as I'm concerned, I don't really care but thought that you > should remember that even in the best case for compatibility, this won't > last long. So they're going to make it use a new feature of the kernel. Nothing wrong with that. Even then, those distros at 182 are STILL 34+ versions out of date. > > Regards, > Adrien Nader > > -- > Slashdot TV. Videos for Nerds. Stuff that Matters. > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: eo-cxx: s/eo_add/eo_add_ref/ in efl::eo::inherit.
savio pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=b551593087a68a63150c17403e10affe4d2c4a3b
commit b551593087a68a63150c17403e10affe4d2c4a3b
Author: Savio Sena
Date: Mon Sep 29 16:05:14 2014 +
eo-cxx: s/eo_add/eo_add_ref/ in efl::eo::inherit.
---
src/bindings/eo_cxx/eo_inherit.hh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/bindings/eo_cxx/eo_inherit.hh
b/src/bindings/eo_cxx/eo_inherit.hh
index 0d38539..d81c70f 100644
--- a/src/bindings/eo_cxx/eo_inherit.hh
+++ b/src/bindings/eo_cxx/eo_inherit.hh
@@ -77,7 +77,7 @@ struct inherit
{
typedef std::tuple::type...>
tuple_type;
_eo_cls = detail::create_class
(eina::make_index_sequence());
- _eo_raw = eo_add
+ _eo_raw = eo_add_ref
(_eo_cls, NULL,
detail::inherit_constructor
--
[EGIT] [core/efl] master 01/02: eina: Eina_List - remove obvious if() check.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=d25747c7f86a548256a210654f1c46cb5672ccc0
commit d25747c7f86a548256a210654f1c46cb5672ccc0
Author: Amitesh Singh
Date: Mon Sep 29 19:45:49 2014 +0200
eina: Eina_List - remove obvious if() check.
Summary:
if (cmp == 0) - in false branch, cmp can not be equal to 0
else if (cmp < 0) - in false branch, cmp is atleast 1.
else if (cmp > 0) - it is abvious that cmp > 0.
Reviewers: cedric, seoz, raster
Subscribers: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D1502
Signed-off-by: Cedric BAIL
---
src/lib/eina/eina_list.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/lib/eina/eina_list.c b/src/lib/eina/eina_list.c
index 527a141..e1088b0 100644
--- a/src/lib/eina/eina_list.c
+++ b/src/lib/eina/eina_list.c
@@ -1429,7 +1429,7 @@ eina_list_search_sorted_near_list(const Eina_List *list,
break;
else if (cmp < 0)
inf = cur + 1;
-else if (cmp > 0)
+else
{
if (cur > 0)
sup = cur - 1;
--
[EGIT] [core/efl] master 02/02: eina: Eina_Inlist - remove obvious if() check.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=be7a64b6e35b9dab824242f2144519d013b4df94
commit be7a64b6e35b9dab824242f2144519d013b4df94
Author: Amitesh Singh
Date: Mon Sep 29 19:47:09 2014 +0200
eina: Eina_Inlist - remove obvious if() check.
Reviewers: seoz, raster, cedric
Reviewed By: cedric
Subscribers: cedric, seoz
Differential Revision: https://phab.enlightenment.org/D1503
---
src/lib/eina/eina_inlist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/lib/eina/eina_inlist.c b/src/lib/eina/eina_inlist.c
index 9b73ef4..7496c51 100644
--- a/src/lib/eina/eina_inlist.c
+++ b/src/lib/eina/eina_inlist.c
@@ -647,7 +647,7 @@ eina_inlist_sorted_insert(Eina_Inlist *list,
break ;
else if (cmp < 0)
inf = cur + 1;
-else if (cmp > 0)
+else
{
if (cur > 0)
sup = cur - 1;
--
[EGIT] [core/efl] master 01/01: [cxx] Reenable C++ by default as all outstanding fixes are applied
felipealmeida pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=f9e862e52e7f17cd49431fbfb78667e4a1fba3e5
commit f9e862e52e7f17cd49431fbfb78667e4a1fba3e5
Author: Felipe Magno de Almeida
Date: Mon Sep 29 18:00:15 2014 -0300
[cxx] Reenable C++ by default as all outstanding fixes are applied
The C++ binding was disabled because of changes in Eolian. Since we're
already applied fixes on the C++ binding for the changes in the Eolian
API the C++ binding is to be enabled by-default.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 411b946..990fa07 100644
--- a/configure.ac
+++ b/configure.ac
@@ -979,7 +979,7 @@ EFL_LIB_START([Eina_Cxx])
EFL_CXX_COMPILE_STDCXX_11([ext])
AC_ARG_ENABLE([cxx-bindings],
[AS_HELP_STRING([--enable-cxx-bindings],[enable C++11 bindings.
@<:@default=disabledd@:>@])],
- [want_cxx11="${enableval}"], [want_cxx11="no"])
+ [want_cxx11="${enableval}"], [want_cxx11="yes"])
if test "x${HAVE_CXX11}" = "x1" -a "x${want_cxx11}" = "xyes"; then
have_cxx11="yes"
--
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Mon, 29 Sep 2014 10:24:53 -0500 Doug Newgard wrote: > > > > > Date: Tue, 30 Sep 2014 00:50:23 +0930 > > From: graham.go...@gmail.com > > To: enlightenment-devel@lists.sourceforge.net > > Subject: Re: [E-devel] libeeze.so: undefined reference to > > `udev_device_set_sysattr_value' > > > > On 30 September 2014 00:42, Doug Newgard > > wrote: > >> > >> udev works fine without systemd. Those distros that are refusing > >> to update past 184 are either ones that use ancient software > >> anyway or they are just taking a very childish stance and refusing > >> to even build it now. > > > > I think you'll find the version of udev I have (182) really isn't > > that old. > > Two and a half years and over 30 releases ago is pretty out of date. We prefer the term "stable". :-P -- 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 -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Tue, 30 Sep 2014 09:01:58 +1000 David Seikel said: > On Mon, 29 Sep 2014 10:24:53 -0500 Doug Newgard > wrote: > > > > > > > > > > Date: Tue, 30 Sep 2014 00:50:23 +0930 > > > From: graham.go...@gmail.com > > > To: enlightenment-devel@lists.sourceforge.net > > > Subject: Re: [E-devel] libeeze.so: undefined reference to > > > `udev_device_set_sysattr_value' > > > > > > On 30 September 2014 00:42, Doug Newgard > > > wrote: > > >> > > >> udev works fine without systemd. Those distros that are refusing > > >> to update past 184 are either ones that use ancient software > > >> anyway or they are just taking a very childish stance and refusing > > >> to even build it now. > > > > > > I think you'll find the version of udev I have (182) really isn't > > > that old. > > > > Two and a half years and over 30 releases ago is pretty out of date. > > We prefer the term "stable". :-P you and each of your whiskers? :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Tue, 30 Sep 2014 08:05:43 +0900 Carsten Haitzler (The Rasterman) wrote: > On Tue, 30 Sep 2014 09:01:58 +1000 David Seikel > said: > > > On Mon, 29 Sep 2014 10:24:53 -0500 Doug Newgard > > wrote: > > > > > > > > > > > > > > > Date: Tue, 30 Sep 2014 00:50:23 +0930 > > > > From: graham.go...@gmail.com > > > > To: enlightenment-devel@lists.sourceforge.net > > > > Subject: Re: [E-devel] libeeze.so: undefined reference to > > > > `udev_device_set_sysattr_value' > > > > > > > > On 30 September 2014 00:42, Doug Newgard > > > > wrote: > > > >> > > > >> udev works fine without systemd. Those distros that are > > > >> refusing to update past 184 are either ones that use ancient > > > >> software anyway or they are just taking a very childish stance > > > >> and refusing to even build it now. > > > > > > > > I think you'll find the version of udev I have (182) really > > > > isn't that old. > > > > > > Two and a half years and over 30 releases ago is pretty out of > > > date. > > > > We prefer the term "stable". :-P > > you and each of your whiskers? :) Me, and Doug, and people like Ubuntu that provide a "Long Term Stable" distro, where it's supported for way more than two and a half years, built on versions that had been stable for some time at the time of release. It's quite popular, perhaps you have heard of it? 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 -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Tue, 30 Sep 2014 09:15:53 +1000 David Seikel wrote: > On Tue, 30 Sep 2014 08:05:43 +0900 Carsten Haitzler (The Rasterman) > wrote: > > > On Tue, 30 Sep 2014 09:01:58 +1000 David Seikel > > said: > > > > > On Mon, 29 Sep 2014 10:24:53 -0500 Doug Newgard > > > wrote: > > > > > > > > > > > > > > > > > > > > Date: Tue, 30 Sep 2014 00:50:23 +0930 > > > > > From: graham.go...@gmail.com > > > > > To: enlightenment-devel@lists.sourceforge.net > > > > > Subject: Re: [E-devel] libeeze.so: undefined reference to > > > > > `udev_device_set_sysattr_value' > > > > > > > > > > On 30 September 2014 00:42, Doug Newgard > > > > > wrote: > > > > >> > > > > >> udev works fine without systemd. Those distros that are > > > > >> refusing to update past 184 are either ones that use ancient > > > > >> software anyway or they are just taking a very childish > > > > >> stance and refusing to even build it now. > > > > > > > > > > I think you'll find the version of udev I have (182) really > > > > > isn't that old. > > > > > > > > Two and a half years and over 30 releases ago is pretty out of > > > > date. > > > > > > We prefer the term "stable". :-P > > > > you and each of your whiskers? :) > > Me, and Doug, and people like Ubuntu that provide a "Long Term Stable" > distro, where it's supported for way more than two and a half years, > built on versions that had been stable for some time at the time of > release. It's quite popular, perhaps you have heard of it? B-) Er I meant Me and Graham. The quoting got a bit odd there. -- 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 -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
Not part of the Debian-whatever spawns, but in Slackware universe the last used udev version is also 182 ( for reasons sufficiently obvious ) -- Regards, Alex-P. Natsios (a.k.a Drakevr) -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Tue, 30 Sep 2014 09:21:16 +1000 David Seikel said: > On Tue, 30 Sep 2014 09:15:53 +1000 David Seikel > wrote: > > > On Tue, 30 Sep 2014 08:05:43 +0900 Carsten Haitzler (The Rasterman) > > wrote: > > > > > On Tue, 30 Sep 2014 09:01:58 +1000 David Seikel > > > said: > > > > > > > On Mon, 29 Sep 2014 10:24:53 -0500 Doug Newgard > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Date: Tue, 30 Sep 2014 00:50:23 +0930 > > > > > > From: graham.go...@gmail.com > > > > > > To: enlightenment-devel@lists.sourceforge.net > > > > > > Subject: Re: [E-devel] libeeze.so: undefined reference to > > > > > > `udev_device_set_sysattr_value' > > > > > > > > > > > > On 30 September 2014 00:42, Doug Newgard > > > > > > wrote: > > > > > >> > > > > > >> udev works fine without systemd. Those distros that are > > > > > >> refusing to update past 184 are either ones that use ancient > > > > > >> software anyway or they are just taking a very childish > > > > > >> stance and refusing to even build it now. > > > > > > > > > > > > I think you'll find the version of udev I have (182) really > > > > > > isn't that old. > > > > > > > > > > Two and a half years and over 30 releases ago is pretty out of > > > > > date. > > > > > > > > We prefer the term "stable". :-P > > > > > > you and each of your whiskers? :) > > > > Me, and Doug, and people like Ubuntu that provide a "Long Term Stable" > > distro, where it's supported for way more than two and a half years, > > built on versions that had been stable for some time at the time of > > release. It's quite popular, perhaps you have heard of it? B-) > > Er I meant Me and Graham. The quoting got a bit odd there. so your other whisker is called doug ... er graham? :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On 30 September 2014 09:03, Carsten Haitzler wrote: > On Tue, 30 Sep 2014 09:21:16 +1000 David Seikel said: > >> On Tue, 30 Sep 2014 09:15:53 +1000 David Seikel >> wrote: >> >> > On Tue, 30 Sep 2014 08:05:43 +0900 Carsten Haitzler (The Rasterman) >> > wrote: >> > >> > > On Tue, 30 Sep 2014 09:01:58 +1000 David Seikel >> > > said: >> > > >> > > > On Mon, 29 Sep 2014 10:24:53 -0500 Doug Newgard >> > > > wrote: >> > > > >> > > > > >> > > > > >> > > > > >> > > > > > Date: Tue, 30 Sep 2014 00:50:23 +0930 >> > > > > > From: graham.go...@gmail.com >> > > > > > To: enlightenment-devel@lists.sourceforge.net >> > > > > > Subject: Re: [E-devel] libeeze.so: undefined reference to >> > > > > > `udev_device_set_sysattr_value' >> > > > > > >> > > > > > On 30 September 2014 00:42, Doug Newgard >> > > > > > wrote: >> > > > > >> >> > > > > >> udev works fine without systemd. Those distros that are >> > > > > >> refusing to update past 184 are either ones that use ancient >> > > > > >> software anyway or they are just taking a very childish >> > > > > >> stance and refusing to even build it now. >> > > > > > >> > > > > > I think you'll find the version of udev I have (182) really >> > > > > > isn't that old. >> > > > > >> > > > > Two and a half years and over 30 releases ago is pretty out of >> > > > > date. >> > > > >> > > > We prefer the term "stable". :-P >> > > >> > > you and each of your whiskers? :) >> > >> > Me, and Doug, and people like Ubuntu that provide a "Long Term Stable" >> > distro, where it's supported for way more than two and a half years, >> > built on versions that had been stable for some time at the time of >> > release. It's quite popular, perhaps you have heard of it? B-) >> >> Er I meant Me and Graham. The quoting got a bit odd there. > > so your other whisker is called doug ... er graham? :) > Please don't shave. -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: ecore_imf/wayland: fix memory leak occured after getting surrounding text
jihoon pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=dd94425ecce71c7f109322927561c5fe08d9a5b1 commit dd94425ecce71c7f109322927561c5fe08d9a5b1 Author: Jihoon Kim Date: Tue Sep 30 09:31:33 2014 +0900 ecore_imf/wayland: fix memory leak occured after getting surrounding text --- src/modules/ecore_imf/wayland/wayland_imcontext.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/modules/ecore_imf/wayland/wayland_imcontext.c b/src/modules/ecore_imf/wayland/wayland_imcontext.c index 1ca44b0..a83b493 100644 --- a/src/modules/ecore_imf/wayland/wayland_imcontext.c +++ b/src/modules/ecore_imf/wayland/wayland_imcontext.c @@ -235,6 +235,8 @@ text_input_commit_string(void *data, "delete on commit (text: `%s', offset `%d', length: `%d')", surrounding, ev.offset, ev.n_chars); + free(surrounding); + ecore_imf_context_delete_surrounding_event_add(imcontext->ctx, ev.offset, ev.n_chars); ecore_imf_context_event_callback_call(imcontext->ctx, ECORE_IMF_CALLBACK_DELETE_SURROUNDING, &ev); } --
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Tue, 30 Sep 2014 09:25:57 +0930 Graham Gower wrote: > On 30 September 2014 09:03, Carsten Haitzler > wrote: > > On Tue, 30 Sep 2014 09:21:16 +1000 David Seikel > > said: > > > >> On Tue, 30 Sep 2014 09:15:53 +1000 David Seikel > >> wrote: > >> > >> > On Tue, 30 Sep 2014 08:05:43 +0900 Carsten Haitzler (The > >> > Rasterman) wrote: > >> > > >> > > On Tue, 30 Sep 2014 09:01:58 +1000 David Seikel > >> > > said: > >> > > > >> > > > On Mon, 29 Sep 2014 10:24:53 -0500 Doug Newgard > >> > > > wrote: > >> > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > Date: Tue, 30 Sep 2014 00:50:23 +0930 > >> > > > > > From: graham.go...@gmail.com > >> > > > > > To: enlightenment-devel@lists.sourceforge.net > >> > > > > > Subject: Re: [E-devel] libeeze.so: undefined reference to > >> > > > > > `udev_device_set_sysattr_value' > >> > > > > > > >> > > > > > On 30 September 2014 00:42, Doug Newgard > >> > > > > > wrote: > >> > > > > >> > >> > > > > >> udev works fine without systemd. Those distros that are > >> > > > > >> refusing to update past 184 are either ones that use > >> > > > > >> ancient software anyway or they are just taking a very > >> > > > > >> childish stance and refusing to even build it now. > >> > > > > > > >> > > > > > I think you'll find the version of udev I have (182) > >> > > > > > really isn't that old. > >> > > > > > >> > > > > Two and a half years and over 30 releases ago is pretty > >> > > > > out of date. > >> > > > > >> > > > We prefer the term "stable". :-P > >> > > > >> > > you and each of your whiskers? :) > >> > > >> > Me, and Doug, and people like Ubuntu that provide a "Long Term > >> > Stable" distro, where it's supported for way more than two and a > >> > half years, built on versions that had been stable for some time > >> > at the time of release. It's quite popular, perhaps you have > >> > heard of it? B-) > >> > >> Er I meant Me and Graham. The quoting got a bit odd there. > > > > so your other whisker is called doug ... er graham? :) > > > > > Please don't shave. If you saw my entry to the Enlightenment Call For Beards, you'll know there's no danger of that. 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 -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: ecore_imf/ibus: support delete-surrounding-text signal
jihoon pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=d059e1af953329e13792f18333087d84a836e99c
commit d059e1af953329e13792f18333087d84a836e99c
Author: Jihoon Kim
Date: Tue Sep 30 10:47:26 2014 +0900
ecore_imf/ibus: support delete-surrounding-text signal
---
src/modules/ecore_imf/ibus/ibus_imcontext.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/src/modules/ecore_imf/ibus/ibus_imcontext.c
b/src/modules/ecore_imf/ibus/ibus_imcontext.c
index c735ce2..d662ac2 100644
--- a/src/modules/ecore_imf/ibus/ibus_imcontext.c
+++ b/src/modules/ecore_imf/ibus/ibus_imcontext.c
@@ -682,6 +682,25 @@ sort_cb(const void *d1, const void *d2)
}
static void
+_ecore_imf_context_ibus_delete_surrounding_text_cb(IBusInputContext
*ibuscontext EINA_UNUSED,
+ gint
offset_from_cursor,
+ guint nchars,
+ IBusIMContext
*ibusimcontext)
+{
+ EINA_SAFETY_ON_NULL_RETURN(ibusimcontext);
+
+ if (_focus_im_context != ibusimcontext->ctx)
+ return;
+
+ Ecore_IMF_Event_Delete_Surrounding ev;
+ ev.ctx = _focus_im_context;
+ ev.n_chars = nchars;
+ ev.offset = offset_from_cursor;
+ ecore_imf_context_delete_surrounding_event_add(_focus_im_context,
offset_from_cursor, nchars);
+ ecore_imf_context_event_callback_call(_focus_im_context,
ECORE_IMF_CALLBACK_DELETE_SURROUNDING, &ev);
+}
+
+static void
_ecore_imf_context_ibus_update_preedit_text_cb(IBusInputContext *ibuscontext
EINA_UNUSED,
IBusText *text,
gint cursor_pos,
@@ -932,6 +951,10 @@ _ecore_imf_context_ibus_create(IBusIMContext
*ibusimcontext)
G_CALLBACK (_ecore_imf_context_ibus_forward_key_event_cb),
ibusimcontext);
g_signal_connect(ibusimcontext->ibuscontext,
+"delete-surrounding-text",
+G_CALLBACK
(_ecore_imf_context_ibus_delete_surrounding_text_cb),
+ibusimcontext);
+ g_signal_connect(ibusimcontext->ibuscontext,
"update-preedit-text",
G_CALLBACK
(_ecore_imf_context_ibus_update_preedit_text_cb),
ibusimcontext);
--
[EGIT] [core/elementary] master 01/01: elm_menu: Add item_signal_emit_hook for elm_menu
hermet pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=496b4a39cbb630e6658dfa7f56edc880993dcf69
commit 496b4a39cbb630e6658dfa7f56edc880993dcf69
Author: Jaehyun Cho
Date: Tue Sep 30 10:58:18 2014 +0900
elm_menu: Add item_signal_emit_hook for elm_menu
Summary: Add item_signal_emit_hook for elm_menu
Reviewers: Hermet
Reviewed By: Hermet
Subscribers: seoz
Differential Revision: https://phab.enlightenment.org/D1500
---
src/lib/elm_menu.c | 12
src/lib/elm_menu.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/src/lib/elm_menu.c b/src/lib/elm_menu.c
index d103393..95ce2bb 100644
--- a/src/lib/elm_menu.c
+++ b/src/lib/elm_menu.c
@@ -91,6 +91,16 @@ _item_disable_hook(Elm_Object_Item *it)
}
static void
+_item_signal_emit_hook(Elm_Object_Item *it,
+ const char *emission,
+ const char *source)
+{
+ Elm_Menu_Item *item = (Elm_Menu_Item *)it;
+
+ elm_layout_signal_emit(VIEW(item), emission, source);
+}
+
+static void
_submenu_sizing_eval(Elm_Menu_Item *parent_it)
{
Eina_List *l;
@@ -974,6 +984,7 @@ _elm_menu_item_add(Eo *obj, Elm_Menu_Data *sd,
Elm_Object_Item *parent, const ch
elm_widget_item_text_get_hook_set(it, _item_text_get_hook);
elm_widget_item_content_set_hook_set(it, _item_content_set_hook);
elm_widget_item_content_get_hook_set(it, _item_content_get_hook);
+ elm_widget_item_signal_emit_hook_set(it, _item_signal_emit_hook);
it->base.data = data;
it->func = func;
@@ -1059,6 +1070,7 @@ _elm_menu_item_separator_add(Eo *obj, Elm_Menu_Data *sd,
Elm_Object_Item *parent
elm_widget_item_text_get_hook_set(subitem, _item_text_get_hook);
elm_widget_item_content_set_hook_set(subitem, _item_content_set_hook);
elm_widget_item_content_get_hook_set(subitem, _item_content_get_hook);
+ elm_widget_item_signal_emit_hook_set(subitem, _item_signal_emit_hook);
subitem->separator = EINA_TRUE;
_item_separator_obj_create(subitem);
diff --git a/src/lib/elm_menu.h b/src/lib/elm_menu.h
index ea0ead0..9d3e2af 100644
--- a/src/lib/elm_menu.h
+++ b/src/lib/elm_menu.h
@@ -32,6 +32,7 @@
* @li @ref elm_object_item_part_content_get
* @li @ref elm_object_item_disabled_set
* @li @ref elm_object_item_disabled_get
+ * @li @ref elm_object_item_signal_emit (since 1.12)
*
* @see @ref tutorial_menu
* @{
--
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
> On Tue, 30 Sep 2014 08:05:43 +0900 Carsten Haitzler (The Rasterman) > wrote: > >> On Tue, 30 Sep 2014 09:01:58 +1000 David Seikel >> said: >> >>> On Mon, 29 Sep 2014 10:24:53 -0500 Doug Newgard >>> wrote: >>> > Date: Tue, 30 Sep 2014 00:50:23 +0930 > From: graham.go...@gmail.com > To: enlightenment-devel@lists.sourceforge.net > Subject: Re: [E-devel] libeeze.so: undefined reference to > `udev_device_set_sysattr_value' > > On 30 September 2014 00:42, Doug Newgard > wrote: >> >> udev works fine without systemd. Those distros that are >> refusing to update past 184 are either ones that use ancient >> software anyway or they are just taking a very childish >> stance and refusing to even build it now. > > I think you'll find the version of udev I have (182) really > isn't that old. Two and a half years and over 30 releases ago is pretty out of date. >>> >>> We prefer the term "stable". :-P >> >> you and each of your whiskers? :) > > Me, and Doug, and people like Ubuntu that provide a "Long Term Stable" > distro, where it's supported for way more than two and a half years, > built on versions that had been stable for some time at the time of > release. It's quite popular, perhaps you have heard of it? B-) If you're entire system is that old, I'm sure EFL from 2.5 years ago will run just fine as well. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [tools/enventor] master 01/01: Main : Corrected typo, replaced h with H
hermet pushed a commit to branch master.
http://git.enlightenment.org/tools/enventor.git/commit/?id=1b76667733850a07d996af3efa3a49849cf4e2bf
commit 1b76667733850a07d996af3efa3a49849cf4e2bf
Author: kabeer khan
Date: Tue Sep 30 11:07:57 2014 +0900
Main : Corrected typo, replaced h with H
Summary:
Corrected typo in main.c replaced h with H to ensure highlighting with H
Signed-off-by: kabeer khan
Reviewers: Hermet
Reviewed By: Hermet
Differential Revision: https://phab.enlightenment.org/D1488
---
AUTHORS | 1 +
data/about/ABOUT | 1 +
src/bin/main.c | 2 +-
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/AUTHORS b/AUTHORS
index 3a67762..7624129 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -9,3 +9,4 @@ Kateryna Fesyna
Jaehyun Cho
Mykyta Biliavskyi
Alex-P. Natsios
+Kabeer Khan
diff --git a/data/about/ABOUT b/data/about/ABOUT
index d1197b4..fe13398 100644
--- a/data/about/ABOUT
+++ b/data/about/ABOUT
@@ -75,3 +75,4 @@ Daniel Juyung Seo
Jihoon Kim
The Rasterman (Carsten Haitzler)
Jaehyun Cho
+Kabeer Khan
diff --git a/src/bin/main.c b/src/bin/main.c
index 35f4c7d..2f71ffd 100644
--- a/src/bin/main.c
+++ b/src/bin/main.c
@@ -140,7 +140,7 @@ ctrl_func(app_data *ad, const char *key)
return ECORE_CALLBACK_DONE;
}
//Part Highlight
- if (!strcmp(key, "h") || !strcmp(key, "h"))
+ if (!strcmp(key, "h") || !strcmp(key, "H"))
{
config_part_highlight_set(!config_part_highlight_get());
edit_part_highlight_toggle(ad->ed, EINA_TRUE);
--
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On 30 September 2014 11:37, Doug Newgard wrote: > If you're entire system is that old, I'm sure EFL from 2.5 years ago will run > just fine as well. Slackware 14.1, released Nov 2013. This is not old unless you're accustomed to releasing a new version of your software every 2-3 weeks. Systemd flames aside, my initial post was to ask whether there was a deliberate dependency change or if it was unintended. Specifically, this line in efl/configure.ac created some uncertainty in my mind. EFL_DEPEND_PKG([EEZE], [UDEV], [libudev >= 148]) -Graham -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Tue, 30 Sep 2014 13:19:20 +0930 Graham Gower wrote: > On 30 September 2014 11:37, Doug Newgard > wrote: > > If you're entire system is that old, I'm sure EFL from 2.5 years > > ago will run just fine as well. Actually, EFL from 2.5 years ago was just as bleeding edge at the time as it is now, and still unlikely to run on stable systems from 2.5 years ago, which did not use bleeding edge stuff from 2.5 years ago. :-P > Slackware 14.1, released Nov 2013. This is not old unless you're > accustomed to releasing a new version of your software every 2-3 > weeks. There's no arguing with those that insist every one use the most bleeding edge systems. You can't change their minds. It also seems useless trying to keep the large and every growing list of dependencies down to a manageable roar. > Systemd flames aside, my initial post was to ask whether there was a > deliberate dependency change or if it was unintended. Specifically, > this line in efl/configure.ac created some uncertainty in my mind. > EFL_DEPEND_PKG([EEZE], [UDEV], [libudev >= 148]) I think the actual issue got sorted out already. -- 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 -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
> Date: Tue, 30 Sep 2014 14:07:52 +1000 > From: onef...@gmail.com > To: enlightenment-devel@lists.sourceforge.net > Subject: Re: [E-devel] libeeze.so: undefined reference to >`udev_device_set_sysattr_value' > > > On Tue, 30 Sep 2014 13:19:20 +0930 Graham Gower > wrote: > > > On 30 September 2014 11:37, Doug Newgard > > wrote: > >> If you're entire system is that old, I'm sure EFL from 2.5 years > >> ago will run just fine as well. > > Actually, EFL from 2.5 years ago was just as bleeding edge at the time > as it is now, and still unlikely to run on stable systems from 2.5 > years ago, which did not use bleeding edge stuff from 2.5 years > ago. :-P I don't know if you didn't understand my point or if you're just ignoring it. If it takes 2.5 years for software to be considered "stable", go back and install the various libs from 1.4 and you should be great! Match the version of EFL to the rest of your system. > > > Slackware 14.1, released Nov 2013. This is not old unless you're > > accustomed to releasing a new version of your software every 2-3 > > weeks. > > There's no arguing with those that insist every one use the most > bleeding edge systems. You can't change their minds. It also seems > useless trying to keep the large and every growing list of dependencies > down to a manageable roar. It is indeed hard to argue with someone who insists on installing bleeding edge software when everything else on their system is ancient. Can you really not see that that's a recipe for disaster? -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
> Date: Tue, 30 Sep 2014 13:19:20 +0930 > From: graham.go...@gmail.com > To: enlightenment-devel@lists.sourceforge.net > Subject: Re: [E-devel] libeeze.so: undefined reference to > `udev_device_set_sysattr_value' > > On 30 September 2014 11:37, Doug Newgard wrote: >> If you're entire system is that old, I'm sure EFL from 2.5 years ago will >> run just fine as well. > > Slackware 14.1, released Nov 2013. This is not old unless you're > accustomed to releasing a new version of your software every 2-3 > weeks. Slackware is an interesting case. Patrick has a long history of dragging his feet about anything and everything. He seems to be totally incapable of being proactive. I used Slackware for a number of years, starting with version 4, but switched away when I got tired of the way it was run. > > Systemd flames aside, my initial post was to ask whether there was a > deliberate dependency change or if it was unintended. Specifically, > this line in efl/configure.ac created some uncertainty in my mind. > EFL_DEPEND_PKG([EEZE], [UDEV], [libudev>= 148]) > > -Graham -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Mon, 29 Sep 2014 23:28:53 -0500 Doug Newgard wrote: > > Date: Tue, 30 Sep 2014 14:07:52 +1000 > > From: onef...@gmail.com > > To: enlightenment-devel@lists.sourceforge.net > > Subject: Re: [E-devel] libeeze.so: undefined reference to > >`udev_device_set_sysattr_value' > > > > On Tue, 30 Sep 2014 13:19:20 +0930 Graham Gower > > wrote: > > > > > On 30 September 2014 11:37, Doug Newgard > > > wrote: > > >> If you're entire system is that old, I'm sure EFL from 2.5 years > > >> ago will run just fine as well. > > > > Actually, EFL from 2.5 years ago was just as bleeding edge at the > >time as it is now, and still unlikely to run on stable systems from > >2.5 years ago, which did not use bleeding edge stuff from 2.5 years > > ago. :-P > > I don't know if you didn't understand my point or if you're just > ignoring it. If it takes 2.5 years for software to be considered > "stable", go back and install the various libs from 1.4 and you > should be great! Match the version of EFL to the rest of your system. You missed my point, the 2.5 year old EFL was bleeding edge 2.5 years ago, and still not good for a 2.5 year old stable system. > > > Slackware 14.1, released Nov 2013. This is not old unless you're > > > accustomed to releasing a new version of your software every 2-3 > > > weeks. > > > > There's no arguing with those that insist every one use the most > > bleeding edge systems. You can't change their minds. It also seems > > useless trying to keep the large and every growing list of > >dependencies down to a manageable roar. > > It is indeed hard to argue with someone who insists on installing > bleeding edge software when everything else on their system is > ancient. Can you really not see that that's a recipe for disaster? "Stable", not "ancient". Get that through your head please. There are many many people that use stable systems, this is why such systems are provided by popular Linux distros. This is the point of the "long term" part of "long term stable", you can rely on them being stable over a long term of many years. It's not a recipe for disaster, it's done all the time. Install a bleeding edge window manager, fine it shouldn't impact the rest of the system. The stable window manager the OS defaults to can be left alone and used as a backup for when the bleeding edge one falls over. Install a bleeding edge window manager that gratuitously depends on a bleeding edge version of an important sub system, yep THAT's a recipe for disaster, and exactly why it's not such a good idea for said window manager to depend on bleeding edge stuff. Installing a window manager that gratuitously depends on an important sub system that is itself graciously different from what some others do is even worse. The base OS is stable, but you can use a stable OS for development of bleeding edge software, or install bleeding edge bits. Lots of development companies do that. So long as you don't replace stable bits that are crucial to the OS in general with bleeding edge bits, it's all good. Things like udev and systemd are kinda crucial bits, or replace crucial bits in stable systems that didn't use systemd or udev in the first place. There was mention in this thread that eeze being just a thin layer was a bad idea, and it should have been a higher abstraction API. Then you wouldn't be depending on ONE bleeding edge important sub system that some people don't use for various reasons. Flexibility in this area is important. A bit less important for stuff that's not so crucial. -- 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 -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
> Date: Tue, 30 Sep 2014 15:08:04 +1000 > From: onef...@gmail.com > To: enlightenment-devel@lists.sourceforge.net > Subject: Re: [E-devel] libeeze.so: undefined reference to >`udev_device_set_sysattr_value' > > > On Mon, 29 Sep 2014 23:28:53 -0500 Doug Newgard > wrote: > > > > Date: Tue, 30 Sep 2014 14:07:52 +1000 > > > From: onef...@gmail.com > > > To: enlightenment-devel@lists.sourceforge.net > > > Subject: Re: [E-devel] libeeze.so: undefined reference to > > >`udev_device_set_sysattr_value' > > > > > > On Tue, 30 Sep 2014 13:19:20 +0930 Graham Gower > > > wrote: > > > > > >> On 30 September 2014 11:37, Doug Newgard > > >> wrote: > > >>> If you're entire system is that old, I'm sure EFL from 2.5 years > > >>> ago will run just fine as well. > > > > > > Actually, EFL from 2.5 years ago was just as bleeding edge at the > > >time as it is now, and still unlikely to run on stable systems from > > >2.5 years ago, which did not use bleeding edge stuff from 2.5 years > > > ago. :-P > > > > I don't know if you didn't understand my point or if you're just > > ignoring it. If it takes 2.5 years for software to be considered > > "stable", go back and install the various libs from 1.4 and you > > should be great! Match the version of EFL to the rest of your system. > > You missed my point, the 2.5 year old EFL was bleeding edge 2.5 years > ago, and still not good for a 2.5 year old stable system. Oh I understood your point perfectly, but it's totally irrelevant. I'm not telling you to install 2.5 year old libs on a 5 year old system, but 2.5 year old libs on a 2.5 year old system. Makes a twisted kind of sense, doesn't it? Your own reasoning says that the pre-1.7 libs are just now becoming "stable", so why not use them? > >>> Slackware 14.1, released Nov 2013. This is not old unless you're > >>> accustomed to releasing a new version of your software every 2-3 > >>> weeks. > >> > >> There's no arguing with those that insist every one use the most > >> bleeding edge systems. You can't change their minds. It also seems > >> useless trying to keep the large and every growing list of > >>dependencies down to a manageable roar. > > > > It is indeed hard to argue with someone who insists on installing > > bleeding edge software when everything else on their system is > > ancient. Can you really not see that that's a recipe for disaster? > > "Stable", not "ancient". Get that through your head please. There are > many many people that use stable systems, this is why such systems are > provided by popular Linux distros. This is the point of the "long > term" part of "long term stable", you can rely on them being stable > over a long term of many years. I'll stick with "ancient", since it really describes the situation better. "Stable" is not determined by time, "ancient" is and that seems to be what's important in these distros that use ancient software. > > It's not a recipe for disaster, it's done all the time. Install a > bleeding edge window manager, fine it shouldn't impact the rest of the > system. The stable window manager the OS defaults to can be left alone > and used as a backup for when the bleeding edge one falls over. Install > a bleeding edge window manager that gratuitously depends on a bleeding > edge version of an important sub system, yep THAT's a recipe for > disaster, and exactly why it's not such a good idea for said window > manager to depend on bleeding edge stuff. Installing a window manager > that gratuitously depends on an important sub system that is itself > graciously different from what some others do is even worse. > > The base OS is stable, but you can use a stable OS for development of > bleeding edge software, or install bleeding edge bits. Lots of > development companies do that. So long as you don't replace stable > bits that are crucial to the OS in general with bleeding edge bits, > it's all good. Things like udev and systemd are kinda crucial bits, or > replace crucial bits in stable systems that didn't use systemd or udev > in the first place. And this is the crux of the issue. You believe that all software must be backwards compatible to the beginning of time, I do not. By the time your current software gets into distros, the current version of libs will as well. Having to add a bunch of logic for APIs that have been obsolete for 5+ years does nothing except dirty up the code. Note that the lib in question here is already a year and a half old. By the time EFL is shipped in a distro, it *should* already have the necessary version. Calling this bleeding edge is really stretching things beyond belief. > > There was mention in this thread that eeze being just a thin layer was > a bad idea, and it should have been a higher abstraction API. Then you > wouldn't be depending on ONE bleeding edge important sub system that > some people don't use for various reasons. Flexibility in this area is > important. A bit less imp
Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
On Tue, 30 Sep 2014 00:41:59 -0500 Doug Newgard wrote: > > > > > Date: Tue, 30 Sep 2014 15:08:04 +1000 > > From: onef...@gmail.com > > To: enlightenment-devel@lists.sourceforge.net > > Subject: Re: [E-devel] libeeze.so: undefined reference to > >`udev_device_set_sysattr_value' > > > > On Mon, 29 Sep 2014 23:28:53 -0500 Doug Newgard > > wrote: > > > > > > Date: Tue, 30 Sep 2014 14:07:52 +1000 > > > > From: onef...@gmail.com > > > > To: enlightenment-devel@lists.sourceforge.net > > > > Subject: Re: [E-devel] libeeze.so: undefined reference to > > > >`udev_device_set_sysattr_value' > > > > > > > > On Tue, 30 Sep 2014 13:19:20 +0930 Graham Gower > > > > wrote: > > > > > > > >> On 30 September 2014 11:37, Doug Newgard > > > >> wrote: > > > >>> If you're entire system is that old, I'm sure EFL from 2.5 > >years > >>> ago will run just fine as well. > > > > > > > > Actually, EFL from 2.5 years ago was just as bleeding edge at > >the > >time as it is now, and still unlikely to run on stable > >systems from > >2.5 years ago, which did not use bleeding edge stuff > >from 2.5 years > > ago. :-P > > > > > > I don't know if you didn't understand my point or if you're just > > > ignoring it. If it takes 2.5 years for software to be considered > > > "stable", go back and install the various libs from 1.4 and you > > > should be great! Match the version of EFL to the rest of your > >system. > > You missed my point, the 2.5 year old EFL was bleeding edge 2.5 > >years ago, and still not good for a 2.5 year old stable system. > > Oh I understood your point perfectly, but it's totally irrelevant. > I'm not telling you to install 2.5 year old libs on a 5 year old > system, but 2.5 year old libs on a 2.5 year old system. Makes a > twisted kind of sense, doesn't it? Your own reasoning says that the > pre-1.7 libs are just now becoming "stable", so why not use them? > > > >>> Slackware 14.1, released Nov 2013. This is not old unless you're > > >>> accustomed to releasing a new version of your software every 2-3 > > >>> weeks. > > >> > > >> There's no arguing with those that insist every one use the most > > >> bleeding edge systems. You can't change their minds. It also > >seems >> useless trying to keep the large and every growing list of > > >>dependencies down to a manageable roar. > > > > > > It is indeed hard to argue with someone who insists on installing > > > bleeding edge software when everything else on their system is > > > ancient. Can you really not see that that's a recipe for disaster? > > > > "Stable", not "ancient". Get that through your head please. There > >are many many people that use stable systems, this is why such > >systems are provided by popular Linux distros. This is the point of > >the "long term" part of "long term stable", you can rely on them > >being stable over a long term of many years. > > I'll stick with "ancient", since it really describes the situation > better. "Stable" is not determined by time, "ancient" is and that > seems to be what's important in these distros that use ancient > software. > > > > > It's not a recipe for disaster, it's done all the time. Install a > > bleeding edge window manager, fine it shouldn't impact the rest of > >the system. The stable window manager the OS defaults to can be left > >alone and used as a backup for when the bleeding edge one falls > >over. Install a bleeding edge window manager that gratuitously > >depends on a bleeding edge version of an important sub system, yep > >THAT's a recipe for disaster, and exactly why it's not such a good > >idea for said window manager to depend on bleeding edge stuff. > >Installing a window manager that gratuitously depends on an > >important sub system that is itself graciously different from what > >some others do is even worse. > > The base OS is stable, but you can use a stable OS for development > >of bleeding edge software, or install bleeding edge bits. Lots of > > development companies do that. So long as you don't replace stable > > bits that are crucial to the OS in general with bleeding edge bits, > > it's all good. Things like udev and systemd are kinda crucial bits, > >or replace crucial bits in stable systems that didn't use systemd or > >udev in the first place. > > And this is the crux of the issue. You believe that all software must > be backwards compatible to the beginning of time, I do not. By the > time your current software gets into distros, the current version of > libs will as well. Having to add a bunch of logic for APIs that have > been obsolete for 5+ years does nothing except dirty up the code. > > Note that the lib in question here is already a year and a half old. > By the time EFL is shipped in a distro, it *should* already have the > necessary version. Calling this bleeding edge is really stretching > things beyond belief. Like I said, pointless arguing against the bleeding edge people, they just don't get it. sigh > > There
