root@usaos.UUCP (Warren D. Calhoun) (09/05/90)
Running a test-bed setup of cnews (patches to 25 May 90), expire takes several hours to run and creates a history.pag file that appears to take up 25 meg. I know that due to the holes, this apparent size is not right, but what is the real scoop on expire run-time and history.pag size. The system currently has ~5000 articles.
henry@zoo.toronto.edu (Henry Spencer) (09/06/90)
In article <173@usaos.UUCP> root@usaos.UUCP (Warren D. Calhoun) writes: >Running a test-bed setup of cnews (patches to 25 May 90), expire takes several >hours to run and creates a history.pag file that appears to take up 25 meg. I >know that due to the holes, this apparent size is not right, but what is the >real scoop on expire run-time and history.pag size. The system currently has >~5000 articles. Something is very badly wrong with your system. (Have you taken a look through notebook/problems?) It is difficult to say more without knowing details, e.g. are you using dbz or dbm? On utzoo, a Sun 3/180 with good disks, keeping one month of history (circa 135000 history lines), expire typically takes half an hour or so. The .pag file from dbz is circa 6 bytes per history line. You might also try running the expire regression test: "make r" in the expire source directory. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
chip@tct.uucp (Chip Salzenberg) (09/06/90)
According to root@usaos.UUCP (Warren D. Calhoun): >Running a test-bed setup of cnews (patches to 25 May 90), expire takes several >hours to run and creates a history.pag file that appears to take up 25 meg. In the maps, usaos is listed as a '386 system running Interactive Unix. I had similar problems on my SCO Unix system when I compiled "dbz" with the optimizer turned on. Recompiling dbz without "-O" and relinking expire might do the trick. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
calhoun@usaos.UUCP (Warren D. Calhoun) (09/06/90)
In article <1990Sep5.222003.10058@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: *In article <173@usaos.UUCP> root@usaos.UUCP (Warren D. Calhoun) writes: **Running a test-bed setup of cnews (patches to 25 May 90), expire takes several **hours to run and creates a history.pag file that appears to take up 25 meg. I **know that due to the holes, this apparent size is not right, but what is the **real scoop on expire run-time and history.pag size. The system currently has **~5000 articles. * *Something is very badly wrong with your system. (Have you taken a look *through notebook/problems?) It is difficult to say more without knowing *details, e.g. are you using dbz or dbm? * *On utzoo, a Sun 3/180 with good disks, keeping one month of history (circa *135000 history lines), expire typically takes half an hour or so. The .pag *file from dbz is circa 6 bytes per history line. * *You might also try running the expire regression test: "make r" in the *expire source directory. Well, once again, TFM was the answer. In my defense, the only thing I can say is that since I don't have *roff, it usually takes me a while to hand- format and read all of the docs. When I took this particular advice and had a look at notebook/problems, there it was, the -O option when compiling the dbz routines. Removing it and having cc build everything without it cured the problem. history.pag is now 13796 bytes and expire takes about 5 minutes to run. Needless to say, I will force myself to reformat ALL of the docs and read them completely before going any farther. (anybody know of a good PD {n|t}roff that I can get hold of?) Signed [sheepishly]; W.D. Calhoun -- | SSG W.D. Calhoun | UUCP: ...!uunet!usaos!calhoun | | Gas Turbine Engine (52F) Branch | INTERNET: calhoun%usaos@uunet.uu.net | | The U.S. Army Ordnance School | CompUServe: 76336.2212@compuserve.com | | Fort Belvoir, Virginia 22060 | Voice: (703) 664-3396/3595 |
henry@zoo.toronto.edu (Henry Spencer) (09/07/90)
In article <175@usaos.UUCP> calhoun@usaos.UUCP (Warren D. Calhoun) writes: >... (anybody know of a good PD {n|t}roff that I can get hold of?) A limited solution to this problem, workable enough for the C News docs, is in the comp.sources.unix queue (and has been for the last couple of months, sigh...). If you want it, bug Rich Salz about getting "awf" out of the queue and into the newsgroup. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
moraes@cs.toronto.edu (Mark Moraes) (09/07/90)
In news.software.b you write: >Needless to say, I will force myself to reformat ALL of the docs and read >them completely before going any farther. (anybody know of a good PD >{n|t}roff that I can get hold of?) Henry made a cryptic mention of awf, written specifically for this purpose. Since it hasn't shown up in comp.sources.unix yet, an easier way to grab it might be to snarf pub/awf.shar.Z by anonymous ftp from cs.toronto.edu. Here's awf.README. Perhaps some kind soul from osu-cis or uunet will put it there for people without Internet access. Alternatively, try the ftp by mail service offered by bitftp@pucc.princeton.edu (send a message saying "help") If you have GNU C++ (g++), you may want to grab groff instead and get it working. It'll probably run a tad faster. On the other hand, awf is smaller. Mark. ---------- This is awf, the Amazingly Workable Formatter -- a "nroff -man" or (subset) "nroff -ms" clone written entirely in (old) awk. It is slow and has many restrictions, but does a decent job on most manual pages and simple -ms documents, and isn't subject to AT&T's brain-damaged licensing that denies many System V users any text formatter at all. It is also a text formatter that is simple enough to be tinkered with, for people who want to experiment. Type "make r" to run a regression test, formatting the manual page (awf.1) and comparing it to a preformatted copy (awf.1.out). Type "make install" to install it. Pathnames may need changing. I don't know whether awf will run on 16-bit machines. Data requirements are modest, but I fear the programs are probably big enough to run awk out of space. I can't believe I really wrote this. Henry Spencer at U of Toronto Zoology henry@zoo.toronto.edu utzoo!henry 13 July 1990
revell@uunet.UU.NET (James R Revell Jr) (09/07/90)
In article <90Sep6.175510edt.558@smoke.cs.toronto.edu> moraes@cs.toronto.edu (Mark Moraes) writes: >Henry made a cryptic mention of awf, written specifically for this >purpose. Since it hasn't shown up in comp.sources.unix yet, an easier >way to grab it might be to snarf pub/awf.shar.Z by anonymous ftp from >cs.toronto.edu. Here's awf.README. Perhaps some kind soul from >osu-cis or uunet will put it there for people without Internet access pub/awf.shar.Z no available via uucp, anon FTP to uunet.uu.net, and anon uucp on 900-GOT-SRCS -- James Revell uunet postmaster revell@uunet.uu.net /8^{~
rsalz@bbn.com (Rich Salz) (09/08/90)
In <90Sep6.175510edt.558@smoke.cs.toronto.edu> moraes@cs.toronto.edu (Mark Moraes) writes: >Henry made a cryptic mention of awf, written specifically for this >purpose. Since it hasn't shown up in comp.sources.unix yet... It just did... /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
calhoun@usaos.uucp (Warren D. Calhoun) (09/08/90)
In article <2828@litchi.bbn.com> rsalz@bbn.com (Rich Salz) writes: >In <90Sep6.175510edt.558@smoke.cs.toronto.edu> moraes@cs.toronto.edu (Mark Moraes) writes: >>Henry made a cryptic mention of awf, written specifically for this >>purpose. Since it hasn't shown up in comp.sources.unix yet... > >It just did... > /r$ You bet it did. Got it last night and put it to work on about 100 man pages from various places that I've been collecting. It's slow (as advertised), but it DOES work and it IS free. Many thanks for the people who responded. As a side note, some netters also recommended groff, so I tried that as well. After getting gas, bison, gcc, g++, libg++, and groff, and only being able to get gas and bison to compile (gcc doesn't like the Microsoft compiler and blows off with an out of macro space error), I was quite willing to wait the extra time for awf to run. Mind that I would still like to get groff up, but until I can lick the macro problem in the MS compiler I guess I'll have to wait. -- | SSG W.D. Calhoun | UUCP: ...!uunet!usaos!calhoun | | Gas Turbine Engine (52F) Branch | INTERNET: calhoun%usaos@uunet.uu.net | | The U.S. Army Ordnance School | CompUServe: 76336.2212@compuserve.com | | Fort Belvoir, Virginia 22060 | Voice: (703) 664-3396/3595 |