Can someone check this out? The best I can acertain is that the
mixin template isn't adding the generated functions because it
thinks they are already in the class.
i.e., the code generates the following methods
@property iButton button(iButton b)
@property iBorder border(iBorder b)
and the c
On 3/6/2014 10:12 PM, H. S. Teoh wrote:
From what I understand, structs are *supposed* to be thin value types. I
would say that if a struct is under a certain size (determined by the
compiler), and doesn't have complicated semantics like dtors and stuff
like that, then it should be treated like a
On Friday, 7 March 2014 at 02:15:44 UTC, Nick Sabalausky wrote:
On 3/6/2014 11:48 AM, Steve Teale wrote:
class MyBaseClass {
bool addHandlersCalled = false;
bool delegate(int)[] handlers;
/// Subclasses must call this in their ctor.
protected void addHandlers(bool delegate(i
On Thu, Mar 06, 2014 at 08:19:18PM -0800, Walter Bright wrote:
> On 3/6/2014 8:01 PM, Adam D. Ruppe wrote:
> >BTW you know what would help this? A pragma we can attach to a struct
> >which makes it a very thin value type.
>
> I'd rather fix the compiler's codegen than add a pragma.
[...]
>From wh
On 3/6/2014 7:59 PM, bearophile wrote:
Walter Bright:
I understand this all too well. (Note that we currently have a different
silent problem: unnoticed large performance problems.)
On the other hand your change could introduce Unicode-related bugs in future
code (that the current Phobos avoi
Walter Bright:
I'd rather fix the compiler's codegen than add a pragma.
But a standard common intrinsic to detect the overflow
efficiently could be useful.
Bye,
bearophile
On 3/6/2014 11:11 PM, Nick Sabalausky wrote:
What about this?:
Anywhere we currently have a front() that decodes, such as your example:
@property dchar front(T)(T[] a) @safe pure if (isNarrowString!(T[]))
{
assert(a.length, "Attempting to fetch the front of an empty array
of " ~
On 3/6/2014 8:01 PM, Adam D. Ruppe wrote:
BTW you know what would help this? A pragma we can attach to a struct which
makes it a very thin value type.
I'd rather fix the compiler's codegen than add a pragma.
On 3/6/2014 10:59 PM, Walter Bright wrote:
These are good ideas, but for now we need to just bite the bullet and
fix Phobos.
Agreed.
On Friday, 7 March 2014 at 02:57:38 UTC, Walter Bright wrote:
Yes, so that the user selects it, rather than having it wired
in everywhere and the user has to figure out how to defeat it.
BTW you know what would help this? A pragma we can attach to a
struct which makes it a very thin value type
On 3/6/2014 7:22 PM, bearophile wrote:
One advantage of your change is that this code will work:
auto s = "hello".dup;
s.sort();
Yes, I hadn't thought of that.
The auto-decoding front() introduces all kinds of asymmetry in how ranges work,
and asymmetry is bad as it negatively impacts compos
What about this?:
Anywhere we currently have a front() that decodes, such as your example:
@property dchar front(T)(T[] a) @safe pure if (isNarrowString!(T[]))
{
assert(a.length, "Attempting to fetch the front of an empty array
of " ~
T.stringof);
size_t i = 0;
These are good ideas, but for now we need to just bite the bullet and fix
Phobos.
On 3/6/2014 7:31 PM, H. S. Teoh wrote:
Whoa. You're not serious about changing this now, are you? Because even
though I would support such a change, you have to realize the magnitude
of code breakage that will happen. A lot of code that iterates over
narrow strings will break, and worse yet, they
Walter Bright:
I understand this all too well. (Note that we currently have a
different silent problem: unnoticed large performance problems.)
On the other hand your change could introduce Unicode-related
bugs in future code (that the current Phobos avoids) (and here I
am not talking about c
On Thursday, 6 March 2014 at 17:17:12 UTC, Atila Neves wrote:
Well, I found out the other day that vibe.d compiles with gdc
now so I went back to see if it made any difference to the
benchmarks I had.
In throughput it made none.
In the latency one it was about 5-10% faster with gdc compared
On 3/6/2014 7:06 PM, Walter Bright wrote:
On 3/6/2014 6:37 PM, Walter Bright wrote:
Is there any hope of fixing this?
Is there any way we can provide an upgrade path for this? Silent breakage is
terrible. Any ideas?
Ok, I have a plan. Each step will be separated by at least one version:
1.
On 3/6/2014 8:37 PM, H. S. Teoh wrote:
Unfortunately, input ranges are somewhat tedious to write -- nice
foreach loops have to be broken up into .empty, .front, .popFront, which
is a lot of boilerplate code and not so nice in inner loops (though I
suppose the idea is to improve compiler inlining
On Thu, Mar 06, 2014 at 06:59:36PM -0800, Walter Bright wrote:
> On 3/6/2014 6:54 PM, bearophile wrote:
> >Walter Bright:
> >>Is there any hope of fixing this?
> >
> >I don't think we can change that in D2. You can change it in D3.
>
> You use ranges a lot. Would it break any of your code?
Whoa.
Walter Bright:
But it's good to have in Phobos a compiler-intrinsics-based
efficient overflow
detection on a user-defined struct type that behaves like
built-in ints in all
other aspects.
Yes, so that the user selects it, rather than having it wired
in everywhere and the user has to figure
On Thursday, 6 March 2014 at 13:17:02 UTC, qznc wrote:
On Tuesday, 4 March 2014 at 22:27:37 UTC, Walter Bright wrote:
On 3/4/2014 1:30 PM, Brad Anderson wrote:
Anyway, there's my little rant about Hacker News. I still go
there daily :)
I do, too, but I gave up posting links there.
+1
HN ge
Walter Bright:
You use ranges a lot. Would it break any of your code?
I need to try the changes to be sure. But the magnitude of this
change is so large that I guess some code will surely break.
One advantage of your change is that this code will work:
auto s = "hello".dup;
s.sort();
Bye,
On 3/6/2014 6:37 PM, Walter Bright wrote:
Is there any hope of fixing this?
Is there any way we can provide an upgrade path for this? Silent breakage is
terrible. Any ideas?
On 3/6/2014 6:54 PM, bearophile wrote:
Walter Bright:
systems/native programming languages must not hide the underlying
representation (I make similar arguments about proposals to make ints issue
errors on overflow, etc.).
But it's good to have in Phobos a compiler-intrinsics-based efficient
On 3/6/2014 6:54 PM, bearophile wrote:
Walter Bright:
Is there any hope of fixing this?
I don't think we can change that in D2. You can change it in D3.
You use ranges a lot. Would it break any of your code?
Walter Bright:
systems/native programming languages must not hide the
underlying representation (I make similar arguments about
proposals to make ints issue errors on overflow, etc.).
But it's good to have in Phobos a compiler-intrinsics-based
efficient overflow detection on a user-defined s
In "Lots of low hanging fruit in Phobos" the issue came up about the automatic
encoding and decoding of char ranges.
Throughout D's history, there are regular and repeated proposals to redesign D's
view of char[] to pretend it is not UTF-8, but UTF-32. I.e. so D will
automatically generate cod
On 3/6/2014 11:48 AM, Steve Teale wrote:
I've also noticed from the responses, and from responses to associated
questions, that OOP has become almost a dirty word in the D community.
It's old fashioned and slow. So if you're in that camp, you can stop
reading now.
FWIW, I don't think that's r
On 3/6/2014 5:54 PM, Jakob Ovrum wrote:
While I prefer this approach most of the time, I fear it has a performance cost
over sink-style algorithms (whether they use an output range or build an array
result). I guess the question is whether this cost is generally offset by gains
in the memory allo
H. S. Teoh:
Some kind of built-in coroutine syntax with
'yield' would help things a LOT.
Some persons have quickly shot down this idea that I have
suggested:
https://d.puremagic.com/issues/show_bug.cgi?id=11880
Bye,
bearophile
On 3/6/2014 5:37 PM, H. S. Teoh wrote:
Unfortunately, input ranges are somewhat tedious to write
I know. But we need to make the effort, at least for Phobos. The payoff is it
makes user code much less effort.
On Friday, 7 March 2014 at 01:15:43 UTC, Walter Bright wrote:
On 3/6/2014 4:43 PM, H. S. Teoh wrote:
What about using output ranges?
A great question. I tend to regard output ranges as suitable
for a container to expose. An algorithm reads an InputRange,
and presents its output as another In
On Thu, Mar 06, 2014 at 05:15:45PM -0800, Walter Bright wrote:
> On 3/6/2014 4:43 PM, H. S. Teoh wrote:
> >On Thu, Mar 06, 2014 at 01:26:46PM -0800, Walter Bright wrote:
> >>A major goal for D in the short term is to reduce reliance in Phobos
> >>on the GC. I was looking at std.string last night, a
On 3/6/2014 5:10 PM, Sean Kelly wrote:
However, as much as I like that having the Posix headers strongly
encourages the user to write portable code, I can see the idea
doesn't have a lot of traction around here. I beleive Iain's
proposal is to phase them out and do exactly what you suggest,
Th
On 3/6/2014 4:43 PM, H. S. Teoh wrote:
On Thu, Mar 06, 2014 at 01:26:46PM -0800, Walter Bright wrote:
A major goal for D in the short term is to reduce reliance in Phobos
on the GC. I was looking at std.string last night, and I noticed a
couple things:
1. The inputs are constrained to being str
On Friday, 7 March 2014 at 00:53:18 UTC, Walter Bright wrote:
What it will solve is when the user reads the OS api
documentation, and it says:
#include
then the user knows that in D he has to do:
import whatever.sys.ioctl;
What the user should not have to do is:
version (linu
On Friday, 7 March 2014 at 00:44:45 UTC, H. S. Teoh wrote:
What about using output ranges?
I think most the string functions should be transformative, like
std.algorithm.map, so they take an input range and return an
input range.
This lets them chain most easily, letting the user sink them
On 3/6/2014 3:51 PM, Iain Buclaw wrote:
On 6 March 2014 22:53, Walter Bright wrote:
1. Trying to reinvent, improve, refactor, fix, clean up, etc., the OS api.
This is not in D's charter. We have no resources to do it properly anyway.
I don't think that is what druntime does in terms of it's C
On Thu, Mar 06, 2014 at 01:26:46PM -0800, Walter Bright wrote:
> A major goal for D in the short term is to reduce reliance in Phobos
> on the GC. I was looking at std.string last night, and I noticed a
> couple things:
>
> 1. The inputs are constrained to being strings. This is overly
> restricti
On Thursday, 6 March 2014 at 23:56:35 UTC, Iain Buclaw wrote:
Indeed, I don't recall a single port-related pull in the last
several
months that tried to do any refactoring. I think the general
consensus among the current mantainers is that explicit
versioning is
good, vague/fallback else is
On 2014-03-06 16:06, bearophile wrote:
Timon Gehr:
No. static foreach does not introduce a new scope.
"TypeTuple"-foreach does. Deprecating this language feature is not
in scope of the 'static foreach' DIP. It's separate, and I'd even
argue for not doing it.
My most basic point in this ER is
On Mar 7, 2014 12:10 AM, "Mike" wrote:
>
> On Thursday, 6 March 2014 at 23:56:35 UTC, Iain Buclaw wrote:
>>
>> I hope code duplication in many files rather than one file is in the
>> interest of everyone. :)
>
>
> The only people it doesn't benefit are the ones maintaining multiple
ports :)
>
I d
On Thursday, 6 March 2014 at 23:56:35 UTC, Iain Buclaw wrote:
I hope code duplication in many files rather than one file is
in the
interest of everyone. :)
The only people it doesn't benefit are the ones maintaining
multiple ports :)
I agree with Walter that "attempts to eliminate code dupl
On Tuesday, 4 March 2014 at 00:09:47 UTC, Walter Bright wrote:
This is an important debate going on here:
https://github.com/D-Programming-Language/druntime/pull/732
It has a wide impact, and so I'm bringing it up here so
everyone can participate.
I originally posted issue 11666 after readin
On 6 March 2014 23:46, Sean Kelly wrote:
> On Thursday, 6 March 2014 at 22:53:40 UTC, Walter Bright wrote:
>>
>>
>> 4. Attempts to eliminate code duplication in OS api interface modules. A
>> desire to do this comes up repeatedly. I can expand on this if anyone
>> remains unconvinced :-)
>
>
> I 1
On 6 March 2014 22:53, Walter Bright wrote:
> On 3/6/2014 2:32 PM, Vladimir Panteleev wrote:
>>
>> First of all, even considering the idea of putting everything in one
>> package, it
>> should not be "core". There are many D-specific things in "core" right
>> now. It's
>> probably best to keep OS
On Thursday, 6 March 2014 at 22:53:40 UTC, Walter Bright wrote:
4. Attempts to eliminate code duplication in OS api interface
modules. A desire to do this comes up repeatedly. I can expand
on this if anyone remains unconvinced :-)
I 100% agree with this. Trying to avoid code duplication her
On Thursday, 6 March 2014 at 17:24:07 UTC, Timon Gehr wrote:
On 03/05/2014 11:41 PM, deadalnix wrote:
On Wednesday, 5 March 2014 at 21:54:52 UTC, Timon Gehr wrote:
...
static if needs exactly the same thing, currently the
following compiles:
static if(is(int A)){}
A b; // meh
It's pretty e
On 3/6/2014 2:32 PM, Vladimir Panteleev wrote:
First of all, even considering the idea of putting everything in one package, it
should not be "core". There are many D-specific things in "core" right now. It's
probably best to keep OS includes and D stuff differently.
Sure. The package name isn'
The conversation began with Iain talking about how to improve
things from a maintenance perspective and was kind of sidetracked
by my and Walter's discussion. I agree that something should be
done to address Iain's issue and think his suggestions sound
pretty good. But concerning the rest...
Dr
On Thursday, 6 March 2014 at 21:35:34 UTC, Walter Bright wrote:
To clarify some points..
@Walter are you asking for ALL includes even #include
to map?
Yes. Of course, if you're on linux and attempt to import
core.windows, you should expect a compilation failure, just as
you would in C with
On 3/6/2014 1:40 PM, Meta wrote:
Seems like a good idea to reduce memory usage wherever possible, but I thought
that the reason std.string exists (and duplicates some functionality that exists
elsewhere) is to provide string-specific versions that were either optimized
specifically for strings, o
On 3/6/2014 1:30 PM, Vladimir Panteleev wrote:
On Thursday, 6 March 2014 at 21:26:45 UTC, Walter Bright wrote:
The existing functions should not be removed, but perhaps rewritten as
wrappers around the algorithm versions.
How does one handle case sensitivity for ranges of abstract types?
Use
Timon Gehr:
No. static foreach does not introduce a new scope.
"TypeTuple"-foreach does. Deprecating this language feature is
not in scope of the 'static foreach' DIP. It's separate, and
I'd even argue for not doing it.
My most basic point in this ER is to require a "static" before
"foreach
Timon Gehr:
foreach and static foreach should behave the same in all shared
aspects. (Unfortunately, this statement is somewhat messy to
formalize.)
I am for deprecating unpacking of TypeTuples in foreach.
Introducing such unpacking in static foreach just to deprecate it
(hopefully a little
On Thursday, 6 March 2014 at 17:16:39 UTC, knutaf wrote:
On Thursday, 6 March 2014 at 16:58:00 UTC, Peter Alexander
wrote:
Known issue
https://d.puremagic.com/issues/show_bug.cgi?id=9279
Thanks. Is this suggesting that if I don't use toHexString, I
won't see the problem? Because if I do:
a
On 06.03.2014 09:15, knutaf wrote:
Hello,
Apologies if I have missed some rule or convention in posting this. I'm
new to this site and to D as a whole. I do all of my development on
Windows and in general try to keep my programs as 64-bit unless I have a
reason not to.
I tried the following s
On Thursday, 6 March 2014 at 21:30:47 UTC, Vladimir Panteleev
wrote:
On Thursday, 6 March 2014 at 21:26:45 UTC, Walter Bright wrote:
The existing functions should not be removed, but perhaps
rewritten as wrappers around the algorithm versions.
How does one handle case sensitivity for ranges of
07-Mar-2014 01:30, Vladimir Panteleev пишет:
On Thursday, 6 March 2014 at 21:26:45 UTC, Walter Bright wrote:
The existing functions should not be removed, but perhaps rewritten as
wrappers around the algorithm versions.
How does one handle case sensitivity for ranges of abstract types?
+1
On Thu, 06 Mar 2014 16:30:46 -0500, Vladimir Panteleev
wrote:
On Thursday, 6 March 2014 at 21:26:45 UTC, Walter Bright wrote:
The existing functions should not be removed, but perhaps rewritten as
wrappers around the algorithm versions.
How does one handle case sensitivity for ranges of a
On Thursday, 6 March 2014 at 21:26:45 UTC, Walter Bright wrote:
A major goal for D in the short term is to reduce reliance in
Phobos on the GC. I was looking at std.string last night, and I
noticed a couple things:
1. The inputs are constrained to being strings. This is overly
restrictive, th
On 3/5/2014 9:16 AM, Regan Heath wrote:
1. Walter wants the C include to map directly to a D import.
2. Sean wants to be able to ensure he does not import and use a platform
specific function/definiton in a cross platform application.
Is that about right?
Yes.
To clarify some points..
@Walt
On 03/06/2014 12:35 AM, bearophile wrote:
Andrei Alexandrescu:
Walter and I would preapprove implementation of static foreach if and
only if a solid DIP comes about.
Some suggestions for a static foreach DIP:
- It should work at global scope too (I'd like with() to work at global
scope too).
On Thursday, 6 March 2014 at 21:26:45 UTC, Walter Bright wrote:
The existing functions should not be removed, but perhaps
rewritten as wrappers around the algorithm versions.
How does one handle case sensitivity for ranges of abstract types?
I've found that rewriting traditional code, which is
A major goal for D in the short term is to reduce reliance in Phobos on the GC.
I was looking at std.string last night, and I noticed a couple things:
1. The inputs are constrained to being strings. This is overly restrictive, the
inputs should be InputRanges.
2. The outputs should be a range
It works with DMD/Phobos from GIT.
I have a mixin template that I use to make programming to
interfaces easier. The problem is when I try to wrap the template
to reduce dependence on the container class(using typeof(this)) I
get an error as the string mixin is not working.
The code can be seen here
http://dpaste.dzfl.pl/6c90ca
On 6 March 2014 14:37, Regan Heath wrote:
> On Thu, 06 Mar 2014 11:17:36 -, Kagamin wrote:
>
>> On Wednesday, 5 March 2014 at 17:16:34 UTC, Regan Heath wrote:
>>>
>>> It seems this will satisfy Walter without impacting Sean..
>>
>>
>> As I understand, the idea is that Sean get little trying t
Hello!
I know that there was many efforts of creating BerkeleyDB for D
interface.
But db4d already is too old (doesn't compile with fresh D
compiler) and there is no more actual BDB-port on public.
So I want to present my bdb2d project:
https://sourceforge.net/p/unde/bdb2d
It is a part of anot
On 3/6/14, 9:12 AM, Dicebot wrote:
On Thursday, 6 March 2014 at 16:58:12 UTC, Andrei Alexandrescu wrote:
On 3/5/14, 4:59 PM, Shammah Chancellor wrote:
Actually, there is static foreach if you are iterating over a tuple.
There's one scope for iteration. We need all iterations to occur in
the s
On 03/05/2014 11:41 PM, deadalnix wrote:
On Wednesday, 5 March 2014 at 21:54:52 UTC, Timon Gehr wrote:
...
static if needs exactly the same thing, currently the following compiles:
static if(is(int A)){}
A b; // meh
It's pretty easy to solve: Just give static if/static foreach it's own
scope,
Well, I found out the other day that vibe.d compiles with gdc now
so I went back to see if it made any difference to the benchmarks
I had.
In throughput it made none.
In the latency one it was about 5-10% faster with gdc compared to
dmd, which is good, but it still didn't change the relative
On Thursday, 6 March 2014 at 16:58:00 UTC, Peter Alexander wrote:
Known issue
https://d.puremagic.com/issues/show_bug.cgi?id=9279
Thanks. Is this suggesting that if I don't use toHexString, I
won't see the problem? Because if I do:
auto result = sha1Of("abc");
writefln("%s", result[0]);
I
On Thursday, 6 March 2014 at 16:58:12 UTC, Andrei Alexandrescu
wrote:
On 3/5/14, 4:59 PM, Shammah Chancellor wrote:
Actually, there is static foreach if you are iterating over a
tuple.
There's one scope for iteration. We need all iterations to
occur in the same scope as the foreach statement.
On 3/5/14, 4:59 PM, Shammah Chancellor wrote:
Actually, there is static foreach if you are iterating over a tuple.
There's one scope for iteration. We need all iterations to occur in the
same scope as the foreach statement.
Andrei
Known issue
https://d.puremagic.com/issues/show_bug.cgi?id=9279
On Monday, 24 February 2014 at 08:41:06 UTC, Steve Teale wrote:
25 years ago, when I was trying to write some sort of library
to go with Walter's C++ compiler, I had a wish, and it still
pops into my head from time to time.
What I wanted was functions that were declared in a base class
as 'cu
On Thursday, 6 March 2014 at 16:37:21 UTC, Andrej Mitrovic wrote:
On 3/6/14, dnewbie wrote:
It doesn't work for me. Incorrect result & crash.
dmd2.065
Hmm, could it be VC-related? I'm using VS2010:
C:\dev\code\d_code>vcvars
Setting environment for using Microsoft Visual Studio 2010 x86
On 3/6/14, dnewbie wrote:
> It doesn't work for me. Incorrect result & crash.
> dmd2.065
Hmm, could it be VC-related? I'm using VS2010:
C:\dev\code\d_code>vcvars
Setting environment for using Microsoft Visual Studio 2010 x86 tools.
C:\dev\code\d_code>dmd -m64 -run test.d
A9993E364706816ABA
On Thursday, 6 March 2014 at 15:56:07 UTC, Andrej Mitrovic wrote:
On 3/6/14, knutaf wrote:
and then crashes. If I build without -m64, I get
A9993E364706816ABA3E25717850C26C9CD0D89D, which is what I was
expecting.
It works fine for me using 2.064 and 2.065, both with and
without -m64.
It do
On 3/6/14, knutaf wrote:
> and then crashes. If I build without -m64, I get
> A9993E364706816ABA3E25717850C26C9CD0D89D, which is what I was
> expecting.
It works fine for me using 2.064 and 2.065, both with and without -m64.
On Thu, 06 Mar 2014 11:40:55 -, Kagamin wrote:
It can be a module pragma:
pragma(restrictImportTo,"core.sys.posix.ucontext")
module ports.linux.ucontext;
Good idea, then the platform specific modules can only define the platform
specific things.
But, it means when maintaining them yo
On Thu, 06 Mar 2014 11:17:36 -, Kagamin wrote:
On Wednesday, 5 March 2014 at 17:16:34 UTC, Regan Heath wrote:
It seems this will satisfy Walter without impacting Sean..
As I understand, the idea is that Sean get little trying to fix posix
standard: the only way to check if the code wor
On Tuesday, 4 March 2014 at 22:27:37 UTC, Walter Bright wrote:
On 3/4/2014 1:30 PM, Brad Anderson wrote:
Anyway, there's my little rant about Hacker News. I still go
there daily :)
I do, too, but I gave up posting links there.
+1
HN gets less and less interesting to me. Surprisingly, I now
On Wednesday, 5 March 2014 at 22:54:38 UTC, Andrei Alexandrescu
wrote:
On 3/5/14, 11:40 AM, Tofu Ninja wrote:
On Wednesday, 5 March 2014 at 18:58:49 UTC, Andrei
Alexandrescu wrote:
The one difficulty is figuring how to allow for all
iterations to stay
in the same scope, yet not have duplicate
It can be a module pragma:
pragma(restrictImportTo,"core.sys.posix.ucontext")
module ports.linux.ucontext;
On Wednesday, 5 March 2014 at 17:16:34 UTC, Regan Heath wrote:
It seems this will satisfy Walter without impacting Sean..
As I understand, the idea is that Sean get little trying to fix
posix standard: the only way to check if the code works on some
platform is to compile and test it on that
On Wed, 05 Mar 2014 17:55:27 -, Iain Buclaw
wrote:
On 5 March 2014 17:16, Regan Heath wrote:
On Tue, 04 Mar 2014 00:09:46 -, Walter Bright
wrote:
This is an important debate going on here:
https://github.com/D-Programming-Language/druntime/pull/732
It has a wide impact, and so
On Thursday, 6 March 2014 at 08:15:55 UTC, knutaf wrote:
Hello,
Apologies if I have missed some rule or convention in posting
this. I'm new to this site and to D as a whole. I do all of my
development on Windows and in general try to keep my programs
as 64-bit unless I have a reason not to.
Hello,
Apologies if I have missed some rule or convention in posting
this. I'm new to this site and to D as a whole. I do all of my
development on Windows and in general try to keep my programs as
64-bit unless I have a reason not to.
I tried the following simple program, but it seems to not
90 matches
Mail list logo
