[net.news.b] The order in which newsgroups are presented by readnews

solomon@crystal.ARPA (01/02/84)

I've made a small change to readnews to present newsgroups in the order
they are listed in the user's .newsrc file, rather than the order they
are listed in ACTIVE.  I wrote a procedure sortactive() that creates a
copy of ACTIVE sorted in a new order, and makes the rest of readnews()
think it is the "real" active file.  The changes follow.  There are a couple
of design decisions you may like to change:  First, the copy of ACTIVE
is put into $HOME/active and not removed on exit.  I did that partly
out of laziness, and partly for debugging purposes.  The copy should
probably be put in /usr/tmp and removed on exit.  Second, "new" groups
(those listed in ACTIVE but not .newsrc) are sorted to come up first.
The idea is that the user probably wants to learn about the new groups
right way.  He can either Unsubscribe, or (after leaving readnews) edit
.newsrc to put the new groups where he wants them.

By the way, the added overhead on startup seems to be less than a second
(on a lightly loaded VAX 780).

Here are the changes:  first a call to sortactive() in readnews() and
then the function itself, which I put at the end of rfuncs.c.

*** orig/readnews.c	Fri Oct 28 19:28:05 1983
--- ./readnews.c	Mon Jan  2 10:45:35 1984
***************
*** 234,239
  		}
  		fclose(rcfp);
  	}
  	actfp = xfopen(ACTIVE, "r");
  
  #ifdef DEBUG

--- 234,240 -----
  		}
  		fclose(rcfp);
  	}
+ 	sortactive();
  	actfp = xfopen(ACTIVE, "r");
  
  #ifdef DEBUG

*** orig/rfuncs.c	Fri Oct 28 19:28:14 1983
--- ./rfuncs.c	Mon Jan  2 10:56:27 1984
***************
*** 563,565
  	}
  	return -1;
  }

--- 563,623 -----
  	}
  	return -1;
  }
+ 
+ /*
+  * sortactive - make a local copy of the active file, sorted according
+  *   to the user's preferences, according to his .newsrc file.
+  * Marvin Solomon, University of Wisconsin, 1/2/84
+  */
+ 
+ struct table_elt {
+ 	long actpos, rcpos;
+ };
+ 
+ static rcsort(a,b)
+ struct table_elt *a, *b;
+ {
+ 	return(a->rcpos - b->rcpos);
+ }
+ 
+ sortactive()
+ {
+ 	char newactivename[BUFLEN], line[BUFLEN], *strcpy(), *p;
+ 	register FILE *newactive, *actfp;
+ 	struct table_elt table[LINES];
+ 	int nlines = 0, i;
+ 	long actpos;
+ 
+ 	/* make a new sorted copy of ACTIVE in the user's home directory */
+ 	(void) sprintf(newactivename,"%s/active",userhome);
+ 	newactive = fopen(newactivename,"w");
+ 	if (newactive == NULL) {
+ 		perror(newactivename);
+ 		return;
+ 	}
+ 
+ 	/* look up all the lines in ACTIVE, finding their positions in .newsrc */
+ 	actfp = xfopen(ACTIVE, "r");
+ 	actpos = ftell(actfp);
+ 	while (fgets(line, sizeof line, actfp) != NULL) {
+ 		if (p = index(line, ' ')) *p = 0;
+ 		table[nlines].rcpos = findrcline(line);
+ 		table[nlines].actpos = actpos;
+ 		nlines++; actpos = ftell(actfp);
+ 	}
+ 
+ 	/* sort by position in user's .newsrc file (new groups come up first) */
+ 	qsort((char *)table, nlines, sizeof table[0], rcsort);
+ 
+ 	/* copy active to newactive, in the new order */
+ 	for (i=0; i<nlines; i++) {
+ 		(void) fseek(actfp, table[i].actpos, 0);
+ 		(void) fgets(line, sizeof line, actfp);
+ 		(void) fprintf(newactive, "%s", line);
+ 	}
+ 	(void) fclose(actfp);
+ 	(void) fclose(newactive);
+ 
+ 	/* make the rest of readnews think the local active file is the real one */
+ 	(void) strcpy(ACTIVE,newactivename);
+ }
-- 
	Marvin Solomon
	Computer Sciences Department
	University of Wisconsin, Madison WI
	solomon@uwisc
	...{ihnp4,seismo,ucbvax}!uwvax!solomon

jpj@mss.UUCP (J. P. Jenal) (01/12/84)

A minor bug to fix in Marvin Soloman's otherwise swell mod to readnews.  In
the function sortactive, there are two identifiers that might well collide
(depending on your compiler.)   In particular, they are 'newactivename' and
'newactive'.  On my system, the second was seen as a redeclaration of the first.

The fix is to simply shorten one of the two names.  I changed newactivename to
newactname and the problem went away.  This is probably obvious to all, but
perhaps someone out there is recently moved to a "smaller" UNIX and might be
in the dark as to why the thing won't compile.

-- 

Cheers...

	Jim Jenal	(aka trw-unix!scgvaxd!mss!jpj)