Enhancement request for 'Debug View'

And here is the version for OE 10.2B which sits in %DLC%\oeide\eclipse\plugins\com.openedge.pdt.project_10.2.1.00\runtime

Hi Peter,

There is another possibility to view DebugList in OEA. I have made some customizations tom OEA allowing you to view the Preprocessed, Xref, Debug view and CompileListing of the files you are working on. The code and some documentation is attached. Please let me know if you found any bugs or have any other comment.

regards

Kees Vlasblom

Caesar Group

I heartily agree.

Since error messages refer to debug line numbers they need to be easy to find.  Currently they are not.

chuimonster wrote:
I heartily agree.
Since error messages refer to debug line numbers they need to be easy to find.  Currently they are not.

OK then cast your votes everybody!

I don't think anyone at PSC has taken a serious look at the ERS since

1997 or so.

Are you speking of compile time messages? Be aware that the stupid preprocessed view does not show anything when the file compiles. When else do you need that view? When the file compiles the preprocessor view is just decoration.

By the way: I looged that as a bug and got the feedback (in Oct/Nov) that this is about to get fixed in OE 10.3A (!). Right now nobody is talking about such a release. I can only hope that this means it will implemented in 11.0 or a 10.2B SP.

I was speaking of runtime messages.

Peter's code changes the debug view to show the debug line numbers by fiddling with _icompile.p to add the DEBUG option.  I did have to realize that I needed to restart OEA to get it to work but once I did that I got what I needed.

I can't quite understand Progress' attitude about this.  It's a pretty basic need.  If they're going to spit out DEBUG line numbers in all of their error messages they really need to provide a simple way to get to that line.  Not everyone writes everything using little tiny source files where the OEA line numbers and DEBUG line numbers always match up.  Some of us still use the occassional include file

OpenEdge Product Management reports on new ERS's quarterly and updates them as needed. PM continues to apply ehancements to each major/minor release of OpenEdge if applicable. Over the past year PM has managed to close 238 enhancements for different reasons (duplicates, not applicable, V9 (mature), completed, etc).

We will continue to review and update the enhancements as time permits.

Regards

Kristen

Hi Peter, Tom et al.

I understand your use case for needing Debug listing view. Are there other use cases for debug listing view that I am missing?

Since the first release of OpenEdge Architect, OEA debugger has provided source code debugging and the plan is to continue that model with the future enhancements like AppServer/ Webspeed debugging etc... The reason OEA  debugger has moved away from debug listing and focused on source code debugging is that -

• Most modern IDE's provide source code debugging
• The developer is more likely to be familiar source code as opposed to intermediate code that may or may not resemble the structure of the source code and hence the familiarity.

From this thread it is apperant that we missed a couple of things in the transition - When debugging from OEA, runtime error messages should provide the source line number (as  opposed to debug line numers).

I need your input on the following questions so we can validate OEA debugger strategy -

1. Do you agree with OEA debugger strategy of continuing to provide source code debugging for future enhancements like AppServer/Webspeed debugging, remote debugging etc...?
2. Do you think us providing (in a future release) runtime error messages with source line numbers resolve the need for debug listing view?

Let me know.

Thanks

Sunil.

sbelgaon wrote:
Hi Peter, Tom et al.
I understand your use case for needing Debug listing view. Are there other use cases for debug listing view that I am missing?
Since the first release of OpenEdge Architect, OEA debugger has provided source code debugging and the plan is to continue that model with the future enhancements like AppServer/ Webspeed debugging etc... The reason OEA  debugger has moved away from debug listing and focused on source code debugging is that -
Most modern IDE's provide source code debugging
The developer is more likely to be familiar source code as opposed to intermediate code that may or may not resemble the structure of the source code and hence the familiarity.
From this thread it is apperant that we missed a couple of things in the transition - When debugging from OEA, runtime error messages should provide the source line number (as  opposed to debug line numers).
I need your input on the following questions so we can validate OEA debugger strategy -
Do you agree with OEA debugger strategy of continuing to provide source code debugging for future enhancements like AppServer/Webspeed debugging, remote debugging etc...?

Yes that would be much more natural to the developer. It would be quite some reworking for you to do I suspect.

Do you think us providing (in a future release) runtime error messages with source line numbers resolve the need for debug listing view?

Yes it would.

In the mean time, please give us the debug listing view and don't take it out until WE are convinced we don't need it anymore (make it optional like the preprocessor view is now).

Thanks for listening!

-peter

Tom - speechless?1?

Busy.

Sunil, let me put in a more general pitch here that anything one can now get from a compile option should also be available directly from a tool in architect.  E.g., one should be able to click on something and see the transaction, record scope, and block listing from the end of COMPILE LIST and there should be a more reader friendly and filterable version of the COMPILE XREF output.

Sunil, when looking at enhancements for the way applications are compiled, please review also the selection of files. Not every .w, .p or .cls file is meant to get compiled.

There are templates, scratch files, migration routines, old sample code in most of the workspaces that I've seen. Usually those files don't compile without errors. So a huge amount of red X's usually pollutes the resource view - disturbing the eye when searching for important compile errors.

A "compile" checkbox on the property sheet of the file AND folder resource would resolve that issue.

Also compilation by working set would be great.

I can vouch for that -- my projects are certainly cluttered up with all sorts of trash that is too useful to delete but not really expected to compile at the moment.

FWIW, I'd favour something in the file itself, that the compiler would recognise as an override to the general COMPILE statement it's using. That way it's not OEA dependent (not that OEA dependency is bad, but what about batch compiles?). I've been thinking about a @compiler-option() annotation/directive that allows the setting of compiler options from with the source code.

Something like:

@compiler-option(md5="true", saveAs="%FILENAME%_%PROCNAME%").

Or a COMPILER-OPTION directive like the ROUTINE-LEVEL one.

-- peter

FWIW, I'd favour something in the file itself, that the compiler would recognise as an override to the general COMPILE statement it's using. That way it's not OEA dependent (not that OEA dependency is bad, but what about batch compiles?). I've been thinking about a @compiler-option() annotation/directive that allows the setting of compiler options from with the source code.

Sounds like a very great idea! Because it will guarantee that these settings will be versioned and distributed with the file.

BUT...

When it's a template, the markup needs to be removed from the file... How can we automate this (without XFTR)?

The check syntax option probably should still check those files when requested (so the COMPILE statement would need and override).

And certainly the evaluation of this "flag" should be fast, not waste minutes of compile time. So maybe Eclipse could cache that somewhere.

One of my concerns about something in the file is the overhead of having to open and read the file.

One of my concerns about something in the file is the overhead of having to open and read the file.

That certainly can be cached in the workspace (and refreshed when a change in the source file is detected).

But the more I think about the fact that the setting will be transported with the file is really neat.

Can't cache it for a batch compile and one has to try compiling it before there is anything to cache.

I'd be a lot more interested in the annotation if it came along with some options.  This might include

1) Strict versus not strict flags.

2) Deprecated usage warnings

3) Automatically generate XREF

4) Suppress certain kinds of warnings.

etc.

Now we've finally hijacked Peter's thread because a batch compile certainly is not related to an OpenEdge Architect enhancement request.

I'm more concerned about the behaviour within the IDE - not a batch compile which is usually a build / deployment topic and these files the I am thinking about shouldn't get deployed. And that's an SCM topic - and not of PSC's concern.

But I agree the options you've listed would be nice to have, maybe prio 2.

pjudge wrote:
I've been thinking about a @compiler-option() annotation/directive that allows the setting of compiler options from with the source code.

If you do that, I'd like to have a run-time-checkable setting for code I use as persistent & super procedures, and embed the functionality in with the RUN statement. 

3) Automatically generate XREF

I guess I'd prefer to have that as a generic workspace / project setting. If you're thinking about your batch compile, you are basically already able to do this as an option to the COMPILE statement.

4) Suppress certain kinds of warnings.

That is a cool thing. It could actually go down to the source code line level, like acknologing that you are aware of an issue that raises a compile time warning and don't need to hear about it over and over again.

Another good compiler option would be "verbose".  Most of the time, having the compiler simply point at the relevant line is enough for me to see the mistake and know what to do to fix it, but occasionaly one just doesn't see the error.  At those points it would be nice to be able to get the compiler to say "So, I'm parsing this define dataset statement and I'm expecting a name and you are giving me a FOR so, you know, there just isn't much point in my reading anything until I get to the period, is there?"

Today we are celebrating the 3rd birthday of the reasonable enhancement request.

Does anywhere know where PSC have hidden this in OE 11? We still need this after three years

All attendees of this EMEA PUG Challenge presentation will receive a free copy of the requested functionality...

http://www.pugchallenge.eu/index.php?option=com_content&view=article&id=245&Itemid=185

mikefe wrote:
All attendees of this EMEA PUG Challenge presentation will receive a free copy of the requested functionality...
http://www.pugchallenge.eu/index.php?option=com_content&view=article&id=245&Itemid=185

That is very nice but does not answer my question.