[Top][All Lists]
[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
- Re: pspp development, John Darrington, 2004/12/28
- Re: pspp development, Ben Pfaff, 2004/12/29
- Re: pspp development, John Darrington, 2004/12/29
- Re: pspp development,
Ben Pfaff <=
- Re: pspp development, John Darrington, 2004/12/29
- Re: pspp development, Ben Pfaff, 2004/12/29
- Re: pspp development, John Darrington, 2004/12/29
- Re: pspp development, John Darrington, 2004/12/29
- Re: pspp development, Ben Pfaff, 2004/12/29