On 09/25/2011 11:46 PM, Bastien ROUCARIES wrote:
Did you seehttp://bugs.python.org/issue4804 ?
Particularlyhttp://bugs.python.org/file12953/__pioinfo.patch
A little bit hackhish but seems to work
That would provide a lot more flexibility, including:
* the ability to implement O_INHERIT
Hi Stefano,
On 25 Sep 2011, at 22:55, Stefano Lattarini wrote:
On Thursday 22 September 2011, Gary V wrote:
Anyone:
It's beginning to look as though all this work is, once again, in very
real danger of just slipping quietly through the cracks.
Hi Gary. While I don't pretend to really
Gijs van Tulder gvtul...@gmail.com writes:
Simon Josefsson wrote:
Once the copyright papers are resolved, I can commit it
unless someone else beats me to it.
Hi. The copyright should be solved now. I've attached the patch for
the base32 module again. (I've changed the RFC reference to point
On Mon, Sep 26, 2011 at 9:01 AM, Paolo Bonzini bonz...@gnu.org wrote:
On 09/25/2011 11:46 PM, Bastien ROUCARIES wrote:
Did you seehttp://bugs.python.org/issue4804 ?
Particularlyhttp://bugs.python.org/file12953/__pioinfo.patch
A little bit hackhish but seems to work
That would provide a
On 09/26/2011 10:37 AM, Bastien ROUCARIES wrote:
python seehttp://svn.python.org/projects/python/trunk/Modules/posixmodule.c
seems to have solved a lot the maintenabilty stuff by determining the
actual size of the structure is determined at runtime.
Still hackish, though slightly better. What
Particularlyhttp://bugs.python.org/file12953/__pioinfo.patch
A little bit hackhish but seems to work
...
However, it is bad that these data structures can change for every
version of MSVC.
Additionally, there's a legal problem here: Code like
+#define IOINFO_L2E 5
+#define
On 09/26/2011 11:01 AM, Bruno Haible wrote:
Additionally, there's a legal problem here: Code like
Stopped reading here. Do not include snippets, we _can_ do clean-room
reverse engineering if necessary.
We can also take code from Wine's MSVCRT implementation if need be, so
that at least it
On Mon, Sep 26, 2011 at 11:06 AM, Paolo Bonzini bonz...@gnu.org wrote:
On 09/26/2011 11:01 AM, Bruno Haible wrote:
Additionally, there's a legal problem here: Code like
Stopped reading here. Do not include snippets, we _can_ do clean-room
reverse engineering if necessary.
We can also take
On Monday 26 September 2011, Gary V wrote:
Hi Stefano,
On 25 Sep 2011, at 22:55, Stefano Lattarini wrote:
On Thursday 22 September 2011, Gary V wrote:
Anyone:
It's beginning to look as though all this work is, once again, in very
real danger of just slipping quietly through the
On Monday 26 September 2011, Gary V wrote:
@cnindex gnulib_precious
@item gnulib_precious
Normally, @command{bootstrap} removes any macro-files that are not
included by @file{aclocal.m4} before it returns, except for files
listed in this variable which are always kept.
Are you sure
Hi Stefano!
[[Items I agree with elided]]
On 26 Sep 2011, at 17:27, Stefano Lattarini wrote:
On Monday 26 September 2011, Gary V wrote:
On 25 Sep 2011, at 22:55, Stefano Lattarini wrote:
On Thursday 22 September 2011, Gary V wrote:
Anyone:
It's beginning to look as though all this work
Hi Stefano,
On 26 Sep 2011, at 18:06, Stefano Lattarini wrote:
On Monday 26 September 2011, Gary V wrote:
@cnindex gnulib_precious
@item gnulib_precious
Normally, @command{bootstrap} removes any macro-files that are not
included by @file{aclocal.m4} before it returns, except for files
On 09/24/2011 06:11 PM, Bruno Haible wrote:
* modules/fclose-tests (Depends-on): Add fdopen.
* modules/fflush-tests (Depends-on): Likewise.
* modules/fgetc-tests (Depends-on): Likewise.
* modules/fputc-tests (Depends-on): Likewise.
* modules/fread-tests
On Monday 26 September 2011, Gary V wrote:
Maybe some code like this should be enough to catch most potential
erroneous definitions?
case $po_download_command_format in
*[^%]%s*[^%]%s*) ;;
*) fatal invalid format in \$po_download_command_format;;
esac
That's better
On Monday 26 September 2011, Gary V wrote:
Hi Stefano!
Hi Gary, thanks for your quick and detailed answers.
[[Items I agree with elided]]
Ditto.
On 26 Sep 2011, at 17:27, Stefano Lattarini wrote:
Do you have a diff file to show what you've changed exactly? I'd find that
really helpful.
* m4/dup2.m4 (gl_PREREQ_DUP2): Don't require AC_C_INLINE,
as lib/dup2.c no longer uses 'inline'.
diff --git a/m4/dup2.m4 b/m4/dup2.m4
index 6385b0c..cd9d254 100644
--- a/m4/dup2.m4
+++ b/m4/dup2.m4
@@ -1,4 +1,4 @@
-#serial 15
+#serial 16
dnl Copyright (C) 2002, 2005, 2007, 2009-2011 Free Software
Hi,
The copy of gnulib.mk in Emacs says:
# This file is free software, distributed under the terms of the GNU
# General Public License. As a special exception to the GNU General
# Public License, this file may be distributed as part of a program
# that contains a configuration
Hi Simon,
Thanks for accepting the patch.
Simon Josefsson writes:
There seems to be some memory leaks in the self-tests, although maybe
they are inherited from the base64 self-test?
The memory leaks seem to be related to the tests. The exact same memory
leaks appear in the base64 tests as
Glenn Morris r...@gnu.org writes:
Hi,
The copy of gnulib.mk in Emacs says:
# This file is free software, distributed under the terms of the GNU
# General Public License. As a special exception to the GNU General
# Public License, this file may be distributed as part of a
On 09/26/2011 11:58 AM, Gijs van Tulder wrote:
Hi Simon,
Thanks for accepting the patch.
Simon Josefsson writes:
There seems to be some memory leaks in the self-tests, although maybe
they are inherited from the base64 self-test?
The memory leaks seem to be related to the tests. The exact
Is linebuffer obsoleteable in the face of standardized getline and friends?
--
http://rrt.sc3d.org
Simon Josefsson wrote:
The copy of gnulib.mk in Emacs says:
# This file is free software, distributed under the terms of the GNU
# General Public License. As a special exception to the GNU General
# Public License, this file may be distributed as part of a program
#
[Dropping cygwin list from CC.]
Charles Wilson wrote:
in cygwin libintl is expected to place in /bin so there's no use
of relocatable.
Right, and it is intended that, in the cygwin official packages, both
libiconv and libintl are built without relocation support. If that
isn't true,
On 09/26/2011 03:47 PM, Reuben Thomas wrote:
Is linebuffer obsoleteable in the face of standardized getline and friends?
Not necessarily, because linebuffer provides a slightly different
interface that might be easier to use. However, I do argue that both
linebuffer and getdelim can be
On 09/26/11 10:40, Glenn Morris wrote:
There's no information about which version of the GPL.
m4/gl-comp.m4 seems to have the same issue.
Thanks for mentioning this. Iif it bothers you it may bother someone
else, and it's not that hard to clarify, so I changed it in gnulib
with the patch
On 26 September 2011 23:04, Eric Blake ebl...@redhat.com wrote:
On 09/26/2011 03:47 PM, Reuben Thomas wrote:
Is linebuffer obsoleteable in the face of standardized getline and
friends?
Not necessarily, because linebuffer provides a slightly different interface
that might be easier to use.
Hi Reuben,
Is linebuffer obsoleteable in the face of standardized getline and friends?
I'm not the maintainer of either of these modules, but I don't consider
'linebuffer' to be obsolete.
Whenever I have to understand the calling convention of getline(), I get dizzy.
What will happen if
Paolo Bonzini asked:
* modules/fclose-tests (Depends-on): Add fdopen.
* modules/fflush-tests (Depends-on): Likewise.
* modules/fgetc-tests (Depends-on): Likewise.
* modules/fputc-tests (Depends-on): Likewise.
* modules/fread-tests (Depends-on): Likewise.
*
On 09/26/2011 04:06 PM, Reuben Thomas wrote:
On 26 September 2011 23:04, Eric Blakeebl...@redhat.com wrote:
On 09/26/2011 03:47 PM, Reuben Thomas wrote:
Is linebuffer obsoleteable in the face of standardized getline and
friends?
Not necessarily, because linebuffer provides a slightly
On 26 September 2011 23:19, Eric Blake ebl...@redhat.com wrote:
But a patch for both modules that references the other may indeed be
worthwhile.
Great, I'll write something (and I find your arguments convincing). At
the moment the short descriptions in the module files are identical,
which is
On 09/26/2011 04:04 PM, Eric Blake wrote:
On 09/26/2011 03:47 PM, Reuben Thomas wrote:
Is linebuffer obsoleteable in the face of standardized getline and
friends?
Not necessarily, because linebuffer provides a slightly different
interface that might be easier to use. However, I do argue that
On 09/26/2011 04:17 PM, Bruno Haible wrote:
Paolo Bonzini asked:
* modules/fclose-tests (Depends-on): Add fdopen.
* modules/fflush-tests (Depends-on): Likewise.
* modules/fgetc-tests (Depends-on): Likewise.
* modules/fputc-tests (Depends-on): Likewise.
*
On 09/26/2011 04:30 PM, Eric Blake wrote:
If fdopen(-1,r) returns anything besides NULL in the first place, then
that is a bug in fdopen().
All right, POSIX states that EBADF is a may fail, rather than a shall
fail, in that situation. But do we know of any implementations that
actually
Hi Eric,
If fdopen(-1,r) returns anything besides NULL in the first place, then
that is a bug in fdopen().
Nope. POSIX:2008 says in
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fdopen.html:
The fdopen() function MAY fail if:
[EBADF]
The fildes argument is not a
On 09/26/2011 04:40 PM, Bruno Haible wrote:
On glibc systems (and probably many others as well), the invalid file
descriptor is already caught by fdopen(). But there is no guarantee that
all systems do this.
But this is gnulib. _We_ can make that guarantee for all systems, via
the fdopen
35 matches
Mail list logo
