On Tue, 28 Sep 2010 07:49:32 +0200 (CEST) Vincent Torri <vto...@univ-evry.fr> said:
> > > On Tue, 28 Sep 2010, Carsten Haitzler (The Rasterman) wrote: > > > On Mon, 27 Sep 2010 19:47:36 -0300 Lucas De Marchi > > <lucas.demar...@profusion.mobi> said: > > > >> On Mon, Sep 27, 2010 at 7:35 PM, Enlightenment SVN > >> <no-re...@enlightenment.org> wrote: > >>> Log: > >>> Make ecore_time_get and friends use monotonic clock > >>> Instead of relying on unix time, use a monotonic clock provided by > >>> clock_gettime(). If a monotonic clock is not available, it will fallback > >>> to CLOCK_REALTIME or unix time if neither is available. > >>> > >>> The impact is that now it only makes sense to call ecore_time_get() or > >>> ecore_time_loop_get() if the value retrieved is intended to be used as > >>> relative to previous/posterior measurements. If an absolute value is > >>> needed, the right function to call now is ecore_time_unix_get() which > >>> will give the number of seconds since Jan 1st, 1970, 12:00AM. > >> > >> > >> This is the monotonic clock in svn, and ecore_time_get and > >> ecore_loop_time_get are properly implemented now. I fixed most of the > >> cases where they were used when an absolute time was needed. Hopefully > >> all in EFL are fixed, but since the list is somewhat big, please make > >> some checks and give it some love. > >> > >> I fixed a couple of issues in E-MODULES-EXTRA, but I didn't bother to > >> going through all the modules and fixing them all. If it's not working > >> and all you want is the previous behavior, just change the calls > >> ecore_time_get() and ecore_loop_time_get() to ecore_time_unix_get(). > >> > >> I think that before beta we should rename ecore_loop_time_get() to > >> ecore_time_loop_get() to keep the namespace as the other similar > >> functions. > > > > i don't think thats possible anymore. thats a very invasive change and LOTS > > of code will need to change - outside our own svn, to adapt. i say no to > > this due to sheer practical considerations :( > > and adding just a #define of this new function and putting a deprecated > warning on the other ? #define i'm fine with. or even a full function that simply calls the other internally - ok. but no removale or deprecation of current one. we are not going to deprecate it now... just before a stable release. in a few years - maybe. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
