Hello,
I would like to add NowUTC to SysUtils as we have already discussed
previously. I think that the need for adding this should be of common
knowledge for all after the long discussions about Now, and I
understand that this was agreed upon, although surely we can discuss
again.
So ok, now
On Friday 09 of December 2011 09:23:25 Felipe Monteiro de Carvalho wrote:
Adding a GetTickCount routine would also be good. Lazarus has this:
function GetTickCount64: QWord;
But maybe in the RTL it should have a different name to avoid
conflicts with the Windows unit... but which name?
On Fri, December 9, 2011 09:23, Felipe Monteiro de Carvalho wrote:
Hi,
I would like to add NowUTC to SysUtils as we have already discussed
previously. I think that the need for adding this should be of common
knowledge for all after the long discussions about Now, and I
understand that this
On Fri, 9 Dec 2011, Hans-Peter Diettrich wrote:
Makeskel expects another(?) semicolon after win\wininc\func.inc:
function GetRandomRgn(aHDC: HDC; aHRGN: HRGN; iNum: WINT): WINT; stdcall;
external 'gdi32';
function ...
Perhaps it cannot parse the external directive?
FPDoc seems to suffer
In our previous episode, Felipe Monteiro de Carvalho said:
I would like to add NowUTC to SysUtils as we have already discussed
previously. I think that the need for adding this should be of common
knowledge for all after the long discussions about Now, and I
understand that this was agreed
In our previous episode, Michael Van Canneyt said:
And as long as it is not 100% documented, it will not be added.
In other words, the windows unit will probably never make it in the official
docs.
I do not think it makes any sense to do so anyway. The windows API is best
documented on
On Fri, Dec 9, 2011 at 10:39 AM, Marco van de Voort mar...@stack.nl wrote:
I thought that discussion had established that a timezone based on
fpgettimeofday is not reliable on Linux? Yet, I see it in this patch?
In my tests it worked. What do you propose instead?
--
Felipe Monteiro de
On Fri, 9 Dec 2011, Felipe Monteiro de Carvalho wrote:
Hello,
I would like to add NowUTC to SysUtils as we have already discussed
previously. I think that the need for adding this should be of common
knowledge for all after the long discussions about Now, and I
understand that this was
On Fri, 9 Dec 2011, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
And as long as it is not 100% documented, it will not be added.
In other words, the windows unit will probably never make it in the official
docs.
I do not think it makes any sense to do so
On Fri, 9 Dec 2011, Hans-Peter Diettrich wrote:
Makeskel expects another(?) semicolon after win\wininc\func.inc:
function GetRandomRgn(aHDC: HDC; aHRGN: HRGN; iNum: WINT): WINT; stdcall;
external 'gdi32';
function ...
Perhaps it cannot parse the external directive?
Should be fixed.
In our previous episode, Felipe Monteiro de Carvalho said:
On Fri, Dec 9, 2011 at 10:39 AM, Marco van de Voort mar...@stack.nl wrote:
I thought that discussion had established that a timezone based on
fpgettimeofday is not reliable on Linux? Yet, I see it in this patch?
In my tests it
On Fri, 9 Dec 2011, Marco van de Voort wrote:
In our previous episode, Felipe Monteiro de Carvalho said:
On Fri, Dec 9, 2011 at 10:39 AM, Marco van de Voort mar...@stack.nl wrote:
I thought that discussion had established that a timezone based on
fpgettimeofday is not reliable on Linux?
On Fri, December 9, 2011 12:09, Michael Van Canneyt wrote:
On Fri, 9 Dec 2011, Marco van de Voort wrote:
In our previous episode, Felipe Monteiro de Carvalho said:
On Fri, Dec 9, 2011 at 10:39 AM, Marco van de Voort mar...@stack.nl
wrote:
I thought that discussion had established that a
In our previous episode, Michael Van Canneyt said:
Crossplatform functions which are only stubs on some platforms are useless
and should not be added.
I don't see the problem.
As far as I can see, NowUTC should simply return the kernel time and not
perform
the shift to local time
On Fri, 9 Dec 2011, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Crossplatform functions which are only stubs on some platforms are useless
and should not be added.
I don't see the problem.
As far as I can see, NowUTC should simply return the kernel time and
On 09 Dec 2011, at 12:28, Michael Van Canneyt wrote:
The linux kernel returns UTC time, it always has. Now() converts
this to local time.
(as does libc). All NowUTC needs to do is return the kernel time.
It should only be called NowUTC if it is defined as always returning
UTC on all
On Fri, December 9, 2011 13:07, Jonas Maebe wrote:
On 09 Dec 2011, at 12:28, Michael Van Canneyt wrote:
The linux kernel returns UTC time, it always has. Now() converts
this to local time.
(as does libc). All NowUTC needs to do is return the kernel time.
It should only be called NowUTC if
2011/12/9 Tomas Hajny xhaj...@hajny.biz:
Is it preferred to return ticks (dependent on various stuff), or something
like GetMsCount (as already existing in unit Dos)?
I would like to define it like this:
FPGetTickCount returns the amount of ticks since an unspecified
initial time. This initial
In our previous episode, Michael Van Canneyt said:
what does that have to do with the issue ?
The linux kernel returns UTC time, it always has. Now() converts this to
local time.
(as does libc). All NowUTC needs to do is return the kernel time.
Could be. I thought that was the old
On 12/09/2011 01:17 PM, Felipe Monteiro de Carvalho wrote:
I would like to define it like this: FPGetTickCount returns the
amount of ticks since an unspecified initial time. This initial time
is unknown, but is fixed for the entire duration of the application.
Ticks are time intervals and all
On Fri, 9 Dec 2011, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
what does that have to do with the issue ?
The linux kernel returns UTC time, it always has. Now() converts this to local
time.
(as does libc). All NowUTC needs to do is return the kernel
On Fri, 9 Dec 2011, Jonas Maebe wrote:
On 09 Dec 2011, at 12:28, Michael Van Canneyt wrote:
The linux kernel returns UTC time, it always has. Now() converts this to
local time.
(as does libc). All NowUTC needs to do is return the kernel time.
It should only be called NowUTC if it is
On Fri, 9 Dec 2011, Felipe Monteiro de Carvalho wrote:
2011/12/9 Tomas Hajny xhaj...@hajny.biz:
Is it preferred to return ticks (dependent on various stuff), or something
like GetMsCount (as already existing in unit Dos)?
I would like to define it like this:
FPGetTickCount returns the
On Fri, 9 Dec 2011, Tomas Hajny wrote:
On Fri, December 9, 2011 13:07, Jonas Maebe wrote:
On 09 Dec 2011, at 12:28, Michael Van Canneyt wrote:
The linux kernel returns UTC time, it always has. Now() converts
this to local time.
(as does libc). All NowUTC needs to do is return the kernel
On 09 Dec 2011, at 13:47, Michael Van Canneyt wrote:
I know nothing about OS/2-eCS, but the same arguments as for Go32V2
apply as far as I am concerned. If all these platforms can guarantee
returning correct UTC time, I do not see why we would not introduce
it.
Afaik the original point
In our previous episode, Jonas Maebe said:
I know nothing about OS/2-eCS, but the same arguments as for Go32V2
apply as far as I am concerned. If all these platforms can guarantee
returning correct UTC time, I do not see why we would not introduce
it.
Afaik the original point was
In our previous episode, Michael Van Canneyt said:
Could be. I thought that was the old situation, but assumed now that
timezone is an userland thing, it returned the HW clock. But I assume it
needs some form of timezone too for certain protocols.
So who maintains the difference between
On Fri, Dec 9, 2011 at 2:00 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
Afaik the original point was that some people were interested in some kind
of timestamp that does not jump around (except possibly when overflowing). I
don't think anyone particularly needed the time in UTC.
I
On Fri, Dec 9, 2011 at 2:00 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
Afaik the original point was that some people were interested in some kind
of timestamp that does not jump around (except possibly when overflowing). I
don't think anyone particularly needed the time in UTC.
Use case
aha, the implementation of NowUTC is a bit more complex then I thought =D
I tested it in Mac OS X and in a linux in a virtual machine and it
worked perfectly, but now I tested in a linux machine and it failed
... and I just found that in my system I have:
/etc/sysconfig/clock
UTC=false --
Hello,
How can one call clock_gettime ? I couldn't find a fp prefixed routine
for it ...
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Am 09.12.2011 02:08, schrieb Hans-Peter Diettrich:
I also could not find an option to make the Makefile use a different
OSTARGET - it always seems to use the current system settings. Even if
some cross-platform information may be desireable in the documentation,
some essentially
Am 09.12.2011 13:30, schrieb Michael Schnell:
On 12/09/2011 01:17 PM, Felipe Monteiro de Carvalho wrote:
I would like to define it like this: FPGetTickCount returns the
amount of ticks since an unspecified initial time. This initial time
is unknown, but is fixed for the entire duration of the
Am 09.12.2011 14:44, schrieb Felipe Monteiro de Carvalho:
Hello,
How can one call clock_gettime ? I couldn't find a fp prefixed routine
for it ...
You might need to add it then if it does not exist... (I don't know what
the rules are for adding a new function for a syscall though)
On Fri, 9 Dec 2011, Felipe Monteiro de Carvalho wrote:
Hello,
How can one call clock_gettime ? I couldn't find a fp prefixed routine
for it ...
I have this on my todo list.
The main problem is that I don't know yet if it is Linux-specific or Posix.
That will determine which unit it will
Michael Van Canneyt schrieb:
And as long as it is not 100% documented, it will not be added.
In other words, the windows unit will probably never make it in the
official docs.
At least TSystemTime is declared there, used in GetLocalTime (Win32
platform). Dunno about other types or
Michael Van Canneyt schrieb:
2. Placy a dummy routine which returns 'now' in sysutils.inc
{$IFNDEF FPC_HAS_NOWUTC}
function NowUTC : TDateTime;
begin
Result:=Now;
end;
{$ENDIF}
IMO the dummy routine should return some error value, e.g. zero or NaN,
that makes it clear to the user that
In our previous episode, Felipe Monteiro de Carvalho said:
On Fri, Dec 9, 2011 at 2:00 PM, Jonas Maebe jonas.ma...@elis.ugent.be
wrote:
Afaik the original point was that some people were interested in some kind
of timestamp that does not jump around (except possibly when overflowing).
In our previous episode, Michael Van Canneyt said:
for it ...
I have this on my todo list.
The main problem is that I don't know yet if it is Linux-specific or Posix.
That will determine which unit it will be added to. Maybe Marco knows more ?
No idea.
But maybe IMHO this kind of stuff
In our previous episode, Felipe Monteiro de Carvalho said:
[ Charset ISO-8859-1 unsupported, converting... ]
aha, the implementation of NowUTC is a bit more complex then I thought =D
I tested it in Mac OS X and in a linux in a virtual machine and it
worked perfectly, but now I tested in a
On Fri, Dec 9, 2011 at 3:02 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
The main problem is that I don't know yet if it is Linux-specific or Posix.
That will determine which unit it will be added to. Maybe Marco knows more ?
Wow, timing in UNIX is such a mess, it seams that
On Fri, 9 Dec 2011, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
for it ...
I have this on my todo list.
The main problem is that I don't know yet if it is Linux-specific or Posix.
That will determine which unit it will be added to. Maybe Marco knows more ?
On 09/12/11 14:02, Michael Van Canneyt wrote:
On Fri, 9 Dec 2011, Felipe Monteiro de Carvalho wrote:
Hello,
How can one call clock_gettime ? I couldn't find a fp prefixed routine
for it ...
I have this on my todo list.
The main problem is that I don't know yet if it is Linux-specific or
On 12/09/2011 02:52 PM, Sven Barth wrote:
The description of Felipe mathes Windows' GetTickCount (number of
milliseconds since system start) and Linux' MONOTONIC_RAW time (or
however it is called exactly). So I don't see why this should rule out
OS time API calls...
He writes: Ticks are
On 09 Dec 2011, at 14:14, Felipe Monteiro de Carvalho wrote:
On Fri, Dec 9, 2011 at 2:00 PM, Jonas Maebe
jonas.ma...@elis.ugent.be wrote:
Afaik the original point was that some people were interested in
some kind
of timestamp that does not jump around (except possibly when
overflowing). I
On Fri, 9 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
And as long as it is not 100% documented, it will not be added.
In other words, the windows unit will probably never make it in the
official docs.
At least TSystemTime is declared there, used in GetLocalTime
On Fri, Dec 9, 2011 at 3:11 PM, Marco van de Voort mar...@stack.nl wrote:
But maybe IMHO this kind of stuff should remain out of sysutils, certainly now
it is not entirely clear, and people are still searching for solutions.
NowUTC is not any less portable then Now in relevant platforms.
My
Am 09.12.11 15:19, schrieb Michael Van Canneyt:
That's not the question.
clock_gettime is a linux kernel call. No-one is proposing to add it to
sysutils.
The question is whether clock_gettime is POSIX, and if BSD has it.
The linux man page seems to say it is POSIX 2001. My question is if
On Friday 09 of December 2011 14:52:56 Sven Barth wrote:
Am 09.12.2011 13:30, schrieb Michael Schnell:
On 12/09/2011 01:17 PM, Felipe Monteiro de Carvalho wrote:
I would like to define it like this: FPGetTickCount returns the
amount of ticks since an unspecified initial time. This initial
On Fri, Dec 9, 2011 at 3:37 PM, zeljko zel...@holobit.net wrote:
No, MONOTONIC_RAW is introduced in 2.6.26 afair, so it won't run on older
kernels.
My ideas was: Check if MONOTONIC_RAW is available, if yes, use it, if
not, fallback to MONOTONIC which is a close approximation, not
perfect, but
In our previous episode, Michael Van Canneyt said:
But maybe IMHO this kind of stuff should remain out of sysutils, certainly
now
it is not entirely clear, and people are still searching for solutions.
That's not the question.
clock_gettime is a linux kernel call. No-one is
On Fri, Dec 9, 2011 at 3:16 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
He did not expose any holes in any argument. He simply said that Go32v2 and
OS/2 can be ignored as far as any potential implementation problems are
concerned because Go32v2 and to a (much) lesser extent OS/2 do not
On Friday 09 of December 2011 15:42:20 Marco van de Voort wrote:
FreeBSD has it. But OS X hasn't it seems, not even in recent versions.
Yes, there's many posts and arguing from OSX developers about this.
zeljko
___
fpc-devel maillist -
On Fri, December 9, 2011 13:17, Felipe Monteiro de Carvalho wrote:
2011/12/9 Tomas Hajny xhaj...@hajny.biz:
Is it preferred to return ticks (dependent on various stuff), or
something
like GetMsCount (as already existing in unit Dos)?
I would like to define it like this:
FPGetTickCount
In our previous episode, Marco van de Voort said:
In our previous episode, Michael Van Canneyt said:
But maybe IMHO this kind of stuff should remain out of sysutils,
certainly now
it is not entirely clear, and people are still searching for solutions.
That's not the question.
On Fri, Dec 9, 2011 at 3:42 PM, Marco van de Voort mar...@stack.nl wrote:
FreeBSD has it. But OS X hasn't it seems, not even in recent versions.
I'm not sure if Mac OS X has it, but it doesn't work (returns failure
or something) or if it doesn't have it at all.
--
Felipe Monteiro de Carvalho
On Fri, December 9, 2011 13:47, Michael Van Canneyt wrote:
On Fri, 9 Dec 2011, Tomas Hajny wrote:
On Fri, December 9, 2011 13:07, Jonas Maebe wrote:
On 09 Dec 2011, at 12:28, Michael Van Canneyt wrote:
The linux kernel returns UTC time, it always has. Now() converts
this to local time.
(as
Sven Barth schrieb:
Just as a sidenote: unit Dos is platform independant (every (full)
target has one and the common parts reside in dos.inc and dosh.inc in
%fpcdir%\rtl\inc)
Ah, thanks.
Then Go32v2 is the (MS?)Dos platform?
Looks now as if platforms reside in the rtl subdirectories,
Jonas Maebe schrieb:
On 09 Dec 2011, at 13:47, Michael Van Canneyt wrote:
I know nothing about OS/2-eCS, but the same arguments as for Go32V2
apply as far as I am concerned. If all these platforms can guarantee
returning correct UTC time, I do not see why we would not introduce it.
Afaik
On Fri, 9 Dec 2011, Marco van de Voort wrote:
In our previous episode, Marco van de Voort said:
In our previous episode, Michael Van Canneyt said:
But maybe IMHO this kind of stuff should remain out of sysutils, certainly now
it is not entirely clear, and people are still searching for
2011/12/9 Tomas Hajny xhaj...@hajny.biz:
Wouldn't the use be limited by the fact that the length of time is not
specified at all?
Yes, this limits the usefulness of the routine. I added it to simplify
the implementation and match Windows.GetTickCount64 and MONOTONIC_RAW,
but if someone can come
In our previous episode, Michael Van Canneyt said:
clock_gettime is a linux kernel call. No-one is proposing to add it to
sysutils.
If we decide to use it via libc, we might not have to add it as a syscall.
That sounds as if you think a syscall is a bad thing ?
For borderline
On Fri, 9 Dec 2011, Jonas Maebe wrote:
it also solves the problem that some targets may not support returning the
time in UTC.
I think that Michael already exposed more then enough the holes in
this argument.
He did not expose any holes in any argument. He simply said that Go32v2 and
Well, if OS-X does not have it, we can't really say it is POSIX for
our purposes, so then it goes to the linux unit. It's as simple as that.
Only if you discriminate BSD systems :-) - Many professional vendors
use some sort of BSD in their products,
and some fpc.
Freebsd, Netbsd, Openbsd,
On Fri, 9 Dec 2011, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
Just as a sidenote: unit Dos is platform independant (every (full) target
has one and the common parts reside in dos.inc and dosh.inc in
%fpcdir%\rtl\inc)
Ah, thanks.
Then Go32v2 is the (MS?)Dos platform?
Yes.
Am 09.12.2011 14:49, schrieb Hans-Peter Diettrich:
Michael Van Canneyt schrieb:
2. Placy a dummy routine which returns 'now' in sysutils.inc
{$IFNDEF FPC_HAS_NOWUTC}
function NowUTC : TDateTime;
begin
Result:=Now;
end;
{$ENDIF}
IMO the dummy routine should return some error value, e.g. zero
On Fri, 9 Dec 2011, Marco van de Voort wrote:
Well, if OS-X does not have it, we can't really say it is POSIX for our
purposes,
so then it goes to the linux unit. It's as simple as that.
Unless you have arguments for putting it in (base)unix anyway.
No. Better put it in target specific
Am 09.12.2011 15:37, schrieb zeljko:
On Friday 09 of December 2011 14:52:56 Sven Barth wrote:
Am 09.12.2011 13:30, schrieb Michael Schnell:
On 12/09/2011 01:17 PM, Felipe Monteiro de Carvalho wrote:
I would like to define it like this: FPGetTickCount returns the
amount of ticks
Am 09.12.2011 15:22, schrieb Michael Schnell:
On 12/09/2011 02:52 PM, Sven Barth wrote:
The description of Felipe mathes Windows' GetTickCount (number of
milliseconds since system start) and Linux' MONOTONIC_RAW time (or
however it is called exactly). So I don't see why this should rule out
OS
On Fri, Dec 9, 2011 at 4:04 PM, Marco van de Voort mar...@stack.nl wrote:
It is something else to avoid the core system getting to entangled with
libc, but that doesn't mean I want to reimplement all libc of all unixy
platforms and maintain that.
Why do we provide our own memory manager
Am 09.12.2011 16:07, schrieb Tomas Hajny:
Looks now as if platforms reside in the rtl subdirectories, except
common, inc and objpas?
Right, just add subdirectories created to support a group of platforms
(e.g. unix and win which are not specific platforms but rather
platform groups).
And of
Am 09.12.2011 16:19, schrieb Felipe Monteiro de Carvalho:
On Fri, Dec 9, 2011 at 4:04 PM, Marco van de Voortmar...@stack.nl wrote:
It is something else to avoid the core system getting to entangled with
libc, but that doesn't mean I want to reimplement all libc of all unixy
platforms and
In our previous episode, Michael Van Canneyt said:
No problem.
I will do it so, I was leaning to this anyway based on the mails of Zeljko
some
weeks back where the OSX issue was already touched upon.
I just wanted to know the POSIX situation first, and now that's cleared up.
Btw,
On Fri, 9 Dec 2011, Helmut Hartl wrote:
Well, if OS-X does not have it, we can't really say it is POSIX for our
purposes, so then it goes to the linux unit. It's as simple as that.
Only if you discriminate BSD systems :-) - Many professional vendors use
some sort of BSD in their
On Fri, 9 Dec 2011, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
No problem.
I will do it so, I was leaning to this anyway based on the mails of Zeljko some
weeks back where the OSX issue was already touched upon.
I just wanted to know the POSIX situation
In our previous episode, Felipe Monteiro de Carvalho said:
It is something else to avoid the core system getting to entangled with
libc, but that doesn't mean I want to reimplement all libc of all unixy
platforms and maintain that.
Why do we provide our own memory manager anyway?
Because
On 09/12/11 14:22, Michael Schnell wrote:
On 12/09/2011 02:52 PM, Sven Barth wrote:
The description of Felipe mathes Windows' GetTickCount (number of
milliseconds since system start) and Linux' MONOTONIC_RAW time (or
however it is called exactly). So I don't see why this should rule out
OS
On Fri, December 9, 2011 16:04, Michael Van Canneyt wrote:
On Fri, 9 Dec 2011, Jonas Maebe wrote:
it also solves the problem that some targets may not support returning
the
time in UTC.
I think that Michael already exposed more then enough the holes in
this argument.
He did not expose
In our previous episode, Michael Van Canneyt said:
Freebsd, Netbsd, Openbsd, and Linux has it.
For OSX there is a substitution:
http://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-mac-os-x
Well, you'll have to convince Marco.
But I think it's that time of the
On 09/12/11 15:15, Sven Barth wrote:
Am 09.12.2011 15:22, schrieb Michael Schnell:
On 12/09/2011 02:52 PM, Sven Barth wrote:
The description of Felipe mathes Windows' GetTickCount (number of
milliseconds since system start) and Linux' MONOTONIC_RAW time (or
however it is called exactly). So I
On 12/09/2011 04:31 PM, Henry Vermaak wrote:
On Linux, get_jiffies_64() seems to be a decent Kernel call.
Rechecking, I found that you are correct, this is a Kernel-internal call.
On a quick search, I in fact did not find a userland api call for
getting the current jiffie value (but I
On 09/12/11 15:23, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
No problem.
I will do it so, I was leaning to this anyway based on the mails of Zeljko some
weeks back where the OSX issue was already touched upon.
I just wanted to know the POSIX situation first,
Am 09.12.11 16:25, schrieb Michael Van Canneyt:
On Fri, 9 Dec 2011, Helmut Hartl wrote:
Well, if OS-X does not have it, we can't really say it is POSIX for
our purposes, so then it goes to the linux unit. It's as simple as
that.
Only if you discriminate BSD systems :-) - Many
In our previous episode, Henry Vermaak said:
them, instead of pulling this into the core. (iow, like the users package)
I don't understand. Why link to libc for these? They are syscalls, if
Are they? On any OS and arch that calls itself posix or unix?
Or maybe, the question should be
On Fri, 9 Dec 2011, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Freebsd, Netbsd, Openbsd, and Linux has it.
For OSX there is a substitution:
http://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-mac-os-x
Well, you'll have to convince
On Fri, 9 Dec 2011, Tomas Hajny wrote:
Thanks, but don't worry, I didn't take personally. ;-) I know the proper
solution for both GO32v2 and OS/2 (and probably also other platforms not
providing native support of timezone handling). As mentioned previously,
this solution is based on parsing
On Friday 09 of December 2011 16:10:54 Sven Barth wrote:
Am 09.12.2011 15:37, schrieb zeljko:
On Friday 09 of December 2011 14:52:56 Sven Barth wrote:
Am 09.12.2011 13:30, schrieb Michael Schnell:
On 12/09/2011 01:17 PM, Felipe Monteiro de Carvalho wrote:
I would like to define it
Am 09.12.2011 16:40, schrieb Marco van de Voort:
In our previous episode, Henry Vermaak said:
them, instead of pulling this into the core. (iow, like the users package)
I don't understand. Why link to libc for these? They are syscalls, if
Are they? On any OS and arch that calls itself
On 9-12-2011 14:02, Marco van de Voort wrote:
In our previous episode, Jonas Maebe said:
I know nothing about OS/2-eCS, but the same arguments as for Go32V2
apply as far as I am concerned. If all these platforms can guarantee
returning correct UTC time, I do not see why we would not introduce
Am 09.12.2011 16:44, schrieb zeljko:
On Friday 09 of December 2011 16:10:54 Sven Barth wrote:
Am 09.12.2011 15:37, schrieb zeljko:
On Friday 09 of December 2011 14:52:56 Sven Barth wrote:
Am 09.12.2011 13:30, schrieb Michael Schnell:
On 12/09/2011 01:17 PM, Felipe Monteiro de
On Fri, Dec 9, 2011 at 4:30 PM, Marco van de Voort mar...@stack.nl wrote:
IMHO that should have been done in the first place. First research and find
a workable, portable way, and only then put it up for inclusion.
Well, I was expecting a lot more of discussions about how to do it,
maybe even
In our previous episode, Michael Van Canneyt said:
Well, you'll have to convince Marco.
But I think it's that time of the month, when he's hard to convince, just
for the fun of discussion :)
Strange. I had the same feeling. Something random functionality HAD to be
put in, damn the
On 09/12/11 15:40, Marco van de Voort wrote:
In our previous episode, Henry Vermaak said:
them, instead of pulling this into the core. (iow, like the users package)
I don't understand. Why link to libc for these? They are syscalls, if
Are they? On any OS and arch that calls itself posix
In our previous episode, Sven Barth said:
In our previous episode, Henry Vermaak said:
them, instead of pulling this into the core. (iow, like the users package)
I don't understand. Why link to libc for these? They are syscalls, if
Are they? On any OS and arch that calls itself posix
In our previous episode, Thaddy said:
kind of timestamp that does not jump around (except possibly when
overflowing). I don't think anyone particularly needed the time in
UTC. Therefore, something like FPGetTickCount seems much more
appropriate than NowUTC, and it also solves the problem
In our previous episode, Henry Vermaak said:
Or maybe, the question should be the opposite, why not? Why shouldn't such
peripheral calls NOT be taken from libc?
Because you don't have to link to libc when you have a syscall?
True. You just have to maintain the syscall. And polish away
Am 09.12.2011 16:58, schrieb Marco van de Voort:
Also I personally(!) prefer direct linkage to the kernel.
Not always. See e.g. the readdir situation. Limiting the number of syscalls
drastically speeds up the process.
In Windows you also often call user32, not kernel32.
user32 is the
Am 09.12.2011 16:54, schrieb Felipe Monteiro de Carvalho:
On Fri, Dec 9, 2011 at 4:30 PM, Marco van de Voortmar...@stack.nl wrote:
IMHO that should have been done in the first place. First research and find
a workable, portable way, and only then put it up for inclusion.
Well, I was
On Fri, 9 Dec 2011, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Well, you'll have to convince Marco.
But I think it's that time of the month, when he's hard to convince, just for
the fun of discussion :)
Strange. I had the same feeling. Something random
On Fri, 9 Dec 2011, Sven Barth wrote:
Am 09.12.2011 16:54, schrieb Felipe Monteiro de Carvalho:
On Fri, Dec 9, 2011 at 4:30 PM, Marco van de Voortmar...@stack.nl wrote:
IMHO that should have been done in the first place. First research and
find
a workable, portable way, and only then put
1 - 100 of 104 matches
Mail list logo
