Error Parser does not work, even in SSX3
SunSudio Express (December 2006 release) introduces some interesting new features, but there are still problems. For the first time, I was able to debug Fortran 90 applications in Linux, but debugging is still very limited. Furthermore, the Fortran error parser does not work, even when compiling using Sun's f95 compiler. This is a heavy disadvantage. I assume that Fortran error parsing is not supported on Linux, although the tutorials don't make this point clear: In the Options window, there are settings concerning C/C++ (and its parser), but there are no similar options for the Fortran parser, even in "Advanced Setings" (which are similar to the old Options window). My Linux system is Debian 3.1 (Sarge), with JDK 1.5.0.09.
I don't think that I'm doing something wrong, but I want to ask, just to be sure: has someone had seen the Fortran error parser working on Linux? What about Fortran word completion?
[932 byte] By [
PAPa] at [2007-11-26 13:37:34]
# 1
I'm not even sure that Fortran is supported by the IDE that comes with Sun Studio Express 3...
# 2
> I'm not even sure that Fortran is supported by the IDE that comes with Sun Studio Express 3...
Well, Fortran is supported, but only partially. It is a pity, since Fortran 95 is way more preferrable than C/C++ for Numerical Analysis programs. Furthermore, Sun Fortran compiler seems to be able to produce a faster executable than several other Fortran compilers; it should be totally suppored by the IDE.
Currently, the Eclipse plugin called "Photran" has better Fortran support than SSX. Eclipse's Fortran parser works very well with gfortran, g95, F, and Intel Fortran compilers; in SSX, it seems that the Fortran error parser does not wok at all. Unfortunately, the Fortran debugger doesn't work well both in Eclipse and SSX.
PAPa at 2007-7-7 22:24:45 >
# 3
> SunSudio Express (December 2006 release) introduces some
> interesting new features, but there are still problems. For the first time,
> I was able to debug Fortran 90 applications in Linux, but debugging is
> still very limited.
This is good to know that you were able to debug a f90 application
on Linux. What problems do you see? Please, report them, and we
will file them as bugs or RFEs (requests for enhancements).
> Furthermore, the Fortran error parser does not work, even when
> compiling using Sun's f95 compiler.
Yes, you are right, this feature does not work yet.
> This is a heavy disadvantage. I assume that Fortran error parsing
> is not supported on Linux, although the tutorials don't make this
> point clear:
Yes, it does not work yet on all platforms.
> In the Options window, there are settings concerning C/C++ (and
> its parser), but there are no similar options for the Fortran parser,
> even in "Advanced Settings" (which are similar to the old Options
> window).
There will be similar options for Fortran.
> My Linux system is Debian 3.1 (Sarge), with JDK 1.5.0.09.
JDK 1.5.0.09 is ok.
We do not target Debian system, but we assume everything
should work there (we test on Red Hat and SUSE).
Good to know that our assumption is correct :-)
> I don't think that I'm doing something wrong, but I want to ask, just
> to be sure: has someone had seen the Fortran error parser working
> on Linux?
No. It does not work on Linux, and it does not work on other platforms.
> What about Fortran word completion?
No, this feature is not implemented yet.
Thanks you for trying Sun Studio 12 Express release and for your report.
Nik
# 4
> This is good to know that you were able to debug a
> f90 application
> on Linux. What problems do you see? Please, report
> them, and we
> will file them as bugs or RFEs (requests for
> enhancements).
There is only basic Fortran debugging on Linux, in the sense that the debugger stops in breakpoints, and step operations work as expected (especially "Step Into" works now; this was not the case in previous releases). Unfortunately, that's all. The "Local variables" window is almost always empty, and you cannot add "Watches". Furtrhermore, public variables declared in modules are considered as "not defined in the current scope" (which is not true). In other words, it is impossible to examine the value of variables. In rare cases when a variable is visible in the "Local variables" window, there are additional problems: strings are seen as tables of hexadecimal numbers. This heavily reminds C's representation of strings, so I suspect that the debugger treats the executable as if it was created by C/C++, not by Fortran.
> We do not target Debian system, but we assume
> everything
> should work there (we test on Red Hat and SUSE).
> Good to know that our assumption is correct :-)
Indeed, your assumption is correct.
Thank you for your information concerning current state of Fortran support. I like SunStudio, mainly because of the "dependency checking" ability, which is able to detect which modules of a large program are affected by user's changes, so only the necessary modules are recompiled. I'm planning to test all express releases on Debian systems. I look forward to see better Fortran support in SunStudio.
# 5
An Express release is a "technology preview", it's not even an "early access".
Fortran error parsing and debugging will be fully supported in the IDE by FCS.
Meanwhile, you should be able to debug fortran through the dbx commandline
which is accessible by choosing Window->Debugging->DbxConsole.
# 6
We just converted the Fortran compiler to use dwarf by default and dbx
still has a few known bugs related to that. I'm not sure the problems you
are seeing are related to that, but you could try compiling with the
option: -xdebugformat=stabs and see is some of your problems go away.
--chris
# 7
> Meanwhile, you should be able to debug fortran through the dbx commandline
> which is accessible by choosing Window->Debugging->DbxConsole.
I don't see any difference. Typing "display <variable> in dbx console seems to be equivalent to add a variable to the watchlist, using the IDE. It doesn't work either way.
> We just converted the Fortran compiler to use dwarf
> by default and dbx
> still has a few known bugs related to that. I'm not
> sure the problems you
> are seeing are related to that, but you could try
> compiling with the
> option: -xdebugformat=stabs and see is some of your
> problems go away.
>
> --chris
Indeed, adding -xdebugformat=stabs helps: string variables are now shown correctly. Thank you for the hint, it's really useful.
Using this flag, public variables defined in a USEd module are present in the "Local Variables" window. However, some of them can be added to the watchlist, some cannot (if you try to add some of the variables to the watchlist, the error window "dbx: <variable> is not defined in the scope" appears).
Btw, debugging is not possible if optimizations flags are present.
# 8
I can also reproduce the problem with "Locals" (empty "Locals" view) on
Solaris using a sample project "RoundOffErrors" (one of two Fortran
sample projects that we have inside IDE).
Sometimes the "Locals" view shows local variables, but usually it is empty.
I think the root of this problem is that there is an exception (if you see a red
circle in the right bottom corner of the main IDE window - this is a sign, that
an exception happened).
Sometimes it is a NullPointerException, but usually it is
ArrayIndexOutOfBoundsException, like this one:
java.lang.ArrayIndexOutOfBoundsException: 1 >= 1
at java.util.Vector.elementAt(Vector.java:432)
at javax.swing.table.DefaultTableColumnModel.getColumn(DefaultTableColumnModel.jav a:276)
at org.netbeans.modules.viewmodel.TreeTable.saveWidths(TreeTable.java:289)
at org.netbeans.modules.viewmodel.TreeTable.setModel(TreeTable.java:107)
[catch] at org.netbeans.spi.viewmodel.Models$1.run(Models.java:115)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java: 242)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:16 3)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
Thanks,
Nik
