Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I don't know how to make it output the symbol names like it seems to do
for you.
I dislike the object-file-based approach altogether, not least because
it appears to depend on unportable aspects of
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
indent needs the typedef list. Maybe we can hack something based on
typedefs in the source code, instead of object files.
The only think of is to grab typedefs from the object file and then also
try to get them from the souce too
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
indent needs the typedef list. Maybe we can hack something based on
typedefs in the source code, instead of object files.
The only think of is to grab typedefs from the object file and then also
try to get
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I don't know how to make it output the symbol names like it seems to do
for you.
I dislike the object-file-based approach altogether, not least because
it appears to depend on unportable aspects of someBSD's objdump.
Surely
Alvaro Herrera wrote:
Hi,
It seems pgindent is not considering EXEC_BACKEND typedefs. For
example,
static void restore_backend_variables(BackendParameters * param, Port *port);
BackendParameters is not considered a typedef.
Not sure how serious an issue this is ... I just noticed
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
It seems pgindent is not considering EXEC_BACKEND typedefs.
Yep. The cause is that find_typedefs actually pulls the typedef out of
the debugged-enabled binary, and on Unix those functions aren't used by
default. This is spelled
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
It seems pgindent is not considering EXEC_BACKEND typedefs.
Yep. The cause is that find_typedefs actually pulls the typedef out of
the debugged-enabled binary, and on Unix those functions aren't used by
Hi,
It seems pgindent is not considering EXEC_BACKEND typedefs. For
example,
static void restore_backend_variables(BackendParameters * param, Port *port);
BackendParameters is not considered a typedef.
Not sure how serious an issue this is ... I just noticed and thought I
would mention it.
Somehow pgindent appears to do odd things with multiline string constants,
such as
somefunc(blah,
lots of text
with mulitple lines
like this);
Afterwards this looks more like this:
somefunc(blah,
lots of text
with mulitple lines
like this);
As
Peter Eisentraut [EMAIL PROTECTED] writes:
Somehow pgindent appears to do odd things with multiline string constants,
such as
somefunc(blah,
lots of text
with mulitple lines
like this);
Afterwards this looks more like this:
somefunc(blah,
lots of text
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Somehow pgindent appears to do odd things with multiline string constants,
such as
somefunc(blah,
lots of text
with mulitple lines
like this);
Afterwards this looks more like this:
Tom Lane wrote:
I notice that the latest pgindent run has decided that comments attached
to else should be moved onto the next line, as in this example in
src/bin/psql/mbprint.c:
{
linewidth += 4;
I notice that the latest pgindent run has decided that comments attached
to else should be moved onto the next line, as in this example in
src/bin/psql/mbprint.c:
{
linewidth += 4;
format_size += 4;
On Wed, Oct 04, 2006 at 04:41:44PM -0400, Bruce Momjian wrote:
That will prevent it from being changed by pgindent in the future.
Thanks.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber:
On Tue, Oct 03, 2006 at 08:26:36PM -0400, Bruce Momjian wrote:
I have run pgindent for 8.2.
Is there a way to make pgindent skip a directory? It seems it has
changed all expected file in ecpg's regression suite. So we see a lot of
differences now.
Michael
--
Michael Meskes
Email: Michael at
Michael Meskes wrote:
On Tue, Oct 03, 2006 at 08:26:36PM -0400, Bruce Momjian wrote:
I have run pgindent for 8.2.
Is there a way to make pgindent skip a directory? It seems it has
changed all expected file in ecpg's regression suite. So we see a lot of
differences now.
Sure a directory
On Wed, Oct 04, 2006 at 06:15:31AM -0400, Bruce Momjian wrote:
Michael Meskes wrote:
Is there a way to make pgindent skip a directory? It seems it has
changed all expected file in ecpg's regression suite. So we see a lot of
differences now.
Sure a directory can be skipped. I am confused
Joachim Wieland wrote:
On Wed, Oct 04, 2006 at 06:15:31AM -0400, Bruce Momjian wrote:
Michael Meskes wrote:
Is there a way to make pgindent skip a directory? It seems it has
changed all expected file in ecpg's regression suite. So we see a lot of
differences now.
Sure a directory
I have run pgindent for 8.2.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
It is about time to run pgindent before we enter beta testing. Is this
weekend good for everyone?
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of
Bruce Momjian [EMAIL PROTECTED] writes:
It is about time to run pgindent before we enter beta testing. Is this
weekend good for everyone?
I think we should wait until the fate of the GUC patch is determined
--- if we want to apply it, a pgindent run is going to cause some
unnecessary work,
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
It is about time to run pgindent before we enter beta testing. Is this
weekend good for everyone?
I think we should wait until the fate of the GUC patch is determined
--- if we want to apply it, a pgindent run is going to cause some
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
If it were the else's indent plus one more tab it would be reasonably
sane; it'd match the indentation of what comes next.
OK, I can do that but consider:
[ other case ]
Just out of curiosity, what will
This case in xlog.c is representative of a disease that pgindent has had
for awhile:
@@ -4276,7 +4300,8 @@ StartupXLOG(void)
if (needNewTimeLine)/* stopped because of stop request */
ereport(FATAL,
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
and this does exactly as you describe by putting the comment on its own
line. I just changed it to:
...
so that the new comment will have the same indenting as the else that
was input.
If it were the else's indent plus one more
Tom Lane wrote:
This case in xlog.c is representative of a disease that pgindent has had
for awhile:
@@ -4276,7 +4300,8 @@ StartupXLOG(void)
if (needNewTimeLine)/* stopped because of stop request */
ereport(FATAL,
Bruce Momjian [EMAIL PROTECTED] writes:
and this does exactly as you describe by putting the comment on its own
line. I just changed it to:
...
so that the new comment will have the same indenting as the else that
was input.
If it were the else's indent plus one more tab it would be
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
If it were the else's indent plus one more tab it would be reasonably
sane; it'd match the indentation of what comes next.
OK, I can do that but consider:
[ other case ]
Just out of curiosity, what will pgindent do when re-run on the
I'm fairly displeased with what pgindent has done to single-line PG_TRY
constructs, as in this example from pl_exec.c:
*** exec_stmt_block(PLpgSQL_execstate * esta
*** 911,922
SPI_result_code_string(xrc));
PG_TRY();
!
Tom Lane said:
I'm fairly displeased with what pgindent has done to single-line PG_TRY
constructs, as in this example from pl_exec.c:
*** exec_stmt_block(PLpgSQL_execstate * esta
*** 911,922
SPI_result_code_string(xrc));
Andrew Dunstan wrote:
Tom Lane said:
I'm fairly displeased with what pgindent has done to single-line PG_TRY
constructs, as in this example from pl_exec.c:
*** exec_stmt_block(PLpgSQL_execstate * esta
*** 911,922
SPI_result_code_string(xrc));
Andrew Dunstan wrote:
I had that argument a while ago with Bruce and lost :-) . It does horrible
things to if/else constructs too. The workaround is to put a comment in the
block. On the whole I agree with you, though. If I put braces in my program
it's for a reason, and the indenter shouldn't
Bruce Momjian [EMAIL PROTECTED] writes:
I have removed the code from pgindent. Now how do we clean up the
try/catch code that got messed up?
I've hand-restored the cases that are in the files I'm currently
editing. I'll look for more later.
regards, tom lane
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
| Gaetano Mendola wrote:
|
|I had that argument a while ago with Bruce and lost :-) . It does horrible
|things to if/else constructs too. The workaround is to put a comment in the
|block. On the whole I agree with you, though. If I
OK, it never removed braces from things like:
int x;
{
int x;
x=5;
}
but anyway I think we all agree it was uglifying the code more than it
was clarifying.
---
Should I run pgindent tomorrow in preparation for final release?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown
Bruce Momjian [EMAIL PROTECTED] writes:
Should I run pgindent tomorrow in preparation for final release?
I've been intending to mention that you should do that, and the
copyright year bump bit too, pretty soon. We aren't going to
have a lower level of pending patches later than we do now.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Should I run pgindent tomorrow in preparation for final release?
I've been intending to mention that you should do that, and the
copyright year bump bit too, pretty soon. We aren't going to
have a lower level of pending patches later
I have completed the pgindent run for 8.0.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania
Are folks ready for me to run pgindent?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
I have completed the pgindent run, and the copyright updated to 2003.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.|
I am going to run pgindent in 8 hours, in preparation for 7.4 beta.
I am completing the list of release changes and should be done in 8-12
hours.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard
Just a reminder that once all the patches are in, I need to run
pgindent.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.|
All done. Thanks guys.
I recently ran pgindent, which had some fixes from the 7.1 version that
were suggested by Tom Lane. Unfortunately, some of my fixes had bad
side effects, and I would like to run pgindent again to correct those
problems Tom has found.
The changes should be
I recently ran pgindent, which had some fixes from the 7.1 version that
were suggested by Tom Lane. Unfortunately, some of my fixes had bad
side effects, and I would like to run pgindent again to correct those
problems Tom has found.
The changes should be minimal, mostly related to indenting of
Bruce Momjian [EMAIL PROTECTED] writes:
I have run pgindent on the C files and run pgjindent on the jdbc files
as requested by the jdbc list. You can package up beta now. I will
update the HISTORY file tomorrow with recent changes.
Please hold on that packaging until I add the int2-int8
On Thu, 25 Oct 2001, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
If we aren'g putting that Packaging stuff into v7.2, can we get it into
beta as contrib also? Before I do the first packagingof the beta?
Uh ... what?
I just meant to wait a little bit on wrapping the
Marc G. Fournier [EMAIL PROTECTED] writes:
If we aren'g putting that Packaging stuff into v7.2, can we get it into
beta as contrib also? Before I do the first packagingof the beta?
Uh ... what?
I just meant to wait a little bit on wrapping the tarball while I make
this last(?) catalog
On Thu, 25 Oct 2001, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
If we aren'g putting that Packaging stuff into v7.2, can we get it into
beta as contrib also? Before I do the first packagingof the beta?
Uh ... what?
I just meant to wait a little bit on wrapping
On Thu, 25 Oct 2001, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
If we aren'g putting that Packaging stuff into v7.2, can we get it into
beta as contrib also? Before I do the first packagingof the beta?
Uh ... what?
I just meant to wait a little bit on wrapping
D'oh ...
Okay, will hold off on packaging, but have already tag'd it ...
If we aren'g putting that Packaging stuff into v7.2, can we get it into
beta as contrib also? Before I do the first packagingof the beta?
On Thu, 25 Oct 2001, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, I see my email got through to the list. Running pgindent now and
will commit changes.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your
I have run pgindent on the C files and run pgjindent on the jdbc files
as requested by the jdbc list. You can package up beta now. I will
update the HISTORY file tomorrow with recent changes.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
I have been asked to run pgindent in preparation for beta starting
tomorrow. In this run, I will also reformat the jdbc files as agreed to
by the jdbc list. I don't have much time to wait before starting the
pgindent run. I hope people don't have outstanding patches sitting
around.
--
Christopher Sawtell [EMAIL PROTECTED] writes:
Can't the contributors themselves run pgindent on the files which they
have changed _just_ before creating the patch which is to be contributed?
That would require everyone to have a working copy of BSD indent (gnu
indent does not behave the
* Bruce Momjian [EMAIL PROTECTED] [010321 21:14] wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
and most times, those have to be merged into the source tree due to
extensive changes anyway ... maybe we should just get rid of the use of
pgindent altogether?
I think
Alfred Perlstein [EMAIL PROTECTED] writes:
cvs annotate is a really, really handy tool, unfortunetly these
indent runs remove this very useful tool as well as do a major job
of obfuscating the code changes.
I think this is a good reason for *not* applying pgindent on an
incremental basis, but
It seems that you guys are dead set on using this pgindent tool,
this is cool, we'd probably use some indentation tool on the FreeBSD
sources if there was one that met our code style(9) guidelines.
I would liken running pgindent to having a nice looking store or
website. No one is going to
Alfred Perlstein [EMAIL PROTECTED] writes:
cvs annotate is a really, really handy tool, unfortunetly these
indent runs remove this very useful tool as well as do a major job
of obfuscating the code changes.
I think this is a good reason for *not* applying pgindent on an
incremental
Bruce Momjian [EMAIL PROTECTED] writes:
Alfred Perlstein [EMAIL PROTECTED] writes:
cvs annotate is a really, really handy tool, unfortunetly these
indent runs remove this very useful tool as well as do a major job
of obfuscating the code changes.
I think this is a good reason for *not*
Bruce Momjian writes:
Are there any severely mis-indented files?
There are some new contrib modules that are nowhere close to our
indent conventions; also a good deal of foreign-key-related stuff
in the parser that needs to be cleaned up. So we should run it.
I've always felt
Hey, I am open to whatever people want to do. Just remember that we
accumulate lots of patches/development during the slow time before
development, and those patches become harder to apply. Peter E has some
already.
This argument seems irrelevant when given the choice of before
Bruce Momjian [EMAIL PROTECTED] writes:
I think early beta is the time to
do this next time. That has the fewest patches crossing over time.
That would work too, particularly if you give people a few days' notice.
("Get your patches in now, or expect to have to reformat...")
Bruce Momjian [EMAIL PROTECTED] writes:
I think early beta is the time to
do this next time. That has the fewest patches crossing over time.
That would work too, particularly if you give people a few days' notice.
("Get your patches in now, or expect to have to reformat...")
Yes, I did
On Thu, Mar 22, 2001 at 01:25:07AM -0500, Bruce Momjian wrote:
I have finished pgindent. We also had many old comments of the format:
/* --
* comment
* --
*/
These are now the more concise:
/*
* comment
*/
Bruce Momjian wrote:
You don't notice the value of pgindent until you have some code that
hasn't been run through it. For example, ODBC was not run through until
this release, and I had a terrible time trying to understand the code
because it didn't _look_ like the rest of the code. Now
On Thu, Mar 22, 2001 at 01:25:07AM -0500, Bruce Momjian wrote:
I have finished pgindent. We also had many old comments of the format:
/* --
* comment
* --
*/
These are now the more concise:
/*
* comment
*/
Hmm,
With RC1 nearing, when should I run pgindent? This is usually the time
I do it.
Does the silence mean I should pick a date to run this?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive,
Bruce Momjian writes:
With RC1 nearing, when should I run pgindent? This is usually the time
I do it.
Are there any severely mis-indented files?
Not sure. I think there are some. It doesn't do anything unless there
is mis-indenting, so it is pretty safe and has always been done in
On Wed, 21 Mar 2001, Bruce Momjian wrote:
With RC1 nearing, when should I run pgindent? This is usually the time
I do it.
Does the silence mean I should pick a date to run this?
Since I'm going to end up re-rolling RC1, do a run tonight on her, so that
any problems that arise from
Bruce Momjian writes:
With RC1 nearing, when should I run pgindent? This is usually the time
I do it.
Are there any severely mis-indented files?
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of
On Wed, 21 Mar 2001, Bruce Momjian wrote:
With RC1 nearing, when should I run pgindent? This is usually the time
I do it.
Does the silence mean I should pick a date to run this?
Since I'm going to end up re-rolling RC1, do a run tonight on her, so that
any problems that arise
Bruce Momjian writes:
Peter, this is the optimial time to do it because no one has any
outstanding patches at this point. Seems this is the only good time.
Actually, I have quite a few outstanding patches. I got screwed by this
last time around as well. But I understand that this might be
Bruce Momjian writes:
Peter, this is the optimial time to do it because no one has any
outstanding patches at this point. Seems this is the only good time.
Actually, I have quite a few outstanding patches. I got screwed by this
last time around as well. But I understand that this
OK, I am going to have dinner and then get started on the pgindent run.
I have also noticed we have some comments like:
/*
* one word
*
*/
that look funny in a few places. I propose:
/* one word */
to be consistent.
With RC1 nearing,
On Wed, 21 Mar 2001, Bruce Momjian wrote:
OK, I am going to have dinner and then get started on the pgindent run.
I have also noticed we have some comments like:
/*
* one word
*
*/
that look funny in a few places. I propose:
/* one
On Wed, 21 Mar 2001, Bruce Momjian wrote:
OK, I am going to have dinner and then get started on the pgindent run.
I have also noticed we have some comments like:
/*
* one word
*
*/
that look funny in a few places. I propose:
Bruce Momjian [EMAIL PROTECTED] writes:
With RC1 nearing, when should I run pgindent? This is usually the time
I do it.
Does the silence mean I should pick a date to run this?
If you're going to do it before the release, I think you should do it
*before* we wrap RC1. I've said before and
Are there any severely mis-indented files?
There are some new contrib modules that are nowhere close to our
indent conventions; also a good deal of foreign-key-related stuff
in the parser that needs to be cleaned up. So we should run it.
I've always felt that it'd be smarter to run pgindent
Are there any severely mis-indented files?
There are some new contrib modules that are nowhere close to our
indent conventions; also a good deal of foreign-key-related stuff
in the parser that needs to be cleaned up. So we should run it.
I've always felt that it'd be smarter to run
* Bruce Momjian [EMAIL PROTECTED] [010321 22:11]:
Are there any severely mis-indented files?
There are some new contrib modules that are nowhere close to our
indent conventions; also a good deal of foreign-key-related stuff
in the parser that needs to be cleaned up. So we should run
On Wed, 21 Mar 2001, Bruce Momjian wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
With RC1 nearing, when should I run pgindent? This is usually the time
I do it.
Does the silence mean I should pick a date to run this?
If you're going to do it before the release, I think you
Bruce Momjian [EMAIL PROTECTED] writes:
Hey, I am open to whatever people want to do. Just remember that we
accumulate lots of patches/development during the slow time before
development, and those patches become harder to apply. Peter E has some
already.
Why not start a devel cycle by (a)
Bruce Momjian [EMAIL PROTECTED] writes:
Hey, I am open to whatever people want to do. Just remember that we
accumulate lots of patches/development during the slow time before
development, and those patches become harder to apply. Peter E has some
already.
Why not start a devel cycle
If people can get their patches in all at one time, that would work.
The only problem there is that people who supply patches against 7.1
will not match the 7.2 tree, and we get those patches from people for
months.
and those patches should only be applied to the v7.1 branch ... we are
On Wed, 21 Mar 2001, Bruce Momjian wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Hey, I am open to whatever people want to do. Just remember that we
accumulate lots of patches/development during the slow time before
development, and those patches become harder to apply. Peter E has
On Wed, 21 Mar 2001, Bruce Momjian wrote:
If people can get their patches in all at one time, that would work.
The only problem there is that people who supply patches against 7.1
will not match the 7.2 tree, and we get those patches from people for
months.
and those patches
and most times, those have to be merged into the source tree due to
extensive changes anyway ... maybe we should just get rid of the use of
pgindent altogether? its not something that I've ever seen required on
other projects I've worked on ... in general, most projects seem to
require that
On Wed, 21 Mar 2001, Bruce Momjian wrote:
and most times, those have to be merged into the source tree due to
extensive changes anyway ... maybe we should just get rid of the use of
pgindent altogether? its not something that I've ever seen required on
other projects I've worked on ...
The Hermit Hacker [EMAIL PROTECTED] writes:
and most times, those have to be merged into the source tree due to
extensive changes anyway ... maybe we should just get rid of the use of
pgindent altogether?
I think pgindent is a good thing; the style of different parts of the
code would vary
and most times, those have to be merged into the source tree due to
extensive changes anyway ... maybe we should just get rid of the use of
pgindent altogether? its not something that I've ever seen required on
other projects I've worked on ... in general, most projects seem to
The Hermit Hacker [EMAIL PROTECTED] writes:
and most times, those have to be merged into the source tree due to
extensive changes anyway ... maybe we should just get rid of the use of
pgindent altogether?
I think pgindent is a good thing; the style of different parts of the
code would
On Thu, 22 Mar 2001, Bruce Momjian wrote:
and most times, those have to be merged into the source tree due to
extensive changes anyway ... maybe we should just get rid of the use of
pgindent altogether? its not something that I've ever seen required on
other projects I've worked
The problem is that the small ones don't apply cleanly if they don't
match the indenting in the source.
but ... if they are small, manually merging isn't that big of a deal ...
and if anyone else has been working in that code since release, there is a
chance it won't mergef cleanly ...
I have finished pgindent. We also had many old comments of the format:
/* --
* comment
* --
*/
These are now the more concise:
/*
* comment
*/
Also, comments with dashes are not wrapped nicely by pgindent. Some
comments
* Bruce Momjian [EMAIL PROTECTED] [010321 21:14] wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
and most times, those have to be merged into the source tree due to
extensive changes anyway ... maybe we should just get rid of the use of
pgindent altogether?
I think pgindent is
With RC1 nearing, when should I run pgindent? This is usually the time
I do it.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.
201 - 297 of 297 matches
Mail list logo
