On Thursday, 9 November 2023 at 10:14:46 UTC, Bienlein wrote:
On Thursday, 9 November 2023 at 09:40:47 UTC, Bienlein wrote:
On Wednesday, 8 November 2023 at 16:47:02 UTC, Paul Backus
wrote:
On Wednesday, 8 November 2023 at 16:30:49 UTC, Bienlein wrote:
...
The actual problem here is that you
On Thursday, 9 November 2023 at 09:40:47 UTC, Bienlein wrote:
On Wednesday, 8 November 2023 at 16:47:02 UTC, Paul Backus
wrote:
On Wednesday, 8 November 2023 at 16:30:49 UTC, Bienlein wrote:
...
The actual problem here is that you can't take the address of
a template without instantiating
On Wednesday, 8 November 2023 at 16:47:02 UTC, Paul Backus wrote:
On Wednesday, 8 November 2023 at 16:30:49 UTC, Bienlein wrote:
...
The actual problem here is that you can't take the address of a
template without instantiating it first. To make your example
work, replace `` with `!int`, like
Hello,
I get the error "`addToBiz(T)(Biz!T biz)` is not an lvalue and
cannot be modified" when compiling the code below. Can't find a
way how to do it right. Am a D newbie and would appreciate some
help.
Thank you, Bienlein
class Biz(T) {
private T value;
th
On Monday, 3 October 2022 at 10:13:09 UTC, Rene Zwanenburg wrote:
On Monday, 3 October 2022 at 08:10:43 UTC, Bienlein wrote:
My question is whether someone has an idea for a better
solution.
You can pass a lambda to the fiber constructor. For example:
```
void fiberFunc(int i)
{
writeln
();
writeln("foo: ", foo.i);
}
But this solution is a bit clumsy. It's kind of programming with
global variables.
My question is whether someone has an idea for a better solution.
Thank you, Bienlein
why?
Because an empty string is, by default, represented by an empty
slice of the null pointer.
I don't program in D. I just read from time to time posts in the
D forum because of the good quality of what people write. So, I'm
not proficient in D, but in general internals should not boil
On Tuesday, 9 November 2021 at 17:29:37 UTC, Rumbu wrote:
Nim received a nice donation :)
https://nim-lang.org/blog/2021/10/25/nim-receives-100k-usd-bitcoin.html
You never know when it happens.
I hope the put the money into making a better debugger ;-)
This works, vit. Thanks! I thought it wouldn't, because your code
still makes use of embrace. But it somehow worked, although I
don't understand why ... ;-).
I also added a constructor using the same approach as your
destructor and this also worked:
this(int otherNum) @nogc {
On Thursday, 19 August 2021 at 07:30:38 UTC, Bienlein wrote:
Hello,
I allocate some instance of class C manually and then free the
memory again:
class C {
int num;
~this() {
writeln("~this");
}
}
void foo() // @nogc
{
auto
that I can create some generic
function that calls the destructor and then free for any kind of
class?
Thanks, Bienlein
On Wednesday, 27 May 2020 at 11:40:00 UTC, Mike Parker wrote:
On Wednesday, 27 May 2020 at 10:30:36 UTC, wjoe wrote:
On Wednesday, 27 May 2020 at 10:01:33 UTC, Mike Parker wrote:
Could you please elaborate why checked exceptions are more
annoying?
For me, it's because they require all
On Tuesday, 18 February 2020 at 12:43:22 UTC, Adnan wrote:
What is the alternative to C++'s friend functions in D?
module stable_matching;
alias FemaleID = int;
alias MaleID = int;
class Person {
string name;
int id;
}
class Male : Person {
this(string name = "Unnamed Male") {
On Thursday, 10 October 2019 at 16:05:13 UTC, bachmeier wrote:
On Thursday, 10 October 2019 at 08:59:49 UTC, Russel Winder
wrote:
My impressions is that the complaints about Scala are similar
to C++: too many features that clash with one another and make
the language complicated, plus
On Thursday, 10 October 2019 at 10:08:14 UTC, H. S. Teoh wrote:
On Thu, Oct 10, 2019 at 09:59:49AM +0100, Russel Winder via
Digitalmars-d-learn wrote:
On Wed, 2019-10-09 at 11:12 -0700, H. S. Teoh via
Digitalmars-d-learn wrote: […]
> Actually, std.functional is somewhat of a misnomer. It
>
On Wednesday, 23 January 2019 at 12:26:02 UTC, rikki cattermole
wrote:
On 24/01/2019 1:20 AM, JN wrote:
Well, the truth is, people don't come to a language because of
a killer feature. Sometimes it's even the opposite. Java and
Dart are familiar to some extent because of lack of killer
On Wednesday, 23 January 2019 at 15:04:00 UTC, jmh530 wrote:
I would think that dynamic class loading is something that
could be bolted on to C++ (and presumably D as well), albeit
awkwardly.
Dynamic class loading means there is no more link step.
On Wednesday, 23 January 2019 at 14:14:06 UTC, bachmeier wrote:
I've made this comparison many times before, but I'll do it
again...
Look at what Rust offers as documentation for Cargo:
https://doc.rust-lang.org/cargo/index.html
This is what you get with Dub:
https://dub.pm/getting_started
On Wednesday, 23 January 2019 at 12:26:02 UTC, rikki cattermole
wrote:
Java's killer feature is consistent simplicity. That is how it
was originally sold to great success. The ecosystem and tooling
came later.
Also, the Internet was Java's killer application. No other
language had the
On Friday, 18 January 2019 at 08:55:23 UTC, Paulo Pinto wrote:
D really needs its killer use case if it is to move away from
that list.
D is a lot like Scala on the JVM: Both language have myriads of
language features and bells and whistles, but there is no killer
feature in the language
On Saturday, 22 December 2018 at 13:33:29 UTC, Russel Winder
wrote:
Brilliant, DConf comes to the UK, I can get to it…
except…
it's on at the exact same time as DevoxxUK 2019 which is at the
Business Design Centre. :-(
Programming languages are unimportant anyway.
On Friday, 16 November 2018 at 02:18:11 UTC, Ranjan wrote:
On Thursday, 15 November 2018 at 17:03:55 UTC, Andrea Fontana
wrote:
On Thursday, 15 November 2018 at 13:05:59 UTC, Ranjan wrote:
This is my first time on the Dlang forum. I like the language
but my usecase is a bit different.
I want
On Tuesday, 13 November 2018 at 07:10:26 UTC, Jamie wrote:
I would like my class to inherit from one of two classes based
on a boolean value known at compile time. Something like this:
void main()
{
Top!(OPTION.FALSE) top = new Top!(OPTION.FALSE);
}
enum OPTION
{
FALSE = 0.,
TRUE
On Friday, 15 June 2018 at 07:34:07 UTC, biocyberman wrote:
On Friday, 15 June 2018 at 07:20:04 UTC, Bienlein wrote:
On Wednesday, 13 June 2018 at 12:37:26 UTC, bauss wrote:
On Wednesday, 13 June 2018 at 12:12:11 UTC, bauss wrote:
I'll be there since I live there and would be nice to see
On Wednesday, 13 June 2018 at 12:37:26 UTC, bauss wrote:
On Wednesday, 13 June 2018 at 12:12:11 UTC, bauss wrote:
I'll be there since I live there and would be nice to see
monthly meetups! :)
I forgot to ask. Is it free entry? :)
Yeah, and the Aalborg Akvavit is also free ? ;-)
On Wednesday, 4 April 2018 at 05:31:10 UTC, Andrei Alexandrescu
wrote:
Hi folks, I was thinking of the following.
To keep the PR queue trim and in good shape, we'd need at least
one full-time engineer minding it. I've done that occasionally,
and the queue size got shorter, but I couldn't do
On Thursday, 29 March 2018 at 16:10:55 UTC, Johannes Loher wrote:
I have to say, my experience was totally different. I recently
had quite many job interviews for jobs in which I would mainly
be using Java/C#. Because I like D very much, obviously the
topic came up in every single interview.
On Monday, 26 March 2018 at 17:49:18 UTC, bauss wrote:
On Monday, 26 March 2018 at 16:13:17 UTC, Joakim wrote:
On Monday, 26 March 2018 at 15:52:11 UTC, Jean-Louis Leroy
wrote:
...as a "programming languages you should learn now" - albeit
somewhat dismissively ;-)
On Monday, 26 February 2018 at 19:36:33 UTC, Simen Kjærås wrote:
On Monday, 26 February 2018 at 15:43:54 UTC, Bienlein wrote:
object Scratch extends App {
// compiles:
val list = List(1, 2.4, 5)
val sum = list.sum
println(sum)
// does not compile:
val list2 = List(1, 2.4, 5
On Monday, 26 February 2018 at 16:53:39 UTC, drug wrote:
you can do something like this (https://run.dlang.io/is/RYR5Dm):
```
import std.algorithm : sum;
import std.range : only;
import std.stdio : writeln;
import std.typecons : tuple;
void main()
{
{
auto list = tuple(1, 2.4, 5);
drawbacks (compilation times, colliding implicit conversions the
compiler cannot detect, etc.). So I just wanted to see whether D
does this in a clean way and I know that D allows for some type
parameter constraints to be set.
Thansk for any answers,
Bienlein
On Thursday, 21 December 2017 at 18:45:27 UTC, Adam D. Ruppe
wrote:
On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote:
When the scoped destruction of structs isn't an option,
RefCounted!T seems to be a less evil alternative than an
unreliable class dtor. :-/
Alas, RefCounted
On Wednesday, 13 September 2017 at 07:51:19 UTC, John Burton
wrote:
Is there any threadsafe queue in the standard library?
I've not been able to find anything but thought I'd check
before making my own.
I want to be able to assemble messages (Which are just streams
of bytes) in one thread
On Sunday, 30 July 2017 at 13:35:18 UTC, Poyeyo wrote:
Reading this article:
http://www.evanmiller.org/why-im-learning-perl-6.html
makes me curious about the state of Dlang's M:N thread
multiplexing.
Quoting the article:
"if you want M:N thread multiplexing your options today are
precisely
When looking at other language ranking sites, D always scores
better then Rust. Yet, Rust gets included in the ranking but D
is ... nowhere to be seen.
Well, on the Tiobe index D is currently on place 23 way ahead of
Lua, Scala, Rust, Kotlin, Groovy. So there is obviously
asomething wrong
On Friday, 23 June 2017 at 14:07:09 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 23 June 2017 at 11:15:40 UTC, Bienlein wrote:
I have not done any manual memory management at work for the
last 25 years.
But are you doing any programming for the low end of the
hardware spectrum? It has been
On Friday, 23 June 2017 at 08:57:04 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:
Java, Kotlin, C# are still Jit compiled languages, with the
memory footprint to prove it :)
The memory footprint doesn't matter. Those times are OVER :-).
People said
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:
Java, Kotlin, C# are still Jit compiled languages, with the
memory footprint to prove it :)
The memory footprint doesn't matter. Those times are OVER :-).
Here are some references:
http://benchmarksgame.alioth.debian.org/u64q/go.html
Java, Kotlin, C# are still Jit compiled languages, with the
memory footprint to prove it :)
The memory footprint doesn't matter. Those times are OVER :-).
I suspect though that like Go took Python more than C folk,
Kotlin Native will take more Java that C++, Go and Rust folks.
But speculation rarely turn out quite as speculated.
In Java development there is almost no C or C++ and no Rust or D
at all. Memory is no problem. Some server needs 256
On Monday, 19 June 2017 at 13:24:00 UTC, Russel Winder wrote:
Go gets parallel compilation, at last, and better garbage
collection. The former is not a problem for D, but the latter…
Right, D2 has a problem with the GC. It cannot be put to
reasonable speed, because of initial design
Let's not forget Kotlin and Swift, things we'd really be
competing against - that is the other NEW stuff.
Kotlin/Native is now in the making and there is already a preview:
https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-preview-kotlin-without-a-vm/
On Friday, 21 April 2017 at 17:20:14 UTC, Vasudev Ram wrote:
Hi list,
I hope the question is self-evident from the message subject.
If not, it means: what are D developers generally called (to
indicate that they develop in D)? The question occurred to me
somehow while browsing some D posts
On Sunday, 16 October 2016 at 13:58:51 UTC, Andrei Alexandrescu
wrote:
I was thinking it would be handy if tuples had a way to access
a field by name at runtime. E.g.:
Tuple!(int, "a", double, "b") t;
string x = condition ? "a" : "b";
In Scala you can do this:
def getUserInfo = ("Al", 42,
On Thursday, 1 September 2016 at 18:45:14 UTC, deadalnix wrote:
On Wednesday, 31 August 2016 at 18:50:58 UTC, simendsjo wrote:
An article about how outsourcing reduces the need for
Norwegian developers. No links to D other than the image on
top though. I wonder what they searched for to find
On Tuesday, 30 August 2016 at 18:36:19 UTC, CRAIG DILLABAUGH
wrote:
I am going to vote with Adam here. If memory serves me
correctly what initially drew me in to the D language was a
statement on the main page that "D is not a religion". I think
at the time I had been doing some work with
On Wednesday, 31 August 2016 at 18:50:58 UTC, simendsjo wrote:
An article about how outsourcing reduces the need for Norwegian
developers. No links to D other than the image on top though. I
wonder what they searched for to find this image.
parameter and things
are fine.
-- Bienlein
problem with this approach. Anything I need to be aware of? I'm
not proficient with D. So I thought it's better to ask ;-).
Regards, Bienlein
RefCounted does not work for classes, only for structs. Reason
against adoption at least for me ;-).
On Tuesday, 3 May 2016 at 19:54:06 UTC, tsbockman wrote:
On Friday, 29 April 2016 at 10:06:06 UTC, Bienlein wrote:
All right, thanks for the hint. Is there a timeline till when
this DIP will be implemented?
No; that particular solution might never be implemented at all.
Getting safe
On Tuesday, 26 April 2016 at 12:34:49 UTC, cym13 wrote:
On Tuesday, 26 April 2016 at 12:19:40 UTC, Bienlein wrote:
Hi deadalnix,
thanks for taking the time to answer my questions. The issue
with RefCounted and classes appears to be fixed. I found this:
http://wiki.dlang.org/DIP74. I also
are very well equipped
for this.
Cheers, Bienlein
is
what the current status is concerning this topic.
* RefCounted only used to work with structs. It would be useful
if it worked with classes as well. Is it being considered to work
on this?
Thanks for any answers.
Regards, Bienlein
confused and don't see that without the possibility of
overwriting an inherited method delegation applies and not
inheritance. This is also explained in this blog:
http://objectscape.blogspot.de/search/label/Go See the section
titled Inheritance.
-- Bienlein
You are making a cool project and we'd like to contribute to it,
but we don't know and neither feel like studying this silly D.
This is indeed a problem for many newly created languages. Scala
has somewhat managed to create its own eco system with Akka,
Spark, Spray in a specialized area like
Java programmers are having to come to terms with this. Python
programmers sort of have, except that BDFL has failed to accept
the correct end point and still likes loops. Scala has done it
all wrong. (Further opinions available on request :-)
Could you provide some sample Scala code to
I was recently told by a commercial D user, that using D helps
them to more easily identify good programmers.
It would be nice, if not just D users had this attitude :-)
It's also a bit like that for Scala when companies look for Java
people. Alas, Scala is a bit overloaded ...
are coming.
i'm writing a very long blog post about this. if anyone's
interested, i can happily share the draft with them.
Please drop a comment in this thread or somewhere when it is
published.
Cheers, Bienlein
What about using a JVM with green threads support or Quasar,
wouldn't it be more comparable?
--
Paulo
Long text, contents of common interest in the last section :-)
Thanks for the hints, Paulo. Quasar looks interesting. The
current number one actor implementation for the JVM is Akka
A priori I do not believe the claim made here: a GPars task is
submitted
to a thread pool, which is exactly what the goroutines are.
Thus the
number of Java threads is not a bound on the number of GPars
tasks. Any
bounds will be provided by the Fork/Join pool.
Here is a GPars sample from
the fibonacci calculation in Groovy/GPars yields the processor,
using GPars the first 2.000 fibonacci calculations will
nevertheless crowd out the following 2.000 threads of all those
80.000 fibonacci calculations and so on. I once tried this out
with both Go and Groovy/GPars.
-- Bienlein
of time. I don't want
to appear harsh. It only seems to me that I wasn't able to bring
my point across.
Cheers, Bienlein
People have already suggested you to actually try vibe.d at
least once before repeating CSP is necessary for easy async
mantra.
I was trying to point out in some previous thread that the value
of CSP is that concurrent things from the code looks like
sync calls (not async, but sync). The
this wagon and add
channels and green threads to D. When people successfully develop
many server side systems this way as with Go the news will spread
by itself. No killer app for D needed. Also Go does not have one.
-- Bienlein
On Saturday, 20 December 2014 at 12:24:29 UTC, Paulo Pinto wrote:
On Saturday, 20 December 2014 at 12:19:34 UTC, Bienlein wrote:
I would say that D needs a usecase that puts it aside from
other languages. For Java this was the Internet. For Go it was
channel-based concurrency in conjunction
On Saturday, 20 December 2014 at 12:21:49 UTC, Dicebot wrote:
CSP is not superior to message passing for concurrent server
programming and D already beats Go in this domain, it is purely
marketing crap. Stop repeating same statement over and over
again with no technical data to back it up. Or
On Saturday, 20 December 2014 at 12:50:02 UTC, Dicebot wrote:
People have already suggested you to actually try vibe.d at
least once before repeating CSP is necessary for easy async
mantra. How about actually doing so? vibe.d + std.concurrency
gives you pretty much standard actor model - it
On Saturday, 20 December 2014 at 14:06:51 UTC, Paulo Pinto wrote:
That is why I seldom buy into hype driven development.
Okay, so Docker is hype? Have you seen the impact of it? Every
Java magazine has articles about Docker. And that is not because
Java people had an interest in it, because
to point people to this interesting article. So I thought I
have to do it.
Regards, Bienlein
On Tuesday, 26 August 2014 at 06:01:25 UTC, uri wrote:
RefCounted does not work with classes. Classes are reference
types already.
Yep, that's the problem. I also got some suspicion, then surfed
the Internet and found the information about it. Thanks for
explaining the error message to me.
Hello,
does anyone know of a List/Set/Map implementation that does not
rely on the GC? The would be the last thing I need for D to be
really happy with it ;-)
Thanks, Bienlein
Thanks for the replies. This looks good. I meanwhile found
http://dsource.org/projects/dcollections But it seems to be
GC-based just like Tango ... ;-(.
, RefCountedAutoInitialize autoInit =
RefCountedAutoInitialize.yes) if (!is(T ==
class)) C:\Users\Nutzer\Windows Ordner\Documents\Visual Studio
2013\Projects\RefCountedScratch\RefCountedScratch\main.d 26
I tried many things, but nothing did it. Any help appreciated :-).
Thanks, Bienlein
import std.stdio;
import
the instance was
deallocated before calling nogcDel. Something with the
deallocation in nogcDel seems not to work. Some hint appreciated
on this. When calling delete t the protection violation happens
on the next line as expected.
Thanks a lot, Bienlein
On Sunday, 24 August 2014 at 08:48:03 UTC, bearophile wrote:
Perhaps there are ways, but note that @nogc is meant mostly for
stack-allocation.
Ah, I missed that. Thanks for telling me. I changed nogcDel now
to null out the deallocated object:
void nogcDel(T)(ref T obj)
{
import
I think Walter is exactly right with the first 7 points he is
listing in his starting post of this thread. Nullable types are
nice, but don't get too much distracted by them. The first 7
points are far more important. Go takes absolutely no effort to
get rid of nil and they are very successful
Very nice piece of work. Thank you! The PDF version seems not to
have a table of contents. Would be really helpful if it had :-).
The JVM JIT was originally targeted to SELF, not Java.
Yes, that's right. The guys that developed Self (David Ungar et
al.) then set out to develop a high-performance typed Smalltalk
using the optimization techniques they developed for Self. The
Smalltalk system never hit the market as the
There is also a Semaphore and Barrier class:
http://dlang.org/phobos/core_sync_barrier.html
http://dlang.org/phobos/core_sync_semaphore.html
On Monday, 23 June 2014 at 01:16:49 UTC, Evan Davis wrote:
As the subject says, I would like to pass around an array of
functions. The trick is, that the functions have different type
signatures. Is there a way to put the two functions
int foo(int a, int b);
bool bar(bool a, bool b);
into
that the code is your work along with the date
of publication.
-- Bienlein
On Wednesday, 18 June 2014 at 15:57:40 UTC, Etienne wrote:
On 2014-06-18 11:55 AM, bearophile wrote:
Etienne:
writeln(obj.member?.nested?.val);
What about an approach like Scala instead?
Bye,
bearophile
You mean like this?
What data load profile do you expect? Vibe is tuned to handle
thousands simultaneous incoming light requests (milliseconds),
while distributed computing works better with exclusive heavy
requests, at least minutes of work worth, BOINC uses hours
worth work items.
Communication will be
a Smalltalk/Java developer (only played with C++
when studying) I have to stick to what is easier to use. It would
be a fun leisure learning project anyway...
Regards, Bienlein
Hello,
I'm looking for a way to do some kind of RPC in D. Some way of
being able to say aFoo.bar(int i, ...) with receiver object and
method being marshalled at the sender's site and being
unmarshalled and invoked at the receiver's site. Any hints
appreciated.
Thanks, Bienlein
On Wednesday, 7 May 2014 at 15:54:42 UTC, Paulo Pinto wrote:
So the videos of the Gophercon 2014 are being made available.
Rob Pike did the keynote. At the expected question about
generics,
his answer was There are no plans for generics. I said we're
going to leave the language; we're done..
Well, he had previously stated that there would be no breaking
changes, and that if there were changes it would have to be
called go version 2 or something. So when generics were
brought up he stated that there were no plans for generics and
I said we are going to leave the language, we are
..
Discussion ongoing on HN,
https://news.ycombinator.com/item?id=7708904
--
Paulo
I agree with Paulo. At 54:40 he says what Paulo has already
quoted. And we are done means that's it, folks. It even
sounds to me like the language is finished and it will be left
like that.
-- Bienlein
is this:
void spawnedFunc(Tid tid)
{
receive(
(int i) { writeln(Received the number , i);}
);
}
auto tid = spawn(spawnedFunc, thisTid);
Thanks, Bienlein
On Wednesday, 7 May 2014 at 17:13:07 UTC, Sönke Ludwig wrote:
The Tid handling is currently a little different, but apart
from that it
should work like this:
import vibe.core.core;
import vibe.core.concurrency;
void spawnedFunc(Tid tid)
{
receive(
(int i) {
On Friday, 25 April 2014 at 19:51:22 UTC, Adam Wilson wrote:
I know we don't place much value in TIOBE and it's brethren.
However, I thought that this was a milestone worthy of a note
anyways.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
I don't want to take your joy,
One key difference is that coroutines won't make your programs
run faster. It is a modelling mechanism that can simplify your
programs where you otherwise would have to implement a state
machine.
This is also my impression when I look at this code (see
can
also offer dead-simple concurrency and be appealing to
developing cloud solutions or other style of server-side
applications for which easy concurrency is a big plus.
-- Bienlein
I use vibe.d for a small server side application. It's quite
fast, although we haven't tested it on a larger scale yet. On
the downside, vibe.d's API is not quite intuitive, so it takes
a while to get used to it. But that might be down to the fact
that it's not easy to write an intuitive API
the FiberScheduler by Sean Kelly could achieve something in that
direction. That would make a big difference for using D for
server-side applications beyond the argument of being more
productive than C++.
-- Bienlein
On Wednesday, 16 April 2014 at 13:42:26 UTC, Chris wrote:
Maybe we should spawn a new thread for this discussion. I'm
sure this is of interest for everyone on this forum.
All right, here we go:
by Sean Kelly could achieve something in that
direction. What do you think?
Regards, Bienlein
On Wednesday, 16 April 2014 at 14:06:13 UTC, Sönke Ludwig wrote:
I agree, but I also wonder why you still keep ignoring vibe.d.
It achieves exactly that - right now! Integration with
std.concurrency would be great, but at least for now it has an
API compatible replacement that can be merged
On Wednesday, 16 April 2014 at 14:21:03 UTC, Sönke Ludwig wrote:
I still don't understand what you mean by distributed.
Spawning 50.000 tasks:
import vibe.core.core;
import std.stdio;
void main()
{
foreach (i; 0 .. 50_000)
1 - 100 of 183 matches
Mail list logo
