Re: style convention: /*foo_p=*/ to annotate bool arguments

2016-10-06 Thread David Brown
On 05/10/16 22:24, Florian Weimer wrote:
> * David Brown:
> 
>> Far and away the best solution would be for C++ to support named
>> parameters or named arguments:
>>
>> 
>>
>> Then you could write:
>>
>>  foo(1, 2, bar_p: true);
>>
>> You could also write
>>
>>  foo(y: 2, bar_p: true, x: 1)
>>
>> and get the same call.
>>
>> It is always much better if you can put something in code rather than a
>> comment.
> 
> True, but I don't think this is possible because function argument
> names are explicitly *not* part of the API today (and are often
> mangled in public header files, if they are included at all).

Why is that?  I have always felt that you should have all the required
information to use a function in its declaration in the header - you
should not have to look up the definition unless you want to know /how/
it works.  And in order to know how to use a function, you need to know
what the parameters are - when that can be communicated through their
name, there is no need to clutter the file with extra comments.

But it sounds like there was an active decision not to include argument
names in header declarations in gcc code - and I am curious to know the
basis for that.

> 
> Something analogous to std::initializer_list, but for C99 designated
> initializer syntax might be more acceptible.  So in your example:
> 
>   foo({.y = 2, .bar_p = true, .x = 1})

Are you thinking here of making foo a function that takes a single
struct argument, or as a general method for named parameters as an
alternative syntax to "foo(y: 2, bar_p: true, x: 1)" ?  Personally, I
would prefer to drop the brackets "foo(.y = 2, .bar_p = true, .x = 1)" -
I think that would be nicer than either the N4172 syntax or the syntax
with brackets.  I had merely suggested the N4172 choice of a colon
syntax because it is a lot more likely that a proper C++ feature
proposal gets implemented than a suggestion in a mailing list post!

But unless it is realistic that gcc will get named parameter support in
C and/or C++ (either as an extension, or due to a future C or C++
language standard), then a discussion about these details is just
bikeshedding.

> 
> The advantage is that functions supporting this invocation style would
> have to be marked explicitly in the sources, so there would not be an
> accidental source code dependency on a non-portable aspect of system
> header files.
> 


I suppose that even if gcc were to support named parameters or other
great new features, you couldn't use those features in the source code
for gcc without causing a chicken-and-egg problem.



Re: Repository for the conversion machinery

2016-10-06 Thread Joseph Myers
On Thu, 27 Aug 2015, Eric S. Raymond wrote:

> I've made it available at:
> 
> http://thyrsus.com/gitweb/?p=gcc-conversion.git

What happened with this repository?  Is it somewhere else now?  Pulling in 
my clone of git://thyrsus.com/repositories/gcc-conversion.git has produced 
"thyrsus.com[0: 71.162.243.5]: errno=Connection refused" errors for 
several months now.  (The most recent commit I have in my clone is

commit c9f938a379269f5b9ec861819cc226573a68dad8
Author: Jason Merrill 
Date:   Sat Sep 5 13:30:02 2015 -0400

Use --legacy.

).  I noted various author map additions and one correction in 
 - there are of course 
further new committers since February that will require further authors 
map updates.

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: Repository for the conversion machinery

2016-10-06 Thread Eric S. Raymond
Joseph Myers :
> On Thu, 27 Aug 2015, Eric S. Raymond wrote:
> 
> > I've made it available at:
> > 
> > http://thyrsus.com/gitweb/?p=gcc-conversion.git
> 
> What happened with this repository?  Is it somewhere else now?  Pulling in 
> my clone of git://thyrsus.com/repositories/gcc-conversion.git has produced 
> "thyrsus.com[0: 71.162.243.5]: errno=Connection refused" errors for 
> several months now.  (The most recent commit I have in my clone is
> 
> commit c9f938a379269f5b9ec861819cc226573a68dad8
> Author: Jason Merrill 
> Date:   Sat Sep 5 13:30:02 2015 -0400
> 
> Use --legacy.
> 
> ).  I noted various author map additions and one correction in 
>  - there are of course 
> further new committers since February that will require further authors 
> map updates.
> 
> -- 
> Joseph S. Myers
> jos...@codesourcery.com

I thought the gcc conversion was done.

I can make the repository available again if it's needed.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond


Re: Repository for the conversion machinery

2016-10-06 Thread Joseph Myers
On Thu, 6 Oct 2016, Eric S. Raymond wrote:

> I thought the gcc conversion was done.
> 
> I can make the repository available again if it's needed.

The conversion got stalled (I'm not sure why; maybe just Jason being busy 
with other things) but is still intended (I'm not sure for when), so yes 
the repository is still needed.

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: Repository for the conversion machinery

2016-10-06 Thread Eric S. Raymond
Joseph Myers :
> On Thu, 6 Oct 2016, Eric S. Raymond wrote:
> 
> > I thought the gcc conversion was done.
> > 
> > I can make the repository available again if it's needed.
> 
> The conversion got stalled (I'm not sure why; maybe just Jason being busy 
> with other things) but is still intended (I'm not sure for when), so yes 
> the repository is still needed.

I was unaware of this.  I thought Jason had gotten the bit in his teeth
and finished it while I was off doing other things.

(I'm sorry for not paying closer attention, but leading the project to fix NTP
has eaten almost all my bandwidth gor most of the last two years.)

What do we do to get this restarted?  I'll make the conversion-machinery
repo visible again; what's the step after that?
-- 
http://www.catb.org/~esr/";>Eric S. Raymond


Re: Repository for the conversion machinery

2016-10-06 Thread Jason Merrill
On Thu, Oct 6, 2016 at 1:19 PM, Eric S. Raymond  wrote:
> Joseph Myers :
>> On Thu, 6 Oct 2016, Eric S. Raymond wrote:
>>
>> > I thought the gcc conversion was done.
>> >
>> > I can make the repository available again if it's needed.
>>
>> The conversion got stalled (I'm not sure why; maybe just Jason being busy
>> with other things) but is still intended (I'm not sure for when), so yes
>> the repository is still needed.
>
> I was unaware of this.  I thought Jason had gotten the bit in his teeth
> and finished it while I was off doing other things.

After I ran into a couple of reposurgeon bugs and didn't hear back
from you, I started investigating rewriting the existing git svn
mirror with git filter-branch instead.  That seems an attractive
option, but not long afterward I needed to shift focus to front end
development and decided to put off the conversion until the next stage
1.  And here we are coming toward the end of that stage 1 and I
haven't found time for it yet, and am not likely to before the end of
this stage 1.

> (I'm sorry for not paying closer attention, but leading the project to fix NTP
> has eaten almost all my bandwidth for most of the last two years.)
>
> What do we do to get this restarted?  I'll make the conversion-machinery
> repo visible again; what's the step after that?

As Joseph mentions, we should update the user map.

After that, I had a reposurgeon conversion of the website done apart
from the hooks, and could update that and put it in place as a good
prelude to converting the sources.

We should also reopen discussion of workflow and branch policies.  One
concern I have about the git conversion is that gcc.gnu.org already
refuses git connections fairly frequently due to overloading, and I'm
afraid that will become much more common when current SVN users switch
over.

Jason


Re: Repository for the conversion machinery

2016-10-06 Thread Joseph Myers
On Thu, 6 Oct 2016, Jason Merrill wrote:

> After I ran into a couple of reposurgeon bugs and didn't hear back
> from you, I started investigating rewriting the existing git svn
> mirror with git filter-branch instead.  That seems an attractive
> option, but not long afterward I needed to shift focus to front end

I've used both git-svn (sometimes with git filter-branch) and reposurgeon 
for repository conversions.  My experience is that if there's anything at 
all complicated or messy about the history, using git-svn for the 
conversion is not a good idea, so I don't think that's an attractive 
option at all.  (The non-rewritten git-svn history can be kept alongside 
the reposurgeon conversion using the git fetch command I gave in 
, so existing commit 
references remain meaningful.)

> We should also reopen discussion of workflow and branch policies.  One

There's very little there that should be done before the conversion.  We 
only need enough policy to set up hooks and repository configuration.  A 
starting point would be no non-fast-forward ref updates, either no ref 
deletions or ref deletions restricted to some defined namespace for user 
branches, commit mails to gcc-cvs continue as at present (showing the 
commit message and list of changed files, but not the full diffs), other 
hook actions such as Bugzilla updates continue as at present, all commit 
policies continue as at present.  I think people should be encouraged to 
write git-style commit messages with a meaningful summary line followed by 
something like the description in a mailing list posting of a patch, but I 
think that's a good idea independent of the conversion.

> concern I have about the git conversion is that gcc.gnu.org already
> refuses git connections fairly frequently due to overloading, and I'm
> afraid that will become much more common when current SVN users switch
> over.

That's for anonymous connections, not for git over ssh; I don't think it 
should block the conversion.  I think it's been a while since the hardware 
was refreshed, maybe it's time for work on new hardware (with or without 
an OS update to RHEL 7) to start?  (The more cores the hardware has, the 
higher the load threshold for refusing connections can be.)

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: Repository for the conversion machinery

2016-10-06 Thread Frank Ch. Eigler
Jason Merrill  writes:

> [...]  gcc.gnu.org already refuses git connections fairly frequently
> due to overloading [...]

With the corresponding reduction in cpu load from svn users, plus the
ready adjustability of those xinetd thresholds, please don't let that
hold you back.

- FChE


gcc-6-20161006 is now available

2016-10-06 Thread gccadmin
Snapshot gcc-6-20161006 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/6-20161006/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch 
revision 240845

You'll find:

 gcc-6-20161006.tar.bz2   Complete GCC

  MD5=32c206fe54c8be017072ee5963de055d
  SHA1=c824e1ee457df11735e9a15233014c6bbee3cf90

Diffs from 6-20160929 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.