Emacs and GFortran

Emacs and GFortran

[Angelo Graziosi]

I would ask if there is a way to integrate Emacs with GFortran so that in
case of compiler error one can jump to the line wher the error is born.

This works with G77, GCC and G++ but not with GFortran.




Thanks,

   Angelo.

Re: Emacs and GFortran

[Stefan Monnier]

> I would ask if there is a way to integrate Emacs with GFortran so that in
> case of compiler error one can jump to the line wher the error is born.

> This works with G77, GCC and G++ but not with GFortran.

Does that mean that GFortran does not use the standard GNU error format?
That would be unfortunate (and may be better fixed on GFortran's side).
Could you show us some sample error/warning messages?


        Stefan

Re: Emacs and GFortran

[Angelo Graziosi]

I do not know if we are speaking of the same thing.

I refer to the possibility to use Emacs like an IDE with GFortran.

I will try to be more clear with this example.

-------------------------------------
$ cat hello.F
      program hello
      implicit none
      write(*,) 'Hello!'
      end
-------------------------------------

In Emacs:

M-x compile
g77 hello.F

----------------- *compilation* ----------------
-*- mode: compilation; default-directory: "/tmp/" -*-
Compilation started at Mon Oct 30 15:59:21

g77 hello.F
hello.F: In program `hello':
hello.F:3:                                       <===
         write(*,) 'Hello!'
                 ^
Expression at (^) has incorrect data type or rank for its context

Compilation exited abnormally with code 1 at Mon Oct 30 15:59:28
----------------

Now clicking with mouse-1 (on 'hello.F:3' in '<===') jumps to line 3 so we
can examine where the compilation fails (Image a multifile application
with thousands of line of code).


Now using GFortran


M-x compile
gfortran hello.F

----------------- *compilation* ----------------
-*- mode: compilation; default-directory: "/tmp/" -*-
Compilation started at Mon Oct 30 16:10:09

gfortran hello.F
 In file hello.F:3

      write(*,) 'Hello!'                                                
             1
Error: Syntax error in WRITE statement at (1)

Compilation exited abnormally with code 1 at Mon Oct 30 16:10:12
------------------

But we cannot jump to the wrong line clicking with mouse, we only know
that the error occurs at line 3 which we reach manually.


Obviously this happens even if one uses pure F95 code.


   Angelo.


On Mon, 30 Oct 2006, Stefan Monnier wrote:

> > I would ask if there is a way to integrate Emacs with GFortran so that in
> > case of compiler error one can jump to the line wher the error is born.
> 
> > This works with G77, GCC and G++ but not with GFortran.
> 
> Does that mean that GFortran does not use the standard GNU error format?
> That would be unfortunate (and may be better fixed on GFortran's side).
> Could you show us some sample error/warning messages?
> 
> 
>         Stefan
> 

Re: Emacs and GFortran

[Stefan Monnier]

> I do not know if we are speaking of the same thing.

We are.

> hello.F:3:                                       <===

This is the error message using the standard GNU format
"<file>:<filenb>:<txt>".

>  In file hello.F:3

This uses a gratuitously different format.  Please complain to the GFortran
authors about it.  Maybe they have a good reason for it, of course, in which
case we'd like to know about it.  But otherwise, they should change it to
follow GNU standards.


        Stefan

Re: Emacs and GFortran

[Steve Kargl]

On Mon, Oct 30, 2006 at 10:38:20AM -0500, Stefan Monnier wrote:
> 
> This uses a gratuitously different format.  Please complain to the GFortran
> authors about it.  Maybe they have a good reason for it, of course, in which
> case we'd like to know about it.  But otherwise, they should change it to
> follow GNU standards.
> 

Please do not complain to the gfortran developers.  This
is an emacs issue.  Issues with emacs are off-topic.
Write the needed lisp to parse gfortran's error message.

-- 
Steve

Re: Emacs and GFortran

[François-Xavier Coudert]

> i think we should change.  it is not just emacs...vi
> has a similar function (which i can never remember..)

I think the current error message format is possible to parse, so it's
just that people who want to parse it have to write the appropriate
code.

Frankly, I strongly prefer the current error formating.

FX

Re: Emacs and GFortran

[Stefan Monnier]

>> This uses a gratuitously different format.  Please complain to the GFortran
>> authors about it.  Maybe they have a good reason for it, of course, in which
>> case we'd like to know about it.  But otherwise, they should change it to
>> follow GNU standards.

> Please do not complain to the gfortran developers.  This
> is an emacs issue.  Issues with emacs are off-topic.
> Write the needed lisp to parse gfortran's error message.

Note that my above paragraph makes no reference to Emacs.  It's not
a coincidence.  Standards exist for a reason.


        Stefan

Re: Emacs and GFortran

[Richard Stallman]

    I would ask if there is a way to integrate Emacs with GFortran so that in
    case of compiler error one can jump to the line wher the error is born.

If the error messages have the standard GNU form, then it should work.
If not, then probably GFortran should be fixed to put its error
messages in standard form.

Re: Emacs and GFortran

[Angelo Graziosi]

Tobias Burnus wrote:

> By the way, g95 has the same problem.

Adding


(eval-after-load "compile"
   '(setq compilation-error-regexp-alist
       (cons '("^In file \\(.+\\):\\([0-9]+\\)" 1 2)
          compilation-error-regexp-alist)))


in .emacs solves it.


So, is there something similar for GFortran ?


  Angelo.

Re: Emacs and GFortran

[Tobias Burnus]

Hi,

Angelo Graziosi wrote:
>> By the way, g95 has the same problem.
>>     
>
> Adding
>
> (eval-after-load "compile"
>    '(setq compilation-error-regexp-alist
>        (cons '("^In file \\(.+\\):\\([0-9]+\\)" 1 2)
>           compilation-error-regexp-alist)))
>
> in .emacs solves it.
>
>
> So, is there something similar for GFortran ?
>   
Doesn't this work for gfortran? I think the output is the same:
"In file <filename>:<line>".
Thus it should work with both compilers. (It probably predates the
g95-gfortran split.)

Tobias

Re: Emacs and GFortran

[Steve Kargl]

On Mon, Oct 30, 2006 at 02:16:57PM -0500, Richard Stallman wrote:
>     I would ask if there is a way to integrate Emacs with GFortran so that in
>     case of compiler error one can jump to the line wher the error is born.
> 
> If the error messages have the standard GNU form, then it should work.
> If not, then probably GFortran should be fixed to put its error
> messages in standard form.

I disagree.  Gfortran's error mechanism can span multiple lines.
The GNU form can't.

-- 
Steve

Re: Emacs and GFortran

[Nick Roberts]

Angelo Graziosi writes:
 > 
 > Tobias Burnus wrote:
 > 
 > > By the way, g95 has the same problem.
 > 
 > Adding
 > 
 > 
 > (eval-after-load "compile"
 >    '(setq compilation-error-regexp-alist
 >        (cons '("^In file \\(.+\\):\\([0-9]+\\)" 1 2)
 >           compilation-error-regexp-alist)))
 > 
 > 
 > in .emacs solves it.

The original error message you posted had column number information in the
error output too:

   gfortran hello.F
    In file hello.F:3

         write(*,) 'Hello!'                                                
                1
   Error: Syntax error in WRITE statement at (1)

it would be nice to be able to use this too.  I think gcc outputs kind of
information as something like:

hello.c:3:13: error: blah, blah, blah...

Emacs can then place the cursor in the relevant column when visiting an error
(and Vim probably does something similar too).

Regardless of whose issue it is, it would seem a good idea to co-ordinate
between projects (gfortan/gcc/emacs/vim...).

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs and GFortran

[Miles Bader]

"François-Xavier Coudert" <fxcoudert@gmail.com> writes:
> I think the current error message format is possible to parse, so it's
> just that people who want to parse it have to write the appropriate
> code.

As Stefan said, standards exist for a reason -- even if Emacs adds the
required patterns to match gfortran's idiosyncratic output format, what
about vim?  Or teds-funky-editor which only sees a release every 10
years?  Or other tools/utilities which want to semi-parse error output?

It's very hard to make sure every tool knows about every format, so
having at least some minimal standardization _really_ helps.

> Frankly, I strongly prefer the current error formating.

It is not necessary to completely change the format, nor to make it
human unfriendly, merely make sure that key info (filename/line/colum)
is available in a standard form.

I.e., keep the verbose "squishy good for humans" stuff (e.g. showing a
little picture of where the error occurred), but change the numeric info
into a standard form.  As Stefan mentioned, the difference seems rather
gratuitous (" In file F:L" versus "F:L:").

I guess the result would look something like:

   gfortran hello.F
   hello.F:3:

         write(*,) 'Hello!'                                                
                1
   Error: Syntax error in WRITE statement at (1)

[Which works fine with Emacs.]

-Miles

-- 
I'd rather be consing.

Re: Emacs and GFortran

[Steve Kargl]

On Tue, Oct 31, 2006 at 10:59:11AM +0900, Miles Bader wrote:
> "Fran?ois-Xavier Coudert" <fxcoudert@gmail.com> writes:
> 
> > Frankly, I strongly prefer the current error formating.

I agree with FX.

> 
> It is not necessary to completely change the format, nor to make it
> human unfriendly, merely make sure that key info (filename/line/colum)
> is available in a standard form.
> 
> I.e., keep the verbose "squishy good for humans" stuff (e.g. showing a
> little picture of where the error occurred), but change the numeric info
> into a standard form.  As Stefan mentioned, the difference seems rather
> gratuitous (" In file F:L" versus "F:L:").
> 
 
Are you aware that gfortran can report errors that span multiple lines?

-- 
Steve

Re: Emacs and GFortran

[Miles Bader]

Steve Kargl <sgk@troutmask.apl.washington.edu> writes:
>> > Frankly, I strongly prefer the current error formating.
>
> I agree with FX.

So, _every single detail_ of the current error message format is sacred?

What's being suggested is a fairly minor change -- the bulk of the error
messages would remain exactly the same.

[Surely you recognize the worth of such standardization?]

> Are you aware that gfortran can report errors that span multiple lines?

All we want is enough information to get close; the first line will do
in such cases.

-Miles
-- 
"Suppose He doesn't give a shit?  Suppose there is a God but He
just doesn't give a shit?"  [George Carlin]

Re: Emacs and GFortran

[Miles Bader]

Steve Kargl <sgk@troutmask.apl.washington.edu> writes:
> I disagree.  Gfortran's error mechanism can span multiple lines.
> The GNU form can't.

It is _not_ being suggested that all the gfortan error info be replaced
with something worse.

It is simply being requested that any information which has a "standard"
form be presented in (at least) that way -- additional information for
humans is of course good too, and can remain in the current format.

-Miles

-- 
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete.  [Marshall McLuhan, Understanding Media, 1964]

Re: Emacs and GFortran

[Steve Kargl]

On Tue, Oct 31, 2006 at 12:49:09PM +0900, Miles Bader wrote:
> Steve Kargl <sgk@troutmask.apl.washington.edu> writes:
> >> > Frankly, I strongly prefer the current error formating.
> >
> > I agree with FX.
> 
> So, _every single detail_ of the current error message format is sacred?

Of course not!   OTOH, with so little time and so few people
working of making gfortran actuallyi work as a compiler, these
little suggest are way of the radar.  

> What's being suggested is a fairly minor change -- the bulk of the error
> messages would remain exactly the same.

You apparently have never looked at the source code or the
gfortran testsuite.  You underestimate the impact of your
demand.

> [Surely you recognize the worth of such standardization?]

Don't be condescending!  I've spent the last 3 to 4 years 
fixing gfortran either through my own patches or reviewing 
the patches of others. 

> > Are you aware that gfortran can report errors that span multiple lines?
> 
> All we want is enough information to get close; the first line will do
> in such cases.

You have the source code.  Get a copyright assignment.
Submit a patch.

-- 
Steve

Re: Emacs and GFortran

[Eli Zaretskii]

> Date: Mon, 30 Oct 2006 13:13:04 -0800
> From: Steve Kargl <sgk@troutmask.apl.washington.edu>
> Cc: Angelo Graziosi <Angelo.Graziosi@roma1.infn.it>, fortran@gcc.gnu.org,
> 	emacs-devel@gnu.org
> > 
> > If the error messages have the standard GNU form, then it should work.
> > If not, then probably GFortran should be fixed to put its error
> > messages in standard form.
> 
> I disagree.  Gfortran's error mechanism can span multiple lines.
> The GNU form can't.

I believe there's a misunderstanding about what ``the GNU standard''
is; please read the latest messages that indicate that all we need is
the standard form of identifying the file and line of the problem.

If you still think this will hamper GFortran, please show some
specific examples of what your format allows, while the ``GNU
standard'' (in the meaning I mentioned above) does not.

(Btw, I think Emacs supports multi-line messages just fine, if it's
relevant.)

Re: Emacs and GFortran

[Steve Kargl]

On Tue, Oct 31, 2006 at 06:31:54AM +0200, Eli Zaretskii wrote:
> If you still think this will hamper GFortran, please show some
> specific examples of what your format allows, while the ``GNU
> standard'' (in the meaning I mentioned above) does not.

UTSL

-- 
Steve

Re: Emacs and GFortran

[stephen]

"sk" == Steve Kargl writes:

 sk> On Tue, Oct 31, 2006 at 10:59:11AM +0900, Miles Bader wrote:
 sk> > "Fran?ois-Xavier Coudert" <fxcoudert@gmail.com> writes:
 sk> > 
 sk> > > Frankly, I strongly prefer the current error formating.

 sk> I agree with FX.

"Prefer"?  Me too.  But it's not worth giving up the GNU standard
error format, which AFAIK only specifies the first line.

When there's a widely-used standard in question, "worse is better" if
better doesn't conform.  This particular standard is respected by more
than just Emacs.

 > Are you aware that gfortran can report errors that span multiple lines?

That's irrelevant; there are any number of ways to format arbitrarily
complex error information and remain GNU-conforming.

With respect to this capability per se, while it sounds like a useful
innovation, you'd have to show me an example to convince me that most
messages concerning errors that span multiple lines would not benefit
greatly from being unpacked into a series of messages explaining line
by line what the compiler thinks went wrong.  If so, there's very
little cost to a simple terse header that conforms to the standard.
The readability cost is actually greater for messages that refer to
only one line, IMO!

Note that gcc does things more powerful than that already, without
extending the error syntax standard.  For example it will warn about a
redefined macro on one line, and then tell you where the original
definition was, even in a different file, on the next.

Re: Emacs and GFortran

[Stefan Monnier]

>> I would ask if there is a way to integrate Emacs with GFortran so that in
>> case of compiler error one can jump to the line wher the error is born.
>> 
>> If the error messages have the standard GNU form, then it should work.
>> If not, then probably GFortran should be fixed to put its error
>> messages in standard form.

> I disagree.  Gfortran's error mechanism can span multiple lines.
> The GNU form can't.

AFAIK the GNU form *can* do it with the following syntax:

   <file>:<startline>-<endline>:<message>

and if you want to add column info, that can be done as well:

   <file>:<startline>.<startcol>-<endline>.<endcol>:<message>


-- Stefan

Re: Emacs and GFortran

[FX Coudert]

> AFAIK the GNU form *can* do it with the following syntax:
>
>    <file>:<startline>-<endline>:<message>
>
> and if you want to add column info, that can be done as well:
>
>    <file>:<startline>.<startcol>-<endline>.<endcol>:<message>

Which, you'll agree is not very usefull is the error arises from the  
conjunction of 3 different statements at lines 5, 19 and 1027.

As for the change for the first line from "In file foo.f90:180:" to  
"foo.f90:180:", could you please file a bug-report about that?  
(http://gcc.gnu.org/bugzilla/ , under component "fortran", with  
severity "enhancement") I think it can be done at some point before  
the 4.3 release.

FX

Re: Emacs and GFortran

[Angelo Graziosi]

-------------------------------------
$ cat hello.F
      program hello
      implicit none
      write(*,) 'Hello!'
      end



$ g77 hello.F       
hello.F: In program `hello':
hello.F:3:                                           (<==)
         write(*,) 'Hello!'
                 ^
Expression at (^) has incorrect data type or rank for its context




$ gfortran hello.F
 In file hello.F:3

      write(*,) 'Hello!'                                                
             1
Error: Syntax error in WRITE statement at (1)

-------------------------------------


The only difference between G77 anf GFortran seems the line (<==).

Why is it so hard for GFortran add that line?


Cheers,

  Angelo.


On Mon, 30 Oct 2006, Steve Kargl wrote:

> On Mon, Oct 30, 2006 at 02:16:57PM -0500, Richard Stallman wrote:
> >     I would ask if there is a way to integrate Emacs with GFortran so that in
> >     case of compiler error one can jump to the line wher the error is born.
> > 
> > If the error messages have the standard GNU form, then it should work.
> > If not, then probably GFortran should be fixed to put its error
> > messages in standard form.
> 
> I disagree.  Gfortran's error mechanism can span multiple lines.
> The GNU form can't.
> 
> -- 
> Steve
> 

Re: Emacs and GFortran

[Angelo Graziosi]

The only difference between G95 and GFortran is a blank space at (***):

----------------------------------------------------------
$ g95 hello.F
In file hello.F:3                                  (***)

      write(*,) 'Hello!'
              1
Error: Syntax error in WRITE statement at (1)


$ gfc hello.F
 In file hello.F:3                                (***)

      write(*,) 'Hello!'
             1
Error: Syntax error in WRITE statement at (1)
-----------------------------------------------------------


So is there a way to adjust .emacs?


    Angelo.



On Mon, 30 Oct 2006, Tobias Burnus wrote:

> Hi,
> 
> Angelo Graziosi wrote:
> >> By the way, g95 has the same problem.
> >>     
> >
> > Adding
> >
> > (eval-after-load "compile"
> >    '(setq compilation-error-regexp-alist
> >        (cons '("^In file \\(.+\\):\\([0-9]+\\)" 1 2)
> >           compilation-error-regexp-alist)))
> >
> > in .emacs solves it.
> >
> >
> > So, is there something similar for GFortran ?
> >   
> Doesn't this work for gfortran? I think the output is the same:
> "In file <filename>:<line>".
> Thus it should work with both compilers. (It probably predates the
> g95-gfortran split.)
> 
> Tobias
> 

Re: Emacs and GFortran

[Angelo Graziosi]

It seems that changing :

(eval-after-load "compile"
   '(setq compilation-error-regexp-alist
       (cons '("^In file \\(.+\\):\\([0-9]+\\)" 1 2)
          compilation-error-regexp-alist)))


with


(eval-after-load "compile"
   '(setq compilation-error-regexp-alist
       (cons '("^\\(?:In\\| In\\) file \\(.+\\):\\([0-9]+\\)" 1 2)
          compilation-error-regexp-alist)))


in .emacs, works both for GFortran that G95. Do you confirm ?


In any case this should be considered only a workaround. the best solution
being that each compiler conforms itself to a common standard like G77.


Cheers,

   Angelo.




On Mon, 30 Oct 2006, Tobias Burnus wrote:

> Hi,
> 
> Angelo Graziosi wrote:
> >> By the way, g95 has the same problem.
> >>     
> >
> > Adding
> >
> > (eval-after-load "compile"
> >    '(setq compilation-error-regexp-alist
> >        (cons '("^In file \\(.+\\):\\([0-9]+\\)" 1 2)
> >           compilation-error-regexp-alist)))
> >
> > in .emacs solves it.
> >
> >
> > So, is there something similar for GFortran ?
> >   
> Doesn't this work for gfortran? I think the output is the same:
> "In file <filename>:<line>".
> Thus it should work with both compilers. (It probably predates the
> g95-gfortran split.)
> 
> Tobias
> 

Re: Emacs and GFortran

[Steve Kargl]

On Tue, Oct 31, 2006 at 09:26:36AM +0100, Angelo Graziosi wrote:
> 
> 
> The only difference between G77 anf GFortran seems the line (<==).
> 
> Why is it so hard for GFortran add that line?

You again have chosen a simple case.

> 
> 
> Cheers,
> 
# This archive contains:
#
#       l.inc
#       l.f90
#
echo x - l.inc
sed 's/^X//' >l.inc << 'END-of-l.inc'
X   integer i
END-of-l.inc
echo x - l.f90
sed 's/^X//' >l.f90 << 'END-of-l.f90'
Xprogram a
X   include 'l.inc'
X   call i(j)
Xend program a
END-of-l.f90
exit

laptop:kargl[219] gfc -c l.f90
 In file l.inc:1

     Included at l.f90:2

   integer i
           1
 In file l.f90:3

   call i(j)
           2
Error: 'i' at (1) has a type, which is not consistent with the CALL at (2)

Is "NO" some difficult concept for you to understand?
There are real, hard to fix bug, in bugzilla.  I think
the gfortran developers time is better spent on real
problems.

-- 
Steve

Re: Emacs and GFortran

[Angelo Graziosi]

Perhaps I have some difficult to understand but I do not see a reason for
which a lot of compiler work with Emacs and GFortran which has substituted
G77 in the GNU Compiler Collection (GCC) does not.


Cheers,

  Angelo.

On Tue, 31 Oct 2006, Steve Kargl wrote:

> On Tue, Oct 31, 2006 at 09:26:36AM +0100, Angelo Graziosi wrote:
> > 
> > 
> > The only difference between G77 anf GFortran seems the line (<==).
> > 
> > Why is it so hard for GFortran add that line?
> 
> You again have chosen a simple case.
> 
> > 
> > 
> > Cheers,
> > 
> # This archive contains:
> #
> #       l.inc
> #       l.f90
> #
> echo x - l.inc
> sed 's/^X//' >l.inc << 'END-of-l.inc'
> X   integer i
> END-of-l.inc
> echo x - l.f90
> sed 's/^X//' >l.f90 << 'END-of-l.f90'
> Xprogram a
> X   include 'l.inc'
> X   call i(j)
> Xend program a
> END-of-l.f90
> exit
> 
> laptop:kargl[219] gfc -c l.f90
>  In file l.inc:1
> 
>      Included at l.f90:2
> 
>    integer i
>            1
>  In file l.f90:3
> 
>    call i(j)
>            2
> Error: 'i' at (1) has a type, which is not consistent with the CALL at (2)
> 
> Is "NO" some difficult concept for you to understand?
> There are real, hard to fix bug, in bugzilla.  I think
> the gfortran developers time is better spent on real
> problems.
> 
> -- 
> Steve
> 

Re: Emacs and GFortran

[Chong Yidong]

Angelo Graziosi <Angelo.Graziosi@roma1.infn.it> writes:

> Perhaps I have some difficult to understand but I do not see a reason for
> which a lot of compiler work with Emacs and GFortran which has substituted
> G77 in the GNU Compiler Collection (GCC) does not.

I can't parse this message: it does not conform to GNU standards ;-)

Re: Emacs and GFortran

[Stuart D. Herring]

> (eval-after-load "compile"
>    '(setq compilation-error-regexp-alist
>        (cons '("^\\(?:In\\| In\\) file \\(.+\\):\\([0-9]+\\)" 1 2)
>           compilation-error-regexp-alist)))

No reason for a regexp group here: just begin it with "^ ?In file", or
perhaps even "^ *In file", "^[\t\n ]*In file", or "^\s-*In file",
depending on the generality desired (and, in the last case, on the syntax
table for Compilation mode).

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Emacs and GFortran

[Alfred M. Szmidt]

Steve, you are being silly.  The change is not invasive, hard, or
causes a burden for gfortran developers.  The `GNU error style
message' works perfectly well with multi-line messages, as was shown
with g77.

Index: gcc/fortran/error.c
===================================================================
--- gcc/fortran/error.c    (revision 117956)
+++ gcc/fortran/error.c    (working copy)
@@ -134,7 +134,7 @@
 
   lb = loc->lb;
   f = lb->file;
-  error_printf ("In file %s:%d\n", f->filename,
+  error_printf ("%s:%d:\n", f->filename,
 #ifdef USE_MAPPED_LOCATION
          LOCATION_LINE (lb->location)
 #else

The above will make things parsable by things that parse GNU style
error messages.  You could even make it backward compatible with the
current format which gcc/testsuite/lib/gfortran-dg.exp expects by
simply adding "FILE:LINENO:" above the "In file" message, much like
g77 did!

Sighs...

Re: Emacs and GFortran

[Eli Zaretskii]

> Date: Mon, 30 Oct 2006 20:31:56 -0800
> From: Steve Kargl <sgk@troutmask.apl.washington.edu>
> Cc: Angelo.Graziosi@roma1.infn.it, rms@gnu.org, fortran@gcc.gnu.org,
> 	emacs-devel@gnu.org
> 
> On Tue, Oct 31, 2006 at 06:31:54AM +0200, Eli Zaretskii wrote:
> > If you still think this will hamper GFortran, please show some
> > specific examples of what your format allows, while the ``GNU
> > standard'' (in the meaning I mentioned above) does not.
> 
> UTSL

What for? so you'd reject it flat?

Re: Emacs and GFortran

[Eli Zaretskii]

> Date: Tue, 31 Oct 2006 07:10:22 -0800
> From: Steve Kargl <sgk@troutmask.apl.washington.edu>
> Cc: fortran@gcc.gnu.org, emacs-devel@gnu.org
> 
> laptop:kargl[219] gfc -c l.f90
>  In file l.inc:1
> 
>      Included at l.f90:2
> 
>    integer i
>            1
>  In file l.f90:3
> 
>    call i(j)
>            2
> Error: 'i' at (1) has a type, which is not consistent with the CALL at (2)

GCC outputs similar error messages without any difficulty, and without
violating the GNU standard:

  In file included from foo.h:79:,
		   from bar.c:20:
  baz.h:34:10: error: conflicting types for 'whatever'
  another.h:63:7: error: previous declaration of 'whatever' was here

(It doesn't show the actual offending line(s), but adding that would
not interfere with parsing the messages.)

> Is "NO" some difficult concept for you to understand?

Ah, the winning argument...

Re: Emacs and GFortran

[Angelo Graziosi]

On Tue, 31 Oct 2006, Stuart D. Herring wrote:

> > (eval-after-load "compile"
> >    '(setq compilation-error-regexp-alist
> >        (cons '("^\\(?:In\\| In\\) file \\(.+\\):\\([0-9]+\\)" 1 2)
> >           compilation-error-regexp-alist)))
> 
> No reason for a regexp group here: just begin it with "^ ?In file", or
> perhaps even "^ *In file", "^[\t\n ]*In file", or "^\s-*In file",
> depending on the generality desired (and, in the last case, on the syntax
> table for Compilation mode).
> 

I am not an expert of Elisp code and found that workaround "by tries"
after looking at 'compile.el'.

Your suggestions are more elegant and concise. 


Many thanks,

   Angelo.

Re: Emacs and GFortran

[Richard Stallman]

    UTSL

What does that mean?

Re: Emacs and GFortran

[Richard Stallman]

    > and if you want to add column info, that can be done as well:
    >
    >    <file>:<startline>.<startcol>-<endline>.<endcol>:<message>

    Which, you'll agree is not very usefull is the error arises from the  
    conjunction of 3 different statements at lines 5, 19 and 1027.

The syntax <file>:<startline>.<startcol>-<endline>.<endcol>:<message>
is intended for sitations where a continuous range of code that spans
a few lines is the locus of the error.

In the case you're talking about, it is certainly better to generate 3
different error messages, one for each of those error loci, using the
GNU standard format to indicate them.

They can be supplemented by other text that explains how the three
statements relate to each other and constitute an error.

Re: Emacs and GFortran

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     UTSL
>
> What does that mean?

"Use The Source Luke"

[It doesn't actually make much sense in this context though...]

-Miles

-- 
In New York, most people don't have cars, so if you want to kill a person, you
have to take the subway to their house.  And sometimes on the way, the train
is delayed and you get impatient, so you have to kill someone on the subway.
  [George Carlin]

Re: Emacs and GFortran

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> In the case you're talking about, it is certainly better to generate 3
> different error messages, one for each of those error loci, using the
> GNU standard format to indicate them.

And in fact, that's what the _existing_ gfortran code seems to do: it
emits 3 separate "loci" lines (using their non-standard format for the
file/line-number), finally followed by the text of the error message.

As far as I can tell, Alfred's one line (!) patch would make things work
perfectly using the standard format.

-Miles

-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: Emacs and GFortran

[Richard Stallman]

    Perhaps I have some difficult to understand but I do not see a reason for
    which a lot of compiler work with Emacs and GFortran which has substituted
    G77 in the GNU Compiler Collection (GCC) does not.

All of GCC should follow the GNU standards for error messages.

Re: Emacs and GFortran

[Warren Turkal]

On Wednesday 01 November 2006 09:40, Richard Stallman wrote:
> All of GCC should follow the GNU standards for error messages.

I guess I don't see why this is so unreasonable to the GFortran developers. It 
seems that GFortran should conform to the standards (however established) of 
GCC.

wt
-- 
Warren Turkal, Research Associate III/Systems Administrator
Colorado State University, Dept. of Atmospheric Science

Re: Emacs and GFortran

[Steve Kargl]

On Wed, Nov 01, 2006 at 10:37:12AM -0700, Warren Turkal wrote:
> On Wednesday 01 November 2006 09:40, Richard Stallman wrote:
> > All of GCC should follow the GNU standards for error messages.
> 
> I guess I don't see why this is so unreasonable to the GFortran developers. It 
> seems that GFortran should conform to the standards (however established) of 
> GCC.
> 

Have you even looked at the complexity of the gfortran error mechanism?
Run this source code through gfortran

http://gcc.gnu.org/bugzilla/attachment.cgi?id=9570

To make gfortran conform to 

http://www.gnu.org/prep/standards/standards.html#index-error-messages_002c-formatting-31

requires more than the 2 line patch posted earlier.  There are
at least 1022 possible routes to show_locus.

troutmask:sgk[207] grep gfc_error *c | wc -l
     891
troutmask:sgk[208] grep gfc_warning *c | wc -l
      64
troutmask:sgk[210] grep gfc_notify *c | wc -l
      67

You will need to audit each and every one to ensure that the messages
meet your expectations.  You'll then need to fix the testsuite.

gfortran's error mechanism is fragile, but works.  

If you and/or any of the other whiners in this thread want to contribute
to gfortran then fix an actual problem.  It's not hard to find the list

http://gcc.gnu.org/wiki/GFortran

   ICE-ON-VALID-CODE, REJECTS-VALID & WRONG-CODE 32 bugs on 27th October 2006
   ICE-ON-INVALID-CODE & ACCEPTS-INVALID 32 bugs on 27th October 2006
   DIAGNOSTIC 31 bugs on 27th October 2006 

Some of these bugs have been opened for years (yes, that's years).
There are too few developers and too much to do.

-- 
Steve

Re: Emacs and GFortran

[Stefan Monnier]

> To make gfortran conform to 

> http://www.gnu.org/prep/standards/standards.html#index-error-messages_002c-formatting-31

> requires more than the 2 line patch posted earlier.

Could be, but the 2 line patch is all that's needed in practice to make the
format follow at least the main part of the standard.  The more complex
parts of the standard (e.g. the <file1>:<line1>-<file2>:<line2>) are pretty
dubious anyway: I've never seen them used and they are likely to suffer from
ambiguity (if you file names look like numbers, typically).

> There are
> at least 1022 possible routes to show_locus.

> troutmask:sgk[207] grep gfc_error *c | wc -l
>      891
> troutmask:sgk[208] grep gfc_warning *c | wc -l
>       64
> troutmask:sgk[210] grep gfc_notify *c | wc -l
>       67

Why would that matter?


        Stefan

Re: Emacs and GFortran

[Alfred M. Szmidt]

   You will need to audit each and every one to ensure that the
   messages meet your expectations.  You'll then need to fix the
   testsuite.

This is not needed, you are exaggerating beyond belief Steve.

Here is another version that is should be backward compatible with the
bits that the testsuite parses.  This will fix the problem the
original user reported; namley allowing programs that parse GNU style
error message to jump to the location of the error/warning.  It is a
simple fix, why can it simply not be applied?

Index: error.c
===================================================================
--- error.c	(revision 117956)
+++ error.c	(working copy)
@@ -134,6 +134,15 @@
 
   lb = loc->lb;
   f = lb->file;
+  /* Allow programs that parse GNU style error message catch the
+     error.  */
+  error_printf ("%s:%d:\n", f->filename,
+#ifdef USE_MAPPED_LOCATION
+		LOCATION_LINE (lb->location)
+#else
+		lb->linenum
+#endif
+		);
   error_printf ("In file %s:%d\n", f->filename,
 #ifdef USE_MAPPED_LOCATION
 		LOCATION_LINE (lb->location)

Re: Emacs and GFortran

[Steve Kargl]

On Wed, Nov 01, 2006 at 09:39:31PM +0100, Alfred M. Szmidt wrote:
>    You will need to audit each and every one to ensure that the
>    messages meet your expectations.  You'll then need to fix the
>    testsuite.
> 
> This is not needed, you are exaggerating beyond belief Steve.

Have you actually read gfortran source code other than error.c?

> Here is another version that is should be backward compatible with the
> bits that the testsuite parses.  This will fix the problem the
> original user reported; namley allowing programs that parse GNU style
> error message to jump to the location of the error/warning.

I've already posted a counter example that will not allow a
person to jump to the location of the error.  You need to 
read the entire error message to decide where the error is.

-- 
Steve

Re: Emacs and GFortran

[Alfred M. Szmidt]

   Have you actually read gfortran source code other than error.c?

I have.

   > Here is another version that is should be backward compatible
   > with the bits that the testsuite parses.  This will fix the
   > problem the original user reported; namley allowing programs that
   > parse GNU style error message to jump to the location of the
   > error/warning.

   I've already posted a counter example that will not allow a
   person to jump to the location of the error.  You need to 
   read the entire error message to decide where the error is.

Your example doesn't counter anything, this is your example with GNU
style error messages (simply removing "In file", and adding a extra
semi-colon):

| l.inc:1:
| 
|      Included at l.f90:2
| 
|    integer i
|            1
| l.f90:3:
| 
|    call i(j)
|            2
| Error: 'i' at (1) has a type, which is not consistent with the CALL at (2)

Which will work with any program that parses GNU style error messages
by producing two places where one can go to; the user can choose which
place to edit.  It doesn't have to catch the exact place, it is after
all not a substitute for a brain.

Can you please apply one of those patches?  They both fix the problem.

Re: Emacs and GFortran

[Steve Kargl]

On Wed, Nov 01, 2006 at 10:51:42PM +0100, Alfred M. Szmidt wrote:
>    Have you actually read gfortran source code other than error.c?
> 
> I have.

Good, then you can appreciate that the problem isn't trivial.

> 
>    > Here is another version that is should be backward compatible
>    > with the bits that the testsuite parses.  This will fix the
>    > problem the original user reported; namley allowing programs that
>    > parse GNU style error message to jump to the location of the
>    > error/warning.
> 
>    I've already posted a counter example that will not allow a
>    person to jump to the location of the error.  You need to 
>    read the entire error message to decide where the error is.
> 
> Your example doesn't counter anything, this is your example with GNU
> style error messages (simply removing "In file", and adding a extra
> semi-colon):
> 
> | l.inc:1:
> | 
> |      Included at l.f90:2
> | 
> |    integer i
> |            1
> | l.f90:3:
> | 
> |    call i(j)
> |            2
> | Error: 'i' at (1) has a type, which is not consistent with the CALL at (2)
> 
> Which will work with any program that parses GNU style error messages
> by producing two places where one can go to; the user can choose which
> place to edit.  It doesn't have to catch the exact place, it is after
> all not a substitute for a brain.

What about the third location?  You need to parse "Included at l.f90:2"
to jump to that location to remove the included file.

> Can you please apply one of those patches?  They both fix the problem.

But it does not fix the nonconformance to the GNU standard.  The above 
message would need to become

l.f90:3-l.inc:1: error: 'i' has a type, which is not consistent with the CALL

or

l.f90:3.7-l.inc:1.3: error: 'i' has a type, which is not consistent with the CALL

In neither case, do we see the problem is actually at line 2 of l.f90.

-- 
Steve

Re: Emacs and GFortran

[Alfred M. Szmidt]

   >    Have you actually read gfortran source code other than
   >    error.c?
   > 
   > I have.

   Good, then you can appreciate that the problem isn't trivial.

It is trivial.  As I have shown with the patch.  Can you please apply
it?

   > | l.inc:1:
   > | 
   > |      Included at l.f90:2
   > | 
   > |    integer i
   > |            1
   > | l.f90:3:
   > | 
   > |    call i(j)
   > |            2
   > | Error: 'i' at (1) has a type, which is not consistent with the CALL at (2)
   > 
   > Which will work with any program that parses GNU style error
   > messages by producing two places where one can go to; the user
   > can choose which place to edit.  It doesn't have to catch the
   > exact place, it is after all not a substitute for a brain.

   What about the third location?  You need to parse "Included at
   l.f90:2" to jump to that location to remove the included file.

The error is not in the included file.  The whole point of this thread
is to jump to the location where the error is.  But you can easily
change that to the same format that gcc uses for these things:

| (defconst compilation-error-regexp-alist-alist
| ...
|     (gcc-include
|      "^\\(?:In file included\\|                \\) from \
| \\(.+\\):\\([0-9]+\\)\\(?:\\(:\\)\\|\\(,\\)\\)?" 1 2 nil (3 . 4))
| ...

   > Can you please apply one of those patches?  They both fix the
   > problem.

   But it does not fix the nonconformance to the GNU standard.  The
   above message would need to become

No, this is not needed.  As has been repeated several times by various
people.  The patch fixes the problem to the same extent that g77 fixed
it.  Such extra conformance is not needed at this point.

Please can you apply the patch instead of what I feel as making up
excuses and being stubborn?  Enough time has been wasted on this.

Re: Emacs and GFortran

[Steve Kargl]

On Wed, Nov 01, 2006 at 11:49:12PM +0100, Alfred M. Szmidt wrote:
> 
>    > | l.inc:1:
>    > | 
>    > |      Included at l.f90:2
>    > | 
>    > |    integer i
>    > |            1
>    > | l.f90:3:
>    > | 
>    > |    call i(j)
>    > |            2
>    > | Error: 'i' at (1) has a type, which is not consistent with the CALL at (2)
>    > 
>    > Which will work with any program that parses GNU style error
>    > messages by producing two places where one can go to; the user
>    > can choose which place to edit.  It doesn't have to catch the
>    > exact place, it is after all not a substitute for a brain.
> 
>    What about the third location?  You need to parse "Included at
>    l.f90:2" to jump to that location to remove the included file.
> 
> The error is not in the included file.

What do you mean the error is not the included file?  The include
statement may have been leftover from a debugging session and should
have been removed to not conflict with the CALL statement. 

>    > Can you please apply one of those patches?  They both fix the
>    > problem.
> 
>    But it does not fix the nonconformance to the GNU standard.  The
>    above message would need to become
> 
> No, this is not needed.  As has been repeated several times by various
> people.  The patch fixes the problem to the same extent that g77 fixed
> it.  Such extra conformance is not needed at this point.

First, you and others ask us to make gfortran conform to the GNU standard
for error formats.  I point out it is not trivial and gfortran's error
reporting mechanism works.  Someone comes up with a bandaid patch that
doesn't yield conformance but makes some people happy because it makes
their immediate problem go away.  I again point out the bandaid patch
does not yield conformance, and now your saying "Well, it's good enough.
We really did not mean that gfortran should conform to the GNU standard."  

-- 
Steve

Re: Emacs and GFortran

[Alfred M. Szmidt]

If you wish to make gfortran 100% conformant with the GNU style, by
all means please do, but the suggested patch fixes the most common
case.  Could you please apply it?

Re: Emacs and GFortran

[Steve Kargl]

On Thu, Nov 02, 2006 at 12:35:03AM +0100, Alfred M. Szmidt wrote:
> If you wish to make gfortran 100% conformant with the GNU style, by
> all means please do, but the suggested patch fixes the most common
> case.  Could you please apply it?

No.

Without the simple patch the gfortran testsuite shows

                === gfortran Summary ===

# of expected passes            14905
# of expected failures          7
# of unsupported tests          73
/usr/home/sgk/gcc/obj4x/gcc/testsuite/gfortran/../../gfortran  version 4.3.0 20061101 (experimental)


With the "simple" patch

                === gfortran Summary ===

# of expected passes            12734
# of unexpected failures        2171
# of expected failures          7
# of unsupported tests          73
/usr/home/sgk/gcc/obj4x/gcc/testsuite/gfortran/../../gfortran  version 4.3.0 20061101 (experimental)

-- 
Steve

Re: Emacs and GFortran

[Alfred M. Szmidt]

Steve, please go back and re-read the thread, nobody has ever asked
for full conformance.  You are making up excuses as you go on, it is
seriously getting tiresome and I'm having a hard time being polite to
you since you clearly want to waste my time with this instead of
takling the problem, if you had done that to begin with this would
have been solved days ago.

The unexpected failures message you posted is completely useless,
please post which patch it was ("simple" does not mean anything to
me), please post what the input looked like, and what the output
looked from one of the failed tests.  Or better yet, this will take
even less time than posting this data: simply fix the bug!

Re: Emacs and GFortran

[Thomas Koenig]

On Thu, Nov 02, 2006 at 02:26:24PM +0100, Alfred M. Szmidt wrote:

(addressed to Steve Kargl)

> Or better yet, this will take
> even less time than posting this data: simply fix the bug!

You are proposing a patch to gfortran, which is part of gcc.
The guidelines for accepting contributions are spelled out on
the gcc website.

If your patch is non-trivial, we need copyright papers from you
assigning copyright of any changes to the gcc source tree to
the FSF.  Do you have a copyright assignment?

In order to be included into gcc, your proposed patch needs to be
regression-tested and accompanied by relevant test cases proper
ChangeLog entries.

If these conditions are met, then post the patch to
gcc-patches@gcc.gnu.org and fortran@gcc.gnu.org.  Usually there
will be a discussion of the patch, possibly leading to requirements
for changes.  Finally, if all goes well, a maintainer will approve
the patch and (if you don't have commit privileges) commit it.

That's the way gcc and gfortran maintenance works.  In practice,
it works pretty well.

Best regards
	Thomas

Re: Emacs and GFortran

[Eli Zaretskii]

> Date: Thu, 2 Nov 2006 20:00:05 +0100
> From: Thomas Koenig <Thomas.Koenig@online.de>
> Cc: fortran@gcc.gnu.org, wt@atmos.colostate.edu,
> 	Steve Kargl <sgk@troutmask.apl.washington.edu>, emacs-devel@gnu.org
> 
> If your patch is non-trivial, we need copyright papers from you
> assigning copyright of any changes to the gcc source tree to
> the FSF.  Do you have a copyright assignment?

Yes, he does (and you should have been able to check that yourself in
copyright.list).

> If these conditions are met, then post the patch to
> gcc-patches@gcc.gnu.org and fortran@gcc.gnu.org.  Usually there
> will be a discussion of the patch, possibly leading to requirements
> for changes.  Finally, if all goes well, a maintainer will approve
> the patch and (if you don't have commit privileges) commit it.

If I were Alfred, I'd hesitate to submit a patch, given the attitude
of several GFortranners.  That attitude is so hostile that I'd suggest
to talk to the steering committee about it.

> That's the way gcc and gfortran maintenance works.  In practice,
> it works pretty well.

Well for whom, exactly?

Re: Emacs and GFortran

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> If I were Alfred, I'd hesitate to submit a patch, given the attitude
> of several GFortranners.  That attitude is so hostile that I'd
> suggest to talk to the steering committee about it.

There would be more substance to talk about if he submitted a patch to
the proper channels first.  Mailing lists do not rarely exhibit bouts
of incivility.  People are human, and free time developers don't
necessarily react enthused if work gets dumped at their doors.  It is
not like we don't see some passionate arguments on the Emacs developer
list at times, too.

So I'd really recommend to Alfred passing over the momentary heat of
discussion on the list, and entering a proper report at the bug
reporting data base, filling in as much material as he feels he can
provide with reasonable effort.

When this does not lead to results, there is still enough time to try
getting others involved in a solution.  And it gives third parties a
chance to give an outstanding problem report a shot, without
themselves being participants in the mailing list discussion.  So
there is more of a chance that the problem will get worked on by
somebody without the need for a preceding shouting match.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs and GFortran

[Thomas Koenig]

On Thu, Nov 02, 2006 at 10:22:22PM +0200, Eli Zaretskii wrote:

> > That's the way gcc and gfortran maintenance works.  In practice,
> > it works pretty well.
 
> Well for whom, exactly?

For gcc and gfortran development.

If you have an active interest in that matter, please feel free to
contribute to resolving PR 29689.

	Thomas

Re: Emacs and GFortran

[Steve Kargl]

On Thu, Nov 02, 2006 at 10:22:22PM +0200, Eli Zaretskii wrote:
> 
> If I were Alfred, I'd hesitate to submit a patch, given the attitude
> of several GFortranners.  That attitude is so hostile that I'd suggest
> to talk to the steering committee about it.
> 

Sigh.  Two patches to fortran/error.c have been proposed.
Both patches cause a significant number of failures in the
gfortran testsuite.  Don't suggest a patch is trivial and
turn a blind eye to the problems that it causes elsewhere.  
Someone has to fix the testsuite failure.  That someone is
usually the person whose submitting the patch.

-- 
Steve

Re: Emacs and GFortran

[Paul Thomas]

Eli et alia,
>   
>> Is "NO" some difficult concept for you to understand?
>>     
>
> Ah, the winning argument..
I just spent the last 15 minutes going through this thread, trying to 
understand where all this came from.  I have to confess that I am none 
the wiser.

As Thomas and Francois-Xavier have pointed out, we have a procedure for 
submitting problems and then for considering/applying the fixes.  There 
is now a PR for this problem and now somebody has to sit down and do the 
work of developing a patch that not only fixes the problem but also 
regtests, either with the testsuite as is or by modifying it to suit.

All the gfortran maintainers are part-time volunteers and are fortran 
users.  Our interests and priorities tend to reflect our fortran usage.  
That said, we have put a lot of energy into making the compiler produce 
correct code and to approach the performance of the best commercial 
compilers.  In addition to supporting our own interests, we try very 
hard to do a public service role by fixing bugs submitted through 
Bugzilla, as quickly as possible.  Many reporters have expressed 
satisfaction with our efforts.  The format of error messages happens to 
be something that has not risen to the top of the pile.

Hostility, such as it is, has been triggered by the hectoring attitude 
of those who have crept out of the woodwork to add their halfpenny worth 
to this thread; none of whom have contributed to gfortran, as far as I 
know.  I rather think that the steering committee would support the 
gfortran maintainers, were it to come to that. 

Please do the work, rather than rather rudely insisting that others do 
it - submit a patch and I promise that I for one will take a look at 
it.  In the meantime, I am going to try to put the interface meta-bug to 
bed :-)

Let's cool it now please; there's too much to do spend any more time on 
this correspondence.

Paul

Re: Emacs and GFortran

[Steven Bosscher]

On Thursday 02 November 2006 21:22, Eli Zaretskii wrote:
> > Date: Thu, 2 Nov 2006 20:00:05 +0100
> > From: Thomas Koenig <Thomas.Koenig@online.de>
> > Cc: fortran@gcc.gnu.org, wt@atmos.colostate.edu,
> > 	Steve Kargl <sgk@troutmask.apl.washington.edu>, emacs-devel@gnu.org
> >
> > If your patch is non-trivial, we need copyright papers from you
> > assigning copyright of any changes to the gcc source tree to
> > the FSF.  Do you have a copyright assignment?
>
> Yes, he does (and you should have been able to check that yourself in
> copyright.list).

You should have been able to check that not all GCC developers
can check copyright.list, thank you very much.

> > If these conditions are met, then post the patch to
> > gcc-patches@gcc.gnu.org and fortran@gcc.gnu.org.  Usually there
> > will be a discussion of the patch, possibly leading to requirements
> > for changes.  Finally, if all goes well, a maintainer will approve
> > the patch and (if you don't have commit privileges) commit it.
>
> If I were Alfred, I'd hesitate to submit a patch, given the attitude
> of several GFortranners.  That attitude is so hostile that I'd suggest
> to talk to the steering committee about it.

Puh-lease...

If anyone is really hostile here, it is AMS, and you're on the border
of hostility yourself.  What in the world are you trying to achieve
with all this whining?  Chasing away gfortran developers?

Try as you might, the fact is that you can't force volunteers to do
what you want.

In the case of gfortran, all developers are volunteers, and it just so
happens that most of us like gfortran's current way of reporting errors.

The people who work on gfortran are usually people who need a Fortran
compiler for their research/hobby/work/etc.  They work on things they
believe are important.  Apparently they don't use Emacs, so the error
format issue, which has existed since the incarnation of the project
6 years ago, is just not a major issue for any gfortran developers.
If a developer would care, the issue would be fixed.

Should gfortran conform to the GNU standards? Preferably yes.  But if
no developer (volunteer!) cares to make it so, tough luck but it is not
going to happen.

Then you arrogant folks come in, doing nothing but complaining and
telling respected gfortran developers (nice people, I know some of them
in person) that they basically don't know what they're talking about,
and that The Only Right Way is the way you want things to be even though
the patches AMS has posted clearly show he has no understanding of the
gfortran diagnostics mechanisms.

How arrogant, you should be ashamed of yourselves.

So go ahead and take it up with the SC, and watch to see gfortran hackers
getting so frustrated with your whining that they just give up on the
whole project and just invest their precious time in something that does
not require interacting with people like you.


> > That's the way gcc and gfortran maintenance works.  In practice,
> > it works pretty well.
>
> Well for whom, exactly?

For me, at least.  And for everyone else in the GCC community, AFAICT.

Now, can you go be frustrated about something eise in some place else?

Gr.
Steven

Re: Emacs and GFortran

[Alfred M. Szmidt]

I really do not wish to partake in this anymore, but I cannot let this
slide.

   Should gfortran conform to the GNU standards? Preferably yes.  But
   if no developer (volunteer!) cares to make it so, tough luck but it
   is not going to happen.

I volunteered.  And now you are calling me of all people hostile and
on top of that ignorant? The fix in question is so trivial that it
takes more time to read your message than actually fixing it!  Steve
Kargl might have not been very cooperative, but at least he was not
rude, you on the other hand have gone beyond all possible boundaries.

The only person who should be ashamed is you who are accusing
volunteers of hostility and ignorance, I will not report this to the
GCC SC at this time since I have really better things to do, maybe RMS
who reads emacs-devel@ will act on such rude, disrespectful and
arrogant behaviour from those in-charge of gfortran.  It is no wonder
why gfortran has so few volunteer when they try to chase away anyone
who tries to contribute anything to the project.

Re: Emacs and GFortran

[Steve Kargl]

On Fri, Nov 03, 2006 at 02:08:17AM +0100, Alfred M. Szmidt wrote:
> 
> I volunteered.  And now you are calling me of all people hostile and
> on top of that ignorant? The fix in question is so trivial that it
> takes more time to read your message than actually fixing it!  Steve
> Kargl might have not been very cooperative

Alfred has asked me not to respond to him, so I've removed
him from the list.

I have stated more than once THE TRIVIAL FIX DOES NOT WORK.
It causes REGRESSIONS in the gfortran testsuite.  If someone
wants to fix whatever is causing the regressions, I'll be more
than happy to commit the patch.

This patch 

troutmask:sgk[119] svn diff error.c
Index: error.c
===================================================================
--- error.c     (revision 118397)
+++ error.c     (working copy)
@@ -134,7 +134,7 @@ show_locus (int offset, locus * loc)
 
   lb = loc->lb;
   f = lb->file;
-  error_printf ("In file %s:%d\n", f->filename,
+  error_printf ("%s:%d\n", f->filename,
 #ifdef USE_MAPPED_LOCATION
                LOCATION_LINE (lb->location)
 #else


causes over 2000 regressions of the form


Executing on host: /usr/home/sgk/gcc/obj4x/gcc/testsuite/gfortran/../../gfortran
 -B/usr/home/sgk/gcc/obj4x/gcc/testsuite/gfortran/../../ /usr/home/sgk/gcc/gcc4x
/gcc/testsuite/gfortran.dg/PR19754_1.f90   -O   -pedantic-errors -S  -o PR19754_
1.s    (timeout = 300)
 /usr/home/sgk/gcc/gcc4x/gcc/testsuite/gfortran.dg/PR19754_1.f90:7

   x = x + y ! { dg-error "Shapes for operands at" }
      1    2
Error: Shapes for operands at (1) and (2) are not conformable
compiler exited with status 1
output is:
 /usr/home/sgk/gcc/gcc4x/gcc/testsuite/gfortran.dg/PR19754_1.f90:7

   x = x + y ! { dg-error "Shapes for operands at" }
      1    2
Error: Shapes for operands at (1) and (2) are not conformable

FAIL: gfortran.dg/PR19754_1.f90  -O   (test for errors, line 7)
FAIL: gfortran.dg/PR19754_1.f90  -O  (test for excess errors)
Excess errors:
 /usr/home/sgk/gcc/gcc4x/gcc/testsuite/gfortran.dg/PR19754_1.f90:7
   x = x + y ! { dg-error "Shapes for operands at" }
      1    2
Error: Shapes for operands at (1) and (2) are not conformable

-- 
Steve

Re: Emacs and GFortran

[Brooks Moses]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

Steve Kargl wrote:
> I have stated more than once THE TRIVIAL FIX DOES NOT WORK.
> It causes REGRESSIONS in the gfortran testsuite.  If someone
> wants to fix whatever is causing the regressions, I'll be more
> than happy to commit the patch.

The attached only-slightly-less-trivial patch should fix the 
regressions, although I have not yet tested it to confirm that.

Since my build machine is currently occupied with running CFD 
calculations for my dissertation, would you mind regtesting it?

- Brooks

[-- Attachment #2: error.diff --]
[-- Type: text/x-patch, Size: 1728 bytes --]

Index: testsuite/lib/gfortran-dg.exp
===================================================================
--- testsuite/lib/gfortran-dg.exp	(revision 118446)
+++ testsuite/lib/gfortran-dg.exp	(working copy)
@@ -26,23 +26,23 @@
     set output_file [lindex $result 1]
 
     # gfortran error messages look like this:
-    #      In file [name]:[line]
+    #      [name]:[line]
     #
     #        some code
     #              1
-    #     Error: Some error at (1) and (2)
+    #     Error: Some error at (1)
     # or
-    #      In file [name]:[line]
+    #      [name]:[line]
     #
     #       some code
     #              1
-    #      In file [name]:[line2]
+    #      [name]:[line2]
     #
     #       some other code
     #         2
     #     Error: Some error at (1) and (2)
     # or
-    #      In file [name]:[line]
+    #      [name]:[line]
     #
     #       some code and some more code
     #              1       2
@@ -59,7 +59,7 @@
     # Note that these regexps only make sense in the combinations used below.
     # Note also that is imperative that we first deal with the form with
     # two loci.
-    set locus_regexp " In file (\[^\n\]*)\n\n\[^\n\]*\n\[^\n\]*\n"
+    set locus_regexp " (\[^\n\]*)\n\n\[^\n\]*\n\[^\n\]*\n"
     set diag_regexp "(\[^\n\]*)\n"
 
     set two_loci "$locus_regexp$locus_regexp$diag_regexp"
Index: fortran/error.c
===================================================================
--- fortran/error.c	(revision 118446)
+++ fortran/error.c	(working copy)
@@ -134,7 +134,7 @@
 
   lb = loc->lb;
   f = lb->file;
-  error_printf ("In file %s:%d\n", f->filename,
+  error_printf ("%s:%d\n", f->filename,
 #ifdef USE_MAPPED_LOCATION
 		LOCATION_LINE (lb->location)
 #else

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs and GFortran

[Chong Yidong]

> With the "simple" patch
>
>                 === gfortran Summary ===
>
> # of expected passes            12734
> # of unexpected failures        2171
> # of expected failures          7
> # of unsupported tests          73

If your test suites rely on a non-standard error-reporting format,
bringing the format into standards-compliance will obviously break the
test suites; but the bug here doesn't lie in the standards-compliance.

Re: Emacs and GFortran

[Chong Yidong]

I do have one suggestion: if the only reason for not accepting
Alfred's patch is that the Gfortran developers are relying on test
suites that expect the current non-standard format, and fixing the
test suite is too troublesome at the moment, perhaps the best solution
is to add a flag to Gfortran that says to output using the standard
format.  Then Emacs and other tools can pass this flag to Gfortran by
default.

Re: Emacs and GFortran

[Steve Kargl]

On Thu, Nov 02, 2006 at 09:40:39PM -0500, Chong Yidong wrote:
> > With the "simple" patch
> >
> >                 === gfortran Summary ===
> >
> > # of expected passes            12734
> > # of unexpected failures        2171
> > # of expected failures          7
> > # of unsupported tests          73
> 
> If your test suites rely on a non-standard error-reporting format,
> bringing the format into standards-compliance will obviously break the
> test suites; but the bug here doesn't lie in the standards-compliance.

The two posted patches do not bring gfortran into conformance with
the GNU error format.  It breaks the testsuite, which might be 
important to ensure half-baked patches aren't wedged into gfortran.

-- 
Steve

Re: Emacs and GFortran

[Steven Bosscher]

On 11/3/06, Alfred M. Szmidt <ams@gnu.org> wrote:
> I really do not wish to partake in this anymore, but I cannot let this
> slide.
>
>    Should gfortran conform to the GNU standards? Preferably yes.  But
>    if no developer (volunteer!) cares to make it so, tough luck but it
>    is not going to happen.
>
> I volunteered.

Yes, and that's really sweet of you.

>  And now you are calling me of all people hostile and
> on top of that ignorant?

No, I call you "not listening"...

You've been told many times now that the patches you posted are just
wrong. But you still insist that you've posted the solution and that
everyone should just ignore the fact that you:
a) did not test the patch
b) did not understand the parts of the compiler you're changing


> The fix in question is so trivial that it
> takes more time to read your message than actually fixing it!

See?
Not listening.

> Steve
> Kargl might have not been very cooperative,

> It is no wonder
> why gfortran has so few volunteer when they try to chase away anyone
> who tries to contribute anything to the project.

*laughs*

I don't know what project you're looking at, but it seems to me that
gfortran no problem at all to attract developers.  Granted,
discussions like this one don't help. But there are, I don't know, 12?
15? active gfortran developers, and that's more than any other front
end.

If you want to make a point, don't use such rediculous arguments.

Gr.
Steven

Re: Emacs and GFortran

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

>> With the "simple" patch
>>
>>                 === gfortran Summary ===
>>
>> # of expected passes            12734
>> # of unexpected failures        2171
>> # of expected failures          7
>> # of unsupported tests          73
>
> If your test suites rely on a non-standard error-reporting format,
> bringing the format into standards-compliance will obviously break
> the test suites; but the bug here doesn't lie in the
> standards-compliance.

Certainly.  But it still means that changes in the format imply more
work in their wake than the original change warrants.  It also means
that one should be certain that one does all changes in one swoop so
that this followup work needs to be done only once.  So that means
that one needs to carefully round up _all_ cases and make sure one
does not overlook some.

This requires work, and it requires coordination in order to make sure
that the test suite does not go out of commission at a point of time
where it would be definitely needed desperately.  It might even be
prudent to make a branch for this purpose, and merge it only once when
it is completed.

So I do think the way to go is the one started: first enter this into
the bug database and take the discussion there, and then see when the
work could be done without causing too much disruption, and who would
be willing to work on it.

Fingerpointing is not going to help.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs and GFortran

[Eli Zaretskii]

> Date: Thu, 2 Nov 2006 12:43:18 -0800
> From: Steve Kargl <sgk@troutmask.apl.washington.edu>
> Cc: Thomas Koenig <Thomas.Koenig@online.de>, ams@gnu.org, fortran@gcc.gnu.org,
>         wt@atmos.colostate.edu, emacs-devel@gnu.org
> 
> Sigh.  Two patches to fortran/error.c have been proposed.
> Both patches cause a significant number of failures in the
> gfortran testsuite.

When the failures were reported, Alfred asked for the details of the
failures.  He didn't get them; only today were some of the necessary
details posted.  You cannot expect him to fix 2000 failures without
knowing their particulars.  Telling those details is the minimal
courtesy I think you owe to someone who volunteers to fix a bug in
your package.

Re: Emacs and GFortran

[Eli Zaretskii]

> Date: Thu, 02 Nov 2006 23:20:32 +0100
> From: Paul Thomas <paulthomas2@wanadoo.fr>
> Cc: Steve Kargl <sgk@troutmask.apl.washington.edu>,
> 	Angelo.Graziosi@roma1.infn.it, fortran@gcc.gnu.org,
> 	emacs-devel@gnu.org
> 
> Hostility, such as it is, has been triggered by the hectoring attitude 
> of those who have crept out of the woodwork to add their halfpenny worth 
> to this thread; none of whom have contributed to gfortran, as far as I 
> know.

If this paragraph does not have hostility written all over it, then
perhaps I don't know what hostility is.

FYI, those who ``crept out of the woodwork'' did so only _after_ the
complaints about the non-standard error messages were met with clearly
hostile attitude and ``NO'' responses.  Perhaps you missed that while
reading the long thread, with some messages out of order due to mail
delivery delays.

> I rather think that the steering committee would support the 
> gfortran maintainers, were it to come to that. 

If it is really important to you to know, we could start a discussion
with them.

Re: Emacs and GFortran

[Eli Zaretskii]

> Date: Thu, 2 Nov 2006 23:27:21 +0100
> From: "=?ISO-8859-1?Q?Fran=E7ois-Xavier_Coudert?=" <fxcoudert@gmail.com>
> Cc: "Thomas Koenig" <Thomas.Koenig@online.de>, ams@gnu.org, fortran@gcc.gnu.org, 
> 	wt@atmos.colostate.edu, sgk@troutmask.apl.washington.edu, 
> 	emacs-devel@gnu.org
> 
> >>  Do you have a copyright assignment?
> >
> > Yes, he does (and you should have been able to check that yourself in
> > copyright.list).
> 
> As a matter of fact, no, we can't. Only some people from the GCC
> developers have access to the right machine, and all we (gfortran
> maintainers) can do is ask one of them to look at it.

So it's fine to say UTSL and otherwise request people to look in the
gfortran sources for details, instead of providing them here, but you
yourself have no intent to follow the same practice of consulting your
own resources?  Why don't you ask these few GCC developers, before
bringing that here as one more argument against accepting the patch?

Re: Emacs and GFortran

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 2 Nov 2006 12:43:18 -0800 From: Steve Kargl
>> <sgk@troutmask.apl.washington.edu> Cc: Thomas Koenig
>> <Thomas.Koenig@online.de>, ams@gnu.org, fortran@gcc.gnu.org,
>> wt@atmos.colostate.edu, emacs-devel@gnu.org
>> 
>> Sigh.  Two patches to fortran/error.c have been proposed.
>> Both patches cause a significant number of failures in the
>> gfortran testsuite.
>
> When the failures were reported, Alfred asked for the details of the
> failures.  He didn't get them; only today were some of the necessary
> details posted.  You cannot expect him to fix 2000 failures without
> knowing their particulars.  Telling those details is the minimal
> courtesy I think you owe to someone who volunteers to fix a bug in
> your package.

Let us keep this in perspective: those developers are fixing bugs in
"their" package all of the time and doing their users a greater favor
continually than a one-time effort of somebody else will do to them.

I find the _demands_ people tend to place on volunteers in the free
software world surprising at times.  This holds for demands towards
Emacs developers as well, so I don't think we are sitting in a
different boat here.

The problem has been solved in the mean time.  I am grateful that
stuff like this can, in the end, be worked out and addressed properly.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs and GFortran

[Eli Zaretskii]

> Date: Fri, 3 Nov 2006 01:43:30 +0100
> Cc: Thomas Koenig <Thomas.Koenig@online.de>,
>  ams@gnu.org,
>  wt@atmos.colostate.edu,
>  sgk@troutmask.apl.washington.edu,
>  emacs-devel@gnu.org
> From: Steven Bosscher <stevenb.gcc@gmail.com>
> 
> You should have been able to check that not all GCC developers
> can check copyright.list, thank you very much.

Then the OP should have consulted them before bringing that up here in
the heat of a dispute, as if that were an important reason not to
accept the patch.

> What in the world are you trying to achieve

I hoped (and still hope) that the gfortran developers will learn how
to react to complaints of their users.

> with all this whining?

And what did you try to achieve with these ad hominem attacks?

> Try as you might, the fact is that you can't force volunteers to do
> what you want.

No, but I hope I can talk reason to them.  Perhaps they were unaware
of the fact that their responses were unusually rude; I tried to make
that more clear.

> In the case of gfortran, all developers are volunteers

So are we (myself included).

> Then you arrogant folks come in, doing nothing but complaining and
> telling respected gfortran developers (nice people, I know some of them
> in person) that they basically don't know what they're talking about,
> and that The Only Right Way is the way you want things to be even though
> the patches AMS has posted clearly show he has no understanding of the
> gfortran diagnostics mechanisms.

> So go ahead and take it up with the SC, and watch to see gfortran hackers
> getting so frustrated with your whining that they just give up on the
> whole project and just invest their precious time in something that does
> not require interacting with people like you.

If user complaints are seen as ``whining'' and nuisance, then perhaps
we'd be better off without those who see them as such.

Re: Emacs and GFortran

[Eli Zaretskii]

> Date: Fri, 3 Nov 2006 08:06:33 +0100
> From: "Steven Bosscher" <stevenb.gcc@gmail.com>
> Cc: fortran@gcc.gnu.org, eliz@gnu.org, Thomas.Koenig@online.de, 
> 	wt@atmos.colostate.edu, sgk@troutmask.apl.washington.edu, 
> 	emacs-devel@gnu.org, rms@gnu.org
> >
> >    Should gfortran conform to the GNU standards? Preferably yes.  But
> >    if no developer (volunteer!) cares to make it so, tough luck but it
> >    is not going to happen.
> >
> > I volunteered.
> 
> Yes, and that's really sweet of you.

And what is this if not hostility and rudeness towards a volunteer?

Re: Emacs and GFortran

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 02 Nov 2006 23:20:32 +0100
>> From: Paul Thomas <paulthomas2@wanadoo.fr>
>> Cc: Steve Kargl <sgk@troutmask.apl.washington.edu>,
>> 	Angelo.Graziosi@roma1.infn.it, fortran@gcc.gnu.org,
>> 	emacs-devel@gnu.org
>
>> I rather think that the steering committee would support the 
>> gfortran maintainers, were it to come to that. 
>
> If it is really important to you to know, we could start a discussion
> with them.

Can we please drop this?  The original problem has been dealt with,
and there is nothing to be gained from escalating the situation,
anyway.

I think we all have better things to do.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs and GFortran

[Eli Zaretskii]

> Cc: Thomas Koenig <Thomas.Koenig@online.de>,  ams@gnu.org,
> 	  sgk@troutmask.apl.washington.edu,  wt@atmos.colostate.edu,
> 	  fortran@gcc.gnu.org,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Thu, 02 Nov 2006 21:32:49 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If I were Alfred, I'd hesitate to submit a patch, given the attitude
> > of several GFortranners.  That attitude is so hostile that I'd
> > suggest to talk to the steering committee about it.
> 
> There would be more substance to talk about if he submitted a patch to
> the proper channels first.

The ``proper channels'' could have been pointed out right at the
beginning of this thread, in some polite manner.  Instead, the initial
responses were a flat refusal to even consider any change, then false
arguments about impossibility to express complex errors in the
standard form, then more stonewalling, etc. etc.  Only late into the
(by then very heated) dispute did we hear that the right way to submit
a patch was through ``the channels''.  At some point I wondered
whether we were talking to lawyers, not to fellow developers.

> free time developers don't necessarily react enthused if work gets
> dumped at their doors.

They should know better, IMO.  Btw, ``getting work dumped at my
doorsteps'' is precisely what some of us here do for Emacs for quite
some time now.  Somehow, we do manage to stay cool and supportive to
whoever reports problems.

> It is not like we don't see some passionate arguments on the Emacs
> developer list at times, too.

In those rare cases when similar hostility to outside complaints is
present on the Emacs list, the guilty parties are pointed out their
rude behavior.

> So I'd really recommend to Alfred passing over the momentary heat of
> discussion on the list, and entering a proper report at the bug
> reporting data base

This was already done a day or two ago; please re-read the thread.
And yet we still don't have an agreement to accept the patch, nor even
consider it an important problem to fix.

Re: Emacs and GFortran

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Fri, 03 Nov 2006 13:58:37 +0100
> 
> I find the _demands_ people tend to place on volunteers in the free
> software world surprising at times.

I don't.  If you take upon yourself to maintain a package, you are
expected to do that in a professionally sound manner, and be kind and
responsive to your users; if you can't, you shouldn't be maintaining
the package in the first place.  Of course, we all fail to behave like
that from time to time, but we should at least try; you seem to say we
shouldn't, with which I cannot disagree more.

Re: Emacs and GFortran

[Eli Zaretskii]

> Cc: Paul Thomas <paulthomas2@wanadoo.fr>,  Angelo.Graziosi@roma1.infn.it,
> 	  fortran@gcc.gnu.org,  sgk@troutmask.apl.washington.edu,
> 	  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Fri, 03 Nov 2006 14:14:10 +0100
> 
> Can we please drop this?

You yourself keep this going by posting responses.  Don't ask others
not to do what you do yourself.

Re: Emacs and GFortran

[Nick Roberts]

Brooks Moses writes:
 > Steve Kargl wrote:
 > > I have stated more than once THE TRIVIAL FIX DOES NOT WORK.
 > > It causes REGRESSIONS in the gfortran testsuite.  If someone
 > > wants to fix whatever is causing the regressions, I'll be more
 > > than happy to commit the patch.
 > 
 > The attached only-slightly-less-trivial patch should fix the 
 > regressions, although I have not yet tested it to confirm that.

I guess I'm pushing my luck with current feelings, but would it be
possible to add the column number?

[Previously I wrote:

  The original error message you posted had column number information in the
  error output too:

     gfortran hello.F
      In file hello.F:3

           write(*,) 'Hello!'                                                
                1
     Error: Syntax error in WRITE statement at (1)

  it would be nice to be able to use this too.  I think gcc outputs kind of
  information as something like:

  hello.c:3:13: error: blah, blah, blah...

  Emacs can then place the cursor in the relevant column when visiting an error
  (and Vim probably does something similar too).]



-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs and GFortran

[Brooks Moses]

Nick Roberts wrote:
> Brooks Moses writes:
>  > The attached only-slightly-less-trivial patch should fix the 
>  > regressions, although I have not yet tested it to confirm that.
> 
> I guess I'm pushing my luck with current feelings, but would it be
> possible to add the column number?

That should be possible, albeit trickier.  (Luckily, I'm pretty certain 
that unlike the recent change, it won't break the testsuite.)

Given that that one's trickier and of considerably lower priority, I'm 
not going to give it immediate attention, but I've filed an enhancement 
request for it in the GFortran bug database.  (PR 29702)

- Brooks

Re: Emacs and GFortran

[Richard Stallman]

The GFortran maintainers have a valid point that the test suite also
needs to be fixed.  However, instead of demanding that users like you
do all the work, they should be helping to get it done.  For instance,
someone who understands the test suite could look for an equally
simple way to fix that.

Re: Emacs and GFortran

[Brooks Moses]

Nick Roberts wrote:
> Brooks Moses writes:
>  > The attached only-slightly-less-trivial patch should fix the 
>  > regressions, although I have not yet tested it to confirm that.
> 
> I guess I'm pushing my luck with current feelings, but would it be
> possible to add the column number?

FYI: I just committed a patch to the GCC 4.2 and 4.3 branches that 
provides column numbers in the error messages.  The format is as per the 
following example:

      ~/temp/>gfortran hello.F
      hello.F:3.6:

            write(*,) 'Hello!' 

                 1
      Error: Syntax error in WRITE statement at (1)

- Brooks

Re: Emacs and GFortran

[Nick Roberts]

 > >  > The attached only-slightly-less-trivial patch should fix the 
 > >  > regressions, although I have not yet tested it to confirm that.
 > > 
 > > I guess I'm pushing my luck with current feelings, but would it be
 > > possible to add the column number?
 > 
 > FYI: I just committed a patch to the GCC 4.2 and 4.3 branches that 
 > provides column numbers in the error messages.  The format is as per the 
 > following example:
 > 
 >       ~/temp/>gfortran hello.F
 >       hello.F:3.6:
 > 
 >             write(*,) 'Hello!' 
 > 
 >                  1
 >       Error: Syntax error in WRITE statement at (1)

Thanks, but the error seems to be in column 11 i.e in Emacs the first column
is 0 and the first six (blank) columns are counted too.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs and GFortran

[Brooks Moses]

Nick Roberts wrote:
>  > FYI: I just committed a patch to the GCC 4.2 and 4.3 branches that 
>  > provides column numbers in the error messages.  The format is as per the 
>  > following example:
>  > 
>  >       ~/temp/>gfortran hello.F
>  >       hello.F:3.6:
>  > 
>  >             write(*,) 'Hello!' 
>  > 
>  >                  1
>  >       Error: Syntax error in WRITE statement at (1)
> 
> Thanks, but the error seems to be in column 11 i.e in Emacs the first column
> is 0 and the first six (blank) columns are counted too.

Oh, oops -- that's my fault; I edited the error message quoted in an old 
post, rather than actually running it to generate a real message, and 
missed the blank columns when I was hand-counting.  The blanks would 
very definitely be counted in a real error message.  Thanks for catching 
that!

There is still an off-by-one error; we number the first column as 1 
rather than 0.  Given that there's a very strong tradition in Fortran of 
numbering columns starting with 1, and that off-by-one errors in column 
location are within the noise level of locating things (given that 
nearly all errors are several columns wide), I think it makes more sense 
overall to keep it the way it currently is.

- Brooks

Re: Emacs and GFortran

[Nick Roberts]

 > There is still an off-by-one error; we number the first column as 1 
 > rather than 0.  Given that there's a very strong tradition in Fortran of 
 > numbering columns starting with 1, and that off-by-one errors in column 
 > location are within the noise level of locating things (given that 
 > nearly all errors are several columns wide), I think it makes more sense 
 > overall to keep it the way it currently is.

I see now this is the right way anyway (from "Formatting Error Messages"
in standards.info):

  Line numbers should start from 1 at the beginning of the file, and
  column numbers should start from 1 at the beginning of the line.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs and GFortran

[David Kastrup]

Brooks Moses <brooks.moses@codesourcery.com> writes:

> There is still an off-by-one error; we number the first column as 1
> rather than 0.  Given that there's a very strong tradition in
> Fortran of numbering columns starting with 1, and that off-by-one
> errors in column location are within the noise level of locating
> things (given that nearly all errors are several columns wide), I
> think it makes more sense overall to keep it the way it currently
> is.

I don't actually agree: the error message already contains a
human-readable column indicator in form of the single 1 in the line
below.  The numeric column number is for the sake of computers and in
a computer-readable format, so it would make sense to have it look
just like expected from this format.

Personally, I find it sort of weird to start lines with 1 and columns
with 0, but the point of a machine-readable format is that everybody
does it the same.

I'd suggest that column 1 in Fortran is just called column 1 because
column 0 contains the ASA print control character
<URL:http://en.wikipedia.org/wiki/ASA_carriage_control_characters>,
but then I'd sound silly...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs and GFortran

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > There is still an off-by-one error; we number the first column as 1 
>  > rather than 0.  Given that there's a very strong tradition in Fortran of 
>  > numbering columns starting with 1, and that off-by-one errors in column 
>  > location are within the noise level of locating things (given that 
>  > nearly all errors are several columns wide), I think it makes more sense 
>  > overall to keep it the way it currently is.
>
> I see now this is the right way anyway (from "Formatting Error Messages"
> in standards.info):
>
>   Line numbers should start from 1 at the beginning of the file, and
>   column numbers should start from 1 at the beginning of the line.

Then disregard my previous mail.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs and GFortran

[Andrew Pinski]

On Wed, 2006-11-15 at 09:43 +0100, David Kastrup wrote:
> I'd suggest that column 1 in Fortran is just called column 1 because
> column 0 contains the ASA print control character
> <URL:http://en.wikipedia.org/wiki/ASA_carriage_control_characters>,
> but then I'd sound silly...

I don't think ASA carriage control characters were part of the original
Fortran (which turns 50 in February).

I think it has always been column 1 because of punch cards.  The idea of
zero starting numbers is a much newer invention than Fortran.

-- Pinski

Re: Emacs and GFortran

[David Kastrup]

Andrew Pinski <pinskia@gmail.com> writes:

> On Wed, 2006-11-15 at 09:43 +0100, David Kastrup wrote:
>> I'd suggest that column 1 in Fortran is just called column 1 because
>> column 0 contains the ASA print control character
>> <URL:http://en.wikipedia.org/wiki/ASA_carriage_control_characters>,
>> but then I'd sound silly...
>
> I don't think ASA carriage control characters were part of the original
> Fortran (which turns 50 in February).
>
> I think it has always been column 1 because of punch cards.  The idea of
> zero starting numbers is a much newer invention than Fortran.

And it sounds like it is unique to Emacs, and not in the GNU error
message standard, anyway, so no need to further think about it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs and GFortran

[Richard Stallman]

GFortran and the GNU standards agree that column numbers start with 1,
so there's no issue here.