Proparse server config, 'prorefactor' directory

Jurjen, I'm working on the proparse.jar server configuration stuff.
I'm going to set it up so that the client can request the server to load a project's settings. This way, the client (like Prolint) can dump the project configuration automatically at start up time, and get the server to read that.
The server process will always require its './prorefactor' directory for reading and writing various configuration and other files.

PUB binary files directory

I see the OpenEdge Architect project configuration: "Save r-code (also enables include file tracking)". Proparse also tracks include files with its .pub files: it keeps include file time stamps in there.

Another consideration is for super classes. Proparse allows super class information to be cached, but equally important is that parse unit data (like super class information) is loaded much more quickly from .pub files than it is from source code.

Now, I was going to look into making the storage of the .pub files optional for proparse.jar, but I have another idea that I hope you will agree is OK. In the case of a Prolint session running (both server and client) on a developer's workstation, Prolint can simply take care of clobbering the entire 'pubs' directory at any time that is appropriate. This could be at session startup/shutdown, or even at the end of every Lint Run if you wanted.

This way, you get the advantage of the .pub files when it counts, but you can also make sure that proparse.jar is not storing so much data that it becomes a disc space concern on the developer's workstation.

Does that sound OK? At least for the short term, let's go with that and see how it works out.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jurjen's picture

clobbering?

I do not know what you mean by "Prolint can take care of clobbering". According to different dictionaries, clobber is slang for clothes, or a game, or beat up or criticize etc etc. I cannot compute an answer to your question :-)


tamhas's picture

One suspects the intent was

One suspects the intent was CLOBbering


john's picture

Re: clobbering?

LOL. That's interesting. My very old Webster's dictionary doesn't even have the word clobber. But, my Microsoft Encarta 2001 says "to hit somebody or something with great force... to deal with somebody or something in a harsh or critical way". Now here's the funny bit: You had me thinking that maybe 'clobber' was only a word that I used, because I used to work with another guy who used that word for 'delete'. But Encarta has a "computer dictionary" (cool!) and it says: "To destroy data, generally by inadvertently writing other data over it." So it's not completely uncommon! :)


jurjen's picture

so "clobbering" means

so "clobbering" means "delete" and "pubs" is "temp" and the "prorefactor" directory is a settings directory for proparse.... ok I got it :-)

I've understood from an earlier thread that this prorefactor directory has to be a subdirectory of the working dir, is that right? Is that the working dir of the proparse server process or the working dir of the progress process? Can Prolint communicate with the proparse server to set and/or get the location of the prorefactor dir?


john's picture

Re: so "clobbering" means...

LOL. Smart_ss! :) That's the trouble with several projects that have grown and merged over years!

The 'pubs' directory is a cache of syntax trees. In many cases (ex: search) it could save us from having to re-parse files, and really speed things up. So, it's not really 'temp', but at the same time, there's no harm in clobbering it.

Yes, 'prorefactor' has to be a subdirectory of the working directory of the server. We can't change the prorefactor dir, but if it's of any use, I could add something to the server so that the client can request to find out what directory it's running in.