RJLRef: $PH/COOL-BDE/pr_utilRefactoring
Hi Scot.

I don't believe R Almonte ever started this study of 
pr_util simplification by eliminating pr_init. 

A related task is to ignore version numbering in pfkeys. 
I.e., widen the row number part of the hcg_key type.

The key manipulation routines are all parameter-driven:
E.g.
	grep '_SIZE|_LEN' $RBGB/pr_util_nolog/*.{c,h} 

Bob Lechner


Forwarded message:
> From lechner@cs.uml.edu  Wed Mar 23 18:01:19 2005
> Subject: Re: Gen upgrade...Deal -OK -but first, does your interp. of req'mts == mine?:-)
> To: ralmonte@cs.uml.edu (Robert Almonte)
> Date: Wed, 23 Mar 2005 18:01:15 -0500 (EST)
> Cc: lechner@cs.uml.edu (Bob Lechner), sfrye@cs.uml.edu (Scot Frye)
> 
> Deal - OK, 
> I would welcome that redesign (not refactoring) effort. :-)  
> 
> But first, does your interp. of req'mts == mine?:-)
> 
> What do you mean by 'a cvs version of gen ver 12'?
> Checking out the current repository is fine - we all can
> share it and check in updates. But a separate CVS repository
> is counter-productive - it will cause more grief later.
> 
> Your work could proceed in parallel with 
> chgen updates that generate code that tracks bde/pr_util,
> by tagging it as a RAlmonte branch for later merging.
> 
> 
> pr_init() removal problem is not so much from applications, 
> which only call pr_init a few times or once  and then 
> call pr_load which will take on pr_init functions 
> after file_list is constrained to one-and-the-same file_name.
> 
> The real problem is that other parts of the pr_util library
> (esp. in pr_load.c and pr_log.c) depend on the results of 
> and/or call pr_init.
> This dependence is indirect: i.e., pr_init has side effects 
> on hcg_structs that are followed by other pr_* functions 
> that read this data. What would help size the effort is counting 
> (grep|wc) all read and update uses of the vars set by pr_init
> throughout pr_util. I think bde only refers to them indirectly
> through pr_add() calls; a few exceptions could be caught
> by grep bde/src/*.cc.
> 
> I believe the pr_init removal task ought not to ignore 
> another one: that of replacing hcg_struct references and updates by 
> metatable (from .msdat) content refs and updates.
> I think updating .msdat tables SV/TT/TA/TS/VV in synch with
> hcg_struct tables is the first step. I think we ought to add this
> new task to pr_load when asking it to do pr_init()'s job of 
> keep track of min and max pkey range and actual rcount 
> of rows loaded (for each table) before pr_load is called.
> Metadata tables become ghost variables, and references to
> hcg_structs can be converted to them gradually later.
> 
> Bob Lechner
> 
> 
> > From ralmonte@cs.uml.edu  Wed Mar 23 17:24:28 2005
> > To: "Bob Lechner" <lechner@cs.uml.edu>
> > Subject: Re: Gen upgrade...Deal
> > 
> > Deal,
> > I will document how to eliminate pr_init()...
> > 
> > ----- Original Message -----
> > From: "Bob Lechner" <lechner@cs.uml.edu>
> > To: "Robert Almonte" <ralmonte@cs.uml.edu>
> > Cc: "Bob Lechner" <lechner@cs.uml.edu>
> > Sent: Wednesday, March 23, 2005 11:51 AM
> > Subject: Re: Gen upgrade...you are welcome - see my asgnt3 email on pr*.dif
> > files
> > 
> > 
> > > > From ralmonte@cs.uml.edu  Tue Mar 22 17:01:55 2005
> > > > From: "Robert Almonte" <ralmonte@cs.uml.edu>
> > > > To: "Bob Lechner" <lechner@cs.uml.edu>
> > > > Subject: Gen upgrade...
> > > > Hi Prof. Lechner,
> > > >
> > > > I had setup a cvs version of gen ver 12 at
> > > > /usr/proj3/case/04f522/ralmonte/genv12
> > > > I added your username: 'lechner' as writers.
> > > > I did the first import (module src) from /sjaganat/src,
> > > > but I haven't try after that.
> > > >
> > > > I test it from my PC using eclipse IDE and it was really easy to setup
> > > > (eclipse has everything integrated, don't need to setup ssh
> > > > independently as the case with 'IntelletJ' that was mention in the
> > email).
> > > > I read your email about gen_pr050316...
> > > > Could I start using the 'pr_delete.dif' that you created?
> > > >
> > > > This will make easier for me.
> > > >
> > > >
> > > YOu can use any of the pr_*.dif files.
> > > However, I expect to assign them to 05s523 students.
> > > Do you want to study ways to eliminate pr_init() instead?
> > > (defined in pr_load.c, called in pr_log and pr_load.c and apps.)
> > >
> > > Bob Lechner
> > 
>