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] E SVN: stefan IN trunk/eeze/src: bin modules
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. :) > 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. 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. 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. 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] E SVN: stefan IN trunk/eeze/src: bin modules
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 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.
> S.
>
> >
> > Author: stefan
> > Date: 2012-09-28 02:10:47 -0700 (Fri, 28 Sep 2012)
> > New Revision: 77191
> > Trac: http://trac.enlightenment.org/e/changeset/77191
> >
> > Modified:
> >trunk/eeze/src/bin/eeze_sensor_test.c
> > trunk/eeze/src/modules/eeze_sensor_fake.c
> >
> > Modified: trunk/eeze/src/bin/eeze_sensor_test.c
> > ===
> > --- trunk/eeze/src/bin/eeze_sensor_test.c 2012-09-28 09:10:43 UTC
> > (rev 77190) +++ trunk/eeze/src/bin/eeze_sensor_test.c 2012-09-28
> > 09:10:47 UTC (rev 77191) @@ -129,8 +129,6 @@
> > else
> >printf("Could not find a light sensor!\n");
> >
> > - sleep(1);
> > -
> > /* Get updated values on a sensor. Read out is synchronous */
> > eeze_sensor_read(sens);
> > if (!sens) printf("can't find an light sensor!\n");
> >
> > Modified: trunk/eeze/src/modules/eeze_sensor_fake.c
> > ===
> > --- trunk/eeze/src/modules/eeze_sensor_fake.c 2012-09-28 09:10:43
> > UTC (rev 77190) +++ trunk/eeze/src/modules/eeze_sensor_fake.c
> > 2012-09-28 09:10:47 UTC (rev 77191) @@ -3,7 +3,7 @@
> > #endif
> >
> > #include
> > -#include
> > +#include
> >
> > #include
> > #include
> > @@ -38,6 +38,7 @@
> > fake_read(Eeze_Sensor_Type sensor_type, Eeze_Sensor_Obj *lobj)
> > {
> > Eeze_Sensor_Obj *obj = NULL;
> > + struct timeval tv;
> >
> > obj = eeze_sensor_obj_get(sensor_type);
> > if (obj == NULL)
> > @@ -56,7 +57,8 @@
> > obj->data[0] = 7;
> > obj->data[1] = 23;
> > obj->data[2] = 42;
> > -obj->timestamp = time(NULL);
> > +gettimeofday(&tv, NULL);
> > +obj->timestamp = ((tv.tv_sec * 100) + tv.tv_usec);
> > break;
> >
> > case EEZE_SENSOR_TYPE_LIGHT:
> > @@ -65,7 +67,8 @@
> > case EEZE_SENSOR_TYPE_TEMPERATURE:
> > obj->accuracy = 0;
> > obj->data[0] = 7;
> > -obj->timestamp = time(NULL);
> > +gettimeofday(&tv, NULL);
> > +obj->timestamp = ((tv.tv_sec * 100) + tv.tv_usec);
> > break;
> >
> > default:
> > @@ -82,6 +85,7 @@
> > fake_async_read(Eeze_Sensor_Type sensor_type, void *user_data EINA_UNUSED)
> > {
> > Eeze_Sensor_Obj *obj = NULL;
> > + struct timeval tv;
> >
> > obj = eeze_sensor_obj_get(sensor_type);
> > if (obj == NULL)
> > @@ -101,7 +105,8 @@
> > obj->data[0] = 7;
> > obj->data[1] = 23;
> > obj->data[2] = 42;
> > -obj->timestamp = time(NULL);
> > +gettimeofday(&tv, NULL);
> > +obj->timestamp = ((tv.tv_sec * 100) + tv.tv_usec);
> > break;
> >
> > case EEZE_SENSOR_TYPE_LIGHT:
> > @@ -110,7 +115,8 @@
> > case EEZE_SENSOR_TYPE_TEMPERATURE:
> > obj->accuracy = 0;
> > obj->data[0] = 7;
> > -obj->timestamp = time(NULL);
> > +gettimeofday(&tv, NULL);
> > +obj->timestamp = ((tv.tv_sec * 100) + tv.tv_usec);
> > break;
> >
> > case EEZE_SENSOR_TYPE_MOTION_SNAP:
> >
> >
> > --
> > 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-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
> >
>
>
> --
> G
Re: [E-devel] E SVN: stefan IN trunk/eeze/src: bin modules
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)
S.
>
> Author: stefan
> Date: 2012-09-28 02:10:47 -0700 (Fri, 28 Sep 2012)
> New Revision: 77191
> Trac: http://trac.enlightenment.org/e/changeset/77191
>
> Modified:
>trunk/eeze/src/bin/eeze_sensor_test.c
> trunk/eeze/src/modules/eeze_sensor_fake.c
>
> Modified: trunk/eeze/src/bin/eeze_sensor_test.c
> ===
> --- trunk/eeze/src/bin/eeze_sensor_test.c 2012-09-28 09:10:43 UTC (rev
> 77190)
> +++ trunk/eeze/src/bin/eeze_sensor_test.c 2012-09-28 09:10:47 UTC (rev
> 77191)
> @@ -129,8 +129,6 @@
> else
>printf("Could not find a light sensor!\n");
>
> - sleep(1);
> -
> /* Get updated values on a sensor. Read out is synchronous */
> eeze_sensor_read(sens);
> if (!sens) printf("can't find an light sensor!\n");
>
> Modified: trunk/eeze/src/modules/eeze_sensor_fake.c
> ===
> --- trunk/eeze/src/modules/eeze_sensor_fake.c 2012-09-28 09:10:43 UTC (rev
> 77190)
> +++ trunk/eeze/src/modules/eeze_sensor_fake.c 2012-09-28 09:10:47 UTC (rev
> 77191)
> @@ -3,7 +3,7 @@
> #endif
>
> #include
> -#include
> +#include
>
> #include
> #include
> @@ -38,6 +38,7 @@
> fake_read(Eeze_Sensor_Type sensor_type, Eeze_Sensor_Obj *lobj)
> {
> Eeze_Sensor_Obj *obj = NULL;
> + struct timeval tv;
>
> obj = eeze_sensor_obj_get(sensor_type);
> if (obj == NULL)
> @@ -56,7 +57,8 @@
> obj->data[0] = 7;
> obj->data[1] = 23;
> obj->data[2] = 42;
> -obj->timestamp = time(NULL);
> +gettimeofday(&tv, NULL);
> +obj->timestamp = ((tv.tv_sec * 100) + tv.tv_usec);
> break;
>
> case EEZE_SENSOR_TYPE_LIGHT:
> @@ -65,7 +67,8 @@
> case EEZE_SENSOR_TYPE_TEMPERATURE:
> obj->accuracy = 0;
> obj->data[0] = 7;
> -obj->timestamp = time(NULL);
> +gettimeofday(&tv, NULL);
> +obj->timestamp = ((tv.tv_sec * 100) + tv.tv_usec);
> break;
>
> default:
> @@ -82,6 +85,7 @@
> fake_async_read(Eeze_Sensor_Type sensor_type, void *user_data EINA_UNUSED)
> {
> Eeze_Sensor_Obj *obj = NULL;
> + struct timeval tv;
>
> obj = eeze_sensor_obj_get(sensor_type);
> if (obj == NULL)
> @@ -101,7 +105,8 @@
> obj->data[0] = 7;
> obj->data[1] = 23;
> obj->data[2] = 42;
> -obj->timestamp = time(NULL);
> +gettimeofday(&tv, NULL);
> +obj->timestamp = ((tv.tv_sec * 100) + tv.tv_usec);
> break;
>
> case EEZE_SENSOR_TYPE_LIGHT:
> @@ -110,7 +115,8 @@
> case EEZE_SENSOR_TYPE_TEMPERATURE:
> obj->accuracy = 0;
> obj->data[0] = 7;
> -obj->timestamp = time(NULL);
> +gettimeofday(&tv, NULL);
> +obj->timestamp = ((tv.tv_sec * 100) + tv.tv_usec);
> break;
>
> case EEZE_SENSOR_TYPE_MOTION_SNAP:
>
>
> --
> 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-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
--
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
