Hi,
James Youngman writes:
> On Tue, Jul 27, 2010 at 12:32 AM, Bruno Haible wrote:
>> [Adding James to the CC]
>>
>>> > We’d like to use ‘stat-time’ in libguile, but libguile is LGPLv3+.
>>> > Could you make the license change?
>>>
>>> Or LGPL v2.1+ too.
>>>
>>> Anyway, CCed the other contribut
Continuing with M4 branch-1.4 failures on AIX 5.3:
@ ../doc/m4.texinfo:5688: Origin of test
../../m4/checks/164.regexp: stdout mismatch
*** m4-tmp.569356/m4-xout Wed Aug 25 19:05:46 2010
--- m4-tmp.569356/m4-outWed Aug 25 19:05:46 2010
***
*** 1,4
! 5
! -1
*** Unix
On 08/25/2010 01:03 PM, Ralf Wildenhues wrote:
This is the output from 'truss ./test-rmdir':
[...]
rmdir("test-rmdir.tdir/file/") Err#20 ENOTDIR
rmdir("test-rmdir.tdir")Err#17 EEXIST
rmdir("test-rmdir.tdir/file") Err#20 ENOTDIR
unlink("te
* Eric Blake wrote on Mon, Aug 23, 2010 at 04:04:54PM CEST:
> On 08/21/2010 02:42 AM, Ralf Wildenhues wrote:
> >- 2 gnulib test failures in M4: test-strtod, test-rmdir.
> >
> >I inserted one fprintf in test-strtod.c, for the "0xp" input asserting
> >over 'ptr == input + 1':
>
> The strtod problem
On 08/25/2010 06:51 PM, Erik Faye-Lund wrote:
On Wed, Aug 25, 2010 at 11:50 AM, Paolo Bonzini wrote:
On 08/25/2010 11:48 AM, Erik Faye-Lund wrote:
Actually, when I think of it - if any pipe got POLLHUP already,
shouldn't poll just return right away? I mean, we already have an
event, waiting i
On Wed, Aug 25, 2010 at 11:50 AM, Paolo Bonzini wrote:
> On 08/25/2010 11:48 AM, Erik Faye-Lund wrote:
>>
>> Actually, when I think of it - if any pipe got POLLHUP already,
>> shouldn't poll just return right away? I mean, we already have an
>> event, waiting in that case seems wrong to me.
>
> Yo
On 08/24/2010 04:28 PM, Eric Blake wrote:
On 08/24/2010 03:41 PM, Paul Eggert wrote:
On 08/24/2010 02:13 PM, Eric Blake wrote:
Thanks. Are you planning on syncing this back to gnulib as well?
No, I hadn't thought of that; thanks for reminding me. Here's
what I installed:
From bde8be8f5dd110
On 08/25/2010 11:48 AM, Erik Faye-Lund wrote:
Actually, when I think of it - if any pipe got POLLHUP already,
shouldn't poll just return right away? I mean, we already have an
event, waiting in that case seems wrong to me.
You would have to see what POSIX says.
I'll cook up a new patch. Do yo
On Wed, Aug 25, 2010 at 9:24 AM, Paolo Bonzini wrote:
> On 08/24/2010 10:58 PM, Erik Faye-Lund wrote:
>>
>> Hi, after debugging the Win32-emulation of poll a bit more I think
>> I've found another problem with it. If all fds are pipes and have been
>> hanged up and the timeout is -1, poll() stalls
On 08/25/2010 11:12 AM, Bruno Haible wrote:
Hi Paolo,
I'm happy to deprecate the select module, since in general poll(2) is a
superior interface.
I wouldn't want to deprecate it, because
Sorry, I'm talking about the Win32 emulation code only.
By the way, the test failures are as far as I c
Hi Paolo,
> I'm happy to deprecate the select module, since in general poll(2) is a
> superior interface.
I wouldn't want to deprecate it, because
- It's working fine (better than the 'poll' module which fails its tests
on various systems: Solaris [1], Cygwin [2], mingw [3]).
- It is by n
On 08/24/2010 10:58 PM, Erik Faye-Lund wrote:
Hi, after debugging the Win32-emulation of poll a bit more I think
I've found another problem with it. If all fds are pipes and have been
hanged up and the timeout is -1, poll() stalls infinitely at
MsgWaitForMultipleObjects(). That's because there's
12 matches
Mail list logo
