Throw some low-level C scutwork at me

On Wed, Apr 29, 2009 at 01:34:19PM -0500, Andy Lester wrote:

I've got my git clone set up, a copy of GCC 4.4 (and other
compilers) at the ready, and am glad to help out on low-level scut
work. Anybody need anything done? splint? valgrind? Let me know.

Getting our Perl into shape would be Really Good(TM). :)

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Getting our Perl into shape would be Really Good(TM). :)

I will, but right now my #1 is getting some vi modelines in place so
we can all be using the same tab/space settings.

xoxo,
Andy

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance

Andy Lester wrote:

Getting our Perl into shape would be Really Good(TM). :)

I will, but right now my #1 is getting some vi modelines in place so
we can all be using the same tab/space settings.

Hasn't that been discussed before and rejected? (For one thing, plenty
of us don't use vi)

cheers

andrew

On Thu, Apr 30, 2009 at 05:39:42PM -0400, Andrew Dunstan wrote:

Andy Lester wrote:

Getting our Perl into shape would be Really Good(TM). :)

I will, but right now my #1 is getting some vi modelines in place so
we can all be using the same tab/space settings.

Hasn't that been discussed before and rejected?

Not that I know of.

(For one thing, plenty of us don't use vi)

An emacs modeline would go in a similar spot.

Apart from those two, are there other modelines we would need?

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Apr 30, 2009, at 4:39 PM, Andrew Dunstan wrote:

I will, but right now my #1 is getting some vi modelines in place
so we can all be using the same tab/space settings.

Hasn't that been discussed before and rejected? (For one thing,
plenty of us don't use vi)

For those who do use vi, it enforces proper file formatting for the
user without having to worry about local settings.

And if you're an Emacs person, you can help figure out what the
modeline should be for Emacs, and we can get that in there, too.

xoa

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance

Andy Lester <andy@petdance.com> writes:

And if you're an Emacs person, you can help figure out what the
modeline should be for Emacs, and we can get that in there, too.

If you're an Emacs person, you fix it in your ~/.emacs file so that
every .c file in the Postgres tree is automatically handled with the
correct mode. Surely vi apologists can make their editor do the same.

Let me make it perfectly clear that a patch to add either vi or emacs
decoration to every file in the tree will be rejected out of hand.
We had a similar thing for awhile with the .sgml files, and got rid of
that because it sucked ...

regards, tom lane

On Fri, May 1, 2009 at 11:23 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andy Lester <andy@petdance.com> writes:

And if you're an Emacs person, you can help figure out what the
modeline should be for Emacs, and we can get that in there, too.

If you're an Emacs person, you fix it in your ~/.emacs file so that
every .c file in the Postgres tree is automatically handled with the
correct mode.  Surely vi apologists can make their editor do the same.

Let me make it perfectly clear that a patch to add either vi or emacs
decoration to every file in the tree will be rejected out of hand.
We had a similar thing for awhile with the .sgml files, and got rid of
that because it sucked ...

For what it's worth, I agree with Tom. This sort of thing is more
annoying than useful. There are other ways to solve this problem.

Speaking of space/tab settings, one thing I'm fuzzy on is the rule for
wrapping long lines. I understand that a line that extends past 80
characters has to be wrapped, but the amount of indentation on the
continuation line doesn't appear to follow a consistent pattern - or
does it?

...Robert

Robert Haas <robertmhaas@gmail.com> writes:

Speaking of space/tab settings, one thing I'm fuzzy on is the rule for
wrapping long lines. I understand that a line that extends past 80
characters has to be wrapped, but the amount of indentation on the
continuation line doesn't appear to follow a consistent pattern - or
does it?

I tend to let emacs indent the continuation line the way it wants.
pg_indent sometimes has a slightly different theory about that, but
it usually doesn't change it enough to be a problem.

A rough rule of thumb is that pg_indent is pretty good at horizontal
whitespace decisions and absolutely terrible at vertical decisions.
Break the lines where you want them, and put blank lines where and only
where you want them, and pg_indent will clean up the rest pretty well.

Also, I don't think that 80 columns is an inviolable limit. I don't
generally like to break up error message strings just to keep the
ereport call to 80 columns, for instance. (This is partly because
I know how often it comes in handy to grep the source for particular
message strings --- and breaking the string in a random place can
defeat that.) What I do think is that the code should be easily readable
in an 80-column window. It's usually pretty obvious when a patch author
was working in a 100-or-more-column window, if you try to read it in
80 columns ...

regards, tom lane

On May 1, 2009, at 8:38 AM, Robert Haas wrote:

Speaking of space/tab settings, one thing I'm fuzzy on is the rule for
wrapping long lines. I understand that a line that extends past 80
characters has to be wrapped, but the amount of indentation on the
continuation line doesn't appear to follow a consistent pattern - or
does it?

“Perl Best Practices” recommends an indentation of 4 spaces, both for
block indentations and line continuations. Not sure what'd be best for
C, though.

Best,

David

David E. Wheeler wrote:

On May 1, 2009, at 8:38 AM, Robert Haas wrote:

Speaking of space/tab settings, one thing I'm fuzzy on is the rule for
wrapping long lines. I understand that a line that extends past 80
characters has to be wrapped, but the amount of indentation on the
continuation line doesn't appear to follow a consistent pattern - or
does it?

�Perl Best Practices� recommends an indentation of 4 spaces, both for
block indentations and line continuations. Not sure what'd be best for
C, though.

Please, let's not have a whole host of different indentation styles.
Postgres has a well established style. Let's stick to it in both perl and C.

cheers

andrew

On May 1, 2009, at 10:38 AM, Andrew Dunstan wrote:

Please, let's not have a whole host of different indentation styles.
Postgres has a well established style. Let's stick to it in both
perl and C

+1

David

On Fri, May 01, 2009 at 01:38:38PM -0400, Andrew Dunstan wrote:

David E. Wheeler wrote:

On May 1, 2009, at 8:38 AM, Robert Haas wrote:

Speaking of space/tab settings, one thing I'm fuzzy on is the rule
for wrapping long lines. I understand that a line that extends
past 80 characters has to be wrapped, but the amount of
indentation on the continuation line doesn't appear to follow a
consistent pattern - or does it?

“Perl Best Practices” recommends an indentation of 4 spaces, both
for block indentations and line continuations. Not sure what'd be
best for C, though.

Please, let's not have a whole host of different indentation styles.
Postgres has a well established style. Let's stick to it in both
perl and C.

Perl is not C, and there's no good reason to make them look the same.
We don't format SQL the same way we do C either, and that's a totally
reasonable decision.

Using idiomatic perl like this:

foreach my $element (@array) {
# clear, short, idiomatic code here
}

instead of Rube Goldberg constructs like this:

my $i;
for ($i=0; $i <= $#array; ++$i)
{
# kludges up down and sideways here
}

is a good idea because it makes it easier for Perl programmers to
maintain. It's also more efficient on the machine, for what that's
worth.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On May 1, 2009, at 10:54 AM, David Fetter wrote:

foreach my $element (@array) {
# clear, short, idiomatic code here
}

instead of Rube Goldberg constructs like this:

my $i;
for ($i=0; $i <= $#array; ++$i)
{
# kludges up down and sideways here
}

is a good idea because it makes it easier for Perl programmers to
maintain. It's also more efficient on the machine, for what that's
worth.

We were only talking about indentation, David, not the use of idioms.

Best,

David

If you're an Emacs person, you fix it in your ~/.emacs file so that
every .c file in the Postgres tree is automatically handled with the
correct mode. Surely vi apologists can make their editor do the same.

Thanks for your remarkable response. I will refer to it often for
months to come. I think it tells me quite a bit about the Postgres
world.

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance

On Fri, May 01, 2009 at 11:23:24AM -0400, Tom Lane wrote:

Andy Lester <andy@petdance.com> writes:

And if you're an Emacs person, you can help figure out what the
modeline should be for Emacs, and we can get that in there, too.

If you're an Emacs person, you fix it in your ~/.emacs file so that
every .c file in the Postgres tree is automatically handled with the
correct mode. Surely vi apologists can make their editor do the same.

Let me make it perfectly clear that a patch to add either vi or emacs
decoration to every file in the tree will be rejected out of hand.
We had a similar thing for awhile with the .sgml files, and got rid of
that because it sucked ...

Tom,

That was truly un-called-for. I don't care who you are or what you've
done because nobody gets to treat volunteers the way you did above.
You need to back off if you're not going to do anything helpful.

If you were wondering how our community gets a reputation for
repulsing outsiders, this is a classical example.

I'd appreciate your making an argument, if you're going to, on the
merits of the proposal at hand, rather than stooping to personal
insult. You know better.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Fri, 2009-05-01 at 12:09 -0700, David Fetter wrote:

I'd appreciate your making an argument, if you're going to, on the
merits of the proposal at hand, rather than stooping to personal
insult. You know better.

O.k. guys let's all take a breath here. We all have our favorite editors
and our favorite way of doing things. Frankly I think both emacs and vi
users are nuts. I found the light in joe years ago :). Regardless, I
agree with Tom that the idea of having decorators of any kind in source
or docs is a bad idea.

That being said, there is no reason why we can have a section of the
wiki that has .rc files for respective editors and environments that
conform to .Org coding conventions.

Peace.

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake@jabber.postgresql.org
Consulting, Development, Support, Training
503-667-4564 - http://www.commandprompt.com/
The PostgreSQL Company, serving since 1997

"Joshua D. Drake" <jd@commandprompt.com> writes:

That being said, there is no reason why we can have a section of the
wiki that has .rc files for respective editors and environments that
conform to .Org coding conventions.

I think we already have that in the CVS tree - look in
src/tools/editors/. Might be out of date though.

regards, tom lane

On Fri, May 01, 2009 at 12:37:19PM -0700, Joshua D. Drake wrote:

On Fri, 2009-05-01 at 12:09 -0700, David Fetter wrote:

I'd appreciate your making an argument, if you're going to, on the
merits of the proposal at hand, rather than stooping to personal
insult. You know better.

O.k. guys let's all take a breath here.

No.

Tom screwed up, and he needs to fix it.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On May 1, 2009, at 2:37 PM, Joshua D. Drake wrote:

Regardless, I
agree with Tom that the idea of having decorators of any kind in
source
or docs is a bad idea.

Why is it a bad idea? I don't understand the downside of a line or
two at the bottom of a source file.

That being said, there is no reason why we can have a section of the
wiki that has .rc files for respective editors and environments that
conform to .Org coding conventions.

I've always found it preferable to have the editors enforce the coding
standards for us, without relying on the coder do anything on his
end. I'd rather that volunteers, especially new volunteers, spend
their time and brain cycles thinking about code, not messing with
config files.

xoa

--
Andy Lester => andy@petdance.com => www.theworkinggeek.com => AIM:petdance