in writing \autoFootnote and not getting a footnote
mark?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
m...@apollinemike.com m...@apollinemike.com writes:
On Jan 8, 2012, at 4:16 PM, David Kastrup wrote:
I am currently replacing the footnote user interface. The doc string
for autoFootnote states:
(_i Footnote the item after which this comes with the text in
@var{footnote} allowing
Neil Puttock n.putt...@gmail.com writes:
On 8 January 2012 15:45, David Kastrup d...@gnu.org wrote:
I am also replacing the flowery language Use like @code{\\tweak}. and
Use like @code{\\once}. since neither makes any sense whatsoever: you
don't use the first before a postevent,
What's
.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
David Kastrup d...@gnu.org writes:
Well, scanning for \markup ... will be quite more of a challenge.
Another problem I see is coordinating the change with the equally-named
\footnote markup command. I have to see how that is defined.
On the plus side, most user files will likely be using
m...@apollinemike.com m...@apollinemike.com writes:
On Jan 10, 2012, at 3:23 PM, David Kastrup wrote:
What's that? auto-numbering will only be active if
footnote-auto-numbering is set in the layout? Which it isn't by
default? And where there is no documentation around explaining how
m...@apollinemike.com m...@apollinemike.com writes:
On Jan 10, 2012, at 4:46 PM, David Kastrup wrote:
footnote-auto-numbering is present in the _code_. This is not just a
question of the doc string. There _is_ user-level documentation in
the notation manual (as a warning) mentioning
.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
in Windows.
It does not make sense on GNU/Linux either.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Graham Percival gra...@percival-music.ca writes:
On Thu, Jan 12, 2012 at 07:00:27PM +0100, David Kastrup wrote:
Reinhold Kainhofer reinh...@kainhofer.com writes:
However, even for HTML we need some kind of line width so that we can
line-break all lilypond snippets.
That line width
, and then deleted, and then built again
as a new origin/staging, the developer can get the appropriate
set of commits by just reissuing git rebase origin/staging.
ok, sounds great!
Too good to be true. See comment in the issue.
--
David Kastrup
instead of 13, but IMO stderr is more understandable than
16.
That redirects stdout _to_ file descriptor 6, and would likely be the
source of the stuff that gets back via the other redirection.
--
David Kastrup
___
lilypond-devel mailing list
lilypond
in
their private repositories until the hot release phase is through.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
expectations. I don't see the point in disappointing them more than
necessary. We don't want a KDE4-like press without pressing need.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond
integration the main target of 2.16.
I think we should focus on the near end of the tunnel these days if we
want to see 2.16 anytime soon.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo
David Kastrup d...@gnu.org writes:
m...@apollinemike.com m...@apollinemike.com writes:
I think that the major deciding factor will be Guile 2.0 integration.
We have had no code that has been able to survive basic testing. I
don't think it makes sense to bank on a major feature
-only changes
deliberately.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
/null
Maybe we should have a separate target for removing them. I can't vouch
that this is the problem: I just glanced over the diff, and that was
what caught my eye.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https
on a detached HEAD. Whatever you do will get lost (except
from your repository's reflog) when you switch to another branch.
git checkout origin
is the same as
git checkout origin~0
In either case, what you do subsequently has no reference except the
current HEAD. It's scratch pad work.
--
David
a test run before pushing a
translation merge.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
. My current computer is
far too slow to do a DOC rebuild in any reasonable amount of time, so
I'll be pushing the result of that work unchecked, leaving that job to
Patchy again. Expect an hour or so.
--
David Kastrup
___
lilypond-devel mailing list
staging on the results.
Let's hope that this was all.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
to be more or less right. Apparently you found a less
right case.
Suggestions?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
!
Another year, another Report. This month we’re welcoming new LilyPond
Report editor David Kastrup, who (in addition to being a talented
developer) has been busy writing about some of the new, awesome features
recently added to LilyPond... And speaking of awesomeness, don’t miss
his interview
release.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Carl Sorensen c_soren...@byu.edu writes:
On 1/21/12 9:45 AM, Graham Percival gra...@percival-music.ca wrote:
On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote:
I would very much prefer the work on Issue 2240 (aka 2070) to make it
into 2.16. It is a significant API change
m...@apollinemike.com m...@apollinemike.com writes:
On Jan 21, 2012, at 6:14 PM, Keith OHara wrote:
Carl Sorensen c_sorensen at byu.edu writes:
On 1/21/12 9:45 AM, Graham Percival graham at percival-music.ca wrote:
On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote:
I would
Carl Sorensen c_soren...@byu.edu writes:
On 1/21/12 10:37 AM, David Kastrup d...@gnu.org wrote:
I have actually found out that I promised too much about string numbers
appearing on isolated notes: since the string number events _are_
listened to (likely by the tabstaff engraver team
going on,
but will there be any difference between
c\3 e\2 g\1 and c e g \3\2\1
once these changes are implemented?
The latter would not display anything anywhere.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https
m...@apollinemike.com m...@apollinemike.com writes:
On Jan 21, 2012, at 7:12 PM, David Kastrup wrote:
If you wrote note^postevent previously, the postevent ended up in
articulations of the NoteEvent when written inside of a chord, or as
an EventChord companion when not written in a chord
m...@apollinemike.com m...@apollinemike.com writes:
On Jan 21, 2012, at 10:15 PM, David Kastrup wrote:
m...@apollinemike.com m...@apollinemike.com writes:
On Jan 21, 2012, at 7:58 PM, David Kastrup wrote:
that all articulation events will be pulled out of NoteEvents
I am most productive at.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
m...@apollinemike.com m...@apollinemike.com writes:
After reading through this e-mail, I'm ok with the patch with one
caveat about regtests (see below).
On Jan 22, 2012, at 9:08 AM, David Kastrup wrote:
Music expressions _represent_ the input, as opposed to stream events
which represent
m...@apollinemike.com m...@apollinemike.com writes:
After reading through this e-mail, I'm ok with the patch with one
caveat about regtests (see below).
On Jan 22, 2012, at 9:08 AM, David Kastrup wrote:
Music expressions _represent_ the input, as opposed to stream events
which represent
David Kastrup d...@gnu.org writes:
If I write
myC =
#(define-music-function (parser location) () #{ c #})
then I can't currently write
\myC4 or similar. It would just not work. And there is no way to
define this function, #{ #} or not, in a manner that could work both in
chords as well
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
If I write
myC =
#(define-music-function (parser location) () #{ c #})
then I can't currently write
\myC4 or similar. It would just not work. And there is no way to
define this function, #{ #} or not, in a manner
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
If I write
myC =
#(define-music-function (parser location) () #{ c #})
then I can't currently write
\myC4 or similar. It would just not work. And there is no way to
define
apologies that I can't defend this patch further
today. It does not mean that I am not serious about it, and I
definitely believe that if Graham double-checks the comments on this
patch, he'll find the reason for our difference in test results.
--
David Kastrup
benefits in memory usage if this would
be retired since the music events could be garbage collected after
conversion to stream events. It is also conceptually cleaner.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https
Graham Percival gra...@percival-music.ca writes:
On Sun, Jan 22, 2012 at 11:49:06AM +0100, David Kastrup wrote:
Anybody actually using the music-cause? Inside of LilyPond, the only
appearance (apart from its declaration) would be
/*
ES TODO: This is a temporary fix. Stream_events
Graham Percival gra...@percival-music.ca writes:
On Sun, Jan 22, 2012 at 11:35:55AM +0100, David Kastrup wrote:
So please accept my apologies that I can't defend this patch further
today. It does not mean that I am not serious about it, and I
definitely believe that if Graham double-checks
: David Kastrup d...@gnu.org
Date: Sun Jan 22 18:39:59 2012 +0100
parser.yy: strip music-wrapper-music inside of EventChord
This makes things like
fis \transpose c g fis
work.
commit 751aa4192c75e3bf2436bf2053e041f7d33a6d7d
Author: David Kastrup d...@gnu.org
Date
be done a lot simpler. I think it is
important for snippets to be just as complex as the task requires.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
budget does not allow me to pay developers to
work full time on LilyPond.
At least you have a budget. I don't.
Cheers,
Whining Xavier
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo
Graham Percival gra...@percival-music.ca writes:
On Tue, Jan 24, 2012 at 12:35:17PM +0100, David Kastrup wrote:
has less potential to go wrong if there is a problem at any time. I
actually don't really understand why we bother with restoring the tree
anyway instead of removing it and doing
David Kastrup d...@gnu.org writes:
Graham Percival gra...@percival-music.ca writes:
On Tue, Jan 24, 2012 at 12:35:17PM +0100, David Kastrup wrote:
has less potential to go wrong if there is a problem at any time. I
actually don't really understand why we bother with restoring the tree
to listen.
Wouldn't that alone be worth it?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
and improve Patchy (with
Julien's help).
Sounds like a plan.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
are not core skills is not really very
likely to be an ungrumpifying task.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
for a different old message...
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
unexpectedly
A shallow repository? That's a git problem, not a Python problem. I
would have to look that up.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
to be
proven wrong, though.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
that the similarity does not go
deep enough. My guess is that translations may not be covered.
Apologies.
I'll be fixing this, but it will take several hours to make a doc build
on my current setup. Do you have the log files for the failed runs,
perchance?
Thanks
--
David Kastrup
David Kastrup d...@gnu.org writes:
*** FAILED BUILD ***
nice make doc -j3 CPU_COUNT=3
Previous good commit: 8019ff784cd3aa6cc43b8eb8f29a621bc5800f5c
Current broken commit: f1b7a60cdb4c2f1d41329a1b3a6a01f4306f6467
That would be the 2240 work. I did a full make check
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
*** FAILED BUILD ***
nice make doc -j3 CPU_COUNT=3
Previous good commit: 8019ff784cd3aa6cc43b8eb8f29a621bc5800f5c
Current broken commit: f1b7a60cdb4c2f1d41329a1b3a6a01f4306f6467
That would be the 2240
Graham Percival gra...@percival-music.ca writes:
On Wed, Jan 25, 2012 at 08:29:51PM +0100, David Kastrup wrote:
That would be the 2240 work. I did a full make check and a build of the
info documentation which in my experience is pretty much the same as a
make doc but somewhat faster
David Kastrup d...@gnu.org writes:
Seems like I really got mixed up with my builds. Turns out that my
changes.tely entry depends on the patch in
URL:http://code.google.com/p/lilypond/issues/detail?id=2247 so I
pushed that as well as it is reasonably simple and well-contained.
No idea how
Graham Percival gra...@percival-music.ca writes:
On Wed, Jan 25, 2012 at 09:20:18PM +0100, David Kastrup wrote:
WTF? That's definitely something in the changes file. I checked this
and it compiled and I had code that made sure it compiled. With all the
rebasing to make this fit better I
David Kastrup d...@gnu.org writes:
Graham Percival gra...@percival-music.ca writes:
On Wed, Jan 25, 2012 at 09:20:18PM +0100, David Kastrup wrote:
WTF? That's definitely something in the changes file. I checked this
and it compiled and I had code that made sure it compiled. With all
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
I'll try doing this without messing up again. 15 minutes or so at
least.
Go ahead. No diff to last staging regarding the result, but the fix
commit has been pulled into the side branch.
James was so kind to check
better name for it?) explicitly. Since q is an input
convenience, and relative pitch is also an input convenience, I don't
think that there would be much of an affected user base.
Machine-generated output would rarely have to use q.
--
David Kastrup
else being frozen, but some
overlap should be tolerable.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Nicolas Sceaux nicolas.sce...@gmail.com writes:
Le 26 janv. 2012 à 11:00, David Kastrup a écrit :
The bad news is that absolute pitch friends would have to call the \q
function (any better name for it?) explicitly. Since q is an input
convenience, and relative pitch is also an input
checking whether everything is working as well as one
could hope, but there is a non-zero danger that any fixes with good
results are to a good degree depending on the operating system as well.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel
the necessity for calling
it explicitly for absolute music (and the necessity of putting a call
inside of \relative).
Suggestions?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond
typing (c or q is pretty much the same effort).
It treats durations and pitches in the input stream in an equivalent
manner. It has the potential downfall of making the input stream more
confusing to read.
For humans _and_ LilyPond.
Let's not get there.
--
David Kastrup
David Kastrup d...@gnu.org writes:
2) do it in a specific music function either explicitly called, or
called automatically at an appropriate time.
This is totally straightforward and controllable. It also means that it
is ok to work with a reference to the previous chord since no arbitrary
David Kastrup d...@gnu.org writes:
It would be possible to let q set a parser variable that will optimize
this pass away when unset. The drawback would be that ChordRepeat
events entering via different channels (#{ c e g q #} uses its own
parser, and generation by Scheme is also possible
Nicolas Sceaux nicolas.sce...@gmail.com writes:
Le 26 janv. 2012 à 11:00, David Kastrup a écrit :
The bad news is that absolute pitch friends would have to call the \q
function (any better name for it?) explicitly. Since q is an input
convenience, and relative pitch is also an input
, commit: 39f50579ff91fdca06acd52a9392ab2874f4723b
and I don't know where I need to look from here.
Run
git fetch --depth=100
in your original repository. That should convert it from a shallow
repository to a full one.
--
David Kastrup
, but because it is much more
flexible and predictable to use (you can already see in the changed
regtest an application that has not been possible previously: fingering
repetition only in tabulature, while not removing the initial fingering
spec in the main score).
--
David Kastrup
James pkx1...@gmail.com writes:
Hello,
On 24 January 2012 22:20, David Kastrup d...@gnu.org wrote:
Janek Warchoł janek.lilyp...@gmail.com writes:
Keeping the staging-merge going would be about five people
committing to 50€ a month. That is, of course, not enough for me to
live
Graham Percival gra...@percival-music.ca writes:
On Sun, Jan 29, 2012 at 03:34:45PM +0100, David Kastrup wrote:
Patchy has been running for about 6 hours on my laptop trying to get the
current staging (which is one trivial commit ahead of master) checked.
And is still on it.
??? if you
importance to you, even if it meant a
solution expensive in developer and possibly execution time.
When you now can't be even bothered looking at it, I will think thrice
before tackling anything which you call important.
--
David Kastrup
___
lilypond-devel
it was in Patch-review, so it
moved into Patch-countdown, and because still nobody bothered to even
look at it, it ended up in master, and now nobody can usefully work with
q anymore in 2.16.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel
make sense to you.
Opinions are more important than results here, and results are only
important as _experiences_, namely connected with your own, individual
work.
Don't bother doing the job of the computer. We need that of the human.
Thanks
--
David Kastrup
such a good idea after all. I'll take a look at how
\times works and likely will change this back, as the durations are more
likely to be found in a duration entry. Hopefully that is enough, or
I'll have some serious head-scratching to do.
Thanks, that was an important help already.
--
David Kastrup
Colin Campbell c...@shaw.ca writes:
On 12-01-29 11:04 AM, David Kastrup wrote:
Thanks. Note that this does _not_ mean regtests and doc builds: we have
automatisms for that. It means running your own files that use this
feature, and reading the docs to see whether the docs as well
Janek Warchoł janek.lilyp...@gmail.com writes:
2012/1/29 David Kastrup d...@gnu.org:
So seriously: this needs to move to a different computer if LilyPond
development is of concern to you all.
My work on Patchy (to make it more foolproof and more
operator-friendly, i.e.
'run-a-script
Graham Percival gra...@percival-music.ca writes:
On Mon, Jan 30, 2012 at 12:47:11PM +0100, David Kastrup wrote:
The test-patches.py script can likely make use of the techniques in
lilypond-patchy-staging.ly with regard to doing an offside build with a
defined starting point not relying
that.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Phil Holmes m...@philholmes.net writes:
Original Message -
From: David Kastrup d...@gnu.org
To: lilypond-devel@gnu.org
Sent: Monday, January 30, 2012 1:07 PM
Subject: Re: somebody needs to run staging before 29 Jan
Phil Holmes m...@philholmes.net writes:
I assume it uses the normal
will
depend on the exact code, but I don't think that this problem should be
cause to worry.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
m...@apollinemike.com m...@apollinemike.com writes:
On Jan 30, 2012, at 2:49 PM, David Kastrup wrote:
logical impossibility
This is all I needed to know - thanks!
Well, it forces
sizeof(x) = 2*sizeof(x)
and we know sizeof(x)= 0, so it is not logically impossible as long as
the structure
David Kastrup d...@gnu.org writes:
m...@apollinemike.com m...@apollinemike.com writes:
On Jan 30, 2012, at 2:49 PM, David Kastrup wrote:
logical impossibility
This is all I needed to know - thanks!
Well, it forces
sizeof(x) = 2*sizeof(x)
sizeof(x) = 2*sizeof(x) of course.
and we know
/tablature-chord-repetition-finger.ly as this may save
you some time afterwards.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
older than
something that already got pushed. Or if his version of staging has
been, in the mean time, replaced by something else that has been pushed
instead.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org
.
inline: Screenshot at 2012-01-30 17:40:37.png
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
that you create the swinged version manually.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
/issues/detail?id=687
You are confusing the quality of one implementation with the qualities
of the approach as such.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
this
information from the music expression either. After all, it is
everything LilyPond has to work with.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
, however, there _is_ an exact timing implied by the notation,
and one that _does_ affect note spacing, so it is more important that
LilyPond offers a way to get this right to a degree where it is
proof-audible.
--
David Kastrup
___
lilypond-devel mailing
.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
What would you expect the following to do?
\new StaffGroup { \relative c' { \relative c' { c2 } c } }
I can't imagine _any_ situation where this behavior would make sense.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
-git.tcl
as well?
I don't think it would help.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
David Kastrup d...@gnu.org writes:
Graham Percival gra...@percival-music.ca writes:
The updated CG instructions for setting up git manually specify to
use clone:
http://lilypond.org/doc/v2.15/Documentation/contributor/setting-up
but the latest patch for lily-git.tcl still appears to use
Trevor Daniels t.dani...@treda.co.uk writes:
David Kastrup wrote Tuesday, January 31, 2012 12:47 PM
What would you expect the following to do?
\new StaffGroup { \relative c' { \relative c' { c2 } c } }
It does pretty much what I expected, but then I have been explaining
the drawbacks
Trevor Daniels t.dani...@treda.co.uk writes:
David Kastrup wrote Tuesday, January 31, 2012 12:47 PM
What would you expect the following to do?
\new StaffGroup { \relative c' { \relative c' { c2 } c } }
It does pretty much what I expected, but then I have been explaining
the drawbacks
Trevor Daniels t.dani...@treda.co.uk writes:
David Kastrup wrote Tuesday, January 31, 2012 2:31 PM
Trevor Daniels t.dani...@treda.co.uk writes:
No, me neither, but leaving Voice contexts to be implied usually works
well, eg with Staff rather than StaffGroup.
Why would you want to have
1 - 100 of 6030 matches
Mail list logo
