On 10/10/13 19:31, Jonathan M Davis wrote:
I'm honestly surprised that Andrei is rejecting the idea of casting to/from
shared or immutable being normal given how it's required by our current
concurrency model. And changing that would be a _big_ change.
I'm starting to incline towards the view t
On Oct 10, 2013, at 10:23 AM, Joseph Rushton Wakeling
wrote:
> On 09/10/13 06:25, Andrei Alexandrescu wrote:
>> The way I see it we must devise a robust solution to that, NOT consider the
>> state of the art immutable (heh, a pun).
>
> Must say I have had a miserable experience with immutabilit
On 10/10/13 19:39, Sean Kelly wrote:
As long as the reference itself can be reassigned (tail-immutable, I suppose) I
think immutable is occasionally quite useful for complex data structures. It
basically formalizes the RCU (read-copy-update) approach to wait-free
concurrency. I'd tend to use
On Oct 10, 2013, at 10:36 AM, Joseph Rushton Wakeling
wrote:
> On 10/10/13 19:31, Jonathan M Davis wrote:
>> I'm honestly surprised that Andrei is rejecting the idea of casting to/from
>> shared or immutable being normal given how it's required by our current
>> concurrency model. And changing t
On Thursday, October 10, 2013 10:27:24 Sean Kelly wrote:
> On Oct 9, 2013, at 9:24 PM, Jonathan M Davis wrote:
> > And given that std.concurrency requires casting to and from shared or
> > immutable in order to pass objects across threads, it seems ilke most of
> > D's concurrency model requires c
On Oct 10, 2013, at 10:43 AM, Joseph Rushton Wakeling
wrote:
> On 10/10/13 19:39, Sean Kelly wrote:
>> As long as the reference itself can be reassigned (tail-immutable, I
>> suppose) I think immutable is occasionally quite useful for complex data
>> structures. It basically formalizes the RC
On 10/10/13 12:18 AM, Walter Bright wrote:
On 10/9/2013 11:34 PM, Jacob Carlborg wrote:
On 2013-10-10 02:22, Sean Kelly wrote:
Only that this would have to be communicated to the user, since
moving data
later is problematic. Today, I think it's common to construct an
object as
unshared and the
On Oct 10, 2013, at 10:50 AM, "Jonathan M Davis" wrote:
> On Thursday, October 10, 2013 10:27:24 Sean Kelly wrote:
>> On Oct 9, 2013, at 9:24 PM, Jonathan M Davis wrote:
>>> And given that std.concurrency requires casting to and from shared or
>>> immutable in order to pass objects across thread
On 10/10/13 12:33 AM, Jonathan M Davis wrote:
I honestly don't think we can solve it a different way without completely
redesigning shared. shared is specifically designed such that you have to
either cast it way to do anything with it
no
or write all of your code to
explicitly work with shar
On Oct 10, 2013, at 10:55 AM, Andrei Alexandrescu
wrote:
> On 10/10/13 12:33 AM, Jonathan M Davis wrote:
>
>> Far more frequently, you want to share a type which you would also
>> use normally as a thread-local variable, and that means casting.
>
> no
Yeah, I'd want to see this claim backed u
On Wed, 09 Oct 2013 22:30:05 +0200, Adam D. Ruppe wrote:
> On Wednesday, 9 October 2013 at 20:10:40 UTC, Justin Whear wrote:
>> Related to the latter, it would be really nice to be able to prove that
>> a section of code makes no heap allocations/GC collections.
>
> As a quick temporary thing, ho
On 10/10/13 19:50, Sean Kelly wrote:
Configuration data, for example. On app start you might load a config file,
generate information about the user, and so on, before real processing begins.
This data needs to be visible everywhere and it rarely if ever changes as the
program runs, so you f
On 10/10/13 19:46, Sean Kelly wrote:
As for const / immutable, I guess I don't see this as such an issue because
I've been dealing with it in C++ for so long. You either have to commit 100%
to using const attributes or not use them at all. Anything in between is
fraught with problems.
Well
On Oct 10, 2013, at 11:17 AM, Joseph Rushton Wakeling
wrote:
> On 10/10/13 19:50, Sean Kelly wrote:
>> Configuration data, for example. On app start you might load a config file,
>> generate information about the user, and so on, before real processing
>> begins. This data needs to be visibl
On Oct 10, 2013, at 11:21 AM, Joseph Rushton Wakeling
wrote:
> On 10/10/13 19:46, Sean Kelly wrote:
>> As for const / immutable, I guess I don't see this as such an issue because
>> I've been dealing with it in C++ for so long. You either have to commit
>> 100% to using const attributes or no
On Thursday, 10 October 2013 at 17:23:20 UTC, Joseph Rushton
Wakeling wrote:
On 09/10/13 06:25, Andrei Alexandrescu wrote:
The way I see it we must devise a robust solution to that, NOT
consider the
state of the art immutable (heh, a pun).
Must say I have had a miserable experience with immut
On 2013-10-10 17:34:47 +, Sean Kelly said:
On Oct 10, 2013, at 4:17 AM, Michel Fortin
wrote:
http://michelf.ca/blog/2012/mutex-synchonization-in-d/
Good article. But why didn't you mention core.sync? It has both a
Mutex and a ReadWriteMutex (ie. shared_mutex).
Because that would ha
On Thu, Oct 10, 2013 at 07:36:06PM +0200, Joseph Rushton Wakeling wrote:
> On 10/10/13 19:31, Jonathan M Davis wrote:
> >I'm honestly surprised that Andrei is rejecting the idea of casting
> >to/from shared or immutable being normal given how it's required by
> >our current concurrency model. And c
On 10/10/2013 10:54 AM, Andrei Alexandrescu wrote:
On 10/10/13 12:18 AM, Walter Bright wrote:
On 10/9/2013 11:34 PM, Jacob Carlborg wrote:
On 2013-10-10 02:22, Sean Kelly wrote:
Only that this would have to be communicated to the user, since
moving data
later is problematic. Today, I think it
On 10/10/13 20:28, Sean Kelly wrote:
Isn't BigInt a struct? I'd expect it to work via copying just like concrete
types.
Yes, it's a struct, but somewhere inside its internals I think it contains
arrays. I'm not sure how that affects copying etc., but suffice to say that if
you try the foll
On 10/10/13 20:28, H. S. Teoh wrote:
I don't know about shared, though. Last I heard, shared was one big mess
so I'm not even going to touch it.
Yes, that seems to be the consensus.
On 2013-10-10 16:14, Michel Fortin wrote:
similar. I don't think it's a good practice to make a mutex part of the
public interface of an object (or any public interface for that matter),
which is why they're kept private inside the class in my examples.
Public mutexes can be locked from anywhere
On 10/10/13 20:28, H. S. Teoh wrote:
I left some comments on these bugs. Basically, BigInt should not be
implicitly castable from const/immutable to unqual, because unlike the
built-in types, it's *not* a value type:
BigInt x = 123;
BigInt y = x; // creates an alias to x's data.
On Thu, Oct 10, 2013 at 08:39:52PM +0200, Joseph Rushton Wakeling wrote:
> On 10/10/13 20:28, Sean Kelly wrote:
> >Isn't BigInt a struct? I'd expect it to work via copying just like
> >concrete types.
>
> Yes, it's a struct, but somewhere inside its internals I think it
> contains arrays. I'm no
On 10/10/2013 10:27 AM, Sean Kelly wrote:
> [...]
Sean - whatever means you're using to reply breaks the thread.
On Oct 10, 2013, at 12:11 PM, Walter Bright wrote:
> On 10/10/2013 10:27 AM, Sean Kelly wrote:
> > [...]
>
> Sean - whatever means you're using to reply breaks the thread.
The mailing list Brad set up--I can't do NNTP from most locations. I guess
I'll use the website.
On 10/10/2013 12:38 PM, Sean Kelly wrote:
On Oct 10, 2013, at 12:11 PM, Walter Bright wrote:
On 10/10/2013 10:27 AM, Sean Kelly wrote:
[...]
Sean - whatever means you're using to reply breaks the thread.
The mailing list Brad set up--I can't do NNTP from most locations. I guess
I'll use
On Thursday, 10 October 2013 at 20:50:10 UTC, Walter Bright wrote:
I'm curious why NNTP would be blocked. I've been able to access
it from any wifi hotspots I've tried it from.
My only guess is that usenet may be perceived as a illegal file
sharing resource. But it's been a while since I've
On Thursday, 10 October 2013 at 17:36:11 UTC, Joseph Rushton
Wakeling wrote:
On 10/10/13 19:31, Jonathan M Davis wrote:
I'm honestly surprised that Andrei is rejecting the idea of
casting to/from
shared or immutable being normal given how it's required by
our current
concurrency model. And cha
On Thursday, 10 October 2013 at 17:39:55 UTC, Sean Kelly wrote:
On Oct 10, 2013, at 10:23 AM, Joseph Rushton Wakeling
wrote:
On 09/10/13 06:25, Andrei Alexandrescu wrote:
The way I see it we must devise a robust solution to that,
NOT consider the
state of the art immutable (heh, a pun).
M
On Thursday, 10 October 2013 at 21:15:39 UTC, Sean Kelly wrote:
On Thursday, 10 October 2013 at 20:50:10 UTC, Walter Bright
wrote:
I'm curious why NNTP would be blocked. I've been able to
access it from any wifi hotspots I've tried it from.
My only guess is that usenet may be perceived as a
On Thursday, October 10, 2013 11:28:02 Walter Bright wrote:
> On 10/10/2013 10:54 AM, Andrei Alexandrescu wrote:
> > On 10/10/13 12:18 AM, Walter Bright wrote:
> >> 1. Shared data cannot be passed to regular functions.
> >
> > I don't understand this. If a function/method accepts "shared", then it
On Thursday, October 10, 2013 11:11:12 Sean Kelly wrote:
> On Oct 10, 2013, at 10:55 AM, Andrei Alexandrescu
wrote:
> > On 10/10/13 12:33 AM, Jonathan M Davis wrote:
> >> Far more frequently, you want to share a type which you would also
> >> use normally as a thread-local variable, and that mean
On Thursday, 10 October 2013 at 23:33:27 UTC, Jonathan M Davis
wrote:
Yeah. The only times that something is going to accept shared
is when it was
specifically designed to work as shared (which most code
isn't), or if it's
templated and the template happens to work with shared. Regular
functi
On Thursday, 10 October 2013 at 23:33:17 UTC, Jonathan M Davis
wrote:
I just don't see how you could avoid casting when passing
ownership of an
object from one thread to another without having a way to pass
an object
across threads without having to make it shared or immutable to
pass it.
W
On 2013-10-10, 20:28, H. S. Teoh wrote:
On Thu, Oct 10, 2013 at 07:36:06PM +0200, Joseph Rushton Wakeling wrote:
On 10/10/13 19:31, Jonathan M Davis wrote:
>I'm honestly surprised that Andrei is rejecting the idea of casting
>to/from shared or immutable being normal given how it's required by
>
On Thursday, October 10, 2013 10:55:49 Andrei Alexandrescu wrote:
> On 10/10/13 12:33 AM, Jonathan M Davis wrote:
> > I honestly don't think we can solve it a different way without completely
> > redesigning shared. shared is specifically designed such that you have to
> > either cast it way to do
On 10/10/13 10:36 AM, Joseph Rushton Wakeling wrote:
On 10/10/13 19:31, Jonathan M Davis wrote:
I'm honestly surprised that Andrei is rejecting the idea of casting
to/from
shared or immutable being normal given how it's required by our current
concurrency model. And changing that would be a _big
On Friday, 11 October 2013 at 00:30:35 UTC, Simen Kjaeraas wrote:
Here's a COW reference type that I can easily pass to a function
requiring a mutable version of the type:
struct S {
immutable(int)[] arr;
}
And usage:
void foo(S s) {}
void main() {
const S s;
foo(s);
}
On Friday, October 11, 2013 02:05:19 Sean Kelly wrote:
> It would be yet another step
> towards not having thread-local pools though.
At this point, I don't see how we can have thread-local pools unless casting
to and from shared has hooks for managing that. Otherwise, it's far too likely
that a
On Friday, October 11, 2013 02:08:16 Sean Kelly wrote:
> On Thursday, 10 October 2013 at 23:33:27 UTC, Jonathan M Davis
>
> wrote:
> > Yeah. The only times that something is going to accept shared
> > is when it was
> > specifically designed to work as shared (which most code
> > isn't), or if it'
On 11/10/13 02:30, Simen Kjaeraas wrote:
TLDR: Do not use inout(T). Fix BigInt.
Yes, that's my feeling too.
Even if you do add inout (or "in", which also works in terms of allowing
qualified BigInts) to std.math.abs, you immediately run back into problems ...
with BigInt.
On 10/10/13 4:33 PM, Jonathan M Davis wrote:
I just don't see how you could avoid casting when passing ownership of an
object from one thread to another without having a way to pass an object
across threads without having to make it shared or immutable to pass it.
By using restricted library ty
On 11/10/13 02:44, Andrei Alexandrescu wrote:
I'll look into this soon.
That would be fantastic, thank you very much.
Any chance you could ask Don Clugston to get in touch with me about these
issues? std.bigint is his, and I know he was in touch with David Simcha about
std.rational. I don'
On 10/10/13 5:36 PM, Jonathan M Davis wrote:
On Thursday, October 10, 2013 10:55:49 Andrei Alexandrescu wrote:
On 10/10/13 12:33 AM, Jonathan M Davis wrote:
I honestly don't think we can solve it a different way without completely
redesigning shared. shared is specifically designed such that yo
On Thursday, October 10, 2013 18:21:52 Andrei Alexandrescu wrote:
> On 10/10/13 5:36 PM, Jonathan M Davis wrote:
> > On Thursday, October 10, 2013 10:55:49 Andrei Alexandrescu wrote:
> >> On 10/10/13 12:33 AM, Jonathan M Davis wrote:
> >>> or write all of your code to
> >>> explicitly work with sha
On 10/10/13 7:04 PM, Jonathan M Davis wrote:
On Thursday, October 10, 2013 18:21:52 Andrei Alexandrescu wrote:
You can't EVER expect to obtain all of that magic by plastering "shared"
on top of your type.
It works just fine with the idiom that I described where you protect the usage
of the obj
On 2013-10-11 02:08:02 +, Andrei Alexandrescu
said:
On 10/10/13 7:04 PM, Jonathan M Davis wrote:
On Thursday, October 10, 2013 18:21:52 Andrei Alexandrescu wrote:
You can't EVER expect to obtain all of that magic by plastering "shared"
on top of your type.
It works just fine with the i
On 10/10/13 7:37 PM, Michel Fortin wrote:
On 2013-10-11 02:08:02 +, Andrei Alexandrescu
said:
On 10/10/13 7:04 PM, Jonathan M Davis wrote:
On Thursday, October 10, 2013 18:21:52 Andrei Alexandrescu wrote:
You can't EVER expect to obtain all of that magic by plastering
"shared"
on top of
On Thursday, October 10, 2013 19:43:40 Andrei Alexandrescu wrote:
> On 10/10/13 7:37 PM, Michel Fortin wrote:
> > Anyway, that whole concept of synchronized class is a deadlock honeypot.
> > It should be scrapped altogether.
>
> People still use it.
To some extent in that some folks used synchron
On Thursday, October 10, 2013 19:08:02 Andrei Alexandrescu wrote:
> On 10/10/13 7:04 PM, Jonathan M Davis wrote:
> > On Thursday, October 10, 2013 18:21:52 Andrei Alexandrescu wrote:
> >> You can't EVER expect to obtain all of that magic by plastering "shared"
> >> on top of your type.
> >
> > It
On 2013-10-11 03:05, Jonathan M Davis wrote:
I'm not disagreeing with how shared works. I'm disagreeing with the idea that
it's not supposed to be normal to cast shared away when operating on shared
objects. I expect that the most common idiom for dealing with shared is to
protect it with a lock
On Wednesday, 9 October 2013 at 09:01:12 UTC, Walter Bright wrote:
On 10/9/2013 1:59 AM, JR wrote:
On Wednesday, 9 October 2013 at 02:22:35 UTC, Andrei
Alexandrescu wrote:
* Get Robert Schadek's precise GC in. Walter and I have
become 101% convinced
a precise GC is the one way to go about GC.
On 2013-10-11 02:51, Jonathan M Davis wrote:
At this point, I don't see how we can have thread-local pools unless casting
to and from shared has hooks for managing that. Otherwise, it's far too likely
that an object is going to be in the wrong pool, because it's being used as
shared when it was
Am Thu, 10 Oct 2013 22:04:16 -0400
schrieb "Jonathan M Davis" :
> most D programmers seem to describe when talking about shared is
> simply using __gshared with normal types, not even using shared, let
> alone using it with types specifically designed to function as
> shared. So, the most common a
On Tuesday, 8 October 2013 at 22:37:28 UTC, Walter Bright wrote:
On 10/8/2013 9:22 AM, Dicebot wrote:
It is simply "@nogc" which is lacking but absolutely
mandatory.
Adding @nogc is fairly simple. The trouble, though, is (like
purity) it is transitive. Every function an @nogc function
calls
11-Oct-2013 05:21, Andrei Alexandrescu пишет:
On 10/10/13 5:36 PM, Jonathan M Davis wrote:
On Thursday, October 10, 2013 10:55:49 Andrei Alexandrescu wrote:
On 10/10/13 12:33 AM, Jonathan M Davis wrote:
I honestly don't think we can solve it a different way without
completely
redesigning share
On 11/10/13 16:32, Dmitry Olshansky wrote:
This. And exactly the same for immutable. It's interesting how folks totally
expect complex types (like containers) to meaningfully work with all 3
qualifiers.
It's not so much that we expect it, as that we might expect that standard
library types wo
11-Oct-2013 18:46, Joseph Rushton Wakeling пишет:
On 11/10/13 16:32, Dmitry Olshansky wrote:
This. And exactly the same for immutable. It's interesting how folks
totally
expect complex types (like containers) to meaningfully work with all 3
qualifiers.
It's not so much that we expect it, as th
On Friday, 11 October 2013 at 02:07:57 UTC, Andrei Alexandrescu
wrote:
TDPL describes how synchronized automatically peels off the
"shared" off of direct members of the object. Unfortunately
that feature is not yet implemented.
This would help a ton. I'm still not super happy about having t
On Friday, 11 October 2013 at 01:05:19 UTC, Jonathan M Davis
wrote:
On Friday, October 11, 2013 02:08:16 Sean Kelly wrote:
Shared data needs to be
treated differently, explicitly, or things go downhill fast.
I'm not disagreeing with how shared works. I'm disagreeing with
the idea that
it's n
On Friday, 11 October 2013 at 17:46:01 UTC, Sean Kelly wrote:
The thing with locks is that you need to use the same lock for
all accesses to a set of mutated data or atomicity isn't
guaranteed. And if you're locking externally you don't know
what might change inside a class during a method cal
On Friday, 11 October 2013 at 17:49:11 UTC, Sean Kelly wrote:
On Friday, 11 October 2013 at 02:07:57 UTC, Andrei Alexandrescu
wrote:
TDPL describes how synchronized automatically peels off the
"shared" off of direct members of the object. Unfortunately
that feature is not yet implemented.
T
On Friday, 11 October 2013 at 17:54:12 UTC, deadalnix wrote:
It should work as well with
synchronized(stuff) {
// Stuff get its first level sharing removed.
}
I still stand by the point that for guaranteed safety it must be
not simply removed but replaced with `scope` (assuming it is
finally
On Friday, 11 October 2013 at 09:56:10 UTC, Leandro Lucarella
wrote:
This is not really what's stopping the porting, is a problem,
but an independent one. My idea was to port the GC as it is in
Tango, and then see how to overcome its limitations.
I tried this a while back, but the GC in Drun
On Friday, 11 October 2013 at 17:50:26 UTC, Dicebot wrote:
How can one possibly used "synchronized" for this in absence of
classes if desire behavior is to lock an entity, not statement
block?
I'm not sure I follow. But I was in part objecting to the use of
synchronized without a related o
On Friday, 11 October 2013 at 18:10:27 UTC, Dicebot wrote:
I was reading this :
http://dlang.org/statement.html#SynchronizedStatement
It says that Expression in sync statement must evaluate to
Object or interface and mutex get created specifically for it.
But what if I want to use struct in
On Friday, 11 October 2013 at 18:05:00 UTC, Sean Kelly wrote:
On Friday, 11 October 2013 at 17:50:26 UTC, Dicebot wrote:
How can one possibly used "synchronized" for this in absence
of classes if desire behavior is to lock an entity, not
statement block?
I'm not sure I follow. But I was in
On Friday, 11 October 2013 at 18:18:45 UTC, Sean Kelly wrote:
On Friday, 11 October 2013 at 18:10:27 UTC, Dicebot wrote:
I was reading this :
http://dlang.org/statement.html#SynchronizedStatement
It says that Expression in sync statement must evaluate to
Object or interface and mutex get cr
On Friday, 11 October 2013 at 18:10:27 UTC, Dicebot wrote:
I was reading this :
http://dlang.org/statement.html#SynchronizedStatement
It says that Expression in sync statement must evaluate to
Object or interface and mutex get created specifically for it.
But what if I want to use struct in
On Friday, 11 October 2013 at 18:19:59 UTC, Dicebot wrote:
On Friday, 11 October 2013 at 18:18:45 UTC, Sean Kelly wrote:
Synchronize on a dummy object or use core.sync.mutex:
auto m = new Mutex;
synchronized(m) {
}
It's effectively the same as in C++ except that synchronized
saves you the t
On Friday, 11 October 2013 at 18:22:46 UTC, Sean Kelly wrote:
It should. Stripping "shared" just means that you'll be able
to call any function available on the struct as opposed to only
explicitly shared functions. And the mutex gives you atomic
behavior (assuming you use the mutex properly
On Friday, October 11, 2013 16:27:53 ixid wrote:
> On Tuesday, 8 October 2013 at 22:37:28 UTC, Walter Bright wrote:
> > On 10/8/2013 9:22 AM, Dicebot wrote:
> >> It is simply "@nogc" which is lacking but absolutely
> >> mandatory.
> >
> > Adding @nogc is fairly simple. The trouble, though, is (lik
On Friday, October 11, 2013 18:32:15 Dmitry Olshansky wrote:
> 11-Oct-2013 05:21, Andrei Alexandrescu пишет:
> > Yes. Data structures that can be shared are ALWAYS designed specifically
> > for sharing, unless of course it's a trivial type like int.
>
> This. And exactly the same for immutable. It
On Friday, October 11, 2013 20:04:57 Sean Kelly wrote:
> On Friday, 11 October 2013 at 17:50:26 UTC, Dicebot wrote:
> > How can one possibly used "synchronized" for this in absence of
> > classes if desire behavior is to lock an entity, not statement
> > block?
>
> I'm not sure I follow. But I was
On Friday, 11 October 2013 at 18:26:52 UTC, Dicebot wrote:
On Friday, 11 October 2013 at 18:22:46 UTC, Sean Kelly wrote:
It should. Stripping "shared" just means that you'll be able
to call any function available on the struct as opposed to
only explicitly shared functions. And the mutex give
12-Oct-2013 00:14, Jonathan M Davis пишет:
On Friday, October 11, 2013 18:32:15 Dmitry Olshansky wrote:
11-Oct-2013 05:21, Andrei Alexandrescu пишет:
Yes. Data structures that can be shared are ALWAYS designed specifically
for sharing, unless of course it's a trivial type like int.
This. And
On 10/11/13 7:46 AM, Joseph Rushton Wakeling wrote:
On 11/10/13 16:32, Dmitry Olshansky wrote:
This. And exactly the same for immutable. It's interesting how folks
totally
expect complex types (like containers) to meaningfully work with all 3
qualifiers.
It's not so much that we expect it, as
On 11/10/13 23:02, Andrei Alexandrescu wrote:
On 10/11/13 7:46 AM, Joseph Rushton Wakeling wrote:
It's not so much that we expect it, as that we might expect that
standard library types would _have the appropriate design work put in_
so that they would "just work" with these qualifiers. (Admitt
On Tuesday, 8 October 2013 at 15:43:46 UTC, ponce wrote:
At least on Internet forums, there seems to be an entire
category of people dismissing D immediately because it has a GC.
Whatever rational rebutal we have it's never heard.
The long answer is that it's not a real problem. But it seems
p
Am 13.10.2013 16:21, schrieb qznc:
On Tuesday, 8 October 2013 at 15:43:46 UTC, ponce wrote:
At least on Internet forums, there seems to be an entire category of
people dismissing D immediately because it has a GC.
Whatever rational rebutal we have it's never heard.
The long answer is that it's
On Friday, 11 October 2013 at 17:58:07 UTC, Sean Kelly wrote:
On Friday, 11 October 2013 at 09:56:10 UTC, Leandro Lucarella
wrote:
This is not really what's stopping the porting, is a problem,
but an independent one. My idea was to port the GC as it is in
Tango, and then see how to overcome i
201 - 282 of 282 matches
Mail list logo
