Re: [E-devel] [PATCH] ecore_x_randr_current_output_get ~> ecore_x_randr_window_outputs_get
Am 09.04.2011 um 05:22 schrieb Carsten Haitzler (The Rasterman) : > On Thu, 7 Apr 2011 16:41:38 +0200 Leif Middelschulte > said: > > in svn, but i've had to fix some things :) Thanks :-) Feel free to simply denie my patches and give me hints, about what I did wrong. :-) > >> Dear developers, >> >> find attached a set of patches that do the following: >> >> State before patches: >> ecore_x_randr_current_output_get was unimplemented. >> >> State after patches: >> Patch1: ecore_x_randr_window_outputs_get implements functionality of >> ecore_x_randr_current_output_get >> Patch2: ecore_x_randr_current_output_get is deprecated and redirects >> calls to ecore_x_randr_window_outputs_get >> >> Please review/comment/commit! >> >> BR, >> >> Leif > > > -- > - Codito, ergo sum - "I code, therefore I am" > -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/edje/src/lib
On 04/09/2011 01:52 AM, Mike Blumenkrantz wrote: > On Fri, 8 Apr 2011 22:48:47 -0700 > "Enlightenment SVN" wrote: > >> Log: >> Edje: Edje_Text: Don't segfault on _edje_text_part_on_del if there is >>not 'part' >> >>Don't ask me how I found this one, but it happened :/ so trap for >>valid part before trying to use it. >> >> >> > how did you find it?!!? > What part of 'don't ask me' did you not understand ? :P dh -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] enki compile error
I didn't realize edje was also updated.. Just recompiled edje and now enki compiles & runs.. Thanks! On Apr 9, 2011, at 3:04 AM, Carsten Haitzler (The Rasterman) wrote: > > did you update both enki and edje? recompile & installed edje? > >> I still get the same error. -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore: request to drop printf warning
On Sat, 9 Apr 2011 03:25:49 -0700 Dave Ray said: that's not worth worrying about then. it's a good reminder of problems you will end up facing sooner or later. :) and really.. you will not even MEASURE the amount of space it takes to log. really. relative to all your other logs/outputs. > Yes, it's invoked dozens of times in a few minutes of work. > So I should patch EINA logging then. > > On Apr 9, 2011, at 3:12 AM, Carsten Haitzler (The Rasterman) wrote: > > > On Fri, 8 Apr 2011 20:10:29 -0700 Dave Ray said: > > > > actually... ecore does only spew it out once... on init. so at worst you get > > this complaint once per invocation/run. that's entirely reasonable. i don't > > see us removing that. > > > >> I agree entirely. MacOS is getting more POSIX by the year :). > >> But in interest of making e17 a clean experience for other MacOS users now > >> I am wondering what the best fix is. Can we add a patch for Darwin with an > >> equivalent clock call? Or should I just patch EINA logging. > >> > >> > >> > >> On Apr 8, 2011, at 8:03 PM, Carsten Haitzler (The Rasterman) wrote: > >> > >>> On Fri, 8 Apr 2011 18:45:12 -0700 Dave Ray said: > >>> > >>> wtf? so 10 years after posix-2001 was standardized (and clock_gettime was > >>> around before that) osx still hasnt caught up? wonderfully primitive OS > >>> you have there :) seriously that clock_gettime is relatively important. > >>> things happen to work for you by luck and not by design, as gustavo said > >>> - change clock config/timezone and such.. and things will stuff up > >>> without a monotonic clock. it's warning you of a serious deficiency in > >>> your OS that leads to other bugs. > >>> > It's a known issue with Darwin, which MacOS is part of. They haven't had > clock_gettime support for 6+ years. > > There are alternative time calls that work on Darwin. but the fallback in > ecore seems to work fine. There are some good discussions on the net, I > can post some ideas for monotonic clocks if interested. > > I can try adding the EINA flag to suppress the warnings, that sounds like > the best option for now. > > But I wonder does anyone benefit from this printf warning spewing > frequently. It seems to work fine using the fallback. > > > On Apr 8, 2011, at 6:06 PM, Carsten Haitzler (The Rasterman) wrote: > > > On Fri, 8 Apr 2011 21:36:39 -0300 Gustavo Sverzut Barbieri > > said: > > > >> On Fri, Apr 8, 2011 at 8:40 PM, Dave Ray wrote: > >>> On my OS ecore runs fine, but spews a warning frequently. > >>> > >>> CRI<12490>:ecore ecore_time.c:170 _ecore_time_init() Platform does not > >>> support clock_gettime. Fallback to unix time. > >>> > >>> Everything that uses ecore spews it. Fills up my logs. > >>> > >>> Is this printf necessary? > >> > >> It's not a printf(), but eina_log and you van disable it with > >> EINA_LOG_LEVELS=ecore:-1 > >> > >> What platform is yours? The correct fix would be to add proper > >> monotonic clock to it... this may result in skews and problems during > >> timezone changes. > > > > not just timezone - every time the clock is changed - ie u set the time > > (ntp adjusts clock skew, etc. etc) depending on timezone setup and so > > on. i would agree with gustavo - your Os sounds pretty poor if it has no > > monotonic clock. if it does and it simply has decided to not comform to > > posix (As clock_gettime is posix.1-2001) then it's just wanting to be > > different for the sake of being different. if it is a problem with our > > detection of the call and it does exist, then please let us know what it > > requires to detect it etc. (see configure.ac for ecore - we check libc > > and if not we check librt) :) > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > > > -- > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > ___ > 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 > >>> > >> > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > -- - Codito, ergo sum - "I code, therefore I am" -
Re: [E-devel] ecore: request to drop printf warning
On Fri, 8 Apr 2011 20:10:29 -0700 Dave Ray said: actually... ecore does only spew it out once... on init. so at worst you get this complaint once per invocation/run. that's entirely reasonable. i don't see us removing that. > I agree entirely. MacOS is getting more POSIX by the year :). > But in interest of making e17 a clean experience for other MacOS users now I > am wondering what the best fix is. Can we add a patch for Darwin with an > equivalent clock call? Or should I just patch EINA logging. > > > > On Apr 8, 2011, at 8:03 PM, Carsten Haitzler (The Rasterman) wrote: > > > On Fri, 8 Apr 2011 18:45:12 -0700 Dave Ray said: > > > > wtf? so 10 years after posix-2001 was standardized (and clock_gettime was > > around before that) osx still hasnt caught up? wonderfully primitive OS you > > have there :) seriously that clock_gettime is relatively important. things > > happen to work for you by luck and not by design, as gustavo said - change > > clock config/timezone and such.. and things will stuff up without a > > monotonic clock. it's warning you of a serious deficiency in your OS that > > leads to other bugs. > > > >> It's a known issue with Darwin, which MacOS is part of. They haven't had > >> clock_gettime support for 6+ years. > >> > >> There are alternative time calls that work on Darwin. but the fallback in > >> ecore seems to work fine. There are some good discussions on the net, I can > >> post some ideas for monotonic clocks if interested. > >> > >> I can try adding the EINA flag to suppress the warnings, that sounds like > >> the best option for now. > >> > >> But I wonder does anyone benefit from this printf warning spewing > >> frequently. It seems to work fine using the fallback. > >> > >> > >> On Apr 8, 2011, at 6:06 PM, Carsten Haitzler (The Rasterman) wrote: > >> > >>> On Fri, 8 Apr 2011 21:36:39 -0300 Gustavo Sverzut Barbieri > >>> said: > >>> > On Fri, Apr 8, 2011 at 8:40 PM, Dave Ray wrote: > > On my OS ecore runs fine, but spews a warning frequently. > > > > CRI<12490>:ecore ecore_time.c:170 _ecore_time_init() Platform does not > > support clock_gettime. Fallback to unix time. > > > > Everything that uses ecore spews it. Fills up my logs. > > > > Is this printf necessary? > > It's not a printf(), but eina_log and you van disable it with > EINA_LOG_LEVELS=ecore:-1 > > What platform is yours? The correct fix would be to add proper > monotonic clock to it... this may result in skews and problems during > timezone changes. > >>> > >>> not just timezone - every time the clock is changed - ie u set the time > >>> (ntp adjusts clock skew, etc. etc) depending on timezone setup and so on. > >>> i would agree with gustavo - your Os sounds pretty poor if it has no > >>> monotonic clock. if it does and it simply has decided to not comform to > >>> posix (As clock_gettime is posix.1-2001) then it's just wanting to be > >>> different for the sake of being different. if it is a problem with our > >>> detection of the call and it does exist, then please let us know what it > >>> requires to detect it etc. (see configure.ac for ecore - we check libc > >>> and if not we check librt) :) > >>> > >>> -- > >>> - Codito, ergo sum - "I code, therefore I am" -- > >>> The Rasterman (Carsten Haitzler)ras...@rasterman.com > >>> > >> > >> > >> -- > >> Xperia(TM) PLAY > >> It's a major breakthrough. An authentic gaming > >> smartphone on the nation's most reliable network. > >> And it wants your games. > >> http://p.sf.net/sfu/verizon-sfdev > >> ___ > >> 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 > > > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] enki compile error
On Sat, 9 Apr 2011 02:54:35 -0700 Dave Ray said: did you update both enki and edje? recompile & installed edje? > I still get the same error. > > Actually, I omitted the ecore warning before the the console output, this is > the actual output: > > [trunk/enki/] > > make > ... > Making all in default > /usr/local/bin/edje_cc -v default.edc -id ../images/ > CRI<84997>:ecore ecore_time.c:170 _ecore_time_init() Platform does not > support clock_gettime. Fallback to unix time. ERR<84997>:edje_cc > edje_cc_parse.c:1018 check_arg_count() /usr/local/bin/edje_cc: Error. > minislideshow.edc:108 got 5 arguments, but expected 4 make[4]: *** > [default.edj] Error 255 make[3]: *** [all-recursive] Error 1 make[2]: *** > [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 > > > > > > On Apr 8, 2011, at 10:46 PM, Daniel Juyung Seo wrote: > > > Raster fixed this and I fixed another bug as well. > > Thanks. > > > > Daniel Juyung Seo (SeoZ) > > > > On Sat, Apr 9, 2011 at 8:37 AM, Dave Ray wrote: > > I am getting the following error when compiling enki. Any suggestions? > > > > ... > > Making all in default > > /usr/local/bin/edje_cc -v default.edc -id ../images/ > > In file included: > > geocaching_bubble.edc:126:8: warning: `wrap_stars_signal' redefined > > geocaching.edc:44: warning: this is the location of the previous definition > > ERR<12490>:edje_cc edje_cc_parse.c:1018 check_arg_count > > () /usr/local/bin/edje_cc: Error. minislideshow.edc:108 got 5 arguments, > > but expected 4 make[4]: *** [default.edj] Error 255 > > > > > > > > -- > > Xperia(TM) PLAY > > It's a major breakthrough. An authentic gaming > > smartphone on the nation's most reliable network. > > And it wants your games. > > http://p.sf.net/sfu/verizon-sfdev > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > -- > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > ___ > 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 -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] enki compile error
I still get the same error. Actually, I omitted the ecore warning before the the console output, this is the actual output: [trunk/enki/] > make ... Making all in default /usr/local/bin/edje_cc -v default.edc -id ../images/ CRI<84997>:ecore ecore_time.c:170 _ecore_time_init() Platform does not support clock_gettime. Fallback to unix time. ERR<84997>:edje_cc edje_cc_parse.c:1018 check_arg_count() /usr/local/bin/edje_cc: Error. minislideshow.edc:108 got 5 arguments, but expected 4 make[4]: *** [default.edj] Error 255 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 On Apr 8, 2011, at 10:46 PM, Daniel Juyung Seo wrote: > Raster fixed this and I fixed another bug as well. > Thanks. > > Daniel Juyung Seo (SeoZ) > > On Sat, Apr 9, 2011 at 8:37 AM, Dave Ray wrote: > I am getting the following error when compiling enki. Any suggestions? > > ... > Making all in default > /usr/local/bin/edje_cc -v default.edc -id ../images/ > In file included: > geocaching_bubble.edc:126:8: warning: `wrap_stars_signal' redefined > geocaching.edc:44: warning: this is the location of the previous definition > ERR<12490>:edje_cc edje_cc_parse.c:1018 check_arg_count() > /usr/local/bin/edje_cc: Error. minislideshow.edc:108 got 5 arguments, but > expected 4 > make[4]: *** [default.edj] Error 255 > > > > -- > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
