Re: Could we start accepting rich-text postings on the gcc lists?

[Jonathan Wakely]

On 24 November 2012 00:40, Nathan Ridge wrote:
>
> I am regular reader of several mailing lists, some of which (such as this
> one) require plain text, and some (like cdt-dev) which allow rich text.
>
> My experience has been that the formatting of messages on plain-text
> lists is consistent across the board, while on rich-text lists you get a
> mess by mixing together different formatting conventions. A prominent
> example is the formatting convention used for quoting the message you're
> replying to. Plain-text lists always use one convention: greater-than
> signs (>) before each line of the quote, one for each level of quoting.
> On rich-text lists, some messages use greater-than signs, some use a
> vertical line to the left of the text, some use a different color, etc.
> The result is a mess that's difficult to follow.

It also seems to be more common with rich text mails for people to
start their reply inside the markup of quoted text, so the reply then
appears in the same font/color/indentation as the quoted text, which
puts quite a burden on the readers to disentangle the reply from the
quoted text.

> I think rich-text works well when everyone uses the same mail client.
> For example, at a company I used to work, for everyone used Microsoft
> Outlook as their mail client, and emails were sent in rich text. There
> was no readability problem there because everyone used the same
> formatting conventions.

But everyone top-posts ... eurgh.

In my experience of a few technical lists the small benefits of being
able to show code snippets in a different font from text, or make
conservative use of bold/italics for emphasis are not enough to
warrant using rich text.

Re: Could we start accepting rich-text postings on the gcc lists?

[Ian Lance Taylor]

Diego Novillo  writes:

> Sure.  First I wanted to find out whether this requirement is just a
> technical limitation with our mailing list software.

It is not a technical limitation.  We explicitly reject HTML e-mail.  We
could accept it.

As Jonathan pointed out, accepting HTML e-mail and then displaying it in
the web archives will make us even more of a spam target than we already
are, and will mean that we will need some mechanisms for identifying and
removing spam and virus links in the web pages.

A possible compromise would be to accept HTML e-mail that has a text
alternative, and only display the text alternative in the archives.
That would also work for people who have text-only e-mail readers.  In
general that would help for people who use e-mail programs that send
HTML with text alternatives by default.  But it would fail for people
who actually use HTML formatting in a meaningful way.  And, of course,
this would require some administrative work to be done.

I don't really care one way or the other on this issue.  That said:

1) People who send HTML e-mail ought to get a bounce message, so I would
think they would be able to reform.

2) The fact that Android refuses to provide a non-HTML e-mail capability
is ridiculous but does not seem to me to be a reason for us to change
our policy.

Ian

Re: Could we start accepting rich-text postings on the gcc lists?

[Robert Dewar]

2) The fact that Android refuses to provide a non-HTML e-mail capability
is ridiculous but does not seem to me to be a reason for us to change
our policy.


Surely there are altenrative email client for Android that have plain
text capability???

Re: Could we start accepting rich-text postings on the gcc lists?

[Daniel Berlin]

On Sat, Nov 24, 2012 at 12:13 PM, Ian Lance Taylor  wrote:
> Diego Novillo  writes:
>
>> Sure.  First I wanted to find out whether this requirement is just a
>> technical limitation with our mailing list software.
>
> It is not a technical limitation.  We explicitly reject HTML e-mail.  We
> could accept it.
>
> As Jonathan pointed out, accepting HTML e-mail and then displaying it in
> the web archives will make us even more of a spam target than we already
> are, and will mean that we will need some mechanisms for identifying and
> removing spam and virus links in the web pages.

I'd love to see data on this.  As others have pointed out, almost
every other open source project accepts html email.
I went through, for example, the LLVM email archives, and i don't see
a massive amount of spam.
Do you have reason to believe our existing spam detection solution
will start to fail massively when presented with html email?
After all, if most of the HTML email is spam, something being HTML
email is a great signal for it.
>
> A possible compromise would be to accept HTML e-mail that has a text
> alternative, and only display the text alternative in the archives.
> That would also work for people who have text-only e-mail readers.  In
> general that would help for people who use e-mail programs that send
> HTML with text alternatives by default.  But it would fail for people
> who actually use HTML formatting in a meaningful way.
I have not seen html formatting used in the other open source
projects, just text/html emails.

>  And, of course,
> this would require some administrative work to be done.
>
> I don't really care one way or the other on this issue.  That said:
>
> 1) People who send HTML e-mail ought to get a bounce message, so I would
> think they would be able to reform.

At that point they probably don't care.
Honestly, any community that actively makes it hard for me to send
mail from a common email program, is a huge turn-off.
Folks can retort that we may not want users who don't want to take the
time to send non-html email.  I doubt this is actually true, since the
majority of folks i've seen are just using clients that default to
html email, and aren't doing anything obnoxious.

Note that *we* are currently rejecting multipart/alternative if it
contains text/html, even if it contains text/plain.
This is fairly obnoxious.

> 2) The fact that Android refuses to provide a non-HTML e-mail capability
> is ridiculous but does not seem to me to be a reason for us to change
> our policy.

Expect it to get worse.  Folks can say what they like, but other
communities i'm a part of, and are much larger than GCC, deal with
HTML email with zero problem.  All bouncing HTML email is really doing
is turning away some people.

In the "olden days", when html email was some shitty gobbledygook
produced by an old version of exchange, this may have made sense.  In
the days now of relatively sane multipart/alternative emails, it just
seems like folks being annoyed that the rest of the world changed.



>
> Ian

Re: Could we start accepting rich-text postings on the gcc lists?

[Daniel Berlin]

On Sat, Nov 24, 2012 at 12:47 PM, Robert Dewar  wrote:
>
>> 2) The fact that Android refuses to provide a non-HTML e-mail capability
>> is ridiculous but does not seem to me to be a reason for us to change
>> our policy.
>
>
> Surely there are altenrative email client for Android that have plain
> text capability???
>

Yes, we should expect users to change, instead of keeping up with users.

Re: Could we start accepting rich-text postings on the gcc lists?

[Robert Dewar]

On 11/24/2012 12:59 PM, Daniel Berlin wrote:

On Sat, Nov 24, 2012 at 12:47 PM, Robert Dewar  wrote:



2) The fact that Android refuses to provide a non-HTML e-mail capability
is ridiculous but does not seem to me to be a reason for us to change
our policy.



Surely there are altenrative email client for Android that have plain
text capability???



Yes, we should expect users to change, instead of keeping up with users.


Well my experience with HTML-burdened mail is awful. From people who set
ludicrous font choices, to bad color choices, to inappropriate use of
multiple fonts, to inappropriate use of colors, it's a mess.

I think it is perfectly reasonable to expect serious developers to
send text messages in text form. BTW, our experience at AdaCore, where
we get lots of email from lots of customers, users, hobbyists, and
students, sending email from all sorts
of programs, is that yes, occasionally they send us HTML burdened
email, but almost always when we ask them to adjust their mailers to
send text, they can do so without problems.

Re: Could we start accepting rich-text postings on the gcc lists?

[Frank Ch. Eigler]

Hi -

On Sat, Nov 24, 2012 at 12:58:33PM -0500, Daniel Berlin wrote:
> [...]
> I'd love to see data on this.  As others have pointed out, almost
> every other open source project accepts html email. [...]
> Do you have reason to believe our existing spam detection solution
> will start to fail massively when presented with html email? [...]

Yes.  I run a similar spamassassin setup at home as sourceware's, and
it routinely lets through spam that is disguised in HTML.  That is
after all trivial to do - font size=1 color=white or somesuch gunk.
Annoyingly, the spam's hidden bayes-countering filler goo shows up in
its full html-to-text glory in a text-based MUA.

> After all, if most of the HTML email is spam, something being HTML
> email is a great signal for it.

Dunno about "most", but "an uncomfortable amount" is right.


> [...]
> Note that *we* are currently rejecting multipart/alternative if it
> contains text/html, even if it contains text/plain.
> This is fairly obnoxious.

See above.  Spam filtering on HTML bodies is not very effective,
unless one's a gmail.  There is no mechanical way to ensure that the
multipart alternative text/plain is equivalent -- and if it were,
then it could just have been sent as is in the first place (were it
not for MUA intransigence).


- FChE

Re: Could we start accepting rich-text postings on the gcc lists?

[Jonathan Wakely]

On 24 November 2012 17:47, Robert Dewar wrote:
>
>> 2) The fact that Android refuses to provide a non-HTML e-mail capability
>> is ridiculous but does not seem to me to be a reason for us to change
>> our policy.
>
>
> Surely there are altenrative email client for Android that have plain
> text capability???

The official gmail app, which obviously integrates well with gmail and
is good in most other ways, won't send non-html mails.

I find that very annoying, but I get annoyed with the app and am not
suggesting the GCC lists should change to deal with it.

Re: Could we start accepting rich-text postings on the gcc lists?

[Robert Dewar]

On 11/24/2012 1:13 PM, Jonathan Wakely wrote:


The official gmail app, which obviously integrates well with gmail and
is good in most other ways, won't send non-html mails.


There seem to be a variety of alternatives


http://www.tested.com/tech/android/3110-the-best-alternative-android-apps-to-manage-all-your-email/


K-9 is a free software client that looks interesting


I find that very annoying, but I get annoyed with the app and am not
suggesting the GCC lists should change to deal with it.

Re: Could we start accepting rich-text postings on the gcc lists?

[Ruben Safir]

On Sat, Nov 24, 2012 at 12:58:33PM -0500, Daniel Berlin wrote:
> On Sat, Nov 24, 2012 at 12:13 PM, Ian Lance Taylor  wrote:
> > Diego Novillo  writes:
> >
> >> Sure.  First I wanted to find out whether this requirement is just a
> >> technical limitation with our mailing list software.
> >
> > It is not a technical limitation.  We explicitly reject HTML e-mail.  We
> > could accept it.
> >
> > As Jonathan pointed out, accepting HTML e-mail and then displaying it in
> > the web archives will make us even more of a spam target than we already
> > are, and will mean that we will need some mechanisms for identifying and
> > removing spam and virus links in the web pages.
> 
> I'd love to see data on this.  

Go generate it with you own mailing list and let us know.

> As others have pointed out, almost
> every other open source project accepts html email.


Wrong

And it is silly to burden everyone else with the bulk and storage of
that nonsense, let alone the multiple fonts and standards and CSS style
sheets and missappropriate images and links.

Its time for users to get with it and not use every stupid thing shoved
down their through.  And PLEASE tell me you write you C programming in
adroind using your thumb prints.

Ruben

-- 
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like 
Atlantis, reaches mythological proportions in the mind of the world  - RI Safir 
1998

http://fairuse.nylxs.com  DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our 
own cultural heritage -- we need the ability to participate in our own society."

"> I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been 
attached at the hip since the 1st dynasty in Ancient Egypt.  I guess you missed 
that one."

© Copyright for the Digital Millennium

Re: Could we start accepting rich-text postings on the gcc lists?

[Ruben Safir]

> 
> Yes, we should expect users to change, instead of keeping up with users.



No - we shouldn't punish developers by making them use stupid mime
translational servces that breaks the replying mechanism in EMACS and
mutt because they are stupidly try to post to a tech mailing list on
their android as if it is facebook.

Blah.

Ruben
-- 
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

gcc-4.7-20121124 is now available

[gccadmin]

Snapshot gcc-4.7-20121124 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20121124/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch 
revision 193784

You'll find:

 gcc-4.7-20121124.tar.bz2 Complete GCC

  MD5=cc74983930400700ceb6c810d3f289e4
  SHA1=98f14240d2604fcf5cb8c89acc408f93426390e3

Diffs from 4.7-20121117 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.7
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.

Re: RFC - Alternatives to gengtype

[Diego Novillo]

Thanks for all the responses.

I have created a wiki page to track this proposal:
http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives

It is also indexed from the main improvements wiki:
http://gcc.gnu.org/wiki/ImprovementProjects

Given the number of choices we have in this proposal, I've added a
table that keeps track of how popular each of the different choices
are.  If you care about this topic, please respond, and/or update the
wiki with your "vote".

So far, the clear winner is pool allocation, followed by
manually-implemented GC marking and reference-counted pointers.  We
still have no clear idea of what style of PCH people prefer.


Thanks.  Diego.

Re: Simplifying Gimple Generation

[Diego Novillo]

Thanks for all the responses.

I have created a wiki page to track this proposal:
http://gcc.gnu.org/wiki/cxx-conversion/gimple-generation

It is also indexed from the main improvements wiki:
http://gcc.gnu.org/wiki/ImprovementProjects


Thanks.  Diego.

Re: Could we start accepting rich-text postings on the gcc lists?

[Daniel Berlin]

Sorry dude, I don't engage in substantive conversation with abusive trolls.


On Sat, Nov 24, 2012 at 2:43 PM, Ruben Safir  wrote:
> On Sat, Nov 24, 2012 at 12:58:33PM -0500, Daniel Berlin wrote:
>> On Sat, Nov 24, 2012 at 12:13 PM, Ian Lance Taylor  wrote:
>> > Diego Novillo  writes:
>> >
>> >> Sure.  First I wanted to find out whether this requirement is just a
>> >> technical limitation with our mailing list software.
>> >
>> > It is not a technical limitation.  We explicitly reject HTML e-mail.  We
>> > could accept it.
>> >
>> > As Jonathan pointed out, accepting HTML e-mail and then displaying it in
>> > the web archives will make us even more of a spam target than we already
>> > are, and will mean that we will need some mechanisms for identifying and
>> > removing spam and virus links in the web pages.
>>
>> I'd love to see data on this.
>
> Go generate it with you own mailing list and let us know.

>
>> As others have pointed out, almost
>> every other open source project accepts html email.
>
>
> Wrong
>
> And it is silly to burden everyone else with the bulk and storage of
> that nonsense, let alone the multiple fonts and standards and CSS style
> sheets and missappropriate images and links.
>
> Its time for users to get with it and not use every stupid thing shoved
> down their through.  And PLEASE tell me you write you C programming in
> adroind using your thumb prints.
>
> Ruben
>
> --
> http://www.mrbrklyn.com - Interesting Stuff
> http://www.nylxs.com - Leadership Development in Free Software
>
> So many immigrant groups have swept through our town that Brooklyn, like 
> Atlantis, reaches mythological proportions in the mind of the world  - RI 
> Safir 1998
>
> http://fairuse.nylxs.com  DRM is THEFT - We are the STAKEHOLDERS - RI Safir 
> 2002
>
> "Yeah - I write Free Software...so SUE ME"
>
> "The tremendous problem we face is that we are becoming sharecroppers to our 
> own cultural heritage -- we need the ability to participate in our own 
> society."
>
> "> I'm an engineer. I choose the best tool for the job, politics be damned.<
> You must be a stupid engineer then, because politcs and technology have been 
> attached at the hip since the 1st dynasty in Ancient Egypt.  I guess you 
> missed that one."
>
> © Copyright for the Digital Millennium

Re: Could we start accepting rich-text postings on the gcc lists?

[Ruben Safir]

Sorry - 
I wasn't really interested in debating this any more than one should
debate the effects of having your head squashed if you hang your head
over the rail when the IRT is coming.

It just gets squashed.


BTW, as well as learning to use text for email, also please learn to
trim the CC list

Ruben

Reorg a reorg.c comment

[Steven Bosscher]

Hello,

A "Not yet implemented" comment in reorg.c discusses conditional
execution. The comment already existed in the earliest revision in the
repository (r99) so it pre-dates the conditional execution framework
now used by the "Acorn RISC Machine" (better known as ARM nowadays :-)
and how HP-PA can do something similar.

The comment in reorg.c looks out of place now, and the ability of
PA-RISC to nullify instructions isn't mentioned anywhere. AFAICT GCC
does not exploit this ability so I've added a comment for a suggested
improvement in pa.md.

OK for trunk?

Ciao!
Steven


* reorg.c: Remove obsolete comment.
* config/pa/pa.md: Add comment explaining how PA-RISC allows most
instructions to nullify the immediately following instruction.

Index: reorg.c
===
--- reorg.c (revision 193787)
+++ reorg.c (working copy)
@@ -100,16 +100,7 @@ along with GCC; see the file COPYING3.
delay slot.  In that case, we point each insn at the other with REG_CC_USER
and REG_CC_SETTER notes.  Note that these restrictions affect very few
machines because most RISC machines with delay slots will not use CC0
-   (the RT is the only known exception at this point).
-
-   Not yet implemented:
-
-   The Acorn Risc Machine can conditionally execute most insns, so
-   it is profitable to move single insns into a position to execute
-   based on the condition code of the previous insn.
-
-   The HP-PA can conditionally nullify insns, providing a similar
-   effect to the ARM, differing mostly in which insn is "in charge".  */
+   (the RT is the only known exception at this point).  */

 #include "config.h"
 #include "system.h"
Index: config/pa/pa.md
===
--- config/pa/pa.md (revision 193786)
+++ config/pa/pa.md (working copy)
@@ -1,6 +1,5 @@
 ;;- Machine description for HP PA-RISC architecture for GCC compiler
-;;   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001,
-;;   2002, 2003, 2004, 2005, 2006, 2007, 2008, 2010
+;;   Copyright (C) 1992-2012
 ;;   Free Software Foundation, Inc.
 ;;   Contributed by the Center for Software Science at the University
 ;;   of Utah.
@@ -21,8 +20,31 @@
 ;; along with GCC; see the file COPYING3.  If not see
 ;; .

-;; This gcc Version 2 machine description is inspired by sparc.md and
-;; mips.md.
+;; This machine description is inspired by sparc.md and (to a lesser
+;; extend) mips.md.
+
+;; Possible improvements, if anyone is still interested in working on
+;; improving this machine description in 2012:
+;;
+;; * With PA2.0, most computational instructions can conditionally nullify
+;;   the execution of the following instruction.  Nullification is performed
+;;   conditionally based on the outcome of a test specified in the opcode.
+;;   The test result is stored in PSW[N] and can only be used to nullify the
+;;   instruction following immediately after the test.  For example:
+;;
+;; ldi 10,%r26 ldi 10,%r26
+;; ldi 5,%r25  ldi 5,%r25
+;; sub,< %r26,%r25,%r28sub,> %r26,%r25,%r28
+;; sub   %r28,%r25,%r28sub   %r28,%r25,%r28
+;; ; %r28 == 0 ; %r28 == 5
+;;
+;;   This could be tricky to implement because the result of the test has
+;;   to be propagated one instruction forward, which, in the worst case,
+;;   would involve (1) adding a fake register for PSW[N]; (2) adding the
+;;   variants of the computational instructions that set or consume this
+;;   fake register.  The cond_exec infrastructure is probably not helpful
+;;   for this.
+;;

 ;;- See file "rtl.def" for documentation on define_insn, match_*, et. al.