Armin Rigo:
Maybe. Feel like adding an issue to
https://bitbucket.org/cffi/cffi/issues, with references?
OK, issue #62 added.
This looks
like a Windows-specific extension, which means that I don't
automatically know about it.
While SAL is Windows-specific, gcc supports some
Armin Rigo:
So the general answer to your question is: we google MessageBox and
copy that line from the microsoft site, and manually remove the
unnecessary WINAPI and _In_opt declarations:
Wouldn't it be better to understand the SAL annotations like _In_opt so that
spurious NULLs (for
Nick Coghlan:
- no need for extensive cross-OS testing prior to commit, that's a key
part of the role of the buildbots
Are the buildbots able to test UI features like menu selections?
Neil
___
Python-Dev mailing list
Python-Dev@python.org
Curt:
But will it be able to target Windows XP?
It will likely be possible in a reasonable manner at some point. From
http://blogs.msdn.com/b/visualstudio/archive/2012/05/18/a-look-ahead-at-the-visual-studio-11-product-lineup-and-platform-support.aspx
:
C++ developers can also use the
Antoine Pitrou:
When you say MoveFile is absent, is MoveFileEx supported instead?
WinRT strongly prefers asynchronous methods for all lengthy
operations. The most likely call to use for moving files is
StorageFile.MoveAsync.
http://msdn.microsoft.com/en-us/library/windows/apps/br227219.aspx
Antoine Pitrou:
How does it translate to C?
The simplest technique would be to use C++ code to bridge from C to
the API. If you really wanted to you could explicitly call the
function pointer in the COM vtable but doing COM in C is more effort
than calling through C++.
I'm not sure why
Austin Fernandes:
Which versions of python will be compatible with windows8. I am using
currently 2.7.2 version.
Current releases of both Python 2.7 and Python 3.2 appear to run
fine on the Windows 8 Developer Preview. You should download and
install the preview to ensure that your own code
Glenn Linderman:
How many different iterators into the same text would be concurrently needed
by an application? And why? Seems like if it is dealing with text at the
level of grapheme clusters, it needs that type of iterator. Of course, if
it does I/O it needs codec access, but that is by
Stephen J. Turnbull:
... Eg, this is why the common GUIs for Unix (X.org, GTK+, and
Qt) either provide or require UTF-8 coding for their text.
Qt uses UTF-16 for its basic QString type. While QString is mostly
treated as a black box which you can create from input buffers in any
encoding,
Glenn Linderman:
That said, regexp, or some sort of cursor on a string, might be a workable
solution. Will it have adequate performance? Perhaps, at least for some
applications. Will it be as conceptually simple as indexing an array of
graphemes? No. Will it ever reach the efficiency of
Guido van Rossum:
On Wed, Aug 31, 2011 at 5:58 PM, Neil Hodgson nyamaton...@gmail.com wrote:
[...] some text drawing engines draw decomposed characters (o
followed by ̈ - ö) differently compared to their composite
equivalents (ö) and this may be perceived as better or worse. I'd
like
Antoine Pitrou:
So what you're saying is that the text is mostly useless (or at least
quite dispensable), but you think it's fine that people waste their
time trying to read it?
I found it useful when starting to write socket code. Later on I
learnt more but, as an introduction, this
Victor Stinner:
C and C++ identifiers are restricted to ASCII. I don't know for Fortran
or Java.
Some C and C++ implementations currently allow non-ASCII
identifiers and the forthcoming C1X and C++0x language standards
include non-ASCII identifiers. The allowed characters are specified in
Victor Stinner:
I read these documents but they don't explain which encoding is used in
libraries and programs. Does it mean that Windows and Linux may use
different encodings?
Yes, Windows will use UTF-16 as it does for almost everything. From
a user's point of view, these should both
Michael Urman:
I'm not convinced this is correct for this case. GetProcAddress takes
an ANSI string, meaning while it could theoretically use UTF-8, in
practice I doubt it uses anything outside of ASCII safely. So while
the name of the library would be encoded in UTF-16, the name of the
Michael Urman:
That screenshot seems to show UTF-8 is being used. This may just be
the literal bytes in the .c file, but could it be something more
dependable?
The file is in UTF-8 so the compiler may just be copying the bytes.
There is a setlocale pragma but that seems to be just for
Martin v. Löwis:
I guess all this advice doesn't really apply to this case, though.
The Microsoft API declares the parameter as a volatile*, indicating
that they consider it proper usage of the API to declare the storage
volatile.
The 'volatile' here is a modifier on the parameter and
Georg Brandl:
I'm very happy to announce that the core Python repository switch
to Mercurial is complete and the new repository at
http://hg.python.org/cpython/ is now officially open for cloning,
OK, I just performed a clone OK. It seems wrong to me that the
*.vcproj and *.vsprops files
Antoine Pitrou:
It mimicks their settings in the SVN repository, so it should be ok.
It doesn't match how they are checked out by svn since they have
the property svn:eol-style set to 'native'. Therefore these files are
checked out by svn with Windows \r\n line ends.
Neil
To minimize differences from previous behaviour, it is probably
best to mimic svn more closely by changing .hgeol to either have all
the project files as native or allow fall through to the default ** =
native.
Another possibility is to set Visual Studio project files to CRLF
but this is
Martin v. Löwis:
So how can I fix this properly: so that all files have CRLF, but
are still attributed to whoever last modified them, rather than
having them attributed to me?
I don't think this is possible from the current state. It may be
possible to change the conversion process to
Adrian Buehlmann:
FWIW, we are very close to releasing TortoiseHg 2.0 (due March 1st),
which ported the current Gtk based TortoiseHg to Qt (although, it was
more like a rewrite :-).
I hope this is going to be fast. One of the reasons I chose Hg over
Bzr for another project was that the Bzr
Line end problems do occur in real projects. A scintilla-cocoa
project was branched off Scintilla to support the Cocoa GUI framework
on OS X. Here is one of the revisions in that project:
http://bazaar.launchpad.net/~mike-lischke/scintilla-cocoa/trunk/revision/5#include/ScintillaWidget.h
If
With hg 1.7.5 on Windows 7 I performed a non-core checkout:
hg clone http://hg.python.org/cpython
The eol extension is enabled in global settings. I looked at things
a bit, opening some files and using the Tortoise Hg Repository
Explorer. But made no actual changes. Running hg diff
Antoine Pitrou:
It should now be fixed in current SVN, meaning the final conversion
should be perfectly usable with the eol extension enabled.
Good.
Do you find other issues under Windows? Have you tried pushing changes?
Since I'm not a member of core developers I used a http pull and
Toshio Kuratomi:
When they update their OS to a version that has
utf-8 python module names, they will find that they have to make a choice.
They can either change their locale settings to a utf-8 encoding and have
the system installed modules work or they can leave their encoding on their
Toshio Kuratomi:
My examples that you're replying to involve two properly
configured OS's. The Linux workstations are configured with a UTF-8
locale. The Windows OS's use wide character unicode. The problem occurs in
that the code that one of the parties develops (either the students or
Stephen J. Turnbull:
Will it accept Arabic on input? (Han might be too much to ask for
since Unicode considers Han digits to be impure.)
I couldn't find a direct way to input Arabic digits into OO Calc,
the normal use of Alt+number didn't work in Calc although it did in
WordPad where
Stephen J. Turnbull:
Here's why: '''print %d %
some_integer''' doesn't now, and never will (unless Kristan gets his
Python 2.8wink), produce Arabic or Han numerals. Not in any
language I know of, not in Microsoft Excel, and definitely not in
Python 2.
While I don't have Excel to test
Ian Bicking:
I think the use case everyone has in mind here is where
you get a URL from one of these sources, and you want to handle it. I have
a hard time imagining the sequence of events that would lead to mojibake.
Naive parsing of a document in bytes couldn't do it, because if you have a
M.-A. Lemburg:
Is it possible to have multiple versions of the lib C loaded
on Windows ?
Yes. It is possible not only to mix C runtimes from different
vendors but different variants from a single vendor.
Historically, each vendor has shipped their own C runtime
libraries. This was also
Terry Reedy:
File C:\Python26\lib\socket.py, line 406, in readline
data = self._sock.recv(self._rbufsize)
socket.error: [Errno 10054] A lÚtez§ kapcsolatot a tßvoli ßllomßs
kÚnyszerÝtette n bezßrta
That is pretty good mojibake. One of the problems of providing
localized error messages
Terry Reedy:
I suspect that the persons who first ported Python to MSDOS simply used what
they were used to using, perhaps in their paid job. And I am sure that is
still true of at least some of the people doing Windows support today.
Some Windows developers actually prefer Visual Studio,
Stephen J. Turnbull:
But it's very important to be able to *move* tabs across windows or
panes. ...
In many apps, however, you would have to select the foo.c tab, close
it, bring up a new window, and open foo.c using the long path
(presumably with a file browser interface, but often enough
Kurt B. Kaiser:
I'm mystified about the comments that the GUI is ugly. It is minimal.
On XP, it looks exactly like an XP window with a simple menubar. Those
who haven't looked at it for awhile may not be aware of the recent
advances made by Tk in native look and feel. What is ugly?
Kurt B. Kaiser:
The tear off menus are ugly as well as being non-standard on all three
major platforms.
Well, would you discard them? They can (occasionally) be useful.
Yes, I would replace the menus with ones missing the tear line.
Most of the GUI toolkits experimented with tear-offs
anatoly techtonik:
The file consists of several licenses for multiple versions of Python.
It is an unusual mix that negatively affects understanding.
A simpler license would be better.
There have been moves in the past to simplify the license of Python
but this would require agreement
Steven D'Aprano:
Do any other languages have any equivalent to this ebtyes type?
The String type in Ruby 1.9 is a byte string with an encoding attribute.
Most online Ruby documentation is for 1.8 but the API can be examined here:
http://ruby-doc.org/ruby-1.9/index.html
Here's
Michael Foord:
Python 3.0 was *declared* to be an experimental release, and by most
standards 3.1 (in terms of the core language and functionality) was a solid
release.
That looks to me like an after-the-event rationalization. The
release note for Python 3.0 (and the What's new) gives no
Victor Stinner:
It's a choice, I didn't want to patch Windows because I know that Windows use
unicode internally. I consider that developers using Python3 should use
unicode on Windows, and byte or unicode+surrogates on other OS.
The Win32 byte string APIs convert their inputs to Unicode
Antoine Pitrou:
Is this concern still valid? We are in the 2010s now.
I'm not saying I want us to put some C++ in the core interpreter, but
the portability argument sounds a little old...
There are still viable platforms which only support subsets of C++.
IIRC, Android does not support
Martin v. Löwis:
See http://bugs.python.org/issue6926
The SDK currently hides symbolic constants from us that people are
asking for.
Setting the version to 0x501 (XP) doesn't actively try to stop
running on version 0x500 (2K), it just reveals the symbols and APIs
from 0x501. Including a
Martin v. Löwis:
I don't recall whether we have already decided about continued support
for Windows 2000.
If not, I'd like to propose that we phase out that support: the Windows
2.7 installer should display a warning; 3.2 will stop supporting Windows
2000.
Is there any reason for this?
Larry Hastings:
But IIUC telling the compiler how to
do that is only vaguely standardized--Microsoft's CL.EXE doesn't seem to
support any environment variable containing an include /path/.
The INCLUDE environment variable is a list of ';' separated paths
Eric Hopper:
I don't suppose it will ever be ported back to Python 2.x? It doesn't
look like the whole GIL concept has changed much between Python 2.x and
3.x so I expect back-porting it would be pretty easy.
There was a patch but it has been rejected.
http://bugs.python.org/issue7753
Tim Delaney:
I like this solution combined with having a single cache directory and a few
other things I've added below.
...
2. /tmp is often on non-volatile memory. If it is (e.g. my Windows system
temp dir is on a RAMdisk) then it seems wise to respect the obvious desire
to throw away
When SourceForge started having comments and ratings, I was a
little upset at having poor negative comments there (like not
work!). But after it has been running for a while it appears useful.
I suppose it helps that Scintilla has 88% thumbs up from 134
respondents. Because there is voting on
Ronald Oussoren:
Both Carbon and the modern APIs use UTF-16.
If Unicode size standardization is seen as sufficiently beneficial
then UTF-16 would be more widely applicable than UTF-32. Unix mostly
uses 8-bit APIs which are either explicitly UTF-8 (such as GTK+) or
can accept UTF-8 when the
Dirkjan Ochtman:
I know a lot of projects use Mercurial on Windows as well, I'm not
aware of any big problems with it.
If you have a Windows-only project with CRLF files using Mercurial
then there is no line end problem as Mercurial preserves the CRLFs for
you. Line end problems occur on
M.-A. Lemburg:
... and because of this, the feature is already available if
you use codecs.open() instead of the built-in open():
So should I not add an issue for the basic open because codecs.open
should be used for this case?
Neil
___
Martin v. Löwis:
Is it really that you don't *understand*? It's fairly easy: there was
a PEP ...
The PEP process is straightforward. However, a PEP may produce an
outcome that proves after more experience to be wrong. ISTM a
prerequisite to choosing a DVCS is that it should support the full
Martin v. Löwis:
Or don't you understand why that single unresolved item didn't manage
to revert the decision? Well, there are many unresolved items in
the Mercurial conversion, some much more stressful than the eol issue
(e.g. the branching discussion).
Then these issues should have been
Glenn Linderman:
and perhaps other things (and
are there new Unicode control characters that could be used for line
endings?),
Unicode includes Line Separator U+2028 and Paragraph Separator
U+2029 but they are rarely supported and very rarely used. They are a
pain to work with since they
Mark Hammond:
Thanks Nick; I didn't want to be the only one saying that. There is a fine
line between asserting reasonable requirements for Windows users and being
obstructionist and unhelpful, and I'm trying to stay on the former side :)
I haven't commented on this issue before because I
Glyph Lefkowitz:
Sounds like this is moving into hypothetical territory better-suited to
python-ideas. (Although I'm sure that if you wanted to contribute polished,
tested code for a standard remote debugger interface, few people would
complain.)
There is a remote debugger protocol
Curt Hagenlocher:
Ah, you're right -- the PGO bits probably need VS Pro. The 64-bit
compilers should be in the Windows SDK, but it wouldn't surprise me if
they were not included in Express.
64-bit isn't in Express and merging the 64 bit compiler from the
SDK into Express may be possible
cmake does not produce relative paths in its generated make and
project files. There is an option CMAKE_USE_RELATIVE_PATHS which
appears to do this but the documentation says:
This option does not work for more complicated projects, and
relative paths are used when possible. In general, it is
Jeffrey Yasskin:
1. It can autogenerate the Visual Studio project files instead of
needing them to be maintained separately
I have looked at a couple of build tools (scons was probably one)
that generate Visual Studio project files in the past and they
produced fairly poor project files,
Antoine Pitrou:
How about shutil.copystat()?
shutil.copystat does not copy over the owner, group or ACLs.
Modeling a copymetadata method on copystat would provide an easy to
understand API and should be implementable on Windows and POSIX.
Reading the OS X documentation shows a set of
Antoine Pitrou:
It depends on what you call ACLs. It does copy the chmod permission bits.
Access Control Lists are fine grained permissions. Perhaps you
want to allow Sam to read a file and for Ted to both read and write
it. These permissions should not need to be reset every time you
The technique advocated by Theodore Ts'o (save to temporary then
rename) discards metadata. What would be useful is a simple, generic
way in Python to copy all the appropriate metadata (ownership, ACLs,
...) to another file so the temporary-and-rename technique could be
used.
On Windows,
zooko:
Um, isn't this tool called unzip? I have done this -- accessed the
source code -- many times, and unzip suffices.
The type of issue I ran into with eggs is when you get an exception
with a trace that includes an egg, you can't use the normal means to
look at the code. Instead you
Travis Oliphant:
PEP: 3118
...
I'd like to see the PEP include discussion of what to do when an
incompatible request is received while locked. Should there be a
standard Can't do that: my buffer has been got exception?
Neil
___
Python-Dev
I have developed a split vector type that implements the buffer protocol at
http://scintilla.sourceforge.net/splitvector-1.0.zip
It acts as a mutable string implementing most of the sequence
protocol as well as the buffer protocol. splitvector.SplitVector('c')
creates a vector containing 8
Travis Oliphant:
3) information about discontiguous memory segments
Number 3 is where I could use feedback --- especially from PIL users and
developers. Strides are a common way to think about a possibly
discontiguous chunk of memory (which appear in NumPy when you select a
sub-region
Greg Ewing:
So an array-of-pointers interface wouldn't be a direct
substitute for the existing multi-segment buffer
interface.
Providing an array of (pointer,length) wouldn't be too much extra
work for a split vector implementation.
Guido van Rossum:
But there's always a call to remove
Martin v. Löwis:
Currently, we have two running tracker demos online:
After playing with them for 30 minutes, Jira seems to have too busy
an interface and finicky behaviour: not liking the back button
sometimes (similar to SF) and clicking on diffs wants to download them
rather than view
Trent Nelson:
I ended up playing around with Profile Guided Optimization, running
``python.exe pystones.py'' to collect call-graph data after
python.exe/Python24.dll had been instrumented, then recompiling with the
optimizations fed back in.
It'd be an idea to build a larger body of
Brett Cannon:
But SourceForge does not support anonymous reporting.
SourceForge does support anonymous reporting. A large proportion of
the fault reports I receive for Scintilla are anonymous as indicated
by nobody in the Submitted By column.
Martin v. Löwis:
Apparently, the status of this changed right now: it seems that
the 2003 compiler is not available anymore; the page now says
that it was replaced with the 2005 compiler.
Should we reconsider?
I expect Microsoft means that Visual Studio Express will be
available free
Martin v. Löwis:
COM really solves all problems people might have on Windows.
COM was partly just a continuation of the practices used for
controls, VBXs and other forms of extension. Visual Basic never forced
use of a particular compiler or runtime library for extensions so why
should
Martin v. Löwis:
Not sure whether this was a serious suggestion.
Yes it is.
If pythonxy.dll
was statically linked, you would get all the CRT duplication
already in extension modules. Given that there are APIs in Python
where you have to do malloc/free across the python.dll
boundary,
Paul Moore:
This has all been thrashed out before, but the issue is passing
CRT-allocated objects across DLL boundaries.
Yes, that was the first point I addressed through wrapping CRT objects.
At first glance, this is a minor issue - passing FILE* pointers across
DLL boundaries isn't
Martin v. Löwis:
Visual Basic never forced
use of a particular compiler or runtime library for extensions so why
should Python?
Do you really not know? Because of API that happens to be defined
the way it is.
It was rhetorical: Why should Python be inferior to VB?
I suppose the
Martin v. Löwis:
So ideally, Python should drop usage of the CRT entirely (but getting
there will be a long process). Hopefully, P3k will drop usage of
stdio for file objects, which will be a big step forward.
You don't need to drop the CRT, just encapsulate it so there is one
copy
Martin v. Löwis:
I don't think this would be good enough. I then also need a way to
provide extension authors with an API that looks like the CRT, but
isn't: they cannot realistically change all their code to use the
wrapped objects. In a recent case, somebody tried to passed a FILE*
to a
Greg Ewing:
But that won't help when you need to deal with third-party
code that knows nothing about Python or its wrapped file
objects, and calls the CRT (or one of the myriad extant
CRTs, chosen at random:-) directly.
Can you explain exactly why there is a problem here? Its fairly
Won't ctypes completely replace dl? dl provides only a small subset
of the functionality of ctypes and is very restricted in the set of
argument types allowed.
Neil
___
Python-Dev mailing list
Python-Dev@python.org
Neal Norwitz:
I think a bigger bang for the buck would be to buy a Windows box with
Purify. Rational was a real pain to deal with, maybe it's better now
that IBM bought them. Parasoft (Insure++) was even worse to deal
with.
My experience with the other Windows option, BoundsChecker, is
Martin v. Löwis:
The problem (for me, atleast) is that VC is so much more convenient to
work with.
In my experience Visual C++ has always produced faster, more
compact code than Mingw. While this may not be true with current
releases, I'd want to ensure that the normal Python download for
Josiah Carlson:
According to wikipedia (http://en.wikipedia.org/wiki/Latin_alphabet),
various languages have adopted a transliteration of their language
and/or former alphabets into latin. They don't purport to know all of
the reasons why, and I'm not going to speculate.
I used to work
Martin v. Löwis:
This aspect of rendering is often not implemented, though. Web browsers
do it correctly, see
...
GUI frameworks sometimes do it correctly, sometimes don't; most
notably, Tk has no good support for RTL text.
Scintilla does a rough job with this. RTL text is displayed
M.-A. Lemburg:
You mean a slice that slices out the next indextype ?
Yes.
This sounds a lot like you'd want iterators for the various
index types. Should be possible to implement on top of the
proposed APIs, e.g. itergraphemes(u), itercodepoints(u), etc.
Iterators may be helpful, but
Martin v. Löwis:
That's very tricky. If you have multiple implementations, you make
usage at the C API difficult. If you make it either UTF-8 or UTF-32,
you make PythonWin difficult. If you make it UTF-16, you make indexing
difficult.
For Windows, the code will get a little uglier,
M.-A. Lemburg:
Unicode has the concept of combining code points, e.g. you can
store an é (e with a accent) as e + '. Now if you slice
off the accent, you'll break the character that you encoded
using combining code points.
...
next_indextype(u, index) - integer
Returns the
Bruce Eckel:
I would say that the troublesome meme is that threads are easy. I
posted an earlier, rather longish message about this. The gist of
which was: when someone says that threads are easy, I have no idea
what they mean by it.
I think you are overcomplicating the issue by looking
Antoine Pitrou:
I don't have a Windows machine at hand right now to test it, but, even
if this solution works, it breaks the principle of least astonishment:
Astonishment is subjective and so a poor tool to measure by. At one
stage Ruby tried to follow the more common formulation principle
Gareth McCaughan:
Interactive use is its own mode and works differently to the base
language. To print the value of something, just type an expression.
Doesn't do the same thing.
In interactive mode, you are normally interested in the values of
things, not their formatting so it
Gareth McCaughan:
3. It's convenient for debugging, interactive use, simple scripts,
and various other things.
Interactive use is its own mode and works differently to the base
language. To print the value of something, just type an expression.
Python will evaluate and print the value of
Martin v. Löwis:
This appears to be based on the usedDefault return value of
WideCharToMultiByte. I believe this is insufficient:
WideCharToMultiByte might convert Unicode characters to
codepage characters in a lossy way, without using the default
character. For example, it converts U+0308
M.-A. Lemburg:
2) Return unicode when the text can not be represented in ASCII. This
will cause a change of behaviour for existing code which deals with
non-ASCII data.
+1 on this one (s/ASCII/Python's default encoding).
I assume you mean the result of sys.getdefaultencoding() here.
Hi Marc-Andre,
With the proposed modification, sys.argv[1] u'\u20ac.txt' is
converted through cp1251
Actually, it is not: if you pass in a Unicode argument to
one of the file I/O functions and the OS supports Unicode
directly or at least provides the notion of a file system
Guido van Rossum:
In some sense the safest approach from this POV would be to return
Unicode as soon as it can't be encoded using the global default
encoding. IOW normally this would return Unicode for all names
containing non-ASCII characters.
On unicode versions of Windows, for
M.-A. Lemburg:
I don't really buy this trick: what if you happen to have
a home directory with Unicode characters in it ?
Most people choose account names and thus home directory names that
are compatible with their preferred locale settings: German users are
unlikely to choose an account
Thomas Heller:
OTOH, I once had a bug report from a py2exe user who complained that the
program didn't start when installed in a path with japanese characters
on it. I tried this out, the bug existed (and still exists), but I was
astonished how many programs behaved the same: On a PC with
Guido van Rossum:
Ah, sigh. I didn't know that os.listdir() behaves differently when the
argument is Unicode. Does os.listdir(.) really behave differently
than os.listdir(u.)?
Yes:
os.listdir(.)
['abc', '']
os.listdir(u.)
[u'abc',
Thomas Heller:
Not only that, all the other flags like -O and -E are also in sys.argvu
but not in sys.argv.
OK, new patch fixes these and the -c issue.
Those are nearly obsoleted by the subprocess module (although I do not
know how that handles unicode.
It breaks. The argspec is
Guido van Rossum:
Whoa! Do we really need a completely different mechanism for doing the
same stuff we can already do?
One benefit I see for the path module is that it makes it easier to
write code that behaves correctly with unicode paths on Windows.
Currently, to implement code that may
Andrew Durdin:
While we'ew discussing outstanding issues: In a related discussion of
the path module on c.l.py, Thomas Heller pointed out that the path
module doesn't correctly handle unicode paths:
...
Here is a patch that avoids failure when paths can not be
represented in a single 8
Anders J. Munch:
1. John X. Programmer buys the product, agrees to the EULA and puts
the DLL up for download, with the explicit and stated intent of
distributing it to anyone who needs it.
Disallowed in 3.1(a):
# you agree: ... to distribute the Redistributables only ... in
#
100 matches
Mail list logo
