Re: [E-devel] libeeze.so: undefined reference to `udev_device_set_sysattr_value'
Em 28/09/2014 08:46, "Graham Gower" escreveu: > > Hi, > > 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 Lucas De Marchi -- 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] [EGIT] [core/efl] efl-1.11 01/01: ecore vsync - work around old kernels by blacklisting them
On Wed, Aug 27, 2014 at 6:32 AM, Tom Hacohen wrote:
> We use @fix, not @bug. :)
>
> --
> Tom.
>
> On 27/08/14 10:27, Carsten Haitzler wrote:
>> raster pushed a commit to branch efl-1.11.
>>
>> http://git.enlightenment.org/core/efl.git/commit/?id=26783f45dd419873f4dc2a9ab3a1e4b421f2c4ca
>>
>> commit 26783f45dd419873f4dc2a9ab3a1e4b421f2c4ca
>> Author: Carsten Haitzler (Rasterman)
>> Date: Wed Aug 27 18:26:58 2014 +0900
>>
>> ecore vsync - work around old kernels by blacklisting them
>>
>> this is a bug workaround apparently old kernels that seems to get
>> vsync and timestamps wrong. 3.14 kernels and up only for now
>>
>> @bug
>> ---
>> src/lib/ecore_x/xlib/ecore_x_vsync.c | 21 +
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/src/lib/ecore_x/xlib/ecore_x_vsync.c
>> b/src/lib/ecore_x/xlib/ecore_x_vsync.c
>> index ec41d0d..1924dfc 100644
>> --- a/src/lib/ecore_x/xlib/ecore_x_vsync.c
>> +++ b/src/lib/ecore_x/xlib/ecore_x_vsync.c
>> @@ -345,6 +345,27 @@ _drm_init(void)
>>*/
>> return 0;
>>}
>> + // only do this on new kernels = let's say 3.14 and up. 3.16 definitely
>> + // works
>> + {
>> +Eina_Bool ok = EINA_FALSE;
>> +
>> +FILE *fp = fopen("/proc/sys/kernel/osrelease", "r");
>> +if (fp)
>> + {
>> + if (fgets(buf, sizeof(buf), fp))
>> + {
>> + int vmaj = 0, vmin = 0;
>> +
>> + if (sscanf(buf, "%i.%i.%*s", &vmaj, &vmin) == 2)
>> +{
>> + if ((vmaj >= 3) && (vmin >= 14)) ok = EINA_TRUE;
>> +}
>> + }
>> + fclose(fp);
>> + }
>> +if (!ok) return 0;
So if a 3.11 kernel has been patch to do the right thing, you still
return 0. Parsing the kernel version is in general a bad thing to do.
--
Lucas De Marchi
--
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: eolian_cxx: Fix out of tree build
demarchi pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=39e5919daec5ad49c1a36aff028ae5e7d95d86cd commit 39e5919daec5ad49c1a36aff028ae5e7d95d86cd Author: Lucas De Marchi Date: Wed May 7 06:42:30 2014 -0300 eolian_cxx: Fix out of tree build Passing a relative path prepending "./" is generally the wrong thing to do in autotools because the auto vars may be absolute. Fix build: ... ERR<17525>:eo_toknz lib/eolian/eo_lexer.rl:1325 eo_tokenizer_database_fill() unable to read in .//home/lucas/p/e//efl/src/lib/ecore/ecore_poll.eo Couldn't load input file: .//home/lucas/p/e//efl/src/lib/ecore/ecore_poll.eo --- src/Makefile_Eolian_Cxx_Helper.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/Makefile_Eolian_Cxx_Helper.am b/src/Makefile_Eolian_Cxx_Helper.am index 3c85669..d234e64 100644 --- a/src/Makefile_Eolian_Cxx_Helper.am +++ b/src/Makefile_Eolian_Cxx_Helper.am @@ -14,6 +14,6 @@ am__v_EOLCXX_0 = @echo " EOLCXX " $@; SUFFIXES += .eo.hh %.eo.hh: %.eo $(_EOLIAN_CXX_DEP) - $(AM_V_EOLCXX)$(EOLIAN_CXX) $(EOLIAN_FLAGS) -I./$< -o $@ + $(AM_V_EOLCXX)$(EOLIAN_CXX) $(EOLIAN_FLAGS) -I $< -o $@ CLEANFILES += $(BUILT_SOURCES) --
Re: [E-devel] [EGIT] [core/efl] master 02/02: eolian_cxx: initial version of the EFL C++ Bindings Generator.
On Tue, May 06, 2014 at 12:58:10AM -0300, Lucas De Marchi wrote: > On Sat, May 3, 2014 at 6:57 PM, Cedric BAIL wrote: > > Hello, > > > > On Sat, May 3, 2014 at 9:53 PM, Daniel Juyung Seo > > wrote: > >> Well, I don't think this can go in at this stage as we're in a feature > >> freeze. > > > > Yes and no :-) It has been discussed on IRC (we should have pointed > > that on the ML to), but as it is not a public API, is not used by > > anything inside our build, and we want people to look at the result > > early, it was decided that this could still get in during this week > > (The patch has been in discussion for some time on phab already). > > > >> This also broke the build. > >> Can you check this again? > > > > This is something I tried to understand but the build break in the > > middle of nowhere and I couldn't make sense of it. So I was thinking > > it was a temporary failure, if anyone has a better explanation :-) > > So, as far as I understood an experimental thing that can not even be > disabled?? Build is broken if you don't build in the src tree. I.e. > make distcheck is broken > > And there are gazillions of warnings introduced all over eolian With the following patch I could at least get the build to complete. Still lots of errors eolian is giving such as: ERR<26616>:eolian /home/lucas/p/e//efl/src/lib/eolian/eolian_database.c:539 eolian_class_function_find_by_name() Function destructor not found in class Eo_Base EOLCXX lib/ecore/ecore_idle_exiter.eo.hh ERR<26670>:eolian /home/lucas/p/e//efl/src/lib/eolian/eolian_database.c:539 eolian_class_function_find_by_name() Function destructor not found in class Eo_Base EOLCXX lib/ecore/ecore_animator.eo.hh ... and C++ warnings as well. Lucas De Marchi 8<--- diff --git a/src/Makefile_Eolian_Cxx_Helper.am b/src/Makefile_Eolian_Cxx_Helper.am index 3c85669..d234e64 100644 --- a/src/Makefile_Eolian_Cxx_Helper.am +++ b/src/Makefile_Eolian_Cxx_Helper.am @@ -14,6 +14,6 @@ am__v_EOLCXX_0 = @echo " EOLCXX " $@; SUFFIXES += .eo.hh %.eo.hh: %.eo $(_EOLIAN_CXX_DEP) - $(AM_V_EOLCXX)$(EOLIAN_CXX) $(EOLIAN_FLAGS) -I./$< -o $@ + $(AM_V_EOLCXX)$(EOLIAN_CXX) $(EOLIAN_FLAGS) -I $< -o $@ CLEANFILES += $(BUILT_SOURCES) -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 02/02: eolian_cxx: initial version of the EFL C++ Bindings Generator.
On Sat, May 3, 2014 at 6:57 PM, Cedric BAIL wrote: > Hello, > > On Sat, May 3, 2014 at 9:53 PM, Daniel Juyung Seo > wrote: >> Well, I don't think this can go in at this stage as we're in a feature >> freeze. > > Yes and no :-) It has been discussed on IRC (we should have pointed > that on the ML to), but as it is not a public API, is not used by > anything inside our build, and we want people to look at the result > early, it was decided that this could still get in during this week > (The patch has been in discussion for some time on phab already). > >> This also broke the build. >> Can you check this again? > > This is something I tried to understand but the build break in the > middle of nowhere and I couldn't make sense of it. So I was thinking > it was a temporary failure, if anyone has a better explanation :-) So, as far as I understood an experimental thing that can not even be disabled?? Build is broken if you don't build in the src tree. I.e. make distcheck is broken And there are gazillions of warnings introduced all over eolian Lucas De Marchi -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Any Improved Pulseaudio support for Mixer planned?
Em 15/04/2014 01:04, "Stefan Schmidt" escreveu: > > Hello. > > On Fri, 2014-04-04 at 13:25, Flavio Ceolin wrote: > > > > Lucas De Marchi writes: > > > > > On Mon, Mar 10, 2014 at 7:07 PM, Flávio Ceolin > > > wrote: > > >> On Mon, Mar 10, 2014 at 6:43 PM, Jeff Hoogland < jeffhoogl...@linux.com> wrote: > > >>> This will be AWESOME. Shame you missed the change window for E19 for this > > >>> to be included in core. Once you have code to share I'll be getting this > > >>> into the Bodhi 3.0.0 testing repos ASAP. > > >>> > > >> > > >> Yeah i know, my bad :( but I'll release something usable soon. > > > > > > ping. > > > > > > > > > Lucas De Marchi > > > > > > -- > > > ___ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > It's about time :) > > https://git.enlightenment.org/devs/ceolin/epulse.git > > > > > > I have added a TODO list with the most important things i think must be > > done. If someone find any problem and|or have suggestions to improve it, > > please let me know. > > So much encouragement and still nobody tested it? Or nobody did report > on it? :) > I just didn't report. I'm using it daily... And it's working pretty well. Not the prettiest interface, but functional. Lucas De Marchi -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Any Improved Pulseaudio support for Mixer planned?
On Mon, Mar 10, 2014 at 7:07 PM, Flávio Ceolin wrote: > On Mon, Mar 10, 2014 at 6:43 PM, Jeff Hoogland wrote: >> This will be AWESOME. Shame you missed the change window for E19 for this >> to be included in core. Once you have code to share I'll be getting this >> into the Bodhi 3.0.0 testing repos ASAP. >> > > Yeah i know, my bad :( but I'll release something usable soon. ping. Lucas De Marchi -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] the great commit access purge of march 2014... LOOK FOR YOUR NAME!
On Fri, Mar 21, 2014 at 8:02 AM, Thanatermesis wrote: > Ouch, I didn't read continuously this ML so I was not noticed about this > step until my "git pull" failed > > Can somebody put me back to active me and princeamd also? You don't really need commit access if you are not going to *push* stuff. To pull things you can just rename your remote. E.g git://git.enlightenment.org/core/enlightenment.git instead of git+ssh://git.enlightenment.org/core/enlightenment.git Of course... if you intend to contribute stuff soon, then it's ok to recover access. Lucas De Marchi -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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: SHUT UP ELM PREFS!!!!!!!!!!
On Mon, Jan 20, 2014 at 2:01 PM, Michael Blumenkrantz wrote: > On Mon, 20 Jan 2014 11:52:21 -0200 > Gustavo Sverzut Barbieri wrote: > >> On Sun, Jan 19, 2014 at 2:10 PM, Michael Blumenkrantz >> wrote: >> > On Sun, 19 Jan 2014 10:13:24 -0200 >> > Gustavo Sverzut Barbieri wrote: >> > >> >> On Sat, Jan 18, 2014 at 4:57 AM, zmike >> >> wrote: >> >> > discomfitor pushed a commit to branch master. >> >> > >> >> > http://git.enlightenment.org/core/elementary.git/commit/?id=fdcad71f7d1ddd3691850b0a5bdde86f44ebe1e8 >> >> > >> >> > commit fdcad71f7d1ddd3691850b0a5bdde86f44ebe1e8 >> >> > Author: zmike >> >> > Date: Sat Jan 18 01:56:12 2014 -0500 >> >> > >> >> > SHUT UP ELM PREFS!! >> >> > >> >> > seriously, this is and has been bullshit since it was added. I >> >> > don't need an error message every time I do ANYTHING just because some >> >> > module has never been found. >> >> >> >> well, it is indeed a problem. The module should have been installed >> >> and your elm profile should request it... You should check (strace) >> >> why it's not being loaded. Alternatively you could remove it from the >> >> modules string in elm profile. >> >> >> >> I plan to port some e19 config to elm using that, so if you don't get >> >> it ready you may expect some problems. >> >> >> > >> > That's news to me. Feel free to propose a plan of action related to this >> > if you want to see it happen. >> >> what plan? it would like "whenever I have time && motivation I'll port >> some config to that". Of course first rounds will be the first real >> users of elm_prefs, then it may require some fixing here and there, >> making it slower than I'd like. > > "I felt like rewriting a core component, so I did it in an afternoon without > talking to anyone" isn't going to happen anymore in E, especially not for > such a major component as the configure system and definitely not any time > soon with a first-use elm widget which "may require some fixing here and > there". Explain what you're planning on doing and how you're planning on > doing it. You may want to review the process then. This just don't work. Let people write the code, send it for inclusion and let the code talk about the idea. *Merging* the code is what should get more strict. "Talk is cheap, show me the code" used to work pretty well for several projects and I don't see why it wouldn't for e/efl now. Some parts may require interactions, talking ahead, RFCs, etc... but that should be a case by case decision. Lucas De Marchi -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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/enlightenment] master 01/01: enlightenment - removed warnings.
On Mon, Jan 20, 2014 at 9:02 AM, Tom Hacohen wrote:
> It's not commented out, it's compiled out base on config:
> +#ifdef HAVE_PAM
>e_auth_begin(char *passwd)
>{
> -#ifdef HAVE_PAM
It's not the best way to ifdef the function, but he indeed added it
just below the code you pasted:
+#else
+e_auth_begin(char *passwd EINA_UNUSED)
Lucas De Marchi
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [bindings/cxx/eflxx] master 180/314: eina-0 is no more, check for the right package name
tasn pushed a commit to branch master.
http://git.enlightenment.org/bindings/cxx/eflxx.git/commit/?id=9d162e687500bdbf5fac7b89afffbb1ea3a31e18
commit 9d162e687500bdbf5fac7b89afffbb1ea3a31e18
Author: Lucas De Marchi
Date: Tue Aug 17 03:59:29 2010 +
eina-0 is no more, check for the right package name
SVN revision: 51235
---
einaxx/configure.ac | 2 +-
einaxx/einaxx-uninstalled.pc.in | 2 +-
einaxx/einaxx.pc.in | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/einaxx/configure.ac b/einaxx/configure.ac
index a8f0f10..3767190 100644
--- a/einaxx/configure.ac
+++ b/einaxx/configure.ac
@@ -25,7 +25,7 @@ AM_PROG_LIBTOOL
-PKG_CHECK_MODULES(EFL, eina-0)
+PKG_CHECK_MODULES(EFL, eina)
PKG_CHECK_MODULES(EFLXX, eflxx)
AC_OUTPUT([
einaxx.pc
diff --git a/einaxx/einaxx-uninstalled.pc.in b/einaxx/einaxx-uninstalled.pc.in
index 0d139b3..2aa5e1b 100644
--- a/einaxx/einaxx-uninstalled.pc.in
+++ b/einaxx/einaxx-uninstalled.pc.in
@@ -6,7 +6,7 @@ includedir=include
Name: @PACKAGE@
Description: Eina (EFL) C++ Wrapper, Not installed
Version: @VERSION@
-Requires: sigc++-2.0 eflxx eina-0
+Requires: sigc++-2.0 eflxx eina
Conflicts:
Libs: ${pcfiledir}/${libdir}/libeinaxx.la
Cflags: -I${pcfiledir}/${includedir}
diff --git a/einaxx/einaxx.pc.in b/einaxx/einaxx.pc.in
index 8e6f453..065e4d1 100644
--- a/einaxx/einaxx.pc.in
+++ b/einaxx/einaxx.pc.in
@@ -6,7 +6,7 @@ includedir=@prefix@/include
Name: @PACKAGE@
Description: Eina (EFL) C++ Wrapper
Version: @VERSION@
-Requires: sigc++-2.0 eflxx eina-0
+Requires: sigc++-2.0 eflxx eina
Conflicts:
Libs: -L${libdir} -leinaxx
Cflags: -I${includedir}
--
Re: [E-devel] [EGIT] [core/efl] master 02/12: edje - edje_cc - try and make coverty ignore the leak (invalid)
On Wed, Dec 11, 2013 at 1:55 PM, Gustavo Sverzut Barbieri
wrote:
> On Wed, Dec 11, 2013 at 8:43 AM, Carsten Haitzler
> wrote:
>> raster pushed a commit to branch master.
>>
>> http://git.enlightenment.org/core/efl.git/commit/?id=f779c49c89875115a0b715a05c524bbb3ed6556c
>>
>> commit f779c49c89875115a0b715a05c524bbb3ed6556c
>> Author: Carsten Haitzler (Rasterman)
>> Date: Wed Dec 11 18:20:13 2013 +0900
>>
>> edje - edje_cc - try and make coverty ignore the leak (invalid)
>>
>> hope that this does not reappear in future if changes happen in src.
>> CID 1132627
>> ---
>> src/bin/edje/edje_cc_out.c | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/bin/edje/edje_cc_out.c b/src/bin/edje/edje_cc_out.c
>> index f5a5044..632a8bb 100644
>> --- a/src/bin/edje/edje_cc_out.c
>> +++ b/src/bin/edje/edje_cc_out.c
>> @@ -945,8 +945,11 @@ data_write_images(Eet_File *ef, int *image_num)
>> data_image_preload_done(iw, evas, im, NULL);
>> }
>>else
>> -error_and_abort_image_load_error
>> -(ef, img->entry, load_err);
>> +{
>> + error_and_abort_image_load_error
>> + (ef, img->entry, load_err);
>> + exit(1); // ensure static analysis tools know we exit
>> +}
>
> You could mark the function with the __attribute__(noreturn)
Or use C11's _Noreturn
Lucas De Marchi
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-intl] EFL 1.8.1
On Mon, Dec 2, 2013 at 11:05 PM, Carsten Haitzler wrote: > On Mon, 2 Dec 2013 22:57:04 -0200 Rafael Antognolli > said: > >> On Mon, Dec 2, 2013 at 10:42 PM, Carsten Haitzler >> wrote: >> > On Mon, 2 Dec 2013 22:32:00 -0200 Rafael Antognolli >> > said: >> > >> >> On Mon, Dec 2, 2013 at 10:20 PM, Carsten Haitzler >> >> wrote: >> >> > On Mon, 2 Dec 2013 21:43:38 +0100 Thanatermesis >> >> > said: >> >> > >> >> >> > BTW, if 1.8.1 is out, we need a proper v1.8.1 tag. >> >> >> >> >> >> with "git tag -l" i can see it listed, but this command is not reliable >> >> >> to get the last tagged value (version) on the branch, for that I use >> >> >> instead "git describe --tag --abbrev=0", but it points to v1.8.0, is >> >> >> the tag wrongly set ? >> >> > >> >> > the tag will be on the 1.8 branch - so possibly you need to switch to >> >> > it. >> >> >> >> That shouldn't be necessary, and actually doesn't show the tags to me. >> >> >> >> Is there anyone else who can't see the v1.8.1 tag, or is it just me? >> > >> > http://git.enlightenment.org/core/efl.git/ >> > >> > cgit can see it. >> >> Doug is right. The tagged commit is not in the efl-1.8 branch (not >> even on master). >> >> This is the 1.8.1 commit on efl-1.8 branch: >> https://git.enlightenment.org/core/efl.git/commit/?h=efl-1.8&id=2af23d998a3be6dc4ef6e9c48d0927821d808014 >> >> And this is the commit that was tagged as v1.8.1: >> https://git.enlightenment.org/core/efl.git/commit/?id=dbc8e3cef9a414bf55dba3f3ddf4e08b85c48b1e >> >> They are different commits. >> >> And I don't know why, but it appears on cgit but doesn't on a local >> branch unless you fetch with --tags. I tried to clone the repository >> again, in a new location, and it still doesn't show the tag. Maybe >> it's because it's not in any branch, so no reason to fetch the tag. > > well i tagged and i had to fix a conflict as well so maybe the tag got "lost" > during the conflict fix somehow. i don't know what git was doing there, but i > committed, tagged and pushed - push failed due to upstream having changed "yet > again!" (seriously. this is why i try to push early because if you don't you > end > up here even more often - git is not a silver bullet), so i pulled, pull had a The problem is that you tagged one commit and pushed a rebased commit *and* the tagged commit (that now isn't on any branch). That's maybe one reason to force the "--tags" to actually push the tags. You can always push the commits first and later tag what is already public. Btw, you can see these things on your machine more easily by using tig, gitk or the like. Lucas De Marchi -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&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/enlightenment] master 01/02: oops - remove debug commit that snuck in!
On Wed, Nov 27, 2013 at 10:28 PM, Carsten Haitzler wrote: > On Thu, 28 Nov 2013 09:22:56 +0900 Carsten Haitzler (The Rasterman) > said: > >> On Wed, 27 Nov 2013 22:08:09 -0200 Lucas De Marchi >> said: >> >> > On Wed, Nov 27, 2013 at 9:50 PM, Carsten Haitzler >> > wrote: >> > > On Wed, 27 Nov 2013 12:33:35 -0200 Lucas De Marchi >> > > said: >> > > >> > >> On Wed, Nov 27, 2013 at 11:57 AM, Carsten Haitzler >> > >> >> > >> wrote: >> > >> > On Wed, 27 Nov 2013 11:51:28 -0200 Gustavo Sverzut Barbieri >> > >> > said: >> > >> > >> > >> >> On Mon, Nov 25, 2013 at 10:16 PM, Carsten Haitzler >> > >> >> wrote: >> > >> >> > On Mon, 25 Nov 2013 17:05:55 -0200 Gustavo Sverzut Barbieri >> > >> >> > said: >> > >> >> > >> > >> >> >> On Mon, Nov 25, 2013 at 10:01 AM, Cedric BAIL >> > >> >> >> >> > >> >> >> wrote: >> > >> >> >> > On Mon, Nov 25, 2013 at 12:30 PM, Tom Hacohen >> > >> >> >> > wrote: >> > >> >> >> >> >> > >> >> >> >> This reminds me. Let's git rid of this changelog and news >> > >> >> >> >> none-sense already. >> > >> >> >> > >> > >> >> >> > Sounds like a good move... when we will have a proven record of >> > >> >> >> > usable commit message to generate a ChangeLog and NEWS from it ! >> > >> >> >> >> > >> >> >> it would be very beautiful to spot bad committers, not only bad >> > >> >> >> messages: >> > >> >> >> >> > >> >> >> Raster(1234): >> > >> >> >>Fix stuff >> > >> >> > >> > >> >> > no such commit log from me (not in efl, elm or e) >> > >> >> > >> > >> >> >>dbg-- >> > >> >> > >> > >> >> > yes - and that tells you want you need to know. removing debugging. >> > >> >> > everythng you need is there. i don't see why it needs to be more >> > >> >> > descriptive. also no such commit log in e, efl or elm >> > >> >> > >> > >> >> >>Fix break due remove dbg >> > >> >> > >> > >> >> > and again - told you what you need to know (and no such commit log >> > >> >> > as above >> > >> >> > - i searched and found none of these). >> > >> >> > >> > >> >> > i wrote all my commit logs ASSUMING people digest them via the svn >> > >> >> > comits list. that means they get the log AND the diff below. if the >> > >> >> > diff is trivial why should i repeat in the log what the diff >> > >> >> > already >> > >> >> > says ? git log -U will do the same. i always did it this way to >> > >> >> > save >> > >> >> > repeating information you already have, but it seems everyone likes >> > >> >> > to not use the information they already have. >> > >> >> >> > >> >> The best (or worse) part of this is that you didn't get the joke. The >> > >> >> problem was not the commit messages, rather the commits themselves. >> > >> >> The above should be like: "Fix stuff" only, not the following 2 >> > >> >> commits that are useless and could be avoided if you didn't push to >> > >> >> git after every commit, instead get them tested and reviewed, being >> > >> >> pushed in a batch afterwards when you're sure work is good. >> > >> > >> > >> > try reviewing the backlog of patch reviews first before suggesting >> > >> > every dev needs to put their commits in for review first. considering >> > >> > the small volume of patches there gets ignored for days or weeks at a >> > >> > time... just wait for the total zero-movement efl and e will do if its >> > >> > done your way. >> > >> >> > >> I don't think he's saying for you to send your commits through >> > >> phabricator or anything like that. The point is... you can git commit, >> > >> then test stuff, do something more, commit again, etc, etc, etc. And >> > >> if it happens to be "oohh... I did a bad commit before", you can just >> > >> squash the commit... After all that you can git push. no need to add >> > >> new commits on top with just printf-- >> > > >> > > "get them tested and reviewed" reads to say to get them tested and >> > > reviewed.. by others. at least in english it does. :) >> > >> > So in English there's no way to say "review your own commits before >> > pushing?" ;-) >> >> yes there is. "review your commits" as opposed to "get your commits >> reviewed". >> the second is a passive construction - the meaning is to have someone (ales) >> review your commits. the first is to say "go review them". > > err "someone (else)"... :) ok. but more important than the english bike shedding, do you understand now? Do you agree? Lucas De Marchi -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&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/enlightenment] master 01/02: oops - remove debug commit that snuck in!
On Wed, Nov 27, 2013 at 9:50 PM, Carsten Haitzler wrote: > On Wed, 27 Nov 2013 12:33:35 -0200 Lucas De Marchi > said: > >> On Wed, Nov 27, 2013 at 11:57 AM, Carsten Haitzler >> wrote: >> > On Wed, 27 Nov 2013 11:51:28 -0200 Gustavo Sverzut Barbieri >> > said: >> > >> >> On Mon, Nov 25, 2013 at 10:16 PM, Carsten Haitzler >> >> wrote: >> >> > On Mon, 25 Nov 2013 17:05:55 -0200 Gustavo Sverzut Barbieri >> >> > said: >> >> > >> >> >> On Mon, Nov 25, 2013 at 10:01 AM, Cedric BAIL >> >> >> wrote: >> >> >> > On Mon, Nov 25, 2013 at 12:30 PM, Tom Hacohen >> >> >> > wrote: >> >> >> >> >> >> >> >> This reminds me. Let's git rid of this changelog and news none-sense >> >> >> >> already. >> >> >> > >> >> >> > Sounds like a good move... when we will have a proven record of >> >> >> > usable >> >> >> > commit message to generate a ChangeLog and NEWS from it ! >> >> >> >> >> >> it would be very beautiful to spot bad committers, not only bad >> >> >> messages: >> >> >> >> >> >> Raster(1234): >> >> >>Fix stuff >> >> > >> >> > no such commit log from me (not in efl, elm or e) >> >> > >> >> >>dbg-- >> >> > >> >> > yes - and that tells you want you need to know. removing debugging. >> >> > everythng you need is there. i don't see why it needs to be more >> >> > descriptive. also no such commit log in e, efl or elm >> >> > >> >> >>Fix break due remove dbg >> >> > >> >> > and again - told you what you need to know (and no such commit log as >> >> > above >> >> > - i searched and found none of these). >> >> > >> >> > i wrote all my commit logs ASSUMING people digest them via the svn >> >> > comits >> >> > list. that means they get the log AND the diff below. if the diff is >> >> > trivial why should i repeat in the log what the diff already says ? git >> >> > log -U will do the same. i always did it this way to save repeating >> >> > information you already have, but it seems everyone likes to not use the >> >> > information they already have. >> >> >> >> The best (or worse) part of this is that you didn't get the joke. The >> >> problem was not the commit messages, rather the commits themselves. >> >> The above should be like: "Fix stuff" only, not the following 2 >> >> commits that are useless and could be avoided if you didn't push to >> >> git after every commit, instead get them tested and reviewed, being >> >> pushed in a batch afterwards when you're sure work is good. >> > >> > try reviewing the backlog of patch reviews first before suggesting every >> > dev >> > needs to put their commits in for review first. considering the small >> > volume of patches there gets ignored for days or weeks at a time... just >> > wait for the total zero-movement efl and e will do if its done your way. >> >> I don't think he's saying for you to send your commits through >> phabricator or anything like that. The point is... you can git commit, >> then test stuff, do something more, commit again, etc, etc, etc. And >> if it happens to be "oohh... I did a bad commit before", you can just >> squash the commit... After all that you can git push. no need to add >> new commits on top with just printf-- > > "get them tested and reviewed" reads to say to get them tested and reviewed.. > by others. at least in english it does. :) So in English there's no way to say "review your own commits before pushing?" ;-) This is one thing that's very different from svn that may take a while to get used to... you can commit, write a good message and wait a little bit before publishing that to others. You can commit and then "git show" to see if everything is in place, there's no printf left, etc etc. Lucas De Marchi -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&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/enlightenment] master 01/02: oops - remove debug commit that snuck in!
On Wed, Nov 27, 2013 at 11:57 AM, Carsten Haitzler wrote: > On Wed, 27 Nov 2013 11:51:28 -0200 Gustavo Sverzut Barbieri > said: > >> On Mon, Nov 25, 2013 at 10:16 PM, Carsten Haitzler >> wrote: >> > On Mon, 25 Nov 2013 17:05:55 -0200 Gustavo Sverzut Barbieri >> > said: >> > >> >> On Mon, Nov 25, 2013 at 10:01 AM, Cedric BAIL wrote: >> >> > On Mon, Nov 25, 2013 at 12:30 PM, Tom Hacohen >> >> > wrote: >> >> >> >> >> >> This reminds me. Let's git rid of this changelog and news none-sense >> >> >> already. >> >> > >> >> > Sounds like a good move... when we will have a proven record of usable >> >> > commit message to generate a ChangeLog and NEWS from it ! >> >> >> >> it would be very beautiful to spot bad committers, not only bad messages: >> >> >> >> Raster(1234): >> >>Fix stuff >> > >> > no such commit log from me (not in efl, elm or e) >> > >> >>dbg-- >> > >> > yes - and that tells you want you need to know. removing debugging. >> > everythng you need is there. i don't see why it needs to be more >> > descriptive. also no such commit log in e, efl or elm >> > >> >>Fix break due remove dbg >> > >> > and again - told you what you need to know (and no such commit log as above >> > - i searched and found none of these). >> > >> > i wrote all my commit logs ASSUMING people digest them via the svn comits >> > list. that means they get the log AND the diff below. if the diff is >> > trivial why should i repeat in the log what the diff already says ? git log >> > -U will do the same. i always did it this way to save repeating information >> > you already have, but it seems everyone likes to not use the information >> > they already have. >> >> The best (or worse) part of this is that you didn't get the joke. The >> problem was not the commit messages, rather the commits themselves. >> The above should be like: "Fix stuff" only, not the following 2 >> commits that are useless and could be avoided if you didn't push to >> git after every commit, instead get them tested and reviewed, being >> pushed in a batch afterwards when you're sure work is good. > > try reviewing the backlog of patch reviews first before suggesting every dev > needs to put their commits in for review first. considering the small volume > of > patches there gets ignored for days or weeks at a time... just wait for the > total zero-movement efl and e will do if its done your way. I don't think he's saying for you to send your commits through phabricator or anything like that. The point is... you can git commit, then test stuff, do something more, commit again, etc, etc, etc. And if it happens to be "oohh... I did a bad commit before", you can just squash the commit... After all that you can git push. no need to add new commits on top with just printf-- Regarding the commit message expecting that people are digesting them through the mailing list... this is bad, because 1, 2 or 3 years from now people won't have the same context and searching through logs is then a nightmare. Lucas De Marchi -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&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/efl] master 02/02: 1.8.0-alpha2
On Nov 19, 2013 4:10 AM, "Tom Hacohen" wrote: > > On 19/11/13 11:04, Carsten Haitzler (The Rasterman) wrote: > > On Tue, 19 Nov 2013 10:49:22 + Tom Hacohen said: > > > >> On 19/11/13 10:47, Carsten Haitzler (The Rasterman) wrote: > >>> On Tue, 19 Nov 2013 10:03:54 + Tom Hacohen < tom.haco...@samsung.com> > >>> said: > >>> > >>>> On 19/11/13 10:05, Carsten Haitzler (The Rasterman) wrote: > >>>>> On Tue, 19 Nov 2013 09:46:32 + Tom Hacohen < tom.haco...@samsung.com> > >>>>> said: > >>>>> > >>>>>> Reminder to whoever tags it: use "git tag -a" i.e an annotated tag. > >>>>> > >>>>> i did. > >>>> > >>>> Please promise me not to hate git, but: > >>>> git push --tags > >>>> :P > >>>> > >>>> Yeah, that's really annoying. > >>> > >>> g! screw you git! :) cant it just pus tags.. when i ... push > >>> normally? :( :( > >>> > >> > >> They must have a good reason for that. :) > > > > to annoy me? :) > > > > No annoy the both of us. :) Count me on the annoyed people about this :) Lucas De Marchi > > -- > Tom. > > -- > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eolian meta-data parsing
On Tue, Oct 22, 2013 at 3:03 PM, Leif Middelschulte
wrote:
> 2013/10/21 daniel.za...@samsung.com :
>> Hi all,
>>
>> I would like to discuss about a project that we are beginning just now.
>> I presented it on EFL dev. day yesterday but I would like to share it
>> here since it will imply all the EFL developers (yes, you) one day or
>> another.
>>
>> It is called Eolian and was first aimed to facilitate addition of new Eo
>> functions by auto-generating code. Then we noted that we can
>> automatically generate language bindings too but it is not the goal of
>> this discussion.
>>
>> The idea is that each Eo class is represented into a .eo file. These
>> files are manually modified to add new functions, comments, callbacks...
>> and parsed and the generation phase updates the C/H files.
>>
>> They contain descriptions of inherited classes, properties, methods,
>> base classes implemented functions and callbacks.
>>
>> We thought about two formats:
>> - a C-like format:
>> Evas_Object_Image =
>> {
>> inherit
>> {
>> Evas_Object;
>> }
>> properties
>> {
>> /* Set the DPI resolution ... */
>> load_dpi(double dpi /* dpi resolution*/);
>> /* Apply the source object's clip to the proxy */
>> source_clip(Eina_Bool source_clip);
>> /* Set whether the image object's fill property ... */
>> filled(Eina_Bool filled);
>> /* Get the kind of looping the image object does. */
>> ro animated_loop_type(
>> Evas_Image_Animated_Loop_Hint hint /* hint */
>> );
>> /* Get the number times the animation of the object loops. */
>> ro animated_loop_count(
>> int loop_count
>> );
>> }
>> methods
>> {
>> /* Set the source object… */
>> source_set(
>> in Evas_Object* src /* in */,
>> out Eina_Bool* result /* out */
>> );
>> /* Get the current source object ... */
>> source_get(
>> out Evas_Object** src /* out */
>> );
>> /* Begin preloading an image … */
>> preload_begin();
>> /* Mark a sub-region of the given ... */
>> data_update_add(
>> in int x /* in */,
>> in int y /* in */,
>> in int w /* in */,
>> in int h /* in */
>> );
>> }
>> }
>>
>> For C developers that we are, it has the advantage to be easier to our
>> eyes. It fits most of the needs but still lacks for specific points:
>> - if we have a property whose comment is different for set and get, how
>> can we describe it? By inserting "tokens" inside the comments
>> themselves, meaning parsing of the comments is needed.
>> - if we want to define a function as virtual pure, do we use the so
>> loved C++ notation "= 0"?
>> - properties that are read-only or write-only (only get or set): do we
>> add some ro/wo parameter, as in the example?
>> ...
>> People complained that it seems too much like C++.
>>
>> - JSON format:
>> {
>> "class_name" : "Evas_Object_Image",
>> "inherits" : [ "Evas_Object" ],
>> "properties" : [
>> {
>> "name" : "load_dpi",
>> "description" : "DPI resolution ...",
>> "parameter" : [
>> {
>> "name" : "dpi",
>> "type" : "double",
>> "description" : "dpi resolution"
>> }
>> }
>> ... (don't have the force to write all ;-)
>> }
>> The format is less intuitive to C developers and there is more to write
>> but it is extensible and so easily solves the issues described in the
>> C-style.
>>
>> So, until yesterday (the day I presented), I really thought we would go
>> on the C (ok, C++) style but now that I saw some faces when I showed the
>> C format and since I want to come back home safe, I prefer asking here.
>>
>> Thank you for your help
>> JackDanielZ, alias Daniel Zomething
>
> Do you want something you'd only write in the text editor?
> If that's not a restriction, have you thought about using UML class
> diagrams? I'm not sure about inlining comments in it, but it has all
> the other features and is XML, so trivially transformable and
> validateable.
no
+1 for json
Lucas De Marchi
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&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/enlightenment] master 01/01: build: Enable subdir-objects option in e_fm
Hi Daniel, On Tue, Oct 15, 2013 at 11:43 AM, Daniel Juyung Seo wrote: > History repeats itself :) At least part of it didn't since it's now fixed ;-) Lucas De Marchi -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&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/enlightenment] master 01/01: build: Enable subdir-objects option in e_fm
Hi Stefan. On Tue, Oct 15, 2013 at 11:23 AM, Stefan Schmidt wrote: > Hello. > > On 10/15/2013 03:13 PM, Lucas De Marchi wrote: >> demarchi pushed a commit to branch master. >> >> http://git.enlightenment.org/core/enlightenment.git/commit/?id=c8a624cc85630796c245852fc7c60fc2d5874d37 >> >> commit c8a624cc85630796c245852fc7c60fc2d5874d37 >> Author: Lucas De Marchi >> Date: Tue Oct 15 10:46:09 2013 -0300 >> >> build: Enable subdir-objects option in e_fm >> >> Sadly we can't globally enable subdir-objects due to gettext choking on >> it so enable at least where it's necessary. Remove the following >> warning from build: >> >> src/bin/e_fm/Makefile.am:40: warning: source file '../e_prefix.c' is >> in a subdirectory, >> src/bin/e_fm/Makefile.am:40: but option 'subdir-objects' is disabled >> automake: warning: possible forward-incompatibility. >> automake: At least a source file is in a subdirectory, but the >> 'subdir-objects' >> automake: automake option hasn't been enabled. For now, the >> corresponding output >> automake: object file(s) will be placed in the top-level directory. >> However, >> automake: this behaviour will change in future Automake versions: >> they will >> automake: unconditionally cause object files to be placed in the >> same subdirectory >> automake: of the corresponding sources. >> automake: You are advised to start using 'subdir-objects' option >> throughout your >> automake: project, to avoid future incompatibilities. >> src/bin/e_fm/Makefile.am:43: warning: source file >> '../e_fm_shared_codec.c' is in a subdirectory, >> src/bin/e_fm/Makefile.am:43: but option 'subdir-objects' is disabled >> src/bin/e_fm/Makefile.am:43: warning: source file >> '../e_fm_shared_device.c' is in a subdirectory, >> src/bin/e_fm/Makefile.am:43: but option 'subdir-objects' is disabled >> src/bin/e_fm/Makefile.am:43: warning: source file '../e_user.c' is >> in a subdirectory, >> src/bin/e_fm/Makefile.am:43: but option 'subdir-objects' is disabled >> src/bin/e_fm/Makefile.am:43: warning: source file '../e_sha1.c' is >> in a subdirectory, >> src/bin/e_fm/Makefile.am:43: but option 'subdir-objects' is disabled >> --- >> src/bin/e_fm/Makefile.am | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/src/bin/e_fm/Makefile.am b/src/bin/e_fm/Makefile.am >> index 083839c..2a9a9ce 100644 >> --- a/src/bin/e_fm/Makefile.am >> +++ b/src/bin/e_fm/Makefile.am >> @@ -1,4 +1,5 @@ >> MAINTAINERCLEANFILES = Makefile.in >> +AUTOMAKE_OPTIONS = subdir-objects >> >> AM_CFLAGS = \ >> -I$(top_builddir) >> > > Herew we are again. Mike added that in > 21f4a15c90a735a61b8be2013d4e3796aece1e01 and I reverted it in > 606b1715c1a48e5e3548c29936ca5a635c29e382 as it breaks make distcheck. Thanks for pointing this out. > > If you are going fix make distcheck with this its fine to stay. It's now fixed, along with another fix for distcheck Lucas De Marchi -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/enlightenment] master 01/02: build: Fix failing to install unit file on distcheck
demarchi pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=219ef659b1ae22c9286d2e5dce77d24227c6d3f5 commit 219ef659b1ae22c9286d2e5dce77d24227c6d3f5 Author: Lucas De Marchi Date: Tue Oct 15 21:06:53 2013 -0300 build: Fix failing to install unit file on distcheck During distcheck we fail to install the systemd user session unit file because it's trying to install to the place returned by pkg-config. We could add a --with-systemduserunitdir= and set it to a proper install place. This is done in some other programs like systemd. However there's not much to test for the unit files installation during distcheck so just pass --disable-systemd that will do the right thing. Fix the error below: /usr/bin/install -c -m 644 e18.service '/usr/lib/systemd/user' /usr/bin/install: cannot remove ‘/usr/lib/systemd/user/e18.service’: Permission denied make[4]: *** [install-unitsDATA] Error 1 make[4]: Leaving directory `/home/lucas/p/e/enlightenment/enlightenment-0.17.99.17181/_build/data/units' make[3]: *** [install-am] Error 2 make[3]: Leaving directory `/home/lucas/p/e/enlightenment/enlightenment-0.17.99.17181/_build/data/units' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/home/lucas/p/e/enlightenment/enlightenment-0.17.99.17181/_build/data' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/lucas/p/e/enlightenment/enlightenment-0.17.99.17181/_build' make: *** [distcheck] Error 1 --- Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile.am b/Makefile.am index 17c74b1..0408b9b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -66,6 +66,8 @@ po/Rules-quot endif +DISTCHECK_CONFIGURE_FLAGS = --disable-systemd + EXTRA_DIST = config.rpath README AUTHORS COPYING \ enlightenment.spec.in enlightenment.spec enlightenment.pc --
[EGIT] [core/enlightenment] master 02/02: build: Fix distcheck due to subdir sources
demarchi pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=a1cb1e4671014529840c03291b6e1f06078dbb7e commit a1cb1e4671014529840c03291b6e1f06078dbb7e Author: Lucas De Marchi Date: Wed Oct 16 01:20:40 2013 -0300 build: Fix distcheck due to subdir sources enlightenment_fm needs some files that are not in its subdirectory, but rather are shared with enlightenment. Possible solutions: 1) Use a non-recursive build for enlightenment_fm. 2) Factor out a convenience library containing necessary files 3) Copy over or link the files to build tree directory during build For simplicity (3) is implemented here. Some files were not necessary (e_prefix.c and e_sha1.c) and the others are now linked during build to it's original location. --- src/bin/e_fm/.gitignore | 4 src/bin/e_fm/Makefile.am | 16 +++- 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/src/bin/e_fm/.gitignore b/src/bin/e_fm/.gitignore new file mode 100644 index 000..d98d934 --- /dev/null +++ b/src/bin/e_fm/.gitignore @@ -0,0 +1,4 @@ +/e_fm_shared_codec.c +/e_fm_shared_device.c +/e_user.c + diff --git a/src/bin/e_fm/Makefile.am b/src/bin/e_fm/Makefile.am index 2a9a9ce..dba628a 100644 --- a/src/bin/e_fm/Makefile.am +++ b/src/bin/e_fm/Makefile.am @@ -34,13 +34,17 @@ if HAVE_EEZE_MOUNT AM_CFLAGS += @EEZE_CFLAGS@ @EET_CFLAGS@ LIBS += @EEZE_LIBS@ @EET_LIBS@ eeze_s = \ -../e_prefix.c \ e_fm_main_eeze.h \ e_fm_main_eeze.c else eeze_s = endif +shared_sources = \ +e_fm_shared_codec.c \ +e_fm_shared_device.c \ +e_user.c + enlightenment_fm_SOURCES = \ e_fm_main.h \ e_fm_ipc.h \ @@ -48,9 +52,11 @@ e_fm_main.c \ e_fm_ipc.c \ $(udisks_s) \ $(eeze_s) \ -../e_fm_shared_codec.c \ -../e_fm_shared_device.c \ -../e_user.c \ -../e_sha1.c +$(shared_sources) + +$(shared_sources): %.c: $(abs_top_srcdir)/src/bin/%.c + $(AM_V_GEN) $(LN_S) -f $< $@ + +CLEANFILES = $(shared_sources) enlightenment_fm_LDADD = @E_FM_LIBS@ --
[EGIT] [core/enlightenment] master 01/01: build: Enable subdir-objects option in e_fm
demarchi pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=c8a624cc85630796c245852fc7c60fc2d5874d37 commit c8a624cc85630796c245852fc7c60fc2d5874d37 Author: Lucas De Marchi Date: Tue Oct 15 10:46:09 2013 -0300 build: Enable subdir-objects option in e_fm Sadly we can't globally enable subdir-objects due to gettext choking on it so enable at least where it's necessary. Remove the following warning from build: src/bin/e_fm/Makefile.am:40: warning: source file '../e_prefix.c' is in a subdirectory, src/bin/e_fm/Makefile.am:40: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. src/bin/e_fm/Makefile.am:43: warning: source file '../e_fm_shared_codec.c' is in a subdirectory, src/bin/e_fm/Makefile.am:43: but option 'subdir-objects' is disabled src/bin/e_fm/Makefile.am:43: warning: source file '../e_fm_shared_device.c' is in a subdirectory, src/bin/e_fm/Makefile.am:43: but option 'subdir-objects' is disabled src/bin/e_fm/Makefile.am:43: warning: source file '../e_user.c' is in a subdirectory, src/bin/e_fm/Makefile.am:43: but option 'subdir-objects' is disabled src/bin/e_fm/Makefile.am:43: warning: source file '../e_sha1.c' is in a subdirectory, src/bin/e_fm/Makefile.am:43: but option 'subdir-objects' is disabled --- src/bin/e_fm/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/bin/e_fm/Makefile.am b/src/bin/e_fm/Makefile.am index 083839c..2a9a9ce 100644 --- a/src/bin/e_fm/Makefile.am +++ b/src/bin/e_fm/Makefile.am @@ -1,4 +1,5 @@ MAINTAINERCLEANFILES = Makefile.in +AUTOMAKE_OPTIONS = subdir-objects AM_CFLAGS = \ -I$(top_builddir) \ --
Re: [E-devel] Creating enlightenment module with C++
On Thu, Oct 10, 2013 at 9:03 PM, Felipe Magno de Almeida wrote: > Hello, > > Currently, writing modules for enlightenment using C++ is not possible > without modifying headers from enlightenment. > > How is the policy for these headers w.r.t C++ compatibility? > > The most common problems are: > * Lack of extern "C"; > * The use of C++ keywords, e.g., class (replaced for klass); > * Functions and macros defined in the header with implicit conversion > from unrelated pointer types; > * Typedefs before definition or declaration of the typedef'ed UDT. I find intriguing why would anyone create an enlightenment module in c++. What are the advantages? I think that if someone steps up to maintain the C++ compatibility and send useful modules to the project, it would be welcome. I don't think doing only the first one makes much sense. Anyway, not my call to decide. Lucas De Marchi -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&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/enlightenment] master 01/01: music control: add Clementine
On Mon, Oct 7, 2013 at 1:17 PM, q66 wrote:
> quaker pushed a commit to branch master.
>
> http://git.enlightenment.org/core/enlightenment.git/commit/?id=8e860facf4eb30a57883569cadf897f9ec5375d5
>
> commit 8e860facf4eb30a57883569cadf897f9ec5375d5
> Author: q66
> Date: Mon Oct 7 18:16:42 2013 +0200
>
> music control: add Clementine
> ---
> src/modules/music-control/e_mod_main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/modules/music-control/e_mod_main.c
> b/src/modules/music-control/e_mod_main.c
> index bd57d13..3dbd279 100644
> --- a/src/modules/music-control/e_mod_main.c
> +++ b/src/modules/music-control/e_mod_main.c
> @@ -12,6 +12,7 @@ const Player music_player_players[] =
> {
> {"gmusicbrowser", "org.mpris.MediaPlayer2.gmusicbrowser"},
> {"Banshee", "org.mpris.MediaPlayer2.banshee"},
> + {"Clementine", "org.mpris.MediaPlayer2.clementine"},
> {"Audacious", "org.mpris.MediaPlayer2.audacious"},
> {"VLC", "org.mpris.MediaPlayer2.vlc"},
> {"BMP", "org.mpris.MediaPlayer2.bmp"},
Why are we doing this instead of calling ListNames and installing a
match rule with
member='NameOwnerChanged',arg0namespace='org.mpris.MediaPlayer2'?
If the player is activatable through d-bus
(o.f.d.ListActivatableNames) we could even start the player ourselves.
Lucas De Marchi
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On Fri, Oct 4, 2013 at 7:05 AM, Carsten Haitzler wrote: > On Fri, 04 Oct 2013 11:42:35 +0200 Bertrand Jacquin said: > >> > steps 3, 4, 5, 6, 8... are an incantation. to be done in that order. >> > there is >> > --no-ff... and he series.. its a DEFINITE incantation. read up on git >> > as a >> > leaky abstraction. it is very much one. it forces peole to learn a >> > series of >> > incantations/steps all the time as opposed to just having a single "do >> > X" where >> > X is always the same series of steps. why do it by hand. why have to >> > LEARN by >> > heart and then of course get it wrong at times >> >> Officially, raster is now a high level manager ! >> >> Theses incantation are quite straight forward when you use git daily. >> Not at the first use, but become fast essential. > > i use git every day.. but i dont go making private branches and merging them. > even then, take a look at my aliases and scripts dir. i fail to understand how > many people survive doing everything manually by hand. i see it all around me. > they do the full command like: > > ps -ef | grep X > > when i do: > > psg X > > why? i get tired of memorizing N steps or magic incantations. i do NOT do: > > ./autogen.sh && > make && > sudo make install > > i do: > > cmi > > i never do: > > make && > sudo make install > > i do: > > mi why not use names like a, b, c, d, e...? I guess it would be easier for you to remember all the aliases. > > why? i can't stand having to memorize a tonneof obscure incantations that make > little sense outside of the leaky abstraction that is git: > > http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ > https://news.ycombinator.com/item?id=3891598 > > you may love doing it all by hand and find great pleasure in twisting your > brain to work and think like gits internals do, but i do not. i want to > perform a simple task and git turns it into a job of remembering a magic > incantation. i keep now having to build scripts that wrap git stuff up so i > dont have to do N steps and maybe forget one. > > the same people who say "omg git is so awesome! it has git bisect! svn sucks! > it is the worst thing. it doesnt have bisect" have a set of standards that > think doing other SIMPLE stuff that svn does in a single cmd is ok to break > into a dozen steps in git with a bunch of cmdline opts u have to keep looking > up, and if in svn i had to write a small script to do a bisect (which was > perfectly possible too) then svn insta-sucks. but having to wrap up git or > memorize a vast series of steps for everything u need to do in git is > perfectly > fine and great! > > git is a poor tool. it's interface is poor. it does some cool stuff - but as a > tool it is poor. if you want people to follow conventions/procedures, don't > make them have to read your powerpoint on them and study them and memorize the > document/process. (and the people here know what i'm referring to). make the > TOOL doe the thing for you obviously and simply. for git that would normally > mean patching it (not as easy), but a simple wrapper does the job. don't > define > a document to describe a process - encapsulate it in a simple tool (script). I was going to reply, but then the complaints became too entertaining. Instead acidx gave me this link that I'd like to share: http://usvsth3m.co.uk/javascript-under-pressure/torvalds.gif Lucas De Marchi -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&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/efl] master 01/05: eina: add infrastructure to handle more CPU and compiler builtin information.
On Fri, Oct 4, 2013 at 1:09 AM, Cedric BAIL wrote:
> On Thu, Oct 3, 2013 at 4:11 AM, Lucas De Marchi
> wrote:
>> On Wed, Oct 2, 2013 at 8:57 AM, Cedric Bail wrote:
>>> cedric pushed a commit to branch master.
>>>
>>> http://git.enlightenment.org/core/efl.git/commit/?id=ff3d2a68d5762ec6bed88f97f2a3751bb51caf86
>>>
>>> commit ff3d2a68d5762ec6bed88f97f2a3751bb51caf86
>>> Author: Cedric Bail
>>> Date: Wed Oct 2 18:31:10 2013 +0900
>>>
>>> eina: add infrastructure to handle more CPU and compiler builtin
>>> information.
>>> ---
>
> [snip]
>
>>> +static inline unsigned short eina_swap16(unsigned short x);
>>> +static inline unsigned int eina_swap32(unsigned int x);
>>> +static inline unsigned long long eina_swap64(unsigned long long x);
>>
>> what's wrong with bswap_{32,16,64}? At least with gcc the correct
>> bswap instruction is emitted when available.
>
> Your millage may vary depending on your compiler or its version. Mine
> on an very old ubuntu doesn't. Same goes with LLVM.
Then I'd say to fix the compiler instead of adding API that we will
need to carry on. These will become the Eina_Bool of tomorrow.
Lucas De Marchi
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git, merges, and better work-flows
On Thu, Oct 3, 2013 at 12:25 AM, Carsten Haitzler wrote: > On Thu, 3 Oct 2013 00:10:17 -0300 Lucas De Marchi > said: > >> On Wed, Oct 2, 2013 at 11:55 PM, Carsten Haitzler >> wrote: >> > On Wed, 02 Oct 2013 16:20:38 +0100 Tom Hacohen >> > said: >> > >> >> On 02/10/13 16:17, Tom Hacohen wrote: >> >> > Hey guys, >> >> > >> >> > I would like to suggest a new work-flow. This work-flow will not be >> >> > mandatory, but just an allowed alternative to the current "commit to >> >> > master" approach. >> >> > >> >> > At the moment we do not allow merges, at all. This was to prevent people >> >> > from littering the log with their inability to rebase (git pull >> >> > --rebase) their local changes on top of the existing commits. This will >> >> > still remain the same. I'd like to suggest using merges to our >> >> > advantage. >> >> > >> >> > I suggest the following: >> >> > For fixes, small features, and the like, do the same as you do now. >> >> > Commit and push to master. >> >> > >> >> > For bigger features, rewrites, or any form of a few commits that are >> >> > tied together by being part of the same set, do as follows (it's >> >> > obviously simpler than that, I listed everything to over-simplify >> >> > things): >> >> > 1. Create a branch (either local or remote) for your change. >> >> > 2. Work on that branch. >> >> > 3. When ready, instead of pushing to master: >> >> > 3. rebase over master (git fetch; git rebase origin/master). >> >> > 4. switch to master (git checkout master) >> >> > 6. git merge --no-ff your-feature-branch-name >> >> > 7. Describe your feature in the commit message. >> >> > 8. push to master (git push or git push origin master). >> >> > >> >> > I've done a few example commits on >> >> > https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ >> >> > >> >> > This work-flow lets us have linear history, while having feature-sets >> >> > show as a single merge that can easily be reverted, provide a good >> >> > description about a feature and the commits that introduced it and I >> >> > find generally easier for the eye. There are also technical advantages, >> >> > for example, if you run "git log --first-parent" you will only see the >> >> > merge commits, cleaning the log from all the fluff involving a feature >> >> > letting you just see the feature. Another advantage is that "git bisect" >> >> > will not go inside the merged branch unless the issue was introduced >> >> > there. >> >> > >> >> > Please feel free to inspect my repo, more specifically, the log: >> >> > https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ >> >> > >> >> > To see how it looks. >> >> > >> >> > Important note: commits on the merge branch should be treated as if they >> >> > are on master, that is, don't use this as an excuse to make ugly commits >> >> > with bad commit messages. >> >> > >> >> > Again: I'm not trying to make it mandatory, just to allow this sort of >> >> > merges. >> >> > >> >> > Please let me know what you think. >> >> I have no strong opinion. I have no problems with merges *when they >> are well defined*, i.e. it's either a feature that is properly split >> in multiple commits, or when there are people maintaining parts of the >> tree and periodically merge them (like in linux kernel). And in those >> cases even not being FF I think is ok. >> >> I'd say let's give it a try for those who want to. >> >> >> >> >> Needless to say, that if agreed upon, I will add some documentation >> >> about how best to follow this work-flow. >> > >> > write some mini tools/scripts. not just docs. if any step in such a >> > workflow >> > involves knowing some magic git incantation and/or more than 1 step, then >> > wrap it up. eg. >> > >> > gitfeature-start BRANCHNAME >> > gitfeature-merge >> >> humn... I don't think creating this beforehand makes any good. Th
Re: [E-devel] Git, merges, and better work-flows
On Wed, Oct 2, 2013 at 11:55 PM, Carsten Haitzler wrote: > On Wed, 02 Oct 2013 16:20:38 +0100 Tom Hacohen said: > >> On 02/10/13 16:17, Tom Hacohen wrote: >> > Hey guys, >> > >> > I would like to suggest a new work-flow. This work-flow will not be >> > mandatory, but just an allowed alternative to the current "commit to >> > master" approach. >> > >> > At the moment we do not allow merges, at all. This was to prevent people >> > from littering the log with their inability to rebase (git pull >> > --rebase) their local changes on top of the existing commits. This will >> > still remain the same. I'd like to suggest using merges to our advantage. >> > >> > I suggest the following: >> > For fixes, small features, and the like, do the same as you do now. >> > Commit and push to master. >> > >> > For bigger features, rewrites, or any form of a few commits that are >> > tied together by being part of the same set, do as follows (it's >> > obviously simpler than that, I listed everything to over-simplify things): >> > 1. Create a branch (either local or remote) for your change. >> > 2. Work on that branch. >> > 3. When ready, instead of pushing to master: >> > 3. rebase over master (git fetch; git rebase origin/master). >> > 4. switch to master (git checkout master) >> > 6. git merge --no-ff your-feature-branch-name >> > 7. Describe your feature in the commit message. >> > 8. push to master (git push or git push origin master). >> > >> > I've done a few example commits on >> > https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/ >> > >> > This work-flow lets us have linear history, while having feature-sets >> > show as a single merge that can easily be reverted, provide a good >> > description about a feature and the commits that introduced it and I >> > find generally easier for the eye. There are also technical advantages, >> > for example, if you run "git log --first-parent" you will only see the >> > merge commits, cleaning the log from all the fluff involving a feature >> > letting you just see the feature. Another advantage is that "git bisect" >> > will not go inside the merged branch unless the issue was introduced there. >> > >> > Please feel free to inspect my repo, more specifically, the log: >> > https://git.enlightenment.org/devs/tasn/git-work-flow-example.git/log/ >> > >> > To see how it looks. >> > >> > Important note: commits on the merge branch should be treated as if they >> > are on master, that is, don't use this as an excuse to make ugly commits >> > with bad commit messages. >> > >> > Again: I'm not trying to make it mandatory, just to allow this sort of >> > merges. >> > >> > Please let me know what you think. I have no strong opinion. I have no problems with merges *when they are well defined*, i.e. it's either a feature that is properly split in multiple commits, or when there are people maintaining parts of the tree and periodically merge them (like in linux kernel). And in those cases even not being FF I think is ok. I'd say let's give it a try for those who want to. >> >> Needless to say, that if agreed upon, I will add some documentation >> about how best to follow this work-flow. > > write some mini tools/scripts. not just docs. if any step in such a workflow > involves knowing some magic git incantation and/or more than 1 step, then wrap > it up. eg. > > gitfeature-start BRANCHNAME > gitfeature-merge humn... I don't think creating this beforehand makes any good. This invariably ends up with horribly big scripts and people not really understanding what's going on. In his description I don't see any git incantation... they are just the normal commands of every day. Lucas De Marchi -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&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/efl] master 01/05: eina: add infrastructure to handle more CPU and compiler builtin information.
friends
> +
> + return EINA_TRUE;
> +}
> +
> +Eina_Bool
> +eina_cpu_shutdown(void)
> +{
> + return EINA_TRUE;
> +}
> +
> /**
> *
> * @return
> */
> EAPI Eina_Cpu_Features eina_cpu_features_get(void)
> {
> - Eina_Cpu_Features ecf = 0;
> -#if defined(__i386__) || defined(__x86_64__)
> - _x86_simd(&ecf);
> -#endif
> - return ecf;
> + return eina_cpu_features;
> }
>
> static int _cpu_count = -1;
> diff --git a/src/lib/eina/eina_cpu.h b/src/lib/eina/eina_cpu.h
> index ac32e1d..651d925 100644
> --- a/src/lib/eina/eina_cpu.h
> +++ b/src/lib/eina/eina_cpu.h
> @@ -31,9 +31,20 @@ typedef enum _Eina_Cpu_Features
> EINA_CPU_ALTIVEC = 0x0010,
> EINA_CPU_VIS = 0x0020,
> EINA_CPU_NEON = 0x0040,
> + EINA_CPU_SSSE3 = 0x0080,
> + EINA_CPU_SSE41 = 0x0100,
> + EINA_CPU_SSE42 = 0x0200
> } Eina_Cpu_Features;
>
> +EAPI extern Eina_Cpu_Features eina_cpu_features;
> +
> EAPI Eina_Cpu_Features eina_cpu_features_get(void);
> EAPI int eina_cpu_count(void);
>
> +static inline unsigned short eina_swap16(unsigned short x);
> +static inline unsigned int eina_swap32(unsigned int x);
> +static inline unsigned long long eina_swap64(unsigned long long x);
what's wrong with bswap_{32,16,64}? At least with gcc the correct
bswap instruction is emitted when available.
Lucas De Marchi
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&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: Revert "eina: add functions to alloc strings from a printf fmt"
lucas pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=ad76ce025c024ef0909292c791bc6f0836761f54
commit ad76ce025c024ef0909292c791bc6f0836761f54
Author: Lucas De Marchi
Date: Wed Sep 25 22:51:03 2013 -0300
Revert "eina: add functions to alloc strings from a printf fmt"
This reverts commit b5fce696c743c50ea0a049c4f879756b5ed231d4 and fixes
to NEWS and @since that came later.
These functions are pretty trivial and their functionality can be
obtained with asprintf() and snprintf. The first is not available only
on windows, but there's an implementation for that one on Evil, that
should be used instead.
---
ChangeLog | 1 -
NEWS| 1 -
src/lib/eina/eina_str.c | 41 -
src/lib/eina/eina_str.h | 33 -
4 files changed, 76 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 08204e8..72873d0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -14,7 +14,6 @@
2013-09-24 Jorge Zapata
* Eina: add a substraction in rectangles and more helpers,
- add functions to alloc strings from a printf format,
add double_from/to and helper defines in f16p16.
2013-09-12 Jihoon Kim
diff --git a/NEWS b/NEWS
index 0dd45af..e40c53f 100644
--- a/NEWS
+++ b/NEWS
@@ -39,7 +39,6 @@ Additions:
- Add eina_rectangle_is_valid(), eina_rectangle_max_x(),
eina_rectangle_max_y(), eina_rectangle_x_cut(),
eina_rectangle_y_cut(), eina_rectangle_width_cut(),
eina_rectangle_height_cut(), eina_rectangle_subtract(),
EINA_RECTANGLE_INIT, EINA_RECTANGLE_FORMAT, EINA_RECTANGLE_ARGS.
- - Add eina_str_vprintf_length(), eina_str_vprintf_dup(),
eina_str_printf_dup().
- Add eina_f16p16_double_from(), eina_f16p16_double_to().
* Eet:
- Add eet_mmap()
diff --git a/src/lib/eina/eina_str.c b/src/lib/eina/eina_str.c
index 283476b..11fef3c 100644
--- a/src/lib/eina/eina_str.c
+++ b/src/lib/eina/eina_str.c
@@ -652,44 +652,3 @@ eina_str_toupper(char **str)
for (p = *str; (*p); p++)
*p = toupper((unsigned char)(*p));
}
-
-EAPI size_t
-eina_str_vprintf_length(const char *format, va_list args)
-{
-char c;
-size_t len;
-
-len = vsnprintf(&c, 1, format, args) + 1;
-return len;
-}
-
-EAPI char *
-eina_str_vprintf_dup(const char *format, va_list args)
-{
-size_t length;
-char *ret;
-va_list copy;
-
-/* be sure to use a copy or the printf implementation will
- * step into the args
- */
-va_copy(copy, args);
-length = eina_str_vprintf_length(format, copy);
-va_end(copy);
-
-ret = calloc(length, sizeof(char));
-vsprintf(ret, format, args);
-return ret;
-}
-
-EAPI char *
-eina_str_printf_dup(const char *format, ...)
-{
-char *ret;
-va_list args;
-
-va_start(args, format);
-ret = eina_str_vprintf_dup(format, args);
-va_end(args);
-return ret;
-}
diff --git a/src/lib/eina/eina_str.h b/src/lib/eina/eina_str.h
index 615cc71..dae592b 100644
--- a/src/lib/eina/eina_str.h
+++ b/src/lib/eina/eina_str.h
@@ -345,39 +345,6 @@ static inline size_t eina_str_join(char *dst, size_t size,
char sep, const char
static inline size_t eina_strlen_bounded(const char *str, size_t maxlen)
EINA_PURE EINA_WARN_UNUSED_RESULT EINA_ARG_NONNULL(1);
-/**
- * @brief Gets the length needed for a string based on a printf format and args
- *
- * @param format The printf format
- * @param args The printf args
- * @return The length needed for such format and args
- * @since 1.8
- */
-EAPI size_t eina_str_vprintf_length(const char *format, va_list args);
-
-/**
- * @brief Gets a newly allocated string that represents the printf format and
args
- *
- * @param format The printf format
- * @param args The printf args
- * @return A newly allocated string
- *
- * @see eina_str_dup_printf
- * @since 1.8
- */
-EAPI char * eina_str_vprintf_dup(const char *format, va_list args);
-
-/**
- * @brief Gets a newly allocated string that represents the printf format and
args
- *
- * @param format The printf format
- * @return A newly allocated string
- *
- * @see eina_str_dup_vprintf
- * @since 1.8
- */
-EAPI char * eina_str_printf_dup(const char *format, ...);
-
#include "eina_inline_str.x"
/**
--
[EGIT] [admin/devs] master 01/01: dev--
lucas pushed a commit to branch master.
http://git.enlightenment.org/admin/devs.git/commit/?id=7f1d7ceab3085e1c491134d6745a2dafa6389d76
commit 7f1d7ceab3085e1c491134d6745a2dafa6389d76
Author: Lucas De Marchi
Date: Wed Sep 25 22:53:44 2013 -0300
dev--
dev++ and update my info.
---
{lucas => demarchi}/icon-map.png | Bin
{lucas => demarchi}/icon-med.png | Bin
{lucas => demarchi}/icon-sml.png | Bin
{lucas => demarchi}/id_rsa.pub | 0
{lucas => demarchi}/info.txt | 8
5 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lucas/icon-map.png b/demarchi/icon-map.png
similarity index 100%
rename from lucas/icon-map.png
rename to demarchi/icon-map.png
diff --git a/lucas/icon-med.png b/demarchi/icon-med.png
similarity index 100%
rename from lucas/icon-med.png
rename to demarchi/icon-med.png
diff --git a/lucas/icon-sml.png b/demarchi/icon-sml.png
similarity index 100%
rename from lucas/icon-sml.png
rename to demarchi/icon-sml.png
diff --git a/lucas/id_rsa.pub b/demarchi/id_rsa.pub
similarity index 100%
rename from lucas/id_rsa.pub
rename to demarchi/id_rsa.pub
diff --git a/lucas/info.txt b/demarchi/info.txt
similarity index 55%
rename from lucas/info.txt
rename to demarchi/info.txt
index ad09aca..01132a4 100644
--- a/lucas/info.txt
+++ b/demarchi/info.txt
@@ -1,10 +1,10 @@
-Login: lucas
+Login: demarchi
IRC Nick: demarchi
Name: Lucas De Marchi
-Location: Limeira, Brazil
-E-Mail: lucas.demar...@profusion.mobi
+Location: Campinas, Brazil
+E-Mail: lucas.demar...@intel.com
WWW:http://www.politreco.com
-Contributing: e, e_dbus, elementary, ecore, evas, eina
+Contributing: eldbus, enlightenment, eina
Group: Core, Libraries
Platform: Arch (Linux)
GeoData:-22.753731,-47.34435
--
Re: [E-devel] [EGIT] [core/efl] master 04/04: eina: add functions to alloc strings from a printf fmt
On Tue, Sep 24, 2013 at 11:03 AM, Lucas De Marchi
wrote:
> On Tue, Sep 24, 2013 at 3:29 AM, Cedric BAIL wrote:
>> On Tue, Sep 24, 2013 at 2:14 PM, Lucas De Marchi
>> wrote:
>>> On Tue, Sep 24, 2013 at 12:20 AM, Jorge Zapata
>>> wrote:
>>>> cedric pushed a commit to branch master.
>>>>
>>>> http://git.enlightenment.org/core/efl.git/commit/?id=b5fce696c743c50ea0a049c4f879756b5ed231d4
>>>>
>>>> commit b5fce696c743c50ea0a049c4f879756b5ed231d4
>>>> Author: Jorge Zapata
>>>> Date: Mon Sep 23 21:13:18 2013 +0200
>>>>
>>>> eina: add functions to alloc strings from a printf fmt
>>>> ---
>>>> src/lib/eina/eina_str.c | 41 +
>>>> src/lib/eina/eina_str.h | 33 +
>>>> 2 files changed, 74 insertions(+)
>>>>
>>>> diff --git a/src/lib/eina/eina_str.c b/src/lib/eina/eina_str.c
>>>> index 11fef3c..283476b 100644
>>>> --- a/src/lib/eina/eina_str.c
>>>> +++ b/src/lib/eina/eina_str.c
>>>> @@ -652,3 +652,44 @@ eina_str_toupper(char **str)
>>>> for (p = *str; (*p); p++)
>>>>*p = toupper((unsigned char)(*p));
>>>> }
>>>> +
>>>> +EAPI size_t
>>>> +eina_str_vprintf_length(const char *format, va_list args)
>>>> +{
>>>> +char c;
>>>> +size_t len;
>>>> +
>>>> +len = vsnprintf(&c, 1, format, args) + 1;
>>>> +return len;
>>>
>>> this is wrong if
>>>
>>> 1) vsnprintf returns an error (for example if there's a wrong format
>>> string)
>>> 2) format is "" - return value value should be 0, but will be 1
>>>
>>> If you change the return value to ssize_t it's better and simpler if you do:
>>>
>>> "return vsnprintf(NULL, 0, format, args);"
>>>
>>> If you prefer to ignore the error and continue with an unsigned type,
>>> then you should check the return value for < 0 before returning.
>>>
>>>> +}
>>>> +
>>>> +EAPI char *
>>>> +eina_str_vprintf_dup(const char *format, va_list args)
>>>> +{
>>>> +size_t length;
>>>> +char *ret;
>>>> +va_list copy;
>>>> +
>>>> +/* be sure to use a copy or the printf implementation will
>>>> + * step into the args
>>>> + */
>>>> +va_copy(copy, args);
>>>> +length = eina_str_vprintf_length(format, copy);
>>>> +va_end(copy);
>>>> +
>>>> +ret = calloc(length, sizeof(char));
>>>
>>> malloc instead? you are replacing all the chars below
>>>
>>>> +vsprintf(ret, format, args);
>>>> +return ret;
>>>> +}
>>>> +
>>>> +EAPI char *
>>>> +eina_str_printf_dup(const char *format, ...)
>>>> +{
>>>> +char *ret;
>>>> +va_list args;
>>>> +
>>>> +va_start(args, format);
>>>> +ret = eina_str_vprintf_dup(format, args);
>>>> +va_end(args);
>>>> +return ret;
>>>> +}
>>>
>>> why these instead of plain (v)asprintf?
>>
>> "These functions are GNU extensions, not in C or POSIX.", straight
>> from the man page...
>
> sure... and they are available everywhere.
I just committed some fixes and related changes, please take a look:
devs/lucas/fix-eina-newfuncs
Why is there only eina_str_vprintf_length() and not eina_str_printf_length()?
As I said above IMO we could remove the check for asprintf since it's
in general available on everywhere... we use asprintf() in some other
places already and the only platform that doesn't have it have the
impl in evil_printf.h.
I still think there isn't much point in adding these APIs
otherwise let's at least let their implementation correct.
Lucas De Marchi
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&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/efl] master 04/04: eina: add functions to alloc strings from a printf fmt
On Tue, Sep 24, 2013 at 3:29 AM, Cedric BAIL wrote:
> On Tue, Sep 24, 2013 at 2:14 PM, Lucas De Marchi
> wrote:
>> On Tue, Sep 24, 2013 at 12:20 AM, Jorge Zapata
>> wrote:
>>> cedric pushed a commit to branch master.
>>>
>>> http://git.enlightenment.org/core/efl.git/commit/?id=b5fce696c743c50ea0a049c4f879756b5ed231d4
>>>
>>> commit b5fce696c743c50ea0a049c4f879756b5ed231d4
>>> Author: Jorge Zapata
>>> Date: Mon Sep 23 21:13:18 2013 +0200
>>>
>>> eina: add functions to alloc strings from a printf fmt
>>> ---
>>> src/lib/eina/eina_str.c | 41 +
>>> src/lib/eina/eina_str.h | 33 +
>>> 2 files changed, 74 insertions(+)
>>>
>>> diff --git a/src/lib/eina/eina_str.c b/src/lib/eina/eina_str.c
>>> index 11fef3c..283476b 100644
>>> --- a/src/lib/eina/eina_str.c
>>> +++ b/src/lib/eina/eina_str.c
>>> @@ -652,3 +652,44 @@ eina_str_toupper(char **str)
>>> for (p = *str; (*p); p++)
>>>*p = toupper((unsigned char)(*p));
>>> }
>>> +
>>> +EAPI size_t
>>> +eina_str_vprintf_length(const char *format, va_list args)
>>> +{
>>> +char c;
>>> +size_t len;
>>> +
>>> +len = vsnprintf(&c, 1, format, args) + 1;
>>> +return len;
>>
>> this is wrong if
>>
>> 1) vsnprintf returns an error (for example if there's a wrong format string)
>> 2) format is "" - return value value should be 0, but will be 1
>>
>> If you change the return value to ssize_t it's better and simpler if you do:
>>
>> "return vsnprintf(NULL, 0, format, args);"
>>
>> If you prefer to ignore the error and continue with an unsigned type,
>> then you should check the return value for < 0 before returning.
>>
>>> +}
>>> +
>>> +EAPI char *
>>> +eina_str_vprintf_dup(const char *format, va_list args)
>>> +{
>>> +size_t length;
>>> +char *ret;
>>> +va_list copy;
>>> +
>>> +/* be sure to use a copy or the printf implementation will
>>> + * step into the args
>>> + */
>>> +va_copy(copy, args);
>>> +length = eina_str_vprintf_length(format, copy);
>>> +va_end(copy);
>>> +
>>> +ret = calloc(length, sizeof(char));
>>
>> malloc instead? you are replacing all the chars below
>>
>>> +vsprintf(ret, format, args);
>>> +return ret;
>>> +}
>>> +
>>> +EAPI char *
>>> +eina_str_printf_dup(const char *format, ...)
>>> +{
>>> +char *ret;
>>> +va_list args;
>>> +
>>> +va_start(args, format);
>>> +ret = eina_str_vprintf_dup(format, args);
>>> +va_end(args);
>>> +return ret;
>>> +}
>>
>> why these instead of plain (v)asprintf?
>
> "These functions are GNU extensions, not in C or POSIX.", straight
> from the man page...
sure... and they are available everywhere.
Lucas De Marchi
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&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/efl] master 04/04: eina: add functions to alloc strings from a printf fmt
On Tue, Sep 24, 2013 at 12:20 AM, Jorge Zapata
wrote:
> cedric pushed a commit to branch master.
>
> http://git.enlightenment.org/core/efl.git/commit/?id=b5fce696c743c50ea0a049c4f879756b5ed231d4
>
> commit b5fce696c743c50ea0a049c4f879756b5ed231d4
> Author: Jorge Zapata
> Date: Mon Sep 23 21:13:18 2013 +0200
>
> eina: add functions to alloc strings from a printf fmt
> ---
> src/lib/eina/eina_str.c | 41 +
> src/lib/eina/eina_str.h | 33 +
> 2 files changed, 74 insertions(+)
>
> diff --git a/src/lib/eina/eina_str.c b/src/lib/eina/eina_str.c
> index 11fef3c..283476b 100644
> --- a/src/lib/eina/eina_str.c
> +++ b/src/lib/eina/eina_str.c
> @@ -652,3 +652,44 @@ eina_str_toupper(char **str)
> for (p = *str; (*p); p++)
>*p = toupper((unsigned char)(*p));
> }
> +
> +EAPI size_t
> +eina_str_vprintf_length(const char *format, va_list args)
> +{
> +char c;
> +size_t len;
> +
> +len = vsnprintf(&c, 1, format, args) + 1;
> +return len;
this is wrong if
1) vsnprintf returns an error (for example if there's a wrong format string)
2) format is "" - return value value should be 0, but will be 1
If you change the return value to ssize_t it's better and simpler if you do:
"return vsnprintf(NULL, 0, format, args);"
If you prefer to ignore the error and continue with an unsigned type,
then you should check the return value for < 0 before returning.
> +}
> +
> +EAPI char *
> +eina_str_vprintf_dup(const char *format, va_list args)
> +{
> +size_t length;
> +char *ret;
> +va_list copy;
> +
> +/* be sure to use a copy or the printf implementation will
> + * step into the args
> + */
> +va_copy(copy, args);
> +length = eina_str_vprintf_length(format, copy);
> +va_end(copy);
> +
> +ret = calloc(length, sizeof(char));
malloc instead? you are replacing all the chars below
> +vsprintf(ret, format, args);
> +return ret;
> +}
> +
> +EAPI char *
> +eina_str_printf_dup(const char *format, ...)
> +{
> + char *ret;
> +va_list args;
> +
> +va_start(args, format);
> +ret = eina_str_vprintf_dup(format, args);
> +va_end(args);
> +return ret;
> +}
why these instead of plain (v)asprintf?
Lucas De Marchi
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Migration of Enlightenment GIT Commits Mailing List
On Wed, Sep 18, 2013 at 4:03 AM, Tom Hacohen wrote: > On 13/09/13 01:20, Bertrand Jacquin wrote: >> Hi, >> >> Tommorrow at 13:00 UTC, the Enlightenment GIT Commits Mailing List will >> be moved from Sourceforge to own servers. This to avoid the moderation >> madness. >> >> All subscribed people will be moved to the new list and unsubscribed from >> the old one. This means no user action will be required. >> >> Then, you will be notified about your subscription and get info on >> how to use it. >> >> This only concern the list enlightenment-...@lists.sourceforge.net. >> Other lists will stay on SF for the moment. >> >> The new list will be g...@lists.enlightenment.org, and List-Id >> git.lists.enlightenment.org. >> > > FYI: > We changed the ML (now that we have more control over it) to spoof the > "From" field to be as if the mail was sent from the git committer email. > This means, that now if you reply to all, you also reply to the > committer, not just the ML, among other advantages. thumbs up :) Lucas De Marchi -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&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/02: Remove __UNUSED__ from function declaration where parameter is actually used.
On Tue, Sep 17, 2013 at 6:40 AM, Stefan Schmidt wrote: > Hello. > > As you like to point out problems with mails. No need to CC me, I'm on > the list. :) > > I also know that thunderbird sucks at this but I'm able to do it. :) > > On 09/17/2013 10:21 AM, Tom Hacohen wrote: >> On 17/09/13 08:30, Stefan Schmidt wrote: >>> Hello. >>> >>> On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote: >>>> devilhorns pushed a commit to branch master. >>>> >>>> commit 64bc97c53c5c3772595f9d2321f9e19590d8a477 >>>> Author: Chris Michael >>>> Date: Mon Sep 16 11:40:30 2013 +0100 >>>> >>>> Remove __UNUSED__ from function declaration where parameter is >>>> actually used. >>> >>> This brings an old topic back into my mind. >>> >>> Its not the first time we eagerly tagged parameters as unused because >>> gcc warned about it and later started to use them without removing the >>> unused label. This has the potential to screw us badly as it is up to >>> the compiler to decide what to do with the parameter here. >> >> I don't know much about the exact implementation details of GCC, but I >> find it very unlikely that GCC is allowed, or will ever actually do >> anything about a *used* variable that is marked as unused. That just >> sounds too crazy to be true. So I don't think we'll ever get screwed. > > I have in the back of my mind that we already screwed by this. I don't > have the details at hand so I can't proof it. > > If I ever run into this problem with efl I will bill you the number of > hours I had to work it out. Could easily be days for such a thing. :) Most likely the problem you remember is regarding the pure or const attributes, not the unused. If you declare the function as pure and then in reality it isn't, bad things will happen depending on the optimization level because the compiler may reuse a previous return value instead of calling the function again. I remember fixing one problem like this in E or EFL some years ago. Lucas De Marchi -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&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/02: Remove __UNUSED__ from function declaration where parameter is actually used.
On Tue, Sep 17, 2013 at 6:21 AM, Tom Hacohen wrote: > On 17/09/13 08:30, Stefan Schmidt wrote: >> Hello. >> >> On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote: >>> devilhorns pushed a commit to branch master. >>> >>> commit 64bc97c53c5c3772595f9d2321f9e19590d8a477 >>> Author: Chris Michael >>> Date: Mon Sep 16 11:40:30 2013 +0100 >>> >>> Remove __UNUSED__ from function declaration where parameter is >>> actually used. >> >> This brings an old topic back into my mind. >> >> Its not the first time we eagerly tagged parameters as unused because >> gcc warned about it and later started to use them without removing the >> unused label. This has the potential to screw us badly as it is up to >> the compiler to decide what to do with the parameter here. > > I don't know much about the exact implementation details of GCC, but I > find it very unlikely that GCC is allowed, or will ever actually do > anything about a *used* variable that is marked as unused. That just > sounds too crazy to be true. So I don't think we'll ever get screwed. It won't produce incorrect code. > >> >> Given how many callback and other signatures we have with user_data or >> other unused parameters we end up with 3630 EINA_UNUSED and even 71 >> __UNUSED__ in efl alone. All with the potential to be used at some point >> but forgotten to remove the label. > > Again, not really an issue. >> >> My proposal would be to use -Wno-unused-parameter in our CFLAGS to >> disable this warning and remove all EINA_UNUSED and __UNUSED__ from >> parameters. >> >> I know it has the downside that in the rare case where you add a >> parameter to a signature yourself (read: not using an existing function >> signature) you might add it and forgot to use it. Which will not >> reported as warning in this case. >> >> In my opinion the risk is higher than the benefit here. > > I disagree. I find this warning very useful when prototyping and > refactoring APIs (both internal and external). I would really hate > losing that in a mess of warnings. Then you turn it on once, for that part of the code. Having it as the default isn't helping, but instead requiring more work from others. Lucas De Marchi -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&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/02: Remove __UNUSED__ from function declaration where parameter is actually used.
On Tue, Sep 17, 2013 at 4:30 AM, Stefan Schmidt wrote: > Hello. > > On 09/17/2013 07:44 AM, Chris Michael - Enlightenment Git wrote: >> devilhorns pushed a commit to branch master. >> >> commit 64bc97c53c5c3772595f9d2321f9e19590d8a477 >> Author: Chris Michael >> Date: Mon Sep 16 11:40:30 2013 +0100 >> >> Remove __UNUSED__ from function declaration where parameter is >> actually used. > > This brings an old topic back into my mind. > > Its not the first time we eagerly tagged parameters as unused because > gcc warned about it and later started to use them without removing the > unused label. This has the potential to screw us badly as it is up to > the compiler to decide what to do with the parameter here. > > Given how many callback and other signatures we have with user_data or > other unused parameters we end up with 3630 EINA_UNUSED and even 71 > __UNUSED__ in efl alone. All with the potential to be used at some point > but forgotten to remove the label. > > My proposal would be to use -Wno-unused-parameter in our CFLAGS to > disable this warning and remove all EINA_UNUSED and __UNUSED__ from > parameters. +1 We use callbacks a lot. And often enough we don't use one parameter or another. Having to *silence* the compiler on every single place about a stupid warning is useless. I'm all in favor or silence it in the build directly. > > I know it has the downside that in the rare case where you add a > parameter to a signature yourself (read: not using an existing function > signature) you might add it and forgot to use it. Which will not > reported as warning in this case. eldbus was made entirely passing -Wno-unused-parameter in CFLAGS. When merging to EFL and forced to drop the flag, I proved my point: there no one single place in which the warning would point to an error. Most of the projects I'm involved with are for long disabling this warning. Lucas De Marchi -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] New emails for every b0rker
On Mon, Sep 16, 2013 at 2:51 PM, Bertrand Jacquin wrote: > Ladies, > > Everyone of you having commit access, also seems to be called > developers does now have an email @enlightenment.org. > > Emails send to a developer is then forwarded to emails you have declared > in the E-Mail: info.txt pattern. > > Only valid email are processed (meaning not starting with a dash (minus > ?)), one or more is accepted. So be carefull about what email you have > registered (isn't it dan ;). Change in that file is learn every 15 minutes. > > So this work for domain enlightenment.org, efl.so and libefl.so > > Your dear spam source, > Report every issue and claims here or in the phab Admin project. > Wouldn't it be easier to just send an email to Cedric blaming him when the build is broken? Lucas De Marchi -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Coding a 'modal' dialog in E17
On Tue, Sep 10, 2013 at 10:02 PM, Carsten Haitzler wrote: > On Tue, 10 Sep 2013 21:53:59 -0300 Lucas De Marchi > said: > >> On Tue, Sep 10, 2013 at 2:45 PM, Robert Heller wrote: >> > At Tue, 10 Sep 2013 17:51:38 +0100 Michael Blumenkrantz >> > wrote: >> > >> >> >> >> On Tue, 10 Sep 2013 12:34:21 -0400 >> >> Robert Heller wrote: >> >> >> >> > I am in the process of modifying E17 (I want to add so additional >> >> > functionality to the file manager). One of the things I need to be able >> >> > to do is have a 'modal' dialog, that is a dislog box that grabs the >> >> > focus and causes the program (the file manager) to wait. I want events >> >> > to be processed, but I want psuedo code like this: >> >> > >> >> >dialog = make_dialog(...); >> >> >show(dialog); >> >> >wait_for(dialog); >> >> > >> >> > The 'wait_for()' call would not return until the OK button or Cancel >> >> > (close) button on the dialog has been clicked. It is not clear how to >> >> > do this -- the documentation does not seem to cover this case (or I >> >> > can't it in the documentation). >> >> > >> >> > Any pointers would be helpful. Thanks in advance. >> >> > >> >> >> >> yeahhh you can't do that. >> >> >> >> what you CAN do is something like the >> >> uhh...modules/conf_theme/e_int_config_wallpaper.c dialog does. you set the >> >> parent dialog (though make sure you do this AFTER you show both dialogs or >> >> it won't work) to set up your modal: the first param is your intended >> >> modal, the second is the parent window which is getting blocked. then you >> >> can basically just wait for the modal to die and you'll know that there >> >> will be no events on the parent. >> >> >> >> I'll say this, however: we STRONGLY discourage the use of modal dialogs in >> >> e. unless you have a really good reason for it, I'm unlikely to accept any >> >> patches which introduce modal dialogs. >> > >> > Yes, I fully understand the 'evils' of modal dialogs, but there are times >> > when it is the only option. In this case I am interfacing to a library that >> > has a callback that wants some input (a passphrase) and I cannot just >> > return without the passphrase and I don't know (in advance) if the >> > passphrase is even needed or what the hint for the passphrase is (this info >> > gets passed into the callback). And the callback might be called again if >> > the passphrase is wrong. I may implement this with a subprocess, but then >> > the subprocess itself will need to have a modal dialog. I am only >> > interested a *local* type modal dialog. >> >> If you know the evils of modal dialogs: back in 2010 when working in >> webkit I remember opening another mainloop for doing modal dialogs. >> Then spending a day to fix nested mainloops in EFL. Things might be >> better these days. > > you poor bastard :( hehe... note that I'm not recommending to do it. Just to make it stronger: AVOID IT AS YOU CAN!! IF YOU CAN'T, RUN! Better this way? :) Lucas De Marchi -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Coding a 'modal' dialog in E17
On Tue, Sep 10, 2013 at 2:45 PM, Robert Heller wrote: > At Tue, 10 Sep 2013 17:51:38 +0100 Michael Blumenkrantz > wrote: > >> >> On Tue, 10 Sep 2013 12:34:21 -0400 >> Robert Heller wrote: >> >> > I am in the process of modifying E17 (I want to add so additional >> > functionality to the file manager). One of the things I need to be able >> > to do >> > is have a 'modal' dialog, that is a dislog box that grabs the focus and >> > causes >> > the program (the file manager) to wait. I want events to be processed, >> > but I >> > want psuedo code like this: >> > >> >dialog = make_dialog(...); >> >show(dialog); >> >wait_for(dialog); >> > >> > The 'wait_for()' call would not return until the OK button or Cancel >> > (close) >> > button on the dialog has been clicked. It is not clear how to do this -- >> > the >> > documentation does not seem to cover this case (or I can't it in the >> > documentation). >> > >> > Any pointers would be helpful. Thanks in advance. >> > >> >> yeahhh you can't do that. >> >> what you CAN do is something like the >> uhh...modules/conf_theme/e_int_config_wallpaper.c dialog does. you set the >> parent dialog (though make sure you do this AFTER you show both dialogs or >> it won't work) to set up your modal: the first param is your intended modal, >> the second is the parent window which is getting blocked. then you can >> basically just wait for the modal to die and you'll know that there will be >> no events on the parent. >> >> I'll say this, however: we STRONGLY discourage the use of modal dialogs in >> e. unless you have a really good reason for it, I'm unlikely to accept any >> patches which introduce modal dialogs. > > Yes, I fully understand the 'evils' of modal dialogs, but there are times when > it is the only option. In this case I am interfacing to a library that has a > callback that wants some input (a passphrase) and I cannot just return without > the passphrase and I don't know (in advance) if the passphrase is even needed > or what the hint for the passphrase is (this info gets passed into the > callback). And the callback might be called again if the passphrase is wrong. > I may implement this with a subprocess, but then the subprocess itself will > need to have a modal dialog. I am only interested a *local* type modal dialog. If you know the evils of modal dialogs: back in 2010 when working in webkit I remember opening another mainloop for doing modal dialogs. Then spending a day to fix nested mainloops in EFL. Things might be better these days. Lucas De Marchi -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] File /usr/lib/pkconfig/eo.pc and EO name
On Tue, Sep 10, 2013 at 5:02 PM, Côme BERNIGAUD wrote: > Le 09/09/2013 15:43, Tom Hacohen a écrit : >> On 03/09/13 22:25, Côme BERNIGAUD wrote: >>> Hello, >>> >>> I saw that there is a new component named EO in the EFLs. >>> EO is already a library, it stands for «Evolving Objects» : >>> http://eodev.sourceforge.net/ >>> >>> This is causing trouble, at least for one file: >>> /usr/lib/pkgconfig/eo.pc is the pkgconfig for evolving objects, which is >>> already used by several projects over the past years. >>> >>> So it might be a good thing if you could rename at least this file. >>> >>> Côme >>> >>> PS: The problem was found when trying to install the AUR package efl-git >>> on ArchLinux, but I'm pretty sure this file is from upstream. >> >> Unfortunately it's really annoying to change it. After discussing it >> on IRC and thinking about all the pain involved, we decided not to >> change anything. >> >> We don't want to change the library name itself, that is, we like eo. >> Changing just the pc file creates a lot of issues with our build >> system which does a lot of things automatically and assumes a specific >> template to be followed. >> libXX.so, XX.pc and etc. before edbus get renamed to eldbus we had stuff in the build system to adjust the .pc file. If that isn't there anymore, I think it could be easily revived. > That is a very sad decision. It means people won't be able to install > both EO and the EFL… > The filename eo.pc was already used since several years by EO, it's > childish to just ignore that and take the same name. > You should indeed use a pattern like efl/xx.pc or efl_xx.pc because if > you intend to keep using two-letters names, you'll find a lot of them > are already in use. IMO efl_eo.pc would be a good name. Lucas De Marchi -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127&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/efl] master 19/19: Merge branch 'framespace'
On Thu, Sep 5, 2013 at 11:01 AM, Chris Michael wrote: > On 09/05/13 03:18, Cedric BAIL wrote: >> On Wed, Sep 4, 2013 at 3:37 PM, Chris Michael - Enlightenment Git >> wrote: >>> devilhorns pushed a commit to branch master. >>> >>> commit 03604a15b6158fdefcfb0f833567dbf91b38c659 >>> Merge: 88cc896 609941e >>> Author: Chris Michael >>> Date: Wed Sep 4 14:36:29 2013 +0100 >>> >>> Merge branch 'framespace' >> May I say that we did agree against merging branch... >> > You sure may. In fact, you can say anything you wish. > > May I say ... French Borker !! :P > Jokes aside, we did agree not to merge things like this. And you were just 3 commit behind master, you could very easily "git rebase origin/master" before pushing. Hoping this was just an isolated mistake. Lucas De Marchi -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391&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: elementary/widget - introduce elm_object_item_object_get().
On Tue, Sep 3, 2013 at 1:54 PM, Michael Blumenkrantz wrote: > On Tue, 3 Sep 2013 13:35:48 -0300 > Iván Briano wrote: > >> On Tue, Sep 3, 2013 at 9:12 AM, ChunEon Park wrote: >> > just it. >> > >> >> That's not how you raise a discussion, you did it by proposing the >> solution to a given problem >> before committing said solution. >> >> And since it seems we are into slowly allowing all sorts of "not >> recommended" behaviors, why don't >> we just expose every single structure in our header files and let >> developers who believe to know what >> they are doing just access everything? It'll save us a lot of time and >> entries in the symbols tables. > > that's how e works and I hear no complaints from its developers problem here is that it's a lib... bad APIs stay until we decide to do a new major release. in E we can break the API at will. If what Hermet wanted was to "raise the question again" like he said, by this thread he clearly accomplished that. And people complained it's bad. Again. So let's revert until there's consensus this is inevitable or there's a better way, ok? Lucas De Marchi -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&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/efl] master 04/04: eldbus: Add timeout message error as a macro
On Mon, Sep 2, 2013 at 4:16 PM, José Roberto de Souza - Enlightenment
Git wrote:
> zehortigoza pushed a commit to branch master.
>
> commit bcba4779c8df1efe950b5f4cc1075187ab365a57
> Author: José Roberto de Souza
> Date: Fri Aug 30 10:52:04 2013 -0300
>
> eldbus: Add timeout message error as a macro
> ---
> src/lib/eldbus/Eldbus.h | 1 +
> src/lib/eldbus/eldbus_pending.c | 8
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/src/lib/eldbus/Eldbus.h b/src/lib/eldbus/Eldbus.h
> index e49061d..fe05f2e 100644
> --- a/src/lib/eldbus/Eldbus.h
> +++ b/src/lib/eldbus/Eldbus.h
> @@ -126,6 +126,7 @@ extern "C" {
> #define ELDBUS_FDO_INTERFACE_INTROSPECTABLE
> "org.freedesktop.DBus.Introspectable"
> #define ELDBUS_FDO_INTEFACE_PEER "org.freedesktop.DBus.Peer"
> #define ELDBUS_ERROR_PENDING_CANCELED "org.enlightenment.DBus.Canceled"
> +#define ELDBUS_ERROR_PENDING_TIMEOUT "org.enlightenment.DBus.Timeout"
I wonder why we are defining this in a public header with the
org.enlightenment namespace when there's a fdo one.
>
> typedef struct _Eldbus_Version
> {
> diff --git a/src/lib/eldbus/eldbus_pending.c b/src/lib/eldbus/eldbus_pending.c
> index 4174ac1..bf561bb 100644
> --- a/src/lib/eldbus/eldbus_pending.c
> +++ b/src/lib/eldbus/eldbus_pending.c
> @@ -51,8 +51,8 @@ cb_pending(DBusPendingCall *dbus_pending, void *user_data)
> INF("timeout to pending %p", pending);
> dbus_pending_call_cancel(dbus_pending);
> msg = eldbus_message_error_new(pending->msg_sent,
> - "org.enlightenment.DBus.Timeout",
> - "This call was not completed.");
> + ELDBUS_ERROR_PENDING_TIMEOUT,
> + "This call was not completed in
> time.");
And here I think we would be better off using
org.freedesktop.DBus.Error.NoReply instead of timeout. I think the
timeout would be used by an *application* when the operation it's
doing timed out.
Lucas De Marchi
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&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/enlightenment] master 01/01: add systemd support to e_sys for shutdown/reboot/suspend/hibernate
On Thu, Aug 15, 2013 at 3:19 PM, Gustavo Sverzut Barbieri wrote: > On Thu, Aug 15, 2013 at 2:11 PM, Lucas De Marchi > wrote: >> On Thu, Aug 15, 2013 at 1:33 PM, Gustavo Sverzut Barbieri >> wrote: >>> On Thu, Aug 15, 2013 at 9:37 AM, Carsten Haitzler >>> wrote: >>>> On Thu, 15 Aug 2013 08:40:36 -0300 Gustavo Sverzut Barbieri >>>> said: >>>> >>>>> Raster, heads up here that you can use eldbus_proxy that will make your >>>>> life >>>>> easier writing these things. >>>>> >>>>> For instance you can manage all the pending call lifetime to the object >>>>> and >>>>> proxy, if you delete it (unref) it would do for all pending methods, >>>>> signal >>>>> handlers, etc >>>>> >>>>> It may be new to you, but check the examples or my code to upower/systemd >>>>> uses it as well. >>>> >>>> i saw some of the proxy use - i wasn't sure why i needed it actually. i >>>> didn't >>>> use any pending handles so it turned out for that bit of code, it's not >>>> needed. >>> >>> if will save you replicating those helpers you did... you don't need >>> to do anything with the pending call.. but you can use it to >>> explicitly cancel one. If you delete the object (unref) it will cancel >>> all pending automatically. >>> >>> your code would reduce to get object, then proxy, then call stuff like >>> CanPowerOff, no need to create the wrappers yourself. That's why we >>> added the proxy, to automate these wrappers we were doing over and >>> over again. >> >> Easier to change the code and show him than argumenting ;-) > > currently I'm not bothering, but indeed this would help more than talking. > > >>>> btw... i put this in e right now, BUT... i totally expect that ecore may >>>> get >>>> these features, so the code can be pasted in when we decie just how it will >>>> look like. i just wanted to do some work to support systemd etc. :) this >>>> was a >>>> simple/easy place/thing to do. :) >>> >>> some like inhibit suspend/power actions may be good, but I don't think >>> doing the suspend/reboot action (even if delegated) should come in >>> Ecore... after all there will be a single app doing that in most >>> cases, E itself. >>> >>> to block the suspend/power may be done by all apps, like during a >>> media playback or slideshow.. >> >> What's the point in adding those to ecore, wrapping the systemd >> functionality? >> >> Same question goes for the recently added events for sleep, hostname, >> etc... Why adding a wrapper instead of just let applications listen to >> the signals sent by systemd directly? > > 1 - because some systems don't have systemd, thus we have different > plugins (tizen for instance); > 2 - because it's easier to listen for an ECORE_EVENT than do all the > dbus code, even if eldbus makes it simpler it's still hundreds of > lines of code; But you also loose control. How do you turn the events off? They should be default off no matter if you have the plugin and be on only if the app requested to watch for. Then I would agree with such an argument. Otherwise you will register for countless signals and wake up all EFL apps to do nothing when there's an event like this that most likely noone is interested. Particularly interesting is the battery-low event ;-) Lucas De Marchi -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&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/enlightenment] master 01/01: add systemd support to e_sys for shutdown/reboot/suspend/hibernate
On Fri, Aug 16, 2013 at 5:06 AM, David Seikel wrote: > On Fri, 16 Aug 2013 08:50:02 +0900 Carsten Haitzler (The Rasterman) > wrote: > >> On Thu, 15 Aug 2013 19:59:28 -0300 Lucas De Marchi >> said: >> >> > On Thu, Aug 15, 2013 at 3:19 PM, Gustavo Sverzut Barbieri >> > wrote: >> > > On Thu, Aug 15, 2013 at 2:11 PM, Lucas De Marchi >> > > wrote: >> > >> On Thu, Aug 15, 2013 at 1:33 PM, Gustavo Sverzut Barbieri >> > >> wrote: >> > >>> On Thu, Aug 15, 2013 at 9:37 AM, Carsten Haitzler >> > >>> wrote: >> > >>>> On Thu, 15 Aug 2013 08:40:36 -0300 Gustavo Sverzut Barbieri >> > >>>> said: >> > >>>> >> > >>>>> Raster, heads up here that you can use eldbus_proxy that will >> > >>>>> make your life easier writing these things. >> > >>>>> >> > >>>>> For instance you can manage all the pending call lifetime to >> > >>>>> the object and proxy, if you delete it (unref) it would do >> > >>>>> for all pending methods, signal handlers, etc >> > >>>>> >> > >>>>> It may be new to you, but check the examples or my code to >> > >>>>> upower/systemd uses it as well. >> > >>>> >> > >>>> i saw some of the proxy use - i wasn't sure why i needed it >> > >>>> actually. i didn't use any pending handles so it turned out >> > >>>> for that bit of code, it's not needed. >> > >>> >> > >>> if will save you replicating those helpers you did... you don't >> > >>> need to do anything with the pending call.. but you can use it >> > >>> to explicitly cancel one. If you delete the object (unref) it >> > >>> will cancel all pending automatically. >> > >>> >> > >>> your code would reduce to get object, then proxy, then call >> > >>> stuff like CanPowerOff, no need to create the wrappers >> > >>> yourself. That's why we added the proxy, to automate these >> > >>> wrappers we were doing over and over again. >> > >> >> > >> Easier to change the code and show him than argumenting ;-) >> > > >> > > currently I'm not bothering, but indeed this would help more than >> > > talking. >> > > >> > > >> > >>>> btw... i put this in e right now, BUT... i totally expect that >> > >>>> ecore may get these features, so the code can be pasted in >> > >>>> when we decie just how it will look like. i just wanted to do >> > >>>> some work to support systemd etc. :) this was a simple/easy >> > >>>> place/thing to do. :) >> > >>> >> > >>> some like inhibit suspend/power actions may be good, but I >> > >>> don't think doing the suspend/reboot action (even if delegated) >> > >>> should come in Ecore... after all there will be a single app >> > >>> doing that in most cases, E itself. >> > >>> >> > >>> to block the suspend/power may be done by all apps, like during >> > >>> a media playback or slideshow.. >> > >> >> > >> What's the point in adding those to ecore, wrapping the systemd >> > >> functionality? >> > >> >> > >> Same question goes for the recently added events for sleep, >> > >> hostname, etc... Why adding a wrapper instead of just let >> > >> applications listen to the signals sent by systemd directly? >> > > >> > > 1 - because some systems don't have systemd, thus we have >> > > different plugins (tizen for instance); >> > >> > Yet the ones that matter (should) implement that interfaces. >> >> one of those platforms... that efl is shipped on by default, doesnt >> use systemd for this (but it should), so abstracting is a must as we >> then already have 2 paths. we ALSO have upower... a bit older than >> systemd and some distros wont go "systemd"... and then think bsd. >> they may have their own things (i have no idea what they are), but it >> gives a point for them to plug in and abstract. > > Then there's things like Windows and Mac OS X. Systemd might not even I'm being very specific to the changes mentioned. I'm looking forward to your patches adding the support for these events on windows and mac os. Lucas De Marchi -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&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/efl] master 03/03: ecore system: Simply systemd locale set
On Thu, Aug 15, 2013 at 3:24 PM, Gustavo Sverzut Barbieri
wrote:
> On Thu, Aug 15, 2013 at 2:49 PM, José Roberto de Souza - Enlightenment
> Git wrote:
>
>> +char buf[1024], *value, *type;
>>
>> - for (i = 0; i < EINA_C_ARRAY_LENGTH(locale_cat_desc); i++)
>> - {
>> -if ((!setlocs[i]) && (locale_cat_desc[i].cat != LC_ALL))
>> - setlocale(locale_cat_desc[i].cat, "C");
>> +snprintf(buf, sizeof(buf), "%s", val);
>> +
>> +type = buf;
>> +
>> +value = strchr(buf, '=');
>> +*value = 0;
>> +value++;
>> +
>> +setenv(type, value, 1);
>
> super! but a hint: you don't have to snprintf() the buffer, it could
> be a simple eina_strlcpy()...
or find the '=' first and memcpy only the first part, checking
bounds with min().
Lucas De Marchi
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&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/enlightenment] master 01/01: add systemd support to e_sys for shutdown/reboot/suspend/hibernate
On Thu, Aug 15, 2013 at 3:19 PM, Gustavo Sverzut Barbieri wrote: > On Thu, Aug 15, 2013 at 2:11 PM, Lucas De Marchi > wrote: >> On Thu, Aug 15, 2013 at 1:33 PM, Gustavo Sverzut Barbieri >> wrote: >>> On Thu, Aug 15, 2013 at 9:37 AM, Carsten Haitzler >>> wrote: >>>> On Thu, 15 Aug 2013 08:40:36 -0300 Gustavo Sverzut Barbieri >>>> said: >>>> >>>>> Raster, heads up here that you can use eldbus_proxy that will make your >>>>> life >>>>> easier writing these things. >>>>> >>>>> For instance you can manage all the pending call lifetime to the object >>>>> and >>>>> proxy, if you delete it (unref) it would do for all pending methods, >>>>> signal >>>>> handlers, etc >>>>> >>>>> It may be new to you, but check the examples or my code to upower/systemd >>>>> uses it as well. >>>> >>>> i saw some of the proxy use - i wasn't sure why i needed it actually. i >>>> didn't >>>> use any pending handles so it turned out for that bit of code, it's not >>>> needed. >>> >>> if will save you replicating those helpers you did... you don't need >>> to do anything with the pending call.. but you can use it to >>> explicitly cancel one. If you delete the object (unref) it will cancel >>> all pending automatically. >>> >>> your code would reduce to get object, then proxy, then call stuff like >>> CanPowerOff, no need to create the wrappers yourself. That's why we >>> added the proxy, to automate these wrappers we were doing over and >>> over again. >> >> Easier to change the code and show him than argumenting ;-) > > currently I'm not bothering, but indeed this would help more than talking. > > >>>> btw... i put this in e right now, BUT... i totally expect that ecore may >>>> get >>>> these features, so the code can be pasted in when we decie just how it will >>>> look like. i just wanted to do some work to support systemd etc. :) this >>>> was a >>>> simple/easy place/thing to do. :) >>> >>> some like inhibit suspend/power actions may be good, but I don't think >>> doing the suspend/reboot action (even if delegated) should come in >>> Ecore... after all there will be a single app doing that in most >>> cases, E itself. >>> >>> to block the suspend/power may be done by all apps, like during a >>> media playback or slideshow.. >> >> What's the point in adding those to ecore, wrapping the systemd >> functionality? >> >> Same question goes for the recently added events for sleep, hostname, >> etc... Why adding a wrapper instead of just let applications listen to >> the signals sent by systemd directly? > > 1 - because some systems don't have systemd, thus we have different > plugins (tizen for instance); Yet the ones that matter (should) implement that interfaces. > 2 - because it's easier to listen for an ECORE_EVENT than do all the > dbus code, even if eldbus makes it simpler it's still hundreds of > lines of code; > > it's like why shouldn't we just inotify some files to know if locale > and time changed, using localed or timedated or hostnamed... because > it's easier with systemd :-) But it's already easy enough with systemd... and systemd as the init serves as a centralization point for this kind of information. For me those events just add an useless abstraction layer on top. Lucas De Marchi -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&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/enlightenment] master 01/01: add systemd support to e_sys for shutdown/reboot/suspend/hibernate
On Thu, Aug 15, 2013 at 1:33 PM, Gustavo Sverzut Barbieri wrote: > On Thu, Aug 15, 2013 at 9:37 AM, Carsten Haitzler > wrote: >> On Thu, 15 Aug 2013 08:40:36 -0300 Gustavo Sverzut Barbieri >> said: >> >>> Raster, heads up here that you can use eldbus_proxy that will make your life >>> easier writing these things. >>> >>> For instance you can manage all the pending call lifetime to the object and >>> proxy, if you delete it (unref) it would do for all pending methods, signal >>> handlers, etc >>> >>> It may be new to you, but check the examples or my code to upower/systemd >>> uses it as well. >> >> i saw some of the proxy use - i wasn't sure why i needed it actually. i >> didn't >> use any pending handles so it turned out for that bit of code, it's not >> needed. > > if will save you replicating those helpers you did... you don't need > to do anything with the pending call.. but you can use it to > explicitly cancel one. If you delete the object (unref) it will cancel > all pending automatically. > > your code would reduce to get object, then proxy, then call stuff like > CanPowerOff, no need to create the wrappers yourself. That's why we > added the proxy, to automate these wrappers we were doing over and > over again. Easier to change the code and show him than argumenting ;-) > > >> btw... i put this in e right now, BUT... i totally expect that ecore may get >> these features, so the code can be pasted in when we decie just how it will >> look like. i just wanted to do some work to support systemd etc. :) this was >> a >> simple/easy place/thing to do. :) > > some like inhibit suspend/power actions may be good, but I don't think > doing the suspend/reboot action (even if delegated) should come in > Ecore... after all there will be a single app doing that in most > cases, E itself. > > to block the suspend/power may be done by all apps, like during a > media playback or slideshow.. What's the point in adding those to ecore, wrapping the systemd functionality? Same question goes for the recently added events for sleep, hostname, etc... Why adding a wrapper instead of just let applications listen to the signals sent by systemd directly? Lucas De Marchi -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&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/enlightenment] master 02/02: Fix crash when trying to move wayland client applications. Add callbacks for e_desktop_shell interface functions (cannot be NULL anymore). When
Hi Michael On Tue, Aug 13, 2013 at 10:51 AM, Chris Michael - Enlightenment Git wrote: > devilhorns pushed a commit to branch master. > > commit 37e2134cf745cc2f5e443508c6769ca9d26f4850 > Author: Chris Michael > Date: Tue Aug 13 14:49:30 2013 +0100 > > Fix crash when trying to move wayland client applications. > Add callbacks for e_desktop_shell interface functions (cannot be NULL > anymore). When committing with git, please remember to put a blank line after the first line. The git log, emails, reflog, gitk, etc look much prettier this way. Lucas De Marchi -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm menu (probably need to break theme and extend api)
On Mon, Aug 12, 2013 at 4:05 AM, Michael Blumenkrantz wrote: > please don't just copy the E menus into elm. while they may be better > overall, they're really not that great...certainly not something I would > hold up as the sterling standard of menus. here's just some of the huge > issues with e menus that stand out as reasons why they're bad (and why I > will eventually need to overhaul them): > > * the whole "separate mouse handler" thing creates a giant race condition > for showing/hiding submenus which is a GIANT nightmare > * e menus can't scroll (obviously) and adding scrolling would turn them > into even more of a nightmare > * submenu deletion is also a huge race condition > * the whole menu item callback design is broken since they can be called > repeatedly instead of just the one time they were intended to be called > (currently hacked around) > * oh jesus the menu category/augmentation system kill it with fire > * interceptors for move/resize? really? just to show menus in the right > place? > * adding items to a menu asynchronously is seriously infuriating--just look > at the fileman menu system to see what a clusterfuck it is > > while I agree that the elm menu api/internals/design needs work, I am > strongly opposed to anything related to copying the E menu system into elm. > a much better solution would be a new menu design which works properly > (without all these hacks and flaws) and can be used in both places. > > this doesn't need to be rushed in just to make it before the 1.8 release; > menus are important, and we should spend some time on them. +1 Lucas De Marchi -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Beta API
On Tue, Jul 23, 2013 at 5:29 AM, Cedric BAIL wrote: > On Tue, Jul 23, 2013 at 5:04 PM, Michael Blumenkrantz > wrote: >> sure, but it sounds more like "pre-alpha" than beta at this point >> considering the amount of rewrite occurring. > > There is still no agreement about if we are going to change any of the > existing API or not. It is still a discussion. And the change is going > to impact mostly EFL internal than an application using EFL. Humn... even then I'd say it would be better to do one of the below: 1) Keep it private and link statically to Eo. This has the downside that now every lib has to link statically and grows (side note.. is there any plans for libelf.so?) 2) Remove the versioning from libeo.so so we can do a proper release later without bumping the major (which would look odd compared to the other libs) Lucas De Marchi -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eo: potential improvements
On Mon, Jul 29, 2013 at 12:04 PM, Jérémy Zurcher wrote:
> On Monday 29 July 2013 10:31, Lucas De Marchi wrote :
>> On Sat, Jul 27, 2013 at 5:54 PM, Jérémy Zurcher wrote:
>> > On Saturday 27 July 2013 11:10, Carsten Haitzler wrote :
>> >> On Fri, 26 Jul 2013 14:57:28 -0300 Lucas De Marchi
>> >> said:
>> >>
>> >> > On Thu, Jul 25, 2013 at 8:54 PM, Carsten Haitzler
>> >> > wrote:
>> >> > > On Thu, 25 Jul 2013 14:58:30 -0300 Gustavo Sverzut Barbieri
>> >> > > said:
>> >> > >
>> >> > >> On Thu, Jul 25, 2013 at 1:46 PM, Tom Hacohen
>> >> > >>
>> >> > >> wrote:
>> >> > >> > On 24/07/13 03:09, Carsten Haitzler (The Rasterman) wrote:
>> >> > >> >> On Tue, 23 Jul 2013 18:22:02 +0200 Jérémy Zurcher
>> >> > >> >>
>> >> > >> >> said:
>> >> > >> >>
>> >> > >> >>> just to clarify a few points:
>> >> > >> >>>
>> >> > >> >>> - I think the less macro we have in an eo class declaration the
>> >> > >> >>> best,
>> >> > >> >>>actually we have nothing but that extra first parameter called
>> >> > >> >>> eo2_o, wich is either an obj_ptr (devs/tasn/eo2) or a call_ctx
>> >> > >> >>> (devs/jeyzu/eo2)
>> >> > >> >>>
>> >> > >> >>>this should go away if we use a stack per thread in eo
>> >> > >> >>> private code,
>> >> > >> >>>so we end up with a clean
>> >> > >> >>>EAPI float times(float f, float t);
>> >> > >> >>>
>> >> > >> >>> - since day 1 break is supported in eo2_do:
>> >> > >> >>>#define eo2_do(obj_id, ...)
>> >> > >> >>>do
>> >> > >> >>> {
>> >> > >> >>> obj_ptr_or_ctx = eo2_do_start(obj_id);
>> >> > >> >>> if(!obj_ptr_or_ctx) break;
>> >> > >> >>> do { __VA_ARGS__ ; } while (0);
>> >> > >> >>> eo2_do_end(obj_ptr_or_ctx);
>> >> > >> >>> } while (0)
>> >> > >> >>
>> >> > >> >> i'm worried about people doing return there. seriously - objid
>> >> > >> >> came in
>> >> > >> >> becau se of experience that people using efl are in general
>> >> > >> >> inexperienced programmers who don't take the time to do things
>> >> > >> >> right.
>> >> > >> >> they do things quickly and take shortcuts, and they ignore
>> >> > >> >> warnings.
>> >> > >> >> they'd rather patch out abort()s in efl code forcing them to fix
>> >> > >> >> their
>> >> > >> >> bugs, than fix their bugs. i am fearful that they will stuff in
>> >> > >> >> returns
>> >> > >> >> quite happily and think it mostly works most of the time... and
>> >> > >> >> then
>> >> > >> >> find subtle issues and waste our time finding them.
>> >> > >> >>
>> >> > >> >> how do we protect/stop returns (or goto's for that matter) within
>> >> > >> >> the
>> >> > >> >> while block. i looked for some pragmas - can't find any to do
>> >> > >> >> this.
>> >> > >> >> this would be a really useful compiler feature though (to maybe
>> >> > >> >> disable
>> >> > >> >> some constructs for a sequence of code).
>> >> >
>> >> > What you seem to be looking for is the cleanup attribute.
>> >> >
>> >> > #define eo2_do(obj_id, ...)
>> >> > do
>> >> > {
>> >> > obj_ptr_or_ctx = eo2_do_start(obj_id);
>> >> > if(!obj_ptr_or_ctx) break;
>> >> > do
>> >> >{
>> >> > obj_ptr_or_ctx_type __attribute__((cleanup(eo2_
Re: [E-devel] Eo: potential improvements
On Mon, Jul 29, 2013 at 10:31 AM, Lucas De Marchi
wrote:
> On Sat, Jul 27, 2013 at 5:54 PM, Jérémy Zurcher wrote:
>> On Saturday 27 July 2013 11:10, Carsten Haitzler wrote :
>>> On Fri, 26 Jul 2013 14:57:28 -0300 Lucas De Marchi
>>> said:
>>>
>>> > On Thu, Jul 25, 2013 at 8:54 PM, Carsten Haitzler
>>> > wrote:
>>> > > On Thu, 25 Jul 2013 14:58:30 -0300 Gustavo Sverzut Barbieri
>>> > > said:
>>> > >
>>> > >> On Thu, Jul 25, 2013 at 1:46 PM, Tom Hacohen
>>> > >> wrote:
>>> > >> > On 24/07/13 03:09, Carsten Haitzler (The Rasterman) wrote:
>>> > >> >> On Tue, 23 Jul 2013 18:22:02 +0200 Jérémy Zurcher
>>> > >> >> said:
>>> > >> >>
>>> > >> >>> just to clarify a few points:
>>> > >> >>>
>>> > >> >>> - I think the less macro we have in an eo class declaration the
>>> > >> >>> best,
>>> > >> >>>actually we have nothing but that extra first parameter called
>>> > >> >>> eo2_o, wich is either an obj_ptr (devs/tasn/eo2) or a call_ctx
>>> > >> >>> (devs/jeyzu/eo2)
>>> > >> >>>
>>> > >> >>>this should go away if we use a stack per thread in eo private
>>> > >> >>> code,
>>> > >> >>>so we end up with a clean
>>> > >> >>>EAPI float times(float f, float t);
>>> > >> >>>
>>> > >> >>> - since day 1 break is supported in eo2_do:
>>> > >> >>>#define eo2_do(obj_id, ...)
>>> > >> >>>do
>>> > >> >>> {
>>> > >> >>> obj_ptr_or_ctx = eo2_do_start(obj_id);
>>> > >> >>> if(!obj_ptr_or_ctx) break;
>>> > >> >>> do { __VA_ARGS__ ; } while (0);
>>> > >> >>> eo2_do_end(obj_ptr_or_ctx);
>>> > >> >>> } while (0)
>>> > >> >>
>>> > >> >> i'm worried about people doing return there. seriously - objid came
>>> > >> >> in
>>> > >> >> becau se of experience that people using efl are in general
>>> > >> >> inexperienced programmers who don't take the time to do things
>>> > >> >> right.
>>> > >> >> they do things quickly and take shortcuts, and they ignore warnings.
>>> > >> >> they'd rather patch out abort()s in efl code forcing them to fix
>>> > >> >> their
>>> > >> >> bugs, than fix their bugs. i am fearful that they will stuff in
>>> > >> >> returns
>>> > >> >> quite happily and think it mostly works most of the time... and then
>>> > >> >> find subtle issues and waste our time finding them.
>>> > >> >>
>>> > >> >> how do we protect/stop returns (or goto's for that matter) within
>>> > >> >> the
>>> > >> >> while block. i looked for some pragmas - can't find any to do this.
>>> > >> >> this would be a really useful compiler feature though (to maybe
>>> > >> >> disable
>>> > >> >> some constructs for a sequence of code).
>>> >
>>> > What you seem to be looking for is the cleanup attribute.
>>> >
>>> > #define eo2_do(obj_id, ...)
>>> > do
>>> > {
>>> > obj_ptr_or_ctx = eo2_do_start(obj_id);
>>> > if(!obj_ptr_or_ctx) break;
>>> > do
>>> >{
>>> > obj_ptr_or_ctx_type __attribute__((cleanup(eo2_do_end))
>>> > dummy = obj_ptr_or_ctx;
>>> > __VA_ARGS__ ;
>>> >} while (0);
>>> > } while (0);
>>> >
>>> >
>>> > But then we need to take a look if the cleanup function will run when
>>> > the actual function returns, or when the second "do" runs out of
>>> > scope. This attribute is more commonly used to call free on the
>>> > variable, so it doesn't matter much but for us this would make a
>>> > difference if it involves locking.
>
Re: [E-devel] Eo: potential improvements
On Sat, Jul 27, 2013 at 11:47 PM, Carsten Haitzler wrote:
> On Sat, 27 Jul 2013 22:54:07 +0200 Jérémy Zurcher said:
>
>> On Saturday 27 July 2013 11:10, Carsten Haitzler wrote :
>> > On Fri, 26 Jul 2013 14:57:28 -0300 Lucas De Marchi
>> > said:
>> >
>> > > On Thu, Jul 25, 2013 at 8:54 PM, Carsten Haitzler
>> > > wrote:
>> > > > On Thu, 25 Jul 2013 14:58:30 -0300 Gustavo Sverzut Barbieri
>> > > > said:
>> > > >
>> > > >> On Thu, Jul 25, 2013 at 1:46 PM, Tom Hacohen
>> > > >> wrote:
>> > > >> > On 24/07/13 03:09, Carsten Haitzler (The Rasterman) wrote:
>> > > >> >> On Tue, 23 Jul 2013 18:22:02 +0200 Jérémy Zurcher
>> > > >> >> said:
>> > > >> >>
>> > > >> >>> just to clarify a few points:
>> > > >> >>>
>> > > >> >>> - I think the less macro we have in an eo class declaration the
>> > > >> >>> best, actually we have nothing but that extra first parameter
>> > > >> >>> called eo2_o, wich is either an obj_ptr (devs/tasn/eo2) or a
>> > > >> >>> call_ctx (devs/jeyzu/eo2)
>> > > >> >>>
>> > > >> >>>this should go away if we use a stack per thread in eo private
>> > > >> >>> code, so we end up with a clean
>> > > >> >>>EAPI float times(float f, float t);
>> > > >> >>>
>> > > >> >>> - since day 1 break is supported in eo2_do:
>> > > >> >>>#define eo2_do(obj_id, ...)
>> > > >> >>>do
>> > > >> >>> {
>> > > >> >>> obj_ptr_or_ctx = eo2_do_start(obj_id);
>> > > >> >>> if(!obj_ptr_or_ctx) break;
>> > > >> >>> do { __VA_ARGS__ ; } while (0);
>> > > >> >>> eo2_do_end(obj_ptr_or_ctx);
>> > > >> >>> } while (0)
>> > > >> >>
>> > > >> >> i'm worried about people doing return there. seriously - objid came
>> > > >> >> in becau se of experience that people using efl are in general
>> > > >> >> inexperienced programmers who don't take the time to do things
>> > > >> >> right. they do things quickly and take shortcuts, and they ignore
>> > > >> >> warnings. they'd rather patch out abort()s in efl code forcing them
>> > > >> >> to fix their bugs, than fix their bugs. i am fearful that they will
>> > > >> >> stuff in returns quite happily and think it mostly works most of
>> > > >> >> the time... and then find subtle issues and waste our time finding
>> > > >> >> them.
>> > > >> >>
>> > > >> >> how do we protect/stop returns (or goto's for that matter) within
>> > > >> >> the while block. i looked for some pragmas - can't find any to do
>> > > >> >> this. this would be a really useful compiler feature though (to
>> > > >> >> maybe disable some constructs for a sequence of code).
>> > >
>> > > What you seem to be looking for is the cleanup attribute.
>> > >
>> > > #define eo2_do(obj_id, ...)
>> > > do
>> > > {
>> > > obj_ptr_or_ctx = eo2_do_start(obj_id);
>> > > if(!obj_ptr_or_ctx) break;
>> > > do
>> > >{
>> > > obj_ptr_or_ctx_type __attribute__((cleanup(eo2_do_end))
>> > > dummy = obj_ptr_or_ctx;
>> > > __VA_ARGS__ ;
>> > >} while (0);
>> > > } while (0);
>> > >
>> > >
>> > > But then we need to take a look if the cleanup function will run when
>> > > the actual function returns, or when the second "do" runs out of
>> > > scope. This attribute is more commonly used to call free on the
>> > > variable, so it doesn't matter much but for us this would make a
>> > > difference if it involves locking.
>> > >
>> > > Then you just allow break and return, and the right thing will happen,
>> > > even in those cases.
>> >
>> > voila! that would do it
Re: [E-devel] Eo: potential improvements
On Sat, Jul 27, 2013 at 5:54 PM, Jérémy Zurcher wrote:
> On Saturday 27 July 2013 11:10, Carsten Haitzler wrote :
>> On Fri, 26 Jul 2013 14:57:28 -0300 Lucas De Marchi
>> said:
>>
>> > On Thu, Jul 25, 2013 at 8:54 PM, Carsten Haitzler
>> > wrote:
>> > > On Thu, 25 Jul 2013 14:58:30 -0300 Gustavo Sverzut Barbieri
>> > > said:
>> > >
>> > >> On Thu, Jul 25, 2013 at 1:46 PM, Tom Hacohen
>> > >> wrote:
>> > >> > On 24/07/13 03:09, Carsten Haitzler (The Rasterman) wrote:
>> > >> >> On Tue, 23 Jul 2013 18:22:02 +0200 Jérémy Zurcher
>> > >> >> said:
>> > >> >>
>> > >> >>> just to clarify a few points:
>> > >> >>>
>> > >> >>> - I think the less macro we have in an eo class declaration the
>> > >> >>> best,
>> > >> >>>actually we have nothing but that extra first parameter called
>> > >> >>> eo2_o, wich is either an obj_ptr (devs/tasn/eo2) or a call_ctx
>> > >> >>> (devs/jeyzu/eo2)
>> > >> >>>
>> > >> >>>this should go away if we use a stack per thread in eo private
>> > >> >>> code,
>> > >> >>>so we end up with a clean
>> > >> >>>EAPI float times(float f, float t);
>> > >> >>>
>> > >> >>> - since day 1 break is supported in eo2_do:
>> > >> >>>#define eo2_do(obj_id, ...)
>> > >> >>>do
>> > >> >>> {
>> > >> >>> obj_ptr_or_ctx = eo2_do_start(obj_id);
>> > >> >>> if(!obj_ptr_or_ctx) break;
>> > >> >>> do { __VA_ARGS__ ; } while (0);
>> > >> >>> eo2_do_end(obj_ptr_or_ctx);
>> > >> >>> } while (0)
>> > >> >>
>> > >> >> i'm worried about people doing return there. seriously - objid came
>> > >> >> in
>> > >> >> becau se of experience that people using efl are in general
>> > >> >> inexperienced programmers who don't take the time to do things right.
>> > >> >> they do things quickly and take shortcuts, and they ignore warnings.
>> > >> >> they'd rather patch out abort()s in efl code forcing them to fix
>> > >> >> their
>> > >> >> bugs, than fix their bugs. i am fearful that they will stuff in
>> > >> >> returns
>> > >> >> quite happily and think it mostly works most of the time... and then
>> > >> >> find subtle issues and waste our time finding them.
>> > >> >>
>> > >> >> how do we protect/stop returns (or goto's for that matter) within the
>> > >> >> while block. i looked for some pragmas - can't find any to do this.
>> > >> >> this would be a really useful compiler feature though (to maybe
>> > >> >> disable
>> > >> >> some constructs for a sequence of code).
>> >
>> > What you seem to be looking for is the cleanup attribute.
>> >
>> > #define eo2_do(obj_id, ...)
>> > do
>> > {
>> > obj_ptr_or_ctx = eo2_do_start(obj_id);
>> > if(!obj_ptr_or_ctx) break;
>> > do
>> >{
>> > obj_ptr_or_ctx_type __attribute__((cleanup(eo2_do_end))
>> > dummy = obj_ptr_or_ctx;
>> > __VA_ARGS__ ;
>> >} while (0);
>> > } while (0);
>> >
>> >
>> > But then we need to take a look if the cleanup function will run when
>> > the actual function returns, or when the second "do" runs out of
>> > scope. This attribute is more commonly used to call free on the
>> > variable, so it doesn't matter much but for us this would make a
>> > difference if it involves locking.
>> >
>> > Then you just allow break and return, and the right thing will happen,
>> > even in those cases.
>>
>> voila! that would do it (if it does work on return as well as break and any
>> goto that jumps out of the while scope). if course it'd be dependant on
>> compiler supporting it - if it doesnt, then we cleanup by hand as normal on a
>> break and return/goto just create bugs.
Re: [E-devel] Eo: potential improvements
On Thu, Jul 25, 2013 at 8:54 PM, Carsten Haitzler wrote:
> On Thu, 25 Jul 2013 14:58:30 -0300 Gustavo Sverzut Barbieri
> said:
>
>> On Thu, Jul 25, 2013 at 1:46 PM, Tom Hacohen wrote:
>> > On 24/07/13 03:09, Carsten Haitzler (The Rasterman) wrote:
>> >> On Tue, 23 Jul 2013 18:22:02 +0200 Jérémy Zurcher said:
>> >>
>> >>> just to clarify a few points:
>> >>>
>> >>> - I think the less macro we have in an eo class declaration the best,
>> >>>actually we have nothing but that extra first parameter called eo2_o,
>> >>> wich is either an obj_ptr (devs/tasn/eo2) or a call_ctx (devs/jeyzu/eo2)
>> >>>
>> >>>this should go away if we use a stack per thread in eo private code,
>> >>>so we end up with a clean
>> >>>EAPI float times(float f, float t);
>> >>>
>> >>> - since day 1 break is supported in eo2_do:
>> >>>#define eo2_do(obj_id, ...)
>> >>>do
>> >>> {
>> >>> obj_ptr_or_ctx = eo2_do_start(obj_id);
>> >>> if(!obj_ptr_or_ctx) break;
>> >>> do { __VA_ARGS__ ; } while (0);
>> >>> eo2_do_end(obj_ptr_or_ctx);
>> >>> } while (0)
>> >>
>> >> i'm worried about people doing return there. seriously - objid came in
>> >> becau se of experience that people using efl are in general inexperienced
>> >> programmers who don't take the time to do things right. they do things
>> >> quickly and take shortcuts, and they ignore warnings. they'd rather patch
>> >> out abort()s in efl code forcing them to fix their bugs, than fix their
>> >> bugs. i am fearful that they will stuff in returns quite happily and think
>> >> it mostly works most of the time... and then find subtle issues and waste
>> >> our time finding them.
>> >>
>> >> how do we protect/stop returns (or goto's for that matter) within the
>> >> while
>> >> block. i looked for some pragmas - can't find any to do this. this would
>> >> be a really useful compiler feature though (to maybe disable some
>> >> constructs for a sequence of code).
What you seem to be looking for is the cleanup attribute.
#define eo2_do(obj_id, ...)
do
{
obj_ptr_or_ctx = eo2_do_start(obj_id);
if(!obj_ptr_or_ctx) break;
do
{
obj_ptr_or_ctx_type __attribute__((cleanup(eo2_do_end))
dummy = obj_ptr_or_ctx;
__VA_ARGS__ ;
} while (0);
} while (0);
But then we need to take a look if the cleanup function will run when
the actual function returns, or when the second "do" runs out of
scope. This attribute is more commonly used to call free on the
variable, so it doesn't matter much but for us this would make a
difference if it involves locking.
Then you just allow break and return, and the right thing will happen,
even in those cases.
Lucas De Marchi
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&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] [legacy/eldbus] master 01/01: Backport fixes from EFL tree
On Tue, Jul 16, 2013 at 2:56 PM, José Roberto de Souza - Enlightenment Git wrote: > zehortigoza pushed a commit to branch master. > > commit 7de696d9d258c372d503c8040d79fd061dc3765a > Author: José Roberto de Souza > Date: Tue Jul 16 14:54:36 2013 -0300 > > Backport fixes from EFL tree Which ones?? I did this for the other commit because the code diverged. It would be way better that now we apply the commits that were applied on EFL tree instead of importing everything in one single commit. And they are not only fixes... there are new APIs and other changes. Lucas De Marchi -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Giving José Souza (zehortigoza) commit access
Hey, I think most of you know zehortigoza. He works with me and wrote most of eldbus stuff - I was most of the time just reviewing and acting as a gate keeper. I'd like to give him commit access so he can help maintaining eldbus and involve himself with other EFL stuff as well. Any objections? Otherwise I'll do it tomorrow. Regards, Lucas De Marchi -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl/elm 1.8 (attn!)
On Wed, May 1, 2013 at 1:15 AM, Carsten Haitzler wrote: > so it's on our todo list. is everyone happy now its "eldbus"? :) everyone > happy otherwise? > > cedric - loader module api. if it isnt public by now... it can wait for 1.9. > > tom/bluezery - genlist map stuff... we need to talk... > > cserve2 - need to talk.. > > and dark theme - i know. underway. > > so given the above... do we all think an alpha1 would be a good call today? today? wouldn't "1/2/3 week(s) from today" be much better? As I said, I didn't have time to properly review eldbus API. And seems nobody did (or it was perfect, which I'm sure it isn't). Lucas De Marchi -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Renaming edbus->eldbus
On Tue, Apr 23, 2013 at 12:57 PM, Tom Hacohen wrote: > On 23/04/13 16:55, Tom Hacohen wrote: >> On 23/04/13 16:34, Lucas De Marchi wrote: >>> Hey, as agreed I'm renaming edbus to eldbus. >>> >>> I did it in efl and enlightenment. Attached is the script used. I >>> don't know what are the projects using it, so please apply the >>> attached script to your project. >>> >>> I usually check with "git grep -i edbus" to check if there are any >>> missing references and with find to check if there are missing >>> renames. >> >> Great, thanks! >> >> Also, please don't forget renaming it in the efl repo, and the edbus >> repo. When you are done with those let us know, and we'll rename the >> edbus repo to eldbus (and add a symlink for compat). > > > Don't mind me, I'm slow today. :) And I did it for elementary as well. Lucas De Marchi -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Renaming edbus->eldbus
Hey, as agreed I'm renaming edbus to eldbus. I did it in efl and enlightenment. Attached is the script used. I don't know what are the projects using it, so please apply the attached script to your project. I usually check with "git grep -i edbus" to check if there are any missing references and with find to check if there are missing renames. Regards, Lucas De Marchi rename-edbus.sh Description: Bourne shell script -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: fix recursive proxy rendering to just show a black rectangle
On Tue, Apr 23, 2013 at 10:25 AM, Cedric BAIL wrote: > On Tue, Apr 23, 2013 at 2:52 PM, ChunEon Park wrote: >> Why do we provide Eina_Bool? > > Because some compiler don't support yet bool. I am thinking especially some? The only compiler that doesn't have native support for it is ms visual studio. And it can't compile efl for lots of other reasons. Even if we decide to support, it can be made to work. But it's unsupported for a long time, since the time vtorri was taking care of windows builds so I don't think there's any hope for it. > on some windows one and as some of those Eina_Bool end up in our API > for consistency with use Eina_Bool everywhere in our code. You can let the Eina_Bool in API and internally use bool just fine. No worry about consistency since this would be very consistent as well. Lucas De Marchi -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: fix recursive proxy rendering to just show a black rectangle
On Tue, Apr 23, 2013 at 9:42 AM, David Seikel wrote:
> On Tue, 23 Apr 2013 09:33:47 -0300 Lucas De Marchi
> wrote:
>
>> On Tue, Apr 23, 2013 at 2:06 AM, ChunEon Park
>> wrote:
>> > zmike, How about using EINA_TRUE/EINA_FALSE?
>>
>> much more typing I guess.
>>
>> let's start converting to C99's bool that's already more than a decade
>> over? One simple advantage is less type, another is that the compiler
>> will do the right thing when you do bool a = 20 (i.e. no need for !!)
>
> +1
>
> Er wait, what does "bool a = 20; a + 1" end up being?
#include
#include
int main(void)
{
bool a = 20;
printf("%d\n", a);
a++;
printf("%d\n", a);
return 0;
}
└ tmp ➤ ./a
1
1
Lucas De Marchi
--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: fix recursive proxy rendering to just show a black rectangle
On Tue, Apr 23, 2013 at 2:06 AM, ChunEon Park wrote:
> zmike, How about using EINA_TRUE/EINA_FALSE?
much more typing I guess.
let's start converting to C99's bool that's already more than a decade
over? One simple advantage is less type, another is that the compiler
will do the right thing when you do bool a = 20 (i.e. no need for !!)
Lucas De Marchi
>
>
> -Regards, Hermet-
>
> -Original Message-
> From: "Mike Blumenkrantz - Enlightenment Git"
> To: ;
> Cc:
> Sent: 2013-04-23 (화) 00:41:30
> Subject: [EGIT] [core/efl] master 01/01: fix recursive proxy rendering to
> just show a black rectangle
>
> discomfitor pushed a commit to branch master.
>
> commit 715c77adb9463aceaf8699c8c4aec4cca96a494e
> Author: Mike Blumenkrantz @samsung.com>
> Date: Mon Apr 22 16:41:24 2013 +0100
>
> fix recursive proxy rendering to just show a black rectangle
> ---
> ChangeLog 4
> NEWS 1 +
> src/lib/evas/canvas/evas_object_image.c 14 +++---
> 3 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/ChangeLog b/ChangeLog
> index 927dcc8..0e58b11 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,7 @@
> +2013-04-22 Mike Blumenkrantz
> +
> +* Evas: Fix recursive proxy image rendering to just render black
> +
> 2013-04-22 WooHyun Jung
>
> * Edje: When selected word exists, selection is cleared and cursor
> diff --git a/NEWS b/NEWS
> index d788220..e0c00a7 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -253,3 +253,4 @@ Fixes:
> * Edje: Fix useless ecore_imf_context_reset call in case of pressing ESC
> and Return key
> * Edje: When selected word exists, selection is cleared and cursor
> remains on the current entry by additional key input.
> * Ecore-X: Fix selection parser to not overrun buffer read by using
> longs on 64bit.
> +* Evas: Fix recursive proxy image rendering to just render black
> diff --git a/src/lib/evas/canvas/evas_object_image.c
> b/src/lib/evas/canvas/evas_object_image.c
> index 44d27d7..db572b4 100644
> --- a/src/lib/evas/canvas/evas_object_image.c
> +++ b/src/lib/evas/canvas/evas_object_image.c
> @@ -121,6 +121,7 @@ struct _Evas_Object_Image
> Eina_Bool video_surface : 1;
> Eina_Bool video_visible : 1;
> Eina_Bool created : 1;
> + Eina_Bool proxyerror : 1;
> };
>
> /* private methods for image objects */
> @@ -2225,6 +2226,7 @@ _image_load_size_set(Eo *eo_obj, void *_pd, va_list
> *list)
> o->changed = EINA_TRUE;
> evas_object_change(eo_obj, obj);
> }
> + o->proxyerror = 0;
> }
>
> EAPI void
> @@ -3124,6 +3126,7 @@ _proxy_set(Evas_Object *eo_proxy, Evas_Object *eo_src)
> state_write->source = eo_src;
> EINA_COW_IMAGE_STATE_WRITE_END(o, state_write);
> o->load_error = EVAS_LOAD_ERROR_NONE;
> + o->proxyerror = 0;
>
> EINA_COW_WRITE_BEGIN(evas_object_proxy_cow, src->proxy,
> Evas_Object_Proxy_Data, proxy_src_write)
> {
> @@ -3142,17 +3145,14 @@ _proxy_error(Evas_Object *eo_proxy, void *context,
> void *output, void *surface,
> int x, int y, Eina_Bool do_async)
> {
> Evas_Func *func;
> - int r = rand() % 255;
> - int g = rand() % 255;
> - int b = rand() % 255;
> + Evas_Object_Image *o = eo_data_get(eo_proxy, MY_CLASS);
>
> - /* XXX: Eina log error or something I'm sure
> -* If it bugs you, just fix it. Don't tell me */
> - if (VERBOSE_PROXY_ERROR) printf("Err: Argh! Recursive proxies.\n");
> + if (!o->proxyerror) printf("Err: Argh! Recursive proxies.\n");
> + o->proxyerror = 1;
>
> Evas_Object_Protected_Data *proxy = eo_data_get(eo_proxy, EVAS_OBJ_CLASS);
> func = proxy->layer->evas->engine.func;
> - func->context_color_set(output, context, r, g, b, 255);
> + func->context_color_set(output, context, 0, 0, 0, 255);
> func->context_multiplier_unset(output, context);
> func->context_render_op_set(output, context, proxy->cur->render_op);
> func->rectangle_draw(output, context, surface, proxy->cur->geometry.x + x,
>
> --
>
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogp
Re: [E-devel] edbus - Annoying inconsistency
On Apr 17, 2013 11:49 AM, "Rafael Antognolli" wrote: > > On Wed, Apr 17, 2013 at 10:09 AM, Cedric BAIL wrote: > > Cedric Bail > > On Apr 17, 2013 2:22 AM, "Tom Hacohen" wrote: > >> > >> On 17/04/13 02:28, Jérôme Pinot wrote: > >> > On 04/17/13 10:11, David Seikel wrote: > >> >> On Tue, 16 Apr 2013 20:57:33 -0300 Lucas De Marchi > >> >> wrote: > >> >> > >> >>> On Tue, Apr 16, 2013 at 8:34 PM, Carsten Haitzler > >> >>> wrote: > >> >>>> On Tue, 16 Apr 2013 16:24:08 -0300 Lucas De Marchi > >> >>>> said: > >> >>>> > >> >>>>> On Tue, Apr 16, 2013 at 4:13 PM, > >> >>>>> wrote: > >> >>>>>> Tom Hacohen wrote: > >> >>>>>>> > >> >>>>>>> On 16/04/13 16:01, Lucas De Marchi wrote: > >> >>>>>>>> > >> >>>>>>>> On Tue, Apr 16, 2013 at 11:54 AM, Tom Hacohen > >> >>>>>>>> wrote: > >> >>>>>>>>> > >> >>>>>>>>> On 16/04/13 15:26, Lucas De Marchi wrote: > >> >>>>>>>>> > >> >>>>>>>>>> On Tue, Apr 16, 2013 at 11:12 AM, Tom Hacohen > >> >>>>>>>>>> wrote: > >> >>>>>>>>>> > >> >>>>>>>>>>> Hey guys, > >> >>>>>>>>>>> > >> >>>>>>>>>>> How are you? I just noticed that 'edbus' installs headers > >> >>>>>>>>>>> under: prefix/include/edbus-1 > >> >>>>>>>>>>> while using the > >> >>>>>>>>>>> pkgconfig name 'edbus2' > >> >>>>>>>>>>> the library name 'libedbus2' > >> >>>>>>>>>>> and an header called 'EDbus.h'. > >> >>>>>>>>>>> > >> >>>>>>>>>>> Luckily for us, it's not too late to fix it. Only question, > >> >>>>>>>>>>> what should > >> >>>>>>>>>>> we > >> >>>>>>>>>>> change it to? Everywhere with the 2 or everywhere without > >> >>>>>>>>>>> the 2? > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> E_DBus installed edbus.pc and libedbus.so - that's why we > >> >>>>>>>>>> needed to put a 2 in the name. > >> >>>>>>>>>> > >> >>>>>>>>>> However the name is edbus and has no relations with the > >> >>>>>>>>>> previous library. It's not a new version, it's a complete > >> >>>>>>>>>> different one. So appending a "2" in headers and include > >> >>>>>>>>>> path is the wrong thing to do. > >> >>>>>>>>>> > >> >>>>>>>>>> If ebus was available I would vote for that. It seems we are > >> >>>>>>>>>> short in options for names. > >> >>>>>>>>>> > >> >>>>>>>>>> Lucas De Marchi > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> I understand putting the 2 was needed, but if we add it once, > >> >>>>>>>>> we should add > >> >>>>>>>>> it everywhere. It's annoyingly inconsistent. > >> >>>>>>>>> > >> >>>>>>>>> Why did you choose 2 then? Why not 4? Or A? You chose 2 > >> >>>>>>>>> because it's the > >> >>>>>>>>> best explanation, as it is, although mostly unrelated, e_dbus > >> >>>>>>>>> v2. And if > >
Re: [E-devel] edbus - Annoying inconsistency
On Tue, Apr 16, 2013 at 8:34 PM, Carsten Haitzler wrote: > On Tue, 16 Apr 2013 16:24:08 -0300 Lucas De Marchi > said: > >> On Tue, Apr 16, 2013 at 4:13 PM, wrote: >> > Tom Hacohen wrote: >> >> >> >> On 16/04/13 16:01, Lucas De Marchi wrote: >> >>> >> >>> On Tue, Apr 16, 2013 at 11:54 AM, Tom Hacohen >> >>> wrote: >> >>>> >> >>>> On 16/04/13 15:26, Lucas De Marchi wrote: >> >>>> >> >>>>> On Tue, Apr 16, 2013 at 11:12 AM, Tom Hacohen >> >>>>> wrote: >> >>>>> >> >>>>>> Hey guys, >> >>>>>> >> >>>>>> How are you? I just noticed that 'edbus' installs headers under: >> >>>>>> prefix/include/edbus-1 >> >>>>>> while using the >> >>>>>> pkgconfig name 'edbus2' >> >>>>>> the library name 'libedbus2' >> >>>>>> and an header called 'EDbus.h'. >> >>>>>> >> >>>>>> Luckily for us, it's not too late to fix it. Only question, what >> >>>>>> should >> >>>>>> we >> >>>>>> change it to? Everywhere with the 2 or everywhere without the 2? >> >>>>> >> >>>>> >> >>>>> >> >>>>> E_DBus installed edbus.pc and libedbus.so - that's why we needed to >> >>>>> put a 2 in the name. >> >>>>> >> >>>>> However the name is edbus and has no relations with the previous >> >>>>> library. It's not a new version, it's a complete different one. So >> >>>>> appending a "2" in headers and include path is the wrong thing to do. >> >>>>> >> >>>>> If ebus was available I would vote for that. It seems we are short in >> >>>>> options for names. >> >>>>> >> >>>>> Lucas De Marchi >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> I understand putting the 2 was needed, but if we add it once, we should >> >>>> add >> >>>> it everywhere. It's annoyingly inconsistent. >> >>>> >> >>>> Why did you choose 2 then? Why not 4? Or A? You chose 2 because >> >>>> it's the >> >>>> best explanation, as it is, although mostly unrelated, e_dbus v2. And if >> >>> >> >>> >> >>> because it was not me is the best explanation. >> >>> >> >>>> that's good enough there, it's good enough everywhere. >> >>>> >> >>>> In conclusion, I see no harm in using edbus2 all around the place. >> >>> >> >>> >> >>> it's not good enough there, even less everywhere. The visible part to >> >>> the developer is the include path and the namespace. And these should >> >>> reflect the library name. If anything change everything to something >> >>> else, but don't put the 2 there. >> >> >> >> >> >> >> >> Let's wait to see what others think, as we disagree about the source of >> >> the problem, and that's: is this a major inconsistency that should be >> >> solved. >> >> >> >> Anyhow, regarding different names: I suggest edbus2. >> >> >> >> -- >> >> Tom. >> >> >> >> >> >> >> >> >> >> Precog is a next-generation analytics platform capable of advanced >> >> analytics on semi-structured data. The platform includes APIs for building >> >> apps and a phenomenal toolset for data science. Developers can use >> >> our toolset for easy data analysis & visualization. Get a free account! >> >> http://www2.precog.com/precogplatform/slashdotnewsletter >> >> >> >> >> >> enlightenment-devel mailing list >> >> enlightenment-devel@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > >> > >> > I agree with whatever demarchi says. >> >> I disagree. >> >> >> oh, wait... >> >> Lucas De Marchi > > :-P ... i have to say though - consistency is good. not just for devs, but > packagers and anyone looking at their filesystem. if things are named in a > consistent pattern it is easy to know what belongs where without needing > package databases or other forensics tools. Sure it's good, no doubt. Just that renaming to edbus2 for the sake of consistency is even worse, not because of the rename, but because of the name chosen. ebus? anyone? Lucas De Marchi -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edbus - Annoying inconsistency
On Tue, Apr 16, 2013 at 4:13 PM, wrote: > Tom Hacohen wrote: >> >> On 16/04/13 16:01, Lucas De Marchi wrote: >>> >>> On Tue, Apr 16, 2013 at 11:54 AM, Tom Hacohen >>> wrote: >>>> >>>> On 16/04/13 15:26, Lucas De Marchi wrote: >>>> >>>>> On Tue, Apr 16, 2013 at 11:12 AM, Tom Hacohen >>>>> wrote: >>>>> >>>>>> Hey guys, >>>>>> >>>>>> How are you? I just noticed that 'edbus' installs headers under: >>>>>> prefix/include/edbus-1 >>>>>> while using the >>>>>> pkgconfig name 'edbus2' >>>>>> the library name 'libedbus2' >>>>>> and an header called 'EDbus.h'. >>>>>> >>>>>> Luckily for us, it's not too late to fix it. Only question, what >>>>>> should >>>>>> we >>>>>> change it to? Everywhere with the 2 or everywhere without the 2? >>>>> >>>>> >>>>> >>>>> E_DBus installed edbus.pc and libedbus.so - that's why we needed to >>>>> put a 2 in the name. >>>>> >>>>> However the name is edbus and has no relations with the previous >>>>> library. It's not a new version, it's a complete different one. So >>>>> appending a "2" in headers and include path is the wrong thing to do. >>>>> >>>>> If ebus was available I would vote for that. It seems we are short in >>>>> options for names. >>>>> >>>>> Lucas De Marchi >>>> >>>> >>>> >>>> >>>> I understand putting the 2 was needed, but if we add it once, we should >>>> add >>>> it everywhere. It's annoyingly inconsistent. >>>> >>>> Why did you choose 2 then? Why not 4? Or A? You chose 2 because >>>> it's the >>>> best explanation, as it is, although mostly unrelated, e_dbus v2. And if >>> >>> >>> because it was not me is the best explanation. >>> >>>> that's good enough there, it's good enough everywhere. >>>> >>>> In conclusion, I see no harm in using edbus2 all around the place. >>> >>> >>> it's not good enough there, even less everywhere. The visible part to >>> the developer is the include path and the namespace. And these should >>> reflect the library name. If anything change everything to something >>> else, but don't put the 2 there. >> >> >> >> Let's wait to see what others think, as we disagree about the source of >> the problem, and that's: is this a major inconsistency that should be >> solved. >> >> Anyhow, regarding different names: I suggest edbus2. >> >> -- >> Tom. >> >> >> >> >> Precog is a next-generation analytics platform capable of advanced >> analytics on semi-structured data. The platform includes APIs for building >> apps and a phenomenal toolset for data science. Developers can use >> our toolset for easy data analysis & visualization. Get a free account! >> http://www2.precog.com/precogplatform/slashdotnewsletter >> >> >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > I agree with whatever demarchi says. I disagree. oh, wait... Lucas De Marchi -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edbus - Annoying inconsistency
On Tue, Apr 16, 2013 at 11:54 AM, Tom Hacohen wrote: > On 16/04/13 15:26, Lucas De Marchi wrote: >> >> On Tue, Apr 16, 2013 at 11:12 AM, Tom Hacohen >> wrote: >>> >>> Hey guys, >>> >>> How are you? I just noticed that 'edbus' installs headers under: >>> prefix/include/edbus-1 >>> while using the pkgconfig name 'edbus2' >>> the library name 'libedbus2' >>> and an header called 'EDbus.h'. >>> >>> Luckily for us, it's not too late to fix it. Only question, what should >>> we >>> change it to? Everywhere with the 2 or everywhere without the 2? >> >> >> E_DBus installed edbus.pc and libedbus.so - that's why we needed to >> put a 2 in the name. >> >> However the name is edbus and has no relations with the previous >> library. It's not a new version, it's a complete different one. So >> appending a "2" in headers and include path is the wrong thing to do. >> >> If ebus was available I would vote for that. It seems we are short in >> options for names. >> >> Lucas De Marchi >> > > > I understand putting the 2 was needed, but if we add it once, we should add > it everywhere. It's annoyingly inconsistent. > > Why did you choose 2 then? Why not 4? Or A? You chose 2 because it's the > best explanation, as it is, although mostly unrelated, e_dbus v2. And if because it was not me is the best explanation. > that's good enough there, it's good enough everywhere. > > In conclusion, I see no harm in using edbus2 all around the place. it's not good enough there, even less everywhere. The visible part to the developer is the include path and the namespace. And these should reflect the library name. If anything change everything to something else, but don't put the 2 there. Lucas De Marchi -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edbus - Annoying inconsistency
On Tue, Apr 16, 2013 at 11:12 AM, Tom Hacohen wrote: > Hey guys, > > How are you? I just noticed that 'edbus' installs headers under: > prefix/include/edbus-1 > while using the pkgconfig name 'edbus2' > the library name 'libedbus2' > and an header called 'EDbus.h'. > > Luckily for us, it's not too late to fix it. Only question, what should we > change it to? Everywhere with the 2 or everywhere without the 2? E_DBus installed edbus.pc and libedbus.so - that's why we needed to put a 2 in the name. However the name is edbus and has no relations with the previous library. It's not a new version, it's a complete different one. So appending a "2" in headers and include path is the wrong thing to do. If ebus was available I would vote for that. It seems we are short in options for names. Lucas De Marchi -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/enlightenment] master 01/03: e: add support for systemd user session.
On Sat, Mar 30, 2013 at 6:22 AM, Cedric Bail - Enlightenment Git
wrote:
> cedric pushed a commit to branch master.
>
> commit cd28bc814552bf52bb670e108343b23d48fa839e
> Author: Cedric Bail
> Date: Thu Mar 28 23:53:24 2013 +0900
>
> e: add support for systemd user session.
> ---
> ChangeLog | 4
> NEWS | 1 +
> configure.ac | 7 +++
> data/Makefile.am | 4 +++-
> data/units/Makefile.am | 9 +
> data/units/e18.service | 27 +
> m4/pkg_var.m4 | 14 +
> src/bin/e_main.c | 55
> ++
> 8 files changed, 94 insertions(+), 27 deletions(-)
>
> diff --git a/ChangeLog b/ChangeLog
> index b040cf5..2b19cb2 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,7 @@
> +2013-03-28 Cedric Bail
> +
> + * added support for systemd user session.
> +
> 2013-03-11 Mike Blumenkrantz
>
> * menus are now drawn directly on the compositor canvas
> diff --git a/NEWS b/NEWS
> index d8cf3ac..c5d08c7 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -45,6 +45,7 @@ Additions:
> * new option for disabling all pointer warps
> * added option for preventing all keyboard layout changes
> * added option for remembering filemanager windows globally
> + * Added support for systemd user session
Al the others are spaces, you added tabs.
>
> Changes:
> Modules:
> diff --git a/configure.ac b/configure.ac
> index ef09d46..34e68dd 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -205,6 +205,12 @@ if test "x${have_bluetooth}" = "xyes"; then
> AC_DEFINE_UNQUOTED([HAVE_BLUETOOTH], [1], [Bluetooth is there])
> fi
>
> +# Detect systemd user session directory properly
> +EFL_PKG_CHECK_VAR([USER_SESSION_DIR], [systemd], [systemduserunitdir],
> + [have_systemd_user_session="yes"], [have_systemd_user_session="no"])
> +AM_CONDITIONAL([HAVE_SYSTEMD_USER_SESSION], [test
> "x${have_systemd_user_session}" = "xyes"])
> +AC_SUBST([USER_SESSION_DIR])
> +
it's missing a --with-systemduserunitdir like other packages have.
> execinfo_libs=""
> AC_CHECK_HEADERS([execinfo.h], [have_execinfo="yes"], [have_execinfo="no"])
> if test "x${have_execinfo}" = "xyes" ; then
> @@ -1009,6 +1015,7 @@ data/etc/Makefile
> data/etc/sysactions.conf
> data/icons/Makefile
> data/backgrounds/Makefile
> +data/units/Makefile
> doc/Makefile
> doc/Doxyfile
> doc/e.dox
> diff --git a/data/Makefile.am b/data/Makefile.am
> index f320e9d..dbd5a42 100644
> --- a/data/Makefile.am
> +++ b/data/Makefile.am
> @@ -10,4 +10,6 @@ icons \
> backgrounds \
> flags \
> favorites \
> -desktop
> +desktop \
> +units
> +
> diff --git a/data/units/Makefile.am b/data/units/Makefile.am
> new file mode 100644
> index 000..04ed87f
> --- /dev/null
> +++ b/data/units/Makefile.am
> @@ -0,0 +1,9 @@
> +AUTOMAKE_OPTIONS = 1.4 foreign
> +MAINTAINERCLEANFILES = Makefile.in
> +
> +if HAVE_SYSTEMD_USER_SESSION
> +unitsdir = $(USER_SESSION_DIR)
> +units_DATA = e18.service
> +endif
> +
> +EXTRA_DIST = $(units_DATA)
> diff --git a/data/units/e18.service b/data/units/e18.service
> new file mode 100644
> index 000..79feb40
> --- /dev/null
> +++ b/data/units/e18.service
> @@ -0,0 +1,27 @@
> +[Unit]
> +Description=Enlightenment 17 service
> +Before=end.target
> +After=xorg.target
> +Requires=xorg.target
> +Requires=dbus.socket
> +Requires=pulseaudio.service
> +Requires=ssh-agent.service
> +AllowIsolate=true
> +
> +[Service]
> +Type=notify
> +#Environment=PATH=uncomment:to:override:your:PATH
> +Environment=E_START=enlightenment
> +ExecStart=/usr/bin/enlightenment
It should use prefix
> +Restart=always
> +RestartPreventExitStatus=0
> +RestartSec=2
> +StartLimitInterval=30
> +StartLimitBurst=7
> +KillMode=process
> +WatchdogSec=1
> +TimeoutSec=1
> +NotifyAccess=all
> +
> +[Install]
> +WantedBy=wm.target
> diff --git a/m4/pkg_var.m4 b/m4/pkg_var.m4
> new file mode 100644
> index 000..3d0a309
> --- /dev/null
> +++ b/m4/pkg_var.m4
> @@ -0,0 +1,14 @@
> +# PKG_CHECK_VAR(VARIABLE, MODULE, CONFIG-VARIABLE,
> +# [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
> +# ---
> +# Retrieves the value of the pkg-config variable for the given module.
> +AC_DEFUN([EFL_PKG_CHECK_VAR],
> +[AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl
> +AC_ARG_VAR([$1], [value of $3 for $2, overriding pkg-config])dnl
> +
> +_PKG_CONFIG([$1], [variable="][$3]["], [$2])
> +AS_VAR_COPY([$1], [pkg_cv_][$1])
> +
> +AS_VAR_IF([$1], [""], [$5], [$4])dnl
> +])# PKG_CHECK_VAR
> +
> diff --git a/src/bin/e_main.c b/src/bin/e_main.c
> index 2df3d96..a6cc382 100644
> --- a/src/bin/e_main.c
> +++ b/src/bin/e_main.c
> @@ -187,32 +187,35 @@ main(int argc, char **argv)
> /* trap deadly bug signals and allow some form of sane recovery */
> /* or ability to gdb attach and debug at this point - better than your */
> /* wm/desktop vanishing and not knowing what happened */
> - TS("Signal Tra
Re: [E-devel] [e-users] Systemd integration
On Mar 29, 2013 3:23 PM, "Gustavo Sverzut Barbieri" wrote: > > good one :-) Yeah, indeed > > it would be good to move some e17 services to systemd services (fm daemon, > thumbnailer...) It'd be really good Lucas De Marchi > > > On Fri, Mar 29, 2013 at 5:58 AM, Cedric BAIL wrote: > > > Hello everyone, > > > > A little news from the b0rker master. I found a really great > > opportunity to bork Enlightenment and EFL by joining force in > > Lennart's evil attempt to break the world with his work on Systemd. I > > believe he should receive an honorary borker cup like all proud > > members of the Enlightenment borker team for his attempt to break the > > network, the audio and now the boot system. Here, I am only taking > > care of breaking the last miles with EFL and Enlightenment :-) > > > > More seriously, what does that means and provide to EFL applications. > > EFL 1.8 will automatically detect if an application was started by > > systemd and will automatically turn on a few features : > > - notify systemd when the main loop is starting running > > - eina_log will send logs directly to journald > > - detect if it needs to ping back systemd watchdog. > > It also make it possible for all Ecore_Con server to become socket > > activated if they wish with just one flags to set at creation time. > > EFL will automatically check if it is the correct type and if the > > configuration is correct. > > > > The only thing left is for an application that may use it, to provide > > a systemd service description. You can look at elev8 for an example of > > it. > > > > I will later this week add its own systemd user session to > > Enlightenment that will remove the need to use enlightenment_start on > > system that work with systemd user session. > > > > For all of those that sadly don't have access or don't want to use > > systemd due to their religion, they will just have the same experience > > as today and just not benefit from all the reliability and > > simplification that systemd provide. > > > > Enjoy the breakage ! > > -- > > Cedric BAIL > > > > > > -- > > Own the Future-Intel(R) Level Up Game Demo Contest 2013 > > Rise to greatness in Intel's independent game demo contest. Compete > > for recognition, cash, and the chance to get your game on Steam. > > $5K grand prize plus 10 genre and skill prizes. Submit your demo > > by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 > > ___ > > enlightenment-users mailing list > > enlightenment-us...@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > > > > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > -- > Own the Future-Intel(R) Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. Compete > for recognition, cash, and the chance to get your game on Steam. > $5K grand prize plus 10 genre and skill prizes. Submit your demo > by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edbus.git
On Tue, Mar 26, 2013 at 1:34 PM, Daniel Willmann wrote: > On 26/03/13 15:42, Bruno Dilly wrote: >> On Tue, Mar 26, 2013 at 12:38 PM, Daniel Willmann >> wrote: >>> On 26/03/13 15:27, Lucas De Marchi wrote: >>>> On Tue, Mar 26, 2013 at 7:35 AM, Daniel Willmann >> >>>> wrote: >>>>> Hey, >>>>> >>>>> On 25/03/13 19:51, Lucas De Marchi wrote: >>>>> >>>>>> There wasn't any edbus release. It seems it was wrongly tagged as >> 1.7. >>>>>> Please remove the tag in >>>>>> http://git.enlightenment.org/legacy/edbus.git/ >>>>> >>>>> That's not a tag, but a branch. As this repository is needed solely >> for >>>>> the 1.7.x release (1.8 will be merged efl), we're preparing for the >>>>> 1.7.x release and there will be no "new" development in here anyway I >>>>> created the 1.7 branch. >>> >>>> A tag or a branch, it's wrong!! There has never been a release of >>>> edbus. Only e_dbus had a release. I'm insisting on this because edbus >>>> is integrated on core/efl now and I don't want people coming to say we >>>> broke the API. We didn't break simply because there wasn't any >>>> release. >>> >>> Sure, and the lack of tags reflects that. I was under the impression >>> that edbus was needed because it will be released in the next cycle of >>> 1.7.x releases. It seems this was wrong so I'm more than happy to remove >>> the repo completely. >>> >>>> Again, please remove this branch. For me it's also fine to plain >>>> remove the repository. >>> >>> That is completely fine with me. Will remove then. >> >> Please, don't do it! >> >> Just remove the branch 1.7 and tag from edbus. >> We still need it before the merge. >> >> Yeah, it wasn't released, but it was merged, and we should be able to >> use it with efl 1.7 > > http://git.enlightenment.org/legacy/edbus.git/ Ok, let me see if I can maintain both without much trouble. Then everybody is happy. thanks Lucas De Marchi -- Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edbus.git
On Tue, Mar 26, 2013 at 12:52 PM, Michael Blumenkrantz wrote: > On Tue, 26 Mar 2013 12:47:33 -0300 > Lucas De Marchi wrote: > >> On Tue, Mar 26, 2013 at 12:41 PM, Michael Blumenkrantz >> wrote: >> > On Tue, 26 Mar 2013 15:38:21 + >> > Daniel Willmann wrote: >> > >> >> On 26/03/13 15:27, Lucas De Marchi wrote: >> >> > On Tue, Mar 26, 2013 at 7:35 AM, Daniel Willmann >> >> > >> >> > wrote: >> >> >> Hey, >> >> >> >> >> >> On 25/03/13 19:51, Lucas De Marchi wrote: >> >> >> >> >> >>> There wasn't any edbus release. It seems it was wrongly tagged as 1.7. >> >> >>> Please remove the tag in >> >> >>> http://git.enlightenment.org/legacy/edbus.git/ >> >> >> >> >> >> That's not a tag, but a branch. As this repository is needed solely for >> >> >> the 1.7.x release (1.8 will be merged efl), we're preparing for the >> >> >> 1.7.x release and there will be no "new" development in here anyway I >> >> >> created the 1.7 branch. >> >> >> >> > A tag or a branch, it's wrong!! There has never been a release of >> >> > edbus. Only e_dbus had a release. I'm insisting on this because edbus >> >> > is integrated on core/efl now and I don't want people coming to say we >> >> > broke the API. We didn't break simply because there wasn't any >> >> > release. >> >> >> >> Sure, and the lack of tags reflects that. I was under the impression >> >> that edbus was needed because it will be released in the next cycle of >> >> 1.7.x releases. It seems this was wrong so I'm more than happy to remove >> >> the repo completely. >> >> >> >> > Again, please remove this branch. For me it's also fine to plain >> >> > remove the repository. >> >> >> >> That is completely fine with me. Will remove then. >> >> >> >> >> >> Daniel >> >> >> > >> > removing the repo is not a good option. I don't care if you stick it in my >> > dev space, but there needs to be an edbus repo somewhere. >> >> >> So at least let's make it synchronized? I remember you fixing a bug >> that didn't exist because you were using the separate repository. I >> am perfectly fine making the other way around... removing edbus from >> inside core/efl until it's settled for a release. Right now I want to >> add and remove functions from the API. I think everybody would be >> happy with this approach. >> >> >> Daniel, hold on removing the repository. >> >> >> Lucas De Marchi >> > > I always tried to keep it synchronized. If I failed then it's because I > didn't make copying your commits a full-time job. There's a handful of commits missing already. And some really important ones. If we are going to support efl 1.7 + edbus, let's put it outside of core/efl, make a 1.7 release when it's ready and then move it back to core/efl. Lucas De Marchi -- Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edbus.git
On Tue, Mar 26, 2013 at 12:41 PM, Michael Blumenkrantz wrote: > On Tue, 26 Mar 2013 15:38:21 + > Daniel Willmann wrote: > >> On 26/03/13 15:27, Lucas De Marchi wrote: >> > On Tue, Mar 26, 2013 at 7:35 AM, Daniel Willmann >> > wrote: >> >> Hey, >> >> >> >> On 25/03/13 19:51, Lucas De Marchi wrote: >> >> >> >>> There wasn't any edbus release. It seems it was wrongly tagged as 1.7. >> >>> Please remove the tag in >> >>> http://git.enlightenment.org/legacy/edbus.git/ >> >> >> >> That's not a tag, but a branch. As this repository is needed solely for >> >> the 1.7.x release (1.8 will be merged efl), we're preparing for the >> >> 1.7.x release and there will be no "new" development in here anyway I >> >> created the 1.7 branch. >> >> > A tag or a branch, it's wrong!! There has never been a release of >> > edbus. Only e_dbus had a release. I'm insisting on this because edbus >> > is integrated on core/efl now and I don't want people coming to say we >> > broke the API. We didn't break simply because there wasn't any >> > release. >> >> Sure, and the lack of tags reflects that. I was under the impression >> that edbus was needed because it will be released in the next cycle of >> 1.7.x releases. It seems this was wrong so I'm more than happy to remove >> the repo completely. >> >> > Again, please remove this branch. For me it's also fine to plain >> > remove the repository. >> >> That is completely fine with me. Will remove then. >> >> >> Daniel >> > > removing the repo is not a good option. I don't care if you stick it in my > dev space, but there needs to be an edbus repo somewhere. So at least let's make it synchronized? I remember you fixing a bug that didn't exist because you were using the separate repository. I am perfectly fine making the other way around... removing edbus from inside core/efl until it's settled for a release. Right now I want to add and remove functions from the API. I think everybody would be happy with this approach. Daniel, hold on removing the repository. Lucas De Marchi -- Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edbus.git
On Tue, Mar 26, 2013 at 7:35 AM, Daniel Willmann wrote: > Hey, > > On 25/03/13 19:51, Lucas De Marchi wrote: > >> There wasn't any edbus release. It seems it was wrongly tagged as 1.7. >> Please remove the tag in >> http://git.enlightenment.org/legacy/edbus.git/ > > That's not a tag, but a branch. As this repository is needed solely for > the 1.7.x release (1.8 will be merged efl), we're preparing for the > 1.7.x release and there will be no "new" development in here anyway I > created the 1.7 branch. A tag or a branch, it's wrong!! There has never been a release of edbus. Only e_dbus had a release. I'm insisting on this because edbus is integrated on core/efl now and I don't want people coming to say we broke the API. We didn't break simply because there wasn't any release. Again, please remove this branch. For me it's also fine to plain remove the repository. Lucas De Marchi -- Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] edbus.git
Hey, There wasn't any edbus release. It seems it was wrongly tagged as 1.7. Please remove the tag in http://git.enlightenment.org/legacy/edbus.git/ Also I think legacy/e_dbus should have its description like the other libraries or maybe "Legacy library e_dbus, replaced by edbus in core/efl" Tom/Daniel, why I am the author of most of that patches btw? Shouldn't the "Patch-by:" have been applied? Lucas De Marchi -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: mike_m IN trunk/efl/src/bin: edbus edje
On Thu, Mar 21, 2013 at 5:15 AM, Mike McCormack wrote: > On 03/21/2013 01:28 PM, Lucas De Marchi wrote: > >> And for those of you to insist in disagreeing, go complaint to GCC devs now: >> >> http://lwn.net/Articles/542920/ >> " In addition, -pedantic has been deprecated (in favor of -Wpedantic), >> and -Wshadow has been fixed. -Wshadow now permits a common use-case >> certain kernel developers have long complained was erroneously flagged >> as invalid." >> >> With a link to exactly the same thread I pointed out. > > So the only build configuration that should be warning free is bleeding > edge Gentoo with the latest alpha of gcc or Tizen, right? It was directed to people arguing the old -Wshadow was right, not to people arguing we should keep a warning free build. So your sarcasm here makes no sense. Lucas De Marchi -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL 1.8 release plan
On Thu, Mar 21, 2013 at 12:16 AM, Carsten Haitzler wrote: > On Thu, 21 Mar 2013 00:13:02 -0300 Lucas De Marchi > said: > >> On Wed, Mar 20, 2013 at 11:21 PM, Cedric BAIL wrote: >> > Hey guys, >> > >> > Let's put some goal for the coming release of EFL 1.8. It is clearly >> > not yet ready for a release and I know that we have still a few >> > features we want to push in. I would say that having one month or so >> > to push those and then a one month feature freeze should be good. >> > So what is your opinion to do an alpha on the 1st of May and start >> > the feature freeze at that time ? >> >> I'd still want to review some APIs (aka remove/rename) in edbus, add >> some others and optimize some paths. >> I'm not sure I'll have time till there (also because I stopped using >> trunk since recent breakages). So looking to the most critical stuff >> for a release it would be the removals and renames. I'd be really >> grateful if someone else could review the API too and give feedback. > > i think that pretty much all devs need to use trunk/master now. regardless of > the pain. that's what it means to be a dev. I agree, and I do that when I'm developing EFL. Actually I always did that, even when developing other things. The recent breakages and frustrations however made me switch away from trunk to EFL stable. Since right now I'm mostly doing other stuff not related to EFL, I don't think I'll have much time for doing the aforementioned tasks. That's why I'm asking for help here. Lucas De Marchi -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL 1.8 release plan
On Wed, Mar 20, 2013 at 11:21 PM, Cedric BAIL wrote: > Hey guys, > > Let's put some goal for the coming release of EFL 1.8. It is clearly > not yet ready for a release and I know that we have still a few > features we want to push in. I would say that having one month or so > to push those and then a one month feature freeze should be good. > So what is your opinion to do an alpha on the 1st of May and start > the feature freeze at that time ? I'd still want to review some APIs (aka remove/rename) in edbus, add some others and optimize some paths. I'm not sure I'll have time till there (also because I stopped using trunk since recent breakages). So looking to the most critical stuff for a release it would be the removals and renames. I'd be really grateful if someone else could review the API too and give feedback. Thanks Lucas De Marchi -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: mike_m IN trunk/efl/src/bin: edbus edje
On Tue, Jan 15, 2013 at 9:08 PM, Tom Hacohen wrote:
> On Mon, Jan 14, 2013 at 10:33 PM, Lucas De Marchi <
> lucas.demar...@profusion.mobi> wrote:
>
>> On Mon, Jan 14, 2013 at 6:32 PM, Tom Hacohen wrote:
>> > How is this a bug in the compiler?
>> > bla = func_name;
>> > and
>> > bla = var_name;
>> > are both valid C statements, it's a bug if they "fixed" it.
>>
>> both are valid, not together... what are you trying to do here?
>>
>> I am not saying -Wshadow is useless. In the snippet below the warning
>> is valid (and GCC 4.7 correctly warns about it):
>>
>> int f(void)
>> {
>> return 0;
>> }
>>
>> int main(void)
>> {
>> int f = 0;
>> return f++;
>> }
>>
>> However in the following snippet there's no way the programmer would
>> be confused about signal:
>>
>> #include
>>
>> int main(void)
>> {
>> int signal = 0;
>>
>> return signal;
>> }
>>
>>
>> signal is a pointer to a function that lives in another TU. What I am
>> saying is essentially the same Linus said on his email I pointed out.
>>
>
> I know this thread, I've read it before. I disagree with that statement
> though.
And for those of you to insist in disagreeing, go complaint to GCC devs now:
http://lwn.net/Articles/542920/
" In addition, -pedantic has been deprecated (in favor of -Wpedantic),
and -Wshadow has been fixed. -Wshadow now permits a common use-case
certain kernel developers have long complained was erroneously flagged
as invalid."
With a link to exactly the same thread I pointed out.
Lucas De Marchi
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Revert "Add a new API to edbus to let it create an EDbus session from"
On Tue, Mar 19, 2013 at 12:40 PM, Kai Huuhko wrote: > 19.03.2013 16:01, Lucas De Marchi kirjoitti: >> On Tue, Mar 19, 2013 at 8:55 AM, Kai Huuhko wrote: >>> 19.03.2013 05:48, Lucas De Marchi kirjoitti: >>>> On Mon, Mar 18, 2013 at 5:57 PM, Kai Huuhko wrote: >>>>> Referring to: >>>>> http://git.enlightenment.org/core/efl.git/commit/?id=61ca9d550d705ea21afbe88a0af3e3cba2515314 >>>>> >>>>> Next time do notify us, preferably beforehand. You broke our build with >>>>> this commit. >>>> How the hell I would know *you* were working with it? >>> http://git.enlightenment.org/core/efl.git/commit/?id=61ca9d550d705ea21afbe88a0af3e3cba2515314 >>> "First of all, if it's not tested it shouldn't be committed." >>> >>> This tells me you actually went and read the original commit message: >> yep >> >>> http://git.enlightenment.org/core/efl.git/commit/?id=8ecd30d578ebac46bbdf5f6d5c0b7cad1187f84f >>> "Add a new API to edbus to let it create an EDbus session from an >>> existing DBus connection. This is needed by the python bindings, was >>> done the same way in edbus1, so it should fit here also >>> NOTE: I did not test this yet, and I'm not into the edbus code, so I >>> please who know the code to give a look. thanks >> particularly this part. >> >>> NOTE2: I don't think this need Changelog and stuff as we are probably >>> the only users of this function, let me know if i'm wrong" >>> >>> and most likely saw the code comment: >>> >>>* @note this is a low-level function, it is meant to be used by language >>>* bindings, don't use unless you know what are you doing! >>> >>> So you very well knew it was being used by the python bindings. >> >> yep... so you added a wrong API to edbus that according to your >> comment is not tested yet, but will be used by the python bindings. > Do not avert the matter from the point. I am not. What I did: git remote update git log HEAD..origin/master -- src/lib/edbus And there was a broken commit there. And a message saying it was a NOTE saying it was *not* tested asking for someone to take a look. I did and since it was wrong I reverted it. >> >>>>And since it was >>>> wrong, breaking it was really the best option. It's like a "HEADS UP, >>>> you are doing it wrong". >>> With the aforementioned knowledge the best option would have been >>> notifying us. You can use strong language and bash us over the head with >> the same way you notified about adding the API. > AFAIK we did, see below. >> >>> virtual trout if you like but don't go and pull the rug from under other >>> peoples work when you have other options available. I don't mind if the >>> breakage happens by incident. But if something is clearly mentioned as >>> being used by other EFL projects then you should either fix those other >>> things yourself or notify the people working on them. >> I'll never fix other projects if they introduced a bug in the library >> in order to create a bug in their software. Sorry if this bothers you, >> but I can't babysit all projects in e-svn or wherever they are hosted. >> As one of the authors of edbus I can however fix whatever is there. >> In a sensible workflow you would submit your change in edbus for >> review so you wouldn't actually depend on this API since the >> beginning... you decided to take the shortcut and commit, so I did. > Since I did not personally commit or develop the code in question I > cannot speak authoritatively of the process that was taking place when > this was added, I did however observe the conversation taking place on > IRC where the code was reviewed by one of the ProFUSION/Intel OTC folks. > So, according to my knowledge the code was reviewed and accepted. > > I am speaking here as someone whose software project was broken by your > commit. I am upset about the fact that the problem nor the fact that you > resolved it, in process breaking our stuff, was not communicated to us It was wrong - I asked on IRC if Dave was around - he wasn't. Then I wrote a lengthy commit message explaining WHY it was being reverted. As I said, I consider this the HEADSUP you were asking for. If you don't agree, sorry, but right now this is how the project is being handled. There's no "notification beforehand" - if you were deeply depending on it you can carry this patch with you until you moved to another implementation. What did you w
Re: [E-devel] Revert "Add a new API to edbus to let it create an EDbus session from"
On Tue, Mar 19, 2013 at 8:55 AM, Kai Huuhko wrote: > 19.03.2013 05:48, Lucas De Marchi kirjoitti: >> On Mon, Mar 18, 2013 at 5:57 PM, Kai Huuhko wrote: >>> Referring to: >>> http://git.enlightenment.org/core/efl.git/commit/?id=61ca9d550d705ea21afbe88a0af3e3cba2515314 >>> >>> Next time do notify us, preferably beforehand. You broke our build with >>> this commit. >> How the hell I would know *you* were working with it? > http://git.enlightenment.org/core/efl.git/commit/?id=61ca9d550d705ea21afbe88a0af3e3cba2515314 > "First of all, if it's not tested it shouldn't be committed." > > This tells me you actually went and read the original commit message: yep > > http://git.enlightenment.org/core/efl.git/commit/?id=8ecd30d578ebac46bbdf5f6d5c0b7cad1187f84f > "Add a new API to edbus to let it create an EDbus session from an > existing DBus connection. This is needed by the python bindings, was > done the same way in edbus1, so it should fit here also > NOTE: I did not test this yet, and I'm not into the edbus code, so I > please who know the code to give a look. thanks particularly this part. > NOTE2: I don't think this need Changelog and stuff as we are probably > the only users of this function, let me know if i'm wrong" > > and most likely saw the code comment: > > * @note this is a low-level function, it is meant to be used by language > * bindings, don't use unless you know what are you doing! > > So you very well knew it was being used by the python bindings. yep... so you added a wrong API to edbus that according to your comment is not tested yet, but will be used by the python bindings. > >> And since it was >> wrong, breaking it was really the best option. It's like a "HEADS UP, >> you are doing it wrong". > With the aforementioned knowledge the best option would have been > notifying us. You can use strong language and bash us over the head with the same way you notified about adding the API. > virtual trout if you like but don't go and pull the rug from under other > peoples work when you have other options available. I don't mind if the > breakage happens by incident. But if something is clearly mentioned as > being used by other EFL projects then you should either fix those other > things yourself or notify the people working on them. I'll never fix other projects if they introduced a bug in the library in order to create a bug in their software. Sorry if this bothers you, but I can't babysit all projects in e-svn or wherever they are hosted. As one of the authors of edbus I can however fix whatever is there. In a sensible workflow you would submit your change in edbus for review so you wouldn't actually depend on this API since the beginning... you decided to take the shortcut and commit, so I did. >> >> And as said in the commit message, we should be careful about adding >> APIs like this. > Yes I completely understand and you are right that it was bad, which I > am not arguing against. We were trying to be lazy and replicate e_dbus > (v1) bindings functionality, where the actual heavy lifting is done by > python-dbus. It was working but obviously edbus did not like having > foreign objects and rightfully complained with error messages. > > We'll come up with a better solution and next time we'll ask more people > for review if new C API is to be added. ok Lucas De Marchi -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Revert "Add a new API to edbus to let it create an EDbus session from"
On Mon, Mar 18, 2013 at 5:57 PM, Kai Huuhko wrote: > Referring to: > http://git.enlightenment.org/core/efl.git/commit/?id=61ca9d550d705ea21afbe88a0af3e3cba2515314 > > Next time do notify us, preferably beforehand. You broke our build with > this commit. How the hell I would know *you* were working with it? And since it was wrong, breaking it was really the best option. It's like a "HEADS UP, you are doing it wrong". And as said in the commit message, we should be careful about adding APIs like this. Lucas De Marchi -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: Edbus: Include config.h
On Fri, Mar 8, 2013 at 11:55 AM, Tom Hacohen wrote: > On 08/03/13 14:40, Lucas De Marchi wrote: >> >> On Fri, Mar 8, 2013 at 7:07 AM, Tom Hacohen >> wrote: >>> >>> On 07/03/13 19:03, Lucas De Marchi wrote: >>>> >>>> >>>> On Thu, Mar 7, 2013 at 4:00 PM, Lucas De Marchi >>>> wrote: >>>>> >>>>> >>>>> On Wed, Mar 6, 2013 at 1:57 PM, Tom Hacohen - Enlightenment Git >>>>> wrote: >>>>>> >>>>>> >>>>>> tasn pushed a commit to branch master. >>>>>> >>>>>> commit fd701b710b088b195b624c29b4a4a49ac55415e2 >>>>>> Author: Tom Hacohen >>>>>> Date: Wed Mar 6 16:57:01 2013 + >>>>>> >>>>>> Edbus: Include config.h >>>>>> --- >>>>>>src/lib/edbus/edbus_core.c | 4 >>>>>>1 file changed, 4 insertions(+) >>>>>> >>>>>> diff --git a/src/lib/edbus/edbus_core.c b/src/lib/edbus/edbus_core.c >>>>>> index 6f8daf8..b7a77ea 100644 >>>>>> --- a/src/lib/edbus/edbus_core.c >>>>>> +++ b/src/lib/edbus/edbus_core.c >>>>>> @@ -1,3 +1,7 @@ >>>>>> +#ifdef HAVE_CONFIG_H >>>>>> +# include "config.h" >>>>>> +#endif >>>>>> + >>>>> >>>>> >>>>> >>>>> There's no need for this since it's already included in the build >>>>> system. Either remove from here or from the build system. >>> >>> >>> >>> Hm...? >>> >>>> >>>> oh... you will notice there's no config.h in .c files of edbus, so if >>>> you are removing it from the build system, you'll have to add it to >>>> the other files. >>>> >>>> I'm in favor of just reverting this patch though. What were you trying >>>> to >>>> fix? >>>> >>> >>> You depend on VMAJ in that piece of code. I think it's cleaner to define >>> those kind of things in config.h than in compiler flags defines. This is >>> the >>> first step towards solving it. >> >> >> You got me wrong. config.h is already included - that's what I'm saying. >> > > We already talked about it in PM. > > Summary: > Lucas wants me to use "-include" i.e a not-available-everywhere compiler > flag to make it include config.h. > > I want to include config.h like we do all around the efl. > > Lucas's arguments: > 1. People tend to forget including config.h > 2. It's annoying to include it everywhere. > > My arguments: > 1. If they forget, it won't compile, I don't see the point. It may compile, with different configuration: 1) "#ifndef BLA" / "#ifdef BLA" may enable/disable certain parts of the code since you don't have the definitions of the config.h 2) "#if BLA" only shows a warning... and only if you give the compiler the -Wundef - which we don't (and as you complained about "-include" is non-standard as well) 3) You may have different tweaks to libraries you are including, particularly libc, if you forget to include the config.h. > 2. We include config.h all around the efl. . > 3. What's the difference between this and other commonly used headers, like > evas_common.h in evas? evas_common.h has typedefs, function declarations etc. And I wouldn't call it an example to be followed. > 4. You are hiding code. No, I'm making sure this is included and it's the first thing to be included. > 5. I'm not sure about this one: does autofoo dependency tracking still work > with this? And to make more point even harder, as we already talked you only included the config.h in 1 single .c file. You should include it in every .c. Anyway, I really don't care about what to do as long as we don't be in a mixed state... if you are going to add these lines, please remove the -include from the build system and don't forget to include them in *every .c* Lucas De Marchi -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: Edbus: Include config.h
On Fri, Mar 8, 2013 at 7:07 AM, Tom Hacohen wrote: > On 07/03/13 19:03, Lucas De Marchi wrote: >> >> On Thu, Mar 7, 2013 at 4:00 PM, Lucas De Marchi >> wrote: >>> >>> On Wed, Mar 6, 2013 at 1:57 PM, Tom Hacohen - Enlightenment Git >>> wrote: >>>> >>>> tasn pushed a commit to branch master. >>>> >>>> commit fd701b710b088b195b624c29b4a4a49ac55415e2 >>>> Author: Tom Hacohen >>>> Date: Wed Mar 6 16:57:01 2013 + >>>> >>>> Edbus: Include config.h >>>> --- >>>> src/lib/edbus/edbus_core.c | 4 >>>> 1 file changed, 4 insertions(+) >>>> >>>> diff --git a/src/lib/edbus/edbus_core.c b/src/lib/edbus/edbus_core.c >>>> index 6f8daf8..b7a77ea 100644 >>>> --- a/src/lib/edbus/edbus_core.c >>>> +++ b/src/lib/edbus/edbus_core.c >>>> @@ -1,3 +1,7 @@ >>>> +#ifdef HAVE_CONFIG_H >>>> +# include "config.h" >>>> +#endif >>>> + >>> >>> >>> There's no need for this since it's already included in the build >>> system. Either remove from here or from the build system. > > > Hm...? > >> >> oh... you will notice there's no config.h in .c files of edbus, so if >> you are removing it from the build system, you'll have to add it to >> the other files. >> >> I'm in favor of just reverting this patch though. What were you trying to >> fix? >> > > You depend on VMAJ in that piece of code. I think it's cleaner to define > those kind of things in config.h than in compiler flags defines. This is the > first step towards solving it. You got me wrong. config.h is already included - that's what I'm saying. Lucas De Marchi -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: Edbus: Include config.h
On Thu, Mar 7, 2013 at 4:00 PM, Lucas De Marchi wrote: > On Wed, Mar 6, 2013 at 1:57 PM, Tom Hacohen - Enlightenment Git > wrote: >> tasn pushed a commit to branch master. >> >> commit fd701b710b088b195b624c29b4a4a49ac55415e2 >> Author: Tom Hacohen >> Date: Wed Mar 6 16:57:01 2013 + >> >> Edbus: Include config.h >> --- >> src/lib/edbus/edbus_core.c | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/src/lib/edbus/edbus_core.c b/src/lib/edbus/edbus_core.c >> index 6f8daf8..b7a77ea 100644 >> --- a/src/lib/edbus/edbus_core.c >> +++ b/src/lib/edbus/edbus_core.c >> @@ -1,3 +1,7 @@ >> +#ifdef HAVE_CONFIG_H >> +# include "config.h" >> +#endif >> + > > There's no need for this since it's already included in the build > system. Either remove from here or from the build system. oh... you will notice there's no config.h in .c files of edbus, so if you are removing it from the build system, you'll have to add it to the other files. I'm in favor of just reverting this patch though. What were you trying to fix? Lucas De Marchi -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: Edbus: Include config.h
On Wed, Mar 6, 2013 at 1:57 PM, Tom Hacohen - Enlightenment Git wrote: > tasn pushed a commit to branch master. > > commit fd701b710b088b195b624c29b4a4a49ac55415e2 > Author: Tom Hacohen > Date: Wed Mar 6 16:57:01 2013 + > > Edbus: Include config.h > --- > src/lib/edbus/edbus_core.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/src/lib/edbus/edbus_core.c b/src/lib/edbus/edbus_core.c > index 6f8daf8..b7a77ea 100644 > --- a/src/lib/edbus/edbus_core.c > +++ b/src/lib/edbus/edbus_core.c > @@ -1,3 +1,7 @@ > +#ifdef HAVE_CONFIG_H > +# include "config.h" > +#endif > + There's no need for this since it's already included in the build system. Either remove from here or from the build system. Lucas De Marchi -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/elementary] master 02/02: Merge branch 'master' of ssh://git.enlightenment.org/core/elementary
On Wed, Feb 27, 2013 at 11:44 AM, Tom Hacohen wrote: > On 27/02/13 14:38, Rafael Antognolli wrote: >> What about requiring push -f? > > Do you know how to do that? I'd love having that. If git >= 1.6 is running on the server, all you need to do is set the configuration: receive.denyNonFastForwards Otherwise you need an update/pre-receive hook checking if "git rev-list $newrev..$oldrev" is empty in order to accept the push. Lucas De Marchi -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Build issue
On Sat, Feb 16, 2013 at 11:33 AM, Cedric BAIL wrote: > Hello, > > Our current build system is currently in a bad state and there was no > improvements in the past week. So here is I think a TODO that everyone > will agree with. > > - siginfo is not a portable API. There was a test and proper #if in > 1.7, we should bring them back. it's better if you share what's your problem - that's in what architecture? in 884c31df411755d4ee86683f184b7bf3b0ce2ec0 you basically reverted the commit removing these checks without providing much info on what exactly is the issue. What we had before was basically papering over the issue. Now we are doing it again. Lucas De Marchi > - libmount is not recent enough for eeze 1.8 on debian. There was > working code in 1.7, we should bring it back. > - binary executed inside the build tree don't use the just build > library, but the system one. > - the profile (UI, server) are not there yet and should be added as > latest discussion did reach consensus on that topic. > > I may have forgotten some issue here, so kindly remind them here. At > least for the four top one, they will be blocker for the 1.8 release > and need to be solved. I may go and fix the one I can when I have > time, but any help will be appreciated. > > Have fun, > -- > Cedric BAIL > > -- > The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, > is your hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials, tech docs, > whitepapers, evaluation guides, and opinion stories. Check out the most > recent posts - join the conversation now. http://goparallel.sourceforge.net/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Build issue
On Feb 16, 2013 6:12 PM, "Davide Andreoli" wrote: > > 2013/2/16 David Seikel > > > On Sat, 16 Feb 2013 17:31:07 +0100 Davide Andreoli > > wrote: > > > > > 2013/2/16 Leandro Dorileo > > > > > > > Hi! > > > > > > > > On Sat, Feb 16, 2013 at 03:58:47PM +0100, Davide Andreoli wrote: > > > > > 2013/2/16 Cedric BAIL > > > > > > > > > > > Hello, > > > > > > > > > > > > Our current build system is currently in a bad state and there > > > > > > was no improvements in the past week. So here is I think a TODO > > > > > > that everyone will agree with. > > > > > > > > > > > > - siginfo is not a portable API. There was a test and proper > > > > > > #if in 1.7, we should bring them back. > > > > > > - libmount is not recent enough for eeze 1.8 on debian. There > > > > > > was working code in 1.7, we should bring it back. > > > > > > - binary executed inside the build tree don't use the just build > > > > > > library, but the system one. > > > > > > - the profile (UI, server) are not there yet and should be > > > > > > added as latest discussion did reach consensus on that topic. > > > > > > > > > > > > I may have forgotten some issue here, so kindly remind them > > > > > > here. At least for the four top one, they will be blocker for > > > > > > the 1.8 release and need to be solved. I may go and fix the one > > > > > > I can when I have time, but any help will be appreciated. > > > > > > > > > > > > > > > > I suggest also to disable physics by default, as libbulett 2.8 is > > > > > only is super recent distro. > > > > > > > > > > > > > I still can't see a use case where ./autogen.sh --disable-physics > > > > wont work. > > > > > > > > > > It works, indeed. But is annoing, why not just disable physics if > > > bullet is not found? > > > There's no usage of ephysics, thus it seems to me better to leave out > > > > E17 has a standard physics module, also there's efbb, plus I'm using it > > my 3D experiment. That's three I found without even trying. B-) > > > > The physics module was totally buggy when I tried it (confirmed by the > author in chat), your window just move randomly on the screen. > I don't know why is in as an 'official' module, it is something that should > stay out for the final user. > > The fact that you are using it in your experiment surly is not a good reason > to make it mandatory for everyone :P s/mandatory/default/ We are not forcing anyone to use it. Lucas De Marchi > > And yes, efbb is the only good user of it. but still not a good reason to > make it mandatory IMO. > > > > > Normally I would agree with you about disabling it if bullet is not > > found, but Leandro has a valid point. I'd want more distros to have an > > EFL compatible bullet to. > > > > -- > > A big old stinking pile of genius that no one wants > > coz there are too many silver coated monkeys in the world. > > > > > > -- > > The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, > > is your hub for all things parallel software development, from weekly > > thought > > leadership blogs to news, videos, case studies, tutorials, tech docs, > > whitepapers, evaluation guides, and opinion stories. Check out the most > > recent posts - join the conversation now. > > http://goparallel.sourceforge.net/ > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, > is your hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials, tech docs, > whitepapers, evaluation guides, and opinion stories. Check out the most > recent posts - join the conversation now. http://goparallel.sourceforge.net/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] SVN->Git Migration (was: (no subject))
On Fri, Feb 15, 2013 at 11:56 AM, Rafael Antognolli wrote: > Hi David, > > On Thu, Feb 14, 2013 at 9:12 AM, David Seikel wrote: >> On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly >> wrote: >> >>> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann >>> wrote: >>> > On 13/02/13 00:36, Bruno Dilly wrote: >>> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann >>> >> wrote: >>> >>> >>> >>> Topic branches: >>> >>> * In each repository every developer with commit access will be >>> >>> able to push/update branches in their own namespace >>> >>> (devs//*). These branches will allow non-fastforward >>> >>> updates and no one should expect these to be stable. >>> >>> * This is a testing ground for developers where new features can >>> >>> be developed, debugged and shared with fellow developers. Ideally >>> >>> any new feature would live in its own branch until it matures and >>> >>> is merged into master. >>> >> >>> >> Hey Daniel, >>> >> >>> >> It's a nice proposal, but what about master branch permissions ? >>> >> Every developer would be allowed to push stuff on there (with a >>> >> flow similar to svn) ? Or we'll try to establish some kind of >>> >> policy about it (maintainers, review, etc) ? >>> > >>> > As others have already pointed out there seems to be consensus that >>> > we don't have enough manpower to work with an integrator workflow >>> > (whether or not that's true I don't know). >>> >>> ok, I got it. >>> >>> > >>> > What I want to achieve with the topic branches is that whoever >>> > wants to can maintain an integrator-like workflow. You develop your >>> > feature in a topic branch, then post a request for review/review >>> > and test yourself and if everything looks good you can merge into >>> > master. >>> > >>> > Speaking of merging...is there any preference on merge vs. rebase? >>> > >>> > Lots of small merges can really pollute your history and I don't >>> > really like them. For larger topic branches I think merging makes >>> > sense. >>> >>> I agree with Tom here. >>> I'm always trying to keep a linear history, focusing on rebases >>> instead of merges. >>> We've used this approach on Profusion projects for years and it worked >>> fine so far. >>> >>> Maybe it will give you a little bit more work, you'll have to fix >>> conflicts in the commits it happens instead of only once in a final >>> merge commit, but it will be nicer to review or look >>> for issues later, imo. >>> >>> Using the merge approach, in a project with so many commiters could >>> lead us to a very confuse history. >> >> If the history is confused, then that's what it should show. I really >> don't like the idea of rewriting history just to make it easier for >> some people. Sometimes you just need to track down what actually >> happened, not the convenient lie we tell ourselves is what happened. > > I don't think those that a rebased branch history is a lie. Each > commit will still have the original commit date (if the author did not > change it). You can use that to know when the feature started to be > developed. > > > OK, you lose a way to track the parent commit for that feature branch, > but on the other hand you earn something important here: the knowledge > that the commits from that feature branch will apply correctly on top > of the current state of the tree, without a magic merge commit fixing > stuff later since some things on the tree are not exactly as they seem > to be in the diff from this commit. The changes that appear in the > diff from a given commit are exactly what that commit is doing. > > I know that this is not a poll, but I particularly prefer rebased > branches/commits too. me too. Merges only make sense when there are maintainers of particular pieces of the repository. The best example of this is the Linux Kernel. You merge what the submaintainers send to you. They can't rebase on top of you because otherwise they would break the history for whoever is basing their development on their tree. On the other side, take projects like BlueZ, ConnMan, WebKit. There aren't merges... and there's no lie as you are implying. People are used to rebase before sending the features they developed. Also we don't need to be black or white here. Sometimes it's easier to use merges and still don't pollute the repository. I myself sometimes use merges in the projects I maintain, though most of the times rebases are better. Lucas De Marchi -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] SVN->Git Migration (was: (no subject))
On Thu, Feb 14, 2013 at 9:12 AM, David Seikel wrote: > On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly > wrote: > >> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann >> wrote: >> > On 13/02/13 00:36, Bruno Dilly wrote: >> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann >> >> wrote: >> >>> >> >>> Topic branches: >> >>> * In each repository every developer with commit access will be >> >>> able to push/update branches in their own namespace >> >>> (devs//*). These branches will allow non-fastforward >> >>> updates and no one should expect these to be stable. >> >>> * This is a testing ground for developers where new features can >> >>> be developed, debugged and shared with fellow developers. Ideally >> >>> any new feature would live in its own branch until it matures and >> >>> is merged into master. >> >> >> >> Hey Daniel, >> >> >> >> It's a nice proposal, but what about master branch permissions ? >> >> Every developer would be allowed to push stuff on there (with a >> >> flow similar to svn) ? Or we'll try to establish some kind of >> >> policy about it (maintainers, review, etc) ? >> > >> > As others have already pointed out there seems to be consensus that >> > we don't have enough manpower to work with an integrator workflow >> > (whether or not that's true I don't know). >> >> ok, I got it. >> >> > >> > What I want to achieve with the topic branches is that whoever >> > wants to can maintain an integrator-like workflow. You develop your >> > feature in a topic branch, then post a request for review/review >> > and test yourself and if everything looks good you can merge into >> > master. >> > >> > Speaking of merging...is there any preference on merge vs. rebase? >> > >> > Lots of small merges can really pollute your history and I don't >> > really like them. For larger topic branches I think merging makes >> > sense. >> >> I agree with Tom here. >> I'm always trying to keep a linear history, focusing on rebases >> instead of merges. >> We've used this approach on Profusion projects for years and it worked >> fine so far. >> >> Maybe it will give you a little bit more work, you'll have to fix >> conflicts in the commits it happens instead of only once in a final >> merge commit, but it will be nicer to review or look >> for issues later, imo. >> >> Using the merge approach, in a project with so many commiters could >> lead us to a very confuse history. > > If the history is confused, then that's what it should show. I really > don't like the idea of rewriting history just to make it easier for ahn?? nobody is talking about rewriting the history of the public repository > some people. Sometimes you just need to track down what actually > happened, not the convenient lie we tell ourselves is what happened. > > Those who don't know history are destined to repeat it. B-) /me confused and so seems you are. Lucas De Marchi -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git repository layout - RFC
On Jan 30, 2013 7:33 AM, "Tom Hacohen" wrote: > > On 30/01/13 01:00, Lucas De Marchi wrote: >> >> On Tue, Jan 29, 2013 at 7:33 PM, Tom Hacohen wrote: >>> >>> Well, we aren't doing the switch yet. Probably early next week. But we are >>> prepping the git repos now (it takes time, a few days of actually >>> *running*). >> >> >> >> sigh... days? Are you running this remotely or on the same machine svn is in? >> >> Another thing to consider to fixup the authors is actually running >> git-filter-branch after the repo is converted. It should be much >> shorter than "days". > > > git-filter-branch can be fast or slow, depending on what you do. We are working with a fast machine, doing everything on ram, and still it takes time. I exaggerated with the "days", it's actually only 2 days. > We have to do a couple of things: Fix the authors, change the commit message (change the git-svn line), go through all the commits in the repo finding historic locations of repos and fixing up history to work nicely. It's computing time. It's not our fault. We were also surprised by the time it takes. > Seriously, try this on your own and you'll see. Ok. 2 days... I was impressed by your "days" imagining 4 or 5 ;-) > > >> >> I'd also like to ask to convert the commits coming from svn-git-am.py >> script so the author in "Patch-by:" in the commit message turns into a >> real author in the new repository. I tried to check this looking at >> edbus dir (since I proxied lots of patches there), but most of it had >> barbieri as the author since he moved the repo -- I think this problem >> has already been discussed and solved. >> > > We'll take a look at solving that. Very annoying that you guys did it like that, but OK. :) svn doesn't differentiate author and comitter. So I'd blame svn rather than us. > > As for barbieri getting credit for moving the repo - while he does deserve some credit, we'll fix it to handle things correctly. > > -- > Tom. Lucas De Marchi -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Git repository layout - RFC
On Tue, Jan 29, 2013 at 7:33 PM, Tom Hacohen wrote: > Well, we aren't doing the switch yet. Probably early next week. But we are > prepping the git repos now (it takes time, a few days of actually > *running*). sigh... days? Are you running this remotely or on the same machine svn is in? Another thing to consider to fixup the authors is actually running git-filter-branch after the repo is converted. It should be much shorter than "days". I'd also like to ask to convert the commits coming from svn-git-am.py script so the author in "Patch-by:" in the commit message turns into a real author in the new repository. I tried to check this looking at edbus dir (since I proxied lots of patches there), but most of it had barbieri as the author since he moved the repo -- I think this problem has already been discussed and solved. regards, Lucas De Marchi -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster IN trunk/efl: m4 src
On Jan 25, 2013 1:40 PM, "Gustavo Sverzut Barbieri" wrote: > > On Thu, Jan 24, 2013 at 1:10 AM, Carsten Haitzler wrote: > > On Wed, 23 Jan 2013 22:20:56 -0200 Gustavo Sverzut Barbieri > > said: > > > >> Hi all, > >> > >> Today I did investigate this issue and the reason is that Debian (and > >> thus Ubuntu) apply a patch called link_all_deplibs.patch that will > >> forcefuly disable emitting the .la dependencies (at leas on linux). > >> They also apply another one to have binaries to never use .la > >> dependencies. This patch exposes bugs with libraries that are missing > >> in LIBADD and LDADD of automake. > >> > >> this patch is to ltmain.sh and libtool.m4, but even if I copy their > >> files to Fedora/Arch it's not behaving the same. I'm still > >> investigating how to force the same behavior everywhere, so we can > >> have it more consistent. > >> > >> As for Ubuntu/Debian patch correctness: although in theory their patch > >> is valid, it is useless if you use -Wl,--as-neeeded and just makes us > >> do more work. They carry this patch for some years and libtool > >> upstream vetoed the inclusion of it (not sure why). > > > > well i can see why deb/ubuntu do it.. they are being anal... but reality deb > > +ubunut+mint+whoever bases from deb carries this "anal" patch and this is > > probably like 60% of the linux installs out there. :( so it's a reality we have > > to live with... even our friends at bodhi will have to deal with it too. > > > > unless we just give up on supporting linux in general and "make our own > > distro"... :) > > > >> Talking to one friend that used to maintain autotools he mentioned > >> that even in development (svn) we should not call autoreconf or > >> autogen.sh. He mentions that the proper usage is to have a single > >> point to place all files in m4/ (svn) and generate configure. I find > >> this quite disgusting, but would solve our problem as well. > > > > wait.. put ALL the .m4 files that come FROM autoconf/libtool/automake etc. > > inside out m4/ dir - ie copy them in? duplicate them? > > as ugly and painful as it sounds: yes. We'd ship everything, people > just run ./configure. Ugly I know, I said :-) Nooo Lucas De Marchi -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/efl: . m4
On Wed, Jan 16, 2013 at 3:24 PM, Enlightenment SVN wrote: > Log: > simplify efl version and initialization in a macro, fixes libtool > version-info. > > Introduces EFL_VERSION() to make it simpler to define our version. The > last parameter is the release status, defaults to 'dev' for > development purposes and may be set to something else to be a > snapshot. It non-empty will be given to libtool's -release. > > As EFL_VERSION() must be done *before* AC_INIT(), we need to create > another macro to do the AC_SUBST() and AC_DEFINE(). This is > EFL_INIT. And no, we can't just call AC_INIT() from inside EFL_INIT(). > > Last but not least, we had a problem with our libtool version-info. It > was being calculated as MAJOR + MINOR, right now 1 + 7 = 8. But as > soon as we get to MAJOR=2 and MINOR=0, we get into problems. This was > fixed by rewriting as (MAJOR * 100 + MINOR), but this is still > problematic. > > According to libtool's manual (info libtool), we shouldn't bind the > version-info with package info, instead doing the 'release' > field. Pretty likely we'll do worse than expected by distros and > binary packages in future :-/ yep. But I'd rather make patches to all stable versions so we have the correct numbers. This is a bug and the sooner we fix it the better. Lucas De Marchi -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Building EFL on Ubuntu 11.04
On Wed, Jan 16, 2013 at 9:56 AM, Carsten Haitzler wrote: > On Wed, 16 Jan 2013 09:51:33 -0200 Gustavo Sverzut Barbieri > said: > >> On Wednesday, January 16, 2013, David Seikel wrote: >> >> > On Wed, 16 Jan 2013 12:54:19 +0200 "Alex-P. Natsios" >> > > wrote: >> > >> > > stupid suggestions but can certainly happen if you forget to check >> > > them :) >> > > >> > > 1) what autofoo versions does Ubuntu 11.04 have? maybe its too old? >> > > 2) same goes for their GCC version >> > >> > I was gonna rant and rave about not being too old, but then checked and >> > Ubuntu 11.04 HAS reached EOL (End Of Life) in October. So yes, good >> > idea to upgrade Ubuntu in this case. >> > >> > >> > Now, had it been Ubuntu 10.04, that's a whole other story, it's not >> > past it's EOL yet, so versions of autofoo and gcc on it are by >> > definition, not too old. Coz the definition of "too old" should NOT >> > include popular distros that are still supported by their makers. >> > >> >> >> Ahahah. That means nothing, really. Who committed to LTS of that version is >> Canonical/Ubuntu, not Enlightenment. Imagine a scenario where some crazy >> dude says he has a distribution with 20 year support, we'll try to match?! > > you know how i love to disagree with you... but you are absolutely right. *WE* > didn't commit to support of 10.04 or 11.04 of ubuntu. canonical did. we are > free to raise out requirements as we see fit. we did not commit to keeping > them > static. > > i DO suggest that we keep in mind though that we will have people on older > systems and by ensuring we don't build/run on them we basically lose users. :) WTF is happening to the world? I, Gustavo and Raster agree on something Lucas De Marchi -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
