On Friday 04 of November 2011 11:54:16 Graeme Geldenhuys wrote:
> On 4 November 2011 12:39, Sven Barth wrote:
> > "fpgettimeofday" itself simply calls the syscall "gettimeofday" of the
> > kernel.
>
> I have another "experimental" version of epiktimer that uses the posix
> clock_gettime() (instea
On 4 November 2011 12:39, Sven Barth wrote:
> "fpgettimeofday" itself simply calls the syscall "gettimeofday" of the
> kernel.
I have another "experimental" version of epiktimer that uses the posix
clock_gettime() (instead of fpgettimeofday), which I had to implement
myself, because FPC doesn't i
On Fri, 4 Nov 2011, Graeme Geldenhuys wrote:
So please checkout the following code to make sure you use the latest EpikTimer.
svn co
https://lazarus-ccr.svn.sourceforge.net/svnroot/lazarus-ccr/components/epiktimer/
I already did this before mailing my reply. The reply was just meant to
ex
Sven Barth schrieb:
It's basically a 64-bit type now. Here's ReactOS' implementation of
GetTickCount64 (which is called by GetTickCount):
[...]
You notice the loop regarding SharedUserData again? ;) (though this time
it also contains a call to "YieldProcessor" and a comment regarding the
loop
Am 04.11.2011 08:46, schrieb Graeme Geldenhuys:
My version of EpikTimer use the
fpgettimeofday() call under Linux for clock ticks. I haven't
investigated in detail what that call translates too under Linux - I
hope it's not Now().
It's the other way round: "Now" uses "fpgettimeofday" internally
Please stop spreading FUD!
> - dependency on LCL
I have fixed this well over a year or two ago. The only LCL dependency
was the registration of the EpikTimer component on the Lazarus
component palette. I simply split the original lazarus package into
two packages (runtime and design-time) - that
On Fri, 4 Nov 2011, Graeme Geldenhuys wrote:
On 3 November 2011 15:55, wrote:
PLEASE NEVER MENTION EPIKTIMER AGAIN.
it returns Now() on all platforms except i386.
Not sure if my version of EpikTimer is the same as yours. Last time we
had this (similar) conversation, your EpikTimer code w
On 3 November 2011 15:55, wrote:
>
> PLEASE NEVER MENTION EPIKTIMER AGAIN.
>
> it returns Now() on all platforms except i386.
Not sure if my version of EpikTimer is the same as yours. Last time we
had this (similar) conversation, your EpikTimer code was out of date
(you still had code which requi
Am 03.11.2011 18:15, schrieb Hans-Peter Diettrich:
zeljko schrieb:
This is what MSDN says about GetTickCount:
Retrieves the number of milliseconds that have elapsed since the
system was started, up to 49.7 days (what they do after 49.7 days ? ).
When the DWORD overflows, Win9x stops to work
zeljko schrieb:
This is what MSDN says about GetTickCount:
Retrieves the number of milliseconds that have elapsed since the system
was started, up to 49.7 days (what they do after 49.7 days ? ).
When the DWORD overflows, Win9x stops to work properly. NT uses an
bigger data type, at least int
On Thu, 3 Nov 2011, Graeme Geldenhuys wrote:
If you want to do timing, you can also take a look at EpikTimer. I
believe it doesn't work on all platforms that FPC supports, but it
works on the big three (Windows, Linux, Mac).
PLEASE NEVER MENTION EPIKTIMER AGAIN.
it returns Now() on all plat
On Thu, Nov 3, 2011 at 9:41 AM, zeljko wrote:
> I guess that there's no GetTickCount in RTL.
> Is it possible to add it there ?
If we are going to add this I would prefer to get the result in
microseconds. If the platform doesnt support, then just multiply the
result, but still allow the possibil
If you want to do timing, you can also take a look at EpikTimer. I
believe it doesn't work on all platforms that FPC supports, but it
works on the big three (Windows, Linux, Mac).
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI
On Thu, November 3, 2011 09:41, zeljko wrote:
> I guess that there's no GetTickCount in RTL.
> Is it possible to add it there ?
> Why ?
> Because current GetTickCount in lazarus uses Now() which is movable
> backward/forward by ntpd under unixes, and that could be a huge problem.
>
> This is what M
Al 03/11/2011 9:41, En/na zeljko ha escrit:
Retrieves the number of milliseconds that have elapsed since the system
was started, up to 49.7 days (what they do after 49.7 days ? ).
It starts again from 0.
If you're using it to time events (i.e.
ElapsedTime:=GetTickCount-StartTime), it's not a
Withdrawn.
It is only partially true.
Still it can not be expanded and can overflow easily.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Did anybody mention gettickcount is documented as microtiming?
And should not be expanded?
On 3-11-2011 9:57, Marco van de Voort wrote:
In our previous episode, zeljko said:
So, according to POSIX clock_gettime(CLOCK_MONOTONIC) is supported on
linux, bsd and others, and in that case we can have
In our previous episode, zeljko said:
> > So, according to POSIX clock_gettime(CLOCK_MONOTONIC) is supported on
> > linux, bsd and others, and in that case we can have exact GetTickCount.
> > If there's no support for monotonic clock on some platform , now() can be
> > returned anytime.
> Forget
On Thursday 03 of November 2011 09:41:05 zeljko wrote:
> I guess that there's no GetTickCount in RTL.
> Is it possible to add it there ?
> Why ?
> Because current GetTickCount in lazarus uses Now() which is movable
> backward/forward by ntpd under unixes, and that could be a huge problem.
>
> This
I guess that there's no GetTickCount in RTL.
Is it possible to add it there ?
Why ?
Because current GetTickCount in lazarus uses Now() which is movable
backward/forward by ntpd under unixes, and that could be a huge problem.
This is what MSDN says about GetTickCount:
Retrieves the number of milli
20 matches
Mail list logo
