[bug #18617] Better debugging facilities: tracing rule invocation.

2007-05-11 Thread Paul D. Smith
Update of bug #18617 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System:

[bug #16389] Defaults for Objective-C

2007-05-11 Thread Paul D. Smith
Update of bug #16389 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

Re: Build warnings in CVS make 3.81.90

2007-05-11 Thread Paul Smith
On Sat, 2007-04-28 at 15:26 +0100, Jon Grant wrote: > A wider query relating to these warnings is that since make 3.81 is > released now, could we change make to use const's instead of #define'd > values, and inline functions instead of #define macro expressions? No... well, at least not inline

Re: 33 make check failures on Ubuntu Linux

2007-05-11 Thread Paul Smith
On Sat, 2007-04-28 at 15:22 +0100, Jon Grant wrote: > Could this message below be updated to remind that "make update" is > needed to download the po files? That message is generated from the standard gettext build environment, that is provided by the gettext package. It's not part of the GNU ma

Re: Offer to help

2007-05-11 Thread Daniel Kraft
I will see what else we have going on, code-wise. Of course there a number of other things; for example our test suite, while extensive, has some significant problems and could use some reworking. There are a number of issues with it that I can discuss with you if you're interested (the test sui

Re: Offer to help

2007-05-11 Thread Paul Smith
On Tue, 2007-05-08 at 19:26 +, Daniel Kraft wrote: > I hope there's still some work to do here, but that should, of course, > be surely the case. Hi Daniel; Definitely there are many things to be done. One complicating factor is that GNU make was awarded a Google Summer of Code slot, so some

Re: timestamp resolution

2007-05-11 Thread Hans Aberg
On 10 May 2007, at 20:42, Joseph M Gwinn wrote: The POSIX.1 standard is very specific, and each and every word was hard-fought. I would parse it (and the corresponding Rationale) very slowly and carefully. Even the things not said are important. There is no intent to put astronomical or attos

Re: timestamp resolution

2007-05-11 Thread Joseph M Gwinn
Hans, Hans Aberg <[EMAIL PROTECTED]> wrote on 05/10/2007 09:09:59 AM: > On 9 May 2007, at 16:30, Joseph M Gwinn wrote: > > > In fact, POSIX "Seconds Since the Epoch" is effectively TAI minus an > > unspecified offset because POSIX counts ~SI seconds regardless of > > astronomy and thus leap anyt

Re: timestamp resolution

2007-05-11 Thread Hans Aberg
On 10 May 2007, at 15:29, Giacomo A. Catenazzi wrote: I think the specs ignore the issue, so it is only accurate within a couple of ten seconds. I figure typical system just ignore the leap seconds from the epoch, and adjusts the internal clock on the first lookup after the time server has

Re: timestamp resolution

2007-05-11 Thread Giacomo A. Catenazzi
Hans Aberg wrote: On 9 May 2007, at 16:30, Joseph M Gwinn wrote: In fact, POSIX "Seconds Since the Epoch" is effectively TAI minus an unspecified offset because POSIX counts ~SI seconds regardless of astronomy and thus leap anything. I think the specs ignore the issue, so it is only accurate

Re: timestamp resolution

2007-05-11 Thread Hans Aberg
On 9 May 2007, at 16:30, Joseph M Gwinn wrote: In fact, POSIX "Seconds Since the Epoch" is effectively TAI minus an unspecified offset because POSIX counts ~SI seconds regardless of astronomy and thus leap anything. I think the specs ignore the issue, so it is only accurate within a couple o

Re: timestamp resolution

2007-05-11 Thread Hans Aberg
On 9 May 2007, at 16:45, Donn Terry wrote: It is simply NOT possible to satisfy both the timestamp-for-system-events needs of the real time people (who really want attosecond resolution -- maybe only 10s or 100s, but really tiny) and the huge range needed for astronomical needs. The system ti