Has anyone tried PDSOE (Eclipse) for OE 12 yet?

Posted by dbeavon on 18-Jun-2019 12:52

I've read the information that is available about OE 12 and I see a few notes about changes to PDSOE in OE 12.

I was wondering if anyone has started using it for day-to-day development yet.  Can you share your experiences?  At my company we aren't quite ready to migrate to OE 12 as a whole.  But perhaps for development purposes I suppose I could start using PDSOE v.12 to edit code. Are there any compelling changes that will make it more productive than what we have in OE 11.7?

One thing I keep hoping will be available some day is a way to build (compile) an entire OE project in a reasonable amount of time.  It is impractical to use the PDSOE IDE to compile anything more than a few programs at a time.  (Let alone a project with 1000 source files or more.)  Does OE 12 have a way to compile code?

I'm hoping there is a better way now; I saw that there was a referral to PCT in the link above ("What's new" ).  The reference is found under the "bundled third-party updates" (https://docs.progress.com/bundle/openedge-whats-new/page/Bundled-third-party-tool-updates.html ).  And I'm wondering if PCT is now integrated into PDSOE to facilitate the compiling of a project (ie. right-click and compile).  I suppose I can also use PCT outside of PDSOE, and keep compiling my code independently of the IDE.  However I'm not all that interested in PCT in its own right; I'm more interested in a better development experience in PDSOE that supports compiling ABL programs and projects

I suppose even if it doesn't compile code, OE 12 comes with a new version of Eclipse and that might be worthwhile.

Please let me know if anyone has tried it yet.  I think I have the OE 12 downloads available in ESD but haven't seen any discussion about PDSOE in the forums, nor heard any compelling reasons that would impact a developer's day-to-day work while programming ABL. 

Posted by Tushar Dhaka on 20-Jun-2019 06:42

Updated the link, it should work now.

Posted by Tushar Dhaka on 19-Jun-2019 09:04

As of now there are no significant improvements in compilation and building of PDSOE in 12.0, however we have plans to support incremental build, parallel build, etc in future releases. As of now, related work is in prototype phase and may not be made available for another couple of releases.

There were other improvements done in PDSOE though to make it more robust, many of which went into 11.7.5 service pack release. (Check out PDSOE's system's demo posted here for more details).

I suggest to to periodically checkout CVP. The work being planned for every quarter is posted there which you can monitor, provide feedback, suggestions or ask questions as to why we are working on something. This post hosts every products objective for the next quarter.

About Refactoring feature, it was retracted from 12.0 release and isn't planned for any future release yet. Likely we'll get back to it after providing compilation and build capabilities.

All Replies

Posted by Torben on 18-Jun-2019 16:16

You have been able to use Ant and PCT for years to build OpenEdge projects!

The only thing new is that now PCT is shipped as part of the OpenEdge installation.

Posted by dbeavon on 18-Jun-2019 17:08

>> only thing new is that now PCT is shipped as part of the OpenEdge installation

So there is no option to right-click "compile project with PCT".

Too bad.  One project of ours would take over an hour to do that in PDSOE as-is.

Posted by Matt Baker on 18-Jun-2019 17:24

If you have a build.xml in your project, you can build your project using that by right-clicking and selecting 'run as ant".  PDSOE won't recognize an ant based build directly, but you can certainly invoke it from within PDSOE.

Posted by dbeavon on 18-Jun-2019 17:44

Gotcha.  I'll have to look into that.  It would be nice if there were templates or something that would give us a headstart.

I think PCT will improve performance as long as it uses some multi-threading, and does the compilation work independent of the Eclipse IDE.  The built-in compile operations are slow because they are probably doing tons of interop with Eclipse (to decorate files in the project explorer, show errors in the output console, etc).  That and they are not making use of all the CPU cores.

Posted by Riverside Software on 18-Jun-2019 20:23

As Matt said, you can invoke your PCT build from PDSOE, and that will fork an Ant build, with no interaction with PDSOE (it will trigger exactly the same build as from your proenv). You'll also be able to use multiple threads to build OE projects (for procedures, not for classes).

Quick start guide: github.com/.../QuickStart

And feel free to ask questions here or report issues on GitHub.

Posted by Matt Baker on 18-Jun-2019 20:29

You might find this link useful for how to setup a project level builder using an ant script

help.eclipse.org/.../index.jsp

Posted by dbeavon on 18-Jun-2019 21:58

>> You'll also be able to use multiple threads to build OE projects (for procedures, not for classes).

Its a bit off topic but what's the problem with compiling OE classes in parallel?  I've never run into trouble as long as all the prior r-code in a project was cleared out as a first step.  

(I do realize that the compiler will not understand the dependency relationships between classes.   It will probably do a lot of duplicated work, whenever it is compiling stuff in a sequence that is not respectful of the class dependency relationships. )

BTW, the OE AVM within PDSOE doesn't do a great job with dependency relationships either.  I'd like to see this improved in PDSOE one day.  The "restart AVM" operation is something I use all the time, after deleting my r-code.  Otherwise the wrong OOABL "sticks" in memory and causes bogus compiler errors - possibly because of r-code which is outdated, or because the AVM simply gets confused by something it is keeping in its memory.

Speaking of bogus compiler issues, here is another one simple thing that happens all the time which is pretty annoying.  I copy one class to another and change the code (w/search/replace) rename the file (correctly) and save.  Then I use the "check syntax" operation to ensure that I did all the steps correctly.  But the first time I check syntax on my new class, it always tells me that I did something wrong (image).  But if I immediately check again then it tells me that my syntax is OK.  Whats up with that?   

On yet another note, has anyone tried the new refactoring stuff for OOABL?  I'm hoping there is something in OE 12 that will improve productivity, especially for those of us that did the work to start using OO.

Posted by Riverside Software on 19-Jun-2019 08:11

I've seen cases where parent classes were incorrectly written to disk, leading to runtime problems.

Posted by Mike Fechner on 19-Jun-2019 08:34

When two threads in parallel compile two child classes of the same super-class, the super-class r-code is written twice (by every thread one). This may lead to file access problems.

Posted by Tushar Dhaka on 19-Jun-2019 09:04

As of now there are no significant improvements in compilation and building of PDSOE in 12.0, however we have plans to support incremental build, parallel build, etc in future releases. As of now, related work is in prototype phase and may not be made available for another couple of releases.

There were other improvements done in PDSOE though to make it more robust, many of which went into 11.7.5 service pack release. (Check out PDSOE's system's demo posted here for more details).

I suggest to to periodically checkout CVP. The work being planned for every quarter is posted there which you can monitor, provide feedback, suggestions or ask questions as to why we are working on something. This post hosts every products objective for the next quarter.

About Refactoring feature, it was retracted from 12.0 release and isn't planned for any future release yet. Likely we'll get back to it after providing compilation and build capabilities.

Posted by Roger Blanchard on 19-Jun-2019 10:27

>  (Check out PDSOE's system's demo posted here for more details).

Invalid link

Posted by Jeff Ledbetter on 19-Jun-2019 11:00

We use PDSOE 12.0 along with the Roundtable TSMS 12.0 plug-in. Works great for targeted and incremental compiling as well partitioning compilations between the client and server.. . and you can also send the process to the background.

Posted by dbeavon on 19-Jun-2019 12:36

>> There were other improvements done in PDSOE though to make it more robust, many of which went into 11.7.5 service pack release. (Check out PDSOE's system's demo posted here for more details).

I think this (following) is the link which doesn't work above....  It is a link to a post in the the CVP group.

community.progress.com/.../58285

Posted by dbeavon on 19-Jun-2019 12:49

>> When two threads in parallel compile two child classes of the same super-class, the super-class r-code is written twice...

I've never noticed the compiler writing an r-code that wasn't requested by the compile statement.

Just to be clear, are you saying that the super-class r-code will actually be written to disk or will be simply interpreted (compiled dynamically in memory) by the AVM?  I always assumed that any related/referenced classes are interpreted to the extent that they are necessary for compiling the targeted class.  But I didn't think that there would be anything stored on disk, unless explicitly requested.

Interpreting a super-class twice is a waste of CPU but doesn't cause serious failures.  Whereas the concurrent file-write problems are more serious.  Is it possible that Progress has already resolved this, and it is not longer an issue?  Otherwise do you know if it is documented somewhere in the KB (that classes may only be compiled one at a time across a given server or within a given output directory)?  I suppose a workaround would be to have concurrent compile operations that save their results into different output directories and then merge all the r-code files as a last step.

Posted by Laura Stern on 19-Jun-2019 12:56

Sorry, if I'm missing something, but if two threads end up compiling the same file (e.g., a common parent class), each will do the job it set out to do - compile the file and write out the r-code.  One thread doesn't know what the other is doing, so each will do its job.

Posted by Laura Stern on 19-Jun-2019 12:56

Sorry, if I'm missing something, but if two threads end up compiling the same file (e.g., a common parent class), each will do the job it set out to do - compile the file and write out the r-code.  One thread doesn't know what the other is doing, so each will do its job.

Posted by Shelley Chase on 19-Jun-2019 13:01

we recommend using multi-compile in a CI/CD environment. As Laura said, separate processes do not benefit from other compiler sessions. See docs.progress.com/.../MULTI-COMPILE-attribute.html

Posted by frank.meulblok on 19-Jun-2019 13:17

> One thread doesn't know what the other is doing, so each will do its job

> compile the file and write out the r-code.

Well, that's where the risk is, as that's where timing issues can happen: If both threads try to compile the same file at the same time, they try to write to same .r file at the same time.

That risk can be mitigated by giving each thread it's own temporary build location and merging those together into a final location. That way you trade in file contention worries for temporarily having duplicate files, and all you really need to make sure of is that you have eough free disk space for those duplicate files.

Posted by dbeavon on 19-Jun-2019 13:53

Wow, this forum keep losing my posts.  Here it goes again....

@Laura.  The question is about two processes that are simultaneously compiling a class file with a shared parent.  Do they both attempt to write the r-code of the parent class to disk?  

I did a test and it appears that the parent class is getting written as well.  Even though it is not explicitly requested in the COMPILE statement.

This is a bit of an inconsistency.  I noticed that other relationships (*member* fields within a class) cause compilation to happen (and generate compiler errors if the related member class is invalid).  But unlike the parent class ("is-a") the classes referenced in member fields ('has-a") are NOT written to disk.

It would be nice if there was a COMPILE option that specified that parent r-code should NOT get written and only write the class that is the direct target of the COMPILE operation.

(I suppose some day OpenEdge customers won't be writing our own custom build engines anymore, and we won't have to care.  Everyone says OE ABL is such an easy platform to work with but nobody points out how we all have to become experts in the inner workings of compilers. )

Posted by Matt Baker on 19-Jun-2019 14:15

The builder (any builder really) in Eclipse is single threaded.  Workspace resources (files on disk) can be read, but not modified outside the thread that owns the workspace lock while the builder is running.  But what can happen is that a class can get compiled to multiple locations in PDSOE.  This has been talked about before, and the multi-compile option doesn't address it.

The parent class writing can become a problem if you have multiple PDSOE projects, each with their own compile destination directory.  When a class in one project (project a), references a class in another project (project b), any referenced classes get compiled twice.  Once by the builder for where the class "lives", and once by the builder where it is referenced.  This leads to cases where a class is compiled twice to different locations.    The one that "wins" at runtime is totally based on PROPATH setting.  Your suggestion dbeavon to request that the compiler only write out exactly what was referenced could assist with this scenario.

And it is not just the parent class.  Any class referenced that isn't compiled, will get written out.

Posted by Riverside Software on 19-Jun-2019 14:15

> Just to be clear, are you saying that the super-class r-code will actually be written to disk or will be simply interpreted (compiled dynamically in memory) by the AVM?  I always assumed that any related/referenced classes are interpreted to the extent that they are necessary for compiling the targeted class.  But I didn't think that there would be anything stored on disk, unless explicitly requested.

RCode of the parent classes is written to disk. If two threads compile at the same a class (different in each thread) with the same parent class, then they will both write the rcode of the parent class. It's a not so common situation, but it can happen.

Posted by Tim Kuehn on 19-Jun-2019 14:23

@dbeavon - an issue I ran into a while ago was that the compiler would create r-code for super classes along the current class even if the super-class files were in other projects and those projects had custom-specified build directories.

The net effect was that compiling a project which had a dependency on another project would result in the dependent project getting carpet-bombed with unwanted r-code. The "fix" for that would be to nuke the r-code in the dependency project before editing in order to ensure that I was running the correct r-code.

What *should* happen in such cases is any intermediate r-code generated by a compile process should be dropped into a temporary directory and then deleted when the compile is completed - or - the build location of the dependent project should be honored.

Tech support / PSC knows about this - I thought this would've been fixed by now.

Posted by Tushar Dhaka on 20-Jun-2019 06:42

Updated the link, it should work now.

Posted by Tushar Dhaka on 20-Jun-2019 06:42

Updated the link, it should work now.

Posted by OctavioOlguin on 21-Jun-2019 22:09

Still the links you [mention:e6e9d01b67bb4afe8fd539ea882df2ea:e9ed411860ed4f2ba0265705b8793d05] posted, won't work..

Posted by OctavioOlguin on 21-Jun-2019 22:09

Still the links you [mention:e6e9d01b67bb4afe8fd539ea882df2ea:e9ed411860ed4f2ba0265705b8793d05] posted, won't work..

Posted by Tushar Dhaka on 24-Jun-2019 04:50

Might be access issue with the CVP forum. You can check it here,

[View:/cfs-file/__key/communityserver-discussions-components-files/19/System_2700_s-Demo-PDSOE.mp4:550:412]

This thread is closed