Re: [E-devel] ephysics does 3D now?
On Thu, 11 Oct 2012 14:43:09 +0900 (KST) ChunEon Park wrote: > as far as I know, only 2d available until now. > > -Original Message- > From: "David Seikel" > > Does ephysics do 3D now? > > I work with 3D virtual world software, so this suddenly has my > interest. 2D physics was not interesting for me. > > Perhaps my modular 3D object loading library work might be interesting > to others now? Odd, coz I saw a lot of stuff that smelled like 3D being committed, which prompted this email. -- 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 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Another French^WKorean E diner
I missed christophe sadoine. Jerome, Raster, Seoz, Cedric + 2 special guests, Sanjeev, Hermet, Christophe. -Regards, Hermet- -Original Message- From: "ChunEon Park" To: "Enlightenment developer list"; Cc: Sent: 2012-10-10 (수) 20:18:47 Subject: Re: [E-devel]Another French^WKorean E diner So, Jerome, Raster, Seoz, Cedric + 2 special guests, Sanjeev, Hermet will join there? Any other participants? -Regards, Hermet- -Original Message- From: "ChunEon Park"@naver.com> To: "Enlightenment developer list"@lists.sourceforge.net>; Cc: Sent: 2012-10-10 (수) 20:12:58 Subject: Re: [E-devel]Another French^WKorean E diner Then let's meet at Exit 11 of Kangnam station! -Regards, Hermet- -Original Message- From: "Cedric BAIL"@free.fr> To: "Enlightenment developer list"@lists.sourceforge.net>; Cc: Sent: 2012-10-08 (월) 16:51:36 Subject: Re: [E-devel] Another French^WKorean E diner On Mon, Oct 8, 2012 at 5:54 AM, Jérôme Pinot @gmail.com> wrote: > On 10/08/12 01:17, Daniel Juyung Seo wrote: >> Oh right. Kangnam can be a good place just to celebrate Psy's Gangnam Style >> :) >> But Jerome will have hard time to reach there :( > > Not really, I can take the bus at the express bus terminal. So Kangnam seems to be a better place for every one. Let's innovate and meet there. Any good idea where we should met ? >> Daniel Juyung Seo (SeoZ) >> >> On Mon, Oct 8, 2012 at 12:54 AM, ChunEon Park @naver.com> wrote: >> > I will not be in Seoul on the day. >> > >> > So It will be better for me if the place is Kangnam. >> > >> > Because i'm kangnam style... >> > >> > um? >> > >> > Joke. >> > >> > just worrying the terrible traffic jam to go to Itewon from the Suwon :) >> > >> > >> > >> > -Regards, Hermet- >> > -Original Message- >> > From: "Sanjeev BA"@gmail.com> >> > To: "Enlightenment developer >> > list"@lists.sourceforge.net>; >> > Cc: >> > Sent: 2012-10-05 (금) 18:28:13 >> > Subject: Re: [E-devel] Another French^WKorean E diner >> > >> > Yes, I will check if anyone wants to meet efl developers and bring them >> > along :) >> > >> > On Fri, Oct 5, 2012 at 6:20 PM, Cedric BAIL @free.fr> wrote: >> > >> >> On Fri, Oct 5, 2012 at 6:13 PM, Sanjeev BA @gmail.com> wrote: >> >> > I went by this. Friday October 12, 2012 4:15pm - 10:00pm @ Samwon >> >> > Gardens< >> >> http://korealinuxforum2012.sched.org/venue/Samwon+Gardens?iframe=yes&w=700&sidebar=no&bg=no >> >> > >> >> > It takes a 35 minute bus ride to Itaewon. >> >> > I will try to make it , if it is decided. >> >> >> >> Cool and you are welcome to bring more people to the after party :-) >> >> >> >> See you there >> >> >> >> > On Fri, Oct 5, 2012 at 5:31 PM, Cedric BAIL @free.fr> >> >> > wrote: >> >> > >> >> >> On Fri, Oct 5, 2012 at 5:04 PM, Sanjeev BA @gmail.com> wrote: >> >> >> > Event ends by 10 pm (as per schedule). >> >> >> > I believe networking starts beyond 8 pm :) >> >> >> >> >> >> Schedule say the dinner start at 4:15pm from marriot hotel and the >> >> >> shuttle bus will take you back between 8 and 10pm. :-) >> >> >> >> >> >> > On Fri, Oct 5, 2012 at 4:58 PM, Cedric BAIL @free.fr> >> >> wrote: >> >> >> > >> >> >> >> On Fri, Oct 5, 2012 at 4:51 PM, Sanjeev BA @gmail.com> >> >> wrote: >> >> >> >> > Korea Linux Forum is scheduled on Oct 11-12 and some of us might >> >> >> >> > be >> >> >> >> there. >> >> >> >> >> >> >> >> The event is supposed to end around 8pm. So you have plenty of time >> >> to >> >> >> >> join us for the night and get a drink. Oh, and if you want you can >> >> >> >> invite more guest from that event ;-) >> >> >> >> >> >> >> >> > On Fri, Oct 5, 2012 at 2:48 PM, Kim Shinwoo < >> >> kimcinoo@gmail.com> >> >> >> >> wrote: >> >> >> >> >> wow two guests.. that sounds great! but i'm afraid i cannot >> >> >> >> >> join.. >> >> >> T,.T >> >> >> >> >> >> >> >> >> >> 2012/10/5 Jérôme Pinot @gmail.com> >> >> >> >> >> >> >> >> >> >> > On 10/04/12 18:17, Cedric BAIL wrote: >> >> >> >> >> > > Hello every body, >> >> >> >> >> > > >> >> >> >> >> > > Long time no see ! For all of you that are in Korea or may be >> >> >> around >> >> >> >> >> > > Seoul on Friday 12th of October, aka Friday next week, I >> >> propose >> >> >> we >> >> >> >> >> > > met in Itaewon for a diner at around 8pm. So who is joining ? >> >> >> And we >> >> >> >> >> > > will have two special guests ! >> >> >> >> >> > >> >> >> >> >> > It's OK for me too! >> >> >> >> >> > >> >> >> >> >> > BTW if you like to start earlier, I may be able to change my >> >> >> schedule. >> >> >> >> >> > >> >> >> >> >> > -- >> >> >> >> >> > Jérôme Pinot >> >> >> >> >> > http://ngc891.blogdns.net/ > > -- > Jérôme Pinot > http://ngc891.blogdns.net/ > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app p
Re: [E-devel] ephysics does 3D now?
as far as I know, only 2d available until now. -Regards, Hermet- -Original Message- From: "David Seikel" To: ; Cc: Sent: 2012-10-11 (목) 11:49:54 Subject: [E-devel] ephysics does 3D now? Does ephysics do 3D now? I work with 3D virtual world software, so this suddenly has my interest. 2D physics was not interesting for me. Perhaps my modular 3D object loading library work might be interesting to others now? -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ 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: . src/benchmarks src/bin src/examples src/lib src/tests
On Wednesday, October 10, 2012, Vincent Torri wrote:
> i've already stated that i do not want that, please revert
>
> Gustavo : you told me that you wanted to take care of options, no other
> stuff
You mean the order? It should be reasonable to build eo before eet. Maybe
some day eet is made to use eo.
Also neither eet or eo will be optional at this point.
>
> Vincent
>
> On Wed, Oct 10, 2012 at 7:27 PM, Enlightenment SVN
> wrote:
> > Log:
> > efl: eet and eo are now mandatory.
> >
> > I've reordered the build to be: eina -> eo -> eet as it make more
> sense.
> >
> >
> >
> > Author: barbieri
> > Date: 2012-10-10 10:27:11 -0700 (Wed, 10 Oct 2012)
> > New Revision: 77766
> > Trac: http://trac.enlightenment.org/e/changeset/77766
> >
> > Modified:
> > trunk/efl/Makefile.am
> > trunk/efl/configure.actrunk/efl/src/benchmarks/Makefile.am
> > trunk/efl/src/bin/Makefile.am
> trunk/efl/src/examples/Makefile.am trunk/efl/src/lib/Makefile.am
> trunk/efl/src/tests/Makefile.am
> >
> > Modified: trunk/efl/Makefile.am
> > ===
> > --- trunk/efl/Makefile.am 2012-10-10 17:06:14 UTC (rev 77765)
> > +++ trunk/efl/Makefile.am 2012-10-10 17:27:11 UTC (rev 77766)
> > @@ -57,17 +57,12 @@
> > pkgconfig_DATA += pc/evil.pc
> > endif
> >
> > -pkgconfig_DATA += pc/eina.pc
> > +pkgconfig_DATA += \
> > +pc/eina.pc \
> > +pc/eo.pc \
> > +pc/eet.pc
> >
> > -if EFL_BUILD_EET
> > -pkgconfig_DATA += pc/eet.pc
> > -endif
> >
> > -if EFL_BUILD_EO
> > -pkgconfig_DATA += pc/eo.pc
> > -endif
> > -
> > -
> > .PHONY: doc benchmark examples install-examples
> >
> > # Documentation
> > @@ -100,12 +95,8 @@
> > if EFL_ENABLE_COVERAGE
> > @$(MAKE) $(AM_MAKEFLAGS) lcov-reset
> > endif
> > -if EFL_BUILD_EET
> > @./src/tests/eet/eet_suite$(EXEEXT)
> > -endif
> > -if EFL_BUILD_EO
> > @./src/tests/eo/eo_suite$(EXEEXT)
> > -endif
> > if EFL_ENABLE_COVERAGE
> > @$(MAKE) $(AM_MAKEFLAGS) lcov-report
> > endif
> > @@ -117,9 +108,7 @@
> > benchmark:
> > @$(MAKE) $(AM_MAKEFLAGS) -C src benchmark
> > @mkdir benchmark || true
> > -if EFL_BUILD_EO
> > @cd benchmark && ../src/benchmarks/eo/eo_bench$(EXEEXT) `date
> +%F_%s`
> > -endif
> >
> > benchmark-e17:
> > @$(MAKE) $(AM_MAKEFLAGS) -C src benchmark-e17
> >
> > Modified: trunk/efl/configure.ac
> > ===
> > --- trunk/efl/configure.ac 2012-10-10 17:06:14 UTC (rev 77765)
> > +++ trunk/efl/configure.ac 2012-10-10 17:27:11 UTC (rev 77766)
> > @@ -196,8 +196,6 @@
> >
> > Additional options to configure
> >
> > -EFL_ENABLE_LIB([eet], [yes])
> > -EFL_ENABLE_LIB([eo], [yes])
> >
> >
> > # Assert or fail.
> > @@ -787,8 +785,6 @@
> >
> > efl_have_eet="no"
> >
> > -if test "x${efl_want_build_eet}" = "xyes" ; then
> > -
> > AC_MSG_NOTICE([Eet checks])
> >
> > ### Default values
> > @@ -1136,8 +1132,6 @@
> > efl_have_eet="yes"
> > fi
> >
> > -fi
> > -
> > End of Eet
> >
> >
> > @@ -1145,8 +1139,6 @@
> >
> > efl_have_eo="no"
> >
> > -if test "x${efl_want_build_eo}" = "xyes" ; then
> > -
> > AC_MSG_NOTICE([Eo checks])
> >
> > ### Default values
> > @@ -1195,12 +1187,6 @@
> >
> > efl_have_eo="yes"
> >
> > -else
> > -
> > -AM_CONDITIONAL([EO_BUILD_EXAMPLE_EVAS], [false])
> > -
> > -fi
> > -
> > End of Eo
> >
> >
> >
> > Modified: trunk/efl/src/benchmarks/Makefile.am
> > ===
> > --- trunk/efl/src/benchmarks/Makefile.am2012-10-10
> 17:06:enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri trunk/efl
On Wednesday, October 10, 2012, Vincent Torri wrote: > i did that for a precise reason... I'll revert some stuff... That was just pollution. We need to keep it lean and later add some macros to create that stuff. It's too error prone. :-( > > Vincent > > On Wed, Oct 10, 2012 at 7:40 PM, Enlightenment SVN > wrote: > > Log: > > efl: cleanup to remove stuff that is not in single-tree yet. > > > > Remove every mention to libraries that are still not in the > > single-tree build such as emotion, efreet and ethumb. > > > > Keep it simple and just add them back when they are merged. > > > > Added similar variables for all of evil, eina, eo and eet. Keep them > > in the same order for now. > > > > > > > > Author: barbieri > > Date: 2012-10-10 10:40:35 -0700 (Wed, 10 Oct 2012) > > New Revision: 77767 > > Trac: http://trac.enlightenment.org/e/changeset/77767 > > > > Modified: > > trunk/efl/INSTALL trunk/efl/configure.ac > > > > Modified: trunk/efl/INSTALL > > === > > --- trunk/efl/INSTALL 2012-10-10 17:27:11 UTC (rev 77766) > > +++ trunk/efl/INSTALL 2012-10-10 17:40:35 UTC (rev 77767) > > @@ -1,8 +1,8 @@ > > Installation Instructions > > * > > > > -Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005, > > -2006, 2007, 2008, 2009 Free Software Foundation, Inc. > > +Copyright (C) 1994-1996, 1999-2002, 2004-2011 Free Software Foundation, > > +Inc. > > > > Copying and distribution of this file, with or without modification, > > are permitted in any medium without royalty provided the copyright > > @@ -226,6 +226,11 @@ > > > > and if that doesn't work, install pre-built binaries of GCC for HP-UX. > > > > + HP-UX `make' updates targets which have the same time stamps as > > +their prerequisites, which makes it generally unusable when shipped > > +generated files such as `configure' are involved. Use GNU `make' > > +instead. > > + > > On OSF/1 a.k.a. Tru64, some versions of the default C compiler cannot > > parse its `' header file. The option `-nodtk' can be used as > > a workaround. If GNU CC is not installed, it is therefore recommended > > > > Modified: trunk/efl/configure.ac > > === > > --- trunk/efl/configure.ac 2012-10-10 17:27:11 UTC (rev 77766) > > +++ trunk/efl/configure.ac 2012-10-10 17:40:35 UTC (rev 77767) > > @@ -51,106 +51,36 @@ > > > > Default values > > > > -want_evas="yes" > > -want_ecore="yes" > > -want_embryo="yes" > > -want_eio="yes" > > -want_edje="yes" > > -want_efreet="yes" > > -want_e_dbus="yes" > > -want_eeze="yes" > > -want_emotion="yes" > > -want_ethumb="yes" > > -want_elementary="yes" > > > > requirements_libs_evil="" > > requirements_libs_eina="" > > +requirements_libs_eo="" > > requirements_libs_eet="" > > -requirements_libs_evas="" > > -requirements_libs_ecore="" > > -requirements_libs_embryo="" > > -requirements_libs_eio="" > > -requirements_libs_edje="" > > -requirements_libs_efreet="" > > -requirements_libs_e_dbus="" > > -requirements_libs_eeze="" > > -requirements_libs_emotion="" > > -requirements_libs_ethumb="" > > -requirements_libs_elementary="" > > > > requirements_libs_deps_evil="" > > requirements_libs_deps_eina="" > > +requirements_libs_deps_eo="" > > requirements_libs_deps_eet="" > > -requirements_libs_deps_evas="" > > -requirements_libs_deps_ecore="" > > -requirements_libs_deps_embryo="" > > -requirements_libs_deps_eio="" > > -requirements_libs_deps_edje="" > > -requirements_libs_deps_efreet=enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ 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: . src/bin/eet
On Thursday, October 11, 2012, Cedric BAIL wrote: > On Thu, Oct 11, 2012 at 11:44 AM, Gustavo Sverzut Barbieri > > wrote: > > On Wednesday, October 10, 2012, Cedric BAIL wrote: > >> On Thu, Oct 11, 2012 at 10:01 AM, Vincent Torri < > vincent.to...@gmail.com > > >> wrote: > >> > On Wed, Oct 10, 2012 at 11:15 PM, Enlightenment SVN > >> > > wrote: > >> >> Log: > >> >> efl: eet binary is not optional anymore. > >> >> > >> >> it's pointless to have this and may cause problems or complex > >> >> configure.ac when we have libraries that use 'eet' during its > compile > >> >> phase (like elementary generates its profile/configuration). > >> > > >> > except that it's completely useless to have it for, for example > >> > Windows CE or any other system on which we don't care about it > >> > >> Yeah, I am with Vincent on that one. Please revert. It is useless and > >> cumbersome to build on many embedded target. > > > > > > You need it to create elementary profiles and such things. Just rm it > from > > your distro once you release. > > No, you don't when you are cross compiling. That's the corner case AND you still need ANOTHER var for that. The thing is that of you leave it optional then you need to make configure.ac overly complex to handle warnings or errors if need_eet_bin && !want_eet_bin > -- > Cedric BAIL > > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [Patch][Evas] texture size issue for nv12 format
Hi. I made a patch for evas regarding texture size issue. When the image has nv12 tiled format and is rendered by gl backend, the uv texture size is 2 times bigger than original size. I fixed nv12 shaders and codes a little. Please review the attahced patch. Regards, Sohyun evas_texture.patch Description: Binary data -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elementary: problem with focus in panel
Following up: >Hi, > >Moving from EFL 1.2 to 1.7 was not flawless for eperiodique. I had to >adjust again the button size in boxes, but well, it does mostly work as >expected. > >I still got a major issue that prevents me to release: it seems that the >focus behaviour in panel changed a lot (or is it a bug?). > >Under EFL 1.2, I can open a panel, which contains an entry widget and a >button, enter formula and activate via or the button to get the >result, as shown at the end of this video: >http://www.youtube.com/watch?v=wjp_0guZ05Q > >But with EFL 1.7, once the panel is open, it's not possible to get the >focus on the entry widget with the mouse (but with it works). >Moreover, pressing when in the entry widget just close the >panel in same time it activates the entry. > >So, if it's not bugs (I didn't change this part of eperiodique code), I'd >like to know: >- how to select the entry with mouse (as before) >- how to make the panel widget not react on the (or change the > key) > >For reference, the panel code of eperiodique is available here; >http://eperiodique.git.sourceforge.net/git/gitweb.cgi?p=eperiodique/eperiodique;a=blob;f=src/panel.c;h=f3b993035a5e3f330bdaaa48b2f9fbdd4f62a553;hb=HEAD > > >Thanks for any help, this issue is blocking my work on SlackE17. Reverting r75008 fixes this issue. -- Jérôme Pinot http://ngc891.blogdns.net/ signature.asc Description: Digital signature -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [patch][elementary] diskselector - blank item should be added on round disabled mode
dear all hello. blank item should be added on the round disabled mode. current diskselector adds blank item even though the round mode is enabled. so please check the patch and give feedback. thanks. cordially, shinwoo kim. diskselector.blank.only.unround.mode.diff Description: Binary data -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ 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: . src/bin/eet
On Thu, Oct 11, 2012 at 11:44 AM, Gustavo Sverzut Barbieri wrote: > On Wednesday, October 10, 2012, Cedric BAIL wrote: >> On Thu, Oct 11, 2012 at 10:01 AM, Vincent Torri >> > >> wrote: >> > On Wed, Oct 10, 2012 at 11:15 PM, Enlightenment SVN >> > > wrote: >> >> Log: >> >> efl: eet binary is not optional anymore. >> >> >> >> it's pointless to have this and may cause problems or complex >> >> configure.ac when we have libraries that use 'eet' during its compile >> >> phase (like elementary generates its profile/configuration). >> > >> > except that it's completely useless to have it for, for example >> > Windows CE or any other system on which we don't care about it >> >> Yeah, I am with Vincent on that one. Please revert. It is useless and >> cumbersome to build on many embedded target. > > > You need it to create elementary profiles and such things. Just rm it from > your distro once you release. No, you don't when you are cross compiling. -- Cedric BAIL -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ 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: . src/lib/eina src/modules/eina/mp
On Wednesday, October 10, 2012, Vincent Torri wrote:
> On Wed, Oct 10, 2012 at 9:57 PM, Enlightenment SVN
> > wrote:
> > Log:
> > efl: simplify mempools, nuke some and make remaining statically built.
> >
> > Now we always build the following memory pools statically:
> >- pass_through: calls malloc/free directly, useful to debug.
> >- chained_pool: default for ages.
> >- one_big: used by some embedded systems (should we remove?)
> >
> > Removed:
> >- ememoa_fixed and ememoa_unknown: depends on a separate lib, not
> supported?
> >- buddy: nobody uses it?
>
> please let turran say if he wants buddy or not before nuking it..
Raster said to keep those so did I. Everything else was removed.
>
> Vincent
>
> >
> > NOTE: we do not need the src/modules/eina/mp/*/Makefile.am anymore
> > since they are statically built. But I'll keep these and the
> > references in src/modules/eina/mp/Makefile.am
> >
> >
> >
> > Author: barbieri
> > Date: 2012-10-10 12:57:53 -0700 (Wed, 10 Oct 2012)
> > New Revision: 77792
> > Trac: http://trac.enlightenment.org/e/changeset/77792
> >
> > Removed:
> > trunk/efl/src/modules/eina/mp/buddy/
> trunk/efl/src/modules/eina/mp/ememoa_fixed/
> trunk/efl/src/modules/eina/mp/ememoa_unknown/
> trunk/efl/src/modules/eina/mp/fixed_bitmap/
> > Modified:
> > trunk/efl/configure.ac trunk/efl/src/lib/eina/Makefile.am
> trunk/efl/src/lib/eina/eina_mempool.c trunk/efl/src/lib/eina/eina_mempool.h
> trunk/efl/src/modules/eina/mp/Makefile.am
> >
> > Modified: trunk/efl/configure.ac
> > ===
> > --- trunk/efl/configure.ac 2012-10-10 19:36:36 UTC (rev 77791)
> > +++ trunk/efl/configure.ac 2012-10-10 19:57:53 UTC (rev 77792)
> > @@ -343,23 +343,7 @@
> > fi
> >
> > # Choose best memory pool
> > -AC_ARG_ENABLE([default-mempool],
> > - [AC_HELP_STRING([--enable-default-mempool], [Default memory
> allocator could be faster for some computer. @<:@default=disabled@:>@])],
> > - [
> > -if test "x${enableval}" = "xyes"; then
> > - have_default_mempool="yes"
> > -else
> > - have_default_mempool="no"
> > -fi
> > - ],
> > - [have_default_mempool="no"])
> > -
> > -AC_MSG_CHECKING([whether to use default mempool allocator])
> > -AC_MSG_RESULT([${have_default_mempool}])
> > -
> > -if test "x${have_default_mempool}" = "xyes" ; then
> > - EINA_CONFIGURE_DEFAULT_MEMPOOL="#define EINA_DEFAULT_MEMPOOL"
> > -fi
> > +EINA_CONFIGURE_DEFAULT_MEMPOOL="#define EINA_DEFAULT_MEMPOOL"
> > AC_SUBST([EINA_CONFIGURE_DEFAULT_MEMPOOL])
> >
> > ### Checks for programs
> > @@ -431,36 +415,11 @@
> > fi
> >
> > ## Modules
> > -
> > -# Check ememoa memory pool library
> > -
> > -AC_ARG_ENABLE([ememoa],
> > - [AC_HELP_STRING([--enable-ememoa], [build ememoa memory pool module
> @<:@default=yes@:>@])],
> > - [
> > -if test "x${enableval}" = "xyes" ; then
> > - enable_ememoa="yes"
> > -else
> > - enable_ememoa="no"
> > -fi
> > - ],
> > - [enable_ememoa="yes"])
> > -
> > -AC_MSG_CHECKING([whether to use ememoa for memory pool])
> > -AC_MSG_RESULT([${enable_ememoa}])
> > -
> > -if test "x${enable_ememoa}" = "xyes" ; then
> > - PKG_CHECK_MODULES([EMEMOA],
> > - [ememoa >= 0.0.26 ],
> > - [enable_ememoa="yes"],
> > - [enable_ememoa="no"])
> > -fi
> > -
> > if ! test "x${requirements_pc_deps_eina}" = "x" ; then
> > PKG_CHECK_MODULES([EINA], [${requirements_pc_deps_eina}])
> > fi
> >
> >
> > -
> > ## Examples
> >
> > # TODO: add once ecore-evas is merged:
> > @@ -596,26 +555,11 @@
> > AM_CONDITIONAL([EINA_ON_OFF_THREADS], [! test
> "x${efl_have_on_off_threads}" = "xno"])
> >
> > ### Modules
> > +EINA_CHECK_MODULE([chained-pool], [static], [chained pool])
> > +EINA_CHECK_MODULE([pass-through], [static], [pass through])
> > +EINA_CHECK_MODULE([one-big],[static], [one big])
> >
> > -if test "x${have_default_mempool}" = "xyes" ; then
> > - enable_chained_pool="no"
> > - enable_pass_through=enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] ephysics does 3D now?
Does ephysics do 3D now? I work with 3D virtual world software, so this suddenly has my interest. 2D physics was not interesting for me. Perhaps my modular 3D object loading library work might be interesting to others now? -- 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 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ 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 Wednesday, October 10, 2012, Vincent Torri wrote:
> On Wed, Oct 10, 2012 at 10:40 PM, Enlightenment SVN
> > wrote:
> > Log:
> > efl: remove option to debug threads, now enabled based on build profile.
> >
> > If --with-profile=dev, we enable threads debug.
>
> again, add a description in README
Ok
>
> Vincent
>
> >
> >
> >
> > Author: barbieri
> > Date: 2012-10-10 13:40:34 -0700 (Wed, 10 Oct 2012)
> > New Revision: 77806
> > Trac: http://trac.enlightenment.org/e/changeset/77806
> >
> > Modified:
> > trunk/efl/configure.ac trunk/efl/m4/efl_threads.m4
> >
> > Modified: trunk/efl/configure.ac
> > ===
> > --- trunk/efl/configure.ac 2012-10-10 20:32:35 UTC (rev 77805)
> > +++ trunk/efl/configure.ac 2012-10-10 20:40:34 UTC (rev 77806)
> > @@ -539,11 +539,11 @@
> > EINA_CONFIGURE_HAVE_THREADS="#define EINA_HAVE_THREADS"
> > AC_SUBST(EINA_CONFIGURE_HAVE_THREADS)
> >
> > -if test "x${efl_have_debug_threads}" = "xyes"; then
> > +if test "$build_profile" = "dev"; then
> > EINA_CONFIGURE_HAVE_DEBUG_THREADS="#define EINA_HAVE_DEBUG_THREADS"
> > + AC_DEFINE([EFL_DEBUG_THREADS], [1], [Assert when forgot to call
> eina_threads_init])
> > fi
> > AC_SUBST(EINA_CONFIGURE_HAVE_DEBUG_THREADS)
> > -AM_CONDITIONAL([EINA_DEBUG_THREADS], [test "x${efl_have_debug_threads}"
> = "xyes"])
> >
> > ### Modules
> > EINA_CHECK_MODULE([chained-pool], [static], [chained pool])
> > @@ -866,7 +866,6 @@
> > echo " Thread Support...: ${efl_have_threads}"
> > if test "${efl_have_threads}" = "POSIX" ; then
> > echo "spinlock...: ${efl_have_posix_threads_spinlock}"
> > -echo "debug usage: ${efl_have_debug_threads}"
> > fi
> > echo
> > echo "Compilation: make (or gmake)"
> >
> > Modified: trunk/efl/m4/efl_threads.m4
> > ===
> > --- trunk/efl/m4/efl_threads.m4 2012-10-10 20:32:35 UTC (rev 77805)
> > +++ trunk/efl/m4/efl_threads.m4 2012-10-10 20:40:34 UTC (rev 77806)
> > @@ -117,19 +117,6 @@
> > AC_DEFINE([EFL_HAVE_POSIX_THREADS_SPINLOCK], [1], [Define to mention
> that POSIX threads spinlocks are supported])
> > fi
> >
> > -dnl Check debug threads
> > -
> > -_efl_enable_debug_threads="no"
> > -AC_ARG_ENABLE([debug-threads],
> > - [AC_HELP_STRING([--enable-debug-threads], [disable assert when you
> forgot to call eina_threads_init])],
> > - [_efl_enable_debug_threads="${enableval}"])
> > -
> > -efl_have_debug_threads="no"
> > -if test "x${_efl_have_posix_threads}" = "xyes" && test
> "x${_efl_enable_debug_threads}" = "xyes"; then
> > - efl_have_debug_threads="yes"
> > - AC_DEFINE([EFL_DEBUG_THREADS], [1], [Assert when forgot to call
> eina_threads_init])
> > -fi
> > -
> > AS_IF([test "x$_efl_have_posix_threads" = "xyes" || test
> "x$_efl_have_win32_threads" = "xyes"],
> > [$1],
> > [m4_if([$2], [$2], [AC_MSG_ERROR([Threads are required.])])])
> >
> >
> >
> --
> > Don't let slow site performance ruin your business. Deploy New Relic APM
> > Deploy New Relic app performance management and know exactly
> > what is happening inside your Ruby, Python, PHP, Java, and .NET app
> > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> > http://p.sf.net/sfu/newrelic-dev2dev
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
> enlightenment-devel
> mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
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: . src/bin/eet
On Wednesday, October 10, 2012, Cedric BAIL wrote: > On Thu, Oct 11, 2012 at 10:01 AM, Vincent Torri > > > wrote: > > On Wed, Oct 10, 2012 at 11:15 PM, Enlightenment SVN > > > wrote: > >> Log: > >> efl: eet binary is not optional anymore. > >> > >> it's pointless to have this and may cause problems or complex > >> configure.ac when we have libraries that use 'eet' during its compile > >> phase (like elementary generates its profile/configuration). > > > > except that it's completely useless to have it for, for example > > Windows CE or any other system on which we don't care about it > > Yeah, I am with Vincent on that one. Please revert. It is useless and > cumbersome to build on many embedded target. You need it to create elementary profiles and such things. Just rm it from your distro once you release. > -- > Cedric BAIL > > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl single tree changes, need help!
On Wednesday, October 10, 2012, Vincent Torri wrote:
> On Thu, Oct 11, 2012 at 12:47 AM, Gustavo Sverzut Barbieri
> > wrote:
> > Hi all,
> >
> > As you may see I did a torrent of commits to efl single tree in order
> > to simplify its build and configuration as we discussed in many other
> > threads.
> >
> > However the work is far from complete and I need your help: please
> > walk configure.ac and read the comments left with "TODO". Mostly what
> > I believe needs lots of improvements:
> >
> > - Windows (and other platforms?) handling: while Linux/BSD is mostly
> > transparent the windows support is widely spread in both configure.ac
> > and Makefile.am. We better find a way to make it automatic or it will
> > be insanely painful to maintain. Likely we should create a set of
> > PLATFORM_LIBS, PLATFORM_CFLAGS... and always include those (instead of
> > Makefile.am: if HAVE_WINDOWS...
> >
> > - Gnutls: do we need to keep the old support? I'd vote to bump
> > requirement and simplify configure.ac and the usage in eet.
> >
> > - Handling of common system functions, headers and compile options.
> > There is a new set of macros that will take the libname as first
> > parameter, applying discovered bits to it. However most checks will be
> > used by more than one library, things like dirfd() or dlopen() are not
> > exclusive of EINA. Same for compiler flags such as -Wl,--as-needed.
> > Also it's not clear when these are actually namespaced and how. For
> > instance dlopen and dirfd shows on config.h as HAVE_DLOPEN and
> > HAVE_DIRFD.
> >
> > - Handling of pkg-config of in-tree libraries. Right now we have some
> > mistakes that wouldn't let a clean system to build. For instance,
> > while building eet we PKG_CHECK_MODULES([EET],
> > [${requirements_pc_deps_eet}]), but requirements_pc_eet="eina >=
> > 1.7.99 ${requirements_pc_eet}"... In other words we're checking eina
> >>= 1.7.99 from SYSTEM ($PKG_CONFIG_PATH, $PKG_CONFIG_LIBDIR).
> >
> > - Need for requirements_libs_LIBNAME, requirements_libs_deps_LIBNAME
> > and requirements_pc_deps_LIBNAME... So easy to forget to set :-/ Maybe
> > add wrapper functions EFL_PKG_CHECK and similar that will
> > automatically append to these variables?
> >
> > Please help! :-)
>
> please stop modifying efl/ You modify stuff that i didn't want you to
> modify. You've talk ed about modifying options in IRC, not more !!!
O just stopped due lack of time. See email, LOTS to do :-(
>
> thanks
>
> Vincent
>
>
> --
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
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: . src/bin/eet
On Thu, Oct 11, 2012 at 10:01 AM, Vincent Torri wrote: > On Wed, Oct 10, 2012 at 11:15 PM, Enlightenment SVN > wrote: >> Log: >> efl: eet binary is not optional anymore. >> >> it's pointless to have this and may cause problems or complex >> configure.ac when we have libraries that use 'eet' during its compile >> phase (like elementary generates its profile/configuration). > > except that it's completely useless to have it for, for example > Windows CE or any other system on which we don't care about it Yeah, I am with Vincent on that one. Please revert. It is useless and cumbersome to build on many embedded target. -- Cedric BAIL -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ 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 src/lib/eina
On Thu, Oct 11, 2012 at 5:30 AM, Enlightenment SVN wrote: > Log: > efl: remove EINA_HAVE_ON_OFF_THREADS support. > > it's still in the code, but not configurable anymore. We may remove it > later if not really needed. As we are going to include the async rendering code, that can be removed as we will always require thread support to be on. -- Cedric BAIL -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Configure profiles for e's source
On Wed, Oct 10, 2012 at 9:33 PM, Gustavo Sverzut Barbieri wrote: > Bd to release what we don't test in dev. > > I'm also against "fast". It will not work, really things will crash and > until we make sure that doesn't crash for our apps. > > If you want dev x release make sure this is just CFLAGS (NDEBUG, -Wall > -Wextra -Wshadow), not features like disable checks. Checks should trigger big fat warning if they are to be removed at release time. -- Cedric BAIL -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl single tree changes, need help!
On Thu, Oct 11, 2012 at 12:47 AM, Gustavo Sverzut Barbieri
wrote:
> Hi all,
>
> As you may see I did a torrent of commits to efl single tree in order
> to simplify its build and configuration as we discussed in many other
> threads.
>
> However the work is far from complete and I need your help: please
> walk configure.ac and read the comments left with "TODO". Mostly what
> I believe needs lots of improvements:
>
> - Windows (and other platforms?) handling: while Linux/BSD is mostly
> transparent the windows support is widely spread in both configure.ac
> and Makefile.am. We better find a way to make it automatic or it will
> be insanely painful to maintain. Likely we should create a set of
> PLATFORM_LIBS, PLATFORM_CFLAGS... and always include those (instead of
> Makefile.am: if HAVE_WINDOWS...
>
> - Gnutls: do we need to keep the old support? I'd vote to bump
> requirement and simplify configure.ac and the usage in eet.
>
> - Handling of common system functions, headers and compile options.
> There is a new set of macros that will take the libname as first
> parameter, applying discovered bits to it. However most checks will be
> used by more than one library, things like dirfd() or dlopen() are not
> exclusive of EINA. Same for compiler flags such as -Wl,--as-needed.
> Also it's not clear when these are actually namespaced and how. For
> instance dlopen and dirfd shows on config.h as HAVE_DLOPEN and
> HAVE_DIRFD.
>
> - Handling of pkg-config of in-tree libraries. Right now we have some
> mistakes that wouldn't let a clean system to build. For instance,
> while building eet we PKG_CHECK_MODULES([EET],
> [${requirements_pc_deps_eet}]), but requirements_pc_eet="eina >=
> 1.7.99 ${requirements_pc_eet}"... In other words we're checking eina
>>= 1.7.99 from SYSTEM ($PKG_CONFIG_PATH, $PKG_CONFIG_LIBDIR).
>
> - Need for requirements_libs_LIBNAME, requirements_libs_deps_LIBNAME
> and requirements_pc_deps_LIBNAME... So easy to forget to set :-/ Maybe
> add wrapper functions EFL_PKG_CHECK and similar that will
> automatically append to these variables?
>
> Please help! :-)
please stop modifying efl/ You modify stuff that i didn't want you to
modify. You've talk ed about modifying options in IRC, not more !!!
thanks
Vincent
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri trunk/efl
i did that for a precise reason... I'll revert some stuff... Vincent On Wed, Oct 10, 2012 at 7:40 PM, Enlightenment SVN wrote: > Log: > efl: cleanup to remove stuff that is not in single-tree yet. > > Remove every mention to libraries that are still not in the > single-tree build such as emotion, efreet and ethumb. > > Keep it simple and just add them back when they are merged. > > Added similar variables for all of evil, eina, eo and eet. Keep them > in the same order for now. > > > > Author: barbieri > Date: 2012-10-10 10:40:35 -0700 (Wed, 10 Oct 2012) > New Revision: 77767 > Trac: http://trac.enlightenment.org/e/changeset/77767 > > Modified: > trunk/efl/INSTALL trunk/efl/configure.ac > > Modified: trunk/efl/INSTALL > === > --- trunk/efl/INSTALL 2012-10-10 17:27:11 UTC (rev 77766) > +++ trunk/efl/INSTALL 2012-10-10 17:40:35 UTC (rev 77767) > @@ -1,8 +1,8 @@ > Installation Instructions > * > > -Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005, > -2006, 2007, 2008, 2009 Free Software Foundation, Inc. > +Copyright (C) 1994-1996, 1999-2002, 2004-2011 Free Software Foundation, > +Inc. > > Copying and distribution of this file, with or without modification, > are permitted in any medium without royalty provided the copyright > @@ -226,6 +226,11 @@ > > and if that doesn't work, install pre-built binaries of GCC for HP-UX. > > + HP-UX `make' updates targets which have the same time stamps as > +their prerequisites, which makes it generally unusable when shipped > +generated files such as `configure' are involved. Use GNU `make' > +instead. > + > On OSF/1 a.k.a. Tru64, some versions of the default C compiler cannot > parse its `' header file. The option `-nodtk' can be used as > a workaround. If GNU CC is not installed, it is therefore recommended > > Modified: trunk/efl/configure.ac > === > --- trunk/efl/configure.ac 2012-10-10 17:27:11 UTC (rev 77766) > +++ trunk/efl/configure.ac 2012-10-10 17:40:35 UTC (rev 77767) > @@ -51,106 +51,36 @@ > > Default values > > -want_evas="yes" > -want_ecore="yes" > -want_embryo="yes" > -want_eio="yes" > -want_edje="yes" > -want_efreet="yes" > -want_e_dbus="yes" > -want_eeze="yes" > -want_emotion="yes" > -want_ethumb="yes" > -want_elementary="yes" > > requirements_libs_evil="" > requirements_libs_eina="" > +requirements_libs_eo="" > requirements_libs_eet="" > -requirements_libs_evas="" > -requirements_libs_ecore="" > -requirements_libs_embryo="" > -requirements_libs_eio="" > -requirements_libs_edje="" > -requirements_libs_efreet="" > -requirements_libs_e_dbus="" > -requirements_libs_eeze="" > -requirements_libs_emotion="" > -requirements_libs_ethumb="" > -requirements_libs_elementary="" > > requirements_libs_deps_evil="" > requirements_libs_deps_eina="" > +requirements_libs_deps_eo="" > requirements_libs_deps_eet="" > -requirements_libs_deps_evas="" > -requirements_libs_deps_ecore="" > -requirements_libs_deps_embryo="" > -requirements_libs_deps_eio="" > -requirements_libs_deps_edje="" > -requirements_libs_deps_efreet="" > -requirements_libs_deps_e_dbus="" > -requirements_libs_deps_eeze="" > -requirements_libs_deps_emotion="" > -requirements_libs_deps_ethumb="" > -requirements_libs_deps_elementary="" > > +requirements_pc_evil="" > requirements_pc_eina="" > -requirements_pc_eet="" > requirements_pc_eo="" > -requirements_pc_evas="" > -requirements_pc_ecore="" > -requirements_pc_embryo="" > -requirements_pc_eio="" > -requirements_pc_edje="" > -requirements_pc_efreet="" > -requirements_pc_e_dbus="" > -requirements_pc_eeze="" > -requirements_pc_emotion="" > -requirements_pc_ethumb="" > -requirements_pc_elementary="" > +requirements_pc_eet="" > > +requirements_pc_deps_evil="" > requirements_pc_deps_eina="" > +requirements_pc_deps_eo="" > requirements_pc_deps_eet="" > -requirements_pc_deps_evas="" > -requirements_pc_deps_ecore="" > -requirements_pc_deps_embryo="" > -requirements_pc_deps_eio="" > -requirements_pc_deps_edje="" > -requirements_pc_deps_efreet="" > -requirements_pc_deps_e_dbus="" > -requirements_pc_deps_eeze="" > -requirements_pc_deps_emotion="" > -requirements_pc_deps_ethumb="" > -requirements_pc_deps_elementary="" > > AC_SUBST([requirements_libs_evil]) > AC_SUBST([requirements_libs_eina]) > +AC_SUBST([requirements_libs_eo]) > AC_SUBST([requirements_libs_eet]) > -AC_SUBST([requirements_libs_evas]) > -AC_SUBST([requirements_libs_ecore]) > -AC_SUBST([requirements_libs_embryo]) > -AC_SUBST([requirements_libs_eio]) > -AC_SUBST([requirements_libs_edje]) > -AC_SUBST([requirements_libs_efreet]) > -AC_SUBST([requirements_libs_e_dbus]) > -AC_SUBST([requirements_libs_eeze]) > -AC_SUBST([requirements_libs_emotion]) > -AC_SUBST([requirements_libs_ethumb]) > -AC_SUBST([requirements_libs_elementary]) > > +AC_SUBST([requirements_pc_ev
Re: [E-devel] E SVN: barbieri IN trunk/efl: . m4
On Wed, Oct 10, 2012 at 10:40 PM, Enlightenment SVN
wrote:
> Log:
> efl: remove option to debug threads, now enabled based on build profile.
>
> If --with-profile=dev, we enable threads debug.
again, add a description in README
Vincent
>
>
>
> Author: barbieri
> Date: 2012-10-10 13:40:34 -0700 (Wed, 10 Oct 2012)
> New Revision: 77806
> Trac: http://trac.enlightenment.org/e/changeset/77806
>
> Modified:
> trunk/efl/configure.ac trunk/efl/m4/efl_threads.m4
>
> Modified: trunk/efl/configure.ac
> ===
> --- trunk/efl/configure.ac 2012-10-10 20:32:35 UTC (rev 77805)
> +++ trunk/efl/configure.ac 2012-10-10 20:40:34 UTC (rev 77806)
> @@ -539,11 +539,11 @@
> EINA_CONFIGURE_HAVE_THREADS="#define EINA_HAVE_THREADS"
> AC_SUBST(EINA_CONFIGURE_HAVE_THREADS)
>
> -if test "x${efl_have_debug_threads}" = "xyes"; then
> +if test "$build_profile" = "dev"; then
> EINA_CONFIGURE_HAVE_DEBUG_THREADS="#define EINA_HAVE_DEBUG_THREADS"
> + AC_DEFINE([EFL_DEBUG_THREADS], [1], [Assert when forgot to call
> eina_threads_init])
> fi
> AC_SUBST(EINA_CONFIGURE_HAVE_DEBUG_THREADS)
> -AM_CONDITIONAL([EINA_DEBUG_THREADS], [test "x${efl_have_debug_threads}" =
> "xyes"])
>
> ### Modules
> EINA_CHECK_MODULE([chained-pool], [static], [chained pool])
> @@ -866,7 +866,6 @@
> echo " Thread Support...: ${efl_have_threads}"
> if test "${efl_have_threads}" = "POSIX" ; then
> echo "spinlock...: ${efl_have_posix_threads_spinlock}"
> -echo "debug usage: ${efl_have_debug_threads}"
> fi
> echo
> echo "Compilation: make (or gmake)"
>
> Modified: trunk/efl/m4/efl_threads.m4
> ===
> --- trunk/efl/m4/efl_threads.m4 2012-10-10 20:32:35 UTC (rev 77805)
> +++ trunk/efl/m4/efl_threads.m4 2012-10-10 20:40:34 UTC (rev 77806)
> @@ -117,19 +117,6 @@
> AC_DEFINE([EFL_HAVE_POSIX_THREADS_SPINLOCK], [1], [Define to mention that
> POSIX threads spinlocks are supported])
> fi
>
> -dnl Check debug threads
> -
> -_efl_enable_debug_threads="no"
> -AC_ARG_ENABLE([debug-threads],
> - [AC_HELP_STRING([--enable-debug-threads], [disable assert when you forgot
> to call eina_threads_init])],
> - [_efl_enable_debug_threads="${enableval}"])
> -
> -efl_have_debug_threads="no"
> -if test "x${_efl_have_posix_threads}" = "xyes" && test
> "x${_efl_enable_debug_threads}" = "xyes"; then
> - efl_have_debug_threads="yes"
> - AC_DEFINE([EFL_DEBUG_THREADS], [1], [Assert when forgot to call
> eina_threads_init])
> -fi
> -
> AS_IF([test "x$_efl_have_posix_threads" = "xyes" || test
> "x$_efl_have_win32_threads" = "xyes"],
> [$1],
> [m4_if([$2], [$2], [AC_MSG_ERROR([Threads are required.])])])
>
>
> --
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
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: . src/bin/eet
On Wed, Oct 10, 2012 at 11:15 PM, Enlightenment SVN wrote: > Log: > efl: eet binary is not optional anymore. > > it's pointless to have this and may cause problems or complex > configure.ac when we have libraries that use 'eet' during its compile > phase (like elementary generates its profile/configuration). except that it's completely useless to have it for, for example Windows CE or any other system on which we don't care about it Vincent > > > > Author: barbieri > Date: 2012-10-10 14:15:54 -0700 (Wed, 10 Oct 2012) > New Revision: 77815 > Trac: http://trac.enlightenment.org/e/changeset/77815 > > Modified: > trunk/efl/configure.ac trunk/efl/src/bin/eet/Makefile.am > > Modified: trunk/efl/configure.ac > === > --- trunk/efl/configure.ac 2012-10-10 21:11:14 UTC (rev 77814) > +++ trunk/efl/configure.ac 2012-10-10 21:15:54 UTC (rev 77815) > @@ -570,8 +570,6 @@ > > ### Additional options to configure > > -EFL_ENABLE_BIN([eet]) > - > AC_ARG_WITH([crypto], > [AC_HELP_STRING([--with-crypto=CRYPTO], > [use the predefined build crypto, one of: > > Modified: trunk/efl/src/bin/eet/Makefile.am > === > --- trunk/efl/src/bin/eet/Makefile.am 2012-10-10 21:11:14 UTC (rev 77814) > +++ trunk/efl/src/bin/eet/Makefile.am 2012-10-10 21:15:54 UTC (rev 77815) > @@ -16,8 +16,7 @@ > -I$(top_builddir)/src/lib/evil > endif > > -bin_PROGRAMS = @EET_PRG@ > -EXTRA_PROGRAMS = eet > +bin_PROGRAMS = eet > > eet_SOURCES = eet_main.c > eet_LDADD = \ > > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ 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: . src/lib/eina src/modules/eina/mp
On Wed, Oct 10, 2012 at 9:57 PM, Enlightenment SVN
wrote:
> Log:
> efl: simplify mempools, nuke some and make remaining statically built.
>
> Now we always build the following memory pools statically:
>- pass_through: calls malloc/free directly, useful to debug.
>- chained_pool: default for ages.
>- one_big: used by some embedded systems (should we remove?)
>
> Removed:
>- ememoa_fixed and ememoa_unknown: depends on a separate lib, not
> supported?
>- buddy: nobody uses it?
please let turran say if he wants buddy or not before nuking it..
Vincent
>
> NOTE: we do not need the src/modules/eina/mp/*/Makefile.am anymore
> since they are statically built. But I'll keep these and the
> references in src/modules/eina/mp/Makefile.am
>
>
>
> Author: barbieri
> Date: 2012-10-10 12:57:53 -0700 (Wed, 10 Oct 2012)
> New Revision: 77792
> Trac: http://trac.enlightenment.org/e/changeset/77792
>
> Removed:
> trunk/efl/src/modules/eina/mp/buddy/
> trunk/efl/src/modules/eina/mp/ememoa_fixed/
> trunk/efl/src/modules/eina/mp/ememoa_unknown/
> trunk/efl/src/modules/eina/mp/fixed_bitmap/
> Modified:
> trunk/efl/configure.ac trunk/efl/src/lib/eina/Makefile.am
> trunk/efl/src/lib/eina/eina_mempool.c trunk/efl/src/lib/eina/eina_mempool.h
> trunk/efl/src/modules/eina/mp/Makefile.am
>
> Modified: trunk/efl/configure.ac
> ===
> --- trunk/efl/configure.ac 2012-10-10 19:36:36 UTC (rev 77791)
> +++ trunk/efl/configure.ac 2012-10-10 19:57:53 UTC (rev 77792)
> @@ -343,23 +343,7 @@
> fi
>
> # Choose best memory pool
> -AC_ARG_ENABLE([default-mempool],
> - [AC_HELP_STRING([--enable-default-mempool], [Default memory allocator
> could be faster for some computer. @<:@default=disabled@:>@])],
> - [
> -if test "x${enableval}" = "xyes"; then
> - have_default_mempool="yes"
> -else
> - have_default_mempool="no"
> -fi
> - ],
> - [have_default_mempool="no"])
> -
> -AC_MSG_CHECKING([whether to use default mempool allocator])
> -AC_MSG_RESULT([${have_default_mempool}])
> -
> -if test "x${have_default_mempool}" = "xyes" ; then
> - EINA_CONFIGURE_DEFAULT_MEMPOOL="#define EINA_DEFAULT_MEMPOOL"
> -fi
> +EINA_CONFIGURE_DEFAULT_MEMPOOL="#define EINA_DEFAULT_MEMPOOL"
> AC_SUBST([EINA_CONFIGURE_DEFAULT_MEMPOOL])
>
> ### Checks for programs
> @@ -431,36 +415,11 @@
> fi
>
> ## Modules
> -
> -# Check ememoa memory pool library
> -
> -AC_ARG_ENABLE([ememoa],
> - [AC_HELP_STRING([--enable-ememoa], [build ememoa memory pool module
> @<:@default=yes@:>@])],
> - [
> -if test "x${enableval}" = "xyes" ; then
> - enable_ememoa="yes"
> -else
> - enable_ememoa="no"
> -fi
> - ],
> - [enable_ememoa="yes"])
> -
> -AC_MSG_CHECKING([whether to use ememoa for memory pool])
> -AC_MSG_RESULT([${enable_ememoa}])
> -
> -if test "x${enable_ememoa}" = "xyes" ; then
> - PKG_CHECK_MODULES([EMEMOA],
> - [ememoa >= 0.0.26 ],
> - [enable_ememoa="yes"],
> - [enable_ememoa="no"])
> -fi
> -
> if ! test "x${requirements_pc_deps_eina}" = "x" ; then
> PKG_CHECK_MODULES([EINA], [${requirements_pc_deps_eina}])
> fi
>
>
> -
> ## Examples
>
> # TODO: add once ecore-evas is merged:
> @@ -596,26 +555,11 @@
> AM_CONDITIONAL([EINA_ON_OFF_THREADS], [! test "x${efl_have_on_off_threads}"
> = "xno"])
>
> ### Modules
> +EINA_CHECK_MODULE([chained-pool], [static], [chained pool])
> +EINA_CHECK_MODULE([pass-through], [static], [pass through])
> +EINA_CHECK_MODULE([one-big],[static], [one big])
>
> -if test "x${have_default_mempool}" = "xyes" ; then
> - enable_chained_pool="no"
> - enable_pass_through="static"
> -else
> - enable_chained_pool="static"
> - enable_pass_through="no"
> -fi
>
> -enable_one_big="static"
> -
> -EINA_CHECK_MODULE([chained-pool], [${enable_chained_pool}], [chained pool])
> -EINA_CHECK_MODULE([ememoa-fixed], [${enable_ememoa}], [ememoa fixed])
> -EINA_CHECK_MODULE([ememoa-unknown], [${enable_ememoa}], [ememoa
> unknown])
> -EINA_CHECK_MODULE([fixed-bitmap], [no], [fixed bitmap])
> -EINA_CHECK_MODULE([pass-through], [${enable_pass_through}], [pass through])
> -EINA_CHECK_MODULE([buddy], [no], [buddy])
> -EINA_CHECK_MODULE([one-big],[${enable_one_big}], [one big])
> -
> -
> End of Eina
>
>
> @@ -912,11 +856,7 @@
> src/modules/eina/Makefile
> src/modules/eina/mp/Makefile
> src/modules/eina/mp/chained_pool/Makefile
> -src/modules/eina/mp/ememoa_fixed/Makefile
> -src/modules/eina/mp/ememoa_unknown/Makefile
> src/modules/eina/mp/pass_through/Makefile
> -src/modules/eina/mp/fixed_bitmap/Makefile
> -src/modules/eina/mp/buddy/Makefile
> src/modules/eina/mp/one_big/Makefile
> src/scripts/Makefile
> src/scripts/eina/Makefile
> @@ -966,15 +906,6 @@
> echo " File xattr...: ${efl_func_setxattr}"
> echo " shm_open.: ${efl_func_
Re: [E-devel] E SVN: barbieri IN trunk/efl: . src/lib/eet
On Wed, Oct 10, 2012 at 9:30 PM, Enlightenment SVN
wrote:
> Log:
> efl: remove option to enable old EET format.
>
> It's disabled. If user wants to enable, give
> -DEET_OLD_EET_FILE_FORMAT=1 to CFLAGS.
add that somewhere... otherwise nobody will remember. In README, at lease
Vincent
>
>
>
> Author: barbieri
> Date: 2012-10-10 12:30:17 -0700 (Wed, 10 Oct 2012)
> New Revision: 77790
> Trac: http://trac.enlightenment.org/e/changeset/77790
>
> Modified:
> trunk/efl/configure.ac trunk/efl/src/lib/eet/eet_lib.c
>
> Modified: trunk/efl/configure.ac
> ===
> --- trunk/efl/configure.ac 2012-10-10 19:26:56 UTC (rev 77789)
> +++ trunk/efl/configure.ac 2012-10-10 19:30:17 UTC (rev 77790)
> @@ -631,30 +631,6 @@
>
> EFL_ENABLE_BIN([eet])
>
> -# Old eet file format support
> -
> -AC_ARG_ENABLE(old-eet-file-format,
> - [AC_HELP_STRING(
> - [--disable-old-eet-file-format],
> - [disable old eet file format support @<:@default=enabled@:>@])],
> - [
> -if test "x${enableval}" = "xyes" ; then
> - old_eet_file_format="yes"
> -else
> - old_eet_file_format="no"
> -fi
> - ],
> - [old_eet_file_format="yes"])
> -
> -AC_MSG_CHECKING([whether to support old eet file format])
> -AC_MSG_RESULT([${old_eet_file_format}])
> -
> -if test "x${old_eet_file_format}" = "xyes" ; then
> - AC_DEFINE(EET_OLD_EET_FILE_FORMAT, 1, [support old eet file format])
> -else
> - AC_DEFINE(EET_OLD_EET_FILE_FORMAT, 0, [support old eet file format])
> -fi
> -
> AC_ARG_WITH([crypto],
> [AC_HELP_STRING([--with-crypto=CRYPTO],
> [use the predefined build crypto, one of:
> @@ -1024,8 +1000,6 @@
> echo
> echo " Secure layer.: ${build_crypto}"
> echo
> -echo " Old eet file format..: ${old_eet_file_format}"
> -echo
> echo " Tests: make check (Coverage:
> ${_efl_enable_coverage})"
> echo " Examples.: make examples"
> echo "installation...: make install-examples"
>
> Modified: trunk/efl/src/lib/eet/eet_lib.c
> ===
> --- trunk/efl/src/lib/eet/eet_lib.c 2012-10-10 19:26:56 UTC (rev 77789)
> +++ trunk/efl/src/lib/eet/eet_lib.c 2012-10-10 19:30:17 UTC (rev 77790)
> @@ -1042,7 +1042,7 @@
> return ef;
> }
>
> -#if EET_OLD_EET_FILE_FORMAT
> +#ifdef EET_OLD_EET_FILE_FORMAT
> static Eet_File *
> eet_internal_read1(Eet_File *ef)
> {
> @@ -1224,7 +1224,7 @@
> return ef;
> }
>
> -#endif /* if EET_OLD_EET_FILE_FORMAT */
> +#endif /* ifdef EET_OLD_EET_FILE_FORMAT */
>
> /*
> * this should only be called when the cache lock is already held
> @@ -1245,11 +1245,11 @@
>
> switch (ntohl(*data))
> {
> -#if EET_OLD_EET_FILE_FORMAT
> +#ifdef EET_OLD_EET_FILE_FORMAT
>case EET_MAGIC_FILE:
> return eet_internal_read1(ef);
>
> -#endif /* if EET_OLD_EET_FILE_FORMAT */
> +#endif /* ifdef EET_OLD_EET_FILE_FORMAT */
>case EET_MAGIC_FILE2:
> return eet_internal_read2(ef);
>
>
>
> --
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
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: . src/benchmarks src/bin src/examples src/lib src/tests
i've already stated that i do not want that, please revert
Gustavo : you told me that you wanted to take care of options, no other stuff
Vincent
On Wed, Oct 10, 2012 at 7:27 PM, Enlightenment SVN
wrote:
> Log:
> efl: eet and eo are now mandatory.
>
> I've reordered the build to be: eina -> eo -> eet as it make more sense.
>
>
>
> Author: barbieri
> Date: 2012-10-10 10:27:11 -0700 (Wed, 10 Oct 2012)
> New Revision: 77766
> Trac: http://trac.enlightenment.org/e/changeset/77766
>
> Modified:
> trunk/efl/Makefile.am trunk/efl/configure.ac
> trunk/efl/src/benchmarks/Makefile.am trunk/efl/src/bin/Makefile.am
> trunk/efl/src/examples/Makefile.am trunk/efl/src/lib/Makefile.am
> trunk/efl/src/tests/Makefile.am
>
> Modified: trunk/efl/Makefile.am
> ===
> --- trunk/efl/Makefile.am 2012-10-10 17:06:14 UTC (rev 77765)
> +++ trunk/efl/Makefile.am 2012-10-10 17:27:11 UTC (rev 77766)
> @@ -57,17 +57,12 @@
> pkgconfig_DATA += pc/evil.pc
> endif
>
> -pkgconfig_DATA += pc/eina.pc
> +pkgconfig_DATA += \
> +pc/eina.pc \
> +pc/eo.pc \
> +pc/eet.pc
>
> -if EFL_BUILD_EET
> -pkgconfig_DATA += pc/eet.pc
> -endif
>
> -if EFL_BUILD_EO
> -pkgconfig_DATA += pc/eo.pc
> -endif
> -
> -
> .PHONY: doc benchmark examples install-examples
>
> # Documentation
> @@ -100,12 +95,8 @@
> if EFL_ENABLE_COVERAGE
> @$(MAKE) $(AM_MAKEFLAGS) lcov-reset
> endif
> -if EFL_BUILD_EET
> @./src/tests/eet/eet_suite$(EXEEXT)
> -endif
> -if EFL_BUILD_EO
> @./src/tests/eo/eo_suite$(EXEEXT)
> -endif
> if EFL_ENABLE_COVERAGE
> @$(MAKE) $(AM_MAKEFLAGS) lcov-report
> endif
> @@ -117,9 +108,7 @@
> benchmark:
> @$(MAKE) $(AM_MAKEFLAGS) -C src benchmark
> @mkdir benchmark || true
> -if EFL_BUILD_EO
> @cd benchmark && ../src/benchmarks/eo/eo_bench$(EXEEXT) `date +%F_%s`
> -endif
>
> benchmark-e17:
> @$(MAKE) $(AM_MAKEFLAGS) -C src benchmark-e17
>
> Modified: trunk/efl/configure.ac
> ===
> --- trunk/efl/configure.ac 2012-10-10 17:06:14 UTC (rev 77765)
> +++ trunk/efl/configure.ac 2012-10-10 17:27:11 UTC (rev 77766)
> @@ -196,8 +196,6 @@
>
> Additional options to configure
>
> -EFL_ENABLE_LIB([eet], [yes])
> -EFL_ENABLE_LIB([eo], [yes])
>
>
> # Assert or fail.
> @@ -787,8 +785,6 @@
>
> efl_have_eet="no"
>
> -if test "x${efl_want_build_eet}" = "xyes" ; then
> -
> AC_MSG_NOTICE([Eet checks])
>
> ### Default values
> @@ -1136,8 +1132,6 @@
> efl_have_eet="yes"
> fi
>
> -fi
> -
> End of Eet
>
>
> @@ -1145,8 +1139,6 @@
>
> efl_have_eo="no"
>
> -if test "x${efl_want_build_eo}" = "xyes" ; then
> -
> AC_MSG_NOTICE([Eo checks])
>
> ### Default values
> @@ -1195,12 +1187,6 @@
>
> efl_have_eo="yes"
>
> -else
> -
> -AM_CONDITIONAL([EO_BUILD_EXAMPLE_EVAS], [false])
> -
> -fi
> -
> End of Eo
>
>
>
> Modified: trunk/efl/src/benchmarks/Makefile.am
> ===
> --- trunk/efl/src/benchmarks/Makefile.am2012-10-10 17:06:14 UTC (rev
> 77765)
> +++ trunk/efl/src/benchmarks/Makefile.am2012-10-10 17:27:11 UTC (rev
> 77766)
> @@ -6,9 +6,7 @@
>
> benchmark:
> @$(MAKE) $(AM_MAKEFLAGS) -C eina benchmark
> -if EFL_BUILD_EO
> @$(MAKE) $(AM_MAKEFLAGS) -C eo benchmark
> -endif
>
> benchmark-e17:
> @$(MAKE) $(AM_MAKEFLAGS) -C eina benchmark-e17
>
> Modified: trunk/efl/src/bin/Makefile.am
> ===
> --- trunk/efl/src/bin/Makefile.am 2012-10-10 17:06:14 UTC (rev 77765)
> +++ trunk/efl/src/bin/Makefile.am 2012-10-10 17:27:11 UTC (rev 77766)
> @@ -8,8 +8,4 @@
>
> endif
>
> -if EFL_BUILD_EET
> -
> SUBDIRS += eet
> -
> -endif
>
> Modified: trunk/efl/src/examples/Makefile.am
> ===
> --- trunk/efl/src/examples/Makefile.am 2012-10-10 17:06:14 UTC (rev 77765)
> +++ trunk/efl/src/examples/Makefile.am 2012-10-10 17:27:11 UTC (rev 77766)
> @@ -1,21 +1,13 @@
> MAINTAINERCLEANFILES = Makefile.in
>
> -SUBDIRS = eina eet eo
> +SUBDIRS = eina eo eet
>
> examples:
> @$(MAKE) $(AM_MAKEFLAGS) -C eina examples
> -if EFL_BUILD_EET
> - @$(MAKE) $(AM_MAKEFLAGS) -C eet examples
> -endif
> -if EFL_BUILD_EO
> @$(MAKE) $(AM_MAKEFLAGS) -C eo examples
> -endif
> + @$(MAKE) $(AM_MAKEFLAGS) -C eet examples
>
> install-examples:
> @$(MAKE) $(AM_MAKEFLAGS) -C eina install-examples
> -if EFL_BUILD_EET
> - @$(MAKE) $(AM_MAKEFLAGS) -C eet install-examples
> -endif
> -if EFL_BUILD_EO
> @$(MAKE) $(AM_MAKEFLAGS) -C eo install-examples
> -endif
> + @$(MAKE) $(AM_MAKEFLAGS) -C eet install-examples
>
> Modified: trunk/efl/src/lib/Makefile.am
> ===
> --- trunk/efl/src/lib/Makefile.am 2012-10-10 17:06:1
Re: [E-devel] efl tree
On Wed, 10 Oct 2012 10:39:34 -0300 Gustavo Sverzut Barbieri said: > On Wednesday, October 10, 2012, Carsten Haitzler wrote: > > > On Wed, 10 Oct 2012 09:15:32 -0300 Gustavo Sverzut Barbieri > > > said: > > > > > On Wednesday, October 10, 2012, Tom Hacohen wrote: > > > > > > > On 10/10/12 10:37, Stefan Schmidt wrote: > > > > > Magic checks, debug and log level left out here as they seem to be > > > > > handled by profiles. Should valgrind support also be handled with > > this? > > > > > > > > > > > > > I guess. > > > > > > > > > Unit tests, coverage and benchmark will be enabled for all libs at > > once > > > > > I suppose. > > > > > > > > > Unit tests and benchmarks should only build when you issue "make > > > > check/benchmark". Coverage is a bit more problematic because it > > requires > > > > you to recompile the sources. I'd love having a way to just make > > > > coverage and make it rebuild the sources that were built without > > > > coverage, but otherwise, we probably need an option. > > > > > > > > -- > > > > Tom. > > > > > > > > > Evas is a real beast when it comes to configure options. :) > > > > > > > > > > The first thing that jumps into my eye are the ARGB Conversion > > Options. > > > > > Having them all on by default would really be so much overhead? I > > mean > > > > > you don't use them it should be fine to just always build them. > > > > > > > > > > Image loaders are way more complicated sadly as we drag in > > dependencies > > > > > here. I would vote for making jpeg, png, gif, bmp, eet on by default. > > > > > > > > > > For the others we might need to see what libs distros ship in a > > default > > > > > installation so we can decide if we have a hard dep on these libs or > > not. > > > > > > > > > > That should clear things up a lot. (Yes, I left out engines here on > > > > > purpose. Don't wanted to fight over them :)) > > > > > > > > > > > > > I'd love to see fribidi and harfbuzz there by default, but tbh, I think > > > > some people would appreciate the speed improvements that come with > > > > ignoring the. > > > > > > > > > Make fribidi and harfbuzz mandatory, we've seen lots of bugs that happens > > > on one but not another system. Leave the old code there for those that > > want > > > to strip it in future, but plan to remove it later and simplify our code. > > > > fribidi - i agree with, but harfbuzz is a problem due to no releases and > > common > > brekage of the api at least in the past. it's also simply not packaged > > even for > > major distros like ubuntu. it sucks but this is one that i think has to > > stay an > > option. :( > > > Do as pango: copy it. They are the maintainers and they do it. One less > runtime linkage not going to do that for the merge. we have enough to do without copying wads of src in as well. this can be something for a later day, so for now it stays an option until that day. :) > > > We have MANY improvement spots in text that we could optimize (like > > fixing > > > the word cache and postponing all the stuff done in _text_set() to render > > > phase) so it pays off fribidi/harfbuzz > > > > agree - but there's a big problem with harfbuzz. > > > > > > > > > > -- > > > > Tom. > > > > > > > > > > > > > > > > > > -- > > > > Don't let slow site performance ruin your business. Deploy New Relic > > APM > > > > Deploy New Relic app performance management and know exactly > > > > what is happening inside your Ruby, Python, PHP, Java, and .NET app > > > > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > > > > http://p.sf.net/sfu/newrelic-dev2dev > > > > ___ > > > > enlightenment-devel mailing list > > > > enlightenment-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > -- > > > Gustavo Sverzut Barbieri > > > http://profusion.mobi embedded systems > > > -- > > > MSN: barbi...@gmail.com > > > Skype: gsbarbieri > > > Mobile: +55 (19) 9225-2202 > > > > > -- > > > Don't let slow site performance ruin your business. Deploy New Relic APM > > > Deploy New Relic app performance management and know exactly > > > what is happening inside your Ruby, Python, PHP, Java, and .NET app > > > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > > > http://p.sf.net/sfu/newrelic-dev2dev > > > ___ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi e
Re: [E-devel] efl tree
On Wed, 10 Oct 2012 21:52:30 +0200 Thomas Sachau said: > Tom Hacohen schrieb: > > On 10/10/12 11:11, Stefan Schmidt wrote: > >> Hello. > >> > >> On 10/10/12 10:04, Tom Hacohen wrote: > >>> On 10/10/12 11:00, Stefan Schmidt wrote: > Hello. > > On 10/10/12 09:50, David Seikel wrote: > > On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt > > wrote: > >> Image loaders are way more complicated sadly as we drag in > >> dependencies here. I would vote for making jpeg, png, gif, bmp, eet > >> on by default. > >> > >> For the others we might need to see what libs distros ship in a > >> default installation so we can decide if we have a hard dep on these > >> libs or not. > > > > Better would be to remove the options, but detect them at build time to > > see if they should be included. Things should never be hard > > dependencies, unless they actually are. > > I see that you don't want to have this for your embedded project. :) > > But I disagree here. Autodetection is even worse in the case for the > image loaders as your application will fail during runtime to load a > theme or display thumbnails, etc. In your strictly controlled env this > is not a problem as you can only blame yourself but in my opinion this > is a no-no for almost all other users. Thus I would vote against > autodetection and choose the hard deps carefully to fit the majority of > our users. > >>> > >>> I'm also against autodetection. I prefer strict option setting. But you > >>> want to have them (all?) on by default and just let people disable them > >>> if needed. > >> > >> This would defeat the original purpose of removing options, right? :) > >> > >> regards > >> Stefan Schmidt > >> > > > > I think the ideas is to remove useless options, not useful. :) > > I'm not really against it, I'm fine with automagically detecting stuff > > if packagers don't find this annoying, the real question is: do they? > > Of course they do. automagic does mean, that you cant control, what > actually happens, so you will never know, what a specific package will do. > > Just a basic example: > > Optional dependency installed, automagic package sees it, uses it, but > user/developer/packager does not notice it, later the optional > dependency gets removed. The result: broken automagic package and no way > to properly fix this. for someone doing rpm pkging... you should know that this wont happen because rpm does auto deps... it ldd's everything looking for deps. > In the end packagers would have to force require all optional > dependencies, so enabling all optional features, which is the same as > doing it right away within the build system, just more annoying and time > consuming for the packager. > > So either remove an option, force-disable or force-enable it for > everyone or give it a configure option to control the feature. Just dont > make it automagic without user control on the behaviour. > > > -- > > Thomas Sachau > Gentoo Linux Developer > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] efl single tree changes, need help!
Hi all,
As you may see I did a torrent of commits to efl single tree in order
to simplify its build and configuration as we discussed in many other
threads.
However the work is far from complete and I need your help: please
walk configure.ac and read the comments left with "TODO". Mostly what
I believe needs lots of improvements:
- Windows (and other platforms?) handling: while Linux/BSD is mostly
transparent the windows support is widely spread in both configure.ac
and Makefile.am. We better find a way to make it automatic or it will
be insanely painful to maintain. Likely we should create a set of
PLATFORM_LIBS, PLATFORM_CFLAGS... and always include those (instead of
Makefile.am: if HAVE_WINDOWS...
- Gnutls: do we need to keep the old support? I'd vote to bump
requirement and simplify configure.ac and the usage in eet.
- Handling of common system functions, headers and compile options.
There is a new set of macros that will take the libname as first
parameter, applying discovered bits to it. However most checks will be
used by more than one library, things like dirfd() or dlopen() are not
exclusive of EINA. Same for compiler flags such as -Wl,--as-needed.
Also it's not clear when these are actually namespaced and how. For
instance dlopen and dirfd shows on config.h as HAVE_DLOPEN and
HAVE_DIRFD.
- Handling of pkg-config of in-tree libraries. Right now we have some
mistakes that wouldn't let a clean system to build. For instance,
while building eet we PKG_CHECK_MODULES([EET],
[${requirements_pc_deps_eet}]), but requirements_pc_eet="eina >=
1.7.99 ${requirements_pc_eet}"... In other words we're checking eina
>= 1.7.99 from SYSTEM ($PKG_CONFIG_PATH, $PKG_CONFIG_LIBDIR).
- Need for requirements_libs_LIBNAME, requirements_libs_deps_LIBNAME
and requirements_pc_deps_LIBNAME... So easy to forget to set :-/ Maybe
add wrapper functions EFL_PKG_CHECK and similar that will
automatically append to these variables?
Please help! :-)
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
Tom Hacohen schrieb: > On 10/10/12 11:11, Stefan Schmidt wrote: >> Hello. >> >> On 10/10/12 10:04, Tom Hacohen wrote: >>> On 10/10/12 11:00, Stefan Schmidt wrote: Hello. On 10/10/12 09:50, David Seikel wrote: > On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt > wrote: >> Image loaders are way more complicated sadly as we drag in >> dependencies here. I would vote for making jpeg, png, gif, bmp, eet >> on by default. >> >> For the others we might need to see what libs distros ship in a >> default installation so we can decide if we have a hard dep on these >> libs or not. > > Better would be to remove the options, but detect them at build time to > see if they should be included. Things should never be hard > dependencies, unless they actually are. I see that you don't want to have this for your embedded project. :) But I disagree here. Autodetection is even worse in the case for the image loaders as your application will fail during runtime to load a theme or display thumbnails, etc. In your strictly controlled env this is not a problem as you can only blame yourself but in my opinion this is a no-no for almost all other users. Thus I would vote against autodetection and choose the hard deps carefully to fit the majority of our users. >>> >>> I'm also against autodetection. I prefer strict option setting. But you >>> want to have them (all?) on by default and just let people disable them >>> if needed. >> >> This would defeat the original purpose of removing options, right? :) >> >> regards >> Stefan Schmidt >> > > I think the ideas is to remove useless options, not useful. :) > I'm not really against it, I'm fine with automagically detecting stuff > if packagers don't find this annoying, the real question is: do they? Of course they do. automagic does mean, that you cant control, what actually happens, so you will never know, what a specific package will do. Just a basic example: Optional dependency installed, automagic package sees it, uses it, but user/developer/packager does not notice it, later the optional dependency gets removed. The result: broken automagic package and no way to properly fix this. In the end packagers would have to force require all optional dependencies, so enabling all optional features, which is the same as doing it right away within the build system, just more annoying and time consuming for the packager. So either remove an option, force-disable or force-enable it for everyone or give it a configure option to control the feature. Just dont make it automagic without user control on the behaviour. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On Wed, Oct 10, 2012 at 1:00 PM, Vincent Torri wrote: > On Wed, Oct 10, 2012 at 4:57 PM, Gustavo Sverzut Barbieri > wrote: >> On Wed, Oct 10, 2012 at 10:46 AM, Vincent Torri >> wrote: >>> On Wed, Oct 10, 2012 at 3:39 PM, Gustavo Sverzut Barbieri >>> wrote: On Wednesday, October 10, 2012, Carsten Haitzler wrote: > On Wed, 10 Oct 2012 09:15:32 -0300 Gustavo Sverzut Barbieri > > said: > > > On Wednesday, October 10, 2012, Tom Hacohen wrote: > > > > > On 10/10/12 10:37, Stefan Schmidt wrote: > > > > Magic checks, debug and log level left out here as they seem to be > > > > handled by profiles. Should valgrind support also be handled with > this? > > > > > > > > > > I guess. > > > > > > > Unit tests, coverage and benchmark will be enabled for all libs at > once > > > > I suppose. > > > > > > > Unit tests and benchmarks should only build when you issue "make > > > check/benchmark". Coverage is a bit more problematic because it > requires > > > you to recompile the sources. I'd love having a way to just make > > > coverage and make it rebuild the sources that were built without > > > coverage, but otherwise, we probably need an option. > > > > > > -- > > > Tom. > > > > > > > Evas is a real beast when it comes to configure options. :) > > > > > > > > The first thing that jumps into my eye are the ARGB Conversion > Options. > > > > Having them all on by default would really be so much overhead? I > mean > > > > you don't use them it should be fine to just always build them. > > > > > > > > Image loaders are way more complicated sadly as we drag in > dependencies > > > > here. I would vote for making jpeg, png, gif, bmp, eet on by > > > > default. > > > > > > > > For the others we might need to see what libs distros ship in a > default > > > > installation so we can decide if we have a hard dep on these libs or > not. > > > > > > > > That should clear things up a lot. (Yes, I left out engines here on > > > > purpose. Don't wanted to fight over them :)) > > > > > > > > > > I'd love to see fribidi and harfbuzz there by default, but tbh, I > > > think > > > some people would appreciate the speed improvements that come with > > > ignoring the. > > > > > > Make fribidi and harfbuzz mandatory, we've seen lots of bugs that > > happens > > on one but not another system. Leave the old code there for those that > want > > to strip it in future, but plan to remove it later and simplify our > > code. > > fribidi - i agree with, but harfbuzz is a problem due to no releases and > common > brekage of the api at least in the past. it's also simply not packaged > even for > major distros like ubuntu. it sucks but this is one that i think has to > stay an > option. :( Do as pango: copy it. They are the maintainers and they do it. One less runtime linkage >>> >>> that means that we must not forget to update it regularly. We also >>> have to do that for lz4 in eet. >> >> unless there is a security bug, you just need to update it whenever >> you have a bug or want a feature. Otherwise it can stay like that >> forever. > > not only security bug. There might be important bugs. So we can search > in the EFL code some bug that are actually in a dep included in our > tree and which was not updated... I think it's doable... in git you could even add as a subproject, though I'm no fan of this. Not only pango does this kind of thing. Node, bluez, connman, webkit do as well Lucas De Marchi -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On Wed, Oct 10, 2012 at 4:57 PM, Gustavo Sverzut Barbieri wrote: > On Wed, Oct 10, 2012 at 10:46 AM, Vincent Torri > wrote: >> On Wed, Oct 10, 2012 at 3:39 PM, Gustavo Sverzut Barbieri >> wrote: >>> On Wednesday, October 10, 2012, Carsten Haitzler wrote: >>> On Wed, 10 Oct 2012 09:15:32 -0300 Gustavo Sverzut Barbieri > said: > On Wednesday, October 10, 2012, Tom Hacohen wrote: > > > On 10/10/12 10:37, Stefan Schmidt wrote: > > > Magic checks, debug and log level left out here as they seem to be > > > handled by profiles. Should valgrind support also be handled with this? > > > > > > > I guess. > > > > > Unit tests, coverage and benchmark will be enabled for all libs at once > > > I suppose. > > > > > Unit tests and benchmarks should only build when you issue "make > > check/benchmark". Coverage is a bit more problematic because it requires > > you to recompile the sources. I'd love having a way to just make > > coverage and make it rebuild the sources that were built without > > coverage, but otherwise, we probably need an option. > > > > -- > > Tom. > > > > > Evas is a real beast when it comes to configure options. :) > > > > > > The first thing that jumps into my eye are the ARGB Conversion Options. > > > Having them all on by default would really be so much overhead? I mean > > > you don't use them it should be fine to just always build them. > > > > > > Image loaders are way more complicated sadly as we drag in dependencies > > > here. I would vote for making jpeg, png, gif, bmp, eet on by default. > > > > > > For the others we might need to see what libs distros ship in a default > > > installation so we can decide if we have a hard dep on these libs or not. > > > > > > That should clear things up a lot. (Yes, I left out engines here on > > > purpose. Don't wanted to fight over them :)) > > > > > > > I'd love to see fribidi and harfbuzz there by default, but tbh, I think > > some people would appreciate the speed improvements that come with > > ignoring the. > > > Make fribidi and harfbuzz mandatory, we've seen lots of bugs that happens > on one but not another system. Leave the old code there for those that want > to strip it in future, but plan to remove it later and simplify our code. fribidi - i agree with, but harfbuzz is a problem due to no releases and common brekage of the api at least in the past. it's also simply not packaged even for major distros like ubuntu. it sucks but this is one that i think has to stay an option. :( >>> >>> >>> Do as pango: copy it. They are the maintainers and they do it. One less >>> runtime linkage >> >> that means that we must not forget to update it regularly. We also >> have to do that for lz4 in eet. > > unless there is a security bug, you just need to update it whenever > you have a bug or want a feature. Otherwise it can stay like that > forever. not only security bug. There might be important bugs. So we can search in the EFL code some bug that are actually in a dep included in our tree and which was not updated... Vincent -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On Wed, Oct 10, 2012 at 10:46 AM, Vincent Torri wrote: > On Wed, Oct 10, 2012 at 3:39 PM, Gustavo Sverzut Barbieri > wrote: >> On Wednesday, October 10, 2012, Carsten Haitzler wrote: >> >>> On Wed, 10 Oct 2012 09:15:32 -0300 Gustavo Sverzut Barbieri >>> > said: >>> >>> > On Wednesday, October 10, 2012, Tom Hacohen wrote: >>> > >>> > > On 10/10/12 10:37, Stefan Schmidt wrote: >>> > > > Magic checks, debug and log level left out here as they seem to be >>> > > > handled by profiles. Should valgrind support also be handled with >>> this? >>> > > > >>> > > >>> > > I guess. >>> > > >>> > > > Unit tests, coverage and benchmark will be enabled for all libs at >>> once >>> > > > I suppose. >>> > > > >>> > > Unit tests and benchmarks should only build when you issue "make >>> > > check/benchmark". Coverage is a bit more problematic because it >>> requires >>> > > you to recompile the sources. I'd love having a way to just make >>> > > coverage and make it rebuild the sources that were built without >>> > > coverage, but otherwise, we probably need an option. >>> > > >>> > > -- >>> > > Tom. >>> > > >>> > > > Evas is a real beast when it comes to configure options. :) >>> > > > >>> > > > The first thing that jumps into my eye are the ARGB Conversion >>> Options. >>> > > > Having them all on by default would really be so much overhead? I >>> mean >>> > > > you don't use them it should be fine to just always build them. >>> > > > >>> > > > Image loaders are way more complicated sadly as we drag in >>> dependencies >>> > > > here. I would vote for making jpeg, png, gif, bmp, eet on by default. >>> > > > >>> > > > For the others we might need to see what libs distros ship in a >>> default >>> > > > installation so we can decide if we have a hard dep on these libs or >>> not. >>> > > > >>> > > > That should clear things up a lot. (Yes, I left out engines here on >>> > > > purpose. Don't wanted to fight over them :)) >>> > > > >>> > > >>> > > I'd love to see fribidi and harfbuzz there by default, but tbh, I think >>> > > some people would appreciate the speed improvements that come with >>> > > ignoring the. >>> > >>> > >>> > Make fribidi and harfbuzz mandatory, we've seen lots of bugs that happens >>> > on one but not another system. Leave the old code there for those that >>> want >>> > to strip it in future, but plan to remove it later and simplify our code. >>> >>> fribidi - i agree with, but harfbuzz is a problem due to no releases and >>> common >>> brekage of the api at least in the past. it's also simply not packaged >>> even for >>> major distros like ubuntu. it sucks but this is one that i think has to >>> stay an >>> option. :( >> >> >> Do as pango: copy it. They are the maintainers and they do it. One less >> runtime linkage > > that means that we must not forget to update it regularly. We also > have to do that for lz4 in eet. unless there is a security bug, you just need to update it whenever you have a bug or want a feature. Otherwise it can stay like that forever. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On Wed, Oct 10, 2012 at 3:39 PM, Gustavo Sverzut Barbieri wrote: > On Wednesday, October 10, 2012, Carsten Haitzler wrote: > >> On Wed, 10 Oct 2012 09:15:32 -0300 Gustavo Sverzut Barbieri >> > said: >> >> > On Wednesday, October 10, 2012, Tom Hacohen wrote: >> > >> > > On 10/10/12 10:37, Stefan Schmidt wrote: >> > > > Magic checks, debug and log level left out here as they seem to be >> > > > handled by profiles. Should valgrind support also be handled with >> this? >> > > > >> > > >> > > I guess. >> > > >> > > > Unit tests, coverage and benchmark will be enabled for all libs at >> once >> > > > I suppose. >> > > > >> > > Unit tests and benchmarks should only build when you issue "make >> > > check/benchmark". Coverage is a bit more problematic because it >> requires >> > > you to recompile the sources. I'd love having a way to just make >> > > coverage and make it rebuild the sources that were built without >> > > coverage, but otherwise, we probably need an option. >> > > >> > > -- >> > > Tom. >> > > >> > > > Evas is a real beast when it comes to configure options. :) >> > > > >> > > > The first thing that jumps into my eye are the ARGB Conversion >> Options. >> > > > Having them all on by default would really be so much overhead? I >> mean >> > > > you don't use them it should be fine to just always build them. >> > > > >> > > > Image loaders are way more complicated sadly as we drag in >> dependencies >> > > > here. I would vote for making jpeg, png, gif, bmp, eet on by default. >> > > > >> > > > For the others we might need to see what libs distros ship in a >> default >> > > > installation so we can decide if we have a hard dep on these libs or >> not. >> > > > >> > > > That should clear things up a lot. (Yes, I left out engines here on >> > > > purpose. Don't wanted to fight over them :)) >> > > > >> > > >> > > I'd love to see fribidi and harfbuzz there by default, but tbh, I think >> > > some people would appreciate the speed improvements that come with >> > > ignoring the. >> > >> > >> > Make fribidi and harfbuzz mandatory, we've seen lots of bugs that happens >> > on one but not another system. Leave the old code there for those that >> want >> > to strip it in future, but plan to remove it later and simplify our code. >> >> fribidi - i agree with, but harfbuzz is a problem due to no releases and >> common >> brekage of the api at least in the past. it's also simply not packaged >> even for >> major distros like ubuntu. it sucks but this is one that i think has to >> stay an >> option. :( > > > Do as pango: copy it. They are the maintainers and they do it. One less > runtime linkage that means that we must not forget to update it regularly. We also have to do that for lz4 in eet. Vincent -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On Wednesday, October 10, 2012, Carsten Haitzler wrote: > On Wed, 10 Oct 2012 09:15:32 -0300 Gustavo Sverzut Barbieri > > said: > > > On Wednesday, October 10, 2012, Tom Hacohen wrote: > > > > > On 10/10/12 10:37, Stefan Schmidt wrote: > > > > Magic checks, debug and log level left out here as they seem to be > > > > handled by profiles. Should valgrind support also be handled with > this? > > > > > > > > > > I guess. > > > > > > > Unit tests, coverage and benchmark will be enabled for all libs at > once > > > > I suppose. > > > > > > > Unit tests and benchmarks should only build when you issue "make > > > check/benchmark". Coverage is a bit more problematic because it > requires > > > you to recompile the sources. I'd love having a way to just make > > > coverage and make it rebuild the sources that were built without > > > coverage, but otherwise, we probably need an option. > > > > > > -- > > > Tom. > > > > > > > Evas is a real beast when it comes to configure options. :) > > > > > > > > The first thing that jumps into my eye are the ARGB Conversion > Options. > > > > Having them all on by default would really be so much overhead? I > mean > > > > you don't use them it should be fine to just always build them. > > > > > > > > Image loaders are way more complicated sadly as we drag in > dependencies > > > > here. I would vote for making jpeg, png, gif, bmp, eet on by default. > > > > > > > > For the others we might need to see what libs distros ship in a > default > > > > installation so we can decide if we have a hard dep on these libs or > not. > > > > > > > > That should clear things up a lot. (Yes, I left out engines here on > > > > purpose. Don't wanted to fight over them :)) > > > > > > > > > > I'd love to see fribidi and harfbuzz there by default, but tbh, I think > > > some people would appreciate the speed improvements that come with > > > ignoring the. > > > > > > Make fribidi and harfbuzz mandatory, we've seen lots of bugs that happens > > on one but not another system. Leave the old code there for those that > want > > to strip it in future, but plan to remove it later and simplify our code. > > fribidi - i agree with, but harfbuzz is a problem due to no releases and > common > brekage of the api at least in the past. it's also simply not packaged > even for > major distros like ubuntu. it sucks but this is one that i think has to > stay an > option. :( Do as pango: copy it. They are the maintainers and they do it. One less runtime linkage > > > We have MANY improvement spots in text that we could optimize (like > fixing > > the word cache and postponing all the stuff done in _text_set() to render > > phase) so it pays off fribidi/harfbuzz > > agree - but there's a big problem with harfbuzz. > > > > > > > -- > > > Tom. > > > > > > > > > > > > > -- > > > Don't let slow site performance ruin your business. Deploy New Relic > APM > > > Deploy New Relic app performance management and know exactly > > > what is happening inside your Ruby, Python, PHP, Java, and .NET app > > > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > > > http://p.sf.net/sfu/newrelic-dev2dev > > > ___ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > Gustavo Sverzut Barbieri > > http://profusion.mobi embedded systems > > -- > > MSN: barbi...@gmail.com > > Skype: gsbarbieri > > Mobile: +55 (19) 9225-2202 > > > -- > > Don't let slow site performance ruin your business. Deploy New Relic APM > > Deploy New Relic app performance management and know exactly > > what is happening inside your Ruby, Python, PHP, Java, and .NET app > > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > > http://p.sf.net/sfu/newrelic-dev2dev > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2
Re: [E-devel] efl tree
On Wed, Oct 10, 2012 at 2:54 PM, Carsten Haitzler wrote: > On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt > said: > >> Hello. >> >> On 10/10/12 08:12, Carsten Haitzler (The Rasterman) wrote: >> > >> > what i want is for everyone please to test the efl tree and look at >> > configure options and find things to clean up/remove/whatever. i already >> > think we need to remove much more. >> >> Magic checks, debug and log level left out here as they seem to be >> handled by profiles. Should valgrind support also be handled with this? >> >> Unit tests, coverage and benchmark will be enabled for all libs at once >> I suppose. >> >> Eina: >> - Remove threads configure option (on by default) > > i already sent a mail about a lot of these about 2 weeks back. :) if there is an option, then i have forgotten to removed it. Currently, it's auto detected. things to do: 1) remove option is it's still there 2) make threads not optional (configure fails if no thread support is found, requested by raster) 3) as 2) is valid, then remove eina_inline_lock_void.x file >> - Remove mempool configure options >> - For Iconv, dirfd, xattr and shm_open I would also think remove the >> configure option and set on by default. But I'm surely not seeing all >> implications for these and have no hard feelings here. :) there is an option to explicitely set the iconv library name. I remove it ? >> >> Eet: >> - GnuTLS might need to stay. My feelings here are that not enough people >> use this feature to justice the overhead of the default linkage with >> gnutls. But we could at least have one option instead of cipher and >> signature. > > th only thing here to consider is removing gnutls support entirely - but here > comes the catch. some distros refuse to use openssl because its "non-free" as > technically its licensing is claimed to be "incompatible with gpl" or > something. :( and it should be fixed as, on windows, because of the libgcrypt stuff horror, it does not compile and I have to disable the secure layer. Maybe this part of the code should be rewritten, using different files for gnutls and openssl, insteadd of plenty of #ifdef >> - Remove old eet file format option (on by default) > > not until 2.0 :( > >> > what we also need to do is strip down configure options for evas, and ecore >> > and the rest of efl where needed, so feel free to look at that. i intent to >> > poke around evas soon., but the current efl tree needs yet more options >> > nuked imho. :) >> >> Evas is a real beast when it comes to configure options. :) > > yes. i plan to nuke most of them. before the merge, please >> The first thing that jumps into my eye are the ARGB Conversion Options. >> Having them all on by default would really be so much overhead? I mean >> you don't use them it should be fine to just always build them. > > that was me being anal about evas being really small for embedded - but evas > is > now much bigger and it makes little sense to have only some - my plan is to > enable all of them. the only issue is dither mask as the 128x128 dither mask > does add a fair chunk of library file size and is slower than ordered or line > dither. i will keep this - at least for now. > >> Image loaders are way more complicated sadly as we drag in dependencies >> here. I would vote for making jpeg, png, gif, bmp, eet on by default. > > right now all loaders are auto or on by default. loaders with no dependencies > i > plan on making always on - no option to turn them off at all (you don't want > them then delete the module files after install). bmp has no deps so its one > of > these always on ones. what about making even static for jpeg and png at least (jpeg is already a hard dep of eet anyway and png is uber-common) ? Don't know for eet one. >> For the others we might need to see what libs distros ship in a default >> installation so we can decide if we have a hard dep on these libs or not. > > jpeg can be on by default - same with eet. in fact no option to turn off. eet > needs jpeg - no option. i think i'll make png a hard-dep too. the rest that > have deps will have to be like they are now. > >> That should clear things up a lot. (Yes, I left out engines here on >> purpose. Don't wanted to fight over them :)) > Vincent -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ 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/ecore: . src/lib/ecore_x/xcb src/lib/ecore_x/xlib
On Wed, 10 Oct 2012 14:54:09 +0200 Sebastian Dransfeld
said:
ooh u're right. oops. good catch seb! tnx!
> On 10/10/2012 11:17 AM, Enlightenment SVN wrote:
> > Log:
> > From: Michal Pakula vel Rutka
> >Subject: [E-devel] [Patch] [Ecore] Allow to send SelectionNotify event
> >if there is no data from XGetWindowProperty.
> >
> >The issue I want to fix is that elementary clipboard does not return
> >paste callback if selection does not contain any data.
> >Currently when ecore_x_window_prop_property_get function is called
> >asking for AnyProperty it returns 0 if there is no data (number of
> >items stored equals 0). This causes ecore_x_event_handle_selection
> >_notify to exit before SelectionNotify event is added and eventually
> >elementary paste callback is not fired.
> >My patch removes this condition and changes behaviour of this function
> >by allowing to add SelectionNotify event even if data returned is empty.
> >
> >
> >
> > Author: raster
> > Date: 2012-10-10 02:17:21 -0700 (Wed, 10 Oct 2012)
> > New Revision: 77732
> > Trac: http://trac.enlightenment.org/e/changeset/77732
> >
>
> > Modified: trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_selection.c
> > ===
> > --- trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_selection.c 2012-10-10
> > 09:15:16 UTC (rev 77731) +++
> > trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_selection.c 2012-10-10
> > 09:17:21 UTC (rev 77732) @@ -748,7 +748,7 @@ sel = calloc(1, sizeof
> > (Ecore_X_Selection_Data_Text)); if (!sel) return NULL;
> >
> > - if (_data[size - 1])
> > + if (data && data[size - 1])
> >{
> > size++;
> > t = realloc(_data, size);
> > @@ -790,7 +790,7 @@
> >
> > ECORE_XCB_SELECTION_DATA(sel)->free =
> > _ecore_xcb_selection_data_files_free;
> >
> > - if (_data[size - 1])
> > + if (data && data[size - 1])
> >{
> > size++;
>
> Sure this shouldn't still be _data?
>
> S.
>
>
> --
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt said: > Hello. > > On 10/10/12 08:12, Carsten Haitzler (The Rasterman) wrote: > > > > what i want is for everyone please to test the efl tree and look at > > configure options and find things to clean up/remove/whatever. i already > > think we need to remove much more. > > Magic checks, debug and log level left out here as they seem to be > handled by profiles. Should valgrind support also be handled with this? > > Unit tests, coverage and benchmark will be enabled for all libs at once > I suppose. > > Eina: > - Remove threads configure option (on by default) i already sent a mail about a lot of these about 2 weeks back. :) > - Remove mempool configure options > - For Iconv, dirfd, xattr and shm_open I would also think remove the > configure option and set on by default. But I'm surely not seeing all > implications for these and have no hard feelings here. :) > > Eet: > - GnuTLS might need to stay. My feelings here are that not enough people > use this feature to justice the overhead of the default linkage with > gnutls. But we could at least have one option instead of cipher and > signature. th only thing here to consider is removing gnutls support entirely - but here comes the catch. some distros refuse to use openssl because its "non-free" as technically its licensing is claimed to be "incompatible with gpl" or something. :( > - Remove old eet file format option (on by default) not until 2.0 :( > > what we also need to do is strip down configure options for evas, and ecore > > and the rest of efl where needed, so feel free to look at that. i intent to > > poke around evas soon., but the current efl tree needs yet more options > > nuked imho. :) > > Evas is a real beast when it comes to configure options. :) yes. i plan to nuke most of them. > The first thing that jumps into my eye are the ARGB Conversion Options. > Having them all on by default would really be so much overhead? I mean > you don't use them it should be fine to just always build them. that was me being anal about evas being really small for embedded - but evas is now much bigger and it makes little sense to have only some - my plan is to enable all of them. the only issue is dither mask as the 128x128 dither mask does add a fair chunk of library file size and is slower than ordered or line dither. i will keep this - at least for now. > Image loaders are way more complicated sadly as we drag in dependencies > here. I would vote for making jpeg, png, gif, bmp, eet on by default. right now all loaders are auto or on by default. loaders with no dependencies i plan on making always on - no option to turn them off at all (you don't want them then delete the module files after install). bmp has no deps so its one of these always on ones. > For the others we might need to see what libs distros ship in a default > installation so we can decide if we have a hard dep on these libs or not. jpeg can be on by default - same with eet. in fact no option to turn off. eet needs jpeg - no option. i think i'll make png a hard-dep too. the rest that have deps will have to be like they are now. > That should clear things up a lot. (Yes, I left out engines here on > purpose. Don't wanted to fight over them :)) i think engines will stay as they are now. :) > regards > Stefan Schmidt > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On Wed, 10 Oct 2012 10:51:19 +0100 Stefan Schmidt said: > Hello. > > On 10/10/12 10:40, David Seikel wrote: > > On Wed, 10 Oct 2012 10:33:30 +0100 Stefan Schmidt > > wrote: > > > >> On 10/10/12 10:17, David Seikel wrote: > >>> On Wed, 10 Oct 2012 10:00:54 +0100 Stefan Schmidt > >>> wrote: > > On 10/10/12 09:50, David Seikel wrote: > > On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt > > wrote: > >>> > But I disagree here. Autodetection is even worse in the case for > the image loaders as your application will fail during runtime to > load a theme or display thumbnails, etc. In your strictly > controlled env this is not a problem as you can only blame > yourself but in my opinion this is a no-no for almost all other > users. Thus I would vote against autodetection and choose the hard > deps carefully to fit the majority of our users. > >>> > >>> I suspect packagers would rather have it my way as well. Less work > >>> for them to do if it just detects what needs to be built. They > >>> also have strictly controlled environments. Then they only have to > >>> worry about making sure the dependencies are there, and not have to > >>> worry about figuring out more options as well. Which is their job. > >> > >> I did some packaging for embedded stuff and I hated it. But it seems > >> we both did not do packaging for desktop distros (correct me if I'm > >> wrong for you here). > > > > Well, since you asked, I have done desktop distro packaging of E17 > > professionally in the past. > > Fair enough. :) > > > In the end, it's rasters plans on this that matter more than our > > opinions, coz I suspect he has some. B-) > > He always has. He just wants all his minions to poke around before doing > what he plans to.;) i listen. a lot of the plans are the result of years of people bitching etc. some things as u say are going to become hard no-option deps. not even a --disable. patch the src if u are that interested. but that means eet, png, jpeg for loaders. loaders with no deps will also be always on no option to disable too. those with deps i am tempted to leave as-is right now - ie auto-enabled if deps found. making them deps u have to --disable is i think a bit much. they also are extra ones we can live without (gif, tiff, esvg, edb, webp). i actually will remove the edb loader - really pointless. so we're down to 4 loaders that need external deps that we dont provide. i think thats simple enough. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On Wed, 10 Oct 2012 09:15:32 -0300 Gustavo Sverzut Barbieri said: > On Wednesday, October 10, 2012, Tom Hacohen wrote: > > > On 10/10/12 10:37, Stefan Schmidt wrote: > > > Magic checks, debug and log level left out here as they seem to be > > > handled by profiles. Should valgrind support also be handled with this? > > > > > > > I guess. > > > > > Unit tests, coverage and benchmark will be enabled for all libs at once > > > I suppose. > > > > > Unit tests and benchmarks should only build when you issue "make > > check/benchmark". Coverage is a bit more problematic because it requires > > you to recompile the sources. I'd love having a way to just make > > coverage and make it rebuild the sources that were built without > > coverage, but otherwise, we probably need an option. > > > > -- > > Tom. > > > > > Evas is a real beast when it comes to configure options. :) > > > > > > The first thing that jumps into my eye are the ARGB Conversion Options. > > > Having them all on by default would really be so much overhead? I mean > > > you don't use them it should be fine to just always build them. > > > > > > Image loaders are way more complicated sadly as we drag in dependencies > > > here. I would vote for making jpeg, png, gif, bmp, eet on by default. > > > > > > For the others we might need to see what libs distros ship in a default > > > installation so we can decide if we have a hard dep on these libs or not. > > > > > > That should clear things up a lot. (Yes, I left out engines here on > > > purpose. Don't wanted to fight over them :)) > > > > > > > I'd love to see fribidi and harfbuzz there by default, but tbh, I think > > some people would appreciate the speed improvements that come with > > ignoring the. > > > Make fribidi and harfbuzz mandatory, we've seen lots of bugs that happens > on one but not another system. Leave the old code there for those that want > to strip it in future, but plan to remove it later and simplify our code. fribidi - i agree with, but harfbuzz is a problem due to no releases and common brekage of the api at least in the past. it's also simply not packaged even for major distros like ubuntu. it sucks but this is one that i think has to stay an option. :( > We have MANY improvement spots in text that we could optimize (like fixing > the word cache and postponing all the stuff done in _text_set() to render > phase) so it pays off fribidi/harfbuzz agree - but there's a big problem with harfbuzz. > > > > -- > > Tom. > > > > > > > > -- > > Don't let slow site performance ruin your business. Deploy New Relic APM > > Deploy New Relic app performance management and know exactly > > what is happening inside your Ruby, Python, PHP, Java, and .NET app > > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > > http://p.sf.net/sfu/newrelic-dev2dev > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ 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/ecore: . src/lib/ecore_x/xcb src/lib/ecore_x/xlib
On 10/10/2012 11:17 AM, Enlightenment SVN wrote:
> Log:
> From: Michal Pakula vel Rutka
>Subject: [E-devel] [Patch] [Ecore] Allow to send SelectionNotify event
>if there is no data from XGetWindowProperty.
>
>The issue I want to fix is that elementary clipboard does not return
>paste callback if selection does not contain any data.
>Currently when ecore_x_window_prop_property_get function is called
>asking for AnyProperty it returns 0 if there is no data (number of
>items stored equals 0). This causes ecore_x_event_handle_selection
>_notify to exit before SelectionNotify event is added and eventually
>elementary paste callback is not fired.
>My patch removes this condition and changes behaviour of this function
>by allowing to add SelectionNotify event even if data returned is empty.
>
>
>
> Author: raster
> Date: 2012-10-10 02:17:21 -0700 (Wed, 10 Oct 2012)
> New Revision: 77732
> Trac: http://trac.enlightenment.org/e/changeset/77732
>
> Modified: trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_selection.c
> ===
> --- trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_selection.c 2012-10-10
> 09:15:16 UTC (rev 77731)
> +++ trunk/ecore/src/lib/ecore_x/xcb/ecore_xcb_selection.c 2012-10-10
> 09:17:21 UTC (rev 77732)
> @@ -748,7 +748,7 @@
> sel = calloc(1, sizeof(Ecore_X_Selection_Data_Text));
> if (!sel) return NULL;
>
> - if (_data[size - 1])
> + if (data && data[size - 1])
>{
> size++;
> t = realloc(_data, size);
> @@ -790,7 +790,7 @@
>
> ECORE_XCB_SELECTION_DATA(sel)->free =
> _ecore_xcb_selection_data_files_free;
>
> - if (_data[size - 1])
> + if (data && data[size - 1])
>{
> size++;
Sure this shouldn't still be _data?
S.
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch][Elementary] Map: Remove unnecessary code & Add prevent code
patch commited, thx ! 2012/10/9 Bluezery > Dear all, > > This patch remove unneeded code & add some prevent code. > Please review this patch. > > -- > BRs, > Kim. > > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- Michaël Bouchaud (yoz) -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Configure profiles for e's source
Bd to release what we don't test in dev.
I'm also against "fast". It will not work, really things will crash and
until we make sure that doesn't crash for our apps.
If you want dev x release make sure this is just CFLAGS (NDEBUG, -Wall
-Wextra -Wshadow), not features like disable checks.
What about the features that impact deps? Well have them in parallel?
On Wednesday, October 10, 2012, Tom Hacohen wrote:
> Dears,
>
> Here's a summary of a discussion between raster, Vincent and I on IRC:
> We'd like to have 4 configure profiles for e (+efl)'s source. You'd have
> a default profile set for trunk ("dev") and a default one for branches
> ("release") and obviously you'd be able to switch between them.
>
> The profiles we thought about are:
> "fast" - magic checks off, logging is off, and NDEBUG is set.
> "release" (default in release branches) - magic checks are on, log level
> is set to errors and above, NDEBUG is set.
> "dev" - magic check on, magic abort on, logging is set to warnings and
> above, NDEBUG is not set.
> "debug" - magic check on, magic abort on, logging is set to debug and
> above, NDEBUG is not set.
>
> What do you guys think?
>
> --
> Tom.
>
>
> --
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Issues on init / shutdown design of elm externals
On Wed, Oct 10, 2012 at 7:11 AM, Carsten Haitzler wrote:
> On Wed, 3 Oct 2012 14:12:52 +0900 Daniel Juyung Seo
> said:
>
> yeah. i dont see any way it could be different. it has to init elm stuff in
> case
> u use an elm external from an app that doesnt use elm. it's needed. the only
> possible way i see is one of:
>
> 1. make elm_exit a "we will never elm_run again without an elm_init so feel
> free to delete all windows"
>
> OR
>
> 2. we add an elm policy mode (we have ways of setting policy enums - eg auto
> do
> elm_exit() when last window is deleted) that does this but then its opt-in
>
> OR
>
> 3. add an elm_win_all_del() that does the deletion of all windows and again
> its
> an explicit opt-in.
>
> right now i don't smell any other solution.
OK, actually I've already committed a new policy for elm_exit, so the
user can request the deletion of all the windows.
r77328
Looks like it's working fine.
Best regards
>
>> Understood.
>> That looks quite complicated issue.
>> I don't have any solid idea about that.
>> But thanks for spotting this issue.
>>
>> Daniel Juyung Seo (SeoZ)
>>
>> On Mon, Oct 1, 2012 at 10:21 PM, Bruno Dilly wrote:
>> > On Sun, Sep 30, 2012 at 11:53 PM, Daniel Juyung Seo
>> > wrote:
>> >> So elm_exit() means, we are not going to continue the main loop anyhow?
>> >
>> > We'll keep elm_exit() the way it is, a call to ecore_main_loop_quit()
>> >
>> > Right now, on elm_shutdown, when _elm_init_count reaches 0, it will
>> > call _elm_win_shutdown, that will go through the list of windows and
>> > delete all of them.
>> > But, if your theme uses externals, the count won't reaches 0 unless
>> > you explicitly deletes the externals before exiting.
>> >
>> > I thought about adding a policy that would delete all the windows
>> > forcedly on elm exit, but I decided to see if anybody could have some
>> > ideas about changing externals init / shutdown design first. So we
>> > could have applications with themes with or without externals working
>> > the same way.
>> >
>> >>
>> >> Daniel Juyung Seo (SeoZ)
>> >>
>> >> On Sun, Sep 30, 2012 at 8:58 PM, Cedric BAIL
>> >> wrote:
>> >>> Cedric Bail
>> >>> On Sep 29, 2012 10:26 PM, "Gustavo Sverzut Barbieri" <
>> >>> barbi...@profusion.mobi> wrote:
>>
>> On Saturday, September 29, 2012, Cedric BAIL wrote:
>>
>> > On Sep 29, 2012 6:28 AM, "Bruno Dilly" > >>> >
>> > wrote:
>> > > I just saw that when an elm external is added it calls elm_init(),
>> > > and calls shutdown when it's deleted.
>> > > But it's not a nice place to put these calls, because you'll create
>> > > scenarios where elm won't shutdown properly.
>> > >
>> > > Example:
>> > >
>> > > A elm application that uses elm_exit() to quit.
>> > >
>> > > it will have
>> > >
>> > > elm_main() {
>> > > ...
>> > > elm_run()
>> > > ...
>> > > elm_shutdown()
>> > > }
>> > > ELM_MAIN
>> > >
>> > > If you are not using externals, when you call elm_exit() it will
>> > > quit
>> > > the main loop, call elm_shutdown, elm init count will be 0, so it
>> > > will delete the windows and it's widgets, call possible callback
>> > > functions for object delete. Nice.
>> > >
>> > > But if you are using externals in your theme, when you call
>> > > elm_shutdown(), elm init count will be the number of externals used,
>> > > so it won't really shutdown, it won't delete the objects, no
>> > > callbacks will be called. Not good.
>> > >
>> > > Does anybody have ideas about how to fix it ?
>> >
>> > Evas_object_del on the window should do the job and seem logical to
>> > me.
>>
>>
>> That's the problem: windows are never destroyed since elm initialization
>> count never drops to zero, then no Evas shutdown and no canvas deleted.
>>
>> He was talking to me about elm policy to request windows to be deleted
>> on
>> elm_exit() and I like that idea.
>> >>>
>> >>> Make sense to me to, as it's the common case.
>> >>>
>> > > --
>> > > Bruno Dilly
>> > > Senior Developer
>> > > ProFUSION embedded systems
>> > > http://profusion.mobi
>> > >
>> > >
>> >
>> >
>> >>> --
>> > > Got visibility?
>> > > Most devs has no idea what their production app looks like.
>> > > Find out how fast your code is with AppDynamics Lite.
>> > > http://ad.doubleclick.net/clk;262219671;13503038;y?
>> > > http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> > > ___
>> > > enlightenment-devel mailing list
>> > > enlightenment-devel@lists.sourceforge.net
>> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>> > >
>> >
>> >
>> >>> ---
Re: [E-devel] efl tree
On Wednesday, October 10, 2012, Tom Hacohen wrote: > On 10/10/12 10:37, Stefan Schmidt wrote: > > Magic checks, debug and log level left out here as they seem to be > > handled by profiles. Should valgrind support also be handled with this? > > > > I guess. > > > Unit tests, coverage and benchmark will be enabled for all libs at once > > I suppose. > > > Unit tests and benchmarks should only build when you issue "make > check/benchmark". Coverage is a bit more problematic because it requires > you to recompile the sources. I'd love having a way to just make > coverage and make it rebuild the sources that were built without > coverage, but otherwise, we probably need an option. > > -- > Tom. > > > Evas is a real beast when it comes to configure options. :) > > > > The first thing that jumps into my eye are the ARGB Conversion Options. > > Having them all on by default would really be so much overhead? I mean > > you don't use them it should be fine to just always build them. > > > > Image loaders are way more complicated sadly as we drag in dependencies > > here. I would vote for making jpeg, png, gif, bmp, eet on by default. > > > > For the others we might need to see what libs distros ship in a default > > installation so we can decide if we have a hard dep on these libs or not. > > > > That should clear things up a lot. (Yes, I left out engines here on > > purpose. Don't wanted to fight over them :)) > > > > I'd love to see fribidi and harfbuzz there by default, but tbh, I think > some people would appreciate the speed improvements that come with > ignoring the. Make fribidi and harfbuzz mandatory, we've seen lots of bugs that happens on one but not another system. Leave the old code there for those that want to strip it in future, but plan to remove it later and simplify our code. We have MANY improvement spots in text that we could optimize (like fixing the word cache and postponing all the stuff done in _text_set() to render phase) so it pays off fribidi/harfbuzz > > -- > Tom. > > > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On Wednesday, October 10, 2012, David Seikel wrote: > On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt > > wrote: > > Image loaders are way more complicated sadly as we drag in > > dependencies here. I would vote for making jpeg, png, gif, bmp, eet > > on by default. > > > > For the others we might need to see what libs distros ship in a > > default installation so we can decide if we have a hard dep on these > > libs or not. > > Better would be to remove the options, but detect them at build time to > see if they should be included. Things should never be hard > dependencies, unless they actually are. Nooo, this automagically detection should not exist anymore. It breaks reliability of builds as I explained multiple times. It's better to just enable all loaders and turn into a compile time dep, if not static they can generate split packages and not make into runtime deps of Evas. IOW make the mandatory loaders static by default and the secondary as ".so" > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] "evas_object_image_save" fails in case of proxy image object
On Fri, 05 Oct 2012 11:33:11 + (GMT) SHILPA ONKAR SINGH
said:
you can't save an image if its being used as a proxy. all the data is in gpu
specific format (if you have something like gl) and thus is not accessible. if
you must have pixel data that's what the buffer canvas exists for. ecore_evas
can create them and return an image object that is filled with the buffer
canvas. elementary also wraps this with the inlined window. take a look at
those.
> Hi All,
>
> I am creating a proxy image object by using the API
> "evas_object_image_source_set" and using elm_button widget as the source.
> The proxy image object successfully gets created and I can see its contents
> on screen when I show it.
>
> I want to save this proxy image object in to a image file.
> Please tell me how to do this, as the API for saving the image
> "evas_object_image_save" fails in case of proxy image object.
>
> internally when I checked it returns 0 as engine_data is NULL in this case.
>
> Below is sample code.
>
> Evas_Object *btn = elm_button_add(parent);
> Evas_Object *proxy;
> elm_object_text_set(btn, "test");
> evas_object_show(btn);
> proxy = evas_object_image_add(evas_object_evas_get(btn));
> evas_object_image_source_set(proxy, btn);
> evas_object_resize(proxy, 100, 200);
> evas_object_image_filled_set(proxy, EINA_TRUE);
> if (!evas_object_image_save(proxy, "\temp\image.png", NULL, "quality=100"))
> printf("\nCannot save image\n");
>
> evas_object_image_save is failing.
>
> Thanks & Regards
> Shilpa Singh
> --
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EINA_UNUSED and __UNUSED__
On Fri, 5 Oct 2012 22:14:38 +0200 Vincent Torri said: > On Fri, Oct 5, 2012 at 8:21 PM, Vincent Torri wrote: > > On Fri, Oct 5, 2012 at 9:14 PM, Christopher Michael > > wrote: > >> On 05/10/2012 05:59 PM, Tom Hacohen wrote: > >>> On 05/10/12 18:43, Lucas De Marchi wrote: > On Fri, Oct 5, 2012 at 6:53 AM, Vincent Torri > wrote: > > hey > > > > EINA_UNUSED is defined in eina. What about removing the m4 stuff about > > __UNUSED__ and replace it by EINA_UNUSED ? It's 1 letter more than > > __UNUSED__ though :p > > ack. > > However make sure the necessary header is included. For example, one > might have included only Ecore.h and be using __UNUSED__ in his code. > sed scripts for this are welcome :) > >>> > >>> Sed and then check for compilation. > >>> > >>> -- > >>> Tom. > >> > >> iirc, Ecore.h already includes Eina.h tho > > > > Yes as almost all the EFL headers, btw. It will not be a big work > > > > Can someone give me the 'find'. + 'sed' command that does the job ? > > > > Vincent > > I did it in efl/ Please check everything is correct (i've compiled on > linux and windows, built examples and tests. Didn't tried the > benchmark, though) i dont see how this could affect performance... but its a good thing so keep doing it wherever u see fit. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: stefan trunk/e/src/modules/connman
On Thu, 4 Oct 2012 16:09:49 -0300 Lucas De Marchi said: > On Thu, Oct 4, 2012 at 11:56 AM, Enlightenment SVN > wrote: > > Log: > > e/connman: Check for the correct messages. > > > > Checking two times the same message does not make any sense. The only > > logical thing seems to be checking for the properties message here. Leaving > > the wifi properties message out as not every setup has wifi. At least on my > > desktop here I don't have /net/connman/technology/wifi so we should not > > fail without it. > > You could put wifi props there. We are just checking if the message > was actually created. > > HOWEVER, handling technologies in this function is totally misplaced. > I blame raster for adding this code :). The intention of this function > was to deal with Manager interface. Right approach would be to create > some infra similar to deal with technologies, calling > GetTechnologies() on Manager, monitoring signals etc. i had to add it... because there was zero way to make my network work at all unless u added at least a toggle checkbox to stop rfkilling everything which is what connman loves to do by default. it was painful as i had to do the work on my 13" laptop screen+kbd so getting it working at all i was happy :) > That said... as it is right now it works, so I'm not changing it. > Soon it will start using edbus, too. > > > > > Dermarchi or Bdilly please cry or fix if this is not as intended. > > (Brought to you by double_condition_check.cocci) > > nice someone is using these scripts... it's a long time since I wrote them > > > > > Author: stefan > > Date: 2012-10-04 07:56:17 -0700 (Thu, 04 Oct 2012) > > New Revision: 77440 > > Trac: http://trac.enlightenment.org/e/changeset/77440 > > > > Modified: > > trunk/e/src/modules/connman/e_connman.c > > > > Modified: trunk/e/src/modules/connman/e_connman.c > > === > > --- trunk/e/src/modules/connman/e_connman.c 2012-10-04 14:30:55 UTC > > (rev 77439) +++ trunk/e/src/modules/connman/e_connman.c 2012-10-04 > > 14:56:17 UTC (rev 77440) @@ -910,7 +910,7 @@ > > > > "/net/connman/technology/wifi", > > CONNMAN_TECHNOLOGY_IFACE, > > "GetProperties"); > > - if (!msg_services || !msg_services) > > + if (!msg_services || !msg_props) > > good catch. > > > Lucas De Marchi > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] icons in menu and everything
On Wed, 10 Oct 2012 09:03:30 +0200 Sebastian Dransfeld said: > On 10/10/2012 02:40 AM, Carsten Haitzler (The Rasterman) wrote: > > On Tue, 9 Oct 2012 22:29:30 +0200 Sebastian Dransfeld > > said: > > > >> Den 9. okt. 2012 kl. 21:36 skrev Tomas Cech : > >> > >>> Hi, > >>> > >>> On Sun, Oct 07, 2012 at 03:48:01PM +0200, Sebastian Dransfeld wrote: > If you want to be sure that icons are loaded you need to wait for the > cache build event. > >>> > >>> I can run necessary commands in post-install script if you tell me > >>> how. > >>> > >>> I reinstalled my computer recently and it seems that selecting icon > >>> theme is enough (though I don't know why it did not work previous > >>> time). > >>> > >>> How can I package such settings? I mean, how can I create package, > >>> which will use some icon set by default? Is it really good default to > >>> not use any icons? > >>> > >> > >> The icon cache is per user, so you can't build on post install. The icon > >> cache is built when efreet is init'ed, f. ex. during E startup. E won't > >> wait till the icon cache is built, so you can end up with no icons, but > >> the should appear when the cache build is done. Can take a while, don't > >> remember how long. I guess there are also some code in E which does not > >> trigger on cache build, we need to track them down before release. > > > > for me on my machines with the slowest disk it takes maybe at most 10 > > seconds. e should magically "update" when efreet says something like > > desktops changes (which includes icon cache and desktop cache rebuild). on > > the faster machines (ssd's) its sub 1 second. > > > > sd@work-sd:~/scm/e/e> grep -l EFREET_EVENT_ICON_CACHE_UPDATE **/*.c > src/bin/e_border.c > src/modules/ibar/e_mod_main.c > > sd@work-sd:~/scm/e/e> grep -l efreet_icon_path_find **/*.c > (git-svn)-[master]- > src/bin/e_configure.c > src/bin/e_eap_editor.c > src/bin/e_icon.c > src/bin/e_module.c > src/bin/e_utils.c > src/bin/e_widget_filepreview.c > src/modules/conf_theme/e_int_config_xsettings.c > src/modules/notification/e_mod_popup.c > > sd@work-sd:~/scm/e/e> grep -l efreet_mime_type_icon_get **/*.c > src/bin/e_fm.c > src/bin/e_utils.c > src/modules/everything/evry_util.c > > It seems we need to do some updating :) i know not everything does it. :) do u feel like doing it? :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] Another French^WKorean E diner
On Thu, 4 Oct 2012 18:17:51 +0900 Cedric BAIL said: > Hello every body, > > Long time no see ! For all of you that are in Korea or may be around > Seoul on Friday 12th of October, aka Friday next week, I propose we > met in Itaewon for a diner at around 8pm. So who is joining ? And we > will have two special guests ! i'll be there. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCHES] Allocation bugs in ecore, eio, elmdentica
On Thu, 4 Oct 2012 17:43:09 +0400 Igor Murzov said: > > > * eio - Problem using sizeof(type *) instead of sizeof(type) for > > > allocation > > > > > > * elmdentica - Same problem as with eio, but implemented less cunningly > > > > In svn for both of them. > > I think the one for eio should be backported to the stable branch. i backported it now. thanks for pointing that out1 :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Another French^WKorean E diner
So, Jerome, Raster, Seoz, Cedric + 2 special guests, Sanjeev, Hermet will join there? Any other participants? -Regards, Hermet- -Original Message- From: "ChunEon Park" To: "Enlightenment developer list"; Cc: Sent: 2012-10-10 (수) 20:12:58 Subject: Re: [E-devel]Another French^WKorean E diner Then let's meet at Exit 11 of Kangnam station! -Regards, Hermet- -Original Message- From: "Cedric BAIL"@free.fr> To: "Enlightenment developer list"@lists.sourceforge.net>; Cc: Sent: 2012-10-08 (월) 16:51:36 Subject: Re: [E-devel] Another French^WKorean E diner On Mon, Oct 8, 2012 at 5:54 AM, Jérôme Pinot @gmail.com> wrote: > On 10/08/12 01:17, Daniel Juyung Seo wrote: >> Oh right. Kangnam can be a good place just to celebrate Psy's Gangnam Style >> :) >> But Jerome will have hard time to reach there :( > > Not really, I can take the bus at the express bus terminal. So Kangnam seems to be a better place for every one. Let's innovate and meet there. Any good idea where we should met ? >> Daniel Juyung Seo (SeoZ) >> >> On Mon, Oct 8, 2012 at 12:54 AM, ChunEon Park @naver.com> wrote: >> > I will not be in Seoul on the day. >> > >> > So It will be better for me if the place is Kangnam. >> > >> > Because i'm kangnam style... >> > >> > um? >> > >> > Joke. >> > >> > just worrying the terrible traffic jam to go to Itewon from the Suwon :) >> > >> > >> > >> > -Regards, Hermet- >> > -Original Message- >> > From: "Sanjeev BA"@gmail.com> >> > To: "Enlightenment developer >> > list"@lists.sourceforge.net>; >> > Cc: >> > Sent: 2012-10-05 (금) 18:28:13 >> > Subject: Re: [E-devel] Another French^WKorean E diner >> > >> > Yes, I will check if anyone wants to meet efl developers and bring them >> > along :) >> > >> > On Fri, Oct 5, 2012 at 6:20 PM, Cedric BAIL @free.fr> wrote: >> > >> >> On Fri, Oct 5, 2012 at 6:13 PM, Sanjeev BA @gmail.com> wrote: >> >> > I went by this. Friday October 12, 2012 4:15pm - 10:00pm @ Samwon >> >> > Gardens< >> >> http://korealinuxforum2012.sched.org/venue/Samwon+Gardens?iframe=yes&w=700&sidebar=no&bg=no >> >> > >> >> > It takes a 35 minute bus ride to Itaewon. >> >> > I will try to make it , if it is decided. >> >> >> >> Cool and you are welcome to bring more people to the after party :-) >> >> >> >> See you there >> >> >> >> > On Fri, Oct 5, 2012 at 5:31 PM, Cedric BAIL @free.fr> >> >> > wrote: >> >> > >> >> >> On Fri, Oct 5, 2012 at 5:04 PM, Sanjeev BA @gmail.com> wrote: >> >> >> > Event ends by 10 pm (as per schedule). >> >> >> > I believe networking starts beyond 8 pm :) >> >> >> >> >> >> Schedule say the dinner start at 4:15pm from marriot hotel and the >> >> >> shuttle bus will take you back between 8 and 10pm. :-) >> >> >> >> >> >> > On Fri, Oct 5, 2012 at 4:58 PM, Cedric BAIL @free.fr> >> >> wrote: >> >> >> > >> >> >> >> On Fri, Oct 5, 2012 at 4:51 PM, Sanjeev BA @gmail.com> >> >> wrote: >> >> >> >> > Korea Linux Forum is scheduled on Oct 11-12 and some of us might >> >> >> >> > be >> >> >> >> there. >> >> >> >> >> >> >> >> The event is supposed to end around 8pm. So you have plenty of time >> >> to >> >> >> >> join us for the night and get a drink. Oh, and if you want you can >> >> >> >> invite more guest from that event ;-) >> >> >> >> >> >> >> >> > On Fri, Oct 5, 2012 at 2:48 PM, Kim Shinwoo < >> >> kimcinoo@gmail.com> >> >> >> >> wrote: >> >> >> >> >> wow two guests.. that sounds great! but i'm afraid i cannot >> >> >> >> >> join.. >> >> >> T,.T >> >> >> >> >> >> >> >> >> >> 2012/10/5 Jérôme Pinot @gmail.com> >> >> >> >> >> >> >> >> >> >> > On 10/04/12 18:17, Cedric BAIL wrote: >> >> >> >> >> > > Hello every body, >> >> >> >> >> > > >> >> >> >> >> > > Long time no see ! For all of you that are in Korea or may be >> >> >> around >> >> >> >> >> > > Seoul on Friday 12th of October, aka Friday next week, I >> >> propose >> >> >> we >> >> >> >> >> > > met in Itaewon for a diner at around 8pm. So who is joining ? >> >> >> And we >> >> >> >> >> > > will have two special guests ! >> >> >> >> >> > >> >> >> >> >> > It's OK for me too! >> >> >> >> >> > >> >> >> >> >> > BTW if you like to start earlier, I may be able to change my >> >> >> schedule. >> >> >> >> >> > >> >> >> >> >> > -- >> >> >> >> >> > Jérôme Pinot >> >> >> >> >> > http://ngc891.blogdns.net/ > > -- > Jérôme Pinot > http://ngc891.blogdns.net/ > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourcefo
Re: [E-devel] E SVN: stefan IN trunk/eeze/src: bin modules
On Tue, 02 Oct 2012 10:57:18 +0100 Stefan Schmidt said: > Hello. > > On 28/09/12 12:28, Carsten Haitzler (The Rasterman) wrote: > > On Fri, 28 Sep 2012 13:20:30 +0200 Sebastian Dransfeld > > > > said: > > > >> On 09/28/2012 11:10 AM, Enlightenment SVN wrote: > >>> Log: > >>> eeze/sensor: Fix fake module to set timestamp to microseconds since epoch. > >>> > >>> Seconds is not really a suitable resolution for sensor data read outs. > >>> This also aligns it with the tizen module and the public API. > >>> The sleep is no longer needed in the test program either. > >> > >> Use ecore_time_unix_get() (Or better ecore_loop_time_get() or > >> ecore_time_get() if possible) > > ecore_time_unix_get() would indeed be a easy replacement here. :) i SUGGEST using ecore_time_get() though. :) > > ecore_time or ecore_loop_time - loop time is when they loop woke up for some > > event (be it a timeout for a timer, animator or input data) so for ecore > > conceptually this is the timepoint exactly at which something happened - it > > keeps animations more in sync for example :) also this timepoint is not > > since some specific time like unix_time - it's all relative - so u can > > compare 2 timepoints and know how far apart they are but not know in > > absolute terms what it is. also this time doesnt continue ticking while a > > system is suspended for example. i suggest these are the best 2 timespaces > > u want to use :) ecore_time_get returns the time right now - not loop > > wakeup time. > > I was wondering about absolute v.s relative time values here. The tizen > framework offers absolute values against the unix epoch. So that is one > source. Other modules might do something else in the future. and that is.. unfortunately.. a design flaw. :) while device is suspended timestamps keep advancing - but relative ones don't - they susupend while device suspended. this is actually fundamentally important. example - with ecore timers, if we had them still stick while suspended, we either (after suspending for 1 day) wake up and run 1's of expired timers, or we throw a lot of them out creating "missed timers"... this is bad. suspending "time" with timestamps while suspended is a very good idea. :) > The only use case for the time-stamp right now is to have the > possibility to check if new data has been read out since the last time > you checked. A straight forward comparison of the time-stamps. Going > with the unix epoch here sounds like a sane plan. i'd suggest ecore_time_get() here - then the timestamps ALSO match other timestamps like the gui event ones which are also the same as ecore_time_get() time. :) > We can switch the unsigned long long timestamp in the public struct to a > double as we get it from ecore_time_unix_get() if you guys want. double better :) > regards > Stefan Schmidt > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Another French^WKorean E diner
Then let's meet at Exit 11 of Kangnam station! -Regards, Hermet- -Original Message- From: "Cedric BAIL" To: "Enlightenment developer list"; Cc: Sent: 2012-10-08 (월) 16:51:36 Subject: Re: [E-devel] Another French^WKorean E diner On Mon, Oct 8, 2012 at 5:54 AM, Jérôme Pinot @gmail.com> wrote: > On 10/08/12 01:17, Daniel Juyung Seo wrote: >> Oh right. Kangnam can be a good place just to celebrate Psy's Gangnam Style >> :) >> But Jerome will have hard time to reach there :( > > Not really, I can take the bus at the express bus terminal. So Kangnam seems to be a better place for every one. Let's innovate and meet there. Any good idea where we should met ? >> Daniel Juyung Seo (SeoZ) >> >> On Mon, Oct 8, 2012 at 12:54 AM, ChunEon Park @naver.com> wrote: >> > I will not be in Seoul on the day. >> > >> > So It will be better for me if the place is Kangnam. >> > >> > Because i'm kangnam style... >> > >> > um? >> > >> > Joke. >> > >> > just worrying the terrible traffic jam to go to Itewon from the Suwon :) >> > >> > >> > >> > -Regards, Hermet- >> > -Original Message- >> > From: "Sanjeev BA"@gmail.com> >> > To: "Enlightenment developer >> > list"@lists.sourceforge.net>; >> > Cc: >> > Sent: 2012-10-05 (금) 18:28:13 >> > Subject: Re: [E-devel] Another French^WKorean E diner >> > >> > Yes, I will check if anyone wants to meet efl developers and bring them >> > along :) >> > >> > On Fri, Oct 5, 2012 at 6:20 PM, Cedric BAIL @free.fr> wrote: >> > >> >> On Fri, Oct 5, 2012 at 6:13 PM, Sanjeev BA @gmail.com> wrote: >> >> > I went by this. Friday October 12, 2012 4:15pm - 10:00pm @ Samwon >> >> > Gardens< >> >> http://korealinuxforum2012.sched.org/venue/Samwon+Gardens?iframe=yes&w=700&sidebar=no&bg=no >> >> > >> >> > It takes a 35 minute bus ride to Itaewon. >> >> > I will try to make it , if it is decided. >> >> >> >> Cool and you are welcome to bring more people to the after party :-) >> >> >> >> See you there >> >> >> >> > On Fri, Oct 5, 2012 at 5:31 PM, Cedric BAIL @free.fr> >> >> > wrote: >> >> > >> >> >> On Fri, Oct 5, 2012 at 5:04 PM, Sanjeev BA @gmail.com> wrote: >> >> >> > Event ends by 10 pm (as per schedule). >> >> >> > I believe networking starts beyond 8 pm :) >> >> >> >> >> >> Schedule say the dinner start at 4:15pm from marriot hotel and the >> >> >> shuttle bus will take you back between 8 and 10pm. :-) >> >> >> >> >> >> > On Fri, Oct 5, 2012 at 4:58 PM, Cedric BAIL @free.fr> >> >> wrote: >> >> >> > >> >> >> >> On Fri, Oct 5, 2012 at 4:51 PM, Sanjeev BA @gmail.com> >> >> wrote: >> >> >> >> > Korea Linux Forum is scheduled on Oct 11-12 and some of us might >> >> >> >> > be >> >> >> >> there. >> >> >> >> >> >> >> >> The event is supposed to end around 8pm. So you have plenty of time >> >> to >> >> >> >> join us for the night and get a drink. Oh, and if you want you can >> >> >> >> invite more guest from that event ;-) >> >> >> >> >> >> >> >> > On Fri, Oct 5, 2012 at 2:48 PM, Kim Shinwoo < >> >> kimcinoo@gmail.com> >> >> >> >> wrote: >> >> >> >> >> wow two guests.. that sounds great! but i'm afraid i cannot >> >> >> >> >> join.. >> >> >> T,.T >> >> >> >> >> >> >> >> >> >> 2012/10/5 Jérôme Pinot @gmail.com> >> >> >> >> >> >> >> >> >> >> > On 10/04/12 18:17, Cedric BAIL wrote: >> >> >> >> >> > > Hello every body, >> >> >> >> >> > > >> >> >> >> >> > > Long time no see ! For all of you that are in Korea or may be >> >> >> around >> >> >> >> >> > > Seoul on Friday 12th of October, aka Friday next week, I >> >> propose >> >> >> we >> >> >> >> >> > > met in Itaewon for a diner at around 8pm. So who is joining ? >> >> >> And we >> >> >> >> >> > > will have two special guests ! >> >> >> >> >> > >> >> >> >> >> > It's OK for me too! >> >> >> >> >> > >> >> >> >> >> > BTW if you like to start earlier, I may be able to change my >> >> >> schedule. >> >> >> >> >> > >> >> >> >> >> > -- >> >> >> >> >> > Jérôme Pinot >> >> >> >> >> > http://ngc891.blogdns.net/ > > -- > Jérôme Pinot > http://ngc891.blogdns.net/ > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Cedric BAIL -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today
Re: [E-devel] E SVN: raster trunk/elementary/src/lib
On Tue, 2 Oct 2012 18:33:34 +0900 Daniel Juyung Seo said:
i have no idea now... i am sure i was chasing a bug... weird. re-enabled now in
svn.
> Oops raster, Why did you commented this out? Any problem was there?
> Actually you committed the code and the code came from Chanwook Jung's patch.
> http://trac.enlightenment.org/e/changeset/68934
>
> I don't know why he added that but at least you disabled genlist item cache.
>
> Daniel Juyung Seo (SeoZ)
>
> On Tue, Aug 14, 2012 at 6:38 PM, Enlightenment SVN
> wrote:
> > Log:
> > genlist tree effect off fix.
> >
> >
> >
> > Author: raster
> > Date: 2012-08-14 02:38:36 -0700 (Tue, 14 Aug 2012)
> > New Revision: 75249
> > Trac: http://trac.enlightenment.org/e/changeset/75249
> >
> > Modified:
> > trunk/elementary/src/lib/elm_genlist.c
> >
> > Modified: trunk/elementary/src/lib/elm_genlist.c
> > ===
> > --- trunk/elementary/src/lib/elm_genlist.c 2012-08-14 09:18:48 UTC
> > (rev 75248) +++ trunk/elementary/src/lib/elm_genlist.c 2012-08-14
> > 09:38:36 UTC (rev 75249) @@ -1268,6 +1268,8 @@
> > it->item->nocache_once = EINA_FALSE;
> > else if (!it->item->nocache)
> > itc = _item_cache_find(it);
> > +/* XXX: so someone explain why this is here forcing items to NOT be
> > realized
> > + * if tree effect is disabled? this doesn't make sense. fix.
> > if (itc && (!GL_IT(it)->wsd->tree_effect_enabled))
> > {
> > VIEW(it) = itc->base_view;
> > @@ -1275,7 +1277,7 @@
> > it->spacer = itc->spacer;
> > itc->spacer = NULL;
> > }
> > - else
> > + else */
> > {
> > const char *stacking_even;
> > const char *stacking;
> >
> >
> > --
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
> --
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas_object_line displays black pixels
On Wed, Oct 10, 2012 at 12:46 PM, Carsten Haitzler wrote:
> On Mon, 1 Oct 2012 13:33:35 +0200 Vincent Torri
> said:
>
>> hey
>>
>> i'm using some evas object green lines, and there are some black
>> pixels that are also drawn. See attached file. Does someone see why ?
>
> wtf? that's odd. the software engine should all render the same regardless of
> where it is...do u have the src so i can test? i've never seen this and it
> shouldn't happen - the line code literally is ancient and hasnt been touched
> for
> years. i am pretty sure it worked when i wrote it and has worked since... but
> maybe some minor bug crept in...
here it is
Vincent
/* gcc -g -Wall -o wolf2 wolf2.c `pkg-config --cflags --libs ecore-evas ecore evas eina evil` */
#include
#include
#include
#include
#include
#define round(x) ((x)>=0?(long)((x)+0.5):(long)((x)-0.5))
typedef struct _W_Player W_Player;
typedef struct _W_World W_World;
struct _W_Player
{
double x;
double y;
int dir; /* -1, 1 ou 0 */
double rot; /* angle courant */
int speed; /* -1, 1 ou 0 */
double speed_move;
double speed_rot;
Evas_Object *o; /* player */
Evas_Object *o_line; /* direction */
int rays_num;
Evas_Object **o_rays;
};
struct _W_World
{
int map[24][32];
int map_width;
int map_height;
int map_scale;
int screen_width;
int strip_width;
double fov;
double view_dist;
Evas_Object *o_map;
W_Player player;
};
static int map_def[24][32] = {
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1},
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,2,2,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,2,0,2,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,1},
{1,0,0,2,0,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2,2,2,2,2,1},
{1,0,0,2,0,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,2,0,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,2,0,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,2,2,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2,2,2,2,2,1},
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,0,0,0,2,2,2,0,0,2,2,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,0,0,0,2,2,2,0,0,2,2,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,0,0,0,2,2,2,0,0,2,2,2,0,0,0,0,0,0,0,0,0,2,2,2,2,2,1},
{1,0,0,0,0,0,0,0,0,2,2,2,0,0,2,2,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,2,0,0,2,2,0,2,2,2,2,2,2,2,2,0,2,2,2,0,0,2,0,0,0,0,0,0,0,1},
{1,0,0,2,0,0,2,0,0,0,0,0,0,0,0,0,0,0,0,0,2,0,0,2,0,0,0,0,0,0,0,1},
{1,0,0,2,0,0,2,0,0,0,0,0,0,0,0,0,0,0,0,0,2,0,0,2,0,0,0,0,0,0,0,1},
{1,0,0,2,0,0,2,0,0,0,0,0,0,0,0,0,0,0,0,0,2,0,0,2,0,0,0,0,0,0,0,1},
{1,0,0,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1},
};
static W_World world;
static void w_player_rays_cast();
static void
w_world_init(Evas *evas)
{
memcpy(world.map, map_def, sizeof(map_def));
world.map_width = 32;
world.map_height = 24;
world.map_scale = 8;
world.screen_width = 320;
world.strip_width = 4;
world.fov = 60 * M_PI / 180;
world.view_dist = (world.screen_width / 2.0) / tan(world.fov / 2.0);
world.player.x = 16 * world.map_scale;
world.player.y = 10 * world.map_scale;
world.player.dir = 0;
world.player.rot = 0;
world.player.speed = 0;
world.player.speed_move = 1.44;
world.player.speed_rot = 5 * M_PI / 180;
world.player.rays_num = world.screen_width / world.strip_width;
}
static void
w_world_draw(Evas *evas)
{
Evas_Object *o;
int i;
int j;
int ii;
int jj;
int w;
int h;
unsigned int *m;
unsigned int *iter;
w = world.map_width * world.map_scale;
h = world.map_height * world.map_scale;
o = evas_object_image_add(evas);
evas_object_move(o, 0, 0);
evas_object_resize(o, w, h);
evas_object_color_set(o, 255, 255, 255, 255);
evas_object_image_size_set(o, w, h);
evas_object_image_fill_set(o, 0, 0, w, h);
m = (unsigned int *)evas_object_image_data_get(o, 1);
if (!m)
return;
iter = m;
for (j = 0; j < world.map_height; j++)
for (jj = 0; jj < world.map_scale; jj++)
for (i = 0; i < world.map_width; i++)
for (ii = 0; ii < world.map_scale; ii++, iter++)
{
if (world.map[j][i] > 0)
*iter = 200 << 24 | 200 << 16 | 200 << 8 | 200;
else
*iter = 255 << 24 | 255 << 16 | 255 << 8 | 255;
}
evas_object_image_data_set(o, m);
evas_object_image_data_update_add(o, 0, 0, w, h);
evas_object_show(o);
world.o_map = o;
o = evas_object_rectangle_add(evas);
evas_object_move(o,
world.player.x - 1,
world.player.y - 1);
evas_object_resize(o, 4, 4);
evas_object_color_set(o, 255,
Re: [E-devel] evas_object_line displays black pixels
On Mon, 1 Oct 2012 13:33:35 +0200 Vincent Torri said: > hey > > i'm using some evas object green lines, and there are some black > pixels that are also drawn. See attached file. Does someone see why ? wtf? that's odd. the software engine should all render the same regardless of where it is...do u have the src so i can test? i've never seen this and it shouldn't happen - the line code literally is ancient and hasnt been touched for years. i am pretty sure it worked when i wrote it and has worked since... but maybe some minor bug crept in... -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore_x_screensaver_set wtf
On Mon, 01 Oct 2012 07:59:32 +0100 Christopher Michael said: > On 01/10/12 07:39, Sebastian Dransfeld wrote: > > On 09/30/2012 11:30 AM, Tomas Cech wrote: > >> Hi, > >> > >> I have strong feeling that this was introduced by commit 76342 > >> (raster). > >> > >> I'm preparing pillory. > > > > In combination with this: > > > > ecore_x_screensaver.c: > >XScreenSaverSelectInput(_ecore_x_disp, root, > >ScreenSaverNotifyMask | ScreenSaverCycle); > > > > Shouldn't the mask be ScreenSaverNotify? Else the handler in E sucks. > > > > (Same code in xcb) > > > > S. > > > > From the man page: > > XScreenSaverSelectInput asks that events related to the screen saver be > generated for this client. If no bits are set in event-mask, then no > events will be generated. Otherwise, any combination of the following > bits may be set: > > ScreenSaverNotify > If this bit is set, ScreenSaverNotify events are generated whenever the > screen saver is activated or deactivated. > ScreenSaverCycle > If this bit is set, ScreenSaverNotify events are generated whenever the > screen saver cycle interval passes. > > So yes, I think you are correct wrt the mask for SelectInput. If we do > the Cycle mask, then that explains why the handler is getting called so > often (when the screensaver timeout is short). > > I do believe that the intended usage for > ecore_x_screensaver_event_listen_set is that we want to be notified when > the screensaver activates (or deactivates). If that is indeed the case, > then we can remove the ScreenSaverCycle mask and just use the NotifyMask. it appears that setting cycle to 10 then back to 0 might generate cycle events. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore_x_screensaver_set wtf
On Sat, 29 Sep 2012 08:59:02 +0200 Tomas Cech said: try 77748. i can't reproduce fyi. > Hi, > > for some time I'm facing high load of E17 and X. > > I attached ltrace to enlightenment and collected data for 3 seconds. > Thise are some higher numbers of calls of functions: > > 42907 ecore_x_screensaver_set > 32809 free > 32800 calloc > 32792 eina_array_step_set > 32792 eina_array_grow > 32792 eina_array_flush > 21453 ecore_x_dpms_enabled_set > 10931 eet_clearcache > 10931 edje_thaw > 10931 edje_freeze > 10931 ecore_x_flush > 10930 evas_render_updates > 1391 evas_render_updates_free > 1391 ecore_x_window_cursor_set > 1391 ecore_x_cursor_new > 1391 ecore_x_cursor_free > 1287 memcpy > 679 ecore_file_mv > 621 eina_hash_find > > > Could someone explain me, why ecore_x_screensaver_set is called 14300 > times per second? > > I attached GDB and set break point to this function, compared > backtrace and it always looks similar: > (gdb) bt > #0 ecore_x_screensaver_set (timeout=10, interval=10, > prefer_blanking=0, allow_exposures=0) at ecore_x_screensaver.c:69 > #1 0x004da619 in e_screensaver_force_update () at > e_screensaver.c:71 > #2 0x004da705 in _e_screensaver_handler_screensaver_notify_cb > (data=, type=, event= > 0x288f670) at e_screensaver.c:231 > #3 0x7fc4f656bb1c in _ecore_call_handler_cb (event= out>, type=, data=, > func=) at ecore_private.h:319 > #4 _ecore_event_call () at ecore_events.c:559 > #5 0x7fc4f65701a9 in _ecore_main_loop_iterate_internal > (once_only=once_only@entry=0) at ecore_main.c:1900 > #6 0x7fc4f6570737 in ecore_main_loop_begin () at ecore_main.c:934 > #7 0x00439869 in main (argc=, argv= out>) at e_main.c:1060 > > > Also ecore_x_dpms_enabled_set is used heavily. > > > So, WTF? > > Best regards, > > Sleep_Walker -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On 10/10/12 12:30, Martin Jansa wrote: > On Wed, Oct 10, 2012 at 10:33:30AM +0100, Stefan Schmidt wrote: >> Hello. >> >> On 10/10/12 10:17, David Seikel wrote: >>> On Wed, 10 Oct 2012 10:00:54 +0100 Stefan Schmidt >>> wrote: On 10/10/12 09:50, David Seikel wrote: > On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt > wrote: >>> But I disagree here. Autodetection is even worse in the case for the image loaders as your application will fail during runtime to load a theme or display thumbnails, etc. In your strictly controlled env this is not a problem as you can only blame yourself but in my opinion this is a no-no for almost all other users. Thus I would vote against autodetection and choose the hard deps carefully to fit the majority of our users. >>> >>> I suspect packagers would rather have it my way as well. Less work for >>> them to do if it just detects what needs to be built. They also have >>> strictly controlled environments. Then they only have to worry about >>> making sure the dependencies are there, and not have to worry about >>> figuring out more options as well. Which is their job. >> >> I did some packaging for embedded stuff and I hated it. But it seems we >> both did not do packaging for desktop distros (correct me if I'm wrong >> for you here). Any packagers around that can shed some light on this? >> You guys like autodetection? Hate it? Don't care? > > I maintain meta-efl layer in openembedded and in general we hate > autodetection. Only way to have reproducible builds is to add "optional" > dependency D as hard dependency, otherwise if there is some other package > (completely unrelated to efl) which needs the same D, then rebuilding > efl package later will detect D available and change the output without > any metadata change. Hey Martin, Thanks for your reply, that's what I thought. -- Tom. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On Wed, Oct 10, 2012 at 10:33:30AM +0100, Stefan Schmidt wrote: > Hello. > > On 10/10/12 10:17, David Seikel wrote: > > On Wed, 10 Oct 2012 10:00:54 +0100 Stefan Schmidt > > wrote: > >> > >> On 10/10/12 09:50, David Seikel wrote: > >>> On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt > >>> wrote: > > > >> But I disagree here. Autodetection is even worse in the case for the > >> image loaders as your application will fail during runtime to load a > >> theme or display thumbnails, etc. In your strictly controlled env > >> this is not a problem as you can only blame yourself but in my > >> opinion this is a no-no for almost all other users. Thus I would vote > >> against autodetection and choose the hard deps carefully to fit the > >> majority of our users. > > > > I suspect packagers would rather have it my way as well. Less work for > > them to do if it just detects what needs to be built. They also have > > strictly controlled environments. Then they only have to worry about > > making sure the dependencies are there, and not have to worry about > > figuring out more options as well. Which is their job. > > I did some packaging for embedded stuff and I hated it. But it seems we > both did not do packaging for desktop distros (correct me if I'm wrong > for you here). Any packagers around that can shed some light on this? > You guys like autodetection? Hate it? Don't care? I maintain meta-efl layer in openembedded and in general we hate autodetection. Only way to have reproducible builds is to add "optional" dependency D as hard dependency, otherwise if there is some other package (completely unrelated to efl) which needs the same D, then rebuilding efl package later will detect D available and change the output without any metadata change. Cheers, > > As for the rest, most people expect to just do "./configure && make && > > sudo make install" or something equivalent, then have it autodetect > > what it can work with. That's kinda a major point of autofoo. > > Autodetect to support the right thing on different systems: Good > Autodetect and fail to build evas png loader because libpng-dev was not > installed and thus fail on loading a theme: Bad > > I have seen a fair amount of trouble regarding "successful" builds but > failures on runtime due to missing loaders. As we moved the librsvg > based loader to evas modules it showed up on mass again. > > I'm an explicit guy not an > implicit-guess-what-I-mean-with-this-in-this-context gyus :) > > Anyway, my opinion is as good as yours and I made my point here. Lets > see what others think. > > regards > Stefan Schmidt > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Issues on init / shutdown design of elm externals
On Wed, 3 Oct 2012 14:12:52 +0900 Daniel Juyung Seo said:
yeah. i dont see any way it could be different. it has to init elm stuff in case
u use an elm external from an app that doesnt use elm. it's needed. the only
possible way i see is one of:
1. make elm_exit a "we will never elm_run again without an elm_init so feel
free to delete all windows"
OR
2. we add an elm policy mode (we have ways of setting policy enums - eg auto do
elm_exit() when last window is deleted) that does this but then its opt-in
OR
3. add an elm_win_all_del() that does the deletion of all windows and again its
an explicit opt-in.
right now i don't smell any other solution.
> Understood.
> That looks quite complicated issue.
> I don't have any solid idea about that.
> But thanks for spotting this issue.
>
> Daniel Juyung Seo (SeoZ)
>
> On Mon, Oct 1, 2012 at 10:21 PM, Bruno Dilly wrote:
> > On Sun, Sep 30, 2012 at 11:53 PM, Daniel Juyung Seo
> > wrote:
> >> So elm_exit() means, we are not going to continue the main loop anyhow?
> >
> > We'll keep elm_exit() the way it is, a call to ecore_main_loop_quit()
> >
> > Right now, on elm_shutdown, when _elm_init_count reaches 0, it will
> > call _elm_win_shutdown, that will go through the list of windows and
> > delete all of them.
> > But, if your theme uses externals, the count won't reaches 0 unless
> > you explicitly deletes the externals before exiting.
> >
> > I thought about adding a policy that would delete all the windows
> > forcedly on elm exit, but I decided to see if anybody could have some
> > ideas about changing externals init / shutdown design first. So we
> > could have applications with themes with or without externals working
> > the same way.
> >
> >>
> >> Daniel Juyung Seo (SeoZ)
> >>
> >> On Sun, Sep 30, 2012 at 8:58 PM, Cedric BAIL
> >> wrote:
> >>> Cedric Bail
> >>> On Sep 29, 2012 10:26 PM, "Gustavo Sverzut Barbieri" <
> >>> barbi...@profusion.mobi> wrote:
>
> On Saturday, September 29, 2012, Cedric BAIL wrote:
>
> > On Sep 29, 2012 6:28 AM, "Bruno Dilly" >>> >
> > wrote:
> > > I just saw that when an elm external is added it calls elm_init(),
> > > and calls shutdown when it's deleted.
> > > But it's not a nice place to put these calls, because you'll create
> > > scenarios where elm won't shutdown properly.
> > >
> > > Example:
> > >
> > > A elm application that uses elm_exit() to quit.
> > >
> > > it will have
> > >
> > > elm_main() {
> > > ...
> > > elm_run()
> > > ...
> > > elm_shutdown()
> > > }
> > > ELM_MAIN
> > >
> > > If you are not using externals, when you call elm_exit() it will quit
> > > the main loop, call elm_shutdown, elm init count will be 0, so it
> > > will delete the windows and it's widgets, call possible callback
> > > functions for object delete. Nice.
> > >
> > > But if you are using externals in your theme, when you call
> > > elm_shutdown(), elm init count will be the number of externals used,
> > > so it won't really shutdown, it won't delete the objects, no
> > > callbacks will be called. Not good.
> > >
> > > Does anybody have ideas about how to fix it ?
> >
> > Evas_object_del on the window should do the job and seem logical to me.
>
>
> That's the problem: windows are never destroyed since elm initialization
> count never drops to zero, then no Evas shutdown and no canvas deleted.
>
> He was talking to me about elm policy to request windows to be deleted on
> elm_exit() and I like that idea.
> >>>
> >>> Make sense to me to, as it's the common case.
> >>>
> > > --
> > > Bruno Dilly
> > > Senior Developer
> > > ProFUSION embedded systems
> > > http://profusion.mobi
> > >
> > >
> >
> >
> >>> --
> > > Got visibility?
> > > Most devs has no idea what their production app looks like.
> > > Find out how fast your code is with AppDynamics Lite.
> > > http://ad.doubleclick.net/clk;262219671;13503038;y?
> > > http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
> >
> >
> >>> --
> > How fast is your code?
> > 3 out of 4 devs don\\\'t know how their code performs in production.
> > Find out how slow your code is with AppDynamics Lite.
> > http://ad.doubleclick.net/clk;262219672;13503038;z?
> > http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> > ___
>
Re: [E-devel] efl tree
On Wed, 10 Oct 2012 10:42:21 +0100 Stefan Schmidt wrote: > Hello. > > On 10/10/12 10:27, David Seikel wrote: > > On Wed, 10 Oct 2012 11:15:47 +0200 Tom Hacohen > > wrote: > >> > >> I think the ideas is to remove useless options, not useful. :) > >> I'm not really against it, I'm fine with automagically detecting > >> stuff if packagers don't find this annoying, the real question is: > >> do they? I know gentoo users don't like it. > > > > Gentoo users want all the "let's tweak this and make it go faster" > > knobs they can get their hands on, and red speed stripes. > > Wait, what? Aren't you the guy who builds every single component for > his project from hand. Tweaking all bits to squeeze out all deps and > remove all unused code form your project? I think the gentoo folks > would certainly welcome you. :P Done to meet legal requirements. Blame the gubermit, they like speed stripes to. :-P -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Another French^WKorean E diner
On 10/10/2012 11:51, Cedric BAIL wrote: Hermet was proposing to meet at exit 2 of Gangnam station at 8pm. Sounds to be fine for me. Still, if people have a better idea, they should not hesitate to raise their voice ! Gangnam style! <>-- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Another French^WKorean E diner
On Wed, Oct 10, 2012 at 6:44 PM, Christophe Sadoine wrote: > On 8 October 2012 16:51, Cedric BAIL wrote: >> On Mon, Oct 8, 2012 at 5:54 AM, Jérôme Pinot wrote: >>> On 10/08/12 01:17, Daniel Juyung Seo wrote: Oh right. Kangnam can be a good place just to celebrate Psy's Gangnam Style :) But Jerome will have hard time to reach there :( >>> >>> Not really, I can take the bus at the express bus terminal. >> >> So Kangnam seems to be a better place for every one. Let's innovate >> and meet there. Any good idea where we should met ? > > I can come! > Do we meet near the station? Hermet was proposing to meet at exit 2 of Gangnam station at 8pm. Sounds to be fine for me. Still, if people have a better idea, they should not hesitate to raise their voice ! -- Cedric BAIL -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
Hello. On 10/10/12 10:40, David Seikel wrote: > On Wed, 10 Oct 2012 10:33:30 +0100 Stefan Schmidt > wrote: > >> On 10/10/12 10:17, David Seikel wrote: >>> On Wed, 10 Oct 2012 10:00:54 +0100 Stefan Schmidt >>> wrote: On 10/10/12 09:50, David Seikel wrote: > On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt > wrote: >>> But I disagree here. Autodetection is even worse in the case for the image loaders as your application will fail during runtime to load a theme or display thumbnails, etc. In your strictly controlled env this is not a problem as you can only blame yourself but in my opinion this is a no-no for almost all other users. Thus I would vote against autodetection and choose the hard deps carefully to fit the majority of our users. >>> >>> I suspect packagers would rather have it my way as well. Less work >>> for them to do if it just detects what needs to be built. They >>> also have strictly controlled environments. Then they only have to >>> worry about making sure the dependencies are there, and not have to >>> worry about figuring out more options as well. Which is their job. >> >> I did some packaging for embedded stuff and I hated it. But it seems >> we both did not do packaging for desktop distros (correct me if I'm >> wrong for you here). > > Well, since you asked, I have done desktop distro packaging of E17 > professionally in the past. Fair enough. :) > In the end, it's rasters plans on this that matter more than our > opinions, coz I suspect he has some. B-) He always has. He just wants all his minions to poke around before doing what he plans to.;) regards Stefan Schmidt -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] multibuttonentry - data corruption issue of the box list
On Wed, Oct 10, 2012 at 6:25 PM, Jihyeon Seol wrote: > Dear, all > > The attached patch is a re-patch for the problem in the data corruption of > the box list in _box_layout_cb() of multibuttonentry. > > This problem has occurred by a dangling pointer of EINA_LIST. > EINA_LIST_FOREACH is replaced by EINA_LIST_FOREACH_SAFE, and the problem has > been fixed. > > Please review this patch. That's in svn. Thanks -- Cedric BAIL -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Another French^WKorean E diner
On 8 October 2012 16:51, Cedric BAIL wrote: > On Mon, Oct 8, 2012 at 5:54 AM, Jérôme Pinot wrote: >> On 10/08/12 01:17, Daniel Juyung Seo wrote: >>> Oh right. Kangnam can be a good place just to celebrate Psy's Gangnam Style >>> :) >>> But Jerome will have hard time to reach there :( >> >> Not really, I can take the bus at the express bus terminal. > > So Kangnam seems to be a better place for every one. Let's innovate > and meet there. Any good idea where we should met ? I can come! Do we meet near the station? -- http://indefini.org -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [patch][elementary] diskselector - bug fix
On Fri, 28 Sep 2012 21:02:03 +0900 Kim Shinwoo said: tnx muchly! in svn it is! :) > diskselector has two bugs. > > 1. on round enable mode > elm_diskselector_item_append(); does not call elm_box_pack_*() for > over_items and under_items which are added when the display item is bigger > than 3. > because over_items and under_items is not added, the diskselector shows > just 4 items + half item(NOT 5 items), in case of display item number is 5 > - elm_diskselector_display_item_num(obj, 5); -. > this bug could be found only if u use as following sequence. >a. elm_diskselector_round_enabled_set(obj, EINA_TRUE); >b. elm_diskselector_item_append(); > > 2. on the round disable mode + bigger than 3 display item > even though display item is bigger than 3 on the round disable mode, only > two blank items are added - left_blank, right_blank. > because of this, the first item could not be selected. means.. the first > item cannot be located in the middle of diskselector. > if u scroll the diskselector to the left-most, then the second item is > selected as below. > >[blank] [ 1st ] [ 2nd ] [ 3rd ] [ 4th ] > > so if the display item is bigger than 3, more blank items would be > necessary. > include lines to resolve above 1st bug, the patch would resolve this issue > also. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
Hello. On 10/10/12 10:27, David Seikel wrote: > On Wed, 10 Oct 2012 11:15:47 +0200 Tom Hacohen > wrote: >> >> I think the ideas is to remove useless options, not useful. :) >> I'm not really against it, I'm fine with automagically detecting >> stuff if packagers don't find this annoying, the real question is: do >> they? I know gentoo users don't like it. > > Gentoo users want all the "let's tweak this and make it go faster" > knobs they can get their hands on, and red speed stripes. Wait, what? Aren't you the guy who builds every single component for his project from hand. Tweaking all bits to squeeze out all deps and remove all unused code form your project? I think the gentoo folks would certainly welcome you. :P regards Stefan Schmidt -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On Wed, 10 Oct 2012 10:33:30 +0100 Stefan Schmidt wrote: > Hello. > > On 10/10/12 10:17, David Seikel wrote: > > On Wed, 10 Oct 2012 10:00:54 +0100 Stefan Schmidt > > wrote: > >> > >> On 10/10/12 09:50, David Seikel wrote: > >>> On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt > >>> wrote: > > > >> But I disagree here. Autodetection is even worse in the case for > >> the image loaders as your application will fail during runtime to > >> load a theme or display thumbnails, etc. In your strictly > >> controlled env this is not a problem as you can only blame > >> yourself but in my opinion this is a no-no for almost all other > >> users. Thus I would vote against autodetection and choose the hard > >> deps carefully to fit the majority of our users. > > > > I suspect packagers would rather have it my way as well. Less work > > for them to do if it just detects what needs to be built. They > > also have strictly controlled environments. Then they only have to > > worry about making sure the dependencies are there, and not have to > > worry about figuring out more options as well. Which is their job. > > I did some packaging for embedded stuff and I hated it. But it seems > we both did not do packaging for desktop distros (correct me if I'm > wrong for you here). Well, since you asked, I have done desktop distro packaging of E17 professionally in the past. In the end, it's rasters plans on this that matter more than our opinions, coz I suspect he has some. 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 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [patch][elementary] multibuttonentry - access feature
On Thu, 27 Sep 2012 14:14:44 +0900 Kim Shinwoo said: > dear all, hello > > i have attached a patch which has access feature for the multibuttonentry. > it was hard time to implement access feature on the multibuttonentry than > others. > anyhow.. please review the patch and give feedback. thanks. looks good to me - in svn it is. thanks very muchly man! :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
Hello. On 10/10/12 10:17, David Seikel wrote: > On Wed, 10 Oct 2012 10:00:54 +0100 Stefan Schmidt > wrote: >> >> On 10/10/12 09:50, David Seikel wrote: >>> On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt >>> wrote: > >> But I disagree here. Autodetection is even worse in the case for the >> image loaders as your application will fail during runtime to load a >> theme or display thumbnails, etc. In your strictly controlled env >> this is not a problem as you can only blame yourself but in my >> opinion this is a no-no for almost all other users. Thus I would vote >> against autodetection and choose the hard deps carefully to fit the >> majority of our users. > > I suspect packagers would rather have it my way as well. Less work for > them to do if it just detects what needs to be built. They also have > strictly controlled environments. Then they only have to worry about > making sure the dependencies are there, and not have to worry about > figuring out more options as well. Which is their job. I did some packaging for embedded stuff and I hated it. But it seems we both did not do packaging for desktop distros (correct me if I'm wrong for you here). Any packagers around that can shed some light on this? You guys like autodetection? Hate it? Don't care? > As for the rest, most people expect to just do "./configure && make && > sudo make install" or something equivalent, then have it autodetect > what it can work with. That's kinda a major point of autofoo. Autodetect to support the right thing on different systems: Good Autodetect and fail to build evas png loader because libpng-dev was not installed and thus fail on loading a theme: Bad I have seen a fair amount of trouble regarding "successful" builds but failures on runtime due to missing loaders. As we moved the librsvg based loader to evas modules it showed up on mass again. I'm an explicit guy not an implicit-guess-what-I-mean-with-this-in-this-context gyus :) Anyway, my opinion is as good as yours and I made my point here. Lets see what others think. regards Stefan Schmidt -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH][ETHUMB] Null checks and checks if divisor is not equal to zero in ethumb.c file
On Tue, 25 Sep 2012 08:19:50 +0200 Michal Jagiello said: ok - in svn it is - but in trunk not in our stable branch. this is "nonsensical" input and shouldn't have been given by the app in the first place, so this is an improvement but not warranting a backport. thanks muchly! :) > Hi, > > > > I found some bugs in ethumb and I have prepared a patch which fixed it. > > > > In functions ethumb_calculate_aspect_from_ratio, > ethumb_calculate_fill_from_ratio, ethumb_plugin_image_resize and > ethumb_image_save Ethumb object is not checked if is NULL, what can cause > segmentation fault. > > > > In functions ethumb_calculate_aspect and ethumb_calculate_fill divisor is > not checked if is equal to zero before division. > > > > Please review the attached patch. > > > > BR, > > > > Michal Jagiello. > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On 10/10/12 11:27, David Seikel wrote: > On Wed, 10 Oct 2012 11:15:47 +0200 Tom Hacohen > wrote: > >> On 10/10/12 11:11, Stefan Schmidt wrote: >>> Hello. >>> >>> On 10/10/12 10:04, Tom Hacohen wrote: On 10/10/12 11:00, Stefan Schmidt wrote: > Hello. > > On 10/10/12 09:50, David Seikel wrote: >> On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt >> wrote: >>> Image loaders are way more complicated sadly as we drag in >>> dependencies here. I would vote for making jpeg, png, gif, bmp, >>> eet on by default. >>> >>> For the others we might need to see what libs distros ship in a >>> default installation so we can decide if we have a hard dep on >>> these libs or not. >> >> Better would be to remove the options, but detect them at build >> time to see if they should be included. Things should never be >> hard dependencies, unless they actually are. > > I see that you don't want to have this for your embedded > project. :) > > But I disagree here. Autodetection is even worse in the case for > the image loaders as your application will fail during runtime to > load a theme or display thumbnails, etc. In your strictly > controlled env this is not a problem as you can only blame > yourself but in my opinion this is a no-no for almost all other > users. Thus I would vote against autodetection and choose the > hard deps carefully to fit the majority of our users. I'm also against autodetection. I prefer strict option setting. But you want to have them (all?) on by default and just let people disable them if needed. >>> >>> This would defeat the original purpose of removing options, >>> right? :) >>> >>> regards >>> Stefan Schmidt >>> >> >> I think the ideas is to remove useless options, not useful. :) >> I'm not really against it, I'm fine with automagically detecting >> stuff if packagers don't find this annoying, the real question is: do >> they? I know gentoo users don't like it. > > Gentoo users want all the "let's tweak this and make it go faster" > knobs they can get their hands on, and red speed stripes. > Speed stripes are pretty awesome. :) -- Tom. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
I prefer my stripes to be red, white, and blue, thank you very much On Wed, Oct 10, 2012 at 10:27 AM, David Seikel wrote: > On Wed, 10 Oct 2012 11:15:47 +0200 Tom Hacohen > wrote: > > > On 10/10/12 11:11, Stefan Schmidt wrote: > > > Hello. > > > > > > On 10/10/12 10:04, Tom Hacohen wrote: > > >> On 10/10/12 11:00, Stefan Schmidt wrote: > > >>> Hello. > > >>> > > >>> On 10/10/12 09:50, David Seikel wrote: > > On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt > > wrote: > > > Image loaders are way more complicated sadly as we drag in > > > dependencies here. I would vote for making jpeg, png, gif, bmp, > > > eet on by default. > > > > > > For the others we might need to see what libs distros ship in a > > > default installation so we can decide if we have a hard dep on > > > these libs or not. > > > > Better would be to remove the options, but detect them at build > > time to see if they should be included. Things should never be > > hard dependencies, unless they actually are. > > >>> > > >>> I see that you don't want to have this for your embedded > > >>> project. :) > > >>> > > >>> But I disagree here. Autodetection is even worse in the case for > > >>> the image loaders as your application will fail during runtime to > > >>> load a theme or display thumbnails, etc. In your strictly > > >>> controlled env this is not a problem as you can only blame > > >>> yourself but in my opinion this is a no-no for almost all other > > >>> users. Thus I would vote against autodetection and choose the > > >>> hard deps carefully to fit the majority of our users. > > >> > > >> I'm also against autodetection. I prefer strict option setting. > > >> But you want to have them (all?) on by default and just let people > > >> disable them if needed. > > > > > > This would defeat the original purpose of removing options, > > > right? :) > > > > > > regards > > > Stefan Schmidt > > > > > > > I think the ideas is to remove useless options, not useful. :) > > I'm not really against it, I'm fine with automagically detecting > > stuff if packagers don't find this annoying, the real question is: do > > they? I know gentoo users don't like it. > > Gentoo users want all the "let's tweak this and make it go faster" > knobs they can get their hands on, and red speed stripes. > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On Wed, 10 Oct 2012 11:15:47 +0200 Tom Hacohen wrote: > On 10/10/12 11:11, Stefan Schmidt wrote: > > Hello. > > > > On 10/10/12 10:04, Tom Hacohen wrote: > >> On 10/10/12 11:00, Stefan Schmidt wrote: > >>> Hello. > >>> > >>> On 10/10/12 09:50, David Seikel wrote: > On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt > wrote: > > Image loaders are way more complicated sadly as we drag in > > dependencies here. I would vote for making jpeg, png, gif, bmp, > > eet on by default. > > > > For the others we might need to see what libs distros ship in a > > default installation so we can decide if we have a hard dep on > > these libs or not. > > Better would be to remove the options, but detect them at build > time to see if they should be included. Things should never be > hard dependencies, unless they actually are. > >>> > >>> I see that you don't want to have this for your embedded > >>> project. :) > >>> > >>> But I disagree here. Autodetection is even worse in the case for > >>> the image loaders as your application will fail during runtime to > >>> load a theme or display thumbnails, etc. In your strictly > >>> controlled env this is not a problem as you can only blame > >>> yourself but in my opinion this is a no-no for almost all other > >>> users. Thus I would vote against autodetection and choose the > >>> hard deps carefully to fit the majority of our users. > >> > >> I'm also against autodetection. I prefer strict option setting. > >> But you want to have them (all?) on by default and just let people > >> disable them if needed. > > > > This would defeat the original purpose of removing options, > > right? :) > > > > regards > > Stefan Schmidt > > > > I think the ideas is to remove useless options, not useful. :) > I'm not really against it, I'm fine with automagically detecting > stuff if packagers don't find this annoying, the real question is: do > they? I know gentoo users don't like it. Gentoo users want all the "let's tweak this and make it go faster" knobs they can get their hands on, and red speed stripes. -- 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 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [elementary] size value checking in elm config
On Tue, 25 Sep 2012 08:15:51 +0200 KoziarekBeata said: ok - correct. these functions make no sense to call with < 0 values. patch in svn. thanks (thanks for not having whitespace changes in this one :)) > Hi, > > > > > > This patch contains size value checks for some functions in elm_config file. > > > > I think that calling these function with negative size values has no sense. > Am I right? > > > > > > Please find attached file and give me some feedback. > > > > > > > > Regards, > > > > Beata > > > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [Patch] multibuttonentry - data corruption issue of the box list
Dear, all The attached patch is a re-patch for the problem in the data corruption of the box list in _box_layout_cb() of multibuttonentry. This problem has occurred by a dangling pointer of EINA_LIST. EINA_LIST_FOREACH is replaced by EINA_LIST_FOREACH_SAFE, and the problem has been fixed. Please review this patch. Sincerely yours, Jihyeon Seol. elc_multibuttonentry.diff Description: Binary data -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] [Ecore] Allow to send SelectionNotify event if there is no data from XGetWindowProperty.
On Mon, 24 Sep 2012 17:17:53 +0200 Michal Pakula vel Rutka said: > Dear EFL developers, > > I have posted this patch some time ago but I didn't receive any feedback > on it apart of WebKit related discussion with Gustavo. > > The issue I want to fix is that elementary clipboard does not return > paste callback if selection does not contain any data. > Currently when ecore_x_window_prop_property_get function is called > asking for AnyProperty it returns 0 if there is no data (number of > items stored equals 0). This causes ecore_x_event_handle_selection > _notify to exit before SelectionNotify event is added and eventually > elementary paste callback is not fired. > My patch removes this condition and changes behaviour of this function > by allowing to add SelectionNotify event even if data returned is empty. we have one problem though... you didnt fix up the xcb code! :-P :) i have done that for u and put your patch into svn. i've also backported it to the 1.7 branch. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On Wed, 10 Oct 2012 10:00:54 +0100 Stefan Schmidt wrote: > Hello. > > On 10/10/12 09:50, David Seikel wrote: > > On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt > > wrote: > >> Image loaders are way more complicated sadly as we drag in > >> dependencies here. I would vote for making jpeg, png, gif, bmp, eet > >> on by default. > >> > >> For the others we might need to see what libs distros ship in a > >> default installation so we can decide if we have a hard dep on > >> these libs or not. > > > > Better would be to remove the options, but detect them at build > > time to see if they should be included. Things should never be hard > > dependencies, unless they actually are. > > I see that you don't want to have this for your embedded project. :) > > But I disagree here. Autodetection is even worse in the case for the > image loaders as your application will fail during runtime to load a > theme or display thumbnails, etc. In your strictly controlled env > this is not a problem as you can only blame yourself but in my > opinion this is a no-no for almost all other users. Thus I would vote > against autodetection and choose the hard deps carefully to fit the > majority of our users. I suspect packagers would rather have it my way as well. Less work for them to do if it just detects what needs to be built. They also have strictly controlled environments. Then they only have to worry about making sure the dependencies are there, and not have to worry about figuring out more options as well. Which is their job. As for the rest, most people expect to just do "./configure && make && sudo make install" or something equivalent, then have it autodetect what it can work with. That's kinda a major point of autofoo. Also, I understand our main goal is to reduce options, not increase hard dependencies. Autodetection at build time is the way to do that. OK, so the other major point of having autofoo is so that we can pretend it will all work just fine on hundreds of obscure systems that no one has ever heard of. -- 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 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On 10/10/12 11:11, Stefan Schmidt wrote: > Hello. > > On 10/10/12 10:04, Tom Hacohen wrote: >> On 10/10/12 11:00, Stefan Schmidt wrote: >>> Hello. >>> >>> On 10/10/12 09:50, David Seikel wrote: On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt wrote: > Image loaders are way more complicated sadly as we drag in > dependencies here. I would vote for making jpeg, png, gif, bmp, eet > on by default. > > For the others we might need to see what libs distros ship in a > default installation so we can decide if we have a hard dep on these > libs or not. Better would be to remove the options, but detect them at build time to see if they should be included. Things should never be hard dependencies, unless they actually are. >>> >>> I see that you don't want to have this for your embedded project. :) >>> >>> But I disagree here. Autodetection is even worse in the case for the >>> image loaders as your application will fail during runtime to load a >>> theme or display thumbnails, etc. In your strictly controlled env this >>> is not a problem as you can only blame yourself but in my opinion this >>> is a no-no for almost all other users. Thus I would vote against >>> autodetection and choose the hard deps carefully to fit the majority of >>> our users. >> >> I'm also against autodetection. I prefer strict option setting. But you >> want to have them (all?) on by default and just let people disable them >> if needed. > > This would defeat the original purpose of removing options, right? :) > > regards > Stefan Schmidt > I think the ideas is to remove useless options, not useful. :) I'm not really against it, I'm fine with automagically detecting stuff if packagers don't find this annoying, the real question is: do they? I know gentoo users don't like it. -- Tom. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On 10/10/12 11:07, Stefan Schmidt wrote: > Are these things actually released and in the distros by now? Harfbuzz: probably soon (already?). Fribidi: it's there in debian stable, I think. :) > >> >> Agreed (wrt the ignoring). Some people have no need for it as they do >> not utilize multiple languages, etc. > > So we should not support i18n either? I could say now that this can only > come from native English speakers but I never use German for my system > either. On the other hand my gf would not use a English only setup. :) > To be honest, we should just make packager's life easy, and not really care about anyone else. :) -- Tom. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On 10/10/12 10:07, Stefan Schmidt wrote: > Hello. > > On 10/10/12 09:56, Christopher Michael wrote: >> On 10/10/12 09:46, Tom Hacohen wrote: >>> On 10/10/12 10:37, Stefan Schmidt wrote: Image loaders are way more complicated sadly as we drag in dependencies here. I would vote for making jpeg, png, gif, bmp, eet on by default. >> Bmp ? Who uses bmp's these days ?? Ohh yea, Windows ;) > > Not for your theme but for some pics on your disk. It all depends on > what libs are shipped by default by > Debian/Fedora/Ubuntu/Gentooe/Bodhi/Arch you name it. > > If they all ship TIFF, etc as well I would vote for building the image > loaders by default on them. User want thumbnails for all pics they have. > Don't care much about the format. :) > For the others we might need to see what libs distros ship in a default installation so we can decide if we have a hard dep on these libs or not. >> Well, if you are referring to the "target" distro (assumed to be >> Crapbuntu), then "Everything under the sun" would be what they include ;) > > See the list above and append or pick as needed. > >>> I'd love to see fribidi and harfbuzz there by default, but tbh, I think >>> some people would appreciate the speed improvements that come with >>> ignoring the. > > Are these things actually released and in the distros by now? > >> >> Agreed (wrt the ignoring). Some people have no need for it as they do >> not utilize multiple languages, etc. > > So we should not support i18n either? Right. Who needs it ? ;) If everyone just learned English than this would be a non-issue :P I could say now that this can only > come from native English speakers but I never use German for my system > either. HA ! I rest my case :P On the other hand my gf would not use a English only setup. :) > Bah, she can just learn English and all would be right with the world ;) dh > regards > Stefan Schmidt > -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
Hello. On 10/10/12 09:56, Christopher Michael wrote: > On 10/10/12 09:46, Tom Hacohen wrote: >> On 10/10/12 10:37, Stefan Schmidt wrote: >>> Image loaders are way more complicated sadly as we drag in dependencies >>> here. I would vote for making jpeg, png, gif, bmp, eet on by default. >>> > Bmp ? Who uses bmp's these days ?? Ohh yea, Windows ;) Not for your theme but for some pics on your disk. It all depends on what libs are shipped by default by Debian/Fedora/Ubuntu/Gentooe/Bodhi/Arch you name it. If they all ship TIFF, etc as well I would vote for building the image loaders by default on them. User want thumbnails for all pics they have. Don't care much about the format. :) >>> For the others we might need to see what libs distros ship in a default >>> installation so we can decide if we have a hard dep on these libs or not. >>> > Well, if you are referring to the "target" distro (assumed to be > Crapbuntu), then "Everything under the sun" would be what they include ;) See the list above and append or pick as needed. >> I'd love to see fribidi and harfbuzz there by default, but tbh, I think >> some people would appreciate the speed improvements that come with >> ignoring the. Are these things actually released and in the distros by now? > > Agreed (wrt the ignoring). Some people have no need for it as they do > not utilize multiple languages, etc. So we should not support i18n either? I could say now that this can only come from native English speakers but I never use German for my system either. On the other hand my gf would not use a English only setup. :) regards Stefan Schmidt -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On 10/10/12 11:00, Stefan Schmidt wrote: > Hello. > > On 10/10/12 09:50, David Seikel wrote: >> On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt >> wrote: >>> Image loaders are way more complicated sadly as we drag in >>> dependencies here. I would vote for making jpeg, png, gif, bmp, eet >>> on by default. >>> >>> For the others we might need to see what libs distros ship in a >>> default installation so we can decide if we have a hard dep on these >>> libs or not. >> >> Better would be to remove the options, but detect them at build time to >> see if they should be included. Things should never be hard >> dependencies, unless they actually are. > > I see that you don't want to have this for your embedded project. :) > > But I disagree here. Autodetection is even worse in the case for the > image loaders as your application will fail during runtime to load a > theme or display thumbnails, etc. In your strictly controlled env this > is not a problem as you can only blame yourself but in my opinion this > is a no-no for almost all other users. Thus I would vote against > autodetection and choose the hard deps carefully to fit the majority of > our users. I'm also against autodetection. I prefer strict option setting. But you want to have them (all?) on by default and just let people disable them if needed. -- Tom. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
Hello. On 10/10/12 09:50, David Seikel wrote: > On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt > wrote: >> Image loaders are way more complicated sadly as we drag in >> dependencies here. I would vote for making jpeg, png, gif, bmp, eet >> on by default. >> >> For the others we might need to see what libs distros ship in a >> default installation so we can decide if we have a hard dep on these >> libs or not. > > Better would be to remove the options, but detect them at build time to > see if they should be included. Things should never be hard > dependencies, unless they actually are. I see that you don't want to have this for your embedded project. :) But I disagree here. Autodetection is even worse in the case for the image loaders as your application will fail during runtime to load a theme or display thumbnails, etc. In your strictly controlled env this is not a problem as you can only blame yourself but in my opinion this is a no-no for almost all other users. Thus I would vote against autodetection and choose the hard deps carefully to fit the majority of our users. regards Stefan Schmidt -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On 10/10/12 09:46, Tom Hacohen wrote: > On 10/10/12 10:37, Stefan Schmidt wrote: >> Magic checks, debug and log level left out here as they seem to be >> handled by profiles. Should valgrind support also be handled with this? >> > > I guess. > >> Unit tests, coverage and benchmark will be enabled for all libs at once >> I suppose. >> > Unit tests and benchmarks should only build when you issue "make > check/benchmark". Coverage is a bit more problematic because it requires > you to recompile the sources. I'd love having a way to just make > coverage and make it rebuild the sources that were built without > coverage, but otherwise, we probably need an option. > > -- > Tom. > >> Evas is a real beast when it comes to configure options. :) >> >> The first thing that jumps into my eye are the ARGB Conversion Options. >> Having them all on by default would really be so much overhead? I mean >> you don't use them it should be fine to just always build them. >> >> Image loaders are way more complicated sadly as we drag in dependencies >> here. I would vote for making jpeg, png, gif, bmp, eet on by default. >> Bmp ? Who uses bmp's these days ?? Ohh yea, Windows ;) >> For the others we might need to see what libs distros ship in a default >> installation so we can decide if we have a hard dep on these libs or not. >> Well, if you are referring to the "target" distro (assumed to be Crapbuntu), then "Everything under the sun" would be what they include ;) >> That should clear things up a lot. (Yes, I left out engines here on >> purpose. Don't wanted to fight over them :)) >> > > I'd love to see fribidi and harfbuzz there by default, but tbh, I think > some people would appreciate the speed improvements that come with > ignoring the. > > -- > Tom. > Agreed (wrt the ignoring). Some people have no need for it as they do not utilize multiple languages, etc. dh -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt wrote: > Image loaders are way more complicated sadly as we drag in > dependencies here. I would vote for making jpeg, png, gif, bmp, eet > on by default. > > For the others we might need to see what libs distros ship in a > default installation so we can decide if we have a hard dep on these > libs or not. Better would be to remove the options, but detect them at build time to see if they should be included. Things should never be hard dependencies, unless they actually are. -- 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 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On 10/10/12 10:37, Stefan Schmidt wrote: > Magic checks, debug and log level left out here as they seem to be > handled by profiles. Should valgrind support also be handled with this? > I guess. > Unit tests, coverage and benchmark will be enabled for all libs at once > I suppose. > Unit tests and benchmarks should only build when you issue "make check/benchmark". Coverage is a bit more problematic because it requires you to recompile the sources. I'd love having a way to just make coverage and make it rebuild the sources that were built without coverage, but otherwise, we probably need an option. -- Tom. > Evas is a real beast when it comes to configure options. :) > > The first thing that jumps into my eye are the ARGB Conversion Options. > Having them all on by default would really be so much overhead? I mean > you don't use them it should be fine to just always build them. > > Image loaders are way more complicated sadly as we drag in dependencies > here. I would vote for making jpeg, png, gif, bmp, eet on by default. > > For the others we might need to see what libs distros ship in a default > installation so we can decide if we have a hard dep on these libs or not. > > That should clear things up a lot. (Yes, I left out engines here on > purpose. Don't wanted to fight over them :)) > I'd love to see fribidi and harfbuzz there by default, but tbh, I think some people would appreciate the speed improvements that come with ignoring the. -- Tom. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
Hello. On 10/10/12 08:12, Carsten Haitzler (The Rasterman) wrote: > > what i want is for everyone please to test the efl tree and look at configure > options and find things to clean up/remove/whatever. i already think we need > to > remove much more. Magic checks, debug and log level left out here as they seem to be handled by profiles. Should valgrind support also be handled with this? Unit tests, coverage and benchmark will be enabled for all libs at once I suppose. Eina: - Remove threads configure option (on by default) - Remove mempool configure options - For Iconv, dirfd, xattr and shm_open I would also think remove the configure option and set on by default. But I'm surely not seeing all implications for these and have no hard feelings here. :) Eet: - GnuTLS might need to stay. My feelings here are that not enough people use this feature to justice the overhead of the default linkage with gnutls. But we could at least have one option instead of cipher and signature. - Remove old eet file format option (on by default) > what we also need to do is strip down configure options for evas, and ecore > and > the rest of efl where needed, so feel free to look at that. i intent to poke > around evas soon., but the current efl tree needs yet more options nuked > imho. :) Evas is a real beast when it comes to configure options. :) The first thing that jumps into my eye are the ARGB Conversion Options. Having them all on by default would really be so much overhead? I mean you don't use them it should be fine to just always build them. Image loaders are way more complicated sadly as we drag in dependencies here. I would vote for making jpeg, png, gif, bmp, eet on by default. For the others we might need to see what libs distros ship in a default installation so we can decide if we have a hard dep on these libs or not. That should clear things up a lot. (Yes, I left out engines here on purpose. Don't wanted to fight over them :)) regards Stefan Schmidt -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Toolbar transverse expand set
On Fri, 21 Sep 2012 16:22:50 +0900 Jaehwan Kim said: hmm actually try use "stretch": elm_toolbar_stretch_set/get() :) that should be much nicer. :) > Dear raster > > Yesterday, you discussed about toolbar with Seoz. > Currently the vertical length of the item is decided by the min value of > item. > (When the toolbar is horizontal mode) > If we want to expand the item according toolbar height, there's any API > which set the mode. > Since the toolbar has the horizontal/vertical mode, I can not use the word > horizontal. > So I decide the API name elm_toolbar_transverse_expanded_set/get. > Please review this name is proper. > > Thanks > -- > Jaehwan Kim. > -- > Got visibility? > Most devs has no idea what their production app looks like. > Find out how fast your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219671;13503038;y? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH][ETHUMB] Null checks and checks if divisor is not equal to zero in ethumb.c file
Hi, I found some bugs in ethumb and I have prepared a patch which fixed it. In functions ethumb_calculate_aspect_from_ratio, ethumb_calculate_fill_from_ratio, ethumb_plugin_image_resize and ethumb_image_save Ethumb object is not checked if is NULL, what can cause segmentation fault. In functions ethumb_calculate_aspect and ethumb_calculate_fill divisor is not checked if is equal to zero before division. Please review the attached patch. BR, Michal Jagiello. ethumb.patch Description: Binary data -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Edje][Patch] Patch with NULL checks for some functions in edje_entry file
On Thu, 20 Sep 2012 11:19:57 +0200 KoziarekBeata said: i'm going to be a bit harsh here.. :( but.. it'd be nice if you didn't make 99% of your patch whitepsace changes? it really discourages review - when u see a long patch u delay it only to find.. its all wasted stuff. :-P so please.. next time... strip whitepsace changes? or don't go making them unless u want to make separate whitespace patches? :) ok - in and i stripped the whitepsace changes out of the patch > Hi, > > > > This patch contains NULL checks for some functions in edje_entry file. > > Lack of these NULL checks after calling these function causes segmentation > faults. > > > > Please find attached file and give me some feedback. > > > > Regards, > > Beata > > > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
On Wed, Oct 10, 2012 at 9:12 AM, Carsten Haitzler wrote: > so everyone by now should know that we are merging all of core efl into a > single efl tree. in the process simplifying options etc. > > please be aware that any changes you make to obj/eo, eina, eet or evil must > also be done in the efl tree and we will soon enough decommission the old src > trees (my moving them to OLD probably). > > what i want is for everyone please to test the efl tree and look at configure > options and find things to clean up/remove/whatever. i already think we need > to > remove much more. > > what we also need to do is strip down configure options for evas, and ecore > and > the rest of efl where needed, so feel free to look at that. i intent to poke > around evas soon., but the current efl tree needs yet more options nuked > imho. :) and if possible, strip down options of evas (and ecore) before the merge in efl/ Vincent -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
ecore-con can drop the flag for enable/disable c-ares support; this should ONLY be enabled on windows, and it can be detected as such at configure time. I'd like to say the same about ipv6 support across the board, but people will likely throw tantrums On Wed, Oct 10, 2012 at 8:12 AM, Carsten Haitzler wrote: > so everyone by now should know that we are merging all of core efl into a > single efl tree. in the process simplifying options etc. > > please be aware that any changes you make to obj/eo, eina, eet or evil must > also be done in the efl tree and we will soon enough decommission the old > src > trees (my moving them to OLD probably). > > what i want is for everyone please to test the efl tree and look at > configure > options and find things to clean up/remove/whatever. i already think we > need to > remove much more. > > what we also need to do is strip down configure options for evas, and > ecore and > the rest of efl where needed, so feel free to look at that. i intent to > poke > around evas soon., but the current efl tree needs yet more options nuked > imho. :) > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] efl tree
so everyone by now should know that we are merging all of core efl into a single efl tree. in the process simplifying options etc. please be aware that any changes you make to obj/eo, eina, eet or evil must also be done in the efl tree and we will soon enough decommission the old src trees (my moving them to OLD probably). what i want is for everyone please to test the efl tree and look at configure options and find things to clean up/remove/whatever. i already think we need to remove much more. what we also need to do is strip down configure options for evas, and ecore and the rest of efl where needed, so feel free to look at that. i intent to poke around evas soon., but the current efl tree needs yet more options nuked imho. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] icons in menu and everything
On 10/10/2012 02:40 AM, Carsten Haitzler (The Rasterman) wrote: > On Tue, 9 Oct 2012 22:29:30 +0200 Sebastian Dransfeld > said: > >> Den 9. okt. 2012 kl. 21:36 skrev Tomas Cech : >> >>> Hi, >>> >>> On Sun, Oct 07, 2012 at 03:48:01PM +0200, Sebastian Dransfeld wrote: If you want to be sure that icons are loaded you need to wait for the cache build event. >>> >>> I can run necessary commands in post-install script if you tell me >>> how. >>> >>> I reinstalled my computer recently and it seems that selecting icon >>> theme is enough (though I don't know why it did not work previous >>> time). >>> >>> How can I package such settings? I mean, how can I create package, >>> which will use some icon set by default? Is it really good default to >>> not use any icons? >>> >> >> The icon cache is per user, so you can't build on post install. The icon >> cache is built when efreet is init'ed, f. ex. during E startup. E won't wait >> till the icon cache is built, so you can end up with no icons, but the should >> appear when the cache build is done. Can take a while, don't remember how >> long. I guess there are also some code in E which does not trigger on cache >> build, we need to track them down before release. > > for me on my machines with the slowest disk it takes maybe at most 10 seconds. > e should magically "update" when efreet says something like desktops changes > (which includes icon cache and desktop cache rebuild). on the faster machines > (ssd's) its sub 1 second. > sd@work-sd:~/scm/e/e> grep -l EFREET_EVENT_ICON_CACHE_UPDATE **/*.c src/bin/e_border.c src/modules/ibar/e_mod_main.c sd@work-sd:~/scm/e/e> grep -l efreet_icon_path_find **/*.c (git-svn)-[master]- src/bin/e_configure.c src/bin/e_eap_editor.c src/bin/e_icon.c src/bin/e_module.c src/bin/e_utils.c src/bin/e_widget_filepreview.c src/modules/conf_theme/e_int_config_xsettings.c src/modules/notification/e_mod_popup.c sd@work-sd:~/scm/e/e> grep -l efreet_mime_type_icon_get **/*.c src/bin/e_fm.c src/bin/e_utils.c src/modules/everything/evry_util.c It seems we need to do some updating :) S. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Configure profiles for e's source
shiny
On Wed, Oct 10, 2012 at 7:55 AM, Vincent Torri wrote:
> On Wed, Oct 10, 2012 at 8:53 AM, Michael Blumenkrantz
> wrote:
> > what the hell is NDEBUG
>
> man assert
>
> Vincent
>
> >
> > On Wed, Oct 10, 2012 at 7:50 AM, Tom Hacohen >wrote:
> >
> >> Dears,
> >>
> >> Here's a summary of a discussion between raster, Vincent and I on IRC:
> >> We'd like to have 4 configure profiles for e (+efl)'s source. You'd have
> >> a default profile set for trunk ("dev") and a default one for branches
> >> ("release") and obviously you'd be able to switch between them.
> >>
> >> The profiles we thought about are:
> >> "fast" - magic checks off, logging is off, and NDEBUG is set.
> >> "release" (default in release branches) - magic checks are on, log level
> >> is set to errors and above, NDEBUG is set.
> >> "dev" - magic check on, magic abort on, logging is set to warnings and
> >> above, NDEBUG is not set.
> >> "debug" - magic check on, magic abort on, logging is set to debug and
> >> above, NDEBUG is not set.
> >>
> >> What do you guys think?
> >>
> >> --
> >> Tom.
> >>
> >>
> >>
> --
> >> Don't let slow site performance ruin your business. Deploy New Relic APM
> >> Deploy New Relic app performance management and know exactly
> >> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> >> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> >> http://p.sf.net/sfu/newrelic-dev2dev
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> >
> --
> > Don't let slow site performance ruin your business. Deploy New Relic APM
> > Deploy New Relic app performance management and know exactly
> > what is happening inside your Ruby, Python, PHP, Java, and .NET app
> > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> > http://p.sf.net/sfu/newrelic-dev2dev
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> --
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
