Re: pspp development

[John Darrington]

On Tue, Dec 28, 2004 at 09:15:41PM -0800, Ben Pfaff wrote:

     What organization do you think would work well?  I've spent the
     last few minutes trying to come up with a better structure, and
     this is what I have so far:
     
         .:
         CVS/       Makefile.am  data-io/      foo     language/  main.h   ui/
         ChangeLog  Makefile.in  data-mgmt/    glob.c  lib/       math/
         Makefile   commands/    expressions/  glob.h  main.c     output/
     
         ./CVS:
         Entries  Repository  Root
     
         ./commands:
         command.c    command.h   dictionary/  procedures/  xforms/
         command.def  ctrl-flow/  io/          utilities/
     
         ./commands/ctrl-flow:
         do-if.c  do-ifP.h  loop.c  repeat.c  repeat.h
     
         ./commands/dictionary:
         apply-dict.c   numeric.c      sysfile-info.c  value-labels.c  weight.c
         formats.c      rename-vars.c  temporary.c     value-labels.h
         mis-val.c      sample.c       title.c         var-labs.c
         modify-vars.c  split-file.c   val-labs.c      vector.c
     
         ./commands/io:
         data-list.c  file-type.c  inpt-pgm.c  matrix-data.c
         data-list.h  get.c        list.q      print.c
     
         ./commands/procedures:
         aggregate.c   correlations.q  descript.c  flip.c         means.q   
t-test.q
         autorecode.c  crosstabs.q     examine.q   frequencies.q  oneway.q
     
         ./commands/utilities:
         copyleft.c  date.c         file-handle.q  permissions.c  settings.h
         copyleft.h  file-handle.h  include.c      set.q
     
         ./commands/xforms:
         compute.c  count.c  recode.c  sel-if.c
     
         ./data-io:
         data-in.c   dfm-read.h   format.def  pfm-write.c  sfm-write.c
         data-in.h   dfm-write.c  format.h    pfm-write.h  sfm-write.h
         data-out.c  dfm-write.h  pfm-read.c  sfm-read.c   sfmP.h
         dfm-read.c  format.c     pfm-read.h  sfm-read.h
     
         ./data-mgmt:
         case.c  casefile.c  dictionary.c  val.h  vars-atr.c  vfm.h
         case.h  casefile.h  dictionary.h  var.h  vfm.c       vfmP.h
     
         ./expressions:
         evaluate.c  expr.def  optimize.c  parse.c  private.h  public.h
     
         ./language:
         getline.c  lexer.c  q2c.c       subclist.h
         getline.h  lexer.h  subclist.c  vars-prs.c
     
         ./lib:
         algorithm.c  alloc.h        filename.c  hash.h   pool.c  str.h
         algorithm.h  bitvector.h    filename.h  magic.c  pool.h  version.h
         alloc.c      debug-print.h  hash.c      magic.h  str.c
     
         ./math:
         factor_stats.c  group.c  group_proc.h  levene.h  misc.h     moments.h  
sort.h
         factor_stats.h  group.h  levene.c      misc.c    moments.c  sort.c     
stat.h
     
         ./output:
         ascii.c  devind.c  font.h        html.c   log.h     output.h      
som.c  tab.c
         charts/  devind.h  groff-font.c  htmlP.h  output.c  postscript.c  
som.h  tab.h
     
         ./output/charts:
         barchart.c     cartesian.c  chart.h      piechart.c
         box-whisker.c  chart.c      histogram.c
     
         ./ui:
         cmdline.c  cmdline.h  error.c  error.h
     
     I'm not really happy with this yet, and it's important to get it
     right (or close to it) the first time, because CVS does not deal
     with moving around files very well.
     

True.  Perhaps the best approach would be to move only the modules we
are sure about (perhaps the "output" and "ui"  directories), and leave
the rest until we have a better understanding of what we're doing. (or
else move to a better SCM tool such as arch or aegis).

I believe that drawing a dependency diagram is the best way to see how
things should be arranged (which is probably only possible after one
has created a working Makefile).  Maybe you've already done this.


1. Perhaps subclist.[ch] should be tidied up a bit, (renamed) and put in
   the same directory as hash.[ch]  I had originally intended these only
   to be used to contain parameters of subcommands, but I'm frequently
   coming up with the situation where I want a general purpose linked
   list. 

2. The modules you've put in "math" are only used by commands, so
   perhaps "math" should be a subdir of "commands".

3. It might be a mistake to try to class things with too fine
   grain. For example, I'm not sure what the distinction between a
   "procedure" and a "utility".  There might be grey areas.


4. title.c doesn't seem to fit where you've put it.
   "command/utilities" would seem more appropriate. 



My $0.02 worth.


J'




-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://wwwkeys.pgp.net or any PGP keyserver for public key.

pgpSUiXMu3fgM.pgp
Description: PGP signature