On 7/27/2012 9:23 PM, todd.tab...@gmail.com wrote:
I'm looking to search an entire XML file for specific text and
replace that text, while maintaining the structure of the XML file.
For a one-off project, or for experimentation, I would use a proper
text-editor* and run through with
On 28/07/2012 08:17, Terry Reedy wrote:
On 7/27/2012 9:23 PM, todd.tab...@gmail.com wrote:
I'm looking to search an entire XML file for specific text and
replace that text, while maintaining the structure of the XML file.
For a one-off project, or for experimentation, I would use a proper
On Sat, Jul 28, 2012 at 6:29 PM, Mark Lawrence breamore...@yahoo.co.uk wrote:
I highly recommend the use of notepad++. If anyone knows of a better text
editor for Windows please let me know :)
My current preference is SciTE, available on Linux and Windows both.
It's configured using Lua, has
On 28/07/2012 09:29, Mark Lawrence wrote:
On 28/07/2012 08:17, Terry Reedy wrote:
On 7/27/2012 9:23 PM, todd.tab...@gmail.com wrote:
I'm looking to search an entire XML file for specific text and
replace that text, while maintaining the structure of the XML file.
For a one-off project, or
On Sun, 29 Jul 2012 01:51:48 +1000, Chris Angelico wrote:
On Sat, Jul 28, 2012 at 6:29 PM, Mark Lawrence breamore...@yahoo.co.uk
wrote:
I highly recommend the use of notepad++. If anyone knows of a better
text editor for Windows please let me know :)
My current preference is SciTE,
PyCon UK 2012 - Call for talks
Please forward this email to relevant lists, social networks, etc.
PyCon UK 2012, the UK's official Python conference, returns from the
28th September to 1st October, Coventry UK.
This volunteer run and organised conference includes sprints, training,
open
On Saturday, July 28, 2012 5:51:48 PM UTC+2, Chris Angelico wrote:
... and has a few limitations (eg it only really supports
UTF-8),
?!
It's my daily plain text editor (Windows) since ? (I don't remember).
And I'm using it for utf-8, utf-16 and cp1252 (my favorite coding)
without problems.
On Sun, Jul 29, 2012 at 3:43 AM, wxjmfa...@gmail.com wrote:
On Saturday, July 28, 2012 5:51:48 PM UTC+2, Chris Angelico wrote:
... and has a few limitations (eg it only really supports
UTF-8),
?!
It's my daily plain text editor (Windows) since ? (I don't remember).
And I'm using it for
On Sat, Jul 28, 2012 at 6:29 PM, Mark Lawrence wrote:
I highly recommend the use of notepad++. If anyone knows of a
better text editor for Windows please let me know :)
I'll advocate for Vim which is crazy-powerful and works nicely on
just about any platform I touch.
Others will advocate for
On Saturday, July 28, 2012 7:47:24 PM UTC+2, Chris Angelico wrote:
On Sun, Jul 29, 2012 at 3:43 AM, wxjmfa...@gmail.com wrote:
On Saturday, July 28, 2012 5:51:48 PM UTC+2, Chris Angelico wrote:
... and has a few limitations (eg it only really supports
UTF-8),
?!
On 7/28/2012 1:23 PM, wxjmfa...@gmail.com wrote:
For info: http://scintilla.org/
Just did a quick check on scintilla.
This looks like a single file editor.
Is there a project like capability in there that I did not notice ?
Thanks
hamilton
--
todd.tab...@gmail.com wrote:
I basically need to replace every occurrence C:\Program Files with
C:\Program Files (x86), regardless of location. For example, that
text appears within:
URLC:\Program Files\\Map Data\Road_Centerlines.shp/URL
and also within:
RoutingIndexPathNameC:\Program
On Sun, Jul 29, 2012 at 7:43 AM, hamilton hamil...@nothere.com wrote:
On 7/28/2012 1:23 PM, wxjmfa...@gmail.com wrote:
For info: http://scintilla.org/
Just did a quick check on scintilla.
This looks like a single file editor.
Is there a project like capability in there that I did not
Hi Python folks,
I am reaching out to various Python-related programming communities in
order to offer new help packaging your software.
If you have ever struggled with packaging and releasing Python software
(e.g. to PyPI), please check out this service:
- http://pythonpackages.com
On Tuesday, July 24, 2012 2:55:29 AM UTC-7, Laszlo Nagy wrote:
conn.getqueryvalue(select '1311-03-14 BC'::date)
What is the good representation here? Should I implement my own date
Do your datetime formatting in postgres: select '1311-03-14 BC'::date::text
PG does have a have a reasonable
On 7/28/2012 4:42 PM, Chris Angelico wrote:
On Sun, Jul 29, 2012 at 7:43 AM, hamilton hamil...@nothere.com wrote:
On 7/28/2012 1:23 PM, wxjmfa...@gmail.com wrote:
For info: http://scintilla.org/
Just did a quick check on scintilla.
This looks like a single file editor.
Is there a project
On Sun, Jul 29, 2012 at 12:33 PM, hamilton hamil...@nothere.com wrote:
Ok, so the answer is no.
In terms of the editor, it's fine; you need only worry about Scintilla
itself if you're aiming to incorporate it in your own program.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Tim Chase python.l...@tim.thechases.com writes:
On Sat, Jul 28, 2012 at 6:29 PM, Mark Lawrence wrote:
I highly recommend the use of notepad++. If anyone knows of a
better text editor for Windows please let me know :)
I highly recommend not tying your editor skills to a single OS,
On Jul 29, 10:08 am, Ben Finney ben+pyt...@benfinney.id.au wrote:
Tim Chase python.l...@tim.thechases.com writes:
On Sat, Jul 28, 2012 at 6:29 PM, Mark Lawrence wrote:
I highly recommend the use of notepad++. If anyone knows of a
better text editor for Windows please let me know :)
I
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset c2618b916081 by Ned Deily in branch 'default':
Issue #15364: Fix test_srcdir for the installed case.
http://hg.python.org/cpython/rev/c2618b916081
--
___
Python tracker
Serhiy Storchaka storch...@gmail.com added the comment:
def wrap_paragraphs(text, width=70, **kwargs):
return [line for para in text.splitlines() for line in textwrap.wrap(para,
width, **kwargs) or ['']]
--
___
Python tracker
Eric Snow ericsnowcurren...@gmail.com added the comment:
Awesome addition, Barry! Bless you for slogging through this. Here are some
thoughts (prepare one grain of salt for each):
* (glossary.rst) finder: should also reference PEP 420.
* (glossary.rst) module: s/contain/containing/
*
Terry J. Reedy tjre...@udel.edu added the comment:
Up until today, I had assumed that it was the generator.__next__ method that
was associated with the compiled body. But in writing my response, I
investigated and discovered
def gf(): yield None
gf().gi_code is gf.__code__
True
Then i
Terry J. Reedy tjre...@udel.edu added the comment:
I will try to read your new patch when I am fresher.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15457
___
New submission from Chris Jerdonek chris.jerdo...@gmail.com:
This issue is to add code object to the documentation glossary, as discussed
in issue 15457 regarding the documentation around generators.
This can be a minimal entry that links to the details here, for example--
Chris Jerdonek chris.jerdo...@gmail.com added the comment:
I created issue 15476 to add code object to the glossary.
Generator functions must have a special __call__ method that simply creates
and returns a generator instance with the code object attached (instead of
executing the code).
Chris Jerdonek chris.jerdo...@gmail.com added the comment:
We may also add a function to change these limits at runtime.
This sounds like a good idea. Is there already an issue for this? If not, I
could create one.
Regardless of whether MAX_STRING_LENGTH is increased, my instinct is that
Serhiy Storchaka storch...@gmail.com added the comment:
issue15456
efficiently demonstrates that the current style can detect bugs
which testing with object.__sizeof__ can't.
Hmm, I see this as a counterexample. The bug *was not detected* with the
current style of testing.
But if you
Serhiy Storchaka storch...@gmail.com added the comment:
Thank you for fast commiting.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15456
___
Stefan Krah stefan-use...@bytereef.org added the comment:
Thanks, Nick! I'll move the function declaration back to abstract.h.
Waiting for Georg's input. -- It seems to me that #14330 is a blocker
that will only be fixed on Monday.
--
___
Python
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: -storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14973
___
___
Python-bugs-list
Georg Brandl ge...@python.org added the comment:
With the beta delayed as you say, I'm okay with this going in now.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12834
___
Georg Brandl ge...@python.org added the comment:
OK, finally I think this can go in.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1692335
___
Georg Brandl ge...@python.org added the comment:
OK, demoting.
--
priority: release blocker - deferred blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14578
___
New submission from Ned Deily n...@acm.org:
==
FAIL: testAtanSign (test.test_cmath.CMathTests)
--
Traceback (most recent call last):
File
Martin v. Löwis mar...@v.loewis.de added the comment:
I suggest the opposite: never emit TYPE_INT64 at all. For compatibility, we can
still support reading it in 3.3 (and drop that support in 3.4).
--
nosy: +loewis
___
Python tracker
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 8fbbc7c8748e by Stefan Krah in branch 'default':
Issue #12834: Fix PyBuffer_ToContiguous() for non-contiguous arrays.
http://hg.python.org/cpython/rev/8fbbc7c8748e
--
___
Stefan Krah stefan-use...@bytereef.org added the comment:
All right, 3.3 is fixed. Re-targeting for 3.2 and 2.7.
--
priority: release blocker - normal
versions: +Python 3.1 -Python 3.3
___
Python tracker rep...@bugs.python.org
Martin v. Löwis mar...@v.loewis.de added the comment:
Here is a patch to stop generating TYPE_INT64. Ok for 3.30b2?
--
keywords: +patch
priority: high - release blocker
Added file: http://bugs.python.org/file26553/marshal.diff
___
Python tracker
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Here is a patch that write TYPE_INT64 on most platforms (where either long or
long long is 64bit).
It is admittedly much larger than Martin's...
--
Added file: http://bugs.python.org/file26554/marshal_use_int64.patch
Mark Dickinson dicki...@gmail.com added the comment:
Judging by previous reports of this type, it's probably either a bug in the
platform math library or a compiler optimization bug (or possibly a combination
of the two: one previous OS X bug involved calls to sin / cos being 'optimized'
to a
Mark Dickinson dicki...@gmail.com added the comment:
Also: what's HAVE_LOG1P for this build?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15477
___
STINNER Victor victor.stin...@gmail.com added the comment:
We may also add a function to change these limits at runtime.
This sounds like a good idea. Is there already an issue for this? If not, I
could create one.
There is no such issue. You can create it: add me to the nosy list.
STINNER Victor victor.stin...@gmail.com added the comment:
Regardless of whether MAX_STRING_LENGTH is increased, my instinct is that the
test should work for long install paths independent of the setting's value.
I wonder if there is a way to adjust the test so that the file name can still
New submission from STINNER Victor victor.stin...@gmail.com:
On Windows, if an OS error fails, the filename type is bytes and the filename
cannot be decoded: Python raises an UnicodeDecodeError instead of an OSError.
The problem is that Python decodes the filename to fill OSError.filename
STINNER Victor victor.stin...@gmail.com added the comment:
I still would prefer if only one issue at a time gets fixed, in particular if
the two issues require independent changes.
Sorry, you are right: I created the issue #15478 for the general fix, and we
will use this issue to fix
Changes by STINNER Victor victor.stin...@gmail.com:
--
title: UnicodeDecodeError on OSError - UnicodeDecodeError on OSError on
Windows with undecodable (bytes) filename
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15478
STINNER Victor victor.stin...@gmail.com added the comment:
In Python 2, it looks like open(arg) does pass its filename argument unchanged
to OSError constructor (so it can be bytes or unicode). OSError.filename is
always bytes for os.chdir() on UNIX, but OSError.filename can be bytes or
Serhiy Storchaka storch...@gmail.com added the comment:
I can see yet another problem under the hood. Marshalling will output different
data on platforms with a different representation of negative numbers. Worse
still, these data are non-portable, written on one platform will be read
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15466
___
___
Martin v. Löwis mar...@v.loewis.de added the comment:
Serhiy: this is safe to ignore.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15466
___
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Are there really platforms which don't use two's complement?
(If there are, I'm not sure to want to share binary data with them. Same for
EBCDIC)
--
___
Python tracker rep...@bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
Everything is still building happily for me on Fedora, so I suggest looking at
the Debian/Ubuntu multiarch support (which is the origin of the
dpkg-architecture call).
Background in http://bugs.python.org/issue11715
--
nosy: +barry,
Serhiy Storchaka storch...@gmail.com added the comment:
I asked in Python-Dev, and if I understood the answers correctly, we can make
changes to 2.7 and 3.2 without fear. For 3.3 risk is higher, so we need to be
more attentive. However patch for 3.3 contains not only the potential
Ezio Melotti added the comment:
test
--
keywords: +easy -patch
nosy: -python-dev
priority: - low
resolution: fixed - later
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2771
___
New submission from Chris Jerdonek:
This issue is to allow the MAX_STRING_LENGTH limit defined in
Python/traceback.c to be changed at runtime, as discussed in issue 15463, as
well as the two related limits:
#define MAX_STRING_LENGTH 100
#define MAX_FRAME_DEPTH 100
#define MAX_NTHREADS 100
Chris Jerdonek added the comment:
There is no such issue. You can create it: add me to the nosy list.
I created issue 15479 to allow the limits to be changed at runtime.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15463
Chris Jerdonek added the comment:
The purpose of the test is to check that the traceback is correct:
it's important to check that the filename ends with threading.py.
I agree with you. That is why I argued against including or '...' logic in
the current test.
Changing the
Meador Inge added the comment:
On Sat, Jul 28, 2012 at 3:27 AM, Serhiy Storchaka
rep...@bugs.python.org wrote:
Serhiy Storchaka storch...@gmail.com added the comment:
issue15456
efficiently demonstrates that the current style can detect bugs
which testing with object.__sizeof__ can't.
Roundup Robot added the comment:
New changeset 68e2690a471d by Richard Oudkerk in branch 'default':
Issue #1692335: Move initial args assignment to BaseException.__new__
http://hg.python.org/cpython/rev/68e2690a471d
--
nosy: +python-dev
___
Python
Amaury Forgeot d'Arc added the comment:
IMO we should not ship 3.3 without a fix for this.
--
priority: normal - high
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15425
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15425
___
___
Changes by Georg Brandl ge...@python.org:
--
priority: high - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15425
___
___
Eric Snow added the comment:
I suggest the opposite: never emit TYPE_INT64 at all. For
compatibility, we can still support reading it in 3.3 (and drop
that support in 3.4).
+1 essentially we maintain the status quo
--
nosy: +eric.snow
___
Python
Roundup Robot added the comment:
New changeset 461e84fc8c60 by Martin v. Löwis in branch 'default':
Issue #15466: Stop using TYPE_INT64 in marshal,
http://hg.python.org/cpython/rev/461e84fc8c60
--
nosy: +python-dev
___
Python tracker
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15466
___
___
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15425
___
___
Amaury Forgeot d'Arc added the comment:
Removing TYPE_INT64 was indeed the most reasonable choice.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15466
___
Changes by Martin v. Löwis mar...@v.loewis.de:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15466
___
New submission from Martin v. Löwis:
As a follow-up of issue15466, TYPE_INT64 can be deleted in Python 3.4.
--
messages: 166670
nosy: loewis
priority: deferred blocker
severity: normal
status: open
title: Drop TYPE_INT64 from marshal in Python 3.4
versions: Python 3.4
Martin v. Löwis added the comment:
I put the complete removal of TYPE_INT64 into issue15480
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15466
___
Eric Snow added the comment:
Looks like the Misc/NEWS entry got truncated. Also, does this change need a
new PYC magic number (now in Lib/importlib/_bootstrap.py)?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15466
Martin v. Löwis added the comment:
For the truncation, see ec7267fa8b84. I don't see why a new pyc magic number
should be necessary. Python continues to support the existing files.
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset fe29a657bde9 by Martin v. Löwis in branch 'default':
Issue #15431: Add _freeze_importlib project to regenerate importlib.h on
Windows.
http://hg.python.org/cpython/rev/fe29a657bde9
--
nosy: +python-dev
Martin v. Löwis added the comment:
Thanks for the patch, committed with slight modifications.
--
nosy: +loewis
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15431
Amaury Forgeot d'Arc added the comment:
Comments about PyImport_FrozenModules linkage have not been addressed. Now the
build is failing on all Unix machines...
--
status: closed - open
___
Python tracker rep...@bugs.python.org
New submission from Eric Snow:
issue15110 introduced a new private function, _exec_module(), to the default
loaders in Lib/importlib/_bootstrap.py. Doing so helped hide importlib frames
from the traceback. A related fix is likely required for issue15425.
Should some general form of
Roundup Robot added the comment:
New changeset bd58c421057c by Martin v. Löwis in branch 'default':
Issue #14578: Support modules registered in the Windows registry again.
http://hg.python.org/cpython/rev/bd58c421057c
--
nosy: +python-dev
___
Python
Martin v. Löwis added the comment:
Amaury's patch nearly worked; committed with slight modifications.
--
dependencies: -Cannot build importlib.h on Windows
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
Chris Jerdonek added the comment:
Here is a patch to the tests that allows the tests to pass when the install
path is long while still checking that file names show up correctly in the
traceback.
One advantage of this patch's approach is that it provides a way to test the
rendering of long
Eric Snow added the comment:
Perhaps this should be split into two issues, as the fix will likely be
different for the two.
For the first part (SyntaxError), my initial impression is that this will
require a similar fix, or extension of it, to the one in issue15110. That fix
was limited
Eric Snow added the comment:
Issue15425 is related. I'm looking into an exception chaining approach that
could be applied for this issue too.
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15110
Antoine Pitrou added the comment:
To be clear, the build fails when importlib needs to be frozen again:
$ touch Lib/importlib/_bootstrap.py
$ make
make Modules/_freeze_importlib
make[1] : on entre dans le répertoire « /home/antoine/cpython/default »
gcc -pthread -c -Wno-unused-result -g -O0
Roundup Robot added the comment:
New changeset 7967cb63e50e by Martin v. Löwis in branch 'default':
Issue #15431: Declare PyImport_FrozenModules conditionally on Unix only.
http://hg.python.org/cpython/rev/7967cb63e50e
--
___
Python tracker
Eric Snow added the comment:
I don't see why a new pyc magic number should be necessary. Python
continues to support the existing files.
Good point.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15466
Roundup Robot added the comment:
New changeset deb421baf671 by Martin v. Löwis in branch 'default':
Issue #15431: Drop _freeze_importlib from all build configurations,
http://hg.python.org/cpython/rev/deb421baf671
--
___
Python tracker
Changes by Łukasz Langa luk...@langa.pl:
--
assignee: lukasz.langa - sbt
stage: patch review - commit review
versions: -Python 2.7, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1692335
Martin v. Löwis added the comment:
The last commits should address Amaury's concerns. _freeze_importlib must now
be built manually, followed by a build of pythoncore.
Interestingly, the builds failed only once. When rebuilding, the builds
succeeded as no attempt to build freeze_importlib was
Chris Jerdonek added the comment:
Terry, if when reviewing my patch for issue 15457, you also have time to review
this much simpler patch (also in the documentation on generators), I would
appreciate it. If not, that's okay.
--
nosy: +terry.reedy
Chris Jerdonek added the comment:
Is there any way I could assist in closing this, perhaps by preparing patches
for the Distutils and Distutils2 components? Can someone point me to where the
changes to those components should be made (e.g. where they are located)?
--
Ned Deily added the comment:
I assume the failure still happens in debug mode?
Yes
Are there any math module failures?
No
What do math.log1p(0.0) and math.log1p(-0.0) give? (Answers *should* be 0.0
and -0.0 respectively.)
math.log1p(0.0)
0.0
math.log1p(-0.0)
0.0
Martin v. Löwis added the comment:
distutils are in Lib/distutils. Distutils2 has been removed from Python.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15231
___
Antoine Pitrou added the comment:
Changing the incredible issue title :-)
--
title: Incredible issue in math.pow - document that math.pow is inappropriate
for integers
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15438
Antoine Pitrou added the comment:
Sounds totally overkill to me.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15479
___
___
Chris Jerdonek added the comment:
Thanks, Martin. Should Distutils2 be removed from the Components list of the
tracker form, then? Or was Éric referencing a third-party location?
--
___
Python tracker rep...@bugs.python.org
Martin v. Löwis added the comment:
Should Distutils2 be removed from the Components list of the tracker form,
then?
No. Please stick to one issue at a time, and distutils2 may come back (google
for details).
--
___
Python tracker
Chris Jerdonek added the comment:
I don't have a problem with closing this as rejected if Victor agrees.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15479
___
Mark Dickinson added the comment:
math.log1p(0.0)
0.0
math.log1p(-0.0)
0.0
Ah, that would do it, then. It looks as though the system's log1p function is
buggy, in the sense that it doesn't follow C99 Annex F (F.9.3.9). It also
doesn't agree with what 'man log1p' says on my OS X 10.6
Chris Jerdonek added the comment:
No. Please stick to one issue at a time, and distutils2 may come back (google
for details).
I was asking only to determine whether to create a new issue -- not to have
that issue addressed here.
It seems to me there are missing words in the text, and it
Ned Deily added the comment:
It also doesn't agree with what 'man log1p' says on my OS X 10.6
Macbook: under 'SPECIAL VALUES', it says: 'log1p(+-0) returns +-0.'
That manpage is unchanged for 10.8.
I'm puzzled about one thing, though: there's a test for this problem
in the configure script,
1 - 100 of 121 matches
Mail list logo
