Having just re-read the PEP I'm concerned that this proposal leaves at least
one major (?) trap for naive users, namely
x = np.array([1, 10])
print X.T@x
which will print 101, not [[1, 10], [10, 100]]
Yes, I know why this is happening but it's still a problem -- the user said,
On Thu, Jul 17, 2014 at 4:21 PM, josef.p...@gmail.com wrote:
On Thu, Jul 17, 2014 at 4:07 PM, josef.p...@gmail.com wrote:
On Wed, Jul 16, 2014 at 9:52 AM, Nathaniel Smith n...@pobox.com wrote:
On 16 Jul 2014 10:26, Tony Yu tsy...@gmail.com wrote:
Is there any reason why the
On Wed, Jul 16, 2014 at 3:48 AM, Todd toddr...@gmail.com wrote:
On Jul 16, 2014 11:43 AM, Chris Barker chris.bar...@noaa.gov wrote:
So numpy should have dtypes to match these. We're a bit stuck, however,
because 'S' mapped to the py2 string type, which no longer exists in py3.
Sorry not
On Tue, Jul 15, 2014 at 7:40 PM, Aldcroft, Thomas
aldcr...@head.cfa.harvard.edu wrote:
On Sat, Jul 12, 2014 at 8:02 PM, Nathaniel Smith n...@pobox.com wrote:
OTOH, fixed length nul padded latin1 would be useful for various flat file
reading tasks.
As one of the original agitators for this,
hi,
as you may know we want to release numpy 1.9 soon. We should have solved
most indexing regressions the first beta showed.
The remaining blockers are finishing the new __numpy_ufunc__ feature.
This feature should allow for alternative method to overriding the
behavior of ufuncs from
On Wed, Jul 16, 2014 at 9:52 AM, Nathaniel Smith n...@pobox.com wrote:
On 16 Jul 2014 10:26, Tony Yu tsy...@gmail.com wrote:
Is there any reason why the defaults for `allclose` and
`assert_allclose` differ? This makes debugging a broken test much more
difficult. More importantly, using an
On Thu, Jul 17, 2014 at 4:07 PM, josef.p...@gmail.com wrote:
On Wed, Jul 16, 2014 at 9:52 AM, Nathaniel Smith n...@pobox.com wrote:
On 16 Jul 2014 10:26, Tony Yu tsy...@gmail.com wrote:
Is there any reason why the defaults for `allclose` and
`assert_allclose` differ? This makes
On Do, 2014-07-17 at 09:48 -0400, Robert Lupton the Good wrote:
Having just re-read the PEP I'm concerned that this proposal leaves at least
one major (?) trap for naive users, namely
x = np.array([1, 10])
print X.T@x
which will print 101, not [[1, 10], [10, 100]]
Yes, I know
On Wed, Jul 16, 2014 at 7:47 PM, Ralf Gommers ralf.gomm...@gmail.com wrote:
On Wed, Jul 16, 2014 at 6:37 AM, Tony Yu tsy...@gmail.com wrote:
It seems like the defaults for `allclose` and `assert_allclose` should
match, and an absolute tolerance of 0 is probably not ideal. I guess this is
a
-1 on the 'arr' name. I think if we're going to support this function at
all (which I'm not convinced is a good idea), it should be np.fromsomething
like the other from* functions.
Maybe frommatlab?
I think that 'arr' is just too generic and too close to 'array'.
On Tue, Jul 15, 2014 at
On Fri, Jul 18, 2014 at 9:03 AM, Sebastian Berg
sebast...@sipsolutions.net wrote:
On Do, 2014-07-17 at 09:48 -0400, Robert Lupton the Good wrote:
Having just re-read the PEP I'm concerned that this proposal leaves at least
one major (?) trap for naive users, namely
x = np.array([1, 10])
On Thu, Jul 17, 2014 at 10:05 PM, Chris Barker chris.bar...@noaa.gov wrote:
A bit of a higher-level view of the issues at hand.
Python has three relevant data types:
A unicode type (unicode in py2, str in py3)
A one-byte-per-char stringtype (py2 string)
A bytes type
The big problem is
On Thu, Jul 17, 2014 at 9:07 PM, josef.p...@gmail.com wrote:
On Wed, Jul 16, 2014 at 9:52 AM, Nathaniel Smith n...@pobox.com wrote:
What you say makes sense to me, and loosening the default tolerances won't
break any existing tests. (And I'm not too worried about people who were
counting on
On Tue, Jul 15, 2014 at 11:15 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Tue, Jul 15, 2014 at 5:26 AM, Sebastian Berg
sebast...@sipsolutions.net wrote:
On Sa, 2014-07-12 at 12:17 -0500, Charles R Harris wrote:
As previous posts have pointed out, Numpy's `S` type is
On Wed, Jul 16, 2014 at 1:47 PM, Ralf Gommers ralf.gomm...@gmail.com
wrote:
On Wed, Jul 16, 2014 at 6:37 AM, Tony Yu tsy...@gmail.com wrote:
Is there any reason why the defaults for `allclose` and `assert_allclose`
differ? This makes debugging a broken test much more difficult. More
Are the problems with sending out the messages with the mailing lists?
I'm getting some replies without original messages, and in some threads I
don't get replies, missing part of the discussions.
Josef
___
NumPy-Discussion mailing list
On Thu, Jul 17, 2014 at 11:10 PM, Charles G. Waldman char...@crunch.io wrote:
-1 on the 'arr' name. I think if we're going to support this function at all
(which I'm not convinced is a good idea), it should be np.fromsomething like
the other from* functions.
Maybe frommatlab?
I think
On Thu, Jul 17, 2014 at 4:07 PM, josef.p...@gmail.com wrote:
On Wed, Jul 16, 2014 at 9:52 AM, Nathaniel Smith n...@pobox.com wrote:
On 16 Jul 2014 10:26, Tony Yu tsy...@gmail.com wrote:
Is there any reason why the defaults for `allclose` and
`assert_allclose` differ? This makes
hi,
I have been doing a lot of backporting for the last few bugfix
releases and noticed that our current approach committing to master
and cherrypicking is not so good for the git history.
When cherry picking a bugfix from master to a maintenance branch both
branches contain a commit with the same
On Thu, Jul 17, 2014 at 11:52 AM, Nathaniel Smith n...@pobox.com wrote:
On Tue, Jul 15, 2014 at 7:40 PM, Aldcroft, Thomas
aldcr...@head.cfa.harvard.edu wrote:
On Sat, Jul 12, 2014 at 8:02 PM, Nathaniel Smith n...@pobox.com wrote:
OTOH, fixed length nul padded latin1 would be useful for
On Thu, Jul 17, 2014 at 11:37 AM, Nathaniel Smith n...@pobox.com wrote:
On Wed, Jul 16, 2014 at 7:47 PM, Ralf Gommers ralf.gomm...@gmail.com
wrote:
On Wed, Jul 16, 2014 at 6:37 AM, Tony Yu tsy...@gmail.com wrote:
It seems like the defaults for `allclose` and `assert_allclose` should
On Thu, Jul 17, 2014 at 5:48 PM, Nathaniel Smith n...@pobox.com wrote:
On Tue, Jul 15, 2014 at 4:29 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Thinking more about it, the easiest thing to do might be to make the S dtype
a UTF-8 encoding. Most of the machinery to deal with that is
On Wed, Jul 16, 2014 at 12:53 PM, Ralf Gommers ralf.gomm...@gmail.com
wrote:
On Wed, Jul 16, 2014 at 10:07 AM, Nathaniel Smith n...@pobox.com wrote:
Weirdly, I never received Chuck's original email in this thread. Should
some list admin be informed?
Also weirdly, my reply didn't show up
On Fri, Jul 18, 2014 at 2:03 AM, Sebastian Berg sebast...@sipsolutions.net
wrote:
On Do, 2014-07-17 at 09:48 -0400, Robert Lupton the Good wrote:
Having just re-read the PEP I'm concerned that this proposal leaves at
least one major (?) trap for naive users, namely
x = np.array([1,
Yes I've filed a ticket with Enthought.
On Fri, Jul 18, 2014 at 7:07 AM, josef.p...@gmail.com wrote:
Are the problems with sending out the messages with the mailing lists?
I'm getting some replies without original messages, and in some threads I
don't get replies, missing part of the
On Tue, Jul 15, 2014 at 4:29 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Thinking more about it, the easiest thing to do might be to make the S dtype
a UTF-8 encoding. Most of the machinery to deal with that is already in
place. That change might affect some users though, and we might
On Fri, Jul 18, 2014 at 8:13 AM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
hi,
I have been doing a lot of backporting for the last few bugfix
releases and noticed that our current approach committing to master
and cherrypicking is not so good for the git history.
When cherry
On 18 Jul 2014, at 01:07 pm, josef.p...@gmail.com wrote:
Are the problems with sending out the messages with the mailing lists?
I'm getting some replies without original messages, and in some threads I
don't get replies, missing part of the discussions.
There seem to be problems with the
On Wed, Jul 16, 2014 at 11:16 AM, Pauli Virtanen p...@iki.fi wrote:
Hi,
15.07.2014 21:06, Julian Taylor kirjoitti:
[clip: __numpy_ufunc__]
So I'm wondering if we should delay the introduction of this
feature to 1.10 or is it important enough to wait until there is a
consensus on the
On Fri, Jul 18, 2014 at 5:38 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Fri, Jul 18, 2014 at 8:13 AM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
hi,
I have been doing a lot of backporting for the last few bugfix
releases and noticed that our current approach
Hi Chris,
A Latin-1 based 'a' type
would have similar problems.
Maybe not -- latin1 is fixed width.
Yes, Latin-1 is fixed width, but the issue is that when writing to a
fixed-width UTF8 string in HDF5, it will expand, possibly losing data.
What I would like to avoid is a situation where a
On Fri, Jul 18, 2014 at 9:07 AM, Pauli Virtanen p...@iki.fi wrote:
Another approach would be to add a new 1-byte unicode
you can't do unicode in 1-byte -- so what does this mean, exactly?
This also is not perfect, since array(['foo']) on Py2 should for
backward compatibility continue
On Fri, Jul 18, 2014 at 6:23 PM, Nathaniel Smith n...@pobox.com wrote:
On 18 Jul 2014 15:36, Julian Taylor jtaylor.deb...@googlemail.com wrote:
git rebase --onto $(git merge-base master maintenance/1.9.x) HEAD^
As a potential refinement, this might be simpler if we define a branch that
On Fri, Jul 18, 2014 at 3:37 AM, Nathaniel Smith n...@pobox.com wrote:
On Thu, Jul 17, 2014 at 11:10 PM, Charles G. Waldman char...@crunch.io
wrote:
-1 on the 'arr' name. I think if we're going to support this function
at all (which I'm not convinced is a good idea), it should be
On Fri, Jul 18, 2014 at 12:38 PM, josef.p...@gmail.com wrote:
On Thu, Jul 17, 2014 at 4:07 PM, josef.p...@gmail.com wrote:
If you mean by this to add atol=1e-8 as default, then I'm against it.
At least it will change the meaning of many of our tests in statsmodels.
I'm using rtol to check
On Fri, Jul 18, 2014 at 9:32 AM, Andrew Collette andrew.colle...@gmail.com
wrote:
A Latin-1 based 'a' type
would have similar problems.
Maybe not -- latin1 is fixed width.
Yes, Latin-1 is fixed width, but the issue is that when writing to a
fixed-width UTF8 string in HDF5, it will
On Fri, Jul 18, 2014 at 5:54 PM, Chris Barker chris.bar...@noaa.gov wrote:
This is why I see no downside to latin-1 -- if you don't use the 127 code
points, it's the same thing -- if you do, you get some extra handy
characters. The only difference is that a proper ascii type would not let
On Fri, Jul 18, 2014 at 3:02 PM, Charles G. Waldman char...@crunch.io wrote:
I greatly prefer np.mat to np.arr for this, FWIW
Unfortunately that's already taken...
--
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org
We think this is fixed now. Let me know if it is otherwise.
On Thu, Jul 17, 2014 at 7:04 AM, Nathaniel Smith n...@pobox.com wrote:
On 17 Jul 2014 11:51, Sebastian Berg sebast...@sipsolutions.net wrote:
On Mi, 2014-07-16 at 09:07 +0100, Nathaniel Smith wrote:
Weirdly, I never received Chuck's
On Fri, Jul 18, 2014 at 9:53 AM, Nathaniel Smith n...@pobox.com wrote:
I don't know what the usecases for np.allclose are since I don't have
any.
I use it all the time -- sometimes you want to check something, but not
raise an assertion -- and I use it like:
assert np.allclose()
with
The Enthought support tells me this is fixed now. Please let me know
if otherwise.
On Fri, Jul 18, 2014 at 8:09 AM, Derek Homeier
de...@astro.physik.uni-goettingen.de wrote:
On 18 Jul 2014, at 01:07 pm, josef.p...@gmail.com wrote:
Are the problems with sending out the messages with the mailing
On 7/18/2014 12:45 PM, Mark Miller wrote:
If the true goal is to just allow quick entry of a 2d array, why not just
advocate using
a = numpy.array(numpy.mat(1 2 3; 4 5 6; 7 8 9))
It's even simpler:
a = np.mat(' 1 2 3;4 5 6;7 8 9').A
I'm not putting a dog in this race. Still I would say
18.07.2014 19:33, Chris Barker kirjoitti:
On Fri, Jul 18, 2014 at 9:07 AM, Pauli Virtanen p...@iki.fi
wrote:
Another approach would be to add a new 1-byte unicode
you can't do unicode in 1-byte -- so what does this mean, exactly?
The first 256 unicode code points, which happen to coincide
Hi Chris,
Again, they shouldn't do that, they should be pushing a 10-character string
into something -- and utf-8 is going to (Possible) truncate that. That's
HDF/utf-8 limitation that people are going to have to deal with. I think
you're suggesting that numpy follow the HDF model, so that
On Fri, Jul 18, 2014 at 10:59 AM, Nathaniel Smith n...@pobox.com wrote:
On Fri, Jul 18, 2014 at 5:54 PM, Chris Barker chris.bar...@noaa.gov
wrote:
This is why I see no downside to latin-1 -- if you don't use the 127
code
points, it's the same thing -- if you do, you get some extra handy
18.07.2014 19:35, Julian Taylor kirjoitti:
On Fri, Jul 18, 2014 at 6:23 PM, Nathaniel Smith n...@pobox.com
wrote:
On 18 Jul 2014 15:36, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
git rebase --onto $(git merge-base master maintenance/1.9.x)
HEAD^
As a potential refinement, this
On Fri, Jul 18, 2014 at 2:03 PM, josef.p...@gmail.com wrote:
On Fri, Jul 18, 2014 at 12:53 PM, Nathaniel Smith n...@pobox.com wrote:
On Fri, Jul 18, 2014 at 12:38 PM, josef.p...@gmail.com wrote:
On Thu, Jul 17, 2014 at 4:07 PM, josef.p...@gmail.com wrote:
If you mean by this to add
On Fri, Jul 18, 2014 at 2:29 PM, Nathaniel Smith n...@pobox.com wrote:
On Fri, Jul 18, 2014 at 7:03 PM, josef.p...@gmail.com wrote:
On Fri, Jul 18, 2014 at 12:53 PM, Nathaniel Smith n...@pobox.com wrote:
For cases like this, you need *some* non-zero atol or the thing just
doesn't
Well, if the goal is shorthand, typing numpy.array(numpy.mat())
won't please many users.
But the more I think about it, the less I think Numpy should support
this (non-Pythonic) input mode. Too much molly-coddling of new users!
When doing interactive work I usually just type:
On 18 Jul 2014 19:31, josef.p...@gmail.com wrote:
Making the behavior of assert_allclose depending on whether desired is
exactly zero or 1e-20 looks too difficult to remember, and which
desired I
use would depend on what I get out of R or Stata.
I thought your whole point here was that
18.07.2014 21:03, josef.p...@gmail.com kirjoitti:
[clip]
Of course you can change it.
But the testing functions are code and very popular code.
And if you break backwards compatibility, then I wouldn't mind reviewing a
pull request for statsmodels that adds 300 to 400 `atol=0` to the unit
On 18 Jul 2014 18:06, Alan G Isaac alan.is...@gmail.com wrote:
On 7/18/2014 12:45 PM, Mark Miller wrote:
If the true goal is to just allow quick entry of a 2d array, why not
just advocate using
a = numpy.array(numpy.mat(1 2 3; 4 5 6; 7 8 9))
It's even simpler:
a = np.mat(' 1 2 3;4 5 6;7
On Wed, Jul 16, 2014 at 8:08 PM, Fernando Perez fperez@gmail.com
wrote:
- it would have been more productive if a focused numpy sprint had been
also planned, so that there could be more structured follow-up on the ideas
that came up.
The trick is people to do it -- there are a scary few
On Fri, Jul 18, 2014 at 11:49 AM, Nathaniel Smith n...@pobox.com wrote:
Going through np.mat also fails on the meta-goal, which is to remove
reasons for people to prefer np.matrix to np.ndarray, so that eventually we
can deprecate the former without harm.
As far as this goal goes, it's all
On Fri, Jul 18, 2014 at 2:44 PM, Nathaniel Smith n...@pobox.com wrote:
On 18 Jul 2014 19:31, josef.p...@gmail.com wrote:
Making the behavior of assert_allclose depending on whether desired is
exactly zero or 1e-20 looks too difficult to remember, and which
desired I
use would
On Fri, Jul 18, 2014 at 11:47 AM, Pauli Virtanen p...@iki.fi wrote:
Using allclose in non-test code without specifying both tolerances
explicitly is IMHO a sign of sloppiness, as the default tolerances are
both pretty big (and atol != 0 is not scale-free).
using it without specifying
On Fri, Jul 18, 2014 at 9:59 AM, Nathaniel Smith n...@pobox.com wrote:
IMO the extra characters aren't the most compelling argument for
latin1 over ascii. Latin1 gives the nice assurance that if some jerk
*does* give me an ascii file that somewhere has some byte with the
8th bit set, then I
On Fri, Jul 18, 2014 at 9:59 AM, Nathaniel Smith n...@pobox.com wrote:
IMO the extra characters aren't the most compelling argument for
latin1 over ascii. Latin1 gives the nice assurance that if some jerk
*does* give me an ascii file that somewhere has some byte with the
8th bit set, then I
18.07.2014 22:13, Chris Barker kirjoitti:
[clip]
but an appropriate rtol would work there too. If only zero testing is
needed, then atol=0 makes sense as a default. (or maybe atol=eps)
There's plenty of room below eps, but finfo(float).tiny ~ 3e-308 (or
some big multiple) is also reasonable in
Hi Chris,
What it would do is push the problem from the HDF5-numpy interface to the
python-numpy interface.
I'm not sure that's a good trade off.
Maybe I'm being too paranoid about the truncation issue. We already
perform truncation when going from e.g. vlen to fixed-width strings in
Le 18/07/2014 20:42, Charles G. Waldman a écrit :
Well, if the goal is shorthand, typing numpy.array(numpy.mat())
won't please many users.
But the more I think about it, the less I think Numpy should support
this (non-Pythonic) input mode. Too much molly-coddling of new users!
When doing
Joseph Martinot-Lagarde writes:
Compare what's comparable:
That's fair.
In addition, you have to use AltGr on some keyboards to get the brackets
Wow, it must be rather painful to do any real programming on such a keyboard!
- C
On Fri, Jul 18, 2014 at 1:15 PM, Joseph Martinot-Lagarde
On Fri, Jul 18, 2014 at 4:21 PM, Charles G. Waldman char...@crunch.io
wrote:
Joseph Martinot-Lagarde writes:
Compare what's comparable:
That's fair.
In addition, you have to use AltGr on some keyboards to get the brackets
Wow, it must be rather painful to do any real programming on
On Fri, Jul 18, 2014 at 12:52 PM, Andrew Collette andrew.colle...@gmail.com
wrote:
What it would do is push the problem from the HDF5-numpy interface to
the
python-numpy interface.
I'm not sure that's a good trade off.
Maybe I'm being too paranoid about the truncation issue.
On Fri, Jul 18, 2014 at 1:15 PM, Joseph Martinot-Lagarde
joseph.martinot-laga...@m4x.org wrote:
In addition,
you have to use AltGr on some keyboards to get the brackets.
If it's hard to type square brackets -- you're kind of dead in the water
with Python anyway -- this is not going to help.
On 18.07.2014 19:47, Pauli Virtanen wrote:
18.07.2014 19:35, Julian Taylor kirjoitti:
On Fri, Jul 18, 2014 at 6:23 PM, Nathaniel Smith n...@pobox.com
wrote:
On 18 Jul 2014 15:36, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
git rebase --onto $(git merge-base master maintenance/1.9.x)
Le 18/07/2014 22:46, Chris Barker a écrit :
On Fri, Jul 18, 2014 at 1:15 PM, Joseph Martinot-Lagarde
joseph.martinot-laga...@m4x.org
mailto:joseph.martinot-laga...@m4x.org wrote:
In addition,
you have to use AltGr on some keyboards to get the brackets.
If it's hard to type square
Hi Chris,
Actually, I agree about the truncation issue, but it's a question of where
to put it -- I'm suggesting that I don't want it at the python-numpy
interface.
Yes, that's a good point. Of course, by using Latin-1 rather than
UTF-8 we can't support all Unicode code points (hence the ?
On Fri, Jul 18, 2014 at 5:04 PM, Joseph Martinot-Lagarde
joseph.martinot-laga...@m4x.org wrote:
Le 18/07/2014 22:46, Chris Barker a écrit :
On Fri, Jul 18, 2014 at 1:15 PM, Joseph Martinot-Lagarde
joseph.martinot-laga...@m4x.org
mailto:joseph.martinot-laga...@m4x.org wrote:
In
On Fri, Jul 18, 2014 at 3:30 PM, Andrew Collette andrew.colle...@gmail.com
wrote:
Hi Chris,
Actually, I agree about the truncation issue, but it's a question of
where
to put it -- I'm suggesting that I don't want it at the python-numpy
interface.
Yes, that's a good point. Of course,
18.07.2014 23:53, Julian Taylor kirjoitti:
On 18.07.2014 19:47, Pauli Virtanen wrote:
[clip]
The other well-known alternative to bugfixes is to first commit it in
the earliest maintenance branch where you want to have it, and then
merge that branch forward to the newer maintenance branches,
On Fri, Jul 18, 2014 at 11:44 PM, Pauli Virtanen p...@iki.fi wrote:
18.07.2014 23:53, Julian Taylor kirjoitti:
On 18.07.2014 19:47, Pauli Virtanen wrote:
[clip]
The other well-known alternative to bugfixes is to first commit it in
the earliest maintenance branch where you want to have it,
19.07.2014 01:49, Nathaniel Smith kirjoitti:
On Fri, Jul 18, 2014 at 11:44 PM, Pauli Virtanen p...@iki.fi wrote:
18.07.2014 23:53, Julian Taylor kirjoitti:
On 18.07.2014 19:47, Pauli Virtanen wrote:
[clip]
The other well-known alternative to bugfixes is to first commit it in
the earliest
19.07.2014 02:10, Pauli Virtanen kirjoitti:
19.07.2014 01:49, Nathaniel Smith kirjoitti:
On Fri, Jul 18, 2014 at 11:44 PM, Pauli Virtanen p...@iki.fi wrote:
[clip]
Presumably all the commits that we miss on the first pass and end up
backporting the hard way later :-)
If those are just
Hi everyone,
I am trying to install a package called PySparse. I have modified the paths
in the template site.cfg file. It appears that during the built process it
compiles numpy as well, because the error messages I get are all over the
numpy mailing list (I did not find one addressing my
On Fri, Jul 18, 2014 at 2:32 PM, Chris Barker chris.bar...@noaa.gov wrote:
On Fri, Jul 18, 2014 at 12:43 PM, Pauli Virtanen p...@iki.fi wrote:
18.07.2014 22:13, Chris Barker kirjoitti:
[clip]
but an appropriate rtol would work there too. If only zero testing is
needed, then atol=0 makes
On Fri, Jul 18, 2014 at 9:47 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Fri, Jul 18, 2014 at 2:32 PM, Chris Barker chris.bar...@noaa.gov wrote:
On Fri, Jul 18, 2014 at 12:43 PM, Pauli Virtanen p...@iki.fi wrote:
18.07.2014 22:13, Chris Barker kirjoitti:
[clip]
but an
77 matches
Mail list logo
