In Eclipse I cannot find an easy way to generate a listing of an ABL program that shows the most interesting facts about the program, insofar as the compiler is concerned.
For example, one of the most interesting facts that someone can discover about one's own ABL program is where the compiler decides to start new OE transactions or "sub transactions" (provided the programmer doesn't explicitly start one themselves with a DO TRANSACTION block). This can sometimes feel a bit like black magic to a new developer or to someone who is trying to transfer their skills from another database programming platform.
(It might be just me, but I always found it a bit scary that the compiler would "help" the developer to create implicit transaction scopes - as if such a decision was so uninteresting that no ABL developer should need to know or care about such things. I've occasionally found myself bewildered by the behavior of some ABL program where the work is undone in only one of several iterations of a FOR EACH loop. I.e. some work on a business document's data is undone, while it is committed in other iterations. This is normally a scenario where the developer was uninterested and the compiler was demonstrating its "helpfulness".)
In any case, the compiler listing is really, really useful when reviewing programs written by developers who make use of implicit ("helpful") transactions that are created at the compiler's discretion. The compile listing will also help to discover the scoping of other items used in a program, like record buffers.
I have used PDSOE for over a year and haven't discovered where the compiler listing feature is hidden yet. I normally have to open a command window and generate the listing for a program manually. In the perfect world, these kinds of annotations would show up immediately while editing the code in the IDE itself (like a "code lens" in visual studio).
I've found preprocessor output - but not the compile listing. Any pointers would be appreciated. I am certain that I'm overlooking something...
You should have a look at OEDT: https://www.hh-berlin.de/oedt/
A commercial add-on for PDSOE. Among many other features, this adds the listing, debug listing, xref, ...
You should have a look at OEDT: https://www.hh-berlin.de/oedt/
A commercial add-on for PDSOE. Among many other features, this adds the listing, debug listing, xref, ...
Thanks for the pointer Mike. I am grateful to know that I didn't overlook this obvious missing feature.
Is there any possibility of selling this to Progress too? It seems like this should be bundled with PDSOE to begin with.
I should have expected it would be in a third-party tool. Some other favorites of mine:
- Wouldn't you like to compile your ABL code now that you've finished writing it? Use PCT!
- Wouldn't you like to manage your database's performance problems now that people are connecting to it? Buy ProTop!
- Do you have a gigabyte of xml-xref? And wouldn't you like to get information from it and make sense of it now that it has been generated? Buy RoundTable!
I guess these types of things (compiling / analyzing ABL code, and managing databases) are not part of the core mission of Progress, so third parties have to pick up where OpenEdge leaves off.
And not to forget Riverside's SonarSource analysis Plugin for OpenEdge.
By the way - I'll be giving an overview of the tools used at Consultingwerk during a break-out session at PUG challenge Americas in a few weeks.
We agree that is an important option. We built the ability to generate and view the listings, xref, and debug in to our Roundtable plug-in as well. :)
Thanks again Jeff and Mike. I hope Progress will move forward with more investments in their OpenEdge tooling; hopefully one day it too will have built-in support for features like the ones you mentioned. Adding features like ABL compiler listings, faster project compilation, and source code (xref) analysis doesn't even seem that innovative to me. These are just the obvious next steps.
It is odd that Progress is willing to spend enormous sums to purchase developer tooling for unrelated platforms (like $250 million on Telerik for .Net) but it invests comparatively little in its own OpenEdge. I really can't understand why Progress leaves such massive gaps in their own OpenEdge tooling.
If Progress has any long-term plans for OpenEdge, it should really consider making some new acquisitions in that ecosystem as well. Otherwise it will appear that they are redirecting their new investments to platforms like .Net. This will only encourage Progress customers to do the same. (The recent "CDC" features in OE 11.7 makes it very apparent that Progress customers are now enabled and encouraged to migrate their data elsewhere, along with the related applications. I don't know how this serves the best interests of Progress, but it certainly doesn't do anything to help the average OpenEdge ABL developer with their day-to-day software development work.)
The purchase of Telerik was not just for the .NET controls but for the Telerik Platform which allows for the cross platform development for mobile apps. I believe this was a good acquisition as Progress had previously failed at a mobile solution for its partners.
As far as CDC I am not sure how this encourages their customers to move elsewhere...I must be missing something. We had built our own CDC solution years ago and would have loved to have had this feature back then. It was not for moving data outside of our OE DB but from DB to DB. We also have customers that do move data from OE to SQL just for the purposes of SQL reporting where this would have helped as well.
I do agree that that more investments in tooling would be great.
Yes, I think more OE tooling would be fantastic. I suspect Progress customers who start using the Telerik technologies will tend to move larger sections of their business systems into those technologies after they get their feet wet (especially once they see how great some of the .Net developer tooling can be, and how it can significantly improve developer productivity.)
Your statement about using CDC to move data away from OE "just for the purposes of SQL reporting" is actually making my case. Insofar as the "reporting" (output) side of things go, we should not belittle that. The reporting/output side of things can be very large if you are including far-ranging technologies for search, reporting, data warehousing, etc.
CDC is intended for a number of other use-cases besides reporting such as sending data to "data lakes" and other large-data analytic systems.
OEDT is a great product, I consider it a must have.
It's a pity that PDSOE does not offer that kind of functionality out-of-the-box.