Re: [E-devel] E SVN: mike_m IN trunk/efl/src/bin: edbus edje
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? thanks, Mike -- 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/enlightenment] master 01/01: dear Mike,
Dear Cedric,
Well said.
Silencing warnings just for silencing is not good. We use them to spot
bugs, that's why we like them so much. Silencing useful warnings is
counter-productive.
--
Tom.
On 21/03/13 01:12, Cedric BAIL - Enlightenment Git wrote:
cedric pushed a commit to branch master.
commit 07b5d9fe6ca5137e0a4c837d0fab5839a0ba50ee
Author: Cedric BAIL cedric.b...@samsung.com
Date: Thu Mar 21 10:04:32 2013 +0900
dear Mike,
If you just want to silence your warning remove all -W from your CFLAGS
and
take your revenge back to your compiler. Introducing bugs to just silent
warning
is not gona help any one.
The borker,
Cedric
---
src/bin/e_sys_l2ping.c | 3 ++-
src/bin/e_sys_main.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/bin/e_sys_l2ping.c b/src/bin/e_sys_l2ping.c
index faab77e..236364d 100644
--- a/src/bin/e_sys_l2ping.c
+++ b/src/bin/e_sys_l2ping.c
@@ -10,7 +10,7 @@
#endif
double
-e_sys_l2ping(const char *bluetooth_mac EINA_UNUSED)
+e_sys_l2ping(const char *bluetooth_mac)
{
#ifdef HAVE_BLUETOOTH
char send_buf[L2CAP_CMD_HDR_SIZE + 1];
@@ -95,6 +95,7 @@ e_sys_l2ping(const char *bluetooth_mac EINA_UNUSED)
return ecore_time_get() - start;
#else
+ (void) bluetooth_mac;
fprintf(stderr, e_sys_l2ping nop\n);
return -1;
#endif
diff --git a/src/bin/e_sys_main.c b/src/bin/e_sys_main.c
index 70f836c..b48f1c0 100644
--- a/src/bin/e_sys_main.c
+++ b/src/bin/e_sys_main.c
@@ -188,7 +188,7 @@ main(int argc,
latency = e_sys_l2ping(output);
eina_convert_dtoa(latency, tmp);
- fprintf(stdout, %s\n, tmp);
+ fputs(tmp, stdout);
return (latency 0) ? 1 : 0;
}
--
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/enlightenment] master 01/01: dear Mike,
On 03/21/2013 09:25 PM, Tom Hacohen wrote: Silencing warnings just for silencing is not good. We use them to spot bugs, that's why we like them so much. Silencing useful warnings is counter-productive. Usually a developer, upon checking out a code base and building it on their system and observing a nice warning free compile will have a sense of confidence in a project. Usually a developer, on making a modification to their code, checks for warnings and makes sure none have been introduced before pushing their code. There are some people who wish to compile their code with every frickin warning in the world turned on, then proceed to ignore said warnings, and commit code with warnings to their revision control systems. That gcc somehow changed which warnings it emits in a newer version changes none of the above. Enjoy your warnings. Mike -- 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/enlightenment] master 01/01: dear Mike,
On 21/03/13 11:00, Mike McCormack wrote: On 03/21/2013 09:25 PM, Tom Hacohen wrote: Silencing warnings just for silencing is not good. We use them to spot bugs, that's why we like them so much. Silencing useful warnings is counter-productive. Usually a developer, upon checking out a code base and building it on their system and observing a nice warning free compile will have a sense of confidence in a project. Usually a developer, on making a modification to their code, checks for warnings and makes sure none have been introduced before pushing their code. There are some people who wish to compile their code with every frickin warning in the world turned on, then proceed to ignore said warnings, and commit code with warnings to their revision control systems. Mike, You are forgetting the most typical case in efl land developers who do not even Compile their code before commit ;) (Sorry, just had to chime in with that ;) Please, ignore that I was even here) dh That gcc somehow changed which warnings it emits in a newer version changes none of the above. Enjoy your warnings. Mike -- 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/enlightenment] master 01/01: dear Mike,
On 21/03/13 11:00, Mike McCormack wrote: On 03/21/2013 09:25 PM, Tom Hacohen wrote: Silencing warnings just for silencing is not good. We use them to spot bugs, that's why we like them so much. Silencing useful warnings is counter-productive. Usually a developer, upon checking out a code base and building it on their system and observing a nice warning free compile will have a sense of confidence in a project. Yes. And we don't want to break that trust by creating false confidence just by silencing the warnings, even ones that my point to bugs. Usually a developer, on making a modification to their code, checks for warnings and makes sure none have been introduced before pushing their code. Yes, that's cedric's fault, no doubt, but still, just blindly silencing these warnings will not help cedric fix the broken code. There are some people who wish to compile their code with every frickin warning in the world turned on, then proceed to ignore said warnings, and commit code with warnings to their revision control systems. I didn't quite get what you are talking about here. That gcc somehow changed which warnings it emits in a newer version changes none of the above. Enjoy your warnings. Dude, you know me, you know I'm pro-fixing warnings. However, shushing important warnings that point out bugs just to silence the build is not a good thing... I think you subconsciously linked this thread with the one you had with demarchi. We are talking about completely different things. Cedric just pointed out, and I agreed, that people shouldn't just shush important warnings just for the sake of it. They should either fix them, or make whoever introduced them fix them. That's it. -- Tom. -- 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/enlightenment] master 01/01: dear Mike,
On Thu, Mar 21, 2013 at 11:10 AM, Tom Hacohen tom.haco...@samsung.comwrote: On 21/03/13 11:00, Mike McCormack wrote: On 03/21/2013 09:25 PM, Tom Hacohen wrote: Silencing warnings just for silencing is not good. We use them to spot bugs, that's why we like them so much. Silencing useful warnings is counter-productive. Usually a developer, upon checking out a code base and building it on their system and observing a nice warning free compile will have a sense of confidence in a project. Yes. And we don't want to break that trust by creating false confidence just by silencing the warnings, even ones that my point to bugs. Usually a developer, on making a modification to their code, checks for warnings and makes sure none have been introduced before pushing their code. Yes, that's cedric's fault, no doubt, but still, just blindly silencing these warnings will not help cedric fix the broken code. There are some people who wish to compile their code with every frickin warning in the world turned on, then proceed to ignore said warnings, and commit code with warnings to their revision control systems. I didn't quite get what you are talking about here. That gcc somehow changed which warnings it emits in a newer version changes none of the above. Enjoy your warnings. Dude, you know me, you know I'm pro-fixing warnings. However, shushing important warnings that point out bugs just to silence the build is not a good thing... I think you subconsciously linked this thread with the one you had with demarchi. We are talking about completely different things. Cedric just pointed out, and I agreed, that people shouldn't just shush important warnings just for the sake of it. They should either fix them, or make whoever introduced them fix them. That's it. -- Tom. pretty sure neither of the cases were blindly silencing warnings. one of the changes made was to use the correct free function, preventing a magic failure and a leak. another was to add a format string and prevent undefined behavior with fprintf; the only issue here was that I added a trailing newline. since we're exaggerating here, I guess I had better delete my commit access since the newline broke build, prevented E from starting, and caused an orphanage to catch fire somewhere in Africa. starting a troll war on the mailing list without knowing what you're fighting about is not a productive use of anyone's time. -- 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/enlightenment] master 01/01: dear Mike,
On 21/03/13 11:22, Michael Blumenkrantz wrote: On Thu, Mar 21, 2013 at 11:10 AM, Tom Hacohen tom.haco...@samsung.comwrote: On 21/03/13 11:00, Mike McCormack wrote: On 03/21/2013 09:25 PM, Tom Hacohen wrote: Silencing warnings just for silencing is not good. We use them to spot bugs, that's why we like them so much. Silencing useful warnings is counter-productive. Usually a developer, upon checking out a code base and building it on their system and observing a nice warning free compile will have a sense of confidence in a project. Yes. And we don't want to break that trust by creating false confidence just by silencing the warnings, even ones that my point to bugs. Usually a developer, on making a modification to their code, checks for warnings and makes sure none have been introduced before pushing their code. Yes, that's cedric's fault, no doubt, but still, just blindly silencing these warnings will not help cedric fix the broken code. There are some people who wish to compile their code with every frickin warning in the world turned on, then proceed to ignore said warnings, and commit code with warnings to their revision control systems. I didn't quite get what you are talking about here. That gcc somehow changed which warnings it emits in a newer version changes none of the above. Enjoy your warnings. Dude, you know me, you know I'm pro-fixing warnings. However, shushing important warnings that point out bugs just to silence the build is not a good thing... I think you subconsciously linked this thread with the one you had with demarchi. We are talking about completely different things. Cedric just pointed out, and I agreed, that people shouldn't just shush important warnings just for the sake of it. They should either fix them, or make whoever introduced them fix them. That's it. -- Tom. pretty sure neither of the cases were blindly silencing warnings. one of the changes made was to use the correct free function, preventing a magic failure and a leak. another was to add a format string and prevent undefined behavior with fprintf; the only issue here was that I added a trailing newline. since we're exaggerating here, I guess I had better delete my commit access since the newline broke build, prevented E from starting, and caused an orphanage to catch fire somewhere in Africa. starting a troll war on the mailing list without knowing what you're fighting about is not a productive use of anyone's time. Huh? I didn't comment on your code. Heck, I didn't even look at the diff. I just agreed with what cedric has said, which is a common offence around here. -- Tom. -- 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/enlightenment] master 01/01: dear Mike,
On 21/03/13 11:22, Michael Blumenkrantz wrote: pretty sure neither of the cases were blindly silencing warnings. one of the changes made was to use the correct free function, preventing a magic failure and a leak. another was to add a format string and prevent undefined behavior with fprintf; the only issue here was that I added a trailing newline. since we're exaggerating here, I guess I had better delete my commit access Just so we're all on the same page here... I think the actual issue in your commit was marking a parameter as unused which in the #ifdef HAVE_BLUETOOTH case was actually used: -e_sys_l2ping(const char *bluetooth_mac) +e_sys_l2ping(const char *bluetooth_mac EINA_UNUSED) I do believe this is a valid complaint. Regards, Daniel -- 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/enlightenment] master 01/01: dear Mike,
On Thu, 21 Mar 2013 11:37:53 + Tom Hacohen tom.haco...@samsung.com wrote: On 21/03/13 11:22, Michael Blumenkrantz wrote: On Thu, Mar 21, 2013 at 11:10 AM, Tom Hacohen tom.haco...@samsung.comwrote: On 21/03/13 11:00, Mike McCormack wrote: On 03/21/2013 09:25 PM, Tom Hacohen wrote: Silencing warnings just for silencing is not good. We use them to spot bugs, that's why we like them so much. Silencing useful warnings is counter-productive. Usually a developer, upon checking out a code base and building it on their system and observing a nice warning free compile will have a sense of confidence in a project. Yes. And we don't want to break that trust by creating false confidence just by silencing the warnings, even ones that my point to bugs. Usually a developer, on making a modification to their code, checks for warnings and makes sure none have been introduced before pushing their code. Yes, that's cedric's fault, no doubt, but still, just blindly silencing these warnings will not help cedric fix the broken code. There are some people who wish to compile their code with every frickin warning in the world turned on, then proceed to ignore said warnings, and commit code with warnings to their revision control systems. I didn't quite get what you are talking about here. That gcc somehow changed which warnings it emits in a newer version changes none of the above. Enjoy your warnings. Dude, you know me, you know I'm pro-fixing warnings. However, shushing important warnings that point out bugs just to silence the build is not a good thing... I think you subconsciously linked this thread with the one you had with demarchi. We are talking about completely different things. Cedric just pointed out, and I agreed, that people shouldn't just shush important warnings just for the sake of it. They should either fix them, or make whoever introduced them fix them. That's it. -- Tom. pretty sure neither of the cases were blindly silencing warnings. one of the changes made was to use the correct free function, preventing a magic failure and a leak. another was to add a format string and prevent undefined behavior with fprintf; the only issue here was that I added a trailing newline. since we're exaggerating here, I guess I had better delete my commit access since the newline broke build, prevented E from starting, and caused an orphanage to catch fire somewhere in Africa. starting a troll war on the mailing list without knowing what you're fighting about is not a productive use of anyone's time. Huh? I didn't comment on your code. Heck, I didn't even look at the diff. I just agreed with what cedric has said, which is a common offence around here. Agreeing with Cedric is an offence? I'll have to be careful with that one, sometimes he makes sense. B-) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- 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/enlightenment] master 01/01: dear Mike,
On 21/03/13 12:05, David Seikel wrote: On Thu, 21 Mar 2013 11:37:53 + Tom Hacohen tom.haco...@samsung.com wrote: On 21/03/13 11:22, Michael Blumenkrantz wrote: On Thu, Mar 21, 2013 at 11:10 AM, Tom Hacohen tom.haco...@samsung.comwrote: On 21/03/13 11:00, Mike McCormack wrote: On 03/21/2013 09:25 PM, Tom Hacohen wrote: Silencing warnings just for silencing is not good. We use them to spot bugs, that's why we like them so much. Silencing useful warnings is counter-productive. Usually a developer, upon checking out a code base and building it on their system and observing a nice warning free compile will have a sense of confidence in a project. Yes. And we don't want to break that trust by creating false confidence just by silencing the warnings, even ones that my point to bugs. Usually a developer, on making a modification to their code, checks for warnings and makes sure none have been introduced before pushing their code. Yes, that's cedric's fault, no doubt, but still, just blindly silencing these warnings will not help cedric fix the broken code. There are some people who wish to compile their code with every frickin warning in the world turned on, then proceed to ignore said warnings, and commit code with warnings to their revision control systems. I didn't quite get what you are talking about here. That gcc somehow changed which warnings it emits in a newer version changes none of the above. Enjoy your warnings. Dude, you know me, you know I'm pro-fixing warnings. However, shushing important warnings that point out bugs just to silence the build is not a good thing... I think you subconsciously linked this thread with the one you had with demarchi. We are talking about completely different things. Cedric just pointed out, and I agreed, that people shouldn't just shush important warnings just for the sake of it. They should either fix them, or make whoever introduced them fix them. That's it. -- Tom. pretty sure neither of the cases were blindly silencing warnings. one of the changes made was to use the correct free function, preventing a magic failure and a leak. another was to add a format string and prevent undefined behavior with fprintf; the only issue here was that I added a trailing newline. since we're exaggerating here, I guess I had better delete my commit access since the newline broke build, prevented E from starting, and caused an orphanage to catch fire somewhere in Africa. starting a troll war on the mailing list without knowing what you're fighting about is not a productive use of anyone's time. Huh? I didn't comment on your code. Heck, I didn't even look at the diff. I just agreed with what cedric has said, which is a common offence around here. Agreeing with Cedric is an offence? I'll have to be careful with that one, sometimes he makes sense. B-) Didn't you get the memo? :) P.s, I meant: I just agreed with what cedric has said, he pointed out a common offence. -- 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/enlightenment] master 01/01: dear Mike,
On 03/21/13 11:07, Christopher Michael wrote: On 21/03/13 11:00, Mike McCormack wrote: On 03/21/2013 09:25 PM, Tom Hacohen wrote: Silencing warnings just for silencing is not good. We use them to spot bugs, that's why we like them so much. Silencing useful warnings is counter-productive. Usually a developer, upon checking out a code base and building it on their system and observing a nice warning free compile will have a sense of confidence in a project. Usually a developer, on making a modification to their code, checks for warnings and makes sure none have been introduced before pushing their code. There are some people who wish to compile their code with every frickin warning in the world turned on, then proceed to ignore said warnings, and commit code with warnings to their revision control systems. Mike, You are forgetting the most typical case in efl land developers who do not even Compile their code before commit ;) (Sorry, just had to chime in with that ;) Please, ignore that I was even here) http://edevel.tumblr.com/post/45908546732 -- Jérôme Pinot http://ngc891.blogdns.net/ signature.asc Description: Digital signature -- 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] GSoC 2013
On Tue, Mar 19, 2013 at 2:14 AM, Cedric BAIL cedric.b...@free.fr wrote: On Tue, Mar 19, 2013 at 1:15 PM, ravenlock ravenl...@ravenlock.us wrote: On 3/10/13 4:43 AM, Daniel Juyung Seo wrote: Hello all, GSoC submission will start in 8 days and will be finished in 19 days. https://www.google.com/calendar/render?eid=cHVmaXBodWhnMWIzc2h0OWNndnRlYjkzOGsgZ3N1bW1lcm9mY29kZUBtctz=America/Los_Angelessf=trueoutput=xml https://www.google.com/calendar/render?eid=b2w4bDFsaWNwN2p2ZjNydnViMHRpZTA4ZnMgZ3N1bW1lcm9mY29kZUBtctz=America/Los_Angelespli=1sf=trueoutput=xml Is there any volunteer that can lead EFL/E GSoC project? While it may all start with someone to lead. It requires a bit more than just that. There must be a pair of admins (primary and backup). There must be a willing and able pool of mentors (in duplicate as well, primary and backup). Those mentors must be willing and capable of mentoring the pool of ideas which should be reasonably applicable to the project (aka Enlightenment). This pool of ideas historically is a tad elusive and difficult to agree upon (the value and applicability of individual ideas). Why do I mention the above? Well, finding someone to admin is likely the easy part. Rounding up enough devs and enough quality ideas, such that E appears committed, determined to be involved, and relevant to today's *nix world is the trick. So, while admin'ing is a lot of work, and frankly time consuming and tough in hard times (though I consider it a very worthwhile endeavor) one might argue admins are a dime a dozen. An admin without mentors is of little value. I would ask... By show of hands... are there volunteers to mentor? And do you have ideas in hand? I have as many ideas as there is second in a year... Sifting through this thread I see: Daniel Juyung Seo Tom Hacohen Cedric BAIL David Seikel Are you all still willing and able? Are there others in the wings? Yes, I am. Just as I said on IRC, you can count me in on this too. -- 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 -- Rafael Antognolli http://antognolli.org/ -- 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] GSoC 2013
On 19/03/13 04:15, ravenlock wrote: On 3/10/13 4:43 AM, Daniel Juyung Seo wrote: Hello all, GSoC submission will start in 8 days and will be finished in 19 days. https://www.google.com/calendar/render?eid=cHVmaXBodWhnMWIzc2h0OWNndnRlYjkzOGsgZ3N1bW1lcm9mY29kZUBtctz=America/Los_Angelessf=trueoutput=xml https://www.google.com/calendar/render?eid=b2w4bDFsaWNwN2p2ZjNydnViMHRpZTA4ZnMgZ3N1bW1lcm9mY29kZUBtctz=America/Los_Angelespli=1sf=trueoutput=xml Is there any volunteer that can lead EFL/E GSoC project? While it may all start with someone to lead. It requires a bit more than just that. There must be a pair of admins (primary and backup). There must be a willing and able pool of mentors (in duplicate as well, primary and backup). Those mentors must be willing and capable of mentoring the pool of ideas which should be reasonably applicable to the project (aka Enlightenment). This pool of ideas historically is a tad elusive and difficult to agree upon (the value and applicability of individual ideas). Why do I mention the above? Well, finding someone to admin is likely the easy part. Rounding up enough devs and enough quality ideas, such that E appears committed, determined to be involved, and relevant to today's *nix world is the trick. So, while admin'ing is a lot of work, and frankly time consuming and tough in hard times (though I consider it a very worthwhile endeavor) one might argue admins are a dime a dozen. An admin without mentors is of little value. I would ask... By show of hands... are there volunteers to mentor? And do you have ideas in hand? Sifting through this thread I see: Daniel Juyung Seo Tom Hacohen Cedric BAIL David Seikel Are you all still willing and able? Are there others in the wings? Yes, I'm up for it. -- Tom. -- 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, 21 Mar 2013 19:15:19 +1100 Mike McCormack m...@atratus.org said: 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? thanks, and this is EXACTLY why i keen going on about warning ANd optimization flags should not be set up by makefiles or configure - they come from the developers CFLAGS env set up for their build env and architecture. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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 11:36 AM, Bruno Dilly bdi...@profusion.mobi wrote: On Wed, Mar 20, 2013 at 11:21 PM, Cedric BAIL cedric.b...@free.fr wrote: 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 would like to review / add some physics stuff on Edje. Anyway one month is enough for me. Btw, does anybody reviewed it ? It is planned since a long time. Sadly I postponed it... Well, do you have more edje examples ? I have some idea that I could try, like adding alternate scheme for switching between terminology terminal as a way to do this review. That or some Enlightenment wallpaper. Regarding the one month feature freeze, it's a great idea. It should be time enough to drastically reduce bugs. I'm not sure since I'm not working with Elementary trunk, but some other devs have reported it's been very instable these weeks. Is anybody in charge to assure Elm quality ? Is this timeframe enough to stabilize it ? I hope someone somewhere close to London can roll in Exactness infrastructure and start building test on it. That should help. Would be great to have a list of issues / features to be implemented for 1.8. Do we have it somewhere ? Should be put on phab I guess. -- Cedric BAIL -- 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 10:58 AM, Carsten Haitzler ras...@rasterman.comwrote: On Thu, 21 Mar 2013 19:15:19 +1100 Mike McCormack m...@atratus.org said: 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? thanks, and this is EXACTLY why i keen going on about warning ANd optimization flags should not be set up by makefiles or configure - they come from the developers CFLAGS env set up for their build env and architecture. +2 here. IMO default cflags should be kept at a bare minimum. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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 -- 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 m...@atratus.org 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] Jenkins IRC notifications - how much is too much?
On 19/03/13 17:43, Daniel Willmann wrote: All was fine until earlier today when the Jenkins bot got kicked from #edevelop for use of colors and excessive messaging. I disabled colors and reduced the message to only report success of failure in order to have the bot in the channel again. [...] So what do you think? Is this too much, does it bother you? Should we re-enable the these features? So far the majority seems to be in favor of going back to the old settings. If I don't hear otherwise by tomorrow (now + ~22h) I will re-enable color and messages. Regards, Daniel -- 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] Jenkins IRC notifications - how much is too much?
On Thu, 21 Mar 2013 17:09:49 + Daniel Willmann d.willm...@samsung.com wrote: On 19/03/13 17:43, Daniel Willmann wrote: All was fine until earlier today when the Jenkins bot got kicked from #edevelop for use of colors and excessive messaging. I disabled colors and reduced the message to only report success of failure in order to have the bot in the channel again. [...] So what do you think? Is this too much, does it bother you? Should we re-enable the these features? So far the majority seems to be in favor of going back to the old settings. If I don't hear otherwise by tomorrow (now + ~22h) I will re-enable color and messages. One question, will it be kicked again? -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- 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
2013/3/19 Michael Blumenkrantz michael.blumenkra...@gmail.com On Tue, 19 Mar 2013 21:51:18 +0200 Kai Huuhko kai.huu...@gmail.com wrote: 19.03.2013 19:38, Lucas De Marchi kirjoitti: On Tue, Mar 19, 2013 at 12:40 PM, Kai Huuhko kai.huu...@gmail.com wrote: 19.03.2013 16:01, Lucas De Marchi kirjoitti: On Tue, Mar 19, 2013 at 8:55 AM, Kai Huuhko kai.huu...@gmail.com wrote: 19.03.2013 05:48, Lucas De Marchi kirjoitti: On Mon, Mar 18, 2013 at 5:57 PM, Kai Huuhko kai.huu...@gmail.com 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 want? An email asking for you to fix the broken stuff? What would happen if another project, unrelated to yours, started depending on it? Would you send them an email, too? How would you know the projects that were depending on it? We do have this list for that kind of communication. There is no policy that prevents one from doing so, nor is there really
