pspp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pspp development


From: Ben Pfaff
Subject: Re: pspp development
Date: Wed, 29 Dec 2004 00:27:32 -0800
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

John Darrington <address@hidden> writes:

> 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 understand that sourceforge supports subversion now.  I wonder
whether savannah has any plans to support additional SCM systems?
CVS can be pretty limiting.

> 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.

I haven't drawn a dependency diagram or created a Makefile that
fits the above scheme.  But I don't think that the dependency
graph dictates how the source must be laid out.  It might help to
indicate a logical organization of course.

> 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. 

Do you mean a real linked list or the kind of dynamic vector that
subclist currently implements?  The properties are quite
different.  I have an actual linked list ADT in the works but
it's not ready yet.  If you'd like a dynamic vector, sounds fine
to me.

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

I was hoping to put only implementations of commands in
commands/, but the suggestion does sound reasonable.

> 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.

A procedure processes the active file, a utility does not.

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

Oops.  Yes, you're right, or perhaps even in command/io because
the title only affects output.
-- 
Ben Pfaff 
email: address@hidden
web: http://benpfaff.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]