On Friday, 11 November 2016 at 11:49:25 UTC, RazvanN wrote:
I am a bit confused about how the is operator works. I have a
function which receives an InputRange and a predicate. Now I
need to be able to test if the InputRange is actually a
SortedRange. I don't care about how the datatypes
On Wednesday, 9 November 2016 at 06:28:31 UTC, Jim wrote:
What does it mean when a variable name starts with a '.'
`.a` --> `::a`.
On Thursday, 27 October 2016 at 02:12:34 UTC, Jason C. Wells
wrote:
I have no idea where this ModuleInfoZ thing is coming from.
as Adam said, it means that it imports some module, and you
didn't passed it to dmd. in this case, it is iv.nanovg.oui
package (this is Blender-like GUI controls --
On Thursday, 27 October 2016 at 01:48:54 UTC, Jason C. Wells
wrote:
I'm not sure I fully understand name mangling, but it looks
like nanovg wants to use iv\stb\ttf.d from it's own source
tree. But Ketmar said "p.s. you will also need stb_ttf port,
arsd repo has it under the name "ttf.d"."
So
On Wednesday, 26 October 2016 at 05:27:53 UTC, Jason C. Wells
wrote:
Hence the repeated advice to supply all the filenames on the
command line.
this is basically 'cause dmd doesn't automatically compile and
link imported modules. it you won't specify module in dmd command
line, dmd will only
On Wednesday, 26 October 2016 at 04:51:23 UTC, Jason C. Wells
wrote:
I am reading through Ketmar's iv.d/nanovg/package.d:
module iv.nanovg;
public import iv.nanovg.nanovg;
This looks like three levels of hierarchy, but is it?
it maps to "iv/nanovg/nanovg.d" according to dmd map rules. i
On Saturday, 22 October 2016 at 03:59:16 UTC, Jason C. Wells
wrote:
nanovg_demo>dmd example.d iv\arsd\color.d
iv\arsd\simpledisplay.d iv\perf.d
iv\perf.d(41): Error: module iv.nanovg.nanovg from file
iv\nanovg.d must be
imported with 'import iv.nanovg.nanovg;'
demo.d(6): Error:
On Wednesday, 19 October 2016 at 03:27:10 UTC, Basile B. wrote:
https://github.com/Pctg-x8/nanovg-d, I even think it's been
announced here last year.
this is wrapper. my thing is complete port.
On Tuesday, 18 October 2016 at 21:00:12 UTC, Karabuta wrote:
This thing really needs a GitHub repo
never.
On Monday, 17 October 2016 at 07:05:24 UTC, ketmar wrote:
On Monday, 17 October 2016 at 02:07:47 UTC, rikki cattermole
wrote:
You're going to need to find an svg rasterizer in some form or
another.
I don't think we have one in D and certainly not a complete
one.
'cmon, you know that i have a
On Monday, 17 October 2016 at 02:07:47 UTC, rikki cattermole
wrote:
You're going to need to find an svg rasterizer in some form or
another.
I don't think we have one in D and certainly not a complete one.
'cmon, you know that i have a working port of NanoSVG! and it
works on top of NanoVG,
On Saturday, 15 October 2016 at 07:55:30 UTC, ketmar wrote:
p.s. compiler doesn't complain each time, only in some
circumstances. i don't remember the exact code now, but some of
it has nothing to do with closures at all -- no std.algo, no
templates with lambda args, etc.
On Saturday, 15 October 2016 at 05:41:05 UTC, Walter Bright wrote:
The problem is the closure is generated when it is expected
that the delegate will survive past the end of the scope (it's
the whole point of a closure). But with a destructor that runs
at the end of the scope, it cannot
On Saturday, 15 October 2016 at 07:39:31 UTC, ketmar wrote:
p.s. this is all about GNU/Linux on x86 arch. for other OS/arch
it may be completely different.
On Friday, 14 October 2016 at 15:13:58 UTC, Jonathan M Davis
wrote:
On Thursday, October 13, 2016 19:07:44 Nordlöw via
Digitalmars-d-learn wrote:
Is there a large speed difference in compilation time
depending on whether the DMD used is built using DMD or LDC?
I would be shocked if there
On Thursday, 13 October 2016 at 20:52:09 UTC, Patric Dexheimer
wrote:
So for now my idea is to brute force the numbers of arguments
with 'compiles' trait or trying to get the sourcecode somehow.
depending on source code form (even if you can get it) is highly
error-prone. consider it UB.
On Thursday, 13 October 2016 at 20:22:51 UTC, Peter Campbell
wrote:
OK that's cool, I'll just avoid GDC for now. Is it generally a
good approach to assume if something compiles in DMD then it's
correct and just hope that GDC/LDC pick up the latest version
at some point?
mostly yes. btw, ldc
sadly, gdc has way older frontend version than ldc (and dmd, of
course). gdc is like 2.067, and ldc/dmd is 2.072. that this was
fixed in later versions, but gdc is not updated yet.
On Monday, 26 September 2016 at 09:43:02 UTC, Nemanja Boric wrote:
On Sunday, 25 September 2016 at 16:07:12 UTC, Matthias Klumpp
wrote:
At time, I work around this bug by calling close() manually at
the appropriate time, but this feel like a rather poor
solution.
Cheers,
Matthias
use rc scheme (a-la std.stdio.File is using), so dtor will be
called deterministically, not by GC. here is the sample of that,
which creates lockfile. you can use RC implementation like that
for many other things. it is mostly as cheap as class: the main
struct is only size_t aka pointer (like
p.s. that is the reason it is not turned on by default, btw.
On Thursday, 22 September 2016 at 19:51:31 UTC, Nordlöw wrote:
A known bug?
prolly. segfault handler is highly non-standard hack, it may miss
exact position or something. as is "it is not guaranteed to work,
and if it will work, it is not guaranteed to work correctly".
On Wednesday, 21 September 2016 at 23:36:08 UTC, Nordlöw wrote:
Is there a way to get a stacktrace instead?
{ import etc.linux.memoryerror; registerMemoryErrorHandler(); }
warning: this is hightly system-specific, and may work or not
work depending of the moon phase, and may broke on any
https://issues.dlang.org/show_bug.cgi?id=11595
https://issues.dlang.org/show_bug.cgi?id=16044
On Wednesday, 7 September 2016 at 11:33:08 UTC, Russel Winder
wrote:
C++, error messages
sorry, i loled hard.
On Wednesday, 7 September 2016 at 08:30:51 UTC, Russel Winder
wrote:
On Tue, 2016-09-06 at 14:53 +, ketmar via
Digitalmars-d-learn wrote:
[…]
exactly. static arrays doesn't have `popFront`, hence
`isInputRange` fails. yet there is no way to tell that to
user, so one should just learn
On Tuesday, 6 September 2016 at 14:50:17 UTC, Lodovico Giaretta
wrote:
From a quick look, it looks like `results` is a
`const(TickDuration[3])`, that is a fixed-length array. And
fixed-length arrays aren't ranges. If you explicitly slice
them, they become dynamic arrays, which are ranges.
So
On Friday, 12 August 2016 at 03:41:54 UTC, bachmeier wrote:
On Friday, 12 August 2016 at 03:31:37 UTC, ketmar wrote:
On Friday, 12 August 2016 at 03:20:59 UTC, grampus wrote:
Didn't realise the D community is such active.
yes, we are. while we may be not very huge in number, we are
very
On Friday, 12 August 2016 at 03:20:59 UTC, grampus wrote:
Didn't realise the D community is such active.
yes, we are. while we may be not very huge in number, we are very
passionate about our language of choice. ;-)
On Friday, 12 August 2016 at 01:36:34 UTC, grampus wrote:
I can use dlang in this existing project as long as nothing can
be changed on the C side.
then you have to check if runtime is initialized at the start of
each function that can be called from C side. like this:
private void
On Friday, 12 August 2016 at 00:57:42 UTC, grampus wrote:
it's 'cause you didn't initialized druntime. you have to use
dlsym to get "rt_init" function and call it right after loading
your .so, but before calling any other API from it.
also, note that druntime is using SIGUSR1 and SIGUSR2 for
On Thursday, 11 August 2016 at 20:27:51 UTC, Michael Coulombe
wrote:
here is something for you to play with:
import std.stdio;
enum CallAllowed0;
enum CallAllowed1;
struct S {
@CallAllowed0 void foo () { writeln("foo()"); }
@CallAllowed1 void foo (int n) { writeln("foo(", n, ")"); }
}
On Thursday, 11 August 2016 at 20:41:33 UTC, ketmar wrote:
ah, my bad, i missed UDA part of the question. sorry. ;-)
On Thursday, 11 August 2016 at 20:27:51 UTC, Michael Coulombe
wrote:
import std.stdio;
struct S {
void foo () { writeln("foo()"); }
void foo (int n) { writeln("foo(", n, ")"); }
}
auto doit(string methodName, C, Args...) (C c, Args args) {
static if
http://dpldocs.info/experimental-docs/std.net.curl.HTTP.setPostData.html
https://dlang.org/phobos/std_net_curl.html#.HTTP.setPostData
reading documentation rox!
On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote:
Should range members front() and back() assert() or throw() on
emptyness?
If it should assert() doesn't that lead to unsafer code in
release mode?
What's the consensus here?
if you can and it is not costly, do `assert(false,
On Thursday, 4 August 2016 at 13:14:34 UTC, llaine wrote:
I saw that your compiling using dmd with all thoses options.
Can you explain me what is the benefit of using this ?
very simple: avoiding dub. Adam is not using it.
On Tuesday, 2 August 2016 at 15:18:31 UTC, Steven Schveighoffer
wrote:
What's wrong with assert(0) that you need to have a wrapper
function for it?
while this is a legitimate question, the comipler's inability to
infer "noreturn" still drives me mad. but if compiler will
suddenly be able to
On Sunday, 31 July 2016 at 08:00:02 UTC, cc wrote:
socket sets usually updated after call to `select()`. you have to
recreate the sets before each call.
On Sunday, 31 July 2016 at 04:32:10 UTC, bachmeier wrote:
I wasn't directing my comment at you specifically. I was
talking about the direction the thread took,
what do you prefer: to have a completely false information, or
corrected information for the price of one or two troll-like
posts? i
On Saturday, 30 July 2016 at 12:18:08 UTC, LaTeigne wrote:
it you think that you know the things better than somebody who
actually *lived* there in those times... well, keep thinking
that. also, don't forget to teach physics to physicians, medicine
to medics, and so on. i'm pretty sure that
On Saturday, 30 July 2016 at 11:31:26 UTC, LaTeigne wrote:
For example in the 2000's Delphi was incredibly popular in
Russia because the holder at this time (so Borland unless it
was already Code Gear) sold literally **hundreds** of licenses
to the russian education department.
actually, no.
On Thursday, 28 July 2016 at 11:41:49 UTC, burjui wrote:
Why do you use D then?
it is fun.
Oh, D is more convenient and robust?
no, it is more fun.
"Refactoring" is more convenient and robust than sed -i
's/.../.../g'.
ues, using specialised tools to do useless work can be counted as
On Wednesday, 27 July 2016 at 10:39:52 UTC, NX wrote:
Lack of production quality tools
like? no, "refactoring" and other crap is not "production quality
tools", they are only useful to pretend that you are doing
something useful, so you will look busy for your boss.
On Tuesday, 26 July 2016 at 16:35:26 UTC, Charles Hixson wrote:
That's sort of what I have in mind, but I want to do what in
Fortran would be (would have been?) called record I/O, except
that I want a file header that specifies a few things like
magic number, records allocated, head of free
On Tuesday, 26 July 2016 at 04:05:22 UTC, Charles Hixson wrote:
Yes, but I really despise the syntax they came up with. It's
probably good if most of your I/O is ranges, but mine hasn't
yet ever been. (Combining ranges with random I/O?)
that's why i wrote iv.stream, and then iv.vfs, with
On Tuesday, 26 July 2016 at 01:19:49 UTC, Charles Hixson wrote:
then I will prefer the core.stdc.stdio approach. I find it's
appearance extremely much cleaner...
only if you are really used to write C code. when you see
pointer, or explicit type size argument in D, it is a sign of C
On Monday, 25 July 2016 at 18:54:27 UTC, Charles Hixson wrote:
Are there reasons why one would use rawRead and rawWrite rather
than fread and fwrite when doiing binary random io? What are
the advantages?
In particular, if one is reading and writing structs rather
than arrays or ranges, are
static if (is(typeof(r is null))) { ...you can do your assert
here... }
yep, cast it. without the cast, compiler assuming that it knows
the type in runtime, and is using well-known classinfo address
instead of really looking into instance for that.
On Saturday, 23 July 2016 at 23:36:40 UTC, Etranger wrote:
is there any good benchmarking lib like the #[bench] in rust
that I can use ?)
dunno, i'm usually just using std.datetime.benchmark.
2OP: sorry, i can barely read that code. this has nothing to do
with your skills, it is the topic -- i've never seen clean lazy
evaluation code. after all, this is a hack.
still, i think that such a library worth at least some work.
as for "is my code/approach is good enough", i know only two
On Saturday, 23 July 2016 at 12:27:39 UTC, rikki cattermole wrote:
Either way I recommend you not worry about it. Compilers can be
smart and dmd is mostly good enough in this department.
he has something to worry about. remember, this is scientific
department, where ours 4x4 matrices are
On Wednesday, 20 July 2016 at 17:31:18 UTC, Ali Çehreli wrote:
I think both not being random access ranges and there is
auto-decoding in Phobos are design decisions due to the fact
that char[] is a multi-byte encoding.
Phobos could choose not to auto-decode but char[] would still
be
On Wednesday, 20 July 2016 at 13:33:34 UTC, Mike Parker wrote:
There is no auto-decoding going on here,
...
as char[] and wchar[] are rejected outright since they are not
considered random access ranges.
...due to autodecoding.
On Tuesday, 19 July 2016 at 15:18:20 UTC, Steven Schveighoffer
wrote:
Please add what you can to the report.
ok, i found why it doesn't work with static libs. not sure what
to do next, though... added the info to bugzilla.
On Tuesday, 19 July 2016 at 15:18:20 UTC, Steven Schveighoffer
wrote:
It's affecting phobos devs too, we are aware of the issue:
https://issues.dlang.org/show_bug.cgi?id=16291
i see, thank you. my searching foo failed to find that issue.
i guess i have to use digger to find the commit that
i'm using git master (updated daily), and recently found very
strange thing.
when i'm linking my programs with libphobos2.a, module ctor from
"std.internal.phobosinit" is not called, but when i'm linking
with .so, everything is ok.
it is easy to check: `EncodingScheme.create("utf-8")` will
short answer: no.
there is still no way to write a reliable enumerator like this:
too much things to hack around.
as for module symbols, it is easy: they has no type. literally:
`!is(typeof(...))`.
`is(typeof(...))` is a necessary safeguard anyway if you are
enumerating symbols in module,
On Sunday, 17 July 2016 at 02:04:50 UTC, Adam D. Ruppe wrote:
(x) => x; // defines a new variable
foreach isn't alone.
compiler should allow `auto` here too.
On Saturday, 16 July 2016 at 21:39:42 UTC, cym13 wrote:
However auto should be allowed here. You are defining a
variable and the fact that it's in a foreach shouldn't be of
any importance. The language should enforce orthogonality of
orthogonal things, not break it. A variable definition in a
On Saturday, 16 July 2016 at 14:00:56 UTC, dom wrote:
.. but why?
because. i've lost that fight too.
On Wednesday, 13 July 2016 at 11:59:18 UTC, Miguel L wrote:
The options would be:
a=[];
a.length=0;
a=null;
...
any other?
it really depends of your other code. if you don't have any
slices of the array, for example, you can use `a.length = 0;
a.assumeSafeAppend;` -- this will reuse the
On Wednesday, 13 July 2016 at 11:11:51 UTC, celavek wrote:
I misunderstood the doc and I got a bit confused by the range -
in C++ I would have incremented the iterators but here I did
not know what to do exactly as I could not match the 2
different concepts in functionality.
it mostly maps
On Wednesday, 13 July 2016 at 11:13:00 UTC, Mike Parker wrote:
To be fair, I think it's only obvious to someone who has
achieved a certain level of comfort and familiarity with ranges
and the range-based functions in Phobos. This particular
function could just as easily be inferred to return
On Wednesday, 13 July 2016 at 11:06:56 UTC, celavek wrote:
On Wednesday, 13 July 2016 at 10:41:44 UTC, ketmar wrote:
I understand your point but it should not be a matter of
guessing.
It should be explicitly stated by the documentation.
then people will start to complain that documentation
On Wednesday, 13 July 2016 at 09:59:30 UTC, celavek wrote:
That goes into an infinite loop.
sure. let's read the docs: "Returns a tuple with the reduced
ranges that start with the two mismatched values." so, if it will
find mismatch, it will loop forever then, as you forgot to pop
one of
On Tuesday, 12 July 2016 at 13:56:49 UTC, cym13 wrote:
I'm with Steven here, that's definitely too surprising,
initialization should not be linked to clear in any way.
feel free to change/improve it. for me it is logical, but i'm
often found that i am the only one who agrees with my logic.
On Tuesday, 12 July 2016 at 12:34:40 UTC, Steven Schveighoffer
wrote:
There was a suggestion to make .clear (a relatively new
feature) actually preallocate if it's currently null, but I
didn't want to do allocating in that method (too surprising). I
do think it would be nice to have an
On Tuesday, 12 July 2016 at 11:26:20 UTC, jj75607 wrote:
you can't. there is no AST macros in D, so you can't rewrite
parsed source.
On Tuesday, 12 July 2016 at 03:38:44 UTC, Bahman Movaqar wrote:
Now I understand.
This is tricky --could introduce hard to find bugs. Is there
anyway to
make sure it doesn't happen? Such as giving the AA a default
empty
value on the declaration line --like `string[int] a = []`?
no. the
p.s. i mean simple D dynamic arrays, like `MyType[] arr;`, not
std.array.array. ;-)
list slices are not random-access ranges, thus they can't be
sorted in-place (this is what std.algorithm.sort does). so the
only way is to convert list to array, sort it, and make a list
from sorted array. probably not something you want. ;-)
this is common for any "traditional" linked list
On Monday, 11 July 2016 at 09:31:49 UTC, Ali Çehreli wrote:
What makes you expect that format should have that feature? :)
the fact that format can insert spaces. it is like: "ok, it can
do spaces. i bet there should be some way to use any character
instead of space. after all, the
On Saturday, 9 July 2016 at 11:57:36 UTC, rikki cattermole wrote:
In this case, its not aut odecoding.
ElementType is using std.range : front for array's since they
do not provide a front method.
That implementation is weird in that it returns a dchar
hello, autodecoding.
On Saturday, 9 July 2016 at 11:24:01 UTC, Tofu Ninja wrote:
Seems pretty silly to me...
due to universally beloved autodecoding.
auto opOpAssign(string op)(ptrdiff_t i) if(op =="+" || op == "-")
On Wednesday, 6 July 2016 at 10:25:44 UTC, zodd wrote:
Thank you for a great example! D's power still surprises me a
lot.
just be careful to not carry wrapper around for too long, so it
won't outlive it's parent.
p.s. or this (abomination, i know!). ripped out of one of my
monkeycoding
On Wednesday, 6 July 2016 at 05:51:04 UTC, Ola Fosheim Grøstad
wrote:
Maybe you could give me an useful example in D that does not
involve «static if» or «string mixins» that would be difficult
to represent in C++?
anything involving templates. c++ template syntax is awful.
On Wednesday, 6 July 2016 at 02:19:47 UTC, Craig Dillabaugh wrote:
Why doesn't my function allow me to insert elements into an
empty associative array, but succeeds for an AA with some
element in it?
this is true for any dynamic array, including AAs. until
something is added to array, it
On Tuesday, 5 July 2016 at 21:58:39 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 5 July 2016 at 21:46:19 UTC, ketmar wrote:
C++ templates vs D templates. this alone is enough.
They are almost the same...
yep. just like C is *almost* the assembler.
On Tuesday, 5 July 2016 at 17:50:46 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 5 July 2016 at 16:20:52 UTC, ketmar wrote:
so, my PoV is: yes, D has it's warts, but they are much more
tolerable than C++ warts, for example. and D has alot to offer
which C++ simply won't be able to offer, ever.
On Tuesday, 5 July 2016 at 16:11:58 UTC, zabruk70 wrote:
On Tuesday, 5 July 2016 at 10:52:10 UTC, zodd wrote:
Property functions are used wrong by a compiler when it needs
i am sorry for my dumbness, what wrong with this code?
as OP said, this one won't call setter on "+=" and company.
On Tuesday, 5 July 2016 at 14:07:25 UTC, zodd wrote:
http://forum.dlang.org/post/mailman.1463.1361561853.22503.digitalmars-d-le...@puremagic.com
: "Don't use 'in', because it doesn't mean what it seems to mean, and it's not
correctly implemented at the moment."
it is freakin' 2013! ;-)
On Tuesday, 5 July 2016 at 13:14:29 UTC, zodd wrote:
Why do you have so pessimistic opinion?
it is realistic.
Is D a perspective language to learn or it's stagnating and
never be production ready?
what do you want here: "non-stagnating" or "production ready"? D
is "production ready", and
On Tuesday, 5 July 2016 at 10:52:10 UTC, zodd wrote:
It's a very inconvenient. Why don't just call a getter and then
a setter functions in such cases?
'cause property specs aren't even finalized yet.
Is there a chance, that this weird behavior will be fixed in
the near future? What can I do
On Tuesday, 5 July 2016 at 10:04:05 UTC, Claude wrote:
So here's my question: Is it normal???
yes. `ubyte` arrays by definition cannot hold pointers, so GC
doesn't bother to scan 'em.
On Monday, 4 July 2016 at 20:54:53 UTC, Luke Picardo wrote:
if (curTime - lastMsgTime).total!"seconds") ...
Both are shared Durations.
also when I try to do
lastMsgTime = curTime;
Gives me
Error: non-shared method std.datetime.SysTime.opAssign is not
callable using a shared object.
cast
On Saturday, 2 July 2016 at 21:17:33 UTC, Namespace wrote:
On Saturday, 2 July 2016 at 21:15:29 UTC, ketmar wrote:
On Saturday, 2 July 2016 at 21:05:18 UTC, Namespace wrote:
Try this little trick:
or don't. such pointers to structs are *dangerous*.
Either that "dangerous" thing or 2^N
On Saturday, 2 July 2016 at 20:40:00 UTC, Adam D. Ruppe wrote:
Using ref is wasteful there regardless just take an
ordinary Point (even const is optional if it is all value but
it doesn't hurt).
I think a lot of C++ programmers overuse references. If you're
passing a large thing, it
On Saturday, 2 July 2016 at 21:05:18 UTC, Namespace wrote:
Try this little trick:
or don't. such pointers to structs are *dangerous*.
On Saturday, 2 July 2016 at 18:47:31 UTC, phant0m wrote:
On Saturday, 2 July 2016 at 18:43:51 UTC, ketmar wrote:
void boo() (in auto ref MyStruct s) { ... }
this will accept both lvalues and rvalues, and will avoid
copying if it can.
Thank you! Could you please explain what does "auto" in
void boo() (in auto ref MyStruct s) { ... }
this will accept both lvalues and rvalues, and will avoid copying
if it can.
also, there is a subtle bug in matcher. sorry. ;-)
On Saturday, 25 June 2016 at 08:46:05 UTC, John wrote:
Anyone able to improve on it?
q hack:
template tyma(T, Cases...) {
import std.traits;
template GetFunc(size_t idx) {
static if (idx >= Cases.length) {
static assert(0, "no delegate for match");
} else static if
On Wednesday, 22 June 2016 at 09:27:01 UTC, cym13 wrote:
what i meant is that "{}" should be fully equivalent to
"Struct()" ctor in terms of calling postblits, and it isn't.
On Wednesday, 22 June 2016 at 09:27:01 UTC, cym13 wrote:
On the other hand I don't see why you'd expect {} to call
postblit at
all.
'cause it essentially makes a copy. i gave the sample in
bugreport. it worth me a hour of debugging to find why my
refcounted struct keep crashing with invalid
On Wednesday, 22 June 2016 at 06:43:12 UTC, Paul wrote:
Why is initialisation via {} bad (in simple terms please :D)?
first, it is buggy. i.e. it doesn't always call postblit[1].
second, it's syntax is the same as the syntax of argument-less
lambda, which makes it context-dependent -- so
On Tuesday, 21 June 2016 at 19:33:31 UTC, cym13 wrote:
i would want him to figure that by himself, tbh. just to remember
that "{}" struct initialization is BAD. ;-)
trackTemplates[0].coords = [ CoordList(0, 9), CoordList(1, 1),
CoordList(3, 6) ];
201 - 300 of 1079 matches
Mail list logo
