[on codalist particularly for portability suggestion #4, but also #3,
which I think really should be part of the coda distribution, even if
gui tools that use it aren't.]

I'm glad you did this; thanks for making the class project code
available.  I hope my comments are helpful.

I tried to build this on FreeBSD (4-stable, more or less).  I had
several problems.  Basically the code uses ulong, and the Makefile
seems slightly broken.  Patches at end for what I did to get it to
compile.

Build/portability suggestions:

1. Use autoconf/automake, to autodetect posix threads etc, and provide
   install targets, --prefix and so on.

2. stick to standard types.  Since this uses gtk, you might use
   guint32 instead of ulong.  (I'm guessing that ulong is usage
   specific to GNU/Linux.)  (I'm glad you used gtk - that part
   required zero effort on my part, and the gtk-config script worked
   as intended.)

3. Structurally, it would be really cool to see a library which can
   fetch info, separately from the GUI processing, so scripting
   languages, etc. could use this same back-end code.  It looks like
   some of this separation is present, but I think it would be good to
   have a more explicit separation, and even build a library (with
   libtool, perhaps) for this part.

4. There are venus ioctl and rpc2 defs in the source tree.  I realize
   that these are files that rpc2 and coda might not install in
   $(prefix)/include, but this is a sign that those pacakges perhaps
   should install include files for those things that are 

5. I got lots of warnings when compiling.  If this compiles cleanly on
   GNU/Linux, I can do this again and mail them to you, but I'd
   recommend doing builds on a least one BSD variant as well.

Usability

1.  The program appears to have a serious file descriptor leakage
    problem.  After about 10-20 minutes, I started getting 'too many
    open files in system' messages.  I couldn't even run 'killall
    codavis'.  Fortunately I had some bloatware running, and exiting
    that and typeing !k<ret> quickly let me win the race for file
    descriptors.

2.  I set up with one volume, and (I think - I don't want to run this
    again until the fd leak is fixed) got a blue ? for status.
    Tooltips showed me #cml entries, which was nice.  But I didn't get
    any obvious visual feedback on whether cml was =0 or not, etc.  (I
    was write-disconnected the whole time.)  The README doesn't
    explain the designed behavior - I'm not sure what was intended.
    Having to mouse over the GUI IMHO defeats the purpose.


        Greg Troxel <gdt_at_ir.bbn.com>


--- codavis/src/af.h    Thu Nov 29 00:34:16 2001
+++ codavis.build/src/af.h      Thu Nov 29 09:38:01 2001
@@ -14,6 +14,8 @@
 #define __AF_H__
 
 #include <sys/types.h>
+typedef unsigned long ulong;
+
 #include <sys/stat.h>
 #include <unistd.h>
 #include <stdlib.h>



--- codavis/src/Makefile        Wed Nov 28 18:06:39 2001
+++ codavis.build/src/Makefile  Thu Nov 29 09:28:26 2001
@@ -18,7 +18,7 @@
 #USER_LINK_FLAGS = -lpthread
 #endif
 
-USER_LINK_FLAGS = -lpthread
+USER_LINK_FLAGS = -pthread
 
 #GTK_INC_FLAGS =  -I/usr/include -DNEED_GNOMESUPPORT_H -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include
 #GTK_LINK_FLAGS = -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -lart_lgpl -lgdk_imlib -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -lgthread
@@ -45,7 +45,7 @@
        $(CC) $(CPPFLAGS) $(CC_FLAGS) -c $(@:%.o=%.c)
 
 $(CODAVIS_ALL): $(CODAVIS_OBJS)
-       $(LINK_USER) -o $@ $(CODAVIS_OBJS) $(GTK_LINK_FLAGS)
+       $(CC) $(LINK_USER) -o $@ $(CODAVIS_OBJS) $(GTK_LINK_FLAGS)
 %.o: %.c
        $(CC) $(CPPFLAGS) $(CC_FLAGS) -c $(@:%.o=%.c)