Hi,
On Wed, Feb 16, 2011 at 09:07:46AM +0100, Mark Kettenis wrote:
From: Van de Bugger van.de.bug...@gmail.com Date: Wed, 16 Feb 2011
00:15:52 +0300
...by using dynamically allocated buffers. No need in PATH_MAX,
MAXPATHLEN. No more Path too long errors.
Not really. Instead fopen(3)
Hi,
On Thu, Nov 25, 2010 at 07:24:29PM +0100, Luc Verhaegen wrote:
On Thu, Nov 25, 2010 at 01:05:09PM -0500, Alex Deucher wrote:
For external monitors most from the last 10 years are geared towards
10x7 or larger which seems like a sufficiently large time horizon
for bumping the default.
Hi,
On Tue, Sep 07, 2010 at 03:39:17PM +0300, Tiago Vignatti wrote:
-#ifdef SA_SIGINFO
OsSigHandler(int signo, siginfo_t *sip, void *unused)
-#else
-OsSigHandler(int signo)
-#endif
Please leave the SA_SIGINFO stuff in for now: SA_SIGINFO is
unfortunately still not implemented on the Hurd
Hi,
On Tue, Aug 17, 2010 at 03:17:09AM +0200, Samuel Thibault wrote:
To be honest, I truly don't care about the name at all. All I do care
about is to get the patch commited eventually. So give us the
variable names that shall be good and let's be done with it.
I still think mem_obj would
Hi,
On Wed, Aug 18, 2010 at 08:28:45AM +1000, Peter Hutterer wrote:
So at some point you will just have to implement it and throw it out
into the wild. I don't think 1.0 is a good version number to begin
with [...]
Why not?
Judging by everything I've seen so far, 0.x numbering schemes are
Hi,
On Tue, Jun 22, 2010 at 04:44:50PM +0200, Mark Kettenis wrote:
I don't think using system(3) would be a good idea, since it has some
nasty side-effects.
That's how UNIX works. If it has nasty side-effects, then something else
is broken.
Also, this probably wouldn't work on OpenBSD where
Hi,
On Mon, Apr 19, 2010 at 04:58:49PM +1000, Daniel Stone wrote:
On Fri, Apr 16, 2010 at 09:17:55PM +0200, olafbuddenha...@gmx.net wrote:
The whole idea of a stable branch is, well, that it's supposed to be
stable... Upgrading to a newer point release should *fix* bugs, not add
stuff
Hi,
On Tue, Apr 06, 2010 at 06:43:22PM -0700, Keith Packard wrote:
This isn't a git super-module,
Well, why not?
-antrik-
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info:
Hi,
On Wed, Apr 07, 2010 at 11:32:21AM -0500, Donnie Berkholz wrote:
On 23:14 Tue 06 Apr , Keith Packard wrote:
The people we're trying to reach with this are those people building
From source.
For people like me, who really can't rely on a distribution to be up
to date enough, I
Hi,
On Sat, Mar 13, 2010 at 02:26:26AM +0100, Samuel Thibault wrote:
diff --git a/hw/xfree86/os-support/hurd/hurd_video.c
b/hw/xfree86/os-support/hurd/hurd_video.c
index 4a99db3..e049ceb 100644
--- a/hw/xfree86/os-support/hurd/hurd_video.c
+++ b/hw/xfree86/os-support/hurd/hurd_video.c
@@
Hi,
On Tue, Sep 01, 2009 at 10:19:57AM +1000, Daniel Stone wrote:
XSERVER IS FROZEN. PLEASE DON'T COMMIT ANYTHING MAJOR, OR ANY API
BREAKS, WITHOUT CHECKING WITH ME AND/OR PETER FIRST.
1.6.99.900 will be rolled some time over the weekend, with .901 to
follow fairly shortly after that.
Hi,
On Tue, Jun 09, 2009 at 04:39:07AM -0400, Thomas Dickey wrote:
On Mon, 8 Jun 2009, olafbuddenha...@gmx.net wrote:
It is not really source code. It is a .c file, but a generated one.
The real source is the .y.
I don't know whether X.org has any policy about licensing of
generated files
Hi,
On Fri, Jun 05, 2009 at 08:20:46AM -0400, Thomas Dickey wrote:
One point to be made is that the source which was added to the tree
has additional restrictions which do not apply to other files.
It is not really source code. It is a .c file, but a generated one. The
real source is the .y.
Hi,
On Sat, May 30, 2009 at 05:26:38PM -0400, Thomas Dickey wrote:
On Sat, 30 May 2009, Jon TURNEY wrote:
The next comment block is perhaps also significant
/* As a special exception, you may create a larger work that
contains part or all of the Bison parser skeleton and distribute
14 matches
Mail list logo
