On Wednesday 02 of November 2011 23:45:53 Martin Schreiber wrote:
On Wednesday 02 November 2011 17.43:56 Martin Schreiber wrote:
On Wednesday 02 November 2011 17.13:49 Jonas Maebe wrote:
Yes, the result slower, but it's also correct (as in it makes sure
that the actual local time is
On Thursday 03 November 2011 07.44:47 zeljko wrote:
The results with 10'000'000 calls:
FPC Now() MSEgui nowutc() MSEgui nowlocal()
Linux
15.29s 3.39s 3.57s
Windows
10.00s 1.22s 1.37s
Have you tried latest Michael's
03.11.2011 15:04, Martin Schreiber wrote:
No, I can not use trunk because of cpstrnew. I'll try the file Michael sent.
If it is not difficult please explain exact problems with cpstrnew you
have in a separate thread. It is important to know for me what problems
do you have with the new
On Thursday 03 November 2011 08.11:16 Paul Ishenin wrote:
03.11.2011 15:04, Martin Schreiber wrote:
No, I can not use trunk because of cpstrnew. I'll try the file Michael
sent.
If it is not difficult please explain exact problems with cpstrnew you
have in a separate thread. It is
On Thursday 03 of November 2011 08:11:16 Paul Ishenin wrote:
03.11.2011 15:04, Martin Schreiber wrote:
No, I can not use trunk because of cpstrnew. I'll try the file Michael
sent.
If it is not difficult please explain exact problems with cpstrnew you
have in a separate thread. It is
On Thursday 03 November 2011 08.04:17 Martin Schreiber wrote:
On Thursday 03 November 2011 07.44:47 zeljko wrote:
The results with 10'000'000 calls:
FPC Now() MSEgui nowutc() MSEgui nowlocal()
Linux
15.29s 3.39s 3.57s
Windows
10.00s
03.11.2011 15:29, zeljko wrote:
Maybe it's not problem *now*, but looking into mailing list ppl have a
lot of problems, so I think that fear is only problem (at least for me).
People mostly expressed their FUD although there were few problems and
there are some.
But why do you think they
On Thursday 03 of November 2011 08:43:55 Martin Schreiber wrote:
On Thursday 03 November 2011 08.04:17 Martin Schreiber wrote:
On Thursday 03 November 2011 07.44:47 zeljko wrote:
The results with 10'000'000 calls:
FPC Now() MSEgui nowutc() MSEgui nowlocal()
Linux
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
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 is
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 all
On Thursday 03 November 2011 09.08:35 zeljko wrote:
That's pretty big difference. Can you compare NowReal() from attached
program with your functions ?
Linux
FPC Now() MSEgui nowutc() MSEgui nowlocal() NowReal()
10.28s 3.45s 3.55s 9.86s
Martin
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
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
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 MSDN
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, Nov 3, 2011 at 9:41 AM, zeljko zel...@holobit.net 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
Am 03.11.2011 02:39, schrieb Hans-Peter Diettrich:
IMO we have to face a problem very similar to Ansi/UTF-8/16: A TDateTime
variable can contain local time in a number of timezones (Ansi), or UTC
values (UTF), which must be interpreted accordingly, e.g. in
DateTimeToStr().
When Delphi
Am 03.11.2011 03:12, schrieb Hans-Peter Diettrich:
Also note that on platforms like Windows this would be a unnecessary
call as there the current(!) timezone bias is located in a shared
memory area which is mapped into each process by the kernel.
I don't think that this really is how Windows
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
Hi,
I can pass an array of TVarRec to a procedure that expects an array of
const like below:
procedure Test(Args: array of const);
begin
//do something with args
end;
var
a: array of TVarRec;
s: String;
begin
SetLength(a, 2);
a[0].VType := vtInteger;
a[0].VInteger := 3;
Sven Barth schrieb:
Am 03.11.2011 02:39, schrieb Hans-Peter Diettrich:
IMO we have to face a problem very similar to Ansi/UTF-8/16: A TDateTime
variable can contain local time in a number of timezones (Ansi), or UTC
values (UTF), which must be interpreted accordingly, e.g. in
DateTimeToStr().
Sven Barth schrieb:
FPC's Now on Windows uses GetLocalTime as well. For its implementation
please take a look here:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/time.c?revision=52912view=markup
(line 277ff)
That code doesn't make sense, without additional
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
On Thu, 03 Nov 2011 17:38:01 +0100, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
FPC's Now on Windows uses GetLocalTime as well. For its implementation
please take a look here:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/time.c?revision=52912view=markup
On Thursday, November 03, 2011 11:03:36 am Hans-Peter Diettrich wrote:
Sven Barth schrieb:
And functions like DateTimeToStr don't care whether a time value is
local or UTC and in my opinion they even MUST NOT.
Splitting the TDateTime into year, month etc. is done by a DecodeDate...
Pete Cervasio schrieb:
Splitting the TDateTime into year, month etc. is done by a DecodeDate...
function, that *assumes* that TDateTime contains a local time. When you
feed it an UTC time, the result is unusable.
What? How does it assume it's in local time? It assumes it has received
Am 03.11.2011 21:11, schrieb Hans-Peter Diettrich:
Pete Cervasio schrieb:
Splitting the TDateTime into year, month etc. is done by a
DecodeDate...
function, that *assumes* that TDateTime contains a local time. When you
feed it an UTC time, the result is unusable.
What? How does it assume
Am 02.11.2011 19:25, schrieb Ludo Brands:
Apparently not everything is that transparent under windows:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724944%28v=vs.85%2
9.aspx
To inform Explorer that the time zone has changed, send the
WM_SETTINGCHANGE message.
WM_SETTINGCHANGE
Am 03.11.2011 17:38, schrieb Hans-Peter Diettrich:
Sven Barth schrieb:
FPC's Now on Windows uses GetLocalTime as well. For its implementation
please take a look here:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/time.c?revision=52912view=markup
(line 277ff)
That
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
On Thursday, November 03, 2011 03:11:37 pm Hans-Peter Diettrich wrote:
Pete Cervasio schrieb:
Splitting the TDateTime into year, month etc. is done by a
DecodeDate...
function, that *assumes* that TDateTime contains a local time. When
you
feed it an UTC time, the
32 matches
Mail list logo
